ADKAR is the most quoted change model in the room and the least applied on the ground. I have run it across ERP rollouts and AI programs at scale, and the gap is always the same: teams treat it as a slide, not a sequence. Here is how I actually use it.
The core idea is simple. Change happens one person at a time, through five states in order: Awareness, Desire, Knowledge, Ability, Reinforcement. You cannot skip a stage. If someone is stuck, the model tells you exactly where. That diagnostic power is the whole point, and most people waste it.
Awareness: make the "why" impossible to ignore
Awareness is not a kickoff email. It is the moment a person can explain, in their own words, why the change is happening and what happens if it does not.
Concrete moves I use:
- Write the "why" in one sentence a warehouse operator and a CFO would both accept.
- Have managers deliver it face to face. People believe their direct lead, not a program logo.
- Tie it to a business pain the person already feels, not a strategy abstraction.
The pitfall: confusing communication volume with awareness. Sending forty updates does not create understanding. I test awareness by asking three random people to explain the change. If they parrot the tagline but cannot say why it matters to them, I am not done.
Desire: you cannot mandate it, so stop trying
Desire is the hardest stage because it is personal and political. Awareness answers "why change." Desire answers "why should I."
What works is surfacing the real objections instead of steamrolling them. Fear of looking incompetent. Loss of status. A workflow someone spent years perfecting.
- Map your actual resistors by name and understand their specific loss.
- Recruit visible early adopters who have peer credibility, not just seniority.
- Give people a role in shaping the change so it becomes theirs.
You do not build desire with a benefits slide. You build it by making the person's future in the new world feel safe and worth having.
The pitfall: assuming a good business case creates desire. It does not. Logic informs; emotion decides. I have seen airtight ROI cases die because no one addressed what people were quietly afraid to lose.
Knowledge: teach the job, not the tool
Knowledge is where most programs over-invest and still miss. They train the system and forget the new way of working around it.
Two distinct things live here: knowledge of how to change, and knowledge of how to perform once changed. Both need addressing.
- Train on the new process and decisions, then the software as a supporting layer.
- Deliver training close to go-live. Skills learned three months early are gone by launch.
- Use real scenarios from the person's actual role, not generic demo data.
The pitfall: treating a completed training session as a completed stage. Attendance is not competence. Knowledge means someone understands what to do, which is still not the same as being able to do it under pressure.
Ability: the stage everyone skips
Ability is the delta between knowing and doing. It only appears through practice in real conditions, and it is where transformations quietly break.
People sit through training, pass the quiz, then freeze on day one with a live customer in front of them. That is not a knowledge gap. It is an ability gap, and no amount of extra slides will close it.
- Build a hypercare period with hands-on floor support in the first weeks.
- Create safe practice environments where mistakes cost nothing.
- Pair struggling users with peer coaches, not helpdesk tickets.
The pitfall: declaring victory at go-live. Go-live is when Ability starts, not when the program ends. The budget usually evaporates exactly when people need the most support.
Reinforcement: protect the change from gravity
Every organization has gravity pulling people back to the old way. Reinforcement is how you fight it, and it is almost always the first thing cut.
- Measure adoption, not just deployment. Track whether people actually use the new way.
- Align incentives, targets, and recognition with the new behavior.
- Remove the old system and the old workarounds. If the escape route stays open, people use it.
The pitfall: assuming the change will stick on its own. It will not. Without reinforcement, adoption decays within months and you pay twice for the same transformation.
How I use it day to day
The real value of ADKAR is as a diagnostic, not a checklist. When adoption stalls, I do not push harder on everything. I find the earliest broken stage and fix that.
Someone resisting after months of training is rarely a knowledge problem. It is usually Desire that was never built. Fixing the wrong stage is the most common and expensive mistake I see.
Run it in order, diagnose in order, and never confuse activity with progress. That is the entire field guide.
Cédric Bignet is an AI & ERP Change Management expert at Novartis and founder of AInspire. He writes about change management, AI adoption and enterprise transformation.