You’re sitting at the top of something large. Below you, a handful of PRINCE2 projects are grinding through their stages, each with its own business case and its own project manager who thinks their initiative is the most important one in the building. Off to one side, two or three Agile Release Trains are delivering increments every eight to twelve weeks, blissfully unbothered by your stage gates. And once their software goes live, a service desk somewhere is keeping it all running under an ITIL operating model.
Everyone below you are busy. Everyone is delivering. And yet someone, you, probably, has to answer the one question that none of those frameworks fully owns:
What is all of this activity actually for, and how will we know it worked?
That question is the entire reason MSP, Managing Successful Programmes, exists. If the three-part series in this collection mapped PRINCE2, SAFe and ITIL against one another, think of this piece as the view from the floor above: the programme office, where investment meets outcome, and where the connective tissue between all three frameworks is either deliberately designed or quietly missing.
What MSP Actually Is (and What It Isn’t)
MSP is PeopleCert’s framework for programme management, the discipline of coordinating a group of related projects and change activities to deliver outcomes and benefits that no single project could achieve on its own. The current 5th edition is built on a tidy, memorable structure of sevens:
- Seven principles, Lead with purpose, collaborate across boundaries, Deal with ambiguity, align with priorities, deploy diverse skills, realise measurable benefits, and Bring pace and value.
- Seven governance themes, Organization, Design, Justification, Structure, Knowledge, Assurance, and Decisions.
- Seven processes, the programme lifecycle: Identify the programme, Design the outcomes, plan progressive delivery, Deliver the capabilities, Embed the outcomes, evaluate new information, and close the programme.
Here’s what MSP isn’t: it isn’t a delivery method. It won’t tell your teams how to write software (that’s SAFe), how to control an individual project (that’s PRINCE2), or how to run a service desk (that’s ITIL). MSP deliberately sits above all of that. It is concerned with the why and the so what, the investment case across multiple initiatives, and the benefits that justify the whole endeavour.
One small detail worth noting for anyone who has ever sat through a continuous-improvement workshop: MSP 5th edition explicitly threads the Plan-Do-Check-Act cycle through its programme strategy and plans. The programme advances in incremental tranches, checking emergent reality against intended outcomes and adapting as it goes. Which, you may agree, is a rather sensible way to run anything.
The Layer Below You: A Quick Recap
If you’ve read the three-part series, you already know the boundaries. If you haven’t, here’s the one-paragraph version from a programme manager’s height:
PRINCE2 7 governs each project, its business case, its controlled stages, its delivery of specified products. In a scaled-agile setting it maps to the Agile Release Train as the delivery vehicle: the ART builds the products a project is accountable for. Strong on project-level justification and control; silent on what happens across projects.
SAFe 6 governs delivery at scale, Agile Release Trains delivering increments on a fixed cadence. Strong on execution; silent on investment justification and benefits realisation.
ITIL 5 governs the live service, operations, incidents, change enablement, continual improvement. Strong on keeping value flowing once it’s live; silent on whether the right thing was built in the first place.
Each is excellent within its boundary. None of them, individually or collectively, answers the programme-level question: is this coordinated portfolio of change worth the investment, and are the benefits actually materialising? That gap is where you live.
The Investment Question Nobody Else Owns
Here’s a distinction that trips people up. PRINCE2 has a business case. So why does a programme need its own justification?
Because a project business case answers a project-shaped question: is this initiative worth doing, and is it still worth doing as it progresses? It’s bounded by the project’s own outputs. What it cannot do is weigh one project against another, decide which initiatives should be sequenced or stopped to protect a shared outcome, or judge whether the combined effect of a dozen projects justifies the total spend.
MSP’s Justification theme is the business case raised to programme scope. It governs financial decision-making across the whole programme, investment appraisal, prioritisation of cash, the risk profile of achieving the target outcomes, and the ongoing question of whether the programme remains a viable investment as the world changes around it. It is, in effect, the investment-governance layer for everything happening beneath you.
This is the connective tissue. The programme business case sets the envelope. Each PRINCE2 project’s business case nests inside it. Each SAFe ART’s roadmap serves it. And the benefits it promises only land once ITIL-governed services are operating and embedded. MSP is the only one of the four frameworks whose entire reason for being is to hold that chain together.
Where the Programme Meets the Programme Increment
There’s a happy linguistic accident worth exploiting here. SAFe gives you a Release Train, the standing team of teams, and a Programme Increment (rebranded the Planning Interval in SAFe 6.0, though the PI initials survive), the eight-to-twelve-week timebox in which that train delivers. The word “programme” turns up in both SAFe’s PI and in MSP, and that isn’t entirely a coincidence: both are concerned with delivering value incrementally toward something larger than a single sprint. But they operate at different altitudes, and getting the relationship right is what separates a coordinated programme from a collection of trains running on parallel tracks.
- An MSP programme advances in tranches, blocks of work that deliver a step-change in capability, after which benefits can be reviewed and the programme re-justified before committing to the next.
- A SAFe ART advances in Programme Increments, fixed-cadence delivery timeboxes, each one planned at PI Planning and closed with an Inspect & Adapt.
The link is this: the Programme Increment is the delivery heartbeat; the tranche is the benefits-bearing block of the programme. A single MSP tranche is typically realised through one or more PIs. The ART’s Programme Increments supply the cadenced delivery; MSP supplies the outcome those increments are serving, and the benefits review that decides whether the next tranche, and therefore the next run of PIs, is still worth funding.
| Put plainly: PRINCE2 governs the project the ART delivers; MSP governs the Programme Increment cadence those projects advance through. Two frameworks, two altitudes, one train. |
This is where MSP’s lifecycle and SAFe’s cadence interlock cleanly:
- SAFe’s PI Planning sets each increment’s objectives, serving MSP’s Plan progressive delivery, which defines the tranche those increments deliver into.
- SAFe’s Inspect & Adapt at the close of each Programme Increment feeds MSP’s Evaluate new information, the process that decides whether the programme’s direction still holds.
- The benefits reviewed at an MSP tranche boundary are the cumulative result of everything the ART shipped across its Programme Increments.
At heart, it’s the same Plan-Do-Check-Act loop running at two altitudes: the ART checks and adapts every Programme Increment; the programme checks and adapts every tranche. Align those two rhythms and you have genuine programme governance over scaled agile delivery. Leave them disconnected and you have an ART delivering increments very efficiently toward an outcome that nobody is actually governing.
Who Owns Which Governance Question
If you take one table away from this piece, make it this one. It maps the governance question to the framework that owns it, and shows precisely where MSP provides the connective tissue.
| The governance question | Framework that owns it |
| Is this coordinated set of change worth the total investment, and are the benefits materialising? | MSP, Justification theme + benefits management |
| Is this individual initiative justified and under control? | PRINCE2 7, Business Case practice, mapped to the ART |
| How do we organise and execute delivery at scale? | SAFe 6, ARTs, PI Planning, cadence |
| How does each Programme Increment connect to a benefits-bearing tranche? | MSP, tranches and progressive delivery, served by SAFe PIs |
| How do we keep the live service reliable, and improve it? | ITIL 5, service operation and improvement |
| How do all of the above stay align to one set of outcomes? | MSP, the connective tissue across all three |
The Benefits Realisation Gap
Here is the uncomfortable truth that programme managers learn early and everyone else learns late: benefits do not appear when software is delivered. A PRINCE2 project closes when its products are accepted. A SAFe ART celebrates when the increment ships. But shipping a capability is not the same as realising a benefit.
Benefits appear later, when the new capability is adopted, when people change how they work, when the service runs reliably enough that the organisation actually relies on it. That’s why MSP’s lifecycle has a process called Embed the outcomes, and why benefits management runs as a continuous thread rather than a closing formality.
This is also where MSP and ITIL shake hands. The benefit you promised in the programme business case is realised in the operational world that ITIL governs. If nobody connects the programme’s benefit profiles to the live service’s performance, you will close a ‘successful’ programme that delivered everything and benefited no one. MSP exists, in large part, to stop precisely that.
Three Questions to Ask from the Programme Office
If you’re sitting above PRINCE2 projects, SAFe ARTs and ITIL services, here are the three questions that tell you whether your programme governance is real or merely organisational décor:
Can I trace every project and ART back to a programme-level outcome, and would I stop any of them if they stopped serving it?
Do I have benefit profiles that name who realises each benefit, when, and how it’s measured, and are they connected to the live service?
If the world changes mid-programme, do I have a governance mechanism to re-justify, re-sequence or stop, rather than simply finishing what we started because we started it?
If you can answer all three with a straight face, your programme office is doing its job, and the three delivery frameworks beneath you have something coherent to align to. If you can’t, you’ve found the gap, and MSP is the framework purpose-built to fill it.
| PRINCE2, SAFe and ITIL each govern a layer brilliantly. MSP governs whether all those layers are adding up to something worth the investment, the quietest framework in the room, and often the one holding the room together. |
To find out more about PDCA Consulting’s expert consulting services or coaching either:
- Call +49 172 579 4719
- Complete the contact form
- Contact via LinkedIn
Part of the series: Frameworks in the Enterprise. The three-part series maps PRINCE2 7, SAFe 6 and ITIL 5 for senior leaders, SAFe practitioners, and PRINCE2/ITIL practitioners. This bonus piece adds the programme governance layer.
About the author: This series is produced by a PRINCE2 7 Master and ITIL 5 Master practitioner working in the DACH region, specialising in governance, programme and service management, and agile transformation.
