ADKAR Model

What is the ADKAR model?

The ADKAR model is a change management framework that looks at change through the eyes of the individual rather than the organisation. It says that for any change to succeed, each person affected needs five things, in order: Awareness of the need for change, Desire to take part in it, Knowledge of how to change, Ability to put that knowledge into practice, and Reinforcement to make the change stick. The model was developed by Jeff Hiatt, founder of Prosci, in the late 1990s, drawing on Prosci's research into how change succeeds and fails across hundreds of organisations. It's used by anyone responsible for making change happen - project leads, managers, HR and OD teams - both to plan the people side of a change and, its sharpest use, to diagnose exactly where a change that's underway is getting stuck.

This page gives you everything you need to put it to work: a free ADKAR assessment template with diagnostic questions for every stage, a plain-English walkthrough of all five elements, a worked example scored 1-5 with the barrier point identified, and a comparison with Kotter, Lewin and Bridges so you can check you're holding the right model before you start.

The technical side and the people side of change

Every change has two sides. The technical side is the work of building the thing itself - the new system designed and tested, the new structure signed off, the new process documented. The people side is everything that determines whether anyone actually works differently once it lands. The two run on different rules: the technical side responds to planning, budget and project discipline; the people side responds to what each person understands, wants, knows and can do.

A new system can be implemented perfectly - on time, on budget, every workstream green - and still change nothing, because implementation isn't adoption. Until people choose to use it and engage with it, the organisation still works the old way; the technology has changed but the organisation hasn't. Delivery gets you to go-live; only adoption gets you to the benefits.

That's the premise ADKAR is built on, and it's easy to forget: organisations don't change - the people in them do. A "transformation" is really hundreds of individual decisions to work differently, made one person at a time. Most change efforts manage the technical side rigorously and leave the people side to hope. ADKAR exists to make the people side just as visible and manageable - Prosci's own shorthand for change management is exactly this: the people side of change.

The five stages of ADKAR: a detailed walkthrough

The five elements are sequential, and the order is the whole point. Each one builds on the one before it: desire without awareness is unstable, knowledge without desire goes unused, and ability without knowledge is luck. When a change stalls, the model's claim is that one specific element is missing for the people involved - and that's where the effort needs to go.

It helps to notice what kind of work each element needs. The first three - Awareness, Desire and Knowledge - are built in people's heads, through communication, involvement and training, mostly before the change lands. The last two - Ability and Reinforcement - are built in the flow of work, through practice, coaching and what the organisation chooses to notice and reward afterwards. Change efforts routinely over-invest in the first kind of work and under-invest in the second, which is why so many changes go live successfully and quietly unravel within six months.

For each element below we've included the test we use when we teach ADKAR: a first-person sentence you want each person to be able to say honestly. Score people against the sentence, not the label - the labels are easy to nod along to; the sentences are not. In two places the sentence deliberately departs from the model as written - we're Prosci-trained, so the departures are considered rather than casual - and we've said where and why.

Awareness

The test: "I understand the value of this change."

Awareness means a person understands the nature of the change, why it's needed, and what happens if nothing changes. That's more than having heard the announcement - plenty of people can repeat the project name without believing the problem is real.

The name is also where this element most often goes wrong in practice, and it's the model's soft spot: taken literally, "awareness" sets the bar at knowing the change exists. People can be fully aware of a change - fluent in the project name and the go-live date - while seeing no worth in it whatsoever. That's why our test is about value, not information: "I understand the value of this change", not "I know this is happening". It's a deliberate departure from the model as written, and a harder state to create - but a person who can see what the change is worth doesn't need convincing that it's happening.

When it's missing you hear it directly: "why are we changing something that works?", "this feels like change for change's sake". Rumour fills whatever gap the official story leaves, and people comply in meetings while dismissing the whole thing at their desks.

How to build it: be specific and honest about the reasons, and match the messenger to the message - business reasons land best from senior leaders, personal impact lands best from someone's own manager. Answer "why now?" and "what happens if we don't?" directly, and connect the change to problems people already recognise - the case for change lands differently when it explains something they've been living with. A clear problem statement does a lot of this work for you, and a considered narrative strategy helps the explanation connect with what people actually care about rather than what the project cares about. Awareness is built through repetition and dialogue, not a single all-staff email.

