An institution chooses a new platform or integration. The demo was convincing, the contract is signed, the deployment goes as planned. Six months later, many instructors still email documents to students, keep grades in spreadsheets and ask the help desk where to find their class. The software works. People just aren't using it.
That's an adoption problem, and it's the most expensive way for a campus technology project to fail, because the subscription, the integration work and the training have already been paid for. It shows up at predictable moments: the first week of term, when faculty fall back on what they know; mid-term, when the pilot enthusiasm fades; and at renewal time, when someone asks what the institution actually got for its money.
Why do rollouts stall after go-live?
Across the cégeps, colleges and universities we've worked with, the same three patterns come up again and again.
- IT led the rollout alone. When the main argument is that the tool saves IT work, faculty have no reason to change how they teach. The benefit lands on someone else.
- Everyone got it at once. A campus-wide launch leaves no reference users, no internal champions and no colleague down the hall who can answer a quick question.
- Training came too early. Sessions held weeks before the tool is in production are forgotten by the time people need them.
There's a fourth, quieter cause: the first experience is empty. A teacher opens the new platform and finds nothing there. No class, no students, no schedule. They have to build it all before they get any value, in the busiest week of the term.
What it costs
Failed adoption rarely appears as a line in the budget, which is why it's underestimated. It shows up as:
- Subscriptions paid for tools that only a minority of faculty use.
- Parallel systems IT has to keep running because nobody moved.
- Students who check three places to find course material, because each instructor chose a different one.
- Help-desk volume that never comes down after the launch peak.
- Lost credibility for the next project: faculty who lived through one stalled rollout are slower to try the next one.
What doesn't work
Mandates without help. Requiring every course to use the new platform by a given date produces compliance on paper: empty course shells with a link to an email address.
One big training session. A two-hour demo in August covers features people won't need until October. Without practice, it's gone by the time they do.
Feature tours. Showing every capability overwhelms people. Faculty want to know how to do the three things they do every week, faster.
Launching mid-term. Switching tools in the middle of a term forces faculty to move courses that are already running. Launch between terms, or with the next term's classes only.
Measuring deployment. "All 2,000 sections are provisioned" says the integration works. It says nothing about whether anyone opened them.
How do you get faculty and students to adopt a new tool?
1. Start with five teachers who want it
Find around five instructors per campus, or per large department, who are curious about the tool. They don't need to be the most technical; they need to be the ones colleagues talk to. Make them the pilot group and the visible faces of the rollout. When a colleague shows how she merged her three sections into one space, it lands in a way no IT email ever does.
Give the pilot group what it needs to succeed: access a few weeks before everyone else, a direct line to the project team and visible recognition, such as a few minutes at a department meeting. Ask them what's confusing and fix it before the wider launch. Every problem they hit is one a hundred colleagues won't.
2. Make the first ten minutes end with a win
Adoption depends on how quickly someone gets value. Design the first ten minutes so a teacher sees something useful without configuring anything:
- Pre-populate everything that can be pre-populated: classes, rosters, schedules. This is where connecting the platform to the student information system (SIS) pays off.
- Make the default setup usable as it is.
- Put the thing instructors actually want to do (post a document, message the class, start a meeting) on the first screen.
3. Train just in time, in short pieces
Offer short, task-based help in the week people need it: a five-minute video on posting the first assignment, a drop-in session during the first week of term, an instructional designer reachable in Teams. Pedagogical advisers and instructional designers are often the best people to lead this, because they speak both languages, teaching and technology.
4. Talk to students separately
Students don't care about your workflow. They care about not missing a class or an assignment. Explain the tool in terms of the friction it removes from their week ("your classes, readings and schedule are in one place from day one"), through the channels they actually check, such as their Teams feed or the learning platform, rather than an email they won't open.
Tell them what changes, when, and where to get help. A short message at the start of term, repeated by instructors in the first class, does more than a long announcement nobody reads to the end.
5. Measure adoption, not deployment
| Measure | What it tells you | What to watch for |
|---|---|---|
| Weekly active instructors | How many faculty performed a meaningful action, not just a sign-in | Steady growth beyond the pilot group |
| Weekly active students | Whether students actually go there for course material | Gaps by program or campus |
| Tickets per 1,000 users | Whether people are trying, then succeeding | An early rise is healthy; it should level off and decline within a few months |
| Would-recommend score | Whether faculty would suggest the tool to a colleague | Comments from skeptics, not just the average |
6. Don't switch off the old way too soon
Run the previous tool or process alongside the new one for one full term. Faculty need time to learn, verify and build confidence. Announce the end date early, then retire the old system once usage has clearly moved. Turning it off on launch day is a reliable way to start a conflict instead of a transition.
How LS2 approaches it
LS2's higher-education products are built around the first-ten-minutes problem. Teameo, Classeo and Calendo read the institution's SIS, so when an instructor opens Microsoft Teams, Moodle or their calendar for the first time, the class already exists, the right students are in it and the schedule is where it should be. Cross-listed sections can arrive already merged into a single class. There's nothing to build before teaching starts.
That removes one of the most common reasons faculty give up in the first week, and it frees pedagogical advisers to focus on teaching practice rather than on creating class spaces. During deployment, LS2 works with the institution's IT team and pedagogical advisers on the go-live plan, so classes are ready before the start of term and support stays close through add/drop week. The steps are laid out in From contract to first class: a realistic SIS integration rollout plan, and the reasoning behind them in One source of truth: connecting your SIS to Teams, Moodle and calendars.
For a wider view of where these tools fit, see our pages on higher education digital transformation, digital learning platforms and EdTech for higher education.
Key takeaways
- Adoption fails when a rollout is led by IT alone, deployed to everyone at once and trained before the tool is live.
- A small pilot group of faculty who want the tool persuades colleagues more than any IT announcement.
- Design the first ten minutes so a teacher sees a working class, roster and schedule without configuring anything.
- Talk to students separately, about the friction the tool removes from their week, in the channels they check.
- Measure weekly active use and support tickets, not accounts provisioned, and keep the old way available for one term.
Planning a rollout faculty will actually use?
A 30-minute demo shows what instructors see on day one: classes, rosters and schedules already in Teams, Moodle and their calendars.
Book a demoFrequently asked questions
Why do faculty resist new educational technology?
Usually not because they dislike technology. Faculty resist tools that cost them time during a term that's already full, that arrive with training weeks before they need it, or that are presented as saving IT work rather than solving a teaching problem. When a tool gives them something useful on the first day, such as a class that already contains the right students, resistance drops.
How many faculty should be in a technology pilot?
Small enough to support closely, large enough to be visible. A practical starting point is around five interested instructors per campus or large department, chosen for how well they communicate with colleagues rather than for technical skill. They become the people others ask, and their answers carry more weight than messages from IT or from the vendor.
How do you measure whether a new tool is actually adopted?
Track behavior, not deployment. Useful measures are the number of instructors and students who perform a meaningful action each week, the trend in support tickets per 1,000 users, and a short survey after a few months asking faculty whether they would recommend the tool to a colleague. Accounts created and classes provisioned only prove that the deployment happened.
Should we turn off the old system when the new one goes live?
Not right away. Keeping the previous tool or process available for one full term lets faculty verify the new one, build confidence and move at their own pace. Announce the end date early, support the transition, and retire the old system once usage has clearly shifted. Switching it off on launch day tends to turn a rollout into a conflict.