6.1 Structure Theme & Delivery Strategies

6.1 Structure Theme & Delivery Strategies

[!NOTE] Core MSP Definition: The Structure theme in Managing Successful Programmes (MSP) 5th edition defines how the programme plans, organizes, and resources the delivery of capabilities and the realization of benefits. It establishes the organizational architecture, work breakdown, and governance mechanisms required to translate the Programme Vision Statement and Target Operating Model into managed operational realities.

Transforming an enterprise involves navigating significant strategic ambiguity, technical complexity, and cultural disruption. While the Vision Statement articulates the desired future state and the Design theme details the Target Operating Model (TOM), the programme leadership team must solve the pragmatic question of execution: How do we structure hundreds of interrelated activities, technical deliverables, and business transitions across multiple years so that value is steadily delivered without overwhelming operational capacity?

This is the explicit focus of the Structure theme. Rather than treating delivery as an undifferentiated, multi-year stream of work, MSP establishes structured governance frameworks—specifically the Delivery Approach, the Resourcing Approach, and the staging of work into Tranches—to maintain control, manage capital risk, and enable incremental benefits realization.

---

The Purpose of the Structure Theme in MSP 5th Edition

In MSP 5th edition, the Structure theme answers several fundamental governance questions that executive leadership and programme boards must resolve before committing capital:

1. Structuring for Capability and Value: How should the total scope of transformational change be decomposed into coherent delivery packages (projects and operational change activities) that systematically build organizational capability?
2. Resourcing the Transformation: How will the programme secure, deploy, develop, and retain the necessary talent, funding, specialized tools, and external supplier partnerships without destabilizing business-as-usual (BAU)?
3. Managing Delivery Risk via Staging: How should delivery be phased over time to prevent catastrophic "all-or-nothing" failure, ensure continuous stakeholder alignment, and allow formal decision gates for continuing, adjusting, or terminating the investment?
4. Balancing Precision and Adaptability: How can planning provide the rigorous predictability demanded by financial sponsors while maintaining the flexibility to respond to shifting market, geopolitical, or technological realities?

By addressing these questions, the Structure theme provides the operational bridge connecting strategic intent with project execution and operational absorption.

---

Core Delivery Strategies: Delivery Approach and Resourcing Approach

During the early lifecycle stages (specifically within the Design the Outcomes process), the Programme Manager, under the direction of the Senior Responsible Owner (SRO), authors two foundational strategy documents that govern the Structure theme: the Delivery Approach and the Resourcing Approach.

                     ┌──────────────────────────────────────────────┐
                     │         Programme Vision & Strategy          │
                     └──────────────────────┬───────────────────────┘
                                            │
                                            ▼
                     ┌──────────────────────────────────────────────┐
                     │            MSP STRUCTURE THEME               │
                     │  "How we organize, schedule, and resource"   │
                     └──────────────┬────────────────┬──────────────┘
                                    │                │
                 ┌──────────────────┴──┐          ┌──┴──────────────────┐
                 │   Delivery Approach │          │ Resourcing Approach │
                 │   - Delivery models │          │ - Talent sourcing   │
                 │   - Release cadence │          │ - Capability gaps   │
                 │   - Tranche gating  │          │ - Funding models    │
                 └─────────────────────┘          └─────────────────────┘

1. The Delivery Approach

The Delivery Approach documents the overarching philosophy, methodologies, standards, and staging rules that will govern how project outputs are created and integrated. Key elements defined in the Delivery Approach include:

• Methodology Frameworks: Deciding where iterative/agile methods (e.g., Scrum, Kanban, SAFe) will be deployed (ideal for rapid software development, user interface design, and emerging customer journeys) versus where linear/predictive methods (e.g., PRINCE2, traditional engineering waterfalls) are required (essential for civil works, physical datacenter builds, and statutory regulatory filings).
• Packaging of Work: Establishing the criteria for grouping activities into distinct projects, temporary work streams, or procurement contracts. For instance, should a CRM overhaul be managed as a single mega-project or decoupled into database migration, interface design, and frontline training projects?
• Release and Integration Cadence: Defining how project outputs will be packaged and released into operational business environments (e.g., continuous deployment, quarterly software releases, or annual operational change windows).
• Quality and Acceptance Standards: Establishing enterprise-wide gateway criteria and technical compliance standards that every constituent project must satisfy before its outputs are accepted into business transition.

2. The Resourcing Approach

The Resourcing Approach defines how the programme will identify, acquire, deploy, and manage the assets needed to execute the Delivery Approach. Programmes consume immense organizational resources—not only financial capital, but scarce operational personnel, technical specialists, and external supplier capacity. Key elements include:

