---
name: project-risk-management
description: Identify what could derail a project, decide responses in advance, and track them rather than reacting when they happen. Use at project start and at every major checkpoint.
---

# Project risk management

Project risks are mostly predictable and mostly ignored until they
materialise. The value is in deciding the response before the pressure
arrives, when thinking is clearer and options are wider.

## Method

1. **Identify risks by category rather than free association.**
   Technical, dependency, resource, and external, since prompted recall
   finds more than open brainstorming (see pre-mortem).
2. **Assess likelihood and impact on the project, not in general.** A
   severe risk that cannot affect this project is noise.
3. **Choose a response per risk.** Avoid, mitigate, transfer, or accept.
   Acceptance is legitimate and must be recorded as a decision (see
   agent-risk-register).
4. **Assign an owner and a trigger.** What signal means this is
   happening, and who acts, because unowned risks are watched by nobody.
5. **Front-load the risky work.** Doing uncertain things early leaves
   time to respond, while deferring them concentrates risk at the
   deadline.
6. **Review at checkpoints, not just at kickoff.** Risks change as the
   project progresses, and a start-of-project list goes stale within
   weeks.
7. **Track realised risks and misses.** Which ones happened and which
   were never anticipated improves the next project's list.

## Boundaries

Risk management reduces surprise, not the possibility of failure. Very
long risk registers dilute attention and go unread. Some risks are
outside the project's control and belong escalated rather than managed
(see agent-escalation-ladder).