Desire

The test: "I want to engage actively in this change."

Desire is the personal decision to support the change and be part of it. It's the element you can't mandate: you can require attendance, but you can't require wanting to.

Notice what the test asks for. "Desire" on its own can be read as something passive - privately hoping the change goes well, or at least not minding it. The state that actually carries a change is active: wanting to take part, shape it, and be involved in how it lands. That's the second place we depart from the model's own framing - we test for active engagement, not quiet approval - and it changes what you work on, because the strongest builder of active engagement is genuine involvement, not persuasion.

When it's missing you get the politest form of failure: people understand the change perfectly and quietly wait it out. Nothing is openly resisted, deadlines slip for plausible reasons, and workarounds keep the old way alive under the surface.

How to build it: answer "what's in it for me?" honestly - including when part of the honest answer is loss, because people can tell. Involve people in shaping how the change works in their area; involvement converts spectators into owners faster than any communications plan. Treat resistance as information about what the change threatens rather than as an attitude problem. And expect the dip: the Change Curve and the Satir Change Model both map the emotional journey through change, and both are useful for anticipating where desire will falter even in people who started out supportive.

Knowledge

The test: "I know what to do and how to do it."

Knowledge is knowing how: the skills, processes, tools and behaviours the change requires - both during the transition and once the new way of working is normal. The test has a useful second edge: a person should also be able to say what "good" looks like in the new way of working, and where to go the first time they're stuck.

When it's missing you see willing people doing the wrong things, anxiety dressed up as scepticism, and a flood of basic questions arriving after go-live instead of before it. "Nobody actually showed us" is the signature complaint.

How to build it: train close to the work, not in the abstract - real scenarios, role-specific content, and support available at the moment of need rather than in one big session weeks before anyone can apply it. Peer learning carries more weight than course slides, so identify the people who learn fastest and give them time to help others. And remember that knowledge has a shelf life: a training day in March is not a plan for a September go-live.

Ability

The test: "I can do it in practice, not just in theory."

Ability is demonstrated performance - actually working the new way, in real conditions, at a decent standard. It's a separate element from Knowledge because knowing how and being able to are different things, and the gap between them is where a lot of change quietly dies. The questions people are silently asking here are practical ones: can I do this when it matters, what happens when I make mistakes, and how long until this feels normal?

When it's missing trained, willing people still can't perform: there's no time to work the slower new way, the old system is still running and easier, or the workload assumes everyone is already fluent. Help requests spike and then - more worryingly - stop.

How to build it: create room to practise. Phase the rollout so people build skill without drowning, provide coaching in the early weeks when confidence is most fragile, and hunt down the practical blockers - access, kit, conflicting targets - that no amount of motivation fixes. Above all, make it safe to be slow at first. If the performance regime punishes the learning dip, people will go back to the old way and hide it.

Reinforcement

The test: "I'm sticking with it - it's become my new normal."

Reinforcement is what makes the change stick. Old habits are efficient, and under pressure people revert to them - not out of defiance, but because the first genuinely busy week is a referendum on the new way of working.

When it's missing adoption peaks at go-live and decays from there. The new system is used for the visible parts and bypassed for the rest, and six months later the audit finds the old spreadsheets alive and well. The questions underneath the decay are quiet ones: is this change here to stay, does my effort matter, is anyone noticing what I'm doing?

How to build it: keep measuring adoption after the project team has moved on - reversion is invisible until you look. Recognise and celebrate the new behaviour, especially early and imperfect versions of it. Fix whatever still makes the old way easier, and embed the change in the organisation's permanent machinery: job descriptions, induction, performance conversations, the systems people touch every day. This is the least glamorous element and the most neglected one - which is why making change stick is a discipline in its own right.

The barrier point: where change gets stuck

The barrier point is ADKAR's sharpest practical idea, and the reason the model earns a place in a working toolkit rather than on a poster.

Because the elements are sequential, a change doesn't fail evenly across all five - it fails at the first element that's weak. That element is the barrier point, and everything downstream of it is blocked no matter how well it's resourced. Assess a person or group against each element in turn (a simple 1-5 score per element works well) and the barrier point is the first place the score drops.

