# Risk Register

> Systematically identify and track technical and organizational risks that could impact delivery timelines. Use when planning significant initiatives.

- Skill: `sethdford/risk-register` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/risk-register`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/risk-register/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/risk-register

---


# Risk Register

Create and maintain a living document of risks, impacts, and mitigation strategies.

## Context

You are helping a tech lead build a risk register for an initiative or roadmap. If you have project details, team constraints, or technical architecture, use them to identify realistic risks.

## Domain Context

- Project Management Institute (PMI): risk management is identifying, analyzing, and responding to risks that could impact project success
- Larson: "the best way to be wrong is confidently"; risk registers force healthy paranoia
- Nassim Taleb's "Antifragile": the goal is not to predict the future, but to be robust to surprises

Key principles:

1. **Risks are not problems**: A risk is something that might happen. If it has happened, it's a problem (manage differently)
2. **Probability × impact = priority**: A low-probability, high-impact risk may need action. A high-probability, low-impact risk might not
3. **Mitigation is not elimination**: You rarely eliminate risk. You reduce probability, reduce impact, or accept it

## Instructions

1. **Brain dump risks**: In 30 minutes, list every technical, organizational, and external risk that could derail the initiative. Don't filter; include paranoid ones. Example risks:
   - Key engineer leaves (headcount risk)
   - Third-party dependency (auth provider) changes their API (vendor risk)
   - Underestimated complexity in migration (technical risk)
   - Business priorities shift (strategy risk)
   - Infrastructure incident impacts development (operational risk)

2. **For each risk, estimate probability and impact**:
   - Probability: low (< 20%), medium (20-50%), high (> 50%)
   - Impact: low (can work around), medium (delays 1 sprint), high (derails project)

3. **Calculate priority**: High probability × high impact risks get immediate attention. Low probability × low impact risks get noted but not actively managed

4. **Define trigger conditions**: What signal tells you a risk is becoming real? Example: "If we haven't seen design by milestone X, architecture review risk is materializing"

5. **Design mitigation**: For each high-priority risk, write 1-2 mitigation actions. Focus on reducing probability (can we de-risk early?) or impact (what's our backup plan?). Example:
   - **Risk**: Key engineer leaves
   - **Mitigation 1**: Knowledge transfer sessions (pair programming) starting month 1, not month 3
   - **Mitigation 2**: Cross-train second engineer on critical path items now, while original engineer can mentor

6. **Assign owners**: Who monitors each risk and triggers mitigation if needed? Tech lead or specific engineer?

7. **Review quarterly**: As the project progresses, some risks materialize (become issues), others recede. Keep the register alive

Example format:

```
| Risk | Probability | Impact | Priority | Trigger | Mitigation | Owner |
|------|------------|--------|----------|---------|-----------|-------|
| Third-party auth API changes | Medium | High | High | API deprecation notice | Build abstraction layer, monitor API roadmap | Backend Lead |
| Capacity loss to firefighting | High | High | High | > 25% of sprint on interrupts | Define on-call rotation, reserve sprint slack | Tech Lead |
```

## Anti-Patterns

- **Generic risk lists**: LLMs sometimes generate boilerplate risks ("scope creep", "communication issues") without grounding them in the actual project. Always make risks specific to your context.
- **Assuming mitigation is free**: LLMs suggest mitigations (extra testing, documentation, pair programming) without accounting for the time cost. Good mitigations have a cost; list it explicitly.
- **Set-it-and-forget-it registers**: A risk register written in month 1 and never updated is useless. Require quarterly reviews and updates when probabilities change.
- **Treating all risks equally**: LLMs sometimes list 20 risks without prioritizing. Focus on the 3-5 risks that could actually derail the project. Ignore the rest.

## Further Reading

- PMI. "A Guide to the Project Management Body of Knowledge." 2021. Chapter on Risk Management.
- Taleb, Nassim. "Antifragile: Things That Gain from Disorder." Random House, 2012.
- Larson, Will. "An Elegant Puzzle." Chapter on managing uncertainty and risk in projects.