A Risk Register Nobody Looks At Is a Liability, Not a Control

"Do we have a risk register?" "Yeah, it's on the SharePoint." "When did we last update it?" "Kickoff, I think."

That exchange happened in a governance meeting I sat in about a fortnight before the thing on row eleven of that register happened, on schedule, exactly as described, with the impact that had been written down eight months earlier. Nobody had read row eleven since the day it was typed.

Here's the thing people miss about writing a risk down and then ignoring it.

An undocumented risk that lands is bad luck, or at worst a gap in your thinking. A documented risk that lands, with your name in the owner column and no activity against it since kickoff, is a record proving you knew, you assessed it, you assigned it to yourself, and then you did nothing for eight months.

That's not a control. That's a signed confession sitting in a folder, waiting.

I'm being deliberately hard about this because the reflex in most organisations is that having the register is the thing. Somebody asks "is there a risk register" and everyone relaxes when the answer is yes. The existence of the file gets treated as the risk being managed, and the gap between those two things is where projects actually fail.

So the test isn't whether you have one. The test is whether anything in your project changed in the last month because of something in it. If nothing did, you don't have a risk process. You have a spreadsheet, and a liability.

Related sin, and it's the most common one I see: registers that have quietly filled up with issues. A risk is something that hasn't happened yet. An issue has already happened and is now just a problem you own. When the row says "the client's test environment is unavailable" and that has been true since April, that isn't a risk any more. It's an issue, and it needs a fix and a date, not a likelihood score. Mixing them means the genuinely forward looking items get buried under things that are already burning, and after a while nobody reads any of it because most of it is old news.

The reason nobody looks at your register is almost always that it's too long. I've inherited registers with sixty entries. Nobody can hold sixty things in their head, so the brain does the sensible thing and holds none of them.

So cut it, and be ruthless about what survives. My working rule is that a project of normal size has somewhere between six and twelve risks worth actively managing at any one time. Everything else either gets accepted with a note saying you accepted it, or closed, or it was never really a risk, it was an anxiety.

What earns a row:

A named owner who is a person, not a team. "Infrastructure" has never once mitigated anything.

A description written so that someone outside the project understands the consequence. Not "resourcing risk". Try "if the two engineers certified on the storage platform are pulled to the billing programme in September, the migration testing stops for at least four weeks." That sentence does the work of a likelihood column and an impact column on its own.

Two plans, and they are different things. Mitigation is what you do now to make it less likely or less painful. Contingency is what you do if it happens anyway. Most registers have a vague gesture at the first and nothing at all for the second, which is exactly backwards, because the contingency is the one you'll need under pressure when there's no time to think.

A date by which the position changes. This is the one everybody leaves out and it's the one that makes a register move. A risk without a review date is a risk that will be looked at never.

Here's the shape in practice. A network refresh for a theme park operator, one row, the whole row:

Risk: the hardware for phase two is on a fourteen week lead time and the order isn't placed, so if it slips past the second week of August the rollout across the attractions misses the closed season and runs into the March opening weekend.

Owner: the delivery lead, by name.

Mitigation: get the order raised by 8 August, and confirm with the supplier in writing whether partial shipment is possible.

Contingency: if the order isn't placed by 8 August, phase two is re-planned for the following closed season and we tell the operations director in the same week rather than in October.

Review: 1 August.

You could hand that to a finance director and they'd know exactly what to do with it. Four sentences. No scoring matrix, no colour coding, no heat map. Heat maps are a way of making a register look managed to someone who is not going to read the rows.

A register only stays alive if there's a recurring moment where somebody is obliged to talk about it out loud. Not a report. A conversation, with the rows on screen, where you go line by line.

Fortnightly, twenty minutes, same slot. Four questions per row and nothing else:

Has this become an issue since last time? If yes, it leaves the register and goes into your issues list with an action and a date today.

Has the likelihood or the consequence changed? Say why. "Their infrastructure director confirmed the September freeze, so this went from possible to near certain" is the single most useful sentence anyone says in these meetings.

Did the mitigation happen? If it didn't, either it happens this fortnight with a name against it, or you accept the risk formally and say so.

Is this still worth a row? Closing risks is not admitting you were wrong to raise them. A register that only grows is one nobody will read by month four.

Twenty minutes, twice a month. That's under an hour a month to keep the thing honest, and it's the cheapest insurance in delivery management. The reason people skip it is that it feels like administration when nothing has gone wrong yet, which is precisely the window in which it works.

Open your register. Count the rows. If there are more than twelve, you are going to cut it down to your genuine top ten, and you are going to do it in one sitting rather than gradually.

Move anything that has already happened into an issues list with an owner and a date. Close anything that's no longer live. For whatever survives, put a real person's name and a review date in every row, and where the contingency column is empty, write the sentence that says what you'll actually do if it lands.

Then send the cut down version to your project sponsor with one line: "This is the list I'm actually managing. Tell me if you think something's missing." If they add one, that's the most valuable row on there, because it's the one they were already worried about and had not said out loud.