10.1 Process 4: Deliver the Capabilities

10.1 Process 4: Deliver the Capabilities

[!NOTE] Core MSP Lifecycle Definition: In Managing Successful Programmes (MSP) 5th edition, Deliver the Capabilities is the fourth lifecycle process. Following the baselining of the Delivery Plan and tranche authorization in Process 3, Process 4 coordinates the actual execution of constituent projects and work packages to construct, integrate, and verify the specialist deliverables required to create new organizational capabilities.

Transformational programmes do not deliver strategic outcomes through executive declarations or architectural diagrams alone. At some point, the strategic vision and Target Operating Model (TOM) must be translated into tangible technical, physical, and organizational assets. This execution phase occurs within Process 4: Deliver the Capabilities.

Process 4 represents the primary delivery engine of the programme lifecycle. It bridges the gap between detailed planning and operational business change. While constituent projects focus on building specific specialist outputs, Process 4 ensures that these diverse projects operate as an integrated ecosystem, delivering coherent capabilities that fit seamlessly into business operations.

---

Purpose and Scope of Deliver the Capabilities

The primary purpose of Process 4 is to govern, direct, orchestrate, and oversee the initiation, execution, and delivery of constituent projects and work packages that produce the project outputs required to create new organizational capabilities.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     PURPOSE & BOUNDARIES OF PROCESS 4                       │
├─────────────────────────────────────────────────────────────────────────────┤
│  Input: Baselined Delivery Plan & Tranche Authorization       │
│  Core Activities:                                                           │
│    - Commissioning projects & work packages from the Delivery Plan       │
│    - Orchestrating multi-project delivery cadences & milestones             │
│    - Managing inter-project dependencies & technical interfaces             │
│    - Resolving cross-project resource contention & aggregated risks         │
│    - Conducting quality verification & end-to-end integration testing       │
│  Output: Formally verified capabilities handed over to BCMs for transition  │
└─────────────────────────────────────────────────────────────────────────────┘

The Foundational Distinction: Outputs vs. Capabilities

A central tenet of MSP 5th edition is the distinction between a project output and an organizational capability:

• Project Output: A tangible or intangible specialist product produced by a single project (e.g., a relational database schema, a newly constructed warehouse facility, an updated HR policy document, or a software microservice).
• Organizational Capability: The completed, collective ability of an organization to execute a business function or operational activity. A capability rarely emerges from a single project output; it requires synthesizing technical deliverables from multiple projects with retrained personnel, reconfigured business processes, data structures, and physical facilities.

┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│ Project Alpha   │       │ Project Beta    │       │ Project Gamma   │
│ Output: Cloud   │       │ Output: Mobile  │       │ Output: Standard│
│ Core Database   │       │ Banking App UI  │       │ Operating Proc. │
└────────┬────────┘       └────────┬────────┘       └────────┬────────┘
         │                         │                         │
         └────────────────►  SYNTHESIS  ◄────────────────────┘
                                   │
                                   ▼
                  ┌─────────────────────────────────┐
                  │    ORGANIZATIONAL CAPABILITY    │
                  │ Real-Time Omnichannel Customer  │
                  │ Digital Self-Service Banking    │
                  └─────────────────────────────────┘

Scope Boundaries of Process 4

Process 4 encompasses all activities required to move from an authorized Project Brief in the Delivery Plan to a verified capability ready for operational cutover. However, Process 4 does not include running operational business-as-usual (BAU) or harvesting long-term strategic benefits. Its boundary ends when the delivered capability is formally accepted by the Business Change Manager (BCM) to commence operational transition.

---

The Orchestration Role of the Programme Manager

In MSP governance, the Programme Manager is the operational director of Process 4. While Project Managers manage individual project teams, the Programme Manager acts as the enterprise conductor, ensuring that all constituent projects advance in harmony.

                     ┌──────────────────────────────────────────────┐
                     │       SENIOR RESPONSIBLE OWNER (SRO)         │
                     │  - Holds ultimate accountability for delivery│
                     │  - Re-allocates tranche budgets & capital    │
                     │  - Resolves escalated programme-level issues │
                     └──────────────────────┬───────────────────────┘
                                            │ Directs & Empowers
                                            ▼
                     ┌──────────────────────────────────────────────┐
                     │              PROGRAMME MANAGER               │
                     │  - Orchestrates multi-project delivery       │
                     │  - Controls cross-project critical path      │
                     │  - Manages technical interfaces & dependencies│
                     │  - Receives outputs & conducts verification  │
                     └──────────────────────┬───────────────────────┘
                                            │ Commissions & Coordinates
         ┌──────────────────────────────────┼──────────────────────────────────┐
         ▼                                  ▼                                  ▼
