Building a Risk Register That Prevents Surprises

Identify before you score

Run a structured identification session rather than collecting risks by email. Assumption analysis works well: list every assumption in the plan and ask what happens if each one is wrong. A pre-mortem, where the group imagines the project has already failed and explains why, surfaces the risks people are reluctant to raise directly.

Add a review of lessons learned from two comparable past projects. Organisations repeat their own failure modes with remarkable consistency, and the previous register is usually the highest-yield source available.

At this stage go for volume over precision. Filtering is cheap; remembering a risk nobody wrote down is impossible.

Score consistently

Use a five-by-five probability and impact matrix with written definitions for each band. Without definitions, 'high impact' means whatever the loudest person in the room thinks it means, and the resulting heat map is decoration.

Define impact across at least three dimensions — cost, schedule and reputation or compliance — and score the worst of the three. A risk with modest cost consequences and severe regulatory ones is not a medium risk.

Record the score date alongside the score. Risk exposure changes as the project progresses, and an unstamped score tells you nothing about whether it is current.

Respond, own and review

Every risk above your threshold needs three things: a named individual owner, a chosen response strategy, and a review date. Ownership by a team or a department is functionally the same as no ownership.

The four responses for threats are avoid, transfer, mitigate and accept. Acceptance is a legitimate choice when made explicitly and recorded — what damages projects is implicit acceptance by inattention.

Review the top ten risks fortnightly and the full register monthly. Close risks that have passed, promote realised risks into the issue log, and be willing to delete entries that were never credible. A register of two hundred stale rows is worse than one of twenty live ones.

Common register failures and how to avoid them

The most frequent failure is a register that exists only for the audit. If nobody reads it between gate reviews, it will not change a single decision, and the effort spent maintaining it is pure overhead.

The second is scoring inflation, where every risk drifts towards high because owners fear being blamed for underestimating. Written band definitions and a calibration session with two or three example risks fix this quickly.

The third is confusing risks with causes and effects. 'The vendor may deliver late' is a risk; 'the vendor has three competing projects' is a cause; 'we miss the go-live date' is an effect. Writing all three in a single structured sentence makes responses far easier to design.

Finally, watch for registers with no closure activity. A healthy register shrinks as often as it grows, because passed risks are retired and realised ones move to the issue log.