The five elements in sequence
| Element |
What it means for one person |
What its absence looks like |
| Awareness |
They understand why the change is needed, in business terms |
"Nobody has explained why we are doing this": resistance framed as confusion |
| Desire |
They have personally decided to support the change |
Compliance in meetings, workarounds at the desk |
| Knowledge |
They know how to change: new process, new system, new role |
People willing to change but making it up as they go |
| Ability |
They can actually perform the new way, at real-world pace and volume |
Trained and certified, yet productivity collapses at go-live |
| Reinforcement |
The new way is rewarded, measured and made permanent |
Quiet reversion within two quarters of the programme team disbanding |
The barrier point, and why it matters
ADKAR's most useful concept is the barrier point: the first element in the sequence that is missing for a given group. Everything invested beyond the barrier point is wasted until the barrier is cleared: more training does nothing for a team whose barrier is desire, and more town halls do nothing for a team whose barrier is ability. Diagnosing the barrier per group, rather than pushing a uniform plan at everyone, is the difference between managing change and performing it.
Where it fits in a decision process
- Before a transformation budget is approved: an honest ADKAR view of the affected population tests whether the adoption assumptions in the business case are plausible.
- When a live programme is stalling: mapping each stakeholder group against the five elements usually locates the stall more precisely than a programme review does.
- Before benefits are declared: benefits that depend on changed behaviour are not real until reinforcement exists, which is exactly when most programmes stop paying attention.
A concrete sketch
Picture a field-service business rolling out dynamic scheduling. Head office assumes the barrier is knowledge, so it commissions training. An ADKAR pass by region tells a different story: dispatchers in one region have a desire problem (the new system removes discretion they regard as their expertise), while engineers in another have an ability problem, because the app assumes connectivity their rural patch does not have. Same programme, two different barriers, neither of which training addresses. The rollout plan is resequenced accordingly, and the training budget shrinks while adoption improves.
How ADKAR degrades into a comms plan
The model is individual and diagnostic; organisations flatten it into something broadcast and generic.
- Desire is assumed because leadership desires it. The programme measures messages sent, not minds changed, and discovers the difference at go-live.
- Awareness is treated as done after the announcement. Awareness of the change is not awareness of the reasons for it. ADKAR requires the second, and most programmes deliver the first.
- Ability is signed off from training-completion dashboards. Certification in a sandbox says nothing about performing the new process at month-end volume with real customers on the phone.
- Reinforcement is dropped entirely: the programme closes at go-live, incentives still reward the old behaviour, and the organisation reverts within two quarters, then blames the software.
The honesty problem, and where outside perspectives help
ADKAR assessments depend on people telling the programme the truth about desire (their own and their teams'), and the incentives run the other way: no middle manager reports that their function does not want the sponsored change. Independent perspectives from operators who have run comparable rollouts recalibrate the two assessments internal teams flatter most: how much genuine desire exists, and how long ability actually takes to build. This level of adoption risk warrants challenge before the benefits case is committed, not after.