What makes this so useful is that it tells you what kind of intervention will help - and, just as importantly, what kind won't. Effort spent downstream of the barrier point is largely wasted: more training won't fix a desire problem, and a better comms plan won't fix an ability problem. Each element has its own remedy - communication for Awareness, involvement and honest listening for Desire, training for Knowledge, practice and coaching for Ability, recognition and measurement for Reinforcement. The barrier point tells you which one you actually need right now, which is a far better basis for a change plan than doing a bit of everything.

The five first-person tests above make the scoring concrete: for each element, ask how honestly the people affected could say the sentence. "I understand the value of this change" scores very differently from "I've heard about it" - and the gap between those two answers is usually where the barrier is hiding.

The discipline is simple: find the earliest weak element, work there until it moves, then reassess. Our assessment template is built around exactly this - diagnostic questions for each stage so the barrier point shows itself.

When ADKAR works best (and when it doesn't)

ADKAR is at its best when the change is concrete and definable: a system rollout, a process change, a restructure that asks people to work differently, a new set of behaviours you can describe. If you can say what an individual will do differently on a Tuesday, ADKAR can tell you whether they're ready to do it.

It's a weaker fit in three situations. In a genuine crisis there's no time for staged readiness-building - you act first and rebuild commitment afterwards. In purely technical changes with little human impact, the model has nothing to grip. And where the hard part of the change is loss and identity rather than skills and process - a merger of proud institutions, the end of a role people loved - ADKAR's practical lens can feel thin, and the Bridges Transition Model covers that ground better (see the comparison below).

It's also worth being clear about what ADKAR is: a diagnostic, not a delivery plan. It tells you where people are and what kind of help they need. It won't sequence the workstreams, design the programme or manage the dependencies - you still need a plan to do that.

ADKAR vs Kotter vs Lewin vs Bridges

ADKAR sits in a family of well-known change models, and they're less interchangeable than they look - each one is really an answer to a different question. Kotter's 8-Step Change Model is an organisational campaign playbook: how leaders build urgency, coalition and momentum for a large-scale transformation. Lewin's Change Model gives you the simplest possible shape of any change - unfreeze, change, refreeze - which makes it a good planning frame and a poor diagnostic. The Bridges Transition Model maps the inner, psychological journey - endings, the neutral zone, new beginnings - and is at its best where the human loss in a change is the hard part.

They combine well. A common pattern is to run the campaign with Kotter and check progress with ADKAR - the campaign creates the conditions for change, and the individual assessment tells you whether each group is actually moving through it. The barrier-point diagnosis works just as well inside any of the other models.

ADKAR example: a new case-management system rollout

Here's how an ADKAR assessment plays out in practice. This is an illustrative example - a fictional organisation, invented for the purpose - but the pattern it shows is the one the assessment exists to catch.

A mid-sized organisation that manages long-running casework is three months from replacing its ageing case-management system. The project is on time and on budget, training is booked, and the project board is confident. As a check, the change lead runs an ADKAR assessment with the caseworker teams - each team lead scores their group from 1 (absent) to 5 (strong) against each element, then they compare notes.

Awareness scores 4. Nobody defends the old system - it's slow, it loses attachments, and everyone has a horror story. The reasons for the change are understood and mostly believed.

Desire scores 2. This is the surprise. Caseworkers understand the change but don't want it - and the reason only surfaces in the discussion. The new system makes case notes visible to team leads in real time, and caseworkers hear that as monitoring, not support. Nobody has said so in a project meeting; it comes out sideways, in the scoring.

Knowledge scores 3. Training is planned and the materials are decent, but it's scheduled as a single half-day, weeks before go-live, generic across roles.

Ability scores 2. Caseloads are already at capacity, and no allowance has been made for the slow early weeks. The old system stays available "for reference" during transition - which everyone quietly understands as permission to keep using it.

Reinforcement scores 1. Nothing is planned after go-live at all. The project closes at cutover; nobody owns what happens in month three.

Pulled into one view:

The barrier point is Desire - the first element where the score drops. And that changes the plan. The team's instinct had been to add more training, but training was never the problem: effort downstream of the barrier point is wasted until the barrier moves. Instead, the change lead takes the monitoring concern seriously and in the open - the head of service says plainly what the visibility is for and what it will never be used for, and caseworkers join the group configuring how notes and dashboards actually work. Only once Desire moves does attention shift downstream: training is rebuilt around real cases closer to go-live, caseload expectations are eased for the first month, and the old system gets a retirement date. Reinforcement - the empty element - gets an owner and a plan before cutover, not after.

Six weeks later the assessment is run again. That's the rhythm: assess, work the barrier point, reassess. The scores are nothing more than a structured conversation - but it's a conversation this project wasn't having anywhere else.

Getting started with ADKAR

You don't need a programme office to start using ADKAR - you need a specific change and an honest hour with the people who know the ground truth.

1. Define the change precisely. "The new rostering system", not "our transformation". ADKAR works change by change; vague scope produces vague scores.
2. Understand your starting point. Get a picture of how ready the organisation is for change in general - our guide to assessing change readiness covers what to look at, and a structured change readiness assessment does it formally.
3. Map who's affected. Different groups will sit at different stages. A power-interest matrix helps you see who matters most to the change and whose readiness to assess first.
4. Baseline the five elements. Run the assessment for each key group, find the barrier point, and build your plan around what it tells you.
5. Work the barrier, then reassess. Treat the scores as a living picture, not an audit. For larger changes, this cycle is the heart of a well-run change delivery programme.

ADKAR assessment template

Our free ADKAR assessment template turns the model into something you can run, not just read. It breaks down each of the five stages with diagnostic questions to assess where people currently sit, the common barriers at each stage, and practical actions to move people forward - so a team can score a real change against the model and find its barrier point in a single working session.

Download the free ADKAR assessment template (PDF) - fill in your details and it's yours straight away.

ADKAR model FAQs

Is the ADKAR model free to use?

The model is Prosci's intellectual property - ADKAR is a registered trademark of Prosci, and the definitive methodology, training and certification come from Prosci directly. Applying the concepts in your day-to-day work - assessing a team against the five elements, talking about barrier points - is normal practice, the same as with any published management model. We're Prosci-trained ourselves, so the practitioner perspective on this page comes from applying the model in real programmes - but we're not affiliated with Prosci, and if you want formal ADKAR training or licensed methodology, Prosci is the place to go. Our assessment template is our own free worksheet for putting the ideas to work.

ADKAR or Kotter - which should I use?

They answer different questions, so it's rarely either/or. Kotter tells leaders how to run the organisational campaign - urgency, coalition, momentum. ADKAR tells you whether each individual or group is actually moving. For a large transformation, use Kotter to shape the campaign and ADKAR to check it's landing; for a contained change, ADKAR alone is usually enough.

Does ADKAR work for organisational change, or just individuals?

Both - because ADKAR's claim is that organisational change is individual change, repeated. You assess at the level of individuals or groups, then aggregate: if one department sits at Desire while another is stuck at Knowledge, that's not a complication, that's the finding. What ADKAR won't give you is the organisational machinery - vision, structure, programme design - so for whole-organisation work, pair it with an organisational model rather than stretching it.

How do you run an ADKAR assessment with a team?

Pick one specific change and the group it affects. Have each person score that group against the five elements independently - 1 (absent) to 5 (strong) - using diagnostic questions for each stage, then compare scores. A useful sharpener is to score each element's first-person test: how honestly could this group say "I understand the value of this change", or "I want to engage actively in this change"? The disagreements are the most valuable part: they usually reveal that different groups, or different levels, are at different stages. Agree the barrier point, agree the action, and book the rescore before you leave the room. Our assessment template gives you the questions; if you want to build the skill properly, our change management training works through the whole approach with your team.

What should you do at the barrier point?

Stop pushing downstream and work the barrier itself. Each element has its own remedy: Awareness needs honest, repeated communication about why; Desire needs listening, involvement and a straight answer to "what's in it for me?"; Knowledge needs role-specific training near the moment of use; Ability needs practice, coaching and the removal of practical blockers; Reinforcement needs measurement, recognition and making the new way the easy way. Apply the remedy that matches the stalled element, give it time to work, then reassess - the barrier point moves, and the next one becomes visible.

Sources and further reading

• Prosci - The Prosci ADKAR Model
• Jeff Hiatt, ADKAR: A Model for Change in Business, Government and our Community (Prosci Learning Center Publications, 2006) - the original book-length treatment of the model, by its creator