On Risk: Probability, Impact and Perspective

Communicating risks proactively is often an important part of managing a project and managing expectations. I often find myself reminding Product people to sit down and think about all the reasons something might go wrong – ie, identify the possible risks – and then figure out what to do about them. That is, how do we mitigate the risk.

But the question is: which risks are worth mitigating?

Spending time discussing mitigation plans for risks can become quite unhelpful when either the probability is low, the impact immaterial, or the risk itself extremely fuzzy and unclear.

“There’s a risk that the building will be hit by a meteorite, and if that happens, I’ll be unable to submit the report on time.”

Ok. It’s technically true. You might get hit by a meteorite. But the probability is low – very low, right? So not worth talking about.

A more realistic example:

“I might have other projects or tasks come in, and if that happens, I’ll be unable to submit the report on time.”

OK. It’s also technically true – new projects can land at any moment. But do we know that today? What projects would they be, and what would be the impact? Both probability and impact are hard to predict. 

The Risk Function

A simplified and fairly reductive view of risk is that it is the combination of two things:

• Probability that the event will occur
• The relative impact should the event occur

So we can represent Risk with this simple function:

Risk = Probability(event) x Impact

When we map that on a graph, we get the following:
(roll over the graph to see the calculated value)

Both the Probability and the Impact need to be quite high to result in a high risk score. It is not enough for either probability or impact to be high - both need to be meaningfully high for the risk score to be high. Things that feel emotionally quite important and urgent are sometimes in reality not worth debating.

• Probability 0.7 × impact 0.7 = risk 0.49
• Probability 0.9 × impact 0.05 = risk 0.045
• Probability 0.2 × impact 0.2 = risk 0.04

But discussing risks - especially vague and hard to define ones - can cause a lot of noise and distraction, or in the worst case, panic. Risks that are hard to define are hard to mitigate, and that can create a sense of helplessness that contributes to that feeling of panic.

That's why I advise PMs to be mindful and deliberate about what risks to raise with a broader group, and which ones to monitor quietly.

A project risk register is not a single list of things requiring action. It is a triage tool. Some risks should be accepted, monitored or parked; others should be mitigated, transferred, escalated or avoided. The purpose is to focus attention where reducing risk is genuinely worth the effort.

What needs to go right?

When thinking about Project risks, rather than thinking about a long list of things that might go wrong, a helpful mental model is to ask: what are the things that need to go right?

Obviously lots of stuff needs to go right - but typically there are a handful of things upon which everything else rests... critical path activities, or things that if they go wrong, it blocks others from making progress.

These often turn out to be the most important 'risks' to mitigate.