Skip to content
All tools
Change ManagementIntermediate

ADKAR Change Model

Diagnose the earliest evidence-backed barrier to individual adoption and match support to awareness, desire, knowledge, ability or reinforcement.

Diagnose what a specific group still needs in order to adopt a defined change, then provide support at the earliest unmet outcome instead of sending everyone the same communication or training.

In one minute

ADKAR describes five outcomes of individual change:

  1. Awareness: people can explain why the change is needed and what happens if the current state continues.
  2. Desire: people are willing to participate after considering effects, choices, incentives and trust.
  3. Knowledge: people know what to do, how to do it and where to get help.
  4. Ability: people can perform the new behaviour under realistic conditions.
  5. Reinforcement: feedback, systems and consequences help the new behaviour persist.

The practical decision rule is to find the earliest outcome without sufficient evidence for each affected segment. A training course is a Knowledge intervention; it will not repair unclear purpose, a harmful incentive or lack of practice capacity.

ADKAR is an individual-change model, not a complete organisational transformation method. Strategy, sponsorship, operating design, rights, resources and portfolio coordination still need separate governance.

Best for: a defined process, technology, role or behaviour change whose adoption differs across affected groups.
Avoid when: leaders have not made the change decision, the future behaviour is undefined, opposition reveals an unresolved ethical or structural problem, or the model would be used to score employees.

The problem it addresses

Change programmes often count activity: messages sent, people trained, accounts activated and launch milestones completed. Those measures do not show why people have or have not changed their work.

ADKAR separates distinct adoption problems. Someone may understand the reason but reject the trade-off; know the procedure but be unable to perform it in a real shift; or demonstrate the behaviour briefly before old systems and incentives pull them back. The model turns a vague label such as “resistance” into a testable support question.

When to use it

Use ADKAR when:

  • the change and observable future behaviour are defined;
  • different roles experience different impacts or adoption barriers;
  • a launch has high participation but weak use or outcome evidence;
  • training is complete but real-world performance remains inconsistent;
  • an iterative or AI-enabled workflow changes faster than one rollout plan;
  • managers can remove workload, access, policy or tool constraints;
  • the team can reassess adoption without collecting unnecessary personal data.

When not to use it

Do not use ADKAR:

  • to manufacture consent for a harmful or already discredited change;
  • as a substitute for strategy, programme design, sponsorship or technical delivery;
  • to classify every concern as an individual attitude problem;
  • to infer Desire from compliance, silence, attendance or login counts;
  • to treat the five outcomes as a one-pass waterfall;
  • to publish individual profiles or connect them directly to performance ranking;
  • when required consultation, labour, safety, accessibility or privacy obligations are unresolved.

Use Stakeholder Mapping first when the affected groups, power and impact are unclear. Use PDCA/PDSA alongside ADKAR to test support interventions rather than assume they caused adoption.

Inputs required

Prepare:

  • a precise change statement and the behaviour that will be different;
  • affected role or context segments rather than one workforce average;
  • current-state and future-state workflow evidence;
  • known benefits, harms, workload, identity and incentive effects;
  • observable indicators for all five outcomes;
  • channels for confidential questions, disagreement and accessibility needs;
  • owners able to change communication, design, training, capacity and reinforcement;
  • a reassessment cadence and data-retention boundary.

Step-by-step process

1. Define the change and adoption evidence

State who must do what differently, in which context and by when. Separate business outcome, technical delivery and individual adoption. “Use the new CRM” is weak; “field technicians record safety-critical exceptions in the mobile workflow before closing a visit” is observable.

2. Segment by impact and context

Group people only where their role, location, language, access, risk or workflow materially changes the adoption experience. Do not average together office users with mobile workers or routine cases with safety exceptions.

3. Establish an ethical evidence boundary

Decide which evidence is necessary and who may see it. Prefer aggregated segment signals, interviews, observation, help requests and work outcomes. Do not create a hidden psychological profile or punish candid disagreement.

4. Assess all five outcomes

For each segment, record evidence for Awareness, Desire, Knowledge, Ability and Reinforcement. Use more than one signal where practical. Attendance supports only the claim that an event occurred.

5. Identify the earliest barrier

Find the first outcome in the sequence whose evidence is insufficient. Treat it as a diagnostic hypothesis, not a label attached to a person. Later outcomes may also need work, but an earlier barrier changes which intervention is useful now.

6. Match the response to the barrier

Use distinct responses:

  • Awareness: explain the evidence, decision context, consequences and uncertainties; make questions answerable.
  • Desire: surface impacts and objections, adjust unfair trade-offs, clarify real choices and build credible sponsorship.
  • Knowledge: provide role-specific instruction, examples, decision rules and accessible help.
  • Ability: create practice, coaching, time, permissions, tools, realistic exceptions and safe feedback.
  • Reinforcement: align measures, manager behaviour, recognition, system defaults and corrective learning.

7. Remove system constraints

If people know and want to change but cannot, inspect workload, permissions, interface design, staffing, conflicting metrics and legacy procedures before asking for more motivation.

8. Test a bounded support action

Define a prediction and guardrails. For example: “After coached exception rehearsals, first-pass completion will rise from 58% to at least 75% without increasing safety overrides.” Preserve a non-digital or human escalation route where required.

9. Reassess and adapt

Outcomes can weaken when the workflow, leadership, incentives or technology changes. Reassess by segment, record what changed and move support to the new earliest barrier. Do not declare Reinforcement complete from one short observation window.

AI automation lens

AI can summarise authorised feedback, cluster questions, detect recurring help topics, translate approved learning material, simulate routine practice and flag workflow signals for review.

