Topic 5.2 — Program-Led Work

In one sentence: Program-led work coordinates a set of related projects and products toward a strategic change that none could deliver alone, holding a clear line of sight from the work to the benefits it is meant to realize.

Why this matters in health and care#

The biggest changes in health and care are never a single project. Rolling out a shared care record across an integrated care system (ICS), moving a region to a single electronic patient record, transforming an urgent-and-emergency-care pathway, or delivering a virtual-ward program across multiple trusts — each of these is a coordinated bundle of projects, product teams, workforce change, estates work, and clinical redesign, aligned to one strategic outcome. Manage the pieces in isolation and they collide: incompatible data standards, duplicated spend, contradictory clinical workflows, and benefits that never actually materialize.

Program management exists to hold that coalition together and to keep it pointed at outcomes and benefits, not just outputs. This matters acutely in health and care because system-wide change touches patient safety across organizational boundaries, commits large sums of public money over several years, and depends on many autonomous organizations choosing to move in step. A program provides the leadership, the shared target state, and the benefits discipline to make that happen — and, just as importantly, to know whether it is working.

The recurring failure it guards against is the program that spends millions, delivers a pile of technical outputs, and yet changes nothing measurable for patients or staff. This topic uses Managing Successful Programmes (MSP), the UK public sector's dominant framework, and shows how program-led work coexists with the project-led (Topic 5.1 — Project-Led Work) and product-led (Topic 5.0 — Product-Led Work) modes it coordinates. Topic 5.3 — Enterprise Portfolio & Project Management (EPPM) then explains how an organization prioritizes across many programs.

Core concepts#

Program. A temporary, flexible organization created to coordinate, direct, and oversee a group of related projects and activities to deliver outcomes and benefits aligned to strategic objectives. A program differs from a project in that it is defined by the outcome and benefits it seeks, and it manages the uncertainty of coordinating many moving parts, rather than delivering a single fixed output.

MSP (Managing Successful Programmes). The UK best-practice framework for managing transformational change through multiple related projects. It is organized around principles, themes, and a "transformational flow" of processes, and is designed for large, complex change where the end state is known in direction but the path involves many interdependent deliveries.

Vision and blueprint. The vision is the compelling picture of the future the program will create. The blueprint makes it concrete: it describes the target operating model — the future state of processes, organization, technology, information, and roles (often summarized as POTI). The blueprint is the reference point every project is steered toward, so the pieces add up to a coherent whole.

Benefits realization. The heart of program management. Benefits are the measurable improvements that justify the investment — reduced delayed discharges, fewer duplicated tests, faster diagnosis, lower administrative burden. MSP treats identifying, mapping, measuring, and actively managing benefits across the whole lifecycle as a core discipline, because outputs only create value when they are used to change how care is delivered.

Tranches. MSP breaks a program into tranches — blocks of work ending at a major review point where a step of capability has been delivered and benefits realization can begin. A tranche is a moment to demonstrate outcomes, reassess the blueprint against reality, and decide whether to continue, adjust, or stop, rather than merely a slice of the schedule.

Program board and SRO. The Senior Responsible Owner (SRO) is the single individual accountable for the program meeting its objectives and realizing its benefits, with enough seniority and authority to lead and to make decisions. The SRO chairs a program board — typically a business change manager, project leads, and senior stakeholders — that provides direction across organizational boundaries.

Business change manager (BCM). MSP's distinctive role: someone from the operational business (not the delivery team) accountable for embedding the change and realizing the benefits on the ground. The BCM is why programs deliver outcomes and not just outputs — projects hand over capability, the BCM turns it into benefit.

Best practices#

1. Anchor the program in a vision and a blueprint. Define the strategic outcome and translate it into a concrete target operating model (processes, organization, technology, information — POTI). Every constituent project and product is then steered toward the same future state, which is what stops a coalition of deliveries from fragmenting.