┌─────────────────┐                ┌─────────────────┐                ┌─────────────────┐
│ PROJECT MANAGER │                │ PROJECT MANAGER │                │ PROJECT MANAGER │
│ (Core Platform) │                │ (Front-End App) │                │ (Change & Proc) │
│ - Manages sprints│                │ - Manages vendor│                │ - Manages SOPs  │
│ - Reports status│                │ - Reports status│                │ - Reports status│
└─────────────────┘                └─────────────────┘                └─────────────────┘

Programme Manager vs. Project Manager in Process 4

Key Orchestration Mechanisms

• Highlight Reporting: The Programme Manager reviews regular Highlight Reports from Project Managers to evaluate milestone health, burn rates, and emerging risks.
• Exception Management: When a project exceeds its agreed tolerances for cost, time, scope, or quality, the Project Manager submits an Exception Report. The Programme Manager determines whether the exception can be absorbed within programme tolerances or must be escalated to the SRO.
• Resource Arbitration: When multiple projects compete for scarce enterprise resources (e.g., lead cloud architects, cybersecurity penetration testers, or specialized testing laboratories), the Programme Manager arbitrates priorities based on the cross-project critical path.

---

Initiating Projects and Work Packages from the Delivery Plan

Projects are not commissioned all at once upon programme inception. In accordance with progressive delivery and rolling-wave planning, Process 4 executes staged project commissioning.

The Delivery Plan in Action

The Delivery Plan baselined in Process 3 serves as the definitive master catalog. In Process 4, the Programme Manager activates individual initiatives from the delivery plan by:

1. Issuing Project Mandates and Briefs: Formally defining the scope boundaries, required outputs, acceptance criteria, allocated budgets, and delivery timescales for each project.
2. Appointing Project Managers: Assigning qualified project leaders and establishing formal reporting cadences.
3. Establishing Delivery Tolerances: Setting specific tolerances for cost, time, quality, scope, risk, and benefits within which the Project Manager can operate autonomously.
4. Aligning Delivery Lifecycles: Operationalizing the Delivery Approach defined in Process 3. A digital customer experience project may be commissioned using two-week Agile Scrum sprints, while a physical data center construction project is commissioned using linear, gated engineering stages. The Programme Manager aligns their disparate release schedules into unified programme milestone gates.

---

Maintaining Alignment: From Project Outputs to Organizational Capabilities

A persistent risk in large-scale transformations is project drift or "siloed optimization," where project teams focus so narrowly on internal technical specifications that their finished outputs fail to assemble into a viable operational capability.

The Role of the Target Operating Model (TOM)

To maintain delivery alignment, the Programme Manager continuously references the seven facets of the Target Operating Model (TOM) baselined in Process 2:

1. Processes: Ensuring project outputs integrate into end-to-end operational workflows rather than creating disconnected process fragments.
2. Culture: Verifying that operational protocols, incentives, and management routines reinforce the target behaviours.
3. Organization: Aligning outputs with new business unit structures, roles, and reporting lines.
4. Technology: Enforcing enterprise architecture standards, interface protocols, and cyber-security baselines.
5. Infrastructure: Confirming that buildings, depots, plant, fleets, and network estate are ready to host the delivered capability.
6. Information and data: Ensuring that data models, master data standards, and telemetry pipelines match enterprise data architecture.
7. Knowledge and learning: Verifying that training collateral, role competencies, and standard operating procedures (SOPs) accompany physical or software deliverables.

When a Project Manager requests a scope reduction to meet a delivery deadline, the Programme Manager evaluates the impact on the overarching capability: If Project Alpha drops automated data validation, will the operational business unit still be able to achieve the target processing speed? If not, the scope reduction is rejected or escalated.

