Search This Blog


20 September 2011

An Approach For Wording Risks

Capturing risk is something which we all do as part of the projects we work on (or at least should do).

The risk registers I have encountered vary greatly in terms of the language used and the level of detail they go into. Sometimes a risk is expressed as just a couple of words, which although may speak volumes to its author, don’t always give enough information to all relevant project stakeholders - for example, ‘content migration’ or ‘server load’ or ‘key resources unavailable’ are some risks I have seen recently documented. The ambiguous language can become a problem when it comes time to rate the risk and to devise mitigation strategies.

I was recently introduced to a simple formula for wording risks, which I have found very handy in overcoming the shortcomings outlined above. It goes like this:

There is a risk that…
Which could result in…

The first part (‘There is a risk that’) describes what the thing is that could happen. ‘Server load’ doesn’t work in that sentence, but ‘web server capacity could be exceeded on launch day’ does. Note that it is specific in nature.

The second part (‘Because’) tells the reader why it could happen. This is the essential part for rating the probability of the risk, and also when thinking of ways to avoid or manage the risk. To run with the server load example ‘There is a risk that web server capacity could be exceeded on launch day because news of our product might go viral’.

The third part (‘Which could result in’) outlines what the consequence could be if that risk materialises to become an issue. This is important for rating the potential impact of the risk, and also for devising the strategies to deal with it. So, to cap off our example:

There is a risk that web server capacity could be exceeded on launch day
Because news of our product might go viral
Which could result in people not being able to access the website or buy the product online due to browser timeouts.

From there, our project stakeholders can consider the likelihood of the product going viral on launch day (certainly not a bad problem to have!), and what the impact of new customers not being able to access the website on such an important day would have on the business. Then specific strategies to deal with that risk can be devised, and the cost of having them in place (or not) can be weighed up.