Managing Organisational Change in Programmes

Why Change Management Is a Programme Concern

Most programme failures are not technical — they're adoption failures. The system works perfectly, but:

• Users revert to old processes because the new ones weren't embedded
• Middle management resists because they weren't engaged early enough
• Training was insufficient and users can't operate the new system effectively
• The organisation's culture doesn't support the new ways of working
• Benefits don't materialise because behaviour didn't actually change

The Programme Manager doesn't own change management (that's typically a dedicated Change Manager or the business sponsor), but they must ensure it's planned, resourced, and integrated with delivery.

The Change Management Framework

1. Stakeholder Impact Assessment

For each project in the programme, identify:

• Who is affected? (Which teams, roles, departments, customers)
• How are they affected? (New processes, new tools, new skills, new reporting lines)
• How significant is the change? (Minor adjustment vs fundamental role change)
• What's their likely reaction? (Enthusiastic, neutral, resistant, hostile)
• What do they need to adopt successfully? (Training, support, time, incentives)

Map this on a change impact matrix: high impact + high resistance = highest priority for change management investment.

2. Change Readiness Assessment

Before major deployments, assess whether the organisation is ready:

• Awareness: Do affected people know the change is coming? Do they understand why?
• Desire: Do they want to change? What's in it for them? What are their concerns?
• Knowledge: Do they know how to operate in the new way? Have they been trained?
• Ability: Can they actually perform the new processes? Have they practised?
• Reinforcement: Are there mechanisms to sustain the change? (Incentives, metrics, support)

This is the ADKAR model (Prosci). If any element is missing, adoption will fail regardless of how good the technology is.

3. Change Plan Integration

Integrate change activities into the programme plan — not as a separate workstream that runs in parallel, but as embedded activities within each project:

During design:

• Engage affected users in requirements and design decisions
• Communicate the vision and rationale for change
• Identify change champions in each affected team

During build:

• Develop training materials alongside the system
• Run pilot groups to test new processes before full rollout
• Communicate progress and timeline regularly

During deployment:

• Deliver training just-in-time (not 3 months before go-live)
• Provide hypercare support for the first 2-4 weeks
• Monitor adoption metrics daily during the transition period

Post-deployment:

• Measure adoption and address gaps
• Reinforce new behaviours through management actions
• Celebrate early wins to build momentum
• Address resistance directly and empathetically

4. Resistance Management

Resistance is natural and expected. It's not a problem to eliminate — it's information to understand.

Common sources of resistance:

• Fear of job loss or role change
• Comfort with current processes (even if they're inefficient)
• Lack of trust in leadership's motives
• Previous bad experiences with change programmes
• Genuine concerns about the new approach (sometimes resistance is right)

Response strategies:

• Listen first: Understand the concern before trying to address it
• Acknowledge the loss: Change always involves giving something up. Acknowledge that.
• Involve resistors: People support what they help create. Involve vocal critics in design decisions.
• Address legitimate concerns: Sometimes resistance reveals real problems. Fix them.
• Provide support: Training, coaching, time to adjust, permission to make mistakes during transition
• Set clear expectations: After reasonable support, the new way of working is non-negotiable

The Programme Manager's Role

What you own:

• Ensuring change management is planned and resourced in the programme plan
• Integrating change activities with delivery milestones
• Reporting change readiness alongside delivery progress in governance
• Escalating adoption risks that threaten benefit realisation

What you don't own:

• Designing the change approach (Change Manager)
• Delivering training (L&D team)
• Communicating the vision (Executive sponsor)
• Reinforcing new behaviours (Line managers)
• Making the business case for change (Sponsor)

What you enable:

• Budget allocation for change management activities
• Timeline that allows for training and transition periods
• Governance that tracks adoption alongside delivery
• Stakeholder access for the change team
• Integration between technical delivery and organisational readiness

Measuring Change Success

Leading Indicators (During Delivery)

• Awareness: % of affected staff who know the change is coming and understand why
• Training completion: % of users trained before go-live
• Champion engagement: Number of active change champions per affected team
• Resistance level: Sentiment from pulse surveys or focus groups
• Readiness score: ADKAR assessment results across affected populations

Lagging Indicators (Post-Deployment)

• Adoption rate: % of users actively using the new system/process (target: >80% within 3 months)
• Proficiency: Users performing at expected speed/quality (not just logging in)
• Support ticket volume: Decreasing trend after initial spike (indicates growing competence)
• Process compliance: % of transactions following the new process (not workarounds)
• Benefits realisation: Are the expected benefits materialising? (The ultimate measure)

Anti-Patterns

Technology-first, people-later: Building the system first and thinking about adoption after deployment. Fix: start change management at programme initiation, not at go-live.

Training = change management: Assuming a 2-hour training session is sufficient for people to change how they work. Fix: training is one element. Change requires awareness, desire, knowledge, ability, AND reinforcement.

Ignoring middle management: Focusing change efforts on end users while ignoring the managers who will reinforce (or undermine) the change daily. Fix: engage middle management first — they're the multiplier.

One-size-fits-all communication: Sending the same email to everyone regardless of how the change affects them. Fix: tailor communication by impact level and audience.

---

Download the [Benefits Realisation Tracker template](/templates) to track adoption metrics alongside benefit realisation.