What goes in
- Risk description — specific. "Crew weather no-shows during pour week" not "weather."
- Probability (1–5) and Impact (1–5). Score = P × I.
- Owner — one person. Not the team.
- Response strategy — avoid / mitigate / transfer / accept.
- Trigger event — the observable signal that the risk is materializing.
- Status — open / mitigated / closed / occurred.
The four response strategies
| Strategy | What it means | Example |
|---|---|---|
| Avoid | Change scope or plan to eliminate the risk | Skip the feature that needs the unstable API |
| Mitigate | Reduce probability or impact | Add a backup vendor before the lead vendor commits |
| Transfer | Move to someone else (insurance, vendor) | Buy a service contract that covers downtime |
| Accept | Acknowledge, don't act unless triggered | Note the recession risk; revisit if leading indicators flip |
↳ in the wild
A 6-week-old register is already lying to you. The register is a standing agenda item, not a deliverable. Review it weekly. Risks close as their triggers pass; new ones surface as the project evolves.
Common pitfalls
- Listing outcomes ("budget overrun") instead of causes ("steel price spike Q3").
- Owner = "PM" for everything. That's not ownership, that's a list.
- Closing risks silently — always note when and why.
- Treating the register as a launch checklist instead of an ongoing risk-management practice.