I once came across an equation that described Risk in terms of Threat and Vulnerability. The equation is:
Risk = Threat x Vulnerability
From this equation, we can see that if there is no Threat (i.e. Threat = 0) then there can be no Risk. It doesn’t matter how vulnerable you are, if there is no Threat, you are not at risk since Risk = (0 x Vulnerability) = 0.
Similarly, if we are not vulnerable to a threat (i.e. Vulnerability = 0), then there will be no Risk either. It doesn’t matter how big the threat is, if you are not vulnerable to it, then you are not at risk since Risk = (Threat x 0) = 0.
We can use this equation as a core element of managing project risk.
For example: If there is a Threat of rain, and I am Vulnerable because I don’t have an umbrella, then there is a Risk of me getting wet.
If there is a Threat of rain, and I have the biggest and best umbrella on the planet, then I am not Vulnerable and hence there is no Risk of me getting wet.
If there is no Threat of rain, then even if I have the biggest umbrella on the planet I am not Vulnerable, and hence there is no Risk of me getting wet.
This gives us the basis for providing a solid structure for describing project risk.
And why do we want to do that? Because in my experience, the general level and quality of project risk descriptions is lamentable. I’ve seen plenty of organisations in which risks might have been written as “It may rain” or “We may lose a key resource”. Neither of these risks are complete, because it leaves us wondering what the impact is. We are drawn to ask “So what?”. “The policy wordings may not be completed on time”. So what? Who cares? Why should we worry? It doesn’t tell us. We are none the wiser.
So we want to structure risk description in such a way that we don’t need to ask “So what?” using Threat, Consequence, Vulnerability, Impact and Outcome.
[There is a possibility that it may rain] (Threat). If so, [I may get wet] (Consequence) because [I have no umbrella] (Vulnerability). This may [ruin my hair] (Impact) the outcome of which would be [increased cost and delays] (Outcome).
So the formula is:
[Threat]. If so, [Consequence] because [Vulnerability]. This would [Impact], the outcome of which would be [Outcome].
Now we can revisit the policy wordings risk:
“There is a possibility that the policy wordings may not be completed on time. If so, the project will run late because the policy wordings are on the critical path. This would mean we would miss the regulatory deadline, the outcome of which would be financial loss, repetitional loss and penalty sanctions imposed by the regulators.”
So, what is the risk?
Is the risk that the policy wordings may be late? or is the risk that we might suffer financial loss, repetitional loss and penalty sanctions?
I would expect to see the risk short-name written as:
“Penalty sanctions due to policy wordings not completing on time”.
In other words the Risk is Outcome due to Threat. And, as we saw earlier, if you reduce the vulnerability (i.e. the policy wordings are not on the critical path), then there will be no impact (we won’t miss the regulatory deadline), and hence no adverse outcome (we won’t get fined).
These may be trivial examples, but they illustrate the elements of a risk sufficiently well.
Of course, there may be other attributes we want to capture about a risk, to help us manage it.
Impact Score (1 to 5) – a range which describes the “impactfulness” or Scale of Impact of the risk. You might also attribute statements which are meaningful to your business against each value. For example: “5 – Has significant compliance or regulatory impact”.
Probability Score (1 to 5) – a range which describes the probability of an impact (due to a risk) occurring: “1 – very low chance”, “5 – Very high chance”, etc.
Scope – an indication of how far-reaching the impact might be, were it to occur. For example, Local (Impact might be absorbed by the project), Project (Impact may affect other projects), Programme (Impact may affect projects in other programmes), etc.
Impact Date – the specific date on which the impact may occur, if known (e.g. “Y2K”).
These attributes can be used to organise, categorise, filter, but the real question is:
“What are we going to do about it?”
What can we do about it?
Well that depends on the risk, of course, but generically speaking we can mitigate the risk by a) reducing our vulnerability; b) reducing the threat.
Reducing our vulnerability
How do you “reduce vulnerability”?
In the rain example, we were vulnerable because there was a threat of rain and we didn’t have an umbrella. Chances are we’d get wet, ruin our hair, be late and incur unplanned cost.
So to reduce our vulnerability, we can buy an umbrella. That too will incur a cost.
And we need time out to buy it, undergo training, testing maybe.
In other words, this mitigation strategy may need some governance of its own: Requirements, a plan, procurement, testing, implementation in order to reduce our vulnerability to the threat.
Another mitigation strategy may be to “Stay inside”. No procurement, no testing, no plan, no requirements.
So in order to mitigate the risk by reducing our vulnerability to a threat, we may need to launch a change initiative – with all the governance that implies – or it may simply mean reconsidering our plans and “not going out”. The choice is down to the project leadership team.
Reducing the Threat
How do we reduce the Threat? Can we reduce the threat?
Again, in the rain example, “reducing the threat” translates as “reducing the chance of it raining.”
Which is probably a little tricky.
Because it’s an External threat, over which – as mere mortals – we have little or, let’s face it, no control.
So what about Internal threats?
Internal threats are those over which we have some control.
The wordings example states that the “policy wordings may not be completed in time.” Why is that? Is there anything we can do to reduce the likelihood of this situation arising?
Well, we could allocate more staff to the job of writing the wordings? We could reduce the burden of other non-critical work so that the wordings team can concentrate on the critical activities.
And there may be other things we can do too to reduce the internal threat. Why? Because we have some control over them.
Of course, there are many other aspects to managing risk which I have not touched on here.
The point is though, that unless you understand all of the elements of a risk (internal or external threat, vulnerability, impact, outcome, consequence), it’s difficult to justify your strategy to mitigate against it.
And it’s difficult too to really understand what you’re mitigating against.
“It may rain” doesn’t hack it.