---

Managing Dependencies, Cross-Project Risks, and Technical Interfaces

Process 4 requires sophisticated systems thinking to manage complex interrelationships across projects, suppliers, and operational units.

┌─────────────────────────────────────────────────────────────────────────────┐
│                   CROSS-PROJECT DEPENDENCY & INTERFACE MATRIX               │
├─────────────────────────────────────────────────────────────────────────────┤
│  [Project Alpha: Core Cloud API]                                            │
│         │                                                                   │
│         ├──────────► Predecessor Dependency (Data Contract API v2.4)        │
│         ▼                                                                   │
│  [Project Beta: Mobile App Redesign] ◄─── Technical Interface Agreement     │
│         │                                                                   │
│         ├──────────► Cross-Project Critical Path (End-to-End Testing)        │
│         ▼                                                                   │
│  [Project Gamma: Staff Operations Portal]                                   │
│         ▲                                                                   │
│         └─────────── Aggregated Risk: Shared Third-Party Security Auditor   │
└─────────────────────────────────────────────────────────────────────────────┘

1. Inter-Project Dependencies

Dependencies dictate the sequence of execution across constituent projects:

• Technical Dependencies: Where an output from Project A is a technical prerequisite for Project B (e.g., the security token service must be deployed before the mobile customer app can execute user authentication).
• Temporal Dependencies: Where delivery schedules are linked to avoid operational chaos (e.g., physical facility renovations must finish before server racks are installed).
• Resource Dependencies: Where multiple projects rely on the same internal team or external vendor (e.g., specialized data migration engineers).

2. The Cross-Project Critical Path

The Programme Manager maintains the cross-project critical path—the continuous chain of dependent project activities that determines the earliest possible completion date for the tranche. A one-week slippage on a non-critical project can be absorbed, but a 48-hour delay on a critical-path project immediately delays overall capability delivery and subsequent operational transition.

3. Cross-Project and Aggregated Risks

Projects identify localized risks, but the Programme Manager monitors aggregated risks:

• Supplier Concentration: Five separate projects may independently contract with the same specialized engineering vendor. While each project considers its vendor risk low, the programme faces massive systemic risk if that vendor encounters solvency or capacity constraints.
• Interface Integration Failures: Risk that disparate software modules, developed by different teams or vendors, fail to interoperate during end-to-end integration testing.

4. Technical Interface Agreements

To prevent integration failures, the Programme Manager enforces formal Interface Agreements between project teams. These documents specify data exchange formats, API schemas, network latency thresholds, and error codes. Neither team is permitted to alter an interface contract without formal programme change control.

---

Receiving Project Deliverables, Quality Verification, and Acceptance

As constituent projects conclude their development cycles, the Programme Manager oversees a disciplined quality verification process to transition outputs into validated capabilities.

┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│ 1. Project-Level│       │ 2. Programme    │       │ 3. User & Operational
│ Output Delivery │──────►│ Integration     │──────►│ Acceptance      │
│ - Unit testing  │       │ Testing         │       │ Testing (UAT)   │
│ - Defect triage │       │ - End-to-end API│       │ - Business flow │
│ - Factory accept│       │ - System perf.  │       │ - Operational SLA
└─────────────────┘       └─────────────────┘       └────────┬────────┘
                                                             │
                                                             ▼
                                                    ┌─────────────────┐
                                                    │ 4. Capability   │
                                                    │ Acceptance Sign-│
                                                    │ Off by BCM      │
                                                    └─────────────────┘

The Multi-Stage Verification Funnel

1. Project Output Quality Verification: Project teams verify individual components against their Project Product Descriptions and quality criteria.
2. Programme Integration & Systems Testing: Disparate deliverables are assembled in a staging environment. The programme integration team verifies that hardware, software, data pipelines, and security protocols function cohesively under realistic operational loads.
3. User Acceptance Testing (UAT) & Operational Dry-Runs: Frontline operational staff and Business Change Managers evaluate the integrated capability against real-world business scenarios, validating that operating procedures, training guides, and system workflows match operational requirements.
4. Defect Triage & Technical Debt Governance: If defects are discovered, the Programme Manager determines whether they must be resolved before handover or can be classified as acceptable technical debt to be resolved in a subsequent minor release.

