Cross-Programme Dependency Orchestration

The Cross-Programme Challenge

Within a programme, the Programme Manager has authority to resolve dependencies — they can reprioritise projects, reallocate resources, and make trade-off decisions. Cross-programme dependencies are different: you have no authority over the other programme. Resolution requires negotiation, escalation, and influence.

Cross-programme dependencies typically arise from:

• Shared platforms or infrastructure (multiple programmes depend on the same platform team)
• Shared data or APIs (one programme produces data another consumes)
• Shared resources (specialists allocated across programmes)
• Sequential delivery (Programme B can't start until Programme A delivers a capability)
• Regulatory alignment (multiple programmes must comply with the same deadline)

Identification and Classification

Where to Look

• PI Planning events: Cross-programme dependencies surface when teams plan together
• Architecture reviews: System integration points create technical dependencies
• Resource planning: Shared specialists create resource dependencies
• Roadmap alignment: Sequential delivery creates timeline dependencies
• Vendor contracts: Shared vendors create commercial dependencies

Classification

Type 1 — Technical: Programme A's API must be available for Programme B's integration. Resolution: interface agreement, contract testing, parallel development.

Type 2 — Resource: Both programmes need the same DBA for 3 weeks. Resolution: sequencing, part-time allocation, hiring, or upskilling.

Type 3 — Timeline: Programme B can't start Phase 2 until Programme A completes Phase 1. Resolution: sequencing, parallel work with assumptions, or scope adjustment.

Type 4 — Data: Programme A produces the dataset Programme B needs. Resolution: data contract, interim data provision, or synthetic data for development.

Type 5 — Decision: Programme B needs a strategic decision that Programme A's steering committee controls. Resolution: escalation to portfolio level, joint steering session.

The Orchestration Model

The Dependency Register

Maintain a cross-programme dependency register visible to all affected programmes:

• ID and description: What's needed, specifically
• Provider programme and owner: Who delivers it
• Consumer programme and owner: Who needs it
• Due date: When it's needed
• Confidence (RAG): Current status
• Mitigation: What happens if it's late
• Escalation path: Who resolves if it fails

The Cross-Programme Sync

Frequency: Fortnightly (or weekly for critical-path dependencies) Attendees: Programme Managers from all affected programmes + portfolio representative Format: 1. Walk the dependency register (Red → Amber → Green) 2. For each at-risk item: what's blocking? What's the plan? Who owns resolution? 3. New dependencies identified 4. Escalations to portfolio level

The Escalation Framework

When cross-programme dependencies can't be resolved between Programme Managers:

Level 1: Direct conversation between Programme Managers. Most dependencies resolve here with goodwill and creative problem-solving.

Level 2: Joint steering session. Both programmes' sponsors discuss the trade-off and agree a resolution.

Level 3: Portfolio-level decision. When the trade-off affects strategic priorities, the portfolio board decides which programme takes priority.

The key principle: Escalation is not failure. It's the governance system working as designed. Escalate early when you can't resolve — don't let dependencies fester.

Resolution Strategies

Eliminate the Dependency

The best dependency is one that doesn't exist. Can the consuming programme:

• Build the capability themselves? (Duplication cost vs dependency risk)
• Use an alternative approach that doesn't require the other programme's output?
• Redesign the architecture to decouple the systems?

Sequence the Work

If Programme A must deliver before Programme B can proceed:

• Agree a firm delivery date with Programme A (with consequences for missing it)
• Build buffer into Programme B's plan (don't plan to start the day after A delivers)
• Define a "minimum viable" delivery from A that unblocks B (not the full scope)

Parallel with Contract

Both programmes work simultaneously against an agreed interface contract:

• Define the interface specification (API contract, data schema, event format)
• Both programmes develop against the contract independently
• Integration testing validates compatibility at agreed intervals
• Risk: contract changes require renegotiation and potential rework

Accept and Buffer

When elimination and parallelisation aren't possible:

• Acknowledge the dependency explicitly
• Add buffer time to the consuming programme's plan
• Monitor the providing programme's progress closely
• Have a contingency plan if the dependency fails (what's Plan B?)

Measuring Cross-Programme Dependency Health

• Dependency count: Total active cross-programme dependencies. Trend should be stable or decreasing.
• On-time delivery rate: % of dependencies delivered by the agreed date. Target: >85%.
• Escalation rate: % of dependencies requiring portfolio-level escalation. Target: <15%.
• Resolution time: Median days from dependency identified to resolved. Target: within one PI/quarter.
• Impact of failed dependencies: Delivery delays caused by cross-programme dependency failures. Target: <5% of programme milestones.

---

Download the [Dependency Matrix template](/templates) to track cross-programme dependencies with RAG status and escalation paths.