Project Risks? So What?

In my last ProjectBrief post, I talked about the importance of clearly identifying risks as events and making sure they aren’t simply stated as facts.  Here I’d like to briefly highlight the importance of including the consequence of those identified risks in the risk register.

Risk registers often include risks with little or no indication as to the consequence. Take a look at the register below, for example:

These are clearly articulated as risk events, so that’s good.  But if I hadn’t been in the risk identification session when these got added to the register, I’m left with a lot of questions, most notably “So what?”

Let’s take the first one, Scheduling classes on new site fails…when going live.  And?  It looks like it would be a pretty bad thing, but why?  Or what about Doug leaving?  Who is Doug and why do I care if he leaves?

A solid risk register tells the reader why they should be concerned about the events.  Add the consequence or impact of the risk to the register:

Now I understand and the impact rating of “5” makes total sense.

A good test for a risk register might be to give it to someone who hasn’t been involved in the project and see if they understand it.  Is it clear what the potential events are and do they have a sense for why those events matter?

I’m not really suggesting that you do that. In fact, we may use some discretion as to which stakeholders are privy to the project risk register.  But project stakeholders who are involved in risk management activities shouldn’t have to guess at the consequence of these events.  No one should be asking “So?”

Improving the quality of our register by clearly communicating both what the risks events are and what their impact would be helps ensure that our registers doesn’t get ignored as we move through the project. It’s easy to get excited about creating the initial register, but as the day-to-day project grind wears us down, if we aren’t reminded of the consequence of these events, it’s equally easy to put that register on a shelf and eventually forget about it.

Risk registers that sit on a back shelf and collect dust during a project’s life cycle can result in more issue management down the road, which is often a lot more costly than dealing with the risks proactively before they happen.