Making Risk Statements Less Risky

Much has been written about the risk register. It really is one of the project manager's best friends. A particularly good article on the risk register was written by Natasha Baker. In fact, I'd recommend that you read that article first, and then come back here. I'll wait.

Good. You read it? Welcome back.

So now that you're familiar with what it is, let's discuss how to use it - really use it - to help you not only with your current projects but for projects yet to come.

The key is something called the Risk Statement.

To make the risk register useful, one of the most important, yet least understood aspects of a risk register is the entry of the risk itself. You can easily fail right at this point. For example, how many of you have seen signs near airports that say, "Low Flying Planes"? My question: okay, great...now what? How does this affect me? Am I supposed to hold up a butterfly net and try to catch one? What's missing for me in that sign, and in many risk registers, is a statement of the risk in such a crystal clear way that communication about that risk is siimplified.

This is accomplished with a well-formed risk statement.

This seemingly routine task can be done very well - leading to a powerful risk register, or poorly, leading to a risk register that not only is ineffective, it actually could have negative effects because it communicates the wrong risks and could lead to the wrong risk responses.

A strong example of how to do this is found in Hillson and Simon's "Practical Project Risk Management". They advocate the use of metalanguage (for those of you outside the programming world, this is kind of like taking your human brain and writing in such a way that your thoughts could easily be turned into a computer program). For our purposes, think of metalanguage exceedingly grammar to follow when entering a risk statement into the risk register.

As the Hillson/Simon book says, use this form:

"As a result of <definite cause>, <uncertain event> may occur, which would lead to <effect on objective(s)>.

Let's break this down from the end back towards the beginning.

At the end of this risk statement metalanguage is perhaps the most important piece. Think about it. Effect on objectives. Project objectives, that is. All of our risks (and that includes threats as well as opportunities) should be focused on the effect that they have on the project's objectives. Not general things like the country's economy, or being nice to people, but specifically an identified project objective. If the risk has no effect on a project objective, kick it out of the risk register. You should be able to make direct connections between the effect of a risk event taking place and a project objective or perhaps more than one objective.

Each risk statement needs to mention what that is.

Continuing backwards through the statement. <uncertain event> means whatever is the root cause of the risk. So this could be:

• we could misunderstand the government requirement
• we may be able to learn from the interaction with this new subcontractor
• we might have an unexpected interoperability issue with these two vendors

Note the probabilistic nature of these assertions, indicated with the italicized word.

And, at the head of the risk statement we find:

<definite cause>

The definite cause is the trigger. This does not have an uncertainty element with it, as does the uncertain event.

So here we would find causes like:

• We're using brand-new software
• We're outsourcing production
• We are working within the environment of a newly-merged company

Note the lack of uncertainty here. We are declaring that these things are true.

So although this may lead to some longer risk entries than you are used to, all of them should look something like this:

"Because we are using brand-new software, unexpected integration errors may occur, which would lead to spending more time and money than we planned for.

or

"Because we are working in a merged-company environment, we might be able to combine project management practices, which could reduce the project planning time significantly."

In closing - I really want to urge you to put diligence into the Risk Statement. Try to avoid the "Low Flying Planes" syndrome. Give your project a fighting chance to get off the ground - and stay in the air for the full duration of your project flight - by clearly stating the risks and then using the risk register technique to communicate risks to your proejct team and to future project teams.