Project risk register

You make the project's uncertainties visible early enough to act on them. A good register is short enough to be read, specific enough that each risk suggests its own action, scored on scales everyone understands the same way, and owned: every important risk has a person, an action with a date, and an early-warning sign that tells you it is starting to happen.

When to use

• "What could go wrong with this project?"
• "Set up a risk register for the launch."
• "The board wants to see our risks."
• "Run a pre-mortem with the team."
• Weekly during delivery, before the status report.

What you need

• The project charter and plan (scope, dates, budget, dependencies, suppliers).
• The people who know the work: collect input with brief_team or ask_teammate, or run a pre-mortem session the owner hosts.
• Lessons from similar past projects: session_search and memory, plus any retrospective notes.
• Where the register will live: a spreadsheet you build, or the team's project tool if connected on the Connections page.

Method

1. Find risks three ways, then merge duplicates:
   • Pre-mortem: ask the team to imagine it is the end date and the project has failed, and to write down every reason why, independently, before anyone discusses. Facilitation steps in references/register-template.md.
   • Assumption review: take every assumption in the charter and plan ("supplier delivers in 10 days", "data is clean", "Sam is available in November") and ask what happens if it is false.
   • Category prompts: schedule, cost, scope, people and skills, suppliers and contracts, technology and data, legal and compliance, customers, external events.
2. Write each risk as cause, event, effect: "Because the supplier's API documentation is incomplete (cause), configuration may take longer than planned (event), which would delay go-live by up to two weeks and add contractor cost (effect)." If you cannot name the cause, it is a worry, not yet a risk: dig further. If it has already happened, it is an issue: log it separately.
3. Score on defined scales (1 to 5 each; anchors in the reference): probability from rare to almost certain with percentage bands; impact on the dimension that matters most (schedule days, cost as % of budget, quality or customers, legal or safety). Score = probability x impact. Bands: 1 to 4 low, 5 to 9 medium, 10 to 16 high, 20 to 25 critical. Score with at least two people where you can and discuss big disagreements; they usually reveal a missing fact.
4. Choose a response for each medium-and-above risk:
   • Threats: avoid (change the plan so it cannot happen), reduce (lower probability or impact), transfer (contract terms, insurance), accept (with a contingency and a budget).
   • Opportunities: exploit, enhance, share, accept. Every response is an action with an owner and a date, not an intention.
5. Add a trigger and a contingency for high and critical risks: the observable sign that the risk is materialising (a missed interim date, a supplier's slow replies, a test failure rate) and the pre-agreed action if it fires.
6. Score residual risk after the response, so the owner sees what is left and can decide to accept it. Accepting a high residual risk is the owner's decision, recorded with their name and date.
7. Build the register with execute_code (openpyxl): one row per risk, score by formula, a 5 by 5 heat map with counts per cell, conditional colouring, and an issues sheet. Columns and code in the reference.
8. Review weekly: update scores, close risks whose window has passed, move materialised risks to issues with an owner and a fix date, add new ones. Track the trend of total high and critical risks. Report the top 3 to 5 in the status report (see project-status-report).
9. Escalate any critical risk, any risk whose response needs money or a scope change, and any legal, safety or security risk to the owner the same day. Legal, regulatory and security risks need a qualified person's view before they are accepted.

Worked example: two risks, scored and owned

	R1	R2
Cause	The supplier's API documentation is incomplete	The key user has leave booked 9 to 13 Nov
Event	Configuration takes longer than planned	The key user misses training
Effect	Go-live slips up to 2 weeks; contractor cost	Slow adoption; errors in month one
Probability x impact	4 x 4 = 16, High	3 x 3 = 9, Medium
Response	Reduce: API walkthrough workshop with the supplier (IT lead, 20 Oct)	Reduce: second training session on 16 Nov (Ops lead, 23 Oct)
Trigger	More than 2 open API questions after the workshop	Leave confirmed and no second session booked
Contingency	Hire the supplier's consultant for 3 days	Recorded session plus a one-to-one walkthrough
Residual	2 x 3 = 6, Medium	1 x 3 = 3, Low
R1 goes into this week's status report; R2 stays on the project lead's weekly review. If R1's trigger fires it becomes an issue with a fix date and the contingency starts the same day. Both rows, the heat map and the issues sheet come from the code in references/register-template.md.

Scales at a glance

Probability 1 to 5: under 10%, 10 to 30%, 30 to 50%, 50 to 70%, over 70% within the project's life. Impact 1 to 5 on the worst applicable dimension: schedule (under 2 days up to over 6 weeks), cost (under 1% up to over 25% of budget), customers (unnoticed up to reputation damage), legal and safety (none up to serious harm or a data breach). Bands: 1 to 4 low, 5 to 9 medium, 10 to 16 high, 20 to 25 critical. Agree the anchors with the owner once, then keep them fixed for the project.

The weekly review, in ten minutes

1. Has any trigger fired? Move that risk to issues, start the contingency, tell the owner.
2. Has any risk's window passed? Close it with a note.
3. Rescore the open high and critical risks; note what changed and why.
4. Add new risks from this week's status updates and decisions.
5. Put the top 3 to 5 by residual score into the status report with their next action.

Output

• risk-register-<project>.xlsx with sheets: Register (ID, date raised, category, cause, event, effect, probability, impact, score, band, response type, actions, owner, due, trigger, contingency, residual probability, residual impact, residual score, status, last reviewed), Heat map, Issues, Scales.
• A top-risks summary for the owner: the 3 to 5 highest residual risks, what is being done, and what they need to decide or accept.
• A show_card with counts by band (inherent and residual) and the top 5.

Checks before you finish

• Every risk is written as cause, event, effect and is specific to this project.
• Scores use the written scales; score = probability x impact everywhere.
• Every medium-and-above risk has an owner, an action with a date, and a response type.
• Every high and critical risk has a trigger and a contingency.
• Nothing already happening is on the risk list; it is on the issues list.
• Accepted high residual risks name who accepted them and when.

Pitfalls

• Generic risks ("resource constraints", "scope creep"). Make them specific or drop them.
• Scoring everything 3 x 3. Use the anchors; force a choice.
• Risks without owners, or owned by "the team".
• A register written once and never reviewed. It decays in two weeks.
• Mitigations that are intentions ("monitor closely"). Name the action and the date.
• Only threats. Opportunities (an early supplier slot, a reusable component) are worth managing too.
• Group-think in the pre-mortem. Collect reasons individually before discussing.

See also

• project-plan-and-timeline, project-status-report, operational-root-cause-analysis.