project-risk-register

1. [Purpose](#purpose)
2. [When to Use](#when-to-use)
3. [What Is It?](#what-is-it)
4. [Workflow](#workflow)
5. [Common Patterns](#common-patterns)
6. [Risk Scoring Framework](#risk-scoring-framework)
7. [Guardrails](#guardrails)
8. [Quick Reference](#quick-reference)

Proactively identify, assess, prioritize, and monitor project risks to reduce likelihood of surprises, enable informed decision-making, and ensure stakeholders understand uncertainty. Transform vague concerns ("this might not work") into actionable risk management (probability×impact scores, named owners, specific mitigations, measurable triggers).

Use this skill when:

• Project kickoff: Establishing risk baseline before significant work begins
• High uncertainty: New technology, unfamiliar domain, complex dependencies, regulatory constraints
• Stakeholder pressure: Execs/board want visibility into "what could go wrong"
• Critical path concerns: Delays, dependencies, or single points of failure threaten timeline
• Gate reviews: Quarterly check-ins, milestone reviews, go/no-go decisions require risk assessment
• Incident response: Major issue occurred, need to identify related risks to prevent recurrence
• Portfolio management: Comparing risk profiles across multiple projects for resource allocation
• Change requests: Scope/timeline/budget changes require risk re-assessment

Common triggers:

• "What are the biggest risks to this project?"
• "What could cause us to miss the deadline?"
• "How confident are we in this estimate/plan?"
• "What's our backup plan if X fails?"
• "What dependencies could block us?"

Project Risk Register is a living document tracking all identified risks with:

1. Risk identification: What could go wrong (threat) or go better than expected (opportunity)
2. Risk assessment: Probability (how likely?) × Impact (how bad/good if it happens?) = Risk Score
3. Risk prioritization: Focus on high-score risks (red/high) first, monitor medium (yellow), accept low (green)
4. Risk ownership: Named individual responsible for monitoring and mitigation
5. Risk response: Mitigation (reduce probability), contingency (reduce impact if occurs), acceptance (do nothing)
6. Risk triggers: Early warning indicators that risk is materializing (time to activate contingency)
7. Risk monitoring: Regular updates (status changes, new risks, retired risks)

Risk Matrix (5×5 Probability×Impact):

```

Impact → 1 2 3 4 5

Prob ↓ Minimal Minor Moderate Major Severe

5 High │ Medium │ Medium │ High │ High │ Critical│

│ 5 │ 10 │ 15 │ 20 │ 25 │

4 │ Low │ Medium │ Medium │ High │ High │

│ 4 │ 8 │ 12 │ 16 │ 20 │

3 Medium │ Low │ Low │ Medium │ Medium │ High │

│ 3 │ 6 │ 9 │ 12 │ 15 │

2 │ Low │ Low │ Low │ Medium │ Medium │

│ 2 │ 4 │ 6 │ 8 │ 10 │

1 Low │ Low │ Low │ Low │ Low │ Medium │

│ 1 │ 2 │ 3 │ 4 │ 5 │

```

Risk Thresholds:

• Critical (≥20): Escalate to exec, immediate mitigation required
• High (12-19): Active management, weekly review, documented mitigation
• Medium (6-11): Monitor closely, monthly review, contingency plan
• Low (1-5): Accept or minimal mitigation, quarterly review

Example: Software Migration Project

| Risk ID | Risk | Prob | Impact | Score | Owner | Mitigation | Contingency |

|---------|------|------|--------|-------|-------|------------|-------------|

| R-001 | Third-party API deprecated mid-project | 3 | 4 | 12 (Medium) | Eng Lead | Contact vendor for deprecation timeline | Build abstraction layer for quick swap |

| R-002 | Key engineer leaves during critical phase | 2 | 5 | 10 (Medium) | EM | Knowledge sharing, pair programming | Contract backup engineer |

| R-003 | Data migration takes 3× longer than estimated | 4 | 4 | 16 (High) | Data Lead | Pilot migration on 10% data first | Extend timeline, reduce scope |

Copy this checklist and track your progress:

```

Risk Register Progress:

• [ ] Step 1: Identify risks across categories
• [ ] Step 2: Assess probability and impact
• [ ] Step 3: Calculate risk scores and prioritize
• [ ] Step 4: Assign owners and define responses
• [ ] Step 5: Monitor and update regularly

```

Step 1: Identify risks across categories

Brainstorm what could go wrong using structured categories (technical, schedule, resource, external, scope). See [Common Patterns](#common-patterns) for category checklists. Use [resources/template.md](resources/template.md) for register structure.

Step 2: Assess probability and impact

Score each risk on probability (1-5: rare to almost certain) and impact (1-5: minimal to severe). Involve subject matter experts for accuracy. See [Risk Scoring Framework](#risk-scoring-framework) for definitions.

Step 3: Calculate risk scores and prioritize

Multiply Probability × Impact for each risk. Plot on risk matrix (5×5 grid) to visualize risk profile. Focus mitigation on Critical/High risks first. See [resources/methodology.md](resources/methodology.md) for advanced techniques like Monte Carlo simulation.

Step 4: Assign owners and define responses

For each High/Critical risk, assign named owner (not "team"), define mitigation (reduce probability), contingency (reduce impact), and triggers (when to activate contingency). See [resources/template.md](resources/template.md) for response planning structure.

Step 5: Monitor and update regularly

Review risk register weekly (active projects) or monthly (longer projects). Update probabilities/impacts as context changes, add new risks, retire closed risks, track mitigation progress. See [Guardrails](#guardrails) for monitoring cadence.

Risk categories (use for brainstorming):

• Technical risks: Technology failure, integration issues, performance problems, security vulnerabilities, technical debt, complexity underestimated
• Schedule risks: Dependencies delayed, estimation errors, scope creep, resource unavailability, critical path blocked
• Resource risks: Key person leaves, skill gaps, budget overrun, vendor/contractor issues, equipment unavailable
• External risks: Regulatory changes, market shifts, competitor actions, economic downturn, natural disasters, vendor bankruptcy
• Scope risks: Unclear requirements, changing priorities, stakeholder disagreement, gold-plating, mission creep
• Organizational risks: Lack of executive support, competing priorities, insufficient funding, organizational change, political conflicts

By project type:

• Software projects: Third-party API changes, dependency vulnerabilities, cloud provider outages, data migration issues, browser compatibility, scaling problems, security breaches
• Construction projects: Weather delays, material shortages, permit issues, labor strikes, soil conditions, cost overruns, safety incidents
• Product launches: Manufacturing delays, supply chain disruption, competitor launch, pricing miscalculation, market demand lower than expected, quality issues
• Organizational change: Employee resistance, communication breakdown, training inadequate, budget cuts, leadership turnover, cultural misalignment

By risk response type:

• Mitigate (reduce probability): Training, prototyping, process improvements, redundancy, quality checks, early testing
• Contingency (reduce impact if occurs): Backup plans, insurance, reserves (time/budget), alternative suppliers, rollback procedures
• Accept (do nothing): Low-score risks not worth mitigation cost, residual risks after mitigation
• Transfer (shift to others): Insurance, outsourcing, contracts (penalty clauses), warranties

Typical risk profile evolution:

• Project start: Many medium risks (uncertainty high), few critical (pre-mitigation)
• Mid-project: Critical risks mitigated to medium/low, new risks emerge (dependencies, integration)
• Near completion: Low risks dominate (most issues resolved), few high (last-minute surprises)
• Red flag: Risk score increasing over time (mitigation not working, new issues emerging faster than resolution)

Probability Scale (1-5):

• 5 - Almost Certain (>80%): Expected to occur, historical data confirms, no mitigation in place
• 4 - Likely (60-80%): Probably will occur, similar projects had this issue, weak mitigation
• 3 - Possible (40-60%): May or may not occur, depends on circumstances, some mitigation in place
• 2 - Unlikely (20-40%): Probably won't occur, mitigation in place, low historical precedent
• 1 - Rare (<20%): Very unlikely, strong mitigation, no historical precedent

Impact Scale (1-5) - adjust dimensions for project context:

For Schedule Impact:

• 5 - Severe: >20% delay (e.g., 3-month project delayed 3+ weeks), miss critical deadline, cascading delays
• 4 - Major: 10-20% delay, miss milestone, affects dependent projects
• 3 - Moderate: 5-10% delay, timeline buffer consumed, no external impact
• 2 - Minor: <5% delay, absorbed within sprint/phase, minor schedule pressure
• 1 - Minimal: <1% delay or no delay, negligible schedule impact

For Budget Impact:

• 5 - Severe: >20% budget overrun, requires new funding approval, project viability threatened
• 4 - Major: 10-20% overrun, contingency exhausted, scope cuts required
• 3 - Moderate: 5-10% overrun, contingency partially used, no scope cuts
• 2 - Minor: <5% overrun, absorbed within budget flexibility
• 1 - Minimal: <1% overrun or no budget impact

For Scope/Quality Impact:

• 5 - Severe: Core functionality lost, customer-facing quality issue, regulatory violation
• 4 - Major: Important feature cut, significant quality degradation, customer complaints
• 3 - Moderate: Nice-to-have feature cut, minor quality issue, internal workarounds needed
• 2 - Minor: Edge case feature cut, cosmetic quality issue
• 1 - Minimal: No scope or quality impact

Composite Impact (when multiple dimensions affected):

• Use maximum of any single dimension (pessimistic, conservative)
• OR use weighted average: Schedule 40%, Budget 30%, Scope/Quality 30%

Example Scoring:

Risk: "Key engineer leaves mid-project"

• Probability: 2 (Unlikely - 20% based on tenure, satisfaction, retention rate)
• Impact Schedule: 4 (Major - 3-week delay to onboard replacement, knowledge transfer)
• Impact Budget: 2 (Minor - recruiter fees, some overtime)
• Impact Scope: 3 (Moderate - may cut advanced features)
• Composite Impact: 4 (take maximum: schedule impact is worst)
• Risk Score: 2 × 4 = 8 (Medium)

Ensure quality:

1. Identify risks proactively, not reactively: Run risk workshops before problems occur

- ✓ Brainstorm risks at project kickoff, use checklists (technical, schedule, resource, etc.)

- ❌ Add risks only after incidents occur (reactive)

1. Be specific, not vague: "Integration fails" is vague, "Vendor API rate limits block migration" is specific

- ✓ "Third-party payment gateway rejects 10% of transactions due to fraud rules"

- ❌ "Payment issues"

1. Separate probability and impact: Don't conflate "bad if it happens" with "likely to happen"

- ✓ Asteroid hits office: Prob=1 (rare), Impact=5 (severe), Score=5 (low priority)

- ❌ Conflating: "This is really bad so it must be high priority" (ignoring low probability)

1. Assign named owners, not teams: "Engineering team" is not accountable, "Sarah (Tech Lead)" is

- ✓ Owner: Sarah (Tech Lead), responsible for monitoring and activating contingency

- ❌ Owner: Engineering Team (diffused responsibility)

1. Define mitigation AND contingency: Mitigation reduces probability, contingency handles if it occurs anyway

- ✓ Mitigation: Prototype integration early (reduce prob). Contingency: Build abstraction layer for quick swap (reduce impact)

- ❌ Only mitigation, no backup plan

1. Update regularly: Stale risk register is worse than none (false confidence)

- ✓ Weekly review for active projects (High/Critical risks), monthly for longer projects

- ❌ Create register at kickoff, never update (probabilities/impacts change as project progresses)

1. Retire closed risks: Don't let register grow indefinitely, archive mitigated/irrelevant risks

- ✓ Mark risk "Closed" with resolution date, move to archive section

- ❌ Keep all risks forever (signal-to-noise ratio degrades)

1. Escalate critical risks immediately: Don't wait for weekly meeting if Critical risk emerges

- ✓ Prob=5 Impact=5 Score=25 → Escalate to exec same day, emergency mitigation

- ❌ Wait for scheduled review (risk could materialize)

Resources:

• Quick start: [resources/template.md](resources/template.md) - Risk register template with scoring table, response planning, monitoring log
• Advanced techniques: [resources/methodology.md](resources/methodology.md) - Monte Carlo simulation, decision trees, sensitivity analysis, risk aggregation, earned value management
• Quality check: [resources/evaluators/rubric_project_risk_register.json](resources/evaluators/rubric_project_risk_register.json) - Evaluation criteria

Success criteria:

• ✓ Identified 15-30 risks across all categories (technical, schedule, resource, external, scope, org)
• ✓ All High/Critical risks (score ≥12) have named owners, mitigation plans, and contingencies
• ✓ Risk scores differentiated (not all scored 6-9; use full 1-25 range)
• ✓ Mitigation and contingency plans are specific and actionable (not "monitor closely")
• ✓ Triggers defined for when to activate contingencies (quantifiable thresholds)
• ✓ Register updated regularly (weekly for active projects, monthly for longer projects)
• ✓ Risk profile matches project phase (high uncertainty at start, decreasing over time)

Common mistakes:

• ❌ Too few risks identified (<10) → incomplete risk picture, false confidence
• ❌ All risks scored medium (6-9) → not differentiated, unclear prioritization
• ❌ Vague risks ("things might not work") → not actionable
• ❌ No risk owners assigned → diffused accountability, mitigation doesn't happen
• ❌ Mitigation without contingency → no backup plan if mitigation fails
• ❌ Created once, never updated → stale data, risks evolve
• ❌ Only negative risks (threats) → missing opportunities (positive risks)
• ❌ Risk register separate from project plan → not integrated into workflow

When to use alternatives:

• Pre-mortem: When project hasn't started, want to imagine failure scenarios (complements risk register)
• FMEA (Failure Mode Effects Analysis): Manufacturing/engineering projects needing detailed failure analysis
• Monte Carlo simulation: When need probabilistic timeline/budget forecasting (use methodology.md)
• Decision tree: When risks involve sequential decisions with branch points
• Scenario planning: When risks are strategic/long-term (market shifts, competitor actions)