The ADKAR Model Explained for Tech Leaders

Change models get read as plans. ADKAR is not a plan — it's a diagnostic, run one person at a time, and its value is that it tells you which of five very different interventions will actually work.

Note, 4 October 2026. The organisation in this example is a composite: a regional healthcare provider drawn from patterns that recur across several regulated organisations, not a real organisation or a single incident.

The provider replaced a twelve-year-old scheduling system across three sites. Forty clinicians, a nine-month project, a clean go-live.

Six weeks later, eleven of the forty were still booking on paper and typing it in afterwards.

Leadership ran a third training session. Attendance was good. Usage didn't move.

Then someone sat with all eleven individually, which took an afternoon. The eleven were not one problem. Two didn't know the paper route was being retired at all. Seven understood it perfectly and had decided against it. One couldn't complete a recurring booking without help. One had gone back after a bad week and never returned.

Only one of those eleven had a knowledge problem. Training was the wrong instrument for ten of them.

Five gaps, and four of them look the same from outside

What you observe is identical in almost every case: this person isn't using the new thing. ADKAR's contribution is that it splits that single observation into five states, in order — and each one has a different remedy that does nothing for the other four.

Gap	What you actually observe	The default response	What works
Awareness — doesn't know it's happening, or why	Still on the old way, unbothered	More announcements	Say what changes for them, and when the old way stops
Desire — knows, and won't	Attends everything, adopts nothing	More training, then pressure	Find what it costs them. Usually a real cost
Knowledge — wants to, doesn't know how	Asks questions, tries, gets stuck	Training	Training — this is the one it fixes
Ability — knows how, can't in practice	Fine in the session, fails at the desk	"Refresher" training	Remove the environmental blocker
Reinforcement — adopted, then reverted	Used it for a fortnight, drifted back	Nothing; it goes unnoticed	Make the old path harder than the new one

The middle row is the only one training addresses. It is also the response applied to all five, because it's the one intervention that is easy to schedule, easy to attend, and easy to record as done.

The test you can run: take the last change your team rolled out and name three people who didn't adopt it. For each, say which of the five rows they were in. If you can't, you don't know whether your rollout plan addressed anything.

The Knowledge/Ability distinction is the one that saves the most money

These two get collapsed constantly, and the collapse is expensive because Ability failures are invisible in training.

Knowledge is "I don't know how." Ability is "I know how, and I still can't do it here." Someone completes the exercise perfectly in the session, goes back to their desk, and hits something the session didn't have: a permission they don't hold, a screen that behaves differently with real data, a workflow that takes four minutes they don't have between patients.

The provider's single Ability case was a clinician who could book a recurring appointment in training and not in clinic — because in training the room availability was clean, and in clinic it wasn't. That is not a training gap. No repetition fixes it.

The diagnostic question that separates them: can they do it right now, at their own desk, with you watching? If yes, it was Knowledge and it's fixed. If they can do it in a demo environment but not their own, it's Ability, and the fix is in the environment.

The test: for anyone you've labelled "needs more training", watch them attempt it in their real environment once. Most "training gaps" are resolved or reclassified inside five minutes.

Desire is usually a design finding wearing a resistance costume

Seven of the provider's eleven were Desire, and this is the row that most often gets treated as an attitude problem.

It rarely is. Those seven had measured the thing: for clinicians with complex recurring caseloads, the new system added roughly four minutes per appointment. Across a full clinic that's most of a lunch break. They weren't resisting change — they were declining a worse deal, correctly.

The fix wasn't persuasion. It was a template for recurring complex bookings, which removed the four minutes. Adoption in that group went from nought to complete in about two weeks, with no further training and no conversation about mindset.

The reason this matters beyond politeness: a Desire gap is often the only honest usability feedback you will get, and treating it as resistance destroys the signal. The people declining are the ones who have actually used the thing under real conditions.

That said, not every Desire gap is a design finding. Some are a genuine loss — status, autonomy, a task someone enjoyed. Those are real too, and they need naming rather than fixing; that's managing resistance and it's a different conversation. But check for the four minutes first.

The test: ask one non-adopter what the change costs them, and treat the answer as a bug report. If it is a bug report, you've found a defect the project missed.

Run it per person, on a sample — not as a survey

ADKAR is often deployed as a questionnaire across the whole affected population, scored, and averaged. That produces a chart and destroys the information, because the five states are individual and the average of an Awareness gap and a Desire gap is meaningless.

What works is smaller and less formal:

• Sample five to eight non-adopters. Not the enthusiastic ones, not the whole population.

• One conversation each, about ten minutes, in their environment.

• Ask in ADKAR order and stop at the first gap. The states are sequential — someone who doesn't know the change is happening has no useful opinion on whether they want it. Diagnosing past the first gap collects noise.

• Count the gaps. Eleven people is not eleven problems; the provider's eleven were four problems, one of which covered seven people.

An afternoon of this beats a survey of four hundred, because the output is a decision — which of five interventions to fund — rather than a score.

The test: count how many distinct gaps your non-adopters fall into. If it's one, you have one thing to fix and it's probably cheap.

Where ADKAR is the wrong instrument

It diagnoses individual adoption. That is genuinely useful and genuinely narrow.

• The change is mandatory and immediate — a security patch, a compliance deadline. Desire isn't a variable you're managing; you're managing enforcement and support.

• Nobody has to change behaviour. A backend migration nobody notices needs a rollback plan, not an adoption diagnostic.

• The change is wrong. ADKAR will faithfully tell you people don't want it, and can be used to bulldoze past a correct objection. The model has no opinion about whether the change should happen.

• You need to sequence an organisation-wide programme. ADKAR says nothing about order, coalitions, or timing — that's Kotter's territory, and the state the organisation as a whole is in is Lewin's.

• You want to know how long people will feel unsettled. ADKAR has no time axis at all. The individual's timeline is the Bridges model.

The test: before running the diagnostic, ask what you would do if the answer came back "Desire, and their reason is sound." If the honest answer is "proceed anyway", don't run it — you're gathering evidence you've pre-committed to ignore.

What to do this week

Take a change your team rolled out in the last quarter that hasn't fully landed. List the people still on the old way. Talk to five of them, in their environment, for ten minutes each, asking in order and stopping at the first gap.

Then count. Almost every team finds the same thing the provider did: what looked like one adoption problem is two or three distinct gaps, most of the population sits in one of them, and the intervention already scheduled addresses a different one.

The eleven clinicians are all on the new system now. It took a template, one permission change, and two conversations. It did not take a fourth training session, which had already been booked.