I’ve been thinking a lot about risk registers recently. I feel like people don’t know enough about them, or reject them on principle for being “more process”.

I’ve worked in projects where the process was heavy, and like many, I very much didn’t like it then. But since moving to more “agile” environments, I’ve repeatedly been missing the structured aspects of writing things down, and wished for more rigour, more … process?

In this project-management post, let me tell you about my weird love for process, how well-crafted documents can be frameworks to organise conversation around, and semi-seriously try to convince you that you totally need a risk register.

What’s a risk register?

Note: this is called a “threat matrix” by some, but I will here call this “risk register” because it’s what I’m used to calling it, and “risk register” is cool because alliteration is always amazing.

At its most basic form, a risk register is a written list of all the things that could threaten the success of the project. That’s it. For each thing that can go wrong (supplier delivery delays, staffing shortage, regulatory threats), we write it down in an official-looking document.

It’s worth noting this document should be a living document, to be regularly revisited as the project goes on. Say every 2 to 4 weeks, a review should happen, looking again, point by point, checking: does the risk still apply; did it get worse? better? any new risks?

We’ll cover the content of a risk register soon, but at the core, there’s really not much to it: it’s just a big list of things that can go wrong, in a file that everyone in the project has seen and agrees about.

But, why?

Project managers have always had the need to understand what threatens their projects. This takes the form of asking developers questions about status/issues, discussions with other stakeholders about their timelines, reports to the executives on project progress, etc.

Information about identified issues can be important to share to the team: “forewarned is forearmed”. As usual, keeping people in the dark¹ does not make a healthy environment. So we already need to know about risks. And we also benefit from having a shared understanding of it, across the team? What’s better to do that, than to make a central record of it?

And as projects evolve, the risks change, so it should be a living document, not a frozen piece of scripture from months ago when the project just started.

So yeah, a risk register is basically what you’re already half-doing when you’re talking about project status and obstacles! Why not use the formal definition, and benefit from following a process?

In my experience, the very act of trying to enumerate all known risks, and discuss how they evolve, is beneficial. This is a very common side-effect of good process: The documents they output may be interesting, but the discussion they force us to have as they are drafted is what’s most useful.

So the structure of the document is just a framework to grow a conversation around: to fill each section of the risk register, we need to talk about a different angle of each risk. Lack of consensus and surprises are most enlightening, as they usually reveal new information: Disagreement on the severity of a technical risk may reveal that a bug has a simple workaround that wasn’t clearly visible to all members of the team. As always, complementary point of views give a more rounded coverage during assessments.

Note that I’ve mostly seen such a document formatted as a spreadsheet, rather than detailed risk tickets. It makes sense, as a spreadsheet limits the word count per field, and enables a nice overview, in a way that listing tickets may not provide.

I also find, personally, that the process of writing a document that summarizes a thought empties my brain of the need of holding onto that thought forever. I can now point to the document, so I no longer need to remember the details of that thought anymore. So having a risk register can make it easier to not have to worry about risks, because if there’s a risk, it’s in the register, not in the collective sum of brains of the people involved with the project.

In summary: By keeping a risk register you get less risky projects. With arguments:

• Doing it already: You’re already doing the risk management activity anyway by asking devs questions, use the damn register, formalize, adopt process
• Document as mental framework: The register format guides the conversations towards finding risks, the real value-add
• Off-your-mind, into the doc: A written document lowers the cognitive burden: don’t remember, look it up instead

Keen readers will notice that these same goes for most process: By following a process you get less risky projects, with the same arguments listed above.

What goes in a risk register?

Because every project is different, we don’t all need the same level of detail to guide the risk conversations. Still, let’s review the fields that commonly make up these documents, and a discussion of the purpose they serve.

Skipping the most obvious one: “description”, as we obviously should explain in a sentence what the risk is.

Severity

What happens if the risk we worry about really does manifest? Both what kind of bad thing, and how bad is it.

Do we look bad to customers? Do we lose money? A lot of money? Does someone die and/or the business has to shut down? This is usually a number, scale of 1 to 5.

Likelihood

Closely related to severity, we have likelihood of hitting the risk. Is this a once in a lifetime possibility, or a dead certainty? Once more, a scale of 1 - 5 is common.

Risk Level/Score (Severity x Likelihood)

A simple metric for how dangerous a risk, is to blindly multiply the severity by the likelihood. This has obvious traces in mathematics (via expectancy), and works out pretty well: a Severity 5 risk (maximum level of possible risk, “world ending”), but with Likelihood of “0” (no chance of it happening), score is 5 x 0 = 0.

Note that as humans, a high severity event with low likelihood is usually seen as more threatening and worth identifying, than a lower severity high likelihood issue (like car crashes) because we’re desensitized to these all-too-common risks. The simplicity of multiplication is not taking that into account though.

Risk level is usually a reported qualitatively, usually a color coded risk (Low/Medium/High = Green/Amber/Red), though some use the product of the two numbers instead as score.

Risk ID

When tracking many risks, and the risk itself needs discussed, we can’t always say “the parcel delivery delay risk” or “the risk that the hardware is faulty”. We may need to identify these risks to track them over time, and the easiest way is to give it a unique identifier, like a ticket number.

One common way is to use risk identified via <projectname/acronym>-risk-<number> with number positive integers: NEMO-RISK-12. This identifier is particularly important if we use tickets to track risks, though useful still in spreadsheets, when referencing a risk from outside the document.

Date first raised: history

We can’t always count on the risk register document being under meaningful version control, so it is useful to note when a risk was uncovered (“raised”, or “identified”), as it may be relevant for historical purposes, say for insurance reasons, or (unfortunately) discovery during prosecution.

