Project Risk Register

Table of Contents

1. Workflow
2. Common Patterns
3. Risk Scoring Framework
4. Guardrails
5. Quick Reference

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

Workflow

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 for category checklists. Use 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 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 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 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 for monitoring cadence.

Common Patterns

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)

Risk Scoring Framework

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)

Guardrails

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)

2. 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"

3. 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)

4. 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)

5. 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

6. 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)

7. 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)

8. 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)

Quick Reference

Resources:

• Quick start: resources/template.md - Risk register template with scoring table, response planning, monitoring log
• Advanced techniques: resources/methodology.md - Monte Carlo simulation, decision trees, sensitivity analysis, risk aggregation, earned value management
• Quality check: 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)