2. Manage benefits, not just deliverables. Build a benefits map linking each output to the outcomes and measurable benefits it should produce, with owners and baselines. Review benefits actively across the program, and be willing to stop work that is not going to pay back — MSP's emphasis on benefits realization is the discipline that separates a program from an expensive to-do list.

3. Structure the work into tranches with real review points. Deliver capability in tranches, and at each tranche boundary demonstrate the benefits realized so far, re-test the blueprint against what you have learned, and make a genuine continue/adjust/stop decision. Early tranches should target visible quick wins to build stakeholder confidence for the harder later ones.

4. Appoint an empowered SRO and a real program board. Name a single SRO with the seniority and authority to direct the program and decide across organizational boundaries, and convene a board that genuinely represents the affected organizations. Programs fail when accountability is diffuse or the SRO cannot actually make cross-boundary decisions stick.

5. Put business change managers in the operational business. Assign BCMs from the frontline organizations to own adoption and benefit realization where care is delivered. Capability delivered but not adopted realizes no benefit; the BCM role is the mechanism that closes that gap.

6. Coordinate — do not micromanage — the constituent projects and products. The program sets the blueprint, the interdependencies, the standards, and the benefits; it lets projects and product teams deliver within that frame. It manages the seams — shared data standards, information governance, sequencing, and shared infrastructure — not the internal detail of each delivery.

7. Manage cross-cutting risk, dependency, and stakeholders relentlessly. The value a program adds over standalone projects is largely in managing what happens between them. Maintain a program-level view of interdependencies and shared risks, and invest heavily in stakeholder engagement across autonomous organizations, since alignment is voluntary, not commanded.

8. Close the program when the change is embedded, and hand ongoing services to product teams. A program is temporary. When the blueprint is achieved and benefits are being realized, close it deliberately, transfer any enduring services to durable product teams (Topic 5.0), and keep tracking benefits into business-as-usual — many benefits accrue after the program ends.

Questions to discuss with your team#

1. Does our senior responsible owner actually have the authority to make decisions stick across sovereign partner organizations, or only the accountability when they do not? Program-led work lives or dies on cross-boundary authority, because the change spans autonomous trusts, primary care, community, mental health, and social care that cannot simply be ordered to move in step. The characteristic failure is a named SRO who carries the personal, public accountability for benefits but lacks the standing to compel a reluctant partner to adopt a shared data standard or change a clinical workflow — accountability without authority. The debate should be candid about where real power sits in the system: whether the program board genuinely represents the affected organizations or is a reporting forum, whether the SRO is senior enough that their decisions are honored across sovereign boundaries, and what happens when one partner declines to move. Consider a recent cross-organization decision and trace whether it actually held. A good answer names who the SRO is and tests their authority against a concrete cross-boundary conflict, is honest about the organizations that can effectively opt out, and treats a representative board and embedded business change managers as load-bearing mechanisms for voluntary alignment rather than governance decoration.

2. How will we know this program has realized benefits and not merely delivered outputs — and who, in the operational business, is accountable for turning capability into benefit? Output theater is the recurring pathology the topic warns against: a program spends millions, produces a pile of interoperability platforms and integrations, and yet nothing measurable changes for patients or staff. The distinction that prevents it is the business change manager — someone from the frontline operation, not the delivery team, accountable for embedding the change and realizing benefit where care is delivered — so the question forces the team to name those people and confirm they exist. The tension is that delivery is visible and satisfying while adoption is slow, unglamorous, and easy to assume will just happen; a shared care record buried behind an extra login realizes no benefit however well it is built. Bring the benefits map to the discussion and stress-test whether each output is linked to an owned, baselined, measurable benefit (fewer duplicated tests, reduced delayed discharges) or whether benefits are merely asserted. An honest answer names a BCM in each partner organization, admits where benefits are currently unowned or unmeasured, and accepts that some benefits accrue only after the program closes and must be tracked into business-as-usual.

