Mike Wild records the risks of an ineffective risk log, including generic description of risks and the pitfalls of groupthink
I was recently talking with a project manager regarding their project. After the kick-off there was a good deal of initial enthusiasm, and naturally good practice meant requirements gathering and risk identification. However, as the months rolled on, fatigue kicked in and the project manager just wanted it to be over.
Regarding risk management, what they were doing was sufficient to give the appearance of managing risk. There was a log and risks were documented; mitigating steps, along with owners, were identified.
But it wasn’t really effective. There were no new risks, many of the existing risks were described in a very generic way and there were no changes in the risk assessment in light of events or more recent information.
The risk log was being used for the sake of keeping up appearances – it was the right thing to be seen to be doing. In essence, risk management was regarded as a bureaucratic exercise that was simply part of the job.
It is action and not paperwork that protects projects
Clearly, it is difficult (for that read costly) to consider all possible risks on a project, so there is a balance to be struck when deciding what (not) to include. Every organisation is affected by various environmental factors (political, social, legal etc), but going to the extreme of listing all of these isn’t necessarily good practice, because it is action and not paperwork that protects projects.
Ask yourself: am I adding value in recording as much as possible, or just covering myself from future criticism?
Another potential pitfall is following the herd, where the ‘smartest’ people in the room dominate discussion and drive groupthink. Risks are accepted or glossed over because people are over-optimistic about the outcome of planned actions. Confirmation bias means people actively seek out and assign more weight to evidence that confirms their beliefs and underestimate the probability of negative events or risks.
The advantage of formal risk management run by the project manager is knowing when the risks of following the herd have reached an unacceptable level and need calling out. An experienced project manager will be aware of groupthink, at which point paper won’t address the issue, but action will.
Help stakeholders think about what they don’t know
The risk log is a key programme control which should allow stakeholders to be fully informed on key aspects of the programme. It should therefore add value and not just be another form to fill out.
- How often have key stakeholders commented on the risks being managed by the project?
- What might this mean for their areas of responsibility and what potential liabilities are they carrying?
- Do stakeholders know what to look for to identify the early signs of a risk translating into a problem?
The process should devote enough attention to help stakeholders think about what they don’t know. All too often a review of the risks is quick run-through and doesn’t really allow stakeholders the time to reflect and consider whether they are adequately covered for a potential issue.
What does evidence of active risk management look like?
Is it clear from the risk log exactly what uncertainties need to be actively managed? Risks should explicitly address areas of uncertainty, but in too many cases project managers save time and effort by defining risks generically: ‘use of third parties’, ‘poor customer experience’, ‘potential cost increases’. It is difficult to assign risk owners and assess such generic risks, and even more difficult to define effective controls.
Evidence of active risk management includes:
- identification of new risks as the programme progresses;
- closure of risks that have been effectively mitigated; and
- changes in the risk assessment in light of events or more recent information.
There are benefits to a peer review and having someone play devil’s advocate, looking for reasons why a project might fail to keep managers and developers from ignoring risks.
In a conference paper on risk management, speaker and writer Lev Virine puts it quite simply:
“Remember that the main ideas of risk and decision analysis are:
- identify risks which may affect your projects;
- analyse your project and determine the risks that would have the most effect on your project;
- determine workable project alternatives;
- identify which alternative will bring the most value; and
- select a course of action and monitor during execution.”
This calls for a succinct but insightful risk log that delivers quality thinking, avoids groupthink and facilitates the right conversations and effective actions. Does your risk log do that?
You may also be interested in: