ADKAR Change Management Model Explained [2026]

Your company just bought a new CRM. The implementation team spent three months configuring it. Training sessions were scheduled. Go-live day arrived. And six weeks later, half the sales team is still logging deals in the old spreadsheet. Sound familiar? This is what happens when you focus on the technical side of change and ignore the human side. The ADKAR model exists to fix exactly this problem.

What Is the ADKAR Model?

ADKAR is a change management framework developed by Jeff Hiatt, the founder of Prosci, in 1998. The acronym stands for five sequential outcomes that every individual must achieve for a change to succeed: Awareness, Desire, Knowledge, Ability, and Reinforcement. Unlike organizational change frameworks that focus on project plans and milestones, ADKAR focuses on the individual people who need to change how they work.

The core insight behind ADKAR is that organizational change only happens when individual people change. You can redesign a process, deploy new software, or restructure a department, but nothing actually changes until the people involved adopt new behaviors. ADKAR provides a structured way to make that happen.

The Five Elements of ADKAR

1. Awareness: Understanding Why the Change Is Needed

Awareness means the affected people understand why the change is happening and what the risk of not changing is. This is not about announcing the change; it is about building genuine understanding of the business reasons behind it.

What awareness looks like in practice: When a hospital implemented a new electronic health records system, the project team did not start with "we are switching to Epic next quarter." They started with "our current system caused three medication errors last month because the drug interaction check is outdated. The new system has real-time interaction checking that will prevent these errors." That is awareness tied to a consequence people care about.

Common failure at this stage: Leaders announce the change via email, assume people read it, and move on. Research from Prosci shows that the most effective senders of awareness messages are the direct supervisor (for personal impact) and senior leaders (for business reasons). An email from the CEO builds awareness about organizational direction; a conversation with the direct manager builds awareness about personal impact.

Questions that test awareness:

• Can the affected employees articulate why the change is happening?
• Do they understand what happens if the organization does not change?
• Can they explain how the change connects to business goals?

2. Desire: Building Personal Motivation to Change

Awareness tells people why the organization needs to change. Desire is about why they personally should want to participate. These are different things. An employee might fully understand that the company needs a new project management system, but if they have spent five years mastering the current tool and the new one makes them feel incompetent, they will resist.

Desire is the hardest element to create because it is personal and emotional. You cannot mandate desire. What you can do is address the specific concerns people have and create conditions that make change attractive.

Tactics that build desire:

• WIIFM (What Is In It For Me): Show individuals how the change benefits them personally. "The new system auto-populates 60% of the fields you currently fill in manually" is more compelling than "this improves organizational efficiency."
• Involvement: People support what they help create. Involving team members in piloting, testing, or providing feedback during design creates ownership.
• Addressing resistance directly: Ask people what concerns them about the change. Listen. Address what you can, and be honest about what you cannot change.
• Peer influence: Identify early adopters who are respected by the team and make them visible champions.

Example: When a marketing agency moved from tracking time in spreadsheets to using a dedicated tool, the biggest resistance came from senior consultants who saw time tracking as micromanagement. The project team addressed this by showing that automated time tracking actually reduced administrative work by 3 hours per week per person, and that the data would help them negotiate higher rates for complex projects. Desire shifted from resistance to support.

3. Knowledge: Teaching How to Change

Knowledge covers the information, training, and education needed to make the change. This includes understanding new processes, learning new tools, knowing new role expectations, and understanding new policies.

A critical mistake at this stage is conflating training with knowledge. Sitting in a two-hour webinar is training. Being able to actually perform the new tasks is knowledge. Effective knowledge-building includes hands-on practice, not just instruction.

For software changes, the most effective approach is guided practice in the actual tool. If you are rolling out ClickUp to replace a legacy project management system, do not just show slides about ClickUp features. Set up a sandbox project, have each team member create their own tasks, assign dependencies, and run through their actual workflows in the new system.

Knowledge-building principles:

• Train at the point of need, not weeks before go-live when people will forget
• Use the 70-20-10 model: 70% hands-on practice, 20% coaching from peers, 10% formal instruction
• Provide job aids (quick-reference guides, cheat sheets) for the first few weeks
• Differentiate training by role; not everyone needs to learn every feature

4. Ability: Putting Knowledge Into Practice

Ability is the demonstrated capability to perform the change in the real work environment. Knowledge is theoretical ("I know how to use the new system"). Ability is practical ("I can use the new system effectively in my daily work without reverting to old methods").

The gap between knowledge and ability is where many change initiatives fail. People attend training, pass the quiz, and then go back to their desks and cannot apply what they learned because the real environment is more complex than the training scenario.

How to bridge the knowledge-ability gap:

• Provide coaching and support during the first 30 days post-change. Assign super-users who can answer questions in real time.
• Expect a productivity dip and plan for it. People will be slower with new processes initially. Build buffer into workloads during the transition.
• Remove barriers: If the new system is slow, fix the performance issue before blaming adoption. If the new process requires approvals from a bottleneck, fix the bottleneck.
• Celebrate early wins. When someone completes their first task using the new process, acknowledge it. Small wins build confidence.

