Technology projects fail for many reasons, but one stands out: people don't use the new system. Organisations spend millions on software that sits unused because no one invested in helping people change how they work. Change management is how you bridge the gap between "we have a new system" and "everyone uses it effectively."
Why Technology Change Fails
The adoption gap: Many technology projects deliver working software but fail to deliver business value because adoption never happens. Users revert to old processes, workarounds proliferate, and the investment is wasted.
Common Failure Patterns
- "Big bang" announcements: Surprising users with major changes
- No clear "why": Users don't understand the purpose or benefit
- Inadequate training: Brief sessions that don't build real competence
- Ignoring workflow disruption: New system doesn't fit how people actually work
- No support after go-live: Users left to struggle alone
- Leadership doesn't use it: "Do as I say, not as I do"
Change Management Framework
ADKAR Model
A practical framework for individual change:
- Awareness: Understanding why change is needed
- Desire: Wanting to participate and support the change
- Knowledge: Knowing how to change
- Ability: Demonstrating skills and behaviours
- Reinforcement: Sustaining the change
When adoption stalls, diagnose which element is missing. Training doesn't help if people lack awareness of why they should care.
Stakeholder Engagement
Stakeholder Analysis
Identify everyone affected by the change. Map them by influence (can they enable or block adoption?) and impact (how much does this change their work?). Focus engagement on high-influence and high-impact groups.
Communication Strategy
- Early and often: Start communication before project starts, continue through and after go-live
- Multi-channel: Different people prefer different channels—email, meetings, intranet, videos
- Two-way: Create opportunities for questions and feedback
- Tailored messages: Different stakeholder groups have different concerns
Message Components
- Why: The business reason for change
- What: Specifically what is changing
- When: Timeline and key dates
- How: What support is available
- WIIFM: What's in it for me—benefits to the user
Training and Support
Training Approaches
- Role-based training: Train people on what they actually need to do, not everything the system can do
- Hands-on practice: Users need to do, not just watch
- Just-in-time: Training close to go-live, not months before
- Scenario-based: Real workflows, not abstract features
- Multiple formats: Live sessions, videos, quick reference guides, help documentation
Go-Live Support
The first weeks after go-live are critical. People forget training, encounter unexpected scenarios, and become frustrated. Provide:
- Floor walkers: Support staff available where users work
- Super users: Trained colleagues who can help peers
- Help desk: Clear escalation path for issues
- Quick wins: Early successes that build confidence
Managing Resistance
Resistance is natural. People resist change for rational reasons: fear of incompetence, loss of status, workflow disruption, or simply not seeing the benefit. Understand the reasons before addressing them.
Addressing Resistance
- Listen: Understand the specific concerns
- Acknowledge: Validate that change is difficult
- Involve: Give resisters a role in shaping the solution
- Address concerns: If concerns are valid, modify the approach
- Demonstrate benefits: Show real improvements from early adopters
- Hold the line: Eventually, non-adoption isn't optional
The 20-60-20 rule: Typically 20% will embrace change, 60% will wait and see, and 20% will actively resist. Focus on the middle 60%—early adopters help pull them along, and with critical mass, the resisters either come along or become irrelevant.
Measuring Adoption
Adoption Metrics
- Login rates and active users
- Feature usage compared to expectations
- Process compliance (are new workflows being followed?)
- Support ticket volumes and trends
- User satisfaction surveys
Business Outcome Metrics
Ultimately, measure whether the change delivered intended benefits: efficiency gains, error reduction, customer satisfaction improvement, or whatever the project set out to achieve.
Summary
Technology change is really people change. Success requires systematic attention to stakeholder engagement, communication, training, and support—not just good software. Plan change management as carefully as you plan technical implementation.
Invest proportionally: the more significant the change to how people work, the more change management effort required. A new interface needs less than a complete workflow transformation. Match your investment to the size of the human change, not just the size of the technology change.