The Real Reason Technology Projects Fail

Prosci research consistently shows that projects with excellent change management are six times more likely to meet their objectives than projects with poor change management. Yet most technology budgets allocate less than 5% to change management activities. The disconnect stems from a fundamental misunderstanding: technology projects are not technology problems — they are human behavior change problems. A new ERP system only delivers value when employees use it correctly. An AI tool only improves decisions when people trust and act on its recommendations. The technology is the easy part. Changing how thousands of people work every day is the hard part.

The ADKAR Model for Technology Change

The ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement) provides a practical framework for managing individual change through technology transitions. Awareness: employees must understand why the change is happening and what happens if it does not. Desire: employees must want to participate in the change — this requires addressing WIIFM (what's in it for me?). Knowledge: employees must know how to change — training, documentation, and support resources. Ability: employees must be able to demonstrate the new behaviors — practice environments, coaching, and performance support. Reinforcement: the new behaviors must be sustained through recognition, accountability, and ongoing support.

Stakeholder Analysis and Engagement

Not all stakeholders experience change the same way. A stakeholder analysis maps every group affected by the technology change along two dimensions: impact (how significantly does this change affect their daily work?) and influence (how much power do they have to support or block the change?). High-impact, high-influence stakeholders require intensive engagement — executive briefings, early involvement in design decisions, and direct access to project leadership. High-impact, low-influence stakeholders (often frontline employees) require comprehensive training and support. Low-impact, high-influence stakeholders (often senior executives in adjacent departments) require regular communication to prevent them from becoming blockers.

Building a Change Champion Network

Change champions — also called super users or change agents — are employees within each affected department who receive advanced training and serve as peer coaches during the transition. They are not project team members; they are respected colleagues who can answer questions in the language of their department, demonstrate the new technology in real work contexts, and provide ground-level feedback to the project team. An effective change champion network typically includes one champion per 15–20 users, selected based on peer respect and openness to change rather than seniority. Champions should receive 2–3x the training of regular users and have a direct communication channel to the project team.

Measuring Adoption and Sustaining Change

Change management does not end at go-live. The most critical period is the 90 days after launch, when the risk of reverting to old behaviors is highest. Adoption metrics to track include: system login frequency, feature utilization rates, error rates (high errors indicate training gaps), help desk ticket volume (spikes indicate adoption problems), and process compliance rates. When adoption metrics fall below targets, the response should be targeted — identify which user groups are struggling, understand the specific barriers they face, and provide targeted support rather than blanket retraining.