Risky business: it's all a little uncertain

How many times have you walked out of a risk and issue workshop, or worse still a RAID workshop, only to be left wondering what you had achieved? All too often, we commit extended periods of time to 2 or 3 hour long workshops on risks and issues in the belief that this is “the right thing to do” to be seen to be actively managing your risks.

It is not.

More often than not, scoring matrices are too complex, methodologies and phraseology become a sticking point for getting to the bottom of a risk or issue and you end up reviewing maybe 5 or 6 risks in detail without having covered so many of the things that are actually worrying you about your business operations, project or programme. There is clearly a need for a new approach.

Let's talk about uncertainty

First off, there is a need to reconsider how we approach risk — it's really all about uncertainty. This can help bring some clarity around what it is you are really trying to manage. When we talk about risk in a lay context one can be a risk-taker, which usually leads on to considerations of risk/reward and from the other perspective, there are those that talk about not doing things because they are too risky. What this tells us is that there can be an upside, or an opportunity, to taking risks but sometimes they can be threats.

By considering all of this under a single banner of uncertainty, we can adopt a more consistent approach to its management.

The essence of the uncertainty method is simple, break down the various parts into bite-size chunks and remove the need for lengthy workshops that result in brain drain, distractions and reduced productivity.

At its core, the uncertainty approach is considered from 3 perspectives:

• Cause: what condition makes the uncertain thing happen?
• Event: what is the uncertain thing?
• Effect: if the uncertain thing occurs, so what?

This helps provide a good structure to both identify and analyse items of uncertainty. Furthermore, you are provided with immediate options for management of the uncertainty as you can look to remove the cause or limit the effect (unless it is an opportunity, in which case you would want to maximise and exploit that). It is important to note that it is not a simple cause and effect relationship when it comes to uncertainty as that implies an absolute relationship with no element of uncertainty, or probability.

Consider the example of putting your lunch in the fridge in the morning, a chicken and avocado ciabatta from my perspective, but you leave the door to the fridge open — what might happen? Breaking this very simple scenario down into where the uncertainty lies:

• Cause: Left fridge door open
• Event: Sandwich will go bad
• Effect: I will go hungry or I will need to fork out cash to buy lunch

Based on the above example, there is no guarantee that the sandwich will go bad and as such it demonstrates my uncertainty. I can manage the uncertainty by simply closing the door to the fridge, at which point the cause of my uncertainty has now gone. Similarly, I can avoid the uncertainty altogether by choosing another approach for providing my lunch — buying it from a shop for example. Now although this example is extremely simple it does demonstrate that there is more to consider when talking about uncertainty than just the cause or the effect. Had I articulated the uncertainty as "I might go hungry", I am not offering any real useful information that could assist in managing the uncertainty. Of course for those that like to consider the full spectrum when managing uncertainty, there can be many causes and many effects with the same uncertainty. This means the context of the uncertainty is also important. Again with the above example, if the fridge is situated within a garage with poor insulation and the outside temperature is below 0C, I might not have as much cause for concern around heat-related incidents spoiling my chicken and avocado ciabatta!

Returning to the framework though, good practice would be to capture all the elements of uncertainty and rigorously document them, however best practice should be to capture the absolute minimum required to articulate what is worrying you. Using this approach, you are more likely to be able to communicate the uncertainties around your project, perhaps not with the same structure as would be desirable but to the extent that allows you to get on with doing something about it. That is what we are here to do after all — deliver projects.

Near, middle and far - prioritising what really matters

When considering the uncertainties that might surround your project, it is worth considering them against a time horizon so as to focus your efforts. A learned colleague of mine introduced me to the "near, middle, far" model a couple of years ago as a better way to group uncertainties. By removing arbitrary labels such as "less than 3 months proximity", this allows some flexibility in the definition of the terms but in such a way that it becomes more useful to those delivering projects and the stakeholders.

The model in practice though is less about when might the effect take place and more about when does action need to take place in order to manage the uncertainty. This is a key difference when compared to other risk management methodologies, which focus upon when the event might take place — relegating the mitigation or management of the uncertainty to a different field in the risk log. It is a more pro-active model of uncertainty management and it is definitely worth giving a go if you are struggling to "manage your risks".

It's all about communication

But how do you go about improving your communications of uncertainty to key stakeholders and governance forums? Risk logs are difficult to digest in these fora so I have developed a simplistic tool to improve the dialogue with stakeholders when it comes to managing uncertainty — the uncertainty cloud. This takes the form of a word cloud but with a key difference, the size of the word does not relate to its frequency in the log but rather its impact were it to occur. This uncertainty cloud is set across a backdrop of near, middle or far proximity to provide the context of when the risk needs to be managed i.e. the placement of the word on the map indicates when action first needs to be taken to manage the uncertainty.

When introducing a new tool into your project, the conversation in the first instance can be somewhat simple, along the lines of “it doesn’t look red enough”, but that is a good thing. You want to be encouraging a conversation about uncertainty and not simply stating a position. That is the path to actively managing your uncertainties and engaging your stakeholders rather than simply delivering a message in the hope that others will receive it and understand it (communication being a topic for another time).

So to start moving forward, rethink how your governance around uncertainty is setup rather than assuming you must do risk and issue workshops to please the auditors. The community continues to evolve and in time the assurance processes will also. It is worth having a rethink of your risk governance if you want to make your project's delivery... certain.