Change Programme

The MSP Business Change Manager (BCM) role is the operational owner of getting the programme’s new ways of working embedded in the receiving business.

Change Programme is a coordinated portfolio of related projects, activities, and business-as-usual changes managed together to deliver transformational outcomes and realise specified benefits that no individual project could achieve alone. The dominant framework is AXELOS’s Managing Successful Programmes (MSP), widely used across UK public sector, NHS, financial services, and globally. Also called: change program (US), transformation programme, business change programme, programme of work.

Programme vs project vs portfolio

These three terms describe different scales and types of organised work. The distinctions matter operationally because they require different governance, skills, and success measures.

Practical implication: an IT system implementation is a project; modernising an entire customer experience through coordinated IT, process, training, and culture initiatives is a programme. Treating a programme as a project (PRINCE2 only, no benefits-realisation focus) is among the most common transformation failures.

Managing successful programmes (MSP): the dominant framework

Managing Successful Programmes (MSP) is the most-cited programme management framework globally and especially in UK public sector. Originally developed by the UK Office of Government Commerce (now AXELOS, later acquired by PeopleCert in 2021), MSP is in its 2020 edition. Key MSP concepts:

Seven principles

Per MSP, every successful programme operates against seven principles:

• Leading with purpose
• Collaborating across boundaries
• Dealing with ambiguity
• Aligning with priorities
• Deploying diverse skills
• Realising measurable benefits
• Bringing pace and value

Seven themes

Programmes are governed through seven themes: Organisation (roles, governance, structure), Design (vision, blueprint, target operating model), Justification (business case, benefits, investment appraisal), Structure (projects, tranches, dependencies), Knowledge (information management, learning), Assurance (quality control, audit, review), and Decisions (choices, prioritisation, control).

Tranches: the wave structure of programmes

MSP organises programme work into ‘tranches’, groups of projects and activities delivered together to create a step-change in capability before moving to the next tranche. A typical 3-tranche programme structure:

• Tranche 1: Foundation. Establish baseline capabilities, infrastructure, governance, and early wins. Typical duration 6-9 months.
• Tranche 2: Scale. Roll out capabilities at scale; deliver bulk of benefits; embed in business operations. Typical duration 9-15 months.
• Tranche 3: Optimise and sustain. Refine, optimise, embed; ensure benefits sustained and BAU-ready. Typical duration 6-12 months.

Between tranches, the programme conducts a formal review confirming benefits delivered, validating the business case for proceeding, and resetting the plan if needed. This ‘pause-and-check’ discipline is one of MSP’s distinguishing features.

Benefits realisation: the heart of programme management

Where project management focuses on outputs (system delivered, training rolled out), programme management focuses on benefits (cost reduced, customer satisfaction improved, capacity expanded). Benefits realisation is the discipline of ensuring those benefits actually materialise and are measured.

Components of benefits realisation:

1. Benefits identification. In the business case, articulate specific, measurable, time-bound benefits with clear ownership.

1. Benefits mapping. Connect each benefit to specific programme outputs and the changes in behaviour, process, or capability required to convert output into benefit.
2. Baseline measurement. Measure the starting state for each benefit so improvement can be quantified.
3. Benefits realisation plan. Define when each benefit will be measured, by whom, and what action will be taken if benefits underperform.
4. Ongoing measurement. Track benefits during and after the programme; many benefits realise after programme closure.
5. Benefits review. Post-programme reviews, typically 6 months and 12 months post-closure, assess actual benefits realised vs business case.

Hr’s role in change programmes: the business change manager

The MSP Business Change Manager (BCM) role is the operational owner of getting the programme’s new ways of working embedded in the receiving business. In HR-led or HR-heavy programmes, HR often holds the BCM role. Key BCM responsibilities:

• Define the changes in capability, behaviour, and process required to convert programme outputs into benefits
• Coordinate operational readiness for the receiving business unit
• Lead the people-side of change: communication, training, engagement
• Maintain the benefits realisation plan from the business perspective
• Sign off on benefits as they realise
• Operate as the bridge between programme delivery and business operations

HR practitioners are often natural fits for the BCM role given the people-side focus. See Change Management for the individual-level discipline that sits alongside BCM work, Agile HR for iterative approaches to transformation, Boundaryless Organization for transformation type context, Carve-Out for M&A programme context, Rightsizing for structural change context, and Best Practice Policy for HPWS context.

MSP vs change management discipline

A frequent source of confusion: change programme management (MSP-style) and change management (Kotter/ADKAR-style) are related but distinct.

The frameworks are complementary, not competing. MSP provides the programme-level structure and benefits focus; Kotter/ADKAR provides the adoption-level discipline. Mature transformation operates both simultaneously.

Common change programme failures

• Programme run as a large project. PRINCE2 governance applied to programme-scale work; output focus without benefits focus; predictable underdelivery against transformation intent.
• Weak Senior Responsible Owner. SRO without sufficient seniority, authority, or commitment of time. Programmes without strong SROs typically drift.
• BAU change underestimated. Programmes focus on delivery and underestimate the operational embedding work; outputs delivered but not absorbed.
• Benefits not measured. Without baseline and ongoing measurement, benefits realisation becomes anecdote rather than evidence.
• Tranche discipline absent. Programme runs continuously without pause-and-check reviews; problems compound; business case validity drifts.
• Change management treated as a workstream. ‘Change management’ as a small subteam within the programme rather than the operating philosophy of the programme.

Frequently asked questions