PM Mapped
Home / Module 4 / The Risk Register
24
MODULE 4 · MANAGING DELIVERY RISK · TOOL 24

The Risk Register

Delivery risk is the chance an initiative won't ship on time, in scope, or at quality. The defining choice is when you confront it — before the work, when mitigation is cheap, or after, when risks have become problems.

▸ Try the interactive tool
SolvesGetting blindsided by risks someone already saw coming.
Category · Managing Delivery Risk Complexity · Mid Time to apply · Per initiative Pairs with · Release Management
A WHAT IT IS

The framework

Delivery risk is the probability that an initiative won't be completed on time, within scope, or at the expected quality. Every initiative carries it, and the defining choice for a PM is when they confront it: before the work begins, when risks can still be mitigated cheaply, or after they've already materialised as problems. A risk register is the tool for confronting them early.

A risk register is a living list of identified risks, each rated by likelihood and impact, each with an owner and a mitigation. The discipline it forces is proactive rather than reactive: instead of being surprised by problems, you've already named the things that could go wrong, decided which are worth mitigating (high likelihood × high impact), and assigned someone to act. The register's value isn't the document — it's that the act of building it surfaces risks while there's still time and cheap options to address them.

WHAT A RISK ENTRY CARRIES

The risk (what could go wrong) · likelihood · impact · an owner · a mitigation (or contingency). Prioritise by likelihood × impact; confront risks early, when mitigation is cheap.

TRY IT

Try it yourself

B WHY IT MATTERS

What it prevents

Risks confronted early can be mitigated cheaply; the same risks ignored until they materialise become expensive problems — and the only difference is whether you looked ahead.

The shortcutWhat it costsWhat it gives you instead
Reactive risk-handlingSurprised by problems that a register would have foreseen.Proactive identification confronts risks while they're cheap to fix.
All risks treated equallyEffort spread across trivial and critical risks alike.Likelihood × impact focuses mitigation on what matters.
Risks with no ownerEveryone assumes someone else is watching it.An owner per risk ensures each is actually monitored and mitigated.
Identification without mitigationA list of worries that no one acts on.Each risk pairs with a concrete mitigation or contingency.
C HOW TO RUN IT

Step by step

1

Identify the risks up front

Before the work begins, brainstorm what could cause it to miss on time, scope, or quality — technical, dependency, resource, external. Confronting them early is the entire point; surprises are just risks you didn't name.

2

Rate each by likelihood and impact

Score how probable each risk is and how damaging if it occurs. This is what lets you prioritise — a high-likelihood, high-impact risk demands attention a remote, minor one doesn't.

3

Assign an owner to each

Every risk worth tracking gets a named owner responsible for monitoring it and acting if it materialises. Unowned risks are the ones that blindside you.

4

Define a mitigation or contingency

For each significant risk, decide how you'll reduce its likelihood/impact (mitigation) or what you'll do if it happens anyway (contingency). A register without actions is just a worry list.

5

Review and update it as a living document

Revisit the register through the initiative — risks change, new ones emerge, others pass. A register written once and filed is worthless; the value is in keeping it current.

D IN PRACTICE

A short illustration

IN PRACTICEproactive vs reactive

Two teams ran similar initiatives. One never formally considered risk — they just started building, and were repeatedly surprised: a key dependency slipped, a technical unknown proved hard, a resource went unavailable. Each surprise became a costly, scrambling problem because it was confronted only once it had already materialised.

The other team spent an hour up front building a risk register — naming those same possibilities, rating them, assigning owners, and defining mitigations. The dependency risk got an early conversation that prevented the slip; the technical unknown got a de-risking spike before it could derail the build. The risks were identical; the difference was when each team confronted them — and confronting them early made them cheap.

The lesson: delivery risk is defined by timing. The same risk is a cheap, manageable thing when named in advance and an expensive, scrambling problem when it ambushes you — and the register's whole value is forcing the early look.
E THE ARTIFACT

The risk register

The deliverable is a living register — each risk rated by likelihood × impact, owned, and paired with a mitigation — reviewed throughout the initiative.

FieldPurpose
RiskWhat could cause a miss
Likelihood × impactHow to prioritise it
OwnerWho monitors & acts
Mitigation / contingencyHow it's reduced or handled
F THE SO-WHAT

Why it matters

THE KEY INSIGHT

Delivery risk is going to exist either way; the only choice is whether you meet it early, on your terms and cheaply, or late, on its terms and expensively. The register is simply the discipline of choosing 'early.'

What makes the register work is that the document is almost beside the point — the value is in the act of building it, which forces a team to confront, in advance, the things it would otherwise rather not think about. Naming a risk, rating it, and assigning an owner converts a vague background anxiety into a specific, actionable item that someone is watching. And rating by likelihood × impact keeps the effort proportionate, so attention goes to the few risks that could genuinely sink the initiative rather than being spread thin across every conceivable worry. A team that builds and maintains a register trades a small, uncomfortable hour of early honesty for a large reduction in expensive mid-flight surprises.

G MISTAKES & LIMITS

Common mistakes

Handling risk reactively

Waiting for risks to become problems makes them expensive. Identify them up front.

Treating all risks equally

Spreading effort thin. Prioritise by likelihood × impact.

Risks with no owner

Unowned risks blindside you. Assign a named owner to each.

Listing risks without mitigations

A worry list isn't a register. Pair each risk with a concrete action.

When not to use it

H CONNECTS TO

Where this sits in the toolkit

Mitigated by → Release Management

Decoupling deploy from release (Tool 18) is a powerful mitigation for launch risk.

Echoes → the Four Big Risks

Delivery risk (this tool) complements discovery's value/usability/feasibility/viability risks (Module 3, Tool 01).

Owned within → the PM–Tech Lead Relationship

Technical delivery risks are often owned and navigated with the Tech Lead (Tool 20).

Feeds → stakeholder communication

Surfacing risk honestly to stakeholders connects to the influence skills of Module 6.

TRY IT YOURSELF

Build a five-risk register

For an initiative you know, list five things that could cause it to miss on time, scope, or quality. Rate each by likelihood and impact, and note who'd own it.

For your highest likelihood × impact risk, define a concrete mitigation you could start now — while it's still cheap.

If naming the risks in advance turns vague anxiety into specific, ownable actions, you've felt the register's real value — it's the act of confronting risk early, not the document, that pays off.