Risk Management
Risk is uncertainty that matters. Every project operates under uncertainty — requirements change, dependencies break, people leave, estimates miss. Risk management does not eliminate uncertainty; it makes uncertainty visible, quantifiable, and actionable. The goal is not a risk-free project (that project does not exist) but a project where surprises are anticipated, responses are prepared, and the team is never blindsided.
Margaret Hamilton's Apollo guidance software team did not hope their code would work during lunar descent. They engineered priority displays that could shed non-critical tasks under overload — a risk response designed before the risk materialized. When Apollo 11's computer threw 1202 alarms during the final descent, the crew landed safely because Hamilton's team had already decided what to do. That is risk management: deciding what to do before you need to.
Agent affinity: hamilton (systems engineering, risk architecture), brooks (organizational risk, "no silver bullet")
Concept IDs: bus-business-planning, bus-cost-benefit-analysis, crit-problem-analysis, crit-evidence-evaluation
Risk Management Process Overview
| Phase | Activity | Output | |---|---|---| | 1. Identify | Find risks before they find you | Risk list | | 2. Analyze | Assess probability and impact | Prioritized risk register | | 3. Plan responses | Decide what to do about each risk | Response strategies | | 4. Monitor | Track risks, watch for triggers, update | Living risk register |
This is a continuous cycle, not a one-time activity. The risk register is a living document — reviewed at every sprint retrospective, updated at every milestone boundary, and consulted before every major decision.
Phase 1 — Risk Identification
Techniques
Brainstorming. The team generates risks freely. No filtering during generation — quantity over quality. Sort and prioritize afterward. Works best with diverse perspectives: developers, testers, operations, business stakeholders.
Checklist review. Use historical checklists from similar projects. Common categories:
- Technical: Architecture limitations, technology maturity, integration complexity
- Schedule: Optimistic estimates, dependency delays, resource availability
- Scope: Requirement ambiguity, scope creep, stakeholder disagreement
- External: Vendor reliability, regulatory changes, market shifts
- People: Key person dependency, skill gaps, team turnover
SWOT analysis. Strengths, Weaknesses, Opportunities, Threats. Strengths and weaknesses are internal; opportunities and threats are external. SWOT for risk focuses on the WT quadrant (weaknesses that amplify threats).
Assumption analysis. Every project plan rests on assumptions. List them explicitly. Each assumption is a potential risk if it proves false.
Worked example — Assumption surfacing.
| Assumption | If false... | Risk | |---|---|---| | The payment API supports batch processing | Must process sequentially; 10x slower | Schedule slip on checkout feature | | The senior developer stays through Q3 | Knowledge loss on auth subsystem | Quality and schedule risk | | Staging environment available by March 1 | Cannot integration-test until March 15 | Late defect discovery | | Client will provide test data by sprint 3 | Must generate synthetic data | Scope increase, fidelity risk |
Each "If false..." entry becomes a risk in the register.
Pre-mortem (Klein). Gary Klein's technique: imagine the project has failed. Ask the team "Why did it fail?" People generate causes of failure more easily than abstract risks. This is psychologically powerful because it bypasses optimism bias.
GSD Connection — Risk Identification in Phases
GSD's discuss phase (gsd-discuss-phase) gathers context through adaptive questioning before planning. Risk identification is natural here: "What could go wrong?" and "What assumptions are we making?" belong in every discuss phase. The list-phase-assumptions command (gsd-list-phase-assumptions) makes this explicit — surfacing Claude's assumptions before they become embedded in the plan.
Phase 2 — Risk Analysis
Qualitative Analysis — Probability x Impact Matrix
Assign each risk a probability (Low/Medium/High or 1-5) and an impact (Low/Medium/High or 1-5). Multiply to get a risk score.
Standard 5x5 matrix:
| | Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 | |---|---|---|---|---|---| | Prob 5 | 5 | 10 | 15 | 20 | 25 | | Prob 4 | 4 | 8 | 12 | 16 | 20 | | Prob 3 | 3 | 6 | 9 | 12 | 15 | | Prob 2 | 2 | 4 | 6 | 8 | 10 | | Prob 1 | 1 | 2 | 3 | 4 | 5 |
Risk zones:
- Red (15-25): Active mitigation required. Escalate to project sponsor.
- Yellow (8-14): Monitor closely. Mitigation plan on standby.
- Green (1-7): Accept or watch. Low priority.
Worked Example — Risk Register
| ID | Risk | Prob | Impact | Score | Response | Owner | |---|---|---|---|---|---|---| | R01 | Payment API does not support batch | 3 | 4 | 12 | Mitigate: prototype batch call in sprint 1 | Dev lead | | R02 | Senior developer leaves before Q3 | 2 | 5 | 10 | Mitigate: pair programming for knowledge transfer | Scrum master | | R03 | Staging environment delayed | 4 | 3 | 12 | Avoid: provision cloud staging independently | DevOps | | R04 | Client test data late | 3 | 3 | 9 | Accept: synthetic data generator as fallback | QA lead | | R05 | Third-party auth library deprecated | 2 | 4 | 8 | Transfer: use vendor-supported alternative | Architect | | R06 | Performance target (200ms p95) unreachable | 2 | 5 | 10 | Mitigate: performance spike in sprint 2 | Dev lead |
Quantitative Analysis — Monte Carlo Simulation
For schedule and cost risks where qualitative assessment is insufficient, Monte Carlo simulation provides probability distributions.
Process:
- For each task, estimate three durations: optimistic (O), most likely (M), pessimistic (P).
- Model each task duration as a probability distribution (PERT-beta or triangular).
- Simulate the project schedule 10,000+ times, sampling each task duration from its distribution.
- The output is a cumulative probability curve: "There is an 80% chance the project completes by date X."
Worked example — Three-task project.
| Task | O (days) | M (days) | P (days) | PERT mean | |---|---|---|---|---| | Backend API | 5 | 8 | 20 | 9.2 | | Frontend UI | 3 | 5 | 12 | 5.8 | | Integration | 2 | 4 | 10 | 4.7 |
Tasks are sequential. PERT mean total: 19.7 days. But the sum of means is not the 80th percentile — variance accumulates.
After 10,000 Monte Carlo runs:
- P50 (median): 20 days
- P80: 24 days
- P95: 30 days
Insight. If the deadline is 20 days, you have a coin-flip chance of making it. If stakeholders need 80% confidence, plan for 24 days. The difference between P50 and P80 is the risk buffer — and it is not padding, it is mathematics.
Decision Trees and Expected Monetary Value (EMV)
Decision tree. A branching diagram where each node is a decision or chance event. Branches represent options or outcomes, with probabilities and values at each terminal node.
Worked example — Build vs. buy.
Decision: Build custom auth system vs. Buy commercial
Build:
Success (p=0.7): -$50K (dev cost), saves $20K/year for 5 years = +$50K net
Failure, rebuild (p=0.3): -$50K + -$30K rebuild = -$80K
EMV(Build) = 0.7 * $50K + 0.3 * (-$80K) = $35K - $24K = +$11K
Buy:
Works well (p=0.9): -$15K/year * 5 = -$75K
Vendor discontinues (p=0.1): -$75K + -$40K migration = -$115K
EMV(Buy) = 0.9 * (-$75K) + 0.1 * (-$115K) = -$67.5K - $11.5K = -$79KEMV favors Build (+$11K vs. -$79K). But note: Build has a 30% chance of -$80K outcome. If the organization cannot absorb that loss, the EMV calculation alone is insufficient — risk appetite matters.
Phase 3 — Risk Response Strategies
The Four Strategies
Avoid. Eliminate the risk by changing the plan. If a risky technolo