It must not:

  • infer private motives, emotion or loyalty from behaviour;
  • assign Desire scores for employment decisions;
  • suppress objections by labelling them resistance;
  • fabricate an adoption profile from sparse data;
  • coach users around safety, legal or approval controls;
  • change reinforcement, rewards or access without accountable authority.

Human owners remain responsible for the change decision, impact assessment, fair treatment, capability conditions and interpretation of adoption evidence.

Visual model

Text alternative: a defined change is examined through Awareness, Desire, Knowledge, Ability and Reinforcement. Evidence by affected segment identifies the earliest unmet outcome; matched support is tested and the profile is reassessed.

Interactive example

Scenario

A field-service company introduces an AI-assisted mobile workflow. Ninety-four per cent of technicians attended training. Only 36% can explain why the change is needed, experienced technicians believe the workflow removes legitimate judgement, and users who pass the classroom simulation still fail when connectivity drops.

Your move

Diagnose the earliest barrier for three segments and choose one response for each.

Worked answer

  • For technicians who cannot explain the operational or safety need, the earliest barrier is Awareness. Publish evidence, uncertainties and the specific decision—not another feature tour.
  • For experienced technicians who understand the need but reject lost discretion, the earliest barrier is Desire. Review the authority design, preserve justified override and show how feedback changes the workflow.
  • For technicians who understand and support the change but fail offline exceptions, the earliest barrier is Ability. Provide realistic practice, offline tools, coaching and protected time.

One organisation-wide “adoption score” would conceal all three mechanisms.

Facilitation notes

  • Ask for observable evidence before assigning an outcome.
  • Let participants describe impacts in their own language.
  • Separate rational objection from missing motivation.
  • Diagnose by role and context, not personality.
  • Invite an independent employee, accessibility or safety voice for consequential changes.
  • Record system constraints that managers must remove.
  • Keep individual feedback confidential and report only the minimum useful aggregation.

Expected output

  • a defined change and observable adoption behaviour;
  • affected segments with explicit impact differences;
  • evidence for all five ADKAR outcomes;
  • an earliest-barrier hypothesis for each segment;
  • matched support actions, owners and dates;
  • system constraints and escalation decisions;
  • outcome and guardrail measures;
  • a reassessment record and reinforcement plan.

Common mistakes

  1. Training as the default. Knowledge support cannot repair low Awareness or an unacceptable trade-off.
  2. Desire as obedience. Legitimate disagreement, risk or workload is not a character defect.
  3. Knowledge equals Ability. Passing a course does not prove performance under real conditions.
  4. One average profile. Different segments can have different earliest barriers.
  5. Linear rollout. Outcomes interact, decay and need reassessment.
  6. Reinforcement as celebration. Durable adoption also depends on workflow, incentives, feedback and removal of obsolete paths.

Quality checklist

  • The future behaviour is observable and role-specific.
  • Segments reflect real differences in impact or context.
  • Each outcome has evidence beyond attendance or self-report alone.
  • The earliest barrier is a revisable hypothesis, not a personal label.
  • Desire work includes consent, fairness, workload and decision rights.
  • Ability is tested under realistic normal and exception conditions.
  • Reinforcement aligns systems and consequences, not only recognition.
  • Personal data and dissent are protected.

Template

SegmentFuture behaviourAwareness evidenceDesire evidenceKnowledge evidenceAbility evidenceReinforcement evidenceEarliest barrierSupport / owner / review
Role or contextObservable actionWhy is understoodWillingness and concernsWhat/how is knownReal performancePersistence conditionsA / D / K / A / RBounded response and evidence date

Use the structured ADKAR workspace to preserve evidence, privacy boundaries, support decisions and reassessment.

Knowledge check

Question: A team can explain and demonstrate a new workflow in training, but the old approval metric rewards the previous behaviour. What is the most likely immediate ADKAR focus?

A. More Awareness communication.
B. More Knowledge slides.
C. Reinforcement, including the conflicting metric and manager behaviour.
D. Reclassify the team as resistant.

Answer: C. The capability exists, but the operating environment continues to reward the old behaviour.

Related tools

  • Stakeholder Mapping identifies affected groups, power, impact and engagement obligations before diagnosis.
  • RACI Matrix clarifies who owns the change decision, support and system constraints.
  • PDCA/PDSA Cycle tests whether a support intervention changes observed adoption.
  • Service Blueprint exposes backstage conditions that may block Ability.
  • Mistake Proofing redesigns the environment when errors should be prevented rather than coached repeatedly.

References

  1. Prosci. “The Prosci ADKAR Model.” Official overview (opens in a new tab). Accessed 15 September 2026. Primary practitioner source; ADKAR is a registered trademark of Prosci, Inc.
  2. Hiatt, Jeffrey M. ADKAR: A Model for Change in Business, Government and Our Community. Prosci Learning Center Publications, 2006. Foundational practitioner source.
  3. Creasey, Tim. “The Prosci ADKAR Model: Why It Works.” Prosci article (opens in a new tab), updated 18 April 2025. Practitioner explanation of the sequence and barrier concept.
  4. Adelman-Mullally, T. et al. “The use of change theory to facilitate the consolidation of two diverse Bachelors of Science in Nursing programs.” Nursing Outlook, 65(2), 2017. DOI (opens in a new tab). Independent application case; it does not establish universal causal effectiveness.
  5. Mölders, S. et al. “Expanding the success factors of change management by incorporating crisis preparedness in the emerging AI world.” Review of Managerial Science, 2026. DOI (opens in a new tab). Independent review noting limited systematic validation across widely used change models.

Method profile

  • Primary output: segmented, evidence-backed adoption diagnosis and matched support plan.
  • Decision level: individual outcome within a governed team or organisational change.
  • Evidence strength: practical diagnostic heuristic; independent causal validation remains limited.
  • Review trigger: change in role, workflow, technology, leadership, incentives, adoption evidence or affected population.