6.2 The Programme Plans & the Delivery Plan

6.2 The Programme Plans & the Delivery Plan

[!NOTE] What changed in the 5th edition: MSP 4th edition maintained a programme plan, a projects dossier, a resource management plan, and an information management plan as separate products. MSP 5th edition consolidated all four into a single delivery plan, which is one of the five programme plans. If an exam option refers to a "projects dossier" or a standalone "programme plan", it is using superseded 4th edition terminology.

Executing transformational change requires balancing strategic direction with ground-level delivery discipline. When a programme coordinates ten or twenty concurrent projects alongside extensive organizational redesign, leadership faces two constant dangers:

1. Loss of integrated control — projects operate in technical silos, completing their deliverables on schedule but misaligned with operational transition windows or dependent systems.
2. Micro-management paralysis — the programme office attempts to control every task and sprint of every project, generating unmaintainable scheduling overhead and destroying project manager autonomy.

MSP resolves this through planning at the right altitude: the delivery plan schedules the programme's work, and project-level plans schedule the projects' work.

---

The Five Programme Plans

The plans are developed during design the outcomes, validated and completed during plan progressive delivery, and revisited at every tranche boundary. They are baselined together because a change to one moves the others: pulling a tranche forward changes the financial plan's drawdown profile and the benefits realization plan's measurement dates.

---

The Delivery Plan

The delivery plan is the definitive operational baseline used by the programme manager to coordinate delivery and by the SRO to monitor progress against corporate strategy. It is not a Gantt chart of engineering tasks; it is the programme-level schedule that integrates technical delivery with business change and value harvesting.

┌─────────────────────────────────────────────────────────────────────────────┐
│                             THE DELIVERY PLAN                               │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. TRANCHES & LANDING POINTS : Tranche 1 ──► Tranche 2 ──► Tranche 3       │
│  2. PROJECTS & OTHER WORK     : Project A (build) ──► Project B (integrate) │
│  3. BUSINESS CHANGE           : Readiness ──► Workflow redesign ──► Cutover │
│  4. DEPENDENCIES              : Internal, external, and operational links   │
│  5. CRITICAL PATH             : Integrated inter-project dependency sequence│
└─────────────────────────────────────────────────────────────────────────────┘

Contents of the delivery plan

1. The tranche structure and landing points. Start dates, durations, and the stable operating state the organization will occupy at the end of each tranche, together with the review boundary at which continued investment is confirmed.
2. The projects and other work. Every project and every non-project work stream commissioned by the programme, with its purpose, its contribution to the target operating model, and its position in the tranche structure. "Other work" is not an afterthought: stakeholder roadshows, union consultation, reskilling, dual-running, and legacy decommissioning are scheduled here, not left to chance.
3. Sequencing and dependencies. Internal dependencies between the programme's own projects, external dependencies on work outside the programme's authority, and operational dependencies on business as usual.
4. The cross-project critical path. The continuous sequence of dependent deliverables and transitions that dictates the earliest achievable end of a tranche.
5. Resource commitments. Which scarce specialist skills and shared assets are required, when, and by whom — the material formerly held in the 4th edition resource management plan.
6. Transition and cutover windows. Including operational blackout periods when the business cannot absorb a cutover (financial year end, peak trading, statutory reporting).

---

Factors to Consider When Planning Programme Delivery

The syllabus asks specifically about the factors to be considered when planning delivery. These are the constraints that decide the shape of the tranche structure before any date is entered:

