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.

Summarise this post with:

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.

Dimension	Project	Programme	Portfolio
Definition	Temporary endeavour to deliver specific output	Coordinated group of related projects + activities to deliver outcomes and benefits	Group of projects/programmes managed for strategic alignment
Duration	Defined start and end	Longer; often 2-5 years with multiple tranches	Ongoing; portfolio refreshed periodically
Primary success measure	Output delivered on time, in scope, on budget	Benefits realised; transformation achieved	Strategic objectives advanced; resource utilisation optimised
Leadership role	Project Manager	Programme Manager + Business Change Manager	Portfolio Director / PMO
Framework	PRINCE2, PMBOK, Agile (Scrum, Kanban)	MSP (Managing Successful Programmes), PMI Standard for Program Management	MoP (Management of Portfolios), PMI Standard for Portfolio Management

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.

Dimension	Change programme management (MSP)	Change management (Kotter/Prosci)
Focus	Programme structure, governance, benefits	People adoption of change
Scope	Multiple projects + BAU change coordinated for benefits	How individuals and teams adopt new ways of working
Origin	AXELOS / UK Government Office of Government Commerce	Kotter (HBS); Hiatt (Prosci)
Typical owner	Programme Manager, Business Change Manager	Change Management Practitioner, HR/OD

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