---

Formal Handover of Capabilities to the Business Change Manager (BCM)

Process 4 culminates in a critical governance gateway: the formal handover of completed capabilities from the delivery organization to the operational business change organization.

[!IMPORTANT] The Handover Custody Transfer: Capabilities are not handed over directly to general end-users or frontline operational staff. In MSP 5th edition, the Programme Manager formally transfers custody of the verified capability to the Business Change Manager (BCM). The BCM serves as the formal operational recipient representing business-as-usual (BAU).

Mandatory Handover Deliverables

A capability handover is never purely technical. The handover package transferred to the BCM includes:

• Validated Technical & Physical Assets: Production-ready software systems, configured cloud environments, physical equipment, or renovated facilities.
• Operational Documentation: Standard Operating Procedures (SOPs), process workflows, service desk runbooks, and exception-handling escalation matrices.
• Training & Skills Collateral: Staff training modules, competency evaluation checklists, role certifications, and job aids.
• Support & Commercial Agreements: Third-party vendor maintenance contracts, operational service level agreements (SLAs), and warranty coverage.
• Known Issues & Defect Log: Transparent documentation of minor residual defects and agreed workarounds.

The Handover Agreement

The formal handover is documented in a Handover Agreement co-signed by the Programme Manager and the Business Change Manager. By signing, the BCM confirms that the capability meets the Target Operating Model specifications and is accepted into business custody for operational transition.

---

Real-World Organizational Transformation Scenario

ApexPay Global FinTech Neobank: Core Banking Modernization

Context: ApexPay, a fast-growing digital neobank with 6 million active customers, embarked on a multi-year programme to replace its third-party legacy core banking ledger with an in-house, real-time distributed microservices architecture.

Executing Process 4 (Deliver the Capabilities):

• Commissioning Constituent Projects: The Programme Manager activated four projects from the Delivery Plan:
  • Project Alpha (Ledger Engine): Built the high-throughput cloud ledger using Rust (Agile linear hybrid).
  • Project Beta (Mobile App & UX): Redesigned the customer-facing mobile application interface (Agile Scrum).
  • Project Gamma (Real-Time AML & Fraud): Deployed AI-driven transaction monitoring algorithms (Agile Kanban).
  • Project Delta (Operational Readiness & Support): Developed operations manuals, customer service triage playbooks, and staff training curricula (Linear Waterfall).
• Managing Critical Dependencies: Project Beta (Mobile App) and Project Gamma (Fraud) were technically dependent on Project Alpha's API endpoints. When Project Alpha encountered a two-week delay due to database sharding complexities, the Programme Manager intervened: mock API stubs were deployed so Beta and Gamma could continue front-end development without stalling the cross-project critical path.
• Arbitrating Resource Contention: Both Project Alpha and Gamma required the bank's top cybersecurity penetration tester. The Programme Manager prioritized Project Alpha to ensure foundational ledger security was locked before testing transaction monitoring.
• Quality Verification & Handover: After extensive end-to-end integration testing in a staging environment simulating 15,000 transactions per second, the Programme Manager convened the formal handover gate. The Business Change Manager for Retail Banking reviewed the UAT results, customer service SOPs, and training completion rates, formally signing the Handover Agreement to take custody of the new digital banking capability.

---

Exam Tips & Common Traps

• Exam Tip (The Handover Recipient): If an exam question asks who formally receives completed capabilities from the delivery team, the correct answer is always the Business Change Manager (BCM), not the SRO, not the corporate board, and not individual operational end-users.
• Exam Tip (Orchestration vs. Management): The Programme Manager orchestrates and coordinates project delivery; individual Project Managers manage day-to-day project activities and specialist teams.
• Common Trap (Output vs. Capability): Do not confuse a project output with a capability. A single software application delivered by a project is an output. It becomes a capability only when combined with trained personnel, documented operating processes, and necessary infrastructure.
• Common Trap (Direct BAU Management): A common exam distractor suggests that the Programme Manager assumes direct operational command of business-as-usual during Process 4. This is completely false. Business-as-usual operations remain under the operational authority of line managers and BCMs; the Programme Manager governs transformational delivery.