Write clear risk statements and log them with likelihood, impact, an owner and a planned response.
Why it matters
Something will go wrong on every project. A key person gets sick, a supplier is late, a test reveals a design flaw. Teams that thought about likely problems in advance handle them calmly with a plan and a budget. Teams that did not lurch from crisis to crisis. A risk register is a simple table that makes this thinking visible, shared and owned.
Risks vs issues
- A risk is an uncertain event that might happen and would affect the project's objectives. "The food bank might not supply photos on time."
- An issue is something that has happened and needs action now. "The photos did not arrive."
When a risk happens, it becomes an issue, and you move it to the issue log. Risks can also be positive: an opportunity is an uncertain event that would help, such as "a volunteer designer might offer free illustration work".
Writing a good risk statement
Vague risks ("photos", "technical problems") cannot be managed. Use the cause, event, effect pattern:
Because the food bank's photographer is a volunteer with limited time (cause),
the photos may arrive after 15 January (event),
which would delay the visual design and the launch by up to a week (effect).
This tells you what to watch (the cause), what to prevent (the event) and why it matters (the effect).
Likelihood, impact and score
Rate each risk on simple scales, usually 1 to 5:
- Likelihood: 1 = rare, 3 = possible, 5 = almost certain.
- Impact: 1 = negligible, 3 = noticeable delay or cost, 5 = the project fails to meet its main goal.
Multiply them for a risk score (1 to 25). A colour-coded grid of likelihood against impact (a heat map) shows which risks need attention: high scores get active management; low scores are watched. Agree what the numbers mean at the start, in terms of days or money, so different people rate consistently.
Response strategies
For threats:
- Avoid: change the plan so the risk cannot happen (use stock photos with a suitable licence instead of waiting for new ones).
- Mitigate: reduce likelihood or impact (ask for photos by 1 December, and design with placeholders so the layout does not wait).
- Transfer: shift the impact to someone else, usually through a contract or insurance (a fixed-price contract with the web developer).
- Accept: do nothing now, but keep contingency and a fallback plan. Suitable for low scores or when responses cost more than the risk.
For opportunities the matching strategies are exploit, enhance, share and accept.
Escalate when a risk is outside the project's authority, for example a funding decision for the whole food bank.
Owners and triggers
Every risk needs one owner: the person who watches it and carries out the response. A risk owned by "the team" is owned by nobody. Add a trigger, an early warning sign: "no photos received by 8 January".
A worked example
| ID | Risk (cause, event, effect) | L | I | Score | Owner | Response | Trigger | Status |
|---|---|---|---|---|---|---|---|---|
| R1 | Volunteer photographer has limited time; photos arrive after 15 Jan; design and launch slip up to 1 week | 3 | 3 | 9 | Sam | Mitigate: request by 1 Dec, design with placeholders; fallback to licensed stock photos | None by 8 Jan | Open |
| R2 | Only one developer knows the host; if unavailable during launch week, go-live is delayed | 2 | 4 | 8 | Priya | Mitigate: pair the second developer on the host setup in week 3 | Leave booked in launch week | Open |
| R3 | Volunteers are not used to online sign-up; adoption is low in the first month | 3 | 4 | 12 | Coordinator | Mitigate: paper fallback for one month, launch email with a 1-minute video | Fewer than 20 sign-ups in week 1 | Open |
| R4 | A volunteer designer offers free illustrations; site looks friendlier | 2 | 2 | 4 | Sam | Accept (opportunity): say yes if offered, within the existing schedule | Offer received | Open |
Keeping it alive
A register written once and filed is useless. Review it in a short slot at every team meeting: new risks, changed scores, triggers hit, responses done, risks closed. Report the top three in each status report.
Everyone should feel safe adding risks. Thank people for raising them; a risk raised early is far cheaper than an issue found late.
Common mistakes
- Vague risks with no cause or effect.
- No owner, or the project manager owns everything.
- Listing issues as risks: if it has already happened, it is an issue.
- Responses that are not real actions ("monitor closely").
- Never reviewing it.
Quick recap
- A risk might happen; an issue has happened. Risks can be threats or opportunities.
- Write risks as cause, event, effect; rate likelihood and impact; score them.
- Respond with avoid, mitigate, transfer or accept (or escalate); give each risk one owner and a trigger.
- Review the register regularly.
Try it
Open the Do tab and build a risk register for your project.