This article is part two of my look into project risk management, and today we are diving into trends and emerging practices, as determined by the PMBOK® Guide – Sixth Edition.
There are three risk-related trends that bear investigation and we’re looking at the first one today.
The first risk-related trend it’s worth considering is non-event risk.
Most risks that I’ve ever put on a project risk log relate to something happening or not happening. In other words, they are tied to an event. There is a thing that is going to happen that becomes the risk trigger. When the event happens, we acknowledge the risk has materialised and swing into issue management.
But not all risk relates to things happening.
Honestly, this is a bit of revelation for me. I’ve never spent much time thinking about the kinds of things that present risk to the project but that are not event-driven. I’m in the ‘average’ category of risk management, and it’s not one of the areas I would call myself an expert in (can we ever call ourselves experts in anything to do with project management? There’s too much going on and too many variables… I digress…).
The PMBOK® Guide – Sixth Edition talks about two particular types of non-event risk.
This is where uncertainty exists about something to do with what’s going on during the project. It is about recognising that the output of an event, activity or decision might not be exactly what we think. For example, the output of an activity might be above or below the target productivity measure.
I’ve kind of covered this on my risk log in the past by talking about people not having enough time to do their work or that testing takes longer because we find more bugs than I have allowed for in the project schedule – these could be understood as a variability risks.
I also once DIDN’t put a risk on the risk log about weather conditions, which would have disrupted our ability to get equipment to where it needed to go… and lo and behold, that project was hit by a snowstorm and we couldn’t deliver the kit.
We can manage these risks by using Monte Carlo analysis. Reflect the range of variation in probability distributions. They might not be perfect, but it will give you a better idea than guessing, and let you create an action plan to reduce the variability. The more you can reduce the variability, the more easily you can predict (and therefore manage) the output.
Ambiguity risk is about not being able to predict the future: we should all be able to put that on the risk log. This type of risk calls out the fact that we don’t know for certain what might be required for the project, for example in terms of technical solution – until such time as the solution is fully costed, architected and known.
Another example would be future developments in the world of regulation or compliance, which may change the direction of the project or the solution. I once managed a compliance project (GDPR – remember that?) and at the same time other regulation was being introduced that would have an impact on the work we were doing. The lack of information about what was coming made us wonder how much we would have to rework what we were doing. Despite the ambiguity, in that situation, we ploughed ahead, knowing we would have to incorporate subsequent changes when they were known. That actually was on the risk register, if I remember correctly.
For me, the point of including these two types of risk is to make it clear to stakeholders that we aren’t magical beings as project managers. Stuff goes wrong. We do our best. We are thinking about these things but we often need to clearly articulate that we don’t know what we don’t know.
Manage these types of risk by doing exactly that: define what isn’t clear (if that isn’t a contradiction in terms) and then work out how to make it clear. That could be through using third party experts, or through reducing ambiguity by prototyping, user workshops, incremental development, simulation and AI and so on.
Next time we’ll look at the other two emerging practices in project risk management. Watch this space…
Pin for later reading: