Using the ADKAR Model During Organizational and Technology Change

Intro

Change is hard, and nowhere is that more visible than when a technology organization rolls out a new platform or restructures its teams. Leaders often focus on the technical rollout and wonder why adoption lags. The ADKAR Model offers a way to manage the people side of change with the same rigor applied to the project plan. Developed by Prosci founder Jeff Hiatt, ADKAR is a goal-oriented framework that describes the five milestones an individual must reach for a change to succeed: Awareness, Desire, Knowledge, Ability, and Reinforcement. Each element addresses a specific question: Why change? What's in it for me? How do I change? Can I actually do it? And what keeps me doing it?

This article is a practical guide for managers and change leaders in technology organizations. You will learn what ADKAR is, where it works well, how to apply it through a detailed example of a cloud migration, and how to govern the change with clear decision rights and metrics. By the end, you will be able to run an ADKAR-based change initiative with confidence and avoid the common traps that derail transformations.

Management Context

ADKAR is not a project management methodology or a strategic planning tool. It complements those by focusing on individual behavior change. It is most effective when the change requires people to adopt new systems, follow new processes, or shift their roles. ADKAR is particularly useful when resistance stems from a lack of awareness or desire rather than a lack of resources or technical feasibility. If people don't understand why a change is happening or don't want it, no amount of training will help. ADKAR helps diagnose exactly where individuals are stuck.

When to Use ADKAR

• Implementing a new software tool or platform across teams.
• Reorganizing teams or departments.
• Changing core processes or workflows.
• Rolling out new policies or compliance requirements.
• Driving cultural shifts such as agile transformation or DevOps adoption.

ADKAR is less suited for open-ended exploration where the target state is unknown. If you are still figuring out what the change should be, use a strategy or innovation framework first. Once the change is defined, ADKAR becomes your execution lens.

ADKAR vs. Other Change Models

ADKAR is often compared with Kotter's 8-Step Change Model. Kotter's model is a top-down, organizational change process that begins with creating urgency and building a guiding coalition. ADKAR, in contrast, is bottom-up, focusing on individual change. They are complementary: Kotter can set the stage at the organizational level, while ADKAR ensures each person transitions.

Other tools you might combine with ADKAR include:

• Stakeholder Mapping to identify who needs ADKAR support and who might resist.
• Agile Leadership to sustain momentum through iterative cycles.
• RACI matrices to clarify decision rights and responsibilities.

Key Distinctions

• ADKAR is a diagnostic and coaching framework, not a full change management methodology.
• It works best when the change is defined and the target state is clear.
• Each element is sequential; you cannot skip Awareness and expect Desire to develop.
• It focuses on individual transitions, not just organizational milestones.

Management Pitfalls

Assuming awareness alone will lead to desire. People may understand the reasons but still not be personally motivated. Desire requires addressing what's in it for them.

Skipping reinforcement after initial adoption. Without reinforcement, old habits return. This is why many changes fail months after the rollout.

Treating ADKAR as a linear checklist rather than an iterative process. People move back and forth between elements, especially when the change evolves.

Table: ADKAR Elements and Management Actions

ADKAR gives leaders a common language to diagnose where individuals are stuck. For example, if people are not using a new tool despite training, the root cause may be lack of desire or ability, not knowledge. Management can then tailor interventions accordingly.

Technology Organization Example

To make this concrete, consider a mid-sized software company, TechFlow (a constructed example), that is moving from on-premises infrastructure to a cloud-based platform. The change affects engineering, operations, and support teams. The leadership decides to use ADKAR to manage the transition.

Phase 1: Awareness

The CIO holds a series of town halls explaining the business reasons: cost savings, scalability, and competitive pressure. She presents data on infrastructure spending and case studies from similar companies. Emails and intranet posts reinforce the message. After two weeks, a survey shows 80% of employees understand the reasons for the move.

To measure awareness, the change team uses a simple survey question: "Please state in your own words why we are moving to the cloud." Responses are scored 0-3 based on completeness. The target is for 80% of employees to score at least 2. The baseline before the campaign was 20%. After the town halls and communications, 45% score at least 2. After adding manager-led team discussions and an FAQ page, the score reaches 80% by the end of the first month.

Phase 2: Desire

Despite awareness, some engineers worry about job security and skill obsolescence. Managers hold one-on-one meetings to discuss career paths and offer retraining opportunities. A pilot group of enthusiastic volunteers is formed to test the cloud environment. Their positive feedback creates buzz. The survey after one month shows desire increased from 50% to 70%.

Desire is measured with a statement: "I support the move to the cloud for our team." Employees rate agreement on a 1-5 scale. The target is for 70% to rate 4 or 5. Initially, 50% do. After the one-on-ones and pilot group success stories, that rises to 70%. Key influencers who were neutral become advocates after seeing the pilot group's positive experience.

Phase 3: Knowledge

The training team develops a curriculum covering cloud architecture, security, and cost management. Employees take online courses and attend workshops. Documentation is created. A knowledge assessment shows 85% pass the certification exam.

Knowledge is tracked through an online course completion rate and a certification exam. The target is 90% completion and 85% pass rate. After three weeks of training, 80% have completed the course, but only 60% passed the exam. The training team adds a hands-on lab to reinforce concepts, and the pass rate climbs to 85% by week four.

Phase 4: Ability

Employees begin migrating non-critical workloads to the cloud under supervision. Mentors provide real-time coaching. A sandbox environment allows practice. Initially, some deployments fail due to misconfigurations, but a feedback loop captures lessons and updates runbooks. After a two-month pilot, the team can migrate a standard application with minimal assistance.

Ability is measured by the percentage of successful migrations completed without mentor intervention. In the first week, the success rate is 30%. After weekly retros and runbook updates, it reaches 80% by the end of two months. The team defines "success" as the application passing all automated tests and being available within the expected time.

