A risk register is the easiest project artifact to produce and the hardest to keep useful. Most last six weeks. By month three, the spreadsheet is open during status meetings and closed the rest of the time. By month six, the risks listed bear no resemblance to what the team is actually worried about. By close, nobody reads it.
This is preventable.
Why most registers die
The standard register is built to look thorough at the point of creation. It has 30–60 rows, four-axis scoring (probability × impact × velocity × proximity), categorisation taxonomies, owner fields, RAG status columns, and a tab for “closed risks.” It is a document optimised for presenting to a steering committee, not for use.
Three failure modes follow predictably:
- Too many entries to maintain. A register with 47 rows requires someone to update 47 rows. Nobody does. After two weeks, half the entries reflect stale reality.
- No clear “act on this” moment. A risk scored 3×3=9 (medium-medium) sits in the middle of a sorted list and gets ignored. The scoring system tells you the risk’s score, not whether to do anything about it.
- Disconnected from the schedule. Risks live in the register; the schedule lives in the Gantt; the two are never reconciled. A risk that threatens a specific milestone is recorded as a generic concern with no link to when it bites.
The fix is structural, not behavioural. You don’t get a useful register by reminding people to update the spreadsheet. You get one by changing what’s in the spreadsheet.
The format we use
Five columns. That’s it.
| Column | What goes in it | Why |
|---|---|---|
| Risk | A specific sentence in the active voice | ”Vendor X misses the May 12 milestone” — not “vendor delivery delays” |
| Owner | One person’s name | If two people own it, no one does |
| Trigger | The observable thing that means it’s happening | ”Weekly status from vendor X is missed twice in a row” |
| Response | What we do when the trigger fires | ”Reassign to backup vendor Y; cost +$8k, schedule slip 2 weeks” |
| Status | Open / Watching / Fired / Closed | Four states, no RAG |
No probability scores. No impact scores. No five-axis frameworks. Those numbers are made-up precision. The list is shorter — typically 8–15 rows for a six-month engagement — which means it’s actually maintained.
The weekly walkthrough rule
Once a week, the register is walked through with the project owner. Every open risk gets one of three actions:
- Still open, no change. Triggered? No. Confidence in the response plan? Still good. Move on.
- State change. Trigger fired → status moves to Fired and the response is enacted. Or a risk is no longer credible → moved to Closed with a one-line “why this stopped mattering.”
- New risks added. Things we’ve learned in the last week that weren’t on the register get added — using the same five-column format. No risks get added without a defined trigger.
Total time: 15–20 minutes a week. The output is captured in the status report, which means the register and the status are reconciled by construction.
When a risk becomes an issue
Once a risk’s trigger fires, it’s no longer a risk — it’s a thing that’s happening. Its status moves to Fired and it moves to the issues log, a separate one-page document with three columns: issue, owner, current state. Risks are about the future; issues are about the present. Conflating them is how registers become noise.
The risk register stops tracking the firing event the moment it fires. The issues log picks it up.
What we don’t put in the register
- Anything we can design out. If we can change the plan to make a risk impossible, we change the plan. The register tracks risks we’ve accepted, not risks we haven’t acted on.
- Category risks (“scope creep”). Too generic to have a trigger. We force the entry to be specific (“Owner adds scope outside the agreed brief without a signed change order”) or we drop it.
- External catastrophes we can’t influence (“the market crashes”). Acknowledged in the kickoff doc, not the working register. Listing them creates the illusion of management without changing behaviour.
What close looks like for the register
At engagement close, the risk register becomes one of the eight handoff artifacts. It’s the final state — every entry resolved with a one-line outcome:
- Closed (never fired) — what happened? Often: “designed out in week 4 by change to vendor structure”
- Fired and contained — what was the actual cost vs. the response plan estimate?
- Fired and uncontained — what did we learn for next time?
This final-state register is the most valuable artifact of the whole register practice. It’s the document a future project manager reads to understand what actually threatened this engagement and how it was handled. The intermediate versions are just bookkeeping.
A register that produces a useful final-state document at close has done its job. One that doesn’t, hasn’t.