Insights / Perspective / Change management and implementation training
PerspectiveMake change stick: what the evidence says about adoption
What Prosci's research says about adoption, why people resist new ways of working, and how to plan for change before a project begins.
Most organisations judge a new system or process by whether it went live on time and on budget. The more useful question is whether people actually use it, and whether the business gets the benefit it paid for. Go-live is the start of adoption, not the end of the project.
Prosci’s long-running research compares projects by the quality of their change management. In its findings, 88% of projects with excellent change management met or exceeded their objectives, against 13% of those with poor change management. That makes them about seven times more likely to succeed. Few other single factors in a programme show a gap that wide.
Why adoption fails
People rarely resist change out of stubbornness. They resist because they do not understand why it is happening, because they fear losing status or hard-won skills, or because nobody asked them how the work really gets done. Each of these is a reasonable response to a poorly explained change.
Consider a typical finance team moving to a new purchase-to-pay system. The designers map the official process. They do not see the spreadsheet a senior clerk uses to track disputed invoices, or the phone calls that resolve urgent supplier payments. When the new system goes live, those informal routines have no home. The team keeps the spreadsheet, the calls continue, and the new system becomes one more step rather than a replacement.
This is how workarounds are born. They are not acts of defiance. They are the business protecting itself from a design that did not reflect reality.
Read resistance as information
When a group pushes back, ask what they know that the project does not. Resistance often points to a missing process step, an unworkable timeline or a loss that nobody acknowledged.
What good change management looks like
Good change management is not a communications plan bolted onto a technical project. It is a set of disciplined activities that run alongside design, build and launch, each with an owner and a measure.
- Sponsors who explain the reason for change in their own words, show up at key moments and make visible decisions that support it.
- Early impact analysis that lists, role by role, what changes, what each person needs to learn and what they might lose.
- Communication that is honest about trade-offs and repeated through different channels: team meetings, short videos, manager briefings and written guides.
- Role-based training built around real scenarios from people’s own work, supported by champions in each team who can answer questions on the spot.
- Measures after launch: usage, error rates, support requests and direct feedback, reviewed weekly in the first months.
Of these, sponsorship is the one most often underestimated. A sponsor who approves the budget and then disappears sends a clear message that the change is optional. A sponsor who attends a training session, asks about adoption figures in leadership meetings and removes obstacles sends the opposite message.
Impact analysis is the second most neglected activity. It sounds administrative, but it is where the programme learns who will feel the change most. A list of roles, with a short note on what each gains and loses, lets the team target support where it matters. A buyer who loses the authority to approve small orders needs a different conversation from a clerk who simply learns new screens.
Start before the project starts
The most common mistake is treating change management as a training session in the week before go-live. By then, the decisions that cause resistance have already been made: the process design, the screen layouts, the reporting lines, the timing. Training cannot fix a design that people find unworkable.
Involve the people who will use the new process in its design. Run short workshops where they walk through their real day and show where the new approach helps and where it gets in the way. Use their feedback to improve it, and tell them what changed as a result. People support what they help to build.
Once the warehouse supervisors helped redesign the picking screens, they became the ones explaining the new system to everyone else.
Operations director, distribution client
Keep going after go-live
Adoption usually dips in the weeks after launch. People are slower in the new system, errors rise, and the temptation to return to old habits is strong. This is normal, and it is exactly when support matters most.
The dip is also where many programmes lose their sponsors. Leaders see the early complaints and slower processing times and start asking whether the project was a mistake. Warn them in advance that the dip is coming, agree what level of disruption is acceptable, and show them the trend week by week. A dip that is expected and managed is far less alarming than one that arrives as a surprise.
Plan for at least eight to twelve weeks of active support after go-live. Keep champions available, run short refresher sessions on the tasks causing the most problems, and track usage by team so you can see where help is needed. Retire the old system or spreadsheet on a firm date, or it will quietly remain the real process.
A simple test
Ask three frontline employees to explain why the change is happening and what is in it for them. If they cannot, the programme has a communication problem, not a training problem, and no amount of extra training will solve it.
Run the test early, before design is complete, and again a month after launch. The answers will tell you more about the likely success of the project than any status report.
If the answers are vague, return to the sponsor and the managers before adding more training. Ask them to explain the change to their teams again, in their own words, with a clear statement of what will be different and why. Then run the test once more.
Source: Prosci, Best Practices in Change Management.
