Risk Management
Identify, assess, and mitigate risks systematically.
When to use this skill
- Starting a new project or initiative — before committing resources
- Planning a migration, launch, or infrastructure change
- Running a pre-mortem before a critical project begins
- Assessing organizational risks from restructuring or strategic changes
- Activating a contingency plan when a tracked risk materializes
- Building a risk register from an existing list of concerns
When NOT to use this skill
- Security vulnerability scanning → use dedicated security audit tools
- Financial risk modeling (Monte Carlo, VaR) → use specialized quantitative tools
- Real-time incident response → use debugging/troubleshooting workflows
- Finding conceptual flaws in ideas → use
critical-intuition
- Edge-case coverage in code → use
edge-case-coverage
Decision tree
What are you trying to do?
│
├─ Assess risks for a NEW project/initiative
│ └─ Full risk assessment: identify by category → score → mitigate → monitor
│
├─ Imagine the project already FAILED and find out why
│ └─ Pre-mortem technique (see below)
│
├─ Score and prioritize an EXISTING list of concerns
│ └─ Apply 3x3 matrix → assign strategies → add owners and review dates
│
└─ A tracked risk has MATERIALIZED
└─ Contingency activation: execute response → update register → surface new risks
Risk Assessment Matrix
IMPACT
Low Med High
LIKELIHOOD
High Med High Critical
Med Low Med High
Low Low Low Med
Risk Categories
| Category |
Examples |
| Technical |
Architecture, integration, performance |
| Schedule |
Dependencies, estimation, resources |
| Resource |
Skills, availability, turnover |
| External |
Vendors, regulations, market |
| Organizational |
Priorities, funding, politics |
Risk Register Template
## Risk Register
| ID | Risk | Category | Likelihood | Impact | Score | Mitigation | Owner | Status |
|----|------|----------|------------|--------|-------|------------|-------|--------|
| R1 | [desc] | Technical | High | Med | 6 | [action] | [name] | Open |
| R2 | [desc] | Schedule | Med | High | 6 | [action] | [name] | Open |
Scoring
- Likelihood: 1 (Low) - 3 (High)
- Impact: 1 (Low) - 3 (High)
- Score = Likelihood x Impact
- 1-2: Low priority (Accept/monitor), 3-4: Medium (Mitigate), 6-9: High/Critical (Avoid/Mitigate/Transfer)
Mitigation Strategies
| Strategy |
When to Use |
Example |
| Avoid |
Risk is Critical (6-9) and can be eliminated by changing approach |
Use open-source alternative to avoid vendor lock-in |
| Transfer |
Risk involves financial loss or liability that can be shifted |
Cyber insurance for data breach risk |
| Mitigate |
Risk cannot be avoided but likelihood/impact can be reduced |
Run load tests before migration to reduce performance regression risk |
| Accept |
Risk is Low (1-2) or mitigation cost exceeds expected impact |
Minor UI change may confuse some users temporarily |
Risk Response Template
## Risk: [Name]
**Description**: [what could go wrong]
**Trigger**: [warning signs]
**Probability**: [%]
**Impact**: [consequence]
### Response Plan
- **Strategy**: [avoid/transfer/mitigate/accept]
- **Actions**:
1. [preventive action]
2. [contingency if occurs]
- **Owner**: [responsible person]
- **Review date**: [when to reassess]
Monitoring Practices
| Frequency |
Activity |
| Daily |
Check trigger conditions |
| Weekly |
Review active risks |
| Monthly |
Reassess scores |
| Quarterly |
Full register review |
Pre-Mortem Technique
Before project starts, imagine it failed.
- What went wrong? — list specific failure modes (not "it failed" but "the database migration corrupted production data")
- Why did it happen? — trace each failure to a root cause; ask "why?" three times
- What could we have done? — convert each finding into a preventive action with an owner
Convert answers to risks and mitigations. The pre-mortem bypasses optimism bias because starting from assumed failure removes the temptation to say "that probably won't happen."
When to run a pre-mortem: before any project with a hard deadline, irreversible commitment, or budget > 2 team-months.
Anti-Patterns with Solutions
Medium-Medium everything — every risk gets scored "Medium/Medium" without analysis, making the register useless for prioritization.
- Solution: for each "Medium," demand evidence: "what specific fact supports this score? What would change it to High?" If no evidence exists, the score is a guess — gather data before scoring.
Vague mitigations — "Mitigate: reduce risk" without specific actions, triggers, or owners.
- Solution: every mitigation must answer four questions: What specific action? Who owns it? By when? What trigger activates it? Example: "Mitigate: run Aurora compatibility audit by end of week 1 (owned by DB lead), trigger: any incompatible extension found."
Register as checkbox exercise — team fills it mechanically and never revisits.
- Solution: assign each risk a specific owner with a concrete check action (not "keep an eye on it" but "run load test against staging every Monday"); schedule quarterly reviews that close resolved risks and force Accept decisions on stale items.
Optimism bias — forward-looking analysis misses risks because "things usually work out."
- Solution: use the pre-mortem technique; it bypasses optimism bias by starting from assumed failure.
Infinite register growth — every concern gets added, nothing is ever closed.
- Solution: cap at 20 items; at each review, close resolved risks, merge duplicates, and force decisions on items open for 2+ cycles. A register over 20 items loses its usefulness.
Single-category tunnel vision — only technical risks get identified, ignoring schedule, resource, external, and organizational risks.
- Solution: systematically walk all five categories during identification; use the category table as a checklist, not a suggestion.
1---2name: risk-management3description: Systematically assess and mitigate risks using risk registers, probability-impact matrices, mitigation strategies, and contingency plans. Use when the user asks to assess risks, build a risk register, plan for failure modes, evaluate downside scenarios, prepare contingency plans, or quantify uncertainty before a decision or launch. NOT for finding conceptual flaws or blind spots in ideas (use critical-intuition). NOT for security vulnerability auditing in code (use code-review). NOT for identifying boundary conditions in code (use edge-case-coverage).4---56# Risk Management78Identify, assess, and mitigate risks systematically.910## When to use this skill1112- Starting a new project or initiative — before committing resources13- Planning a migration, launch, or infrastructure change14- Running a pre-mortem before a critical project begins15- Assessing organizational risks from restructuring or strategic changes16- Activating a contingency plan when a tracked risk materializes17- Building a risk register from an existing list of concerns1819## When NOT to use this skill2021- **Security vulnerability scanning** → use dedicated security audit tools22- **Financial risk modeling (Monte Carlo, VaR)** → use specialized quantitative tools23- **Real-time incident response** → use debugging/troubleshooting workflows24- **Finding conceptual flaws in ideas** → use `critical-intuition`25- **Edge-case coverage in code** → use `edge-case-coverage`2627---2829## Decision tree3031```32What are you trying to do?33 │34 ├─ Assess risks for a NEW project/initiative35 │ └─ Full risk assessment: identify by category → score → mitigate → monitor36 │37 ├─ Imagine the project already FAILED and find out why38 │ └─ Pre-mortem technique (see below)39 │40 ├─ Score and prioritize an EXISTING list of concerns41 │ └─ Apply 3x3 matrix → assign strategies → add owners and review dates42 │43 └─ A tracked risk has MATERIALIZED44 └─ Contingency activation: execute response → update register → surface new risks45```4647---4849## Risk Assessment Matrix5051```52 IMPACT53 Low Med High54LIKELIHOOD55High Med High Critical56Med Low Med High57Low Low Low Med58```5960## Risk Categories6162| Category | Examples |63|----------|----------|64| Technical | Architecture, integration, performance |65| Schedule | Dependencies, estimation, resources |66| Resource | Skills, availability, turnover |67| External | Vendors, regulations, market |68| Organizational | Priorities, funding, politics |6970## Risk Register Template7172```markdown73## Risk Register7475| ID | Risk | Category | Likelihood | Impact | Score | Mitigation | Owner | Status |76|----|------|----------|------------|--------|-------|------------|-------|--------|77| R1 | [desc] | Technical | High | Med | 6 | [action] | [name] | Open |78| R2 | [desc] | Schedule | Med | High | 6 | [action] | [name] | Open |79```8081### Scoring82- Likelihood: 1 (Low) - 3 (High)83- Impact: 1 (Low) - 3 (High)84- Score = Likelihood x Impact85- 1-2: Low priority (Accept/monitor), 3-4: Medium (Mitigate), 6-9: High/Critical (Avoid/Mitigate/Transfer)8687## Mitigation Strategies8889| Strategy | When to Use | Example |90|----------|-------------|---------|91| **Avoid** | Risk is Critical (6-9) and can be eliminated by changing approach | Use open-source alternative to avoid vendor lock-in |92| **Transfer** | Risk involves financial loss or liability that can be shifted | Cyber insurance for data breach risk |93| **Mitigate** | Risk cannot be avoided but likelihood/impact can be reduced | Run load tests before migration to reduce performance regression risk |94| **Accept** | Risk is Low (1-2) or mitigation cost exceeds expected impact | Minor UI change may confuse some users temporarily |9596## Risk Response Template9798```markdown99## Risk: [Name]100101**Description**: [what could go wrong]102**Trigger**: [warning signs]103**Probability**: [%]104**Impact**: [consequence]105106### Response Plan107- **Strategy**: [avoid/transfer/mitigate/accept]108- **Actions**:109 1. [preventive action]110 2. [contingency if occurs]111- **Owner**: [responsible person]112- **Review date**: [when to reassess]113```114115## Monitoring Practices116117| Frequency | Activity |118|-----------|----------|119| Daily | Check trigger conditions |120| Weekly | Review active risks |121| Monthly | Reassess scores |122| Quarterly | Full register review |123124## Pre-Mortem Technique125126Before project starts, imagine it failed.1271. What went wrong? — list specific failure modes (not "it failed" but "the database migration corrupted production data")1282. Why did it happen? — trace each failure to a root cause; ask "why?" three times1293. What could we have done? — convert each finding into a preventive action with an owner130131Convert answers to risks and mitigations. The pre-mortem bypasses optimism bias because starting from assumed failure removes the temptation to say "that probably won't happen."132133**When to run a pre-mortem**: before any project with a hard deadline, irreversible commitment, or budget > 2 team-months.134135## Anti-Patterns with Solutions1361371. **Medium-Medium everything** — every risk gets scored "Medium/Medium" without analysis, making the register useless for prioritization.138 - **Solution**: for each "Medium," demand evidence: "what specific fact supports this score? What would change it to High?" If no evidence exists, the score is a guess — gather data before scoring.1391402. **Vague mitigations** — "Mitigate: reduce risk" without specific actions, triggers, or owners.141 - **Solution**: every mitigation must answer four questions: What specific action? Who owns it? By when? What trigger activates it? Example: "Mitigate: run Aurora compatibility audit by end of week 1 (owned by DB lead), trigger: any incompatible extension found."1421433. **Register as checkbox exercise** — team fills it mechanically and never revisits.144 - **Solution**: assign each risk a specific owner with a concrete check action (not "keep an eye on it" but "run load test against staging every Monday"); schedule quarterly reviews that close resolved risks and force Accept decisions on stale items.1451464. **Optimism bias** — forward-looking analysis misses risks because "things usually work out."147 - **Solution**: use the pre-mortem technique; it bypasses optimism bias by starting from assumed failure.1481495. **Infinite register growth** — every concern gets added, nothing is ever closed.150 - **Solution**: cap at 20 items; at each review, close resolved risks, merge duplicates, and force decisions on items open for 2+ cycles. A register over 20 items loses its usefulness.1511526. **Single-category tunnel vision** — only technical risks get identified, ignoring schedule, resource, external, and organizational risks.153 - **Solution**: systematically walk all five categories during identification; use the category table as a checklist, not a suggestion.
viktorbezdek