• Sourcing Strategy (Make vs. Buy): Establishing the balance between internal corporate personnel and external market engagement (contractors, management consultants, system integrators, managed service providers).
• Resource Governance & Allocation: Defining how resources will be allocated across competing projects, how contention will be arbitrated, and who holds commercial authority for hiring or procurement.
• Knowledge Transfer and Retention: Specifying mechanisms to ensure that specialized technical skills and operational knowledge built by external contractors during programme delivery are systematically transferred to permanent BAU staff before programme closure.
• Physical and Digital Assets: Defining requirements for specialized testing environments, temporary co-location facilities, tooling, licenses, and data pipelines.

---

The Concept and Function of Tranches

One of the most distinctive and powerful concepts in MSP 5th edition is the Tranche.

[!IMPORTANT] Definition of a Tranche: A tranche is a distinct, formal stage of programme delivery designed to group related projects and business change activities together to deliver a step-change in capability and enable the realization of a specific cohort of strategic benefits.

Tranches are fundamentally different from project stages. While a project stage in PRINCE2 focuses on delivering a set of technical deliverables within agreed cost and time tolerances, an MSP tranche encompasses the entire transformational journey for a defined phase of change:

1. Project Delivery: Designing and producing the required outputs (e.g., new software, physical assets, operational policies).
2. Business Change & Transition: Retraining staff, redesigning operational workflows, migrating data, and executing cutover into business-as-usual.
3. Operational Embedding: Stabilizing new operating procedures within BAU until the new way of working becomes routine.
4. Benefits Realization: Measuring and harvesting the early quantifiable performance improvements enabled by the new operational state.

                                [ TRANCHE BOUNDARY / REVIEW GATE ]
                                                 │
   ┌─────────────────────────────────────────────┴─────────────────────────────────────────────┐
   │                                                                                           │
   ▼                                                                                           ▼
[ TRANCHE 1: Foundation ]                                                   [ TRANCHE 2: Expansion ]
├── Project A (Output) ──┐                                                  ├── Project C (Output) ──┐
├── Project B (Output) ──┼──> [ Transition & BAU Embedding ] ──> [ Benefits ]├── Project D (Output) ──┼──> [ Transition... ]
└── Change Activities ───┘                                                  └── Change Activities ───┘

Tranche Review Gates

Tranches are separated by formal governance review gates (also termed end-of-tranche reviews or tranche boundary reviews). A tranche review gate is not a casual administrative update; it is an executive decision point presided over by the Senior Responsible Owner (SRO) and the Programme Board.

At each tranche review gate, programme leadership evaluates:

• Capability and Deliverable Verification: Were all project outputs delivered to required quality and acceptance criteria?
• Operational Transition Health: Has the business successfully absorbed the change, or is BAU experiencing unacceptable performance drops, employee turnover, or service disruption?
• Benefits Realization Progress: Have the planned intermediate benefits for this tranche been harvested and verified by the Business Change Managers (BCMs)?
• Continued Business Justification: Does the updated Programme Business Case still demonstrate a positive return on investment, acceptable risk exposure, and strategic alignment with evolving enterprise priorities?
• Next Tranche Authorization: Is the detailed plan for the subsequent tranche robust, fully resourced, and ready for baseline approval?

Based on this comprehensive evaluation, the SRO has three formal options at a tranche review gate:

1. Authorize: Formally approve the initiation of the next tranche and release associated tranche funding.
2. Adjust / Pause: Mandate corrective actions, re-baseline schedules, or temporarily pause delivery to allow operational business units time to stabilize and absorb recent changes.
3. Terminate: Recommend premature closure of the programme if strategic alignment has eroded, market conditions have made the business case unviable, or technical feasibility has collapsed.

---

Incremental Tranche-Based Delivery vs. Single Big-Bang Transformation

Historically, many large-scale corporate and governmental transformations failed because leadership adopted a "big-bang" mindset: spending three to five years developing massive monolithic systems in isolation, followed by a single enterprise-wide cutover date. MSP strongly advocates for incremental, tranche-based delivery to eliminate the catastrophic failure modes of big-bang initiatives.

---

Planning Horizons and Rolling-Wave Planning

In a multi-year programme, attempting to plan every single activity, sprint, and resource allocation for Year 4 during Day 1 is an exercise in futility. Requirements will change, technologies will evolve, and corporate strategies will pivot. MSP solves this reality through rolling-wave planning.

TODAY ───────────────────────────────────────────────────────────────────► FUTURE (3 Years)

[ Tranche 1: Active Execution ]    [ Tranche 2: Elaboration ]    [ Tranche 3: Directional Horizon ]
┌─────────────────────────────┐    ┌─────────────────────────┐    ┌────────────────────────────────┐
│ High Detail / Low Ambiguity │    │ Medium Detail           │    │ Low Detail / Strategic Vision  │
│ - Baselined work packages   │    │ - Project briefs        │    │ - Indicative milestones        │
│ - Named individual resources│    │ - Capacity forecasts    │    │ - Target capability themes     │
│ - Exact dependency networks │    │ - Outline dependencies  │    │ - Broad capital envelopes      │
└─────────────────────────────┘    └─────────────────────────┘    └────────────────────────────────┘
      ▲                                  ▲                                      ▲
      │                                  │                                      │