Some variants of the risk’s history may be worth tracking, like the different stages moving from “initially reported”, to “acknowledged by management”, “reviewed by stakeholders”: each of those moments may be relevant to track, depending on the kind of process we’re under. I’ve mostly seen this section used to remember how long ago we identified the issue.

Again, remember not everyone needs all these fields we cover, but they can each shine a light on a different aspect of the risk being discussed, adapt your process to your kind of risks.

Expiry: status

Depending on the format we’re using, we need a way to archive risks that stopped being relevant. For instance the risk is about a phase of the project that completed already. This can be done as a separate tab for archived risks in spreadsheets, a separate column, or a ticket status in ticket trackers.

Response plan

What are we doing about this? In risk management, there’s apparently a few standard actions we can do about a risk:

Avoid it

Find a way to avoid the risk altogether, by changing scope or the approach such that we can’t hit it

Transfer it

Shift the impact onto someone else, such as by contracting insurance, or having contractual clauses deflecting the risk

Accept it

Informed with the full knowledge of its likelihood and impact, accept the risk as worth the opportunity being pursued

Mitigate it

Do something to reduce impact or likelihood of the risk

Escalate it

Ask higher authorities/project stakeholders to take care of the risk as we can’t deal with it ourselves.

Remembering that any response has secondary risks associated, that are worth reviewing: The act of mitigating a cybersecurity risk, by installing security software, raises operational risk, due to the potential of downtime when that software causes all the machines to go down².

Evolution

Is the problem getting worse, or better? This can be done by recalculating the Risk Level, and comparing it to last review’s, along with an explanation. A risk getting worse is obviously not ideal, and may warrant revisiting the response: Maybe it’s time to escalate?

Owner

For high priority risks, we can designate a person that owns that risk. This person has been delegated the task of monitoring and acting on it.

Obviously this doesn’t mean that person will fix the issue themselves, but they are the dedicated coordinator, point of contact who will follow up on the issue. As always, delegating responsibility without authority is a recipe for disaster, so this owner should be someone with enough delegated authority to investigate and act on what they find. Nor should this person be the nominated scapegoat.

Keeping process simple

Process! Don’t like it? Tweak it!

I believe hatred of bad process, like saying “90% of process is bad process” is meaningless because it falls under Sturgeon’s law: 90% of everything is bad, be it poetry or process!

Keeping a risk register is getting a document, but also it’s buying into a process. A lot of people don’t like process, because it’s too heavy for them. But that’s the beauty of it: don’t like it? Change it!

“Bad process”, is most commonly immutable process, frozen process, with different people defining it, from those who use it, and expensive barriers to changing it³. Good process incorporates feedback from previous events, adjusting after too much or too little rigour was applied.

There’s a whole continuum of processes that I’d describe as “YOLO to NASA spectrum”: We should obviously write down some things, to remember them or share to them with others. But then how much writing, is adjustable. How detailed do the records of decisions need to be? How much thought do you need to put in a plan before we decide it’s enough to act on it?

Same principle applies here, with the risk register: You’re not NASA, but don’t YOLO, so just keep a quick list of all the things that can be wrong in a spreadsheet, and revisit it as you need, and you’ve reaped 80% of the value for 20% of the cost. And when that is too much or not enough, update the process!

Counterpoint: Risk management is a sensitive activity

While I’m pretty clearly trying to sell you on risk registers, the real world is messier.

To discuss risk openly, we need to not be afraid to say inconvenient truths. This means broaching all sorts of impolite topics: the underperformance of a team, the possibility that we chose the wrong vendor, that a leader made a preventable mistake. If petty politics apply, we may end up with shallow risk conversations, never willing to raise actual risks to avoid political turmoil.

For that reason, risk registers are probably best kept as internal to the project, where the honesty of the discussion can be guaranteed, not exposed for the whole world to take offense at.

Some risks are also so common we don’t think to include them: Car accidents are very common, but they’re not necesarily the kind of risk we think of tracking on the register. Sometimes a risk is so routinely braved as to be living in our blind spot, needing probing to be teased out explicitly.

Similarly, in a risk assessment process, personal experience bias people towards or away from acknowledging specific risks. Only in very simple cases is a risk without controversy. This can cause bad estimation due to lack of consensus, with potentially catastrophic results. Proximity (or lack thereof) to the risk may bias evaluation of its full impact, leading to similarly poor outcomes.

All these factors make risk management a sensitive activity, more messy than a science. Still, the best weapon we have against projects failing, is still to try to enumerate what can go wrong, and learn from adverse events after the fact.

Conclusion

I’ve described the possible contents of a risk register, what a good document does as framework for important team discussions, and described process as a YOLO to NASA spectrum to find your place on.

You need a risk register!

Well, maybe not exactly, but managers always want to know what’s risking the success of their project, and writing it down is valuable, at that point you’ve pretty much got a risk register, might as well formalize it to get the full value out of it.

In the context of the “understanding vs awareness” matrix, this isn’t a silver bullet, as it doesn’t handle “unknown unknowns” (Things we are neither aware of nor understand), but just keeping track of all the rest (known knowns + known unknowns + unknown knowns) is the best we can, a systems-oriented solution to the chaos.

I’m only starting to reflect on my mixed feelings about process: Process can be the tutor that ensures our projects grow strong with good guidance. But we can’t afford to strangle the innovation and creativity with bureaucracy either. And as always, finding the balance is tracking a moving target.

I will keep pulling on this thread of thought around process, as it feels like a big topic I’ve stumbled onto, bumbling around with little qualification but youthful zeal to back me up. Expect more discussion on that topic.