Example: After implementing a new expense reporting system, a company tracked that 70% of employees submitted their first report correctly within the first week. For the 30% who struggled, the finance team provided 15-minute one-on-one coaching sessions focused on the specific steps that were confusing. Within three weeks, correct submission rates reached 95%.

5. Reinforcement: Making the Change Stick

Reinforcement prevents people from reverting to old behaviors. Without it, the gravitational pull of old habits will erode the change over weeks and months.

Reinforcement mechanisms:

• Recognition: Public acknowledgment of people and teams who have adopted the change effectively
• Metrics: Tracking and sharing adoption metrics so people see the change taking hold
• Accountability: Making clear that the old way is no longer acceptable. If the old system is still available, people will use it.
• Feedback loops: Collecting feedback on what is working and what is not, and making visible adjustments based on that feedback
• Sustained communication: Continuing to share success stories and results three, six, and twelve months after go-live

Practical tip: Remove the old system or process as soon as feasible. If the old spreadsheet is still accessible, people will use it when the new system frustrates them. Removing the fallback forces adoption. This sounds harsh, but maintaining parallel systems is the number one killer of change initiatives.

Using ADKAR to Diagnose Stalled Changes

The most powerful use of ADKAR is diagnostic. When a change is not working, you can survey or interview the affected people to identify which element is the barrier point.

For each person, ask them to rate their level on a 1-5 scale for each ADKAR element. The lowest-scoring element is the barrier point. If someone scores high on Awareness but low on Desire, more communication about why the change is needed will not help. You need to address their personal motivation.

Common barrier patterns and solutions:

• Low Awareness: People were not told why the change is happening. Solution: structured communication from leaders and managers.
• Low Desire: People understand the change but do not want to participate. Solution: address personal concerns, involve them in decisions, show WIIFM.
• Low Knowledge: People want to change but do not know how. Solution: better training, job aids, peer coaching.
• Low Ability: People know what to do but cannot do it effectively. Solution: more practice time, remove barriers, provide hands-on support.
• Low Reinforcement: People adopted the change but are reverting. Solution: recognition, accountability, remove old systems.

ADKAR vs. Other Change Management Models

Kotter 8-Step Model is an organizational-level framework that focuses on the sequence of leadership actions (create urgency, form a coalition, create vision, etc.). ADKAR focuses on the individual experience of change. They are complementary: Kotter tells you what the project team should do; ADKAR tells you what individual employees need.

Lewin Change Model (Unfreeze-Change-Refreeze) is the simplest change model. It captures the basic idea that people must be ready for change (unfreeze), go through the change, and then solidify new behaviors (refreeze). ADKAR provides much more granular guidance within each stage.

McKinsey 7S Model focuses on organizational alignment across seven elements (strategy, structure, systems, shared values, skills, staff, style). It is useful for understanding organizational readiness but does not address individual change adoption.

In practice, experienced change managers use ADKAR alongside an organizational model. ADKAR handles the people side; the organizational model handles the structural side.

Applying ADKAR: A Step-by-Step Example

Scenario: Your company is moving from manual project tracking in spreadsheets to a dedicated project management platform.

Step 1: Build Awareness (Weeks 1-2)

Send a company-wide communication from the COO explaining that the current spreadsheet approach is causing project delays, missed deadlines, and duplicated work, costing an estimated 15 hours per manager per week. Have each department head hold a team meeting to discuss how this affects their specific team.

Step 2: Create Desire (Weeks 2-4)

Run a pilot with a volunteer team of five people. Let them test the new tool and report back. When they share that they saved three hours per week on status updates alone, their peers pay attention. Address concerns: "Will management use this to micromanage us?" Answer honestly: "Here is exactly what management will and will not see in the system."

Step 3: Build Knowledge (Weeks 4-6)

Run role-specific training sessions. Project managers need deep training on Monday.com or ClickUp project templates, timelines, and dashboards. Team members need focused training on updating task status, logging time, and using the notification system. Create a quick-reference card with the five most common tasks.

Step 4: Develop Ability (Weeks 6-10)

Migrate one real project per team into the new tool. Assign a super-user in each department who has been through extra training and can answer questions. Hold daily drop-in office hours for the first two weeks. Track common issues and publish solutions in a shared FAQ.

Step 5: Reinforce (Weeks 10+)

Share weekly adoption metrics: "85% of tasks are now created in the new system." Recognize teams with the highest adoption. Set a deadline for decommissioning the old spreadsheets. After three months, run a retrospective: what is working, what needs adjustment, what additional training is needed.

Tips for ADKAR Success

• Sequence matters. You cannot build Knowledge before Desire. If people do not want to change, sending them to training is a waste of time and their patience.
• Different people will be at different stages simultaneously. Some early adopters may be at Ability while skeptics are still at Awareness. Plan interventions for each group.
• Middle managers are the critical link. They translate organizational messaging into personal impact for their teams. Invest heavily in equipping managers to have these conversations.
• ADKAR is iterative, not linear. External events or setbacks can move someone backward. A system outage during the first week of a software rollout can destroy Desire overnight.
• Measure each element separately. A blended "change readiness" score hides the specific barrier that needs attention.