[ Near-Term Horizon ]             [ Medium-Term Horizon ]                [ Distant-Term Horizon ]

The Mechanics of Rolling-Wave Planning

Rolling-wave planning establishes multiple distinct planning horizons across the programme timeline:

1. The Near-Term Horizon (The Current Tranche):
   • Detail Level: High detail and firm baselines.
   • Characteristics: Constituent projects have fully approved project plans, named human resource assignments, definitive contracts, and precise inter-project dependency schedules. The Business Change Managers have established detailed operational readiness plans and transition schedules.
2. The Medium-Term Horizon (The Subsequent Tranche):
   • Detail Level: Medium detail and directional baselines.
   • Characteristics: Projects are documented as Project Briefs with defined scope boundaries, estimated durations, high-level resource capacity requirements, and identified external dependencies. As the current tranche nears its conclusion, this subsequent tranche is progressively elaborated into full operational detail.
3. The Distant Horizon (Future Tranches):
   • Detail Level: Low detail and strategic conceptualization.
   • Characteristics: Defined in terms of target operational capabilities, broad financial envelopes, and desired strategic outcomes aligned with the Target Operating Model. Precise project configurations remain flexible to allow for emerging solutions.

[!TIP] The Fallacy of False Precision: In the MSP exam, watch out for distractors claiming that a competent Programme Manager must deliver a 100% baselined, activity-level Gantt chart for the entire multi-year programme during programme design. MSP explicitly rejects this; doing so creates false precision, wastes immense planning hours, and builds governance inertia that resists necessary strategic adaptation.

---

Real-World Organizational Transformation Scenario

OmniBank Global Retail Transformation

Context: OmniBank, an international retail bank with 1,200 physical branches and 15 million customers, launched the "OmniBank 2030 Transformation Programme" to transition from a high-cost physical branch model to an agile, omnichannel digital-first bank.

The Strategy: Rather than attempting a single big-bang cutover, the SRO and Programme Manager structured the four-year programme into three distinct tranches:

• Tranche 1: Digital Core & Identity Foundation (Months 1–12):
  • Projects: Cloud-native customer identity engine, Core Mobile App 2.0 overhaul, and API security gateway.
  • Business Transition: Upskilling 500 digital customer service representatives and piloting self-service onboarding across 50 branches.
  • Tranche Review Gate 1: Validated that customer onboarding time dropped from 4 days to 8 minutes. SRO confirmed $18M in annualized branch operational savings, approving initiation of Tranche 2.
• Tranche 2: Smart Branch Hubs & Advisory Automation (Months 13–26):
  • Projects: Video banking kiosks, automated mortgage underwriting engine, and branch footprint downsizing (converting 400 branches to advisory kiosks).
  • Business Transition: Retraining 3,000 branch tellers as licensed financial wellness advisors and closing 300 redundant leases.
  • Tranche Review Gate 2: Validated a 35% increase in mortgage cross-selling and stable customer satisfaction scores. Business justification re-confirmed.
• Tranche 3: Open Banking Ecosystem & AI Wealth Management (Months 27–42):
  • Projects: Third-party fintech marketplace integration and generative AI portfolio assistant.
  • Business Transition: Full enterprise cultural embedding and continuous agile delivery handover to BAU product teams.

By utilizing tranches and rolling-wave planning, OmniBank captured $45M in net benefits before Tranche 3 even commenced, while de-risking the massive organizational redeployment of frontline staff.

---

Exam Tips & Common Traps

• Exam Tip (The Tranche Gate Imperative): On the MSP Foundation exam, remember that tranche boundaries are mandatory executive governance gates. A programme cannot simply drift from Tranche 1 into Tranche 2 without formal SRO authorization, a business case review, and benefits verification.
• Exam Tip (Rolling-Wave Rationale): When exam questions ask why rolling-wave planning is used, look for answers emphasizing managing uncertainty, preventing premature commitment, and progressively elaborating detail as information becomes reliable.
• Common Trap (Stage vs. Tranche): Do not confuse a project stage (PRINCE2) with a programme tranche (MSP). A stage delivers technical products/outputs under a Project Manager. A tranche groups multiple projects AND operational business change activities to deliver a capability step-change and harvest measurable benefits under the direction of the SRO and Programme Manager.
• Common Trap (Synchronous Delivery Myth): An exam question may falsely suggest that all projects within a tranche must start and finish simultaneously. In reality, projects within a tranche can run sequentially, overlap, or finish months apart, provided their outputs converge to enable the planned business transition window.