Overview
Based on "The Phoenix Project" (Kim, Behr & Spafford) and "The Art of Project Management" (Scott Berkun). The core insight from Phoenix Project: most delivery failures are not surprise events - they are predictable patterns (unplanned work, single points of failure, technical debt accumulation) that were visible before the crisis but ignored. A risk review forces you to name these patterns before they explode. Berkun adds: the highest-risk part of any project is not the work - it is the assumptions baked into the plan.
Workflow
Step 1: Gather program context
Ask the user for:
- Program/release name and target date
- Team size and structure (how many teams, any new team members?)
- Key dependencies (external vendors, other teams, regulatory approvals)
- Known hotspots (legacy systems, areas of high technical debt, frequently changed code)
Step 2: Run the risk identification sweep
Work through five risk categories (drawn from Phoenix Project patterns and Berkun's scoping risk model):
Category 1: Unplanned Work Risk
Questions to surface:
- What percentage of past sprint capacity went to unplanned work (bugs, incidents, support)?
- Are there any live production incidents or instability issues currently?
- Is the team on an on-call rotation that competes with feature delivery?
Phoenix Project signal: if unplanned work consumed > 20% of capacity in recent sprints, it will consume more during the release crunch.
Category 2: Dependency Risk
Questions to surface:
- Are there external teams or vendors whose deliverables are on your critical path?
- Have any dependencies been verbally confirmed but not formally committed?
- Is there a shared resource (DBA, security review, legal) that serves multiple teams?
Category 3: Scope Risk
Questions to surface:
- Has the scope changed since the release was planned?
- Are there features with open design questions or unsettled technical approach?
- Are any P0 items estimated with low confidence?
Berkun signal: any feature where the team has not done this type of work before carries a 2x estimation risk.
Category 4: People Risk
Questions to surface:
- Is any critical knowledge concentrated in one person (single point of failure)?
- Are there planned vacations, hiring gaps, or new team members ramping up during the release window?
- Is team morale or engagement a concern?
Category 5: Technical Risk
Questions to surface:
- Is the release touching legacy systems, high-complexity code, or areas with low test coverage?
- Are there infrastructure changes (migrations, new services, third-party integrations) in scope?
- Has this area of the codebase caused incidents in the past 90 days?
Step 3: Score each risk
For each identified risk, assign:
- Likelihood: Low (unlikely in this release) / Med (has happened before) / High (currently happening or happened in last release)
- Impact: Low (minor delay, < 1 sprint) / Med (1-2 sprint delay or scope cut) / High (release date at risk or launch criteria not met)
- Priority: High × High = P0 (escalate now), else use the matrix below
| Impact Low | Impact Med | Impact High
-----------|------------|------------|------------
Likelihood High | P2 | P1 | P0
Likelihood Med | P3 | P2 | P1
Likelihood Low | P3 | P3 | P2
Step 4: Generate the risk register
DELIVERY RISK REGISTER - [your program] - [date]
=================================================
P0 - ESCALATE NOW
| # | Risk | Category | Likelihood | Impact | Owner | Mitigation | Due |
|---|------|----------|-----------|--------|-------|------------|-----|
| 1 | [risk description] | [type] | High | High | [name] | [action] | [date] |
P1 - MONITOR WEEKLY
[same format]
P2/P3 - TRACK AND ACCEPT
[same format]
Step 5: Write mitigations (not just monitoring)
For each P0 and P1 risk, the mitigation must be one of:
- Avoid: change the plan to eliminate the risk (re-sequence, reduce scope)
- Transfer: make it someone else's problem with a formal commitment (SLA, contract, escalation to leadership)
- Reduce: take specific action to lower likelihood or impact (add test coverage, cross-train a second engineer, get written confirmation from vendor)
- Accept: explicitly acknowledge it and define the trigger that would escalate it
"We'll keep an eye on it" is not a mitigation. Name the action, the owner, and the date.
Step 6: Set risk review cadence
Recommend a standing cadence based on program phase:
- More than 6 weeks from release: review risk register every 2 weeks
- 3-6 weeks from release: weekly review, P0 risks reviewed in every program sync
- Less than 3 weeks from release: daily standup includes P0 risk status
Anti-Patterns
1. Identifying risks without owners
Bad: "Technical debt in the auth service is a risk."
Good: "[Name] will assess auth service test coverage by [date] and recommend if it needs a dedicated spike."
2. Only listing obvious risks
Bad: Risk register with "API might be slow" and "team might be busy."
Good: Surface non-obvious risks: knowledge concentration, unplanned work patterns, verbally-confirmed-but-not-written dependencies.
3. All risks rated the same
Bad: 15 risks all rated "medium."
Good: Force a distribution. If everything is medium, you have not done the analysis.
4. Risk review as a one-time event
Bad: Risk register created at kickoff, never updated.
Good: Risk register is a living document. Reviewed at program sync, statuses updated weekly.
5. Mitigation = monitoring
Bad: "We will watch this closely."
Good: A specific action that reduces likelihood or impact, with a named owner and due date.
Quality Checklist