Amey-Thakur 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
- Identify risks by category rather than free association. Technical, dependency, resource, and external, since prompted recall finds more than open brainstorming (see pre-mortem).
- Assess likelihood and impact on the project, not in general. A severe risk that cannot affect this project is noise.
- Choose a response per risk. Avoid, mitigate, transfer, or accept. Acceptance is legitimate and must be recorded as a decision (see agent-risk-register).
- Assign an owner and a trigger. What signal means this is happening, and who acts, because unowned risks are watched by nobody.
- Front-load the risky work. Doing uncertain things early leaves time to respond, while deferring them concentrates risk at the deadline.
- Review at checkpoints, not just at kickoff. Risks change as the project progresses, and a start-of-project list goes stale within weeks.
- 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).