Phase 5: Reinforcement

The company celebrates the first successful migration. Metrics dashboards track cloud adoption, cost savings, and system uptime. Regular check-ins address any backsliding. A recognition program rewards teams that fully decommission old servers. After six months, 90% of workloads are migrated, and the old data center is closed.

Reinforcement is measured by ongoing adoption rates. The target is 90% workload migration and less than 1% regression per month. The company sets up a dashboard that shows migration progress and cost savings. A monthly review meeting with the CIO examines the metrics and decides on corrective actions if targets slip.

Decision Points and Roles

• Go/no-go after each ADKAR phase: Change sponsor (CIO) decides based on readiness assessments.
• Resource allocation for training: HR and department heads.
• Adjusting the migration pace: Project steering committee.

Table: ADKAR Phase, Metrics, and Decision Authority

This example shows how ADKAR turns a large technology change into manageable people-focused milestones. Each phase has clear owners and measures, preventing surprises and resistance.

Decision and Governance Checklist

Governance ensures the change stays on track and that decisions are made by the right people. Use the following checklist at each ADKAR stage to assess readiness and decide whether to continue, modify, or stop the initiative.

Checklist Items

• [ ] Have we clearly defined the business case and communicated it to all affected employees? Owner: Executive Sponsor. Review monthly.
• [ ] Are key stakeholders identified and supportive? Owner: Change Manager. Review monthly.
• [ ] Is the desired future state specific and measurable? Owner: Executive Sponsor. Review at project start.
• [ ] Do we have baseline metrics for current performance? Owner: Change Manager. Review at project start.
• [ ] Have we assessed individual resistance and its sources? Owner: People Managers. Review bi-weekly.
• [ ] Are training and support resources adequate? Owner: Training Lead. Review before Knowledge phase.
• [ ] Is there a feedback mechanism for employees to raise concerns? Owner: Change Manager. Review monthly.
• [ ] Are reinforcement mechanisms in place (rewards, recognition, performance reviews)? Owner: HR Business Partner. Review before Reinforcement phase.
• [ ] Do we have a plan for sustaining the change after initial rollout? Owner: Operations Manager. Review quarterly.

Ownership Checks

• Executive Sponsor: Owns the change vision, secures resources, and removes organizational barriers. Approves go/no-go at major milestones. Revisits the business case quarterly.
• Change Manager: Coordinates ADKAR activities, tracks metrics, and reports progress. Reviews readiness before each phase transition.
• People Managers: Responsible for coaching their teams, addressing individual resistance, and reinforcing the change daily. Meet weekly with team members.
• Employees: Expected to engage with training, provide feedback, and adopt new behaviors.

Table: ADKAR Stage, Review Question, and Decision Criteria

These thresholds are illustrative; adjust based on your organization's risk tolerance and context. The key is to have explicit criteria so decisions are not left to intuition alone.

Common Pitfalls and How to Avoid Them

Even well-intentioned change leaders stumble. Here are the most frequent mistakes with ADKAR and how to recover.

1. Treating ADKAR as a Linear Checklist

Why it happens: Leaders see the five elements as steps to tick off in order. They push through Awareness, declare Desire achieved, and move to Knowledge without verifying individuals have truly embraced the change.

How to avoid: Recognize that people are at different points. Use pulse surveys to gauge where each team or department is. If a group shows low Desire but high Knowledge, you may need to revisit one-on-one coaching. ADKAR is a cycle, not a straight line.

2. Underestimating the Desire Phase

Why it happens: Leaders often assume that if people understand the reasons, they will automatically support the change. This ignores personal impact and emotional resistance.

How to avoid: Spend as much time on Desire as on Knowledge. Involve employees in designing how the change will be implemented. Provide forums for concerns. Use influencers to model support. Measure Desire with surveys and address low scores with targeted conversations.

3. Skipping Reinforcement

Why it happens: Once the new system is live, attention moves to the next project. Without reinforcement, old habits creep back.

How to avoid: Build reinforcement into the system. Automate metrics that show adoption. Schedule monthly reviews for the first six months. Celebrate milestones and recognize employees who sustain the new behavior. Make reinforcement part of performance reviews.

4. Lack of Clear Ownership

Why it happens: Many change initiatives fail because no one person is accountable for each element. Decisions stall, and issues go unresolved.

How to avoid: Assign a single owner for each ADKAR phase. The Executive Sponsor owns Awareness and Desire. The Change Manager owns Knowledge and Ability. The Operations Manager owns Reinforcement. Document these roles and revisit them at each phase gate.

5. Overlooking Individual Barriers

Why it happens: A blanket communication plan treats everyone the same, but individuals may have different obstacles. An engineer may fear job loss; a manager may worry about status.

How to avoid: Use manager one-on-ones to uncover individual barriers. Tailor interventions. For example, offer retraining for those worried about skills. Adjust workload for those overwhelmed. Track resistance patterns and address them early.

Conclusion

The ADKAR Model provides a structured way to manage the people side of organizational and technology change. By focusing on individual transitions through Awareness, Desire, Knowledge, Ability, and Reinforcement, leaders can diagnose resistance and apply targeted interventions. It works best when paired with a clear change vision and governance that defines decision rights and success metrics.

To apply ADKAR in your next initiative:

• Define the change and its business case.
• Assess current ADKAR status for impacted individuals.
• Develop interventions for each element.
• Establish metrics and review cadence.
• Empower managers to coach their teams.
• Reinforce and celebrate progress.

Remember, ADKAR is not a one-time checklist but a continuous cycle. Revisit each element as the change evolves, and adjust your approach based on feedback and data. By doing so, you increase the likelihood of lasting change adoption and avoid the costly trap of failed transformations.