3. Are we tranching this program to bank early benefits and create real continue/adjust/stop points, or drifting toward a big-bang delivery that defers all the risk to one late moment? Tranches are what separate a program from an expensive frozen plan: each tranche boundary should deliver a step of capability, demonstrate benefits realized so far, re-test the blueprint against what has actually been learned, and support a genuine decision to continue, adjust, or stop. The health and care temptation is to sequence for engineering convenience and defer visible value — connecting every trust before anyone can use anything — which loads all the risk into a single late delivery and leaves the board with no evidence to defend continued investment through fiscal and political cycles. The debate should examine whether early tranches target deliberate quick wins that build stakeholder confidence for the harder later work, and whether the review points are real decisions or schedule checkpoints. Consider what the first demonstrable benefit is, how soon it lands, and what the board would actually do at a tranche review if adoption lagged or the blueprint proved wrong. A good answer describes concrete tranches with early, measurable wins, treats each boundary as a real go/no-go with the blueprint genuinely open to revision, and is honest about any pressure to defer value to the end.

4. Do we have a single, maintained blueprint of the target operating model, or is each project quietly optimizing toward its own version of the future? The blueprint — the concrete POTI target operating model of processes, organization, technology, and information — is what makes the pieces add up to a coherent whole rather than a collision of locally sensible decisions. Without one, each constituent project rationally optimizes for its own scope: one trust picks a data standard that suits its incumbent EPR, another designs a clinical workflow around its own staffing, and the shared care record fragments into integrations that technically connect but do not cohere. The tension is that maintaining a blueprint feels like overhead to delivery teams under pressure to ship, and it must be a living reference re-tested at every tranche rather than a document written once and shelved. The debate should establish whether the blueprint actually exists in usable form, who owns it, and whether real project decisions are being steered by it or merely reconciled to it after the fact. Consider a recent design choice in one project and ask whether the blueprint shaped it or was silently overridden. An honest answer can point to a current blueprint, names its owner, and is candid about where local optimization is already pulling the target state apart.

5. When the program closes, what endures — and have we named the durable product teams that will run the capability and keep tracking benefits into business-as-usual? A program is temporary by definition, but the shared care record, the interoperability platform, and the benefits they produce are not, so closure is a design problem to be planned from the start rather than an afterthought. The recurring failure at each end of the spectrum is real: some programs never close and harden into permanent bureaucracies long after the change is embedded, while others close abruptly and strand a live clinical service with no durable owner. The topic is explicit that enduring services should transfer to durable product teams (Topic 5.0) and that many benefits accrue only after the program ends and must be tracked into BAU — which means the receiving teams and the ongoing benefits ownership have to be identified while the program still has the authority and funding to establish them. The debate should surface who will run each enduring capability, how it will be funded once transformation money stops, and who keeps measuring benefits when the program board has dissolved. A good answer names the specific product teams and BAU owners, describes the funding transition honestly, and treats closure and benefit tracking as planned tranches rather than a hopeful handover.

6. How are we managing the seams between projects — shared standards, information governance, sequencing, and shared infrastructure — rather than the internals of each delivery? The value a program adds over a set of standalone projects lives almost entirely in the space between them: the interdependencies, the shared data standards, the information-governance and consent framework, and the common infrastructure that no single project owns but all depend on. The temptation for a program team is to drift into micromanaging the internals of each delivery — comfortable, visible work — while the genuinely hard cross-cutting seams go unmanaged until they surface as an integration failure or an information-governance blocker at go-live. In health and care these seams are unusually load-bearing, because data flows and consent cross sovereign organizational and regulatory boundaries where alignment is voluntary and legal duties are shared but unevenly resourced. The debate should test whether there is a program-level view of interdependencies and shared risks, who owns the shared standards and infrastructure, and whether the program is coordinating seams or meddling in project detail. An honest answer identifies the specific seams that most threaten the outcome, names their owners, and is candid about whether the program is adding value at the boundaries or duplicating the work of the projects it should be enabling.

