“Risk management – you either love it or loathe it” This is a quote from a project manager friend when I was discussing the changes we’d made to Psoda to make risk management easier. It got me thinking: What makes risk management so divisive?
I think it is down to 5 key things:
- That there is perception that in a programme or project environment it is a “must do” task that doesn’t actually add any value to the project, and takes up valuable time that the hard pressed project manager can ill afford.
- That no-one, apart from the anal PMO Nazis, actually reads the register, takes it seriously or takes any action to manage the risks that have been documented.
- The risks that have been documented haven’t been clearly articulated so no one has a clue as to what they actually are and what might happen if nothing is done about it.
- The mitigation plans either don’t exist or are nonsense. If the risk does actually occur, or God forbid becomes an issue, the plans are less than useless and the business has to go into fire fighting mode.
- The risk owner is not engaged, or is simply a name that’s been picked at random to complete the form. When the risk does occur, and we all know that over a project’s lifetime a goodly proportion of risks will occur, there is no one to own the problem and drive a resolution.
For me, risk has become a “love it” activity (sad I know). I’ll tell you why…
I was involved in a project that was part of a multi billion dollar, multi year programme of work. The team was a very gung ho, can do bunch, with combined experience in the hundreds of years. However, the environment was difficult, with multiple suppliers all having to collaborate to build the solution that was acceptable to the customer.
There was no risk manager, which in itself should give you an idea of the mindset of the programme, and risk was very much a tick in the box activity.
The risks that were identified in the register were very generic and had little or no substance to their descriptions. Most of the risks were categorised as mitigate, but the mitigation plans were 1 or 2 lines at most, with the owners being identified by title, e.g. programme manager, but no actual names.
So, as always happens, a risk that had been logged in the risk register came to pass. The project had failed to engage the key stakeholder groups sufficiently and there was a massive user backlash towards the solution during the initial pilot phase.
The team went back to the risk register to pull out the mitigation plan to kick start the resolution process. Only to discover that the risk register had rated this risk as low, with the mitigation plan of “engage stakeholders”. The risk owner was identified as the programme manager, but when the programme manager was approached he knew nothing about it and hadn’t done any work to ensure the risk, was in fact, mitigated.
To cut a long and boring story short, this one risk brought the project to its knees, cost the business 10s of millions to resolve, cost a number of very talented people their jobs and delayed the implementation of the solution by 5 years.
An independent review of the project in question flagged the lack of sound risk management as a leading cause of the project’s failure to deliver a robust solution on time and within budget.
And that, ladies and gentlemen, is why I have become a lover of robust risk management.
Next time we’ll look at some things you can do to overcome the problems I described above.