Change management for digital transformation: using ADKAR and Kotter so people actually adopt the new way
Go-live is not adoption. How Kotter's eight steps and the ADKAR model work together in a transformation program, how to find each team's barrier point, which actions fix which barrier, and how to measure adoption.
The system went live on time and on budget. Three months later, half the team is still using the old spreadsheet, the other half uses the new tool in ways nobody intended, and the promised benefits are nowhere to be seen. Technically, the project succeeded. In every way that matters, it didn't.
This is the most common way digital transformations fall short. BCG found that 70% of digital transformations fall short of their objectives, and in a McKinsey survey only 16% of respondents said their transformation had improved performance and sustained it. The fix isn't more communication emails. It's treating adoption as part of the work, with the same structure you'd give the technology.
Two models do most of the heavy lifting: Kotter's eight steps for leading the change across an organisation, and ADKAR for getting each person through it.
Two models, two jobs
| Kotter's 8 steps | ADKAR | |
|---|---|---|
| Level | The organisation | The individual |
| Answers | "What must leadership do, in what order?" | "Where is this person or team stuck?" |
| Origin | John Kotter, Harvard Business Review, 1995 | Jeff Hiatt, Prosci, developed in 1996 |
| Best used for | Planning the program's change activities | Diagnosing resistance and targeting help |
They're complementary. Kotter tells leadership what to do. ADKAR tells you whether it's working, team by team.
Kotter's eight steps, in a digital program
| Step | What it looks like in practice | Warning sign it was skipped |
|---|---|---|
| 1. Create a sense of urgency | Show the cost of today's process in numbers: hours, errors, lost customers | People ask "why are we doing this?" at go-live |
| 2. Build a guiding coalition | A sponsor with authority, plus respected people from each affected team | The program is seen as "an IT project" |
| 3. Form a vision | One sentence on how work will be different, and why that's better | Every presentation explains it differently |
| 4. Communicate the vision | Repeated, by line managers, in team meetings, not only by email | Teams hear about changes from rumours |
| 5. Remove obstacles | Fix the old incentives, reports and approvals that pull people back | "The new tool is fine, but my boss still wants the Excel" |
| 6. Create short-term wins | A visible, measured improvement within the first few months | Momentum fades after launch |
| 7. Build on the change | Use early wins to take on the harder processes | The program declares victory at go-live |
| 8. Anchor it in the culture | New ways become the standard: in onboarding, KPIs and job descriptions | Six months on, the old way creeps back |
Kotter's original argument, drawn from more than 100 companies, was that skipping steps creates only the illusion of speed. (He has since reworked the steps into eight "accelerators" that run in parallel, but the sequence is still the clearest way to plan.) In digital programs, step 5 is the one most often skipped: the tool changes, but the reports, approvals and targets around it don't.
ADKAR: what each person needs
- Awareness of why the change is needed. Do I understand the reason?
- Desire to take part. Do I want to, and what's in it for me?
- Knowledge of how to change. Do I know what to do differently?
- Ability to do it in real work. Can I actually do it, at full speed?
- Reinforcement to keep it going. Is anything making me stick with it?
The order matters. Training (Knowledge) doesn't help someone who doesn't see why the change is needed (Awareness). This is why a training-only rollout so often fails: it jumps to step three.
Find the barrier point
Ask each team to rate each element from 1 to 5, in a short anonymous survey or in facilitated conversations. The first element in the sequence that scores 3 or lower is the barrier point. Everything after it is secondary until it's fixed.
Reading the chart:
- Finance has no barrier. They asked for the change and use the system well. Keep reinforcing.
- Sales is stuck at Awareness. Scores for later elements are low too, but more training won't help: they don't see why the change matters. Their leaders need to explain it, in their own terms.
- Warehouse understands and wants the change, but is stuck at Knowledge. They need hands-on training on their actual tasks.
- HR knows how, but is stuck at Ability. They need practice time and someone on hand in the first weeks.
Four teams, one rollout, three completely different fixes. A single company-wide change plan would have missed all three.
Match the action to the barrier
| Barrier | Typical symptom | What works | What doesn't |
|---|---|---|---|
| Awareness | "Why are we even doing this?" | The sponsor and direct managers explaining the reason, with numbers | A newsletter |
| Desire | "I get it, but not for me" | Answering "what's in it for me", involving people in the design, removing personal downsides | More facts about the business case |
| Knowledge | "I don't know how to do my job in it" | Role-based training on real tasks, just before go-live | Generic training months early |
| Ability | "I know how, but it's slow and I get stuck" | Practice, floor support, super-users, time to learn | Assuming training equals ability |
| Reinforcement | Old workarounds come back | Recognition, KPIs and reports that use the new way, switching off the old one | Declaring victory at go-live |
Does it make a difference?
Prosci's long-running research with more than 2,600 practitioners links the quality of change management to project results:
| Change management was… | Projects that met or exceeded objectives |
|---|---|
| Excellent | 88% |
| Good | 73% |
| Fair | 39% |
| Poor | 13% |
The numbers are self-reported, and they come from the company that sells ADKAR, so read them as direction rather than precision. The direction is hard to argue with.
Measure adoption, not go-live
Go-live is a date. Adoption is a result. Track these for at least three months after launch:
| Measure | What it tells you | Example target |
|---|---|---|
| Usage | Share of intended users active each week | Above 90% by week 6 |
| Proficiency | Errors, rework and time per transaction | Time per case back to baseline by week 8 |
| Workarounds | Shadow spreadsheets, emails and manual steps still in use | Old process switched off by week 12 |
| Speed of adoption | How quickly each team reaches the target | No team more than 4 weeks behind |
| Business outcome | The benefit the change was for | Cycle time, cost or error rate from the business case |
Break every measure down by team. The averages will hide the one team that's struggling, and that team is usually where the barrier point is.
A 90-day plan for your next rollout
- Before launch: name the sponsor, write the one-sentence vision, run a first ADKAR survey, and plan the obstacles you'll remove (reports, approvals, incentives).
- Launch: role-based training right before go-live, super-users in every team, visible sponsor presence.
- Weeks 2 to 6: track usage weekly, run a second ADKAR survey, and act on each team's barrier point.
- Weeks 6 to 12: publish the first measured win, switch off the old way, and fold the new process into onboarding and KPIs.
None of this is complicated. It's just usually left out of the plan, because it doesn't appear in the technology project's scope. Put it in.
Sources
- Kotter, J. P. (1995). Leading change: why transformation efforts fail. Harvard Business Review, March to April 1995.
- Kotter Inc. The 8 steps for leading change.
- Hiatt, J. (2006). ADKAR: A Model for Change in Business, Government and Our Community. Prosci.
- Prosci. The Prosci ADKAR Model.
- Prosci. The correlation between change management and project success.
- Boston Consulting Group (2020). Flipping the odds of digital transformation success.
- McKinsey (2018). Unlocking success in digital transformations.
The teams and scores are illustrative.