The ADKAR Model is a goal-oriented change management framework that defines the five sequential conditions an individual must meet to successfully adopt and sustain a change. Unlike organizational change models that focus on broad process steps, ADKAR concentrates on the personal, psychological journey of a single employee moving through Awareness, Desire, Knowledge, Ability, and Reinforcement. In project, program, and portfolio management, ADKAR is used to diagnose gaps in user adoption, structure communications and training, and reduce the resistance that often derails technical implementations.
Jeff Hiatt, the founder of Prosci, introduced the model in the late 1990s after observing patterns in how employees internalized new business processes and technologies. The name itself is an acronym formed from the five milestones. The model’s elegance lies in its simplicity, yet its power comes from forcing change sponsors and project managers to view a rollout not from the perspective of a completed deliverable, but from the ground level of a single person altering their daily behavior. In practice, this means that a project is not truly realized until each impacted individual has progressed through the entire ADKAR sequence.
ADKAR Model: Key Topics Summary
| Key Concept | Summary |
|---|---|
| ADKAR Model | A goal-oriented change management framework that defines five sequential milestones individuals must achieve to successfully adopt and sustain organizational change. |
| Individual Focus | Distinguishes itself from process-centric models by concentrating on the personal, psychological journey a single employee navigates through each milestone. |
| Origin | Developed by Prosci founder Jeff Hiatt in the late 1990s after observing consistent patterns in how employees internalized new business processes and technologies. |
| Awareness | An individual’s comprehension of the underlying business drivers for change and the consequences of inaction, requiring substantive rationale rather than surface-level communication. |
| Desire | The personal, often emotional choice to engage with and champion the change; a pivotal checkpoint that is highly susceptible to organizational culture and influential peers. |
| Knowledge | The essential training and know-how to execute the change, delivered only after Awareness and Desire are firmly in place and carefully timed to align with individual readiness. |
| Ability | The demonstrated competence to perform new behaviors at the required performance level, cultivated through hands-on practice, feedback, and coaching where mistakes are treated as learning inputs. |
| Reinforcement | The fifth milestone that cements the change, embedding new behaviors into daily routines so they become the default and regression to old habits is prevented. |
| Diagnostic Tool | Serves as a diagnostic lens to pinpoint where an individual’s progress has stalled along the sequence, enabling precise, evidence-based interventions. |
| Project Integration | Operates in tandem with technical project lifecycles, elevating adoption metrics to the same level of governance and scrutiny as schedule and budget performance. |
What Is the ADKAR Model?
The ADKAR definition centers on five sequential building blocks that individuals must achieve to adopt and use a change successfully. It is not a project management methodology itself but a people-side companion that runs in parallel with technical lifecycles. ADKAR provides a lens for measuring where a person is stuck. Someone who refuses to use a new system almost certainly has a gap at the Awareness or Desire stage, regardless of how many training sessions have been delivered. The model functions as both a diagnostic tool and a roadmap for targeted interventions.
In many organizations, project teams mistakenly assume that delivering a new application, reengineering a workflow, or standing up a new service is enough. ADKAR challenges that assumption. It breaks change into a series of human-led transitions. The organization might be ready, but the individual is not. A project manager who internalizes ADKAR begins to treat adoption metrics like cumulative Awareness scores, Desire indicators from surveys, and demonstrated Ability audits as seriously as schedule variance and budget performance. This mindset shift is what separates a successful deployment from a well-built shelfware solution.
Because ADKAR focuses on the individual, it scales across project types and sizes. Whether a program involves a global ERP transformation or a small team adopting a new daily standup format, the same five elements apply. The model does not dictate specific tools; it sets the conditions that must be true for someone to make the transition. This flexibility is why ADKAR appears so frequently in project management offices that have formalized organizational change management functions.
Key Takeaways on ADKAR
- Five sequential building blocks
- ADKAR outlines a progression of five stages that every individual must navigate in sequence to internalize a change and make it durable.
- Diagnostic tool and roadmap
- By pinpointing the exact stage where a person is blocked, such as low Awareness or weak Desire, the model guides precise, stage-specific interventions that unlock forward movement.
- Challenges technical delivery assumptions
- ADKAR reframes change as a human-driven journey, exposing the flaw in assuming that deploying a new tool or workflow is enough to secure adoption.
- Adoption metrics equal project metrics
- Teams practising ADKAR track awareness scores, desire survey indicators, and ability audits with the same rigor as schedule variance and budget performance, treating adoption data as a core project KPI.
Key Components of ADKAR
The five key components of ADKAR are Awareness, Desire, Knowledge, Ability, and Reinforcement, each representing a distinct psychological or behavioral milestone. No component can be skipped. If a person moves from Awareness to Knowledge without Desire, they might understand the change perfectly but have zero motivation to enact it. The linear nature is deliberate; each milestone is a prerequisite for the next, forming a dependency chain that mirrors how human beings actually process major shifts in habit.
Awareness
Awareness refers to an individual’s understanding of why a change is needed and what will happen if nothing changes. It answers the question, "Why?" This is not simply knowing that a new tool is coming; it is internalizing the business reasons, the risks of the status quo, and the external or internal drivers. Project managers often rely on town halls and mass emails to create awareness, but real awareness forms when a person can articulate, in their own words, the compelling case for the change.
A technician who has maintained a legacy database for a decade may receive a memo about a cloud migration. That is superficial awareness. Deeper awareness takes shape when that technician grasps that manual patching cycles are becoming a security liability and that their own role will pivot toward more valuable data analytics work. Without this grounded view of "what’s in it for me," the change message stays at the surface. The ADKAR model therefore pushes sponsors to segment audiences and craft personalized, role-specific awareness communications early in the project lifecycle, well before any formal training.
Desire
Desire is the individual’s personal decision to support and participate in the change. It is an emotional and motivational milestone, not a logical one. Someone may be fully aware of the data pointing to the need for a new procurement system yet actively resist because they perceive a loss of autonomy or fear that their expertise will become obsolete. Desire is where organizational culture, management credibility, and personal circumstances collide most forcefully.
Project managers frequently underestimate the fragility of desire. A single conversation with a trusted supervisor who downplays the change can extinguish desire even after a brilliant awareness campaign. Conversely, an employee who initially resisted may develop desire after seeing a peer successfully adopt the new way of working and receiving recognition for it. The ADKAR model treats desire as a genuine gate. Activities that nurture it include involving employees in solution design, creating safe spaces to voice concerns, and openly addressing the "what’s in it for me" dimension with tangible examples.
Knowledge
Knowledge is the information, training, and education required to know how to change. This includes understanding new processes, tools, roles, and behaviors. Many project teams conflate knowledge with ability; sending someone to a training course does not mean they can perform the new task under pressure. ADKAR separates the two because knowing how to fly a plane in a simulator is not the same as landing in a crosswind.
Knowledge must be relevant, timely, and suited to the learner’s background. A one-size-fits-all training program that covers every feature of a new project management information system often overwhelms users, causing them to absorb little. The ADKAR perspective encourages project managers to map knowledge requirements to the specific tasks each role will perform post-change. Microlearning, job aids, and shadowing opportunities are typical vehicles. Crucially, knowledge is delivered only after awareness and desire are established; otherwise, training is wasted on disengaged audiences.
Ability
Ability is the demonstrated capability to implement the change at the required level of performance. It is the hands-on, real-world application of knowledge. This is where mistakes happen, coaching is critical, and confidence builds slowly. In project environments, ability is often measured through observed job performance, proficiency checks, and error rates in the new process. ADKAR acknowledges that there is a predictable performance dip when a new way of working replaces an old, comfortable one, and it plans for that dip rather than punishing it.
A common project management error is to declare the change "done" the moment training is completed. ADKAR demands that project teams verify ability under real operating conditions. A support analyst who has taken a three-hour workshop on a new ticketing system demonstrates ability only when they can handle a live high-priority incident without bypassing the tool. Providing practice environments, side-by-side coaching during the first weeks of go-live, and immediate feedback loops is how ability gets cemented.
Reinforcement
Reinforcement refers to the actions taken to sustain the change and prevent individuals from reverting to old behaviors. It is the final ADKAR element and the one most frequently neglected. Reinforcement includes recognizing and rewarding adoption, conducting ongoing measurement, and correcting gaps before they become entrenched. Without it, even strong awareness, desire, knowledge, and ability will decay over time as competing priorities and habits reassert themselves.
In a project context, reinforcement is not a single post-go-live survey. It is a continuum of audits, success stories, leadership visibility, and corrective actions. If a logistics team starts using a new route optimization tool but then quietly returns to manual spreadsheets because the tool seems slow, the ADKAR gap is in reinforcement. Mechanisms such as regular adoption dashboards reviewed at program steering committees, celebrating early wins publicly, and removing structural barriers that penalize new behaviors are all reinforcement tactics. The timing of reinforcement matters: it must be frequent in the early adoption period and then tapered to a sustainable rhythm.
ADKAR in the Context of Project Management Frameworks
The ADKAR in project management frameworks serves as a bridge between the structured world of deliverables and the human dynamics that determine whether those deliverables ever produce business value. While ADKAR does not originate from the PMBOK® Guide or PRINCE2, its principles align naturally with the people-related processes found across all major methodologies. Project managers and change management practitioners collaborate so that every technical work package has a corresponding ADKAR-based people plan.
ADKAR and the PMBOK Guide
Within the PMBOK® Guide, the ADKAR model does not appear as a named process, but its influence is felt throughout the Integration, Communications, and Resource Management Knowledge Areas. When a project manager develops a stakeholder engagement plan, the ADKAR milestones provide a framework for assessing where each stakeholder group stands. Awareness maps to early communications of the business case, Desire connects to stakeholder buy-in efforts, Knowledge to training plans, Ability to performance testing and support, and Reinforcement to ongoing benefit sustainment activities. This alignment allows project managers to embed change readiness metrics into existing project artifacts such as the communications management plan and the lessons learned register.
In earned value management terms, a project whose technical deliverables are on schedule but whose end users have not achieved Ability is not truly performing. The concept of realizing benefits only through use means that ADKAR becomes a hidden dependency in many project schedules. Forward-thinking project managers treat ADKAR assessments as leading indicators that feed into integrated change control. If a survey reveals a collapse in Desire after a reorganization announcement, the project plan may need a formal change request to add reinforcement activities that were not originally baselined.
ADKAR in PRINCE2
PRINCE2’s focus on management stages and the Change Theme provides a natural home for ADKAR. The Change Authority’s scope can be expanded to include organizational change impact assessments that use ADKAR as a diagnostic grid. At the end of each stage, a project manager applying ADKAR would evaluate not only whether products meet quality criteria but also whether the relevant user communities have progressed to the appropriate ADKAR milestone. For example, before moving from design to deployment, the project board might require evidence that Awareness and Desire targets have been met for all core user groups.
PRINCE2’s principle of managing by exception gains extra dimension when ADKAR data is included. A stage boundary report that says "all products delivered on time" but also notes "Desire scores are 30% below threshold across sales teams" triggers a different kind of exception. The board can then direct project managers to pause technical development or repurpose resources toward change management activities, preventing a technically flawless but ultimately unused deliverable.
ADKAR in Agile and Hybrid Environments
Agile methodologies emphasize individuals and interactions, making ADKAR a surprisingly good fit for sprint-based development. In a Scrum context, each user story or feature increment represents a micro-change for the people who will use it. Instead of applying ADKAR as a monolithic front-loaded campaign, agile teams can run mini-ADKAR cycles within each sprint. The product owner’s backlog refinement sessions create Awareness, sprint reviews and demos build Desire and Knowledge, the sprint itself provides a sandbox for early Ability, and the retrospective plus subsequent usage data drive Reinforcement.
Hybrid projects, where predictive planning meets iterative delivery, can use ADKAR to orchestrate the human side of each release train. A major ERP module delivered in a waterfall fashion benefits from a structured ADKAR campaign timed to phases. Meanwhile, smaller enhancement features rolled out continuously receive lightweight ADKAR pulses. The core model stays the same; its application tempo adapts. In all cases, ADKAR ensures that user stories are not truly "done" until the intended users have adopted the change in their daily work.
Core Insights on ADKAR Integration
- PMBOK alignment with ADKAR
- ADKAR aligns directly with PMBOK's stakeholder engagement, communications, and resource management processes, enabling project managers to embed change readiness indicators into core artifacts such as the communications management plan and the lessons learned register.
- PRINCE2 Change Theme synergy
- In PRINCE2, ADKAR reinforces the Change Theme and stage boundary reviews by demanding evidence that user groups have reached the Awareness and Desire milestones, and it triggers exception reports whenever desire scores fall below the acceptance threshold, despite on-time product delivery.
- Agile and hybrid mini-cycles
- Agile teams embed compact ADKAR cycles into each sprint by using backlog refinement for Awareness, sprint demos to build Desire and Knowledge, and retrospectives to solidify Reinforcement, while hybrid projects transition the application tempo from structured campaigns for major releases to lightweight, sustained pulses that support continuous enhancements.
BVOP Perspective on ADKAR
In the BVOP perspective, ADKAR provides a structured mechanism to assess individual readiness, helping project teams identify process damage caused by resistance to change. Business Value-Oriented Project Management treats disruption from poorly adopted changes as a form of invisible organizational harm, alongside overwork, perfectionism, and rejected acceptable work. When an employee reverts to the old method not out of malice but because they never developed Ability, that creates extra processing steps, rework, and hidden costs—all of which BVOP categorizes as waste. ADKAR becomes a lens for spotting these value leaks early.
BVOPM’s emphasis on business value points and program realization sets connects directly to the Reinforcement phase of ADKAR. A persistent decline in business value scores for a product launch may signal that individual reinforcement mechanisms have broken down, allowing old habits to resurface. Using ADKAR assessments, a program manager can pinpoint whether the decline traces back to insufficient Desire among frontline employees or a lack of ongoing coaching that eroded Ability. The model’s individual focus aligns with BVOP’s principle that non-financial benefits, such as employee engagement and future risk reduction, are legitimate program outcomes worthy of tracking alongside revenue and cost metrics.
Practical Application and Use of ADKAR
Successfully applying ADKAR in projects requires integrating its assessments into the project schedule and tailoring actions to the unique gaps of each impacted group. In the early planning stages, a project manager conducting a stakeholder analysis might add an ADKAR baseline assessment, rating each stakeholder segment on a simple scale for each of the five elements. This baseline then informs the communications plan, training strategy, and risk register. For example, if the procurement team shows high Awareness but very low Desire, the project risk register would log a specific risk with mitigation actions focused on leadership engagement and personal impact dialogues rather than more informational webinars.
During execution, ADKAR milestones replace the hollow "training completed" metric. Project dashboards begin to display Red-Amber-Green indicators for ADKAR elements alongside traditional schedule and cost metrics. A red score on Ability for a finance department two weeks before go-live triggers an immediate coaching surge and a potential reassessment of the cutover date. The project manager does not need to become a change management specialist; they need to collaborate with change management resources who can design interventions, while the project manager ensures those interventions have budget, time, and executive air cover.
Real-world project practitioners often set ADKAR-based stage gates. Before entering user acceptance testing, a gate review would require evidence that all core user groups have achieved at least Awareness and Desire, and that Knowledge transfer activities have begun. Before project closure, a gate check demands that Ability has been demonstrated in production and Reinforcement mechanisms are in place and operational. This approach converts abstract change management concepts into tangible, auditable checkpoint criteria that a project board can understand and enforce without deep psychology expertise.
Key Insights on ADKAR Application
- Baseline assessment informs planning
- Early ADKAR baseline ratings for each stakeholder segment directly shape the communications plan, training strategy, and risk register, enabling precise, targeted mitigation actions.
- ADKAR milestones replace training metrics
- Project dashboards combine Red-Amber-Green status indicators for ADKAR elements with traditional schedule and cost metrics; a low Ability score immediately triggers one-on-one coaching and a potential review of the cutover timeline.
- PM collaborates with change experts
- Project managers secure budget, schedule, and executive sponsorship for interventions, while change management specialists design and execute the specific change activities.
- Stage gates demand ADKAR evidence
- Stage gate reviews before user acceptance testing and project closure require documented evidence of Awareness, Desire, Knowledge, Ability, and operational Reinforcement, establishing tangible, auditable checkpoints.
Challenges, Pitfalls, and Misconceptions
The most persistent ADKAR pitfalls arise when sponsors confuse the individual acceptance of a change with the mechanical completion of tasks. ADKAR is not a process checklist where an organization can "do Awareness" by sending one email and then move on. Each element must be true from the individual’s perspective, not merely supplied by the project team. Another common error is treating ADKAR as a purely linear model for groups. While an individual must move through the sequence, a population of people will be scattered across different stages at any given moment. A project manager who designs a single campaign that iterates perfectly from A to R for the whole organization will fail to reach people who, for example, are still in the Awareness phase while the campaign has moved to Knowledge.
Misunderstanding the Desire milestone is particularly damaging. Project managers often believe that a strong business case automatically creates personal desire. It does not. An employee can understand intellectually that a new claims processing system will save the company millions and yet remain deeply unmotivated because it makes their own job harder or less socially connected. Treating Desire as a logical step that follows naturally from Awareness leads to underinvestment in the emotional and motivational side of change. The model demands that project teams explicitly plan for how they will increase personal buy-in, not just broadcast the organizational rationale.
Another misconception is that ADKAR is a substitute for a full project management methodology. Some organizations attempt to govern an entire transformation using only ADKAR milestones, neglecting scope, schedule, risk, and quality management. ADKAR is a people-change model, not a project lifecycle. It must coexist with, not replace, the technical disciplines of project management. When used in isolation, projects drift into endless "change journeys" with no clear deliverables, burning budget and stakeholder patience. Effective application places ADKAR firmly within a structured project framework where each element maps to a work breakdown structure activity and has a defined owner.
Relationship to Other Organizational Change Concepts
While ADKAR vs Kotter comparisons often dominate change management discussions, the two models serve different levels of scope—individual versus organizational. John Kotter’s eight-step model provides a process for leading large-scale organizational transformation, with emphasis on building a guiding coalition, creating a vision, and generating short-term wins. ADKAR zooms in on the single employee who must live that transformation daily. A program manager might orchestrate a Kotter-style change campaign across an enterprise while using ADKAR to troubleshoot why a specific department is not adopting the new purchasing policy. The models are complementary, not competing.
ADKAR is also the core engine behind Prosci’s broader 3-Phase Process, which structures organizational change management into Prepare Approach, Manage Change, and Sustain Outcomes. The five ADKAR elements are the measurement nodes within that framework. Project practitioners often discover that ADKAR assessments serve as the inputs to many commonly used PM artifacts. The stakeholder engagement assessment matrix, for example, can be enriched by ADKAR data to show not just current versus desired engagement levels, but specifically which ADKAR milestone is blocking forward movement for each stakeholder.
Compared to Lewin’s Unfreeze-Change-Refreeze model, ADKAR offers a more incremental, actionable granularity. Lewin’s stages are broad metaphors; ADKAR’s elements can be quantified in surveys and turned into specific action plans. Many organizations blend the two, using Lewin’s three-stage metaphor for executive communications while deploying ADKAR spreadsheets at the team level for targeted interventions. The relationship is practical: ADKAR provides the measurement rigor that lets broader change models be managed with the same discipline as a project.
ADKAR's Place Among Change Frameworks
- Complementary to Kotter's model
- Kotter's eight-step model orchestrates organization-wide transformation, while ADKAR targets individual adoption, allowing the two frameworks to reinforce each other across distinct but interdependent levels of change.
- Core engine of Prosci's 3-Phase Process
- ADKAR's five elements function as measurable progress gates within the Prepare Approach, Manage Change, and Sustain Outcomes phases, and the resulting assessments feed directly into tools like stakeholder engagement matrices and impact analyses.
- Measurement rigor beyond Lewin's model
- Lewin's Unfreeze-Change-Refreeze provides a conceptual narrative, while ADKAR delivers quantifiable, actionable granularity; organizations often combine the two by using Lewin for executive vision and ADKAR assessments for targeted team interventions.
Evolution and Current Thinking
The evolution of the ADKAR model has seen greater integration with agile delivery and a shift toward continuous reinforcement loops. When ADKAR first emerged, it fit neatly into waterfall projects where a big-bang go-live was followed by a stabilization period. Today, with continuous delivery and cloud-based updates arriving weekly, the model has been adapted so that Reinforcement is not a final step but a persistent ongoing state. In this contemporary view, an individual might cycle through Awareness-Desire-Knowledge-Ability for a series of incremental feature releases, while Reinforcement acts as the underlying current that sustains the overall behavioral shift.
Current thinking also acknowledges that the model is not purely sequential in complex environments. Someone may return to a previous stage after a setback. A long-time employee who achieved Ability can lose Desire when their trusted manager leaves, creating a regression that requires re-starting desire-building work. Practitioners now speak of "ADKAR loops" where individuals move forward, fall back, and need re-triggering. This cyclical understanding has reduced the frustration project managers used to feel when adoption metrics didn’t follow a clean upward slope.
Another evolution is the digital quantification of ADKAR milestones. Advanced organizations embed ADKAR surveys into their project management information systems, linking individual readiness data to risk registers and schedule performance indexes. Machine learning models are beginning to predict adoption slow-downs based on early Awareness and Desire patterns, allowing project managers to pre-emptively adjust coaching resources. While the core five elements remain unchanged since Hiatt’s original work, the sophistication with which they are measured, forecast, and integrated into program governance has matured dramatically, making ADKAR not just a soft-side concept but a hard-edged project performance indicator.