• Organizational capacity and organizational ability. How much change the business can absorb alongside business as usual, and how well it can absorb it. This sets the ceiling on pace.
• Dependencies. Especially external ones, which the programme cannot control and must therefore either de-risk or plan around.
• Resource availability. Scarce specialist skills, shared infrastructure, and the lead times to acquire either.
• The funding profile. When money is actually released. A tranche cannot start before its funding gate, regardless of technical readiness.
• Risk. High-uncertainty work is often placed early so that the programme learns cheaply, while high-impact irreversible steps are deferred until the design is proven.
• Benefits. Early tranches are frequently shaped to deliver measurable benefit early, both to fund later tranches and to sustain sponsorship.
• Assurance and decision windows. Reviews and gates must be scheduled into the plan, not bolted on afterwards.
• The operating calendar. Statutory deadlines, regulatory cut-offs, seasonal peaks, and blackout windows.
• Delivery mode. Whether each piece of work is linear, iterative, hybrid, or continual improvement, because that determines how often the business is asked to change.

---

Programme-Level Planning vs. Project-Level Plans

A central principle of MSP governance is a clean separation of concerns between project execution and programme steering.

• Project managers are accountable for managing day-to-day delivery. They maintain detailed stage plans, product breakdown structures, sprint backlogs, and work package allocations, bounded by their agreed tolerances.
• The programme manager is accountable for orchestrating the collective transformation, tracking milestone interfaces, cross-project dependencies, contention, and alignment with business change schedules — not directing daily tasks inside projects.

Handling schedule variance and ripple effects

1. Within project tolerance. If the delay can be absorbed within the project's own float without breaching agreed tolerances or milestone dates, the project manager manages it locally.
2. Exceeding project tolerance. The project manager raises an exception to the project board and alerts the programme manager.
3. Programme-level impact assessment. The programme manager assesses the ripple effect against the baselined delivery plan: is the delay on the programme critical path? Does it break an internal dependency? Does it collide with a change blackout window or a training schedule? Does it threaten the tranche boundary?
4. Corrective steering. If the delivery plan baseline is threatened, the programme manager re-levels resources, uses contingency, re-sequences work, or escalates to the SRO.

---

Real-World Organizational Transformation Scenario

Metropolitan Transit Authority (MTA) Smart Mobility Transformation

Context: The MTA launched a transformation to modernize regional public transport across commuter rail, subway, and bus networks.

Projects and other work in the delivery plan:

• Project 1 (Fare gates): Upgrading 800 station turnstiles with contactless readers.
• Project 2 (Cloud ticketing engine): Modernizing core billing, mobile ticketing, and account databases.
• Project 3 (Bus fleet telemetry): Installing cellular routers and tap sensors across 1,500 buses.
• Project 4 (Station kiosks): Deploying accessibility kiosks.
• Other work A: Training 2,500 station agents and bus operators on new customer protocols.
• Other work B: Public campaign on mobile ticketing adoption.
• Other work C: Decommissioning magnetic paper ticket machines.

The governance test: In month 8, Project 3 slipped six weeks because of a semiconductor shortage. Reading the delivery plan, the programme manager established that Project 3 was not on the critical path for the Tranche 1 subway landing point, but that its slip overlapped the union-negotiated driver training window. The programme manager moved the bus launch into Tranche 2, protected the Tranche 1 boundary, re-sequenced the training work, and preserved the planned $12M fare-evasion benefit. The financial plan and benefits realization plan were re-baselined at the same time.

---

Exam Tips & Common Traps

• Exam tip (five plans, twelve approaches): Know the five programme plans by name. If a question offers a "resource management plan", an "information management plan", or a "projects dossier" as an answer, those are 4th edition products absorbed into the delivery plan.
• Exam tip (the plan's unique scope): An MSP delivery plan uniquely includes business change activities, transition windows, and the tranche structure alongside project schedules. A schedule that covers only technical outputs is not a delivery plan.
• Common trap (the mega-Gantt fallacy): A frequent distractor suggests the programme manager should import every work package from every project into one enormous schedule. The delivery plan works at the level of milestone interfaces, dependencies, and transition windows, preserving project-level autonomy.
• Common trap (delivery plan vs. business case): The business case justifies the investment (benefits and dis-benefits against costs and risks). The delivery plan schedules the work that delivers it. They are re-baselined together but answer different questions.