Project Risk Register

Play the opponent first, then turn the risks into a trackable table

You're a project auditor brought in to poke holes, and you assume this project will slip. Project info: [goal, deadline, staffing, dependencies]. Output a risk table with these columns: risk / trigger signal / impact (time, cost, quality) / likelihood / mitigation we can take / owner. Requirements: 1) at least 8 rows, covering staffing, external dependencies, scope change, technical uncertainty; 2) sort by likelihood × impact; 3) include only what we can still influence — list what already happened separately; 4) mitigations must be executable; no 'improve communication'.

How to use

Update only the trigger-signal column each week, or the table gets forgotten the week after it's written.

Good for

Before a kickoff or schedule review, 'will this slip' has to become a table you update weekly, not a worry voiced in the room.
The project is already showing slippage and you need to separate what can still be influenced from what has already happened.

Not for

The project is cancelled or in wind-down — risk management costs more than it returns; do a retro, not a register.
The team is still exploring direction under high uncertainty — a fixed register suppresses the trial and error you need.

Example

Input

Goal: enterprise SSO live by the end of November. Deadline Nov 30. Staffing: two backend engineers, one on leave from mid-November; one frontend. Dependencies: the IAM team provides the API, legal reviews the DPA.

What you get

At least eight risks across staffing, external dependencies, scope change, and technical uncertainty, sorted by probability times impact. Each row carries a trigger signal (say, IAM integration failure rate above 10%), the impact on time, cost, and quality, a mitigation, and an owner — mitigations specific enough to be actionable, such as getting the IAM sandbox by Oct 30. Put what has already happened, like the IAM API docs arriving a week late, in its own section.

Common mistakes

Generic rows like 'may slip' or 'resources insufficient' — with no trigger signal, nobody knows when to act.
Listing risks with no owner and no mitigation — the register becomes an anxiety list that gets read aloud once and forgotten.

Try tweaking it like this

Add 'Give each risk one quantified signal I can observe next week', so the table is actually worth updating weekly.
Add 'If we can only defend three, which three, and which do we drop?', for when you have to trade off with fixed resources.