ADKAR in Practice: Three Industry Examples

Manufacturing: Implementing a New Quality Management System

A food manufacturer needed to transition from paper-based quality checklists to a digital quality management system to meet new FDA compliance requirements.

• Awareness: The quality director presented actual audit findings that showed paper records led to three compliance gaps in the last inspection, along with the financial penalty risk ($50,000-$500,000 per violation)
• Desire: Line supervisors were shown that the digital system would eliminate the 45 minutes per shift they spent transcribing paper records. Floor workers were told the system would reduce repetitive data entry and auto-flag quality deviations in real time, meaning fewer false alarms.
• Knowledge: Training was done on the production floor using tablets configured exactly like the production environment. Workers practiced logging quality checks during a simulated shift.
• Ability: During the first two weeks of live use, a quality coach was stationed on each production line to answer questions. Common errors were compiled into a one-page "quick fixes" sheet posted at each workstation.
• Reinforcement: Weekly quality scorecards showed each shift their compliance rate. The first shift to hit 100% digital compliance for a full week got a team lunch. Paper forms were physically removed from the floor after week three.

Financial Services: Migrating to a Cloud-Based CRM

A wealth management firm migrated from an on-premise CRM to Monday.com for client relationship management across 200 financial advisors.

• Awareness: The CEO presented data showing the firm was losing 3 deals per month because advisors could not access client data remotely. Client expectations had shifted; they expected their advisor to pull up their portfolio instantly, not say "let me check when I get back to the office."
• Desire: Top-performing advisors were invited to pilot the system first. When they reported closing 2 additional deals in the first month because of mobile access to client data, the rest of the team wanted in.
• Knowledge: Role-specific training sessions were held: advisors learned client management and pipeline views, assistants learned data entry and scheduling, and managers learned reporting and dashboards.
• Ability: Each advisor received a 30-minute one-on-one session to migrate their top 20 clients into the new system with their assistant present. This ensured their most important data was immediately accessible.
• Reinforcement: Access to the old CRM was made read-only after 60 days and decommissioned after 90 days. Monthly "power user" tips were shared via email showcasing features that saved time.

Technology: Adopting Agile Development Practices

A software company with 80 developers transitioned from waterfall to agile using Scrum.

• Awareness: Engineering leadership shared release data showing that 70% of projects were delivered late, with an average overrun of 6 weeks. Customer escalations due to delayed features had increased 40% year-over-year.
• Desire: Developers were promised that agile would give them more input into what they worked on (sprint planning involvement) and reduce the death marches that happened before every waterfall deadline. Managers were shown that incremental delivery would reduce risk.

Knowledge: An external agile coach ran a two-day workshop followed by embedded coaching for eight weeks. Teams set up their boards in Jira with guided templates and practiced estimation techniques on real backlog items.

• Ability: The first two sprints were explicitly treated as "learning sprints" with reduced scope expectations. Retrospectives focused on process learning rather than output. Super-users in each team provided peer support.
• Reinforcement: After three months, the CTO presented data showing that cycle time had dropped 35% and the team was shipping features every two weeks instead of every quarter. Teams that embraced agile practices most fully were recognized at the all-hands meeting.

ADKAR Assessment Template

Use this simple assessment with anyone affected by a change. Ask them to rate each statement on a scale of 1 (strongly disagree) to 5 (strongly agree):

• Awareness: "I understand why this change is happening and what happens if we do not change."
• Desire: "I personally want to participate in this change and believe it will benefit me."
• Knowledge: "I know what I need to do differently and have the information to do it."
• Ability: "I can perform my new tasks effectively and confidently in my daily work."
• Reinforcement: "The organization supports this change with recognition, accountability, and resources."

Any element scoring below 3 is a barrier point that needs targeted intervention. The lowest-scoring element should be addressed first, since later elements depend on earlier ones. Surveying 20-30 affected people gives you a clear picture of where the change is stuck and what type of intervention will make the most difference.

Common ADKAR Mistakes

• Jumping to Knowledge before building Desire: Scheduling training before people understand and want the change produces resentful attendees who retain nothing. Get buy-in first.
• Confusing Awareness with announcement: Sending one email is not building awareness. Awareness requires repeated, multi-channel communication from multiple credible senders.
• Treating the model as linear and one-time: Real change is messy. People move backward when they encounter difficulties. External events can reset Desire overnight. Build ongoing interventions, not one-time events.
• Ignoring middle managers: Frontline managers are the primary influence on their team Desire and Reinforcement. If managers are not equipped and motivated to champion the change, it will stall at the team level.
• Removing Reinforcement too early: Many organizations celebrate go-live and then stop all change management activities. Reinforcement needs to continue for 3-12 months after initial adoption to prevent regression.
• Not measuring: If you are not assessing ADKAR levels, you are guessing at what the barrier is. The assessment takes 5 minutes per person and prevents months of wasted effort targeting the wrong element.