A rollout is behind schedule. Adoption is at 40%, the deadline for switching off the old system is in six weeks, and the meeting produces the same decision it always produces: run more training sessions. Attendance will be excellent. Adoption will move by three points.
The ADKAR model exists to prevent exactly that meeting. It is a change management framework, developed by Prosci, that describes the five things one individual needs before a change sticks — and, crucially, insists they are acquired in order. If someone is stuck at element two, everything you do about elements three, four and five is wasted. More training only helps when a lack of knowledge is genuinely what is stopping people, which in software rollouts is the minority case.
This guide covers what each element means, how to find the one that is actually blocking you, and what each fix looks like in a product rather than in a workshop. For the wider process around it — sponsors, communication plans, resistance — see our guide to change management for software adoption, and for the mechanics of the launch itself, the software rollout plan.
Key Takeaways
- ADKAR describes an individual, not an organisation. A company has changed when enough individual people have completed all five elements — there is no separate organisational shortcut.
- The order is not decorative. Each element depends on the one before it, so effort spent past the blockage is wasted.
- The barrier point is the whole tool. Find the first element a group has not achieved; fix only that.
- In software rollouts the barrier is usually Desire or Ability — almost never Knowledge, which is what most programmes spend their budget on.
- Knowledge and Ability are cheapest to deliver in the product, at the moment of use, rather than in a session held three weeks before anyone needs it.
- Reinforcement is a stage, not an afterthought. Most rollouts that "worked" quietly decay in the quarter after launch because nothing closed the old path.
What Is the ADKAR Model?
ADKAR model: definition
ADKAR is a change management model describing the five outcomes an individual must achieve, in sequence, for a change to succeed and last: Awareness of the need to change, Desire to participate in it, Knowledge of how to change, Ability to implement the change in real conditions, and Reinforcement to sustain it. It was developed by Prosci and is used both as a planning framework and as a diagnostic for changes that have stalled.
The reason ADKAR became the default vocabulary for change practitioners is not that the five words are clever. It is the reframing underneath them: organisations do not change, people do. A migration plan with green status across every workstream can still fail, because the plan tracks deliverables while adoption depends on several hundred individuals each independently arriving at Ability and staying there.
That makes ADKAR unusually useful for software, where the unit of adoption is genuinely one person doing one workflow a different way. It is also why the model is often paired with digital adoption tooling: four of the five elements produce measurable in-product behaviour.
The Five Elements, One at a Time
1. Awareness — "I understand why this is changing"
Awareness is not having been told. It is being able to explain the reason in your own words. The test is uncomfortable and worth running: stop someone in the affected team and ask why the system is changing. If the answer is "because IT decided" or "compliance, I think", you do not have Awareness, however many emails were sent.
Awareness fails in a specific way — the message was broadcast from a level too far away. People believe their own manager about their own work; a company-wide announcement establishes that a project exists, not that it matters. The reliable pattern is the same explanation repeated at decreasing distance: leadership sets the context, the immediate manager translates it into "what changes for this team, and why now".
2. Desire — "I am willing to take part in it"
Desire is the only element you cannot manufacture. It is a personal choice, made largely on private arithmetic: what this costs me, what it gets me, what happens if I quietly do not.
This is where most software rollouts actually stall, and it is very often rational. The new CRM gives management better forecasting and gives the sales rep four extra fields per opportunity. The new system is better for the organisation and, at least for the first month, worse for the person being asked to use it. No amount of communicating the vision changes that trade; removing two of the four fields does.
The most useful question in a change programme: what does this cost the person I am asking to change? If you cannot answer it concretely — minutes per day, a workaround they lose, autonomy they give up — you are not yet in a position to address Desire, and every other lever will underperform.
3. Knowledge — "I know how to work the new way"
Knowledge is the element organisations are best at and most over-invest in, because it is the one with an obvious deliverable. It splits in two: knowledge of how to use the thing, and knowledge of how the job is done now — which steps disappeared, which are new, what to do with the exceptions the old process handled informally. The second is routinely forgotten and is usually the part people are actually missing.
Knowledge also decays fast. Training delivered three weeks before go-live is mostly gone by go-live; this is the single most predictable failure in rollout planning. The fix is not more training but later, smaller, in-context training — the argument for delivering it as training in the flow of work rather than as an event.
4. Ability — "I can actually do it, on real work, at speed"
Ability is the gap between the training exercise and Tuesday. Someone can complete a guided scenario on sample data and still be unable to process a live case with a customer waiting, at the pace the job requires. Knowledge is knowing; Ability is doing it under real conditions.
Ability is where reversion happens. Under pressure people fall back on whatever they can do fluently, which is the old way — so the exported spreadsheet lives on for another year alongside the new system, and your usage numbers look fine while the real work happens elsewhere. Ability needs repetition on genuine work, a visible safety net, and someone nearby for the first few attempts.
5. Reinforcement — "nothing pulls me back"
Reinforcement is everything that stops the change decaying once the launch team has moved on: closing the old path, making the new one the default, recognising the people who switched, and continuing to measure long after the project is officially finished.
The most effective reinforcement is structural rather than motivational. If the old export still works, some people will still use it. If the legacy screen is still reachable by bookmark, it will be bookmarked. Removing the alternative does more than any amount of celebration — and it is the step most often skipped, because by then the project has been declared complete.
The Barrier Point: Why the Order Matters
The elements are sequential, and that is the model's actual claim. You cannot want a change you have not heard of. Training someone who has decided the change is a mistake produces attendance and nothing else. Knowing the steps does not mean you can perform them at speed. And a change that was genuinely made can still be lost if nothing holds it in place.
The barrier point is the first element in the sequence that a person or group has not achieved — and it is the only place where effort produces movement. This is why two rollouts with identical symptoms need opposite interventions: 40% adoption caused by a missing Desire and 40% adoption caused by a missing Ability look the same on the dashboard and share no fix at all.
Each element fails with its own distinctive complaint — which is what makes the model diagnostic rather than descriptive.
| Element | In a software rollout it means | Evidence it is missing | What moves it |
|---|---|---|---|
| Awareness | People can say why the old system is going away and roughly when. | Surprise at go-live; "nobody told us"; support tickets asking what the new tool is. | The reason, from the line manager, more than once, with a date. |
| Desire | People are prepared to work the new way even when the old one is still possible. | Attendance without behaviour change; exports back to spreadsheets; polite agreement, no movement. | Remove a real personal cost; involve sceptics in the design; sponsor visibly using it. |
| Knowledge | People know both the tool and the redesigned process around it. | Repeated identical support questions; the same step abandoned by many users. | Short, contextual guidance at the moment of use — not a session weeks earlier. |
| Ability | People complete the workflow on live work at something near normal speed. | First real attempt takes four times as long; high abandonment mid-task; reversion under pressure. | Practice on genuine work, sandbox data, undo, a visible person to ask for the first week. |
| Reinforcement | Usage is still there ninety days later, without the launch team pushing. | A clean adoption curve that sags at week six; the old export still running. | Close the alternative, make the new path the default, keep measuring past go-live. |
How to Run an ADKAR Assessment in a Week
The assessment is deliberately crude, and its value is in the ranking rather than the numbers. Each person scores themselves one to five on each element; the barrier point is the first element scoring three or below. Aggregate by group, not across the whole population — a single average hides the thing you are looking for.
- Define the change as a behaviour, not a tool.
- Segment the people it affects into groups that will experience it differently.
- Score each group against the five elements — survey, or ten conversations.
- Find each group's barrier point and ignore everything past it.
- Pick one intervention per group and re-measure in three weeks.
1. Define the change as a behaviour
"Roll out the new platform" is not assessable. "Account managers log every client interaction in the platform on the day it happens, instead of in their own notes" is: it names who, what and when, and you can tell whether it is happening. Vague change definitions produce vague scores and are the most common reason an ADKAR assessment tells you nothing.
2. Segment before you score
Different groups have different barrier points and there is no useful average between them. New joiners have no old habit and often need only Knowledge; ten-year veterans may have full Knowledge and no Desire whatsoever. Split by role, by tenure, by site, by how much the change actually costs them — the same logic you would use for user segmentation in a product.
3. Score honestly, in small numbers
Ten real conversations beat a 500-person survey with a 12% response rate, because the people who answer surveys about a change are systematically the people already engaged with it. Ask for the reason behind each low score; the reason is the intervention.
4. Fix only the barrier point
This is the discipline the model exists to enforce. If a group's barrier is Desire, cancel their extra training session and go find out what the change costs them. If the barrier is Ability, stop sending explanatory material and get them doing the task on live work with support beside them.
5. Re-measure, and expect the barrier to move
Clearing a barrier does not finish the work — it reveals the next one. A group that gains Desire this month will surface a Knowledge gap next month, and that is the model working correctly rather than a sign the intervention failed.
Where ADKAR Meets Product Analytics
Awareness and Desire live in people's heads and have to be asked about. Knowledge, Ability and Reinforcement leave fingerprints in the product — which is what makes ADKAR far more measurable for software than for most changes it is applied to.
A single step abandoned by many different users is a knowledge gap with an address. Fix the step, not the curriculum.
Compare a new user's first live completion with a fluent one. A 4× gap is an Ability problem, however good the training scores were.
Adoption at launch is attendance. The number that matters is whether the behaviour is still there a quarter later.
Two of those are ordinary feature adoption measurements; the third is a retention question. If you want a structured way to collect them before a rollout rather than after, the onboarding audit checklist transfers almost unchanged to an internal system.
Delivering Knowledge and Ability Inside the Product
Knowledge and Ability are the two elements a training programme is supposed to cover and the two it is worst at, for the same reason: both are needed at the moment of the task, and training happens weeks earlier in a different room. Everything that closes that gap moves guidance closer to the work.
-
Walk the first real task, not a demo of the whole system
A short guided flow on the workflow someone actually has to do today converts Knowledge into Ability in one pass — the thing a feature tour never does. See building a product tour that converts.
-
Answer the recurring question where it is asked
The step ten people got wrong needs a tooltip on that field, not a paragraph in a document nobody opens.
-
Make the new process visible as a checklist
A short onboarding checklist shows the redesigned job, not just the buttons — which is the half of Knowledge most rollouts skip.
-
Carry Awareness into the app itself
An in-app message at the moment someone opens the old screen reaches people the announcement email did not.
-
Trigger help by behaviour, not by calendar
Behaviour-based triggers deliver the reminder to the person who abandoned the step — and stay silent for the one who did not.
Deliver Knowledge and Ability where the work happens
Kompassify lets you build guided flows, checklists and contextual tooltips on top of your existing software — no engineering, no release cycle when the process changes — and shows per-step completion so you can see which element is actually missing. GDPR compliant, EU-hosted, free up to 100 monthly active users and from $129/mo after that.
Start for Free →ADKAR: Do vs. Don't
✅ Do
- Define the change as an observable behaviour before scoring anything.
- Assess by group — role, tenure, site — never as one average.
- Spend on the barrier point and nothing past it.
- Ask what the change costs the individual, specifically.
- Deliver Knowledge close to the moment of use.
- Keep measuring ninety days after go-live.
❌ Don't
- Answer every adoption problem with more training.
- Treat ADKAR as a project checklist to tick off in order.
- Assume a communications campaign produces Desire.
- Confuse training completion with Ability.
- Leave the old path open and call the change done.
- Score the whole organisation and act on the mean.
The most common misuse: running ADKAR as a five-phase plan — an awareness phase, a desire phase, a knowledge phase — delivered to everyone at once. The model is not a schedule. Five groups will sit at four different barrier points on the same Monday, and a sequential programme serves all of them badly. Use it as a diagnostic per group, then act per group.
ADKAR and the Other Change Models
ADKAR is an individual-level model, which is why it coexists comfortably with the organisation-level ones rather than competing with them. Leadership frameworks describe what an executive team does — establish urgency, build a coalition, communicate a vision, secure early wins. ADKAR describes what must be true inside one person for any of that to convert into behaviour. A practical division of labour is to run the programme with an organisational model and reach for ADKAR the moment a specific team, region or role is not moving, because it will tell you which of five very different problems you have. Our change management guide covers the other models in plain language and the seven-step process around them.
One honest limitation: ADKAR is strongest when the change is reasonably well defined and the affected population is known. It has less to say about whether the change is the right one, about organisational politics, and about changes that are genuinely contested at the leadership level. It diagnoses adoption; it does not adjudicate strategy.
The One-Sentence Version
ADKAR says a change happens one person at a time, in a fixed order, and stops at the first missing element — so the only question worth asking about a stalled rollout is which element is missing for which group, because four of the five possible answers make "more training" the wrong move.
Frequently Asked Questions
What is the ADKAR model?
ADKAR is a change management model, developed by Prosci, that describes the five things one individual needs in order to adopt a change and keep it: Awareness of why the change is happening, Desire to take part in it, Knowledge of how to work the new way, Ability to actually do it in real conditions, and Reinforcement that stops the old way returning. The distinctive idea is that it is a model of a person rather than a project — an organisation has changed only when enough individuals have completed all five, and the elements must be acquired in order.
What does ADKAR stand for?
Awareness, Desire, Knowledge, Ability, Reinforcement. Awareness is understanding why the change is needed. Desire is the personal decision to participate. Knowledge is knowing how to work the new way. Ability is being able to do it in real conditions, at real speed, on real work. Reinforcement is everything that keeps the new behaviour in place once the launch attention has gone.
What is the barrier point in ADKAR?
The barrier point is the first element in the sequence that a person or group has not achieved. Because the five elements build on each other, everything after the barrier point is wasted effort until it is cleared: training someone who does not want the change produces attendance rather than adoption. Finding the barrier point is the entire practical value of the model, because it tells you which intervention will work and which will be ignored.
How do you use ADKAR for a software rollout?
Define the change as a specific behaviour rather than a tool, segment the people it affects into groups that will experience it differently, assess each group against the five elements, then fix only the barrier point for each group. In a software rollout the barrier is usually Desire or Ability rather than Knowledge — people know what the new system is and were trained on it, but the new way is slower for them personally, or they have never done it once on live work. Knowledge and Ability are best delivered inside the application itself, at the moment of use, rather than in a session weeks earlier. The surrounding mechanics are covered in our software rollout plan.
How do you measure ADKAR?
The classic method is a short assessment where each person scores themselves one to five on each element, and the barrier point is the first element scoring three or below. For software specifically, pair that with behavioural evidence: Awareness and Desire show up in survey answers, but Knowledge, Ability and Reinforcement show up in product analytics — who has completed the new workflow once, how long it takes them compared with an experienced user, how often they abandon halfway, and whether usage is still there ninety days after launch.
What is the difference between ADKAR and Kotter's 8-step model?
They operate at different levels and are usually complementary rather than competing. Kotter's eight steps describe what leadership does across an organisation — build urgency, form a coalition, communicate a vision, generate short-term wins. ADKAR describes what has to happen inside one individual for the change to stick. A common working pattern is to run the organisational programme with one of the leadership models and use ADKAR as the diagnostic when a particular team or region is not moving. Both are summarised in our change management guide.
Can ADKAR be used for customer-facing software, not just internal rollouts?
Yes, with one adjustment: with customers you have far less authority and far more signal. You cannot mandate Desire or schedule a training session, so Awareness and Desire have to be earned through the product experience and in-app messaging, and Knowledge and Ability have to be delivered contextually at the moment of use. In exchange you can see exactly where people stop, which internal rollouts often cannot. The five elements still map cleanly onto a migration, a redesign, or the launch of a major new feature.
Why do software rollouts fail even when training is good?
Because training only ever addresses Knowledge, and Knowledge is rarely the barrier point. If Desire is missing, training produces attendance and no behaviour change. If Ability is missing, people can pass a training exercise and still be unable to do the task on a live customer at normal speed, so they revert to the old way at the first sign of pressure. And if Reinforcement is missing, the change genuinely happens and then decays over the following quarter because the old path was left open and nothing made the new one the default.