In practice: a health & care example#

An ICS sets out to deliver a shared care record giving clinicians across acute, community, mental health, primary care, and social care a unified view of a person. No single project can deliver this: it spans multiple trusts, several source systems, information-governance agreements, clinical-workflow redesign, and public engagement. It is coordinated as an MSP program.

The SRO — an ICS executive with genuine cross-system authority — chairs a program board with representatives from each partner organization and named business change managers in each. The program sets a vision ("the right information, about the right person, available to the right clinician, at the point of care") and a blueprint describing the target operating model: the data-sharing architecture and standards (HL7 FHIR-based interoperability), the information-governance framework, the consent model, and the redesigned clinical workflows.

The work is organized into tranches. Tranche one connects two willing acute trusts and delivers a read-only record, a deliberate quick win that proves the approach and lets the board demonstrate an early benefit — a measurable reduction in duplicated tests — to build confidence. At the tranche-one review, the board learns that clinician adoption lags where the record is buried in an extra login, so it adjusts the blueprint to prioritize single-sign-on integration before widening rollout.

Underneath the program, the modes coexist. The interoperability platform is run by a durable product team (Topic 5.0) that keeps improving it across the whole program and beyond. Each trust's connection is a bounded project (Topic 5.1) with its own business case and go-live. The program itself coordinates the blueprint, the standards, the interdependencies, and — through the BCMs — the benefits realization. When the blueprint is achieved and duplicated-testing and delayed-discharge benefits are flowing, the program closes; the platform product team endures, and benefit tracking continues into business-as-usual.

Sector lenses#

Startup#

Few startups run programs in the MSP sense — they lack the multi-organization scope that defines one — but a scale-up deploying across several trusts effectively becomes a program participant. Its realistic role is as a supplier inside someone else's program: aligning its product to the program blueprint, hitting tranche milestones, and feeding the benefits case that the SRO must evidence. Funding and survival depend on the program continuing, so the startup treats tranche reviews as existential go/no-go points and invests in the business change managers' success, because adoption on the ground is what renews its contract. The discipline it must borrow is benefits language — framing its value as realized outcomes, not features shipped.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, or a small health-tech supplier past the startup stage — almost never runs a program, but is routinely swept into one as an affected participant when an ICS rolls out a shared care record or converges systems across the patch. Its practical concern is the seam the program owns: it must adopt the mandated data standards, information-governance agreements, and consent model with thin or no dedicated IT capability and no slack to absorb workflow change, yet it carries the same legal duties as the large trusts around it. The most valuable relationship it has is with the business change manager for its locality, because a well-supported adoption — training, single-sign-on, a workflow that fits how the practice actually runs — is the difference between the program's benefit landing and the change being quietly worked around. Its realistic ask of the program is proportionate support and sequencing that does not assume enterprise-scale resources, and its honest contribution is early, frank feedback at tranche reviews about what is unworkable on the ground.

Enterprise#

An ICS or large trust is the natural home of program-led work: shared care records, EPR convergence, and pathway transformation are inherently multi-organization and multi-year. The hard part is authority — the SRO must make decisions stick across sovereign partner organizations that cannot simply be ordered, so a genuinely representative program board and business change managers embedded in each partner are load-bearing, not decorative. Funding is blended (system transformation money, trust capital, national allocations), which makes the benefits map and tranche reviews essential for defending continued investment to system leaders and regulators. The recurring risk at this scale is output theater: technical delivery with no one accountable for turning it into benefit.

Government#

At national scale, programs carry the heaviest governance — they typically enter the Government Major Projects Portfolio, undergo Infrastructure and Projects Authority assurance and gateway reviews, and answer to ministers, the Public Accounts Committee, and the National Audit Office. The SRO is personally and publicly accountable for benefits realization across the whole system, and blueprints must reconcile national standards (interoperability, information governance, the NHS App as a common front door) with local autonomy. Funding runs through multi-year Spending Review settlements, so tranching and benefits evidence are the mechanism for sustaining or halting investment across fiscal and political cycles. The stakes are population-scale: a national program's benefits — or its failure — are measured in millions of patients and billions of pounds.

Common failure modes#

• Output theater. The program delivers technical outputs but no one owns turning them into benefits, so nothing changes for patients. Fix: benefits maps with owners, and BCMs in the operational business.
• A program that is just a big project. Fixed-scope, output-focused governance applied to genuinely uncertain, multi-organization change. Fix: manage by outcomes/benefits and tranches, not a single frozen plan.
• A powerless SRO. Accountability without authority to decide across boundaries. Fix: appoint an SRO senior enough to make cross-system decisions stick, backed by a representative board.
• No blueprint / target state. Projects optimize locally and the pieces never cohere. Fix: define and maintain a POTI blueprint everything steers toward.
• Big-bang instead of tranches. All the risk deferred to one late delivery. Fix: tranche the work, bank early benefits, and re-plan at review points.
• Program that never closes. It becomes a permanent bureaucracy long after the change is embedded. Fix: close deliberately, hand enduring services to product teams, keep tracking benefits in BAU.

Maturity model#

Checklist#

• Is this genuinely multi-project, multi-organization change toward one strategic outcome?
• Is there a clear vision and a concrete blueprint (target operating model / POTI)?
• Is there a benefits map linking outputs to measurable, owned, baselined benefits?
• Is the work structured into tranches with real continue/adjust/stop review points?
• Is there an empowered SRO with authority to decide across organizational boundaries?
• Does the program board genuinely represent the affected organizations?
• Are business change managers embedded in the operational business to own adoption?
• Are cross-cutting standards, interdependencies, and shared risks managed at program level?
• Do product-led, project-led, and program-led modes coexist with clear roles (Topics 5.0–10)?
• Is there a deliberate close, with enduring services handed to durable product teams and benefits tracked into BAU?

Key sources#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): principles, themes, and the transformational flow (including blueprint, tranches, benefits management, and the SRO/BCM roles).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — guidance on major programmes, SRO accountability, and assurance/gateway reviews.
• HM Treasury — The Green Book and benefits-management guidance (appraisal and evaluation of benefits).
• AXELOS — Management of Portfolios (MoP), for positioning programmes within a portfolio (see Topic 5.3 — EPPM).
• NHS England — guidance on integrated care systems and shared care records (interoperability, HL7 FHIR standards) for the domain context.
• Mik Kersten — Project to Product, for the shift from output-based to outcome/benefit-based investment.

References#

1. Program management — Wikipedia — https://en.wikipedia.org/wiki/Program_management
2. Benefits realisation management — Wikipedia — https://en.wikipedia.org/wiki/Benefits_realisation_management
3. Target operating model — Wikipedia — https://en.wikipedia.org/wiki/Target_operating_model
4. Executive sponsor (Senior Responsible Owner) — Wikipedia — https://en.wikipedia.org/wiki/Executive_sponsor
5. Integrated care system — Wikipedia — https://en.wikipedia.org/wiki/Integrated_care_system
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
9. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
10. Stakeholder management — Wikipedia — https://en.wikipedia.org/wiki/Stakeholder_management
11. Managing Successful Programmes (MSP): principles, themes, and the transformational flow — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/MSP-1006
12. Guidance on major programmes, SRO accountability, and assurance/gateway reviews — Cabinet Office / Infrastructure and Projects Authority — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
13. The Green Book and benefits-management guidance — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
14. Management of Portfolios (MoP) — AXELOS / PeopleCert — https://www.peoplecert.org/
15. Integrated care systems and shared care records (interoperability, HL7 FHIR standards) — NHS England — https://www.england.nhs.uk/integratedcare/
16. Project to Product — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/