Managing Programme-Level RAID

Programme RAID vs Project RAID

Every project has its own RAID log managed by the Project Manager. The Programme Manager doesn't duplicate this — they manage a separate, higher-level RAID that captures:

• Risks that span multiple projects (e.g. a vendor failure affecting 3 projects simultaneously)
• Assumptions that underpin the programme (e.g. "the regulatory deadline won't change")
• Issues that require programme-level authority to resolve (e.g. resource conflicts between projects)
• Dependencies between projects (e.g. Project A's output is Project B's input)

The rule: if a risk, assumption, issue, or dependency can be resolved within a single project, it stays in that project's RAID. If it crosses project boundaries or requires programme-level authority, it escalates to the programme RAID.

Programme Risk Management

Risk Categories at Programme Level

• Strategic risks: Changes in business strategy that affect programme relevance
• Cross-project risks: Failures in one project that cascade to others
• Resource risks: Key skill shortages affecting multiple projects
• Vendor risks: Third-party failures with programme-wide impact
• Regulatory risks: Compliance changes affecting programme scope or timeline
• Integration risks: Combined outputs from multiple projects failing to work together
• Benefits risks: Conditions for benefit realisation not being met

Risk Scoring at Programme Level

Use the same probability × impact framework as project-level, but with programme-scale impact definitions:

• Impact 1 (Negligible): One project delayed by <1 sprint
• Impact 2 (Minor): One project delayed by 1-2 sprints, no budget impact
• Impact 3 (Moderate): Multiple projects affected, 5-10% budget impact
• Impact 4 (Major): Programme milestone missed, 10-20% budget impact
• Impact 5 (Critical): Programme objectives at risk, >20% budget impact or programme cancellation

The Programme Risk Review

Frequency: Fortnightly (aligned with steering committee cadence)

Process: 1. Review existing risks: has probability or impact changed? 2. Review project-level risks escalated to programme level 3. Identify new programme-level risks from delivery progress 4. Check mitigation action progress (are owners delivering?) 5. Prepare risk summary for steering committee

Programme Assumptions Management

Assumptions are the most neglected part of RAID. At programme level, unvalidated assumptions can invalidate entire projects:

Common programme assumptions:

• "The technology platform will support our scale requirements"
• "Users will adopt the new system within 3 months of launch"
• "The regulatory deadline is fixed and won't change"
• "Budget will be available for Phase 2 after Phase 1 completes"
• "Key vendor will remain commercially viable throughout the programme"

For each assumption:

• When will it be validated? (Specific date)
• How will it be validated? (What evidence confirms or refutes it?)
• What's the impact if it's wrong? (Which projects are affected? What's the contingency?)
• Who owns validation? (Named person with deadline)

The assumption validation cadence: Monthly, review all assumptions. Any assumption past its validation date without confirmation becomes a risk.

Programme Issues Management

Issues are risks that have materialised — they're happening now and need resolution.

Programme-level issues typically include:

• Resource conflicts between projects that PMs can't resolve
• Budget shortfalls requiring reallocation between projects
• Vendor performance failures affecting multiple projects
• Stakeholder conflicts requiring programme-level mediation
• Integration failures between project outputs

Issue resolution process: 1. Issue raised (by PM, stakeholder, or programme team) 2. Impact assessed (which projects affected? What's the delivery impact?) 3. Owner assigned (who will resolve? By when?) 4. Resolution options identified (with trade-offs) 5. Decision made (by Programme Manager or escalated to steering) 6. Resolution implemented and verified 7. Issue closed with lessons captured

The 5-day rule: Any programme-level issue without a resolution plan within 5 business days is automatically escalated to the steering committee.

Programme Dependencies

Cross-project dependencies are the Programme Manager's primary operational concern. They're the most common cause of programme-level delays.

Dependency tracking:

• Providing project and consuming project
• What's needed (specific deliverable, not vague "input")
• When it's needed (specific date or sprint)
• Current confidence (RAG)
• Owner on each side
• Escalation path if at risk

Dependency review: Weekly, as part of the programme sync. Any dependency that moves to Amber gets an immediate mitigation plan. Any that moves to Red gets escalated to steering.

Dependency reduction: The Programme Manager should actively work to reduce dependencies through:

• Architecture alignment (decoupling systems at project boundaries)
• Sequencing optimisation (reordering work to eliminate waiting)
• Interface agreements (allowing parallel work against agreed contracts)
• Team topology changes (restructuring teams to internalise dependencies)

The Programme RAID Dashboard

Present programme RAID in a single-page dashboard for steering:

• Risk heat map: Top 5 risks plotted on probability × impact grid
• Assumption status: Validated / Pending / Overdue counts
• Issue summary: Open issues by severity with age
• Dependency health: % Green / Amber / Red with trend
• Key actions: Top 5 actions due this fortnight with owners

Measuring Programme RAID Effectiveness

• Risk materialisation rate: % of identified risks that become issues. Target: <30% (good identification + effective mitigation)
• Issue resolution time: Median days from issue raised to resolved. Target: <10 business days
• Assumption validation rate: % of assumptions validated by their due date. Target: >80%
• Dependency on-time delivery: % of dependencies delivered when needed. Target: >85%
• RAID review attendance: Key stakeholders present at reviews. Target: >90%

---

Download the [Programme RAID Register template](/templates) for a comprehensive programme-level risk, assumption, issue, and dependency tracker.