Are You Making These Risk Mistakes?
Ten common problems that can undermine your project’s success
Risk management can be boring, complicated, difficult, overwhelming, obscure, overly technical, overly detailed, and not detailed enough. It’s hard to get it right. Here are ten common risk mistakes we see all too often on projects.
1. Poorly defined risks
The key with risk is (1) measure against a baseline, and (2) provide enough information in the definition to be able to estimate likelihood and impact. “Weather” is not a risk. “Bad weather” is not a risk. “Worse weather than typical, resulting in additional costs and schedule delays” is getting there, but still might need some additional detail to be able to define what the actual risk event is, because the impact could be different depending on if it’s excessive rain, high winds, or a longer winter season. Write your risks for your future self.
2. Poorly organized risks
A risk register is a collection of data, and it’s most useful when people can remember and find what’s in it. If the register is just a massive, disorganized list, it’s hard to put your finger on the important information, and it’s easy to miss things. Categories, subcategories, and metadata are very useful (or even a full risk breakdown structure). So is a reasonably readable format, availability to the project team, and regular re-familiarization. It’s worth spending time on planning this out up front.
3. If everything’s high priority, then nothing is
When quantifying risk, most people use some form of risk matrix to guide likelihood and impact assignments. The mistake is not thinking about the levels in those matrices and whether they fit your project. Sometimes you don’t have a choice, because the organization has a pre-defined matrix, but if you’ve got a $100 million project and your “max” cost impact is >$1 million, it’s going to be pretty hard to distinguish between your top risks. In addition, if you’re using your risk costs to define your contingency (recommended), that kind of mismatch could greatly underrepresent the true potential cost. If possible, every project should begin with a calibration exercise for your risk matrix, defining what the “worst case” really looks like.
4. Focus on cost only
Sometimes registers don’t even consider non-cost impact, and sometimes cost just gets the most attention. But there are lots of ways for projects to go wrong, and they don’t all involve cost. Some of the most significant problems come with schedule delays. There are also the “soft” impacts, like upset stakeholders or loss of trust from management. Any project manager who’s experienced these can tell you that they don’t feel soft when they happen. It’s best to include these other types of impact when quantifying your risks.
5. Thunderstorm likelihood with tornado impact
This one is common, especially with poorly defined risks (#1). The team starts talking about the risk event, and there are two scenarios: scenario A is pretty minor, but also pretty likely, and scenario B is rare but very serious. If people are concerned about B, the serious event, but also aware of A, the likely event, it’s easy to end up assigning the risk a very high likelihood as well as a very high impact. Some risk quantification practices even encourage doing this, where impact is a “worst case” approach. But this overrepresents the risk severity and takes attention away from other, possibly more important risks.
6. Over-contingency
“Cost” risk can be deceptive. For example, if there is a risk of loss of funding, even though that could mean the project is terminated, that is not a risk that should add cost to the project. A project can’t hold contingency for loss of funding. Trying to do so just means the project estimate will be inflated — which could actually make loss of funding more likely. A second example could be increased costs of operation, which also don’t usually come out of a capital budget. Think carefully about whether the costs you define will actually accrue to the project. These risks could be significant, and they should be captured and analyzed, but they shouldn’t affect your contingency. #1 and #4 make this worse, and #5 is an additional way for this to happen. Watch out for it.
7. Too much reliance on post-mitigation quantification
Pre- and post-mitigation quantification is common, and it can be a useful tool. But remember two things. First, post-mitigation quantification is not that trustworthy; the register is already a pile of assumptions, and now we’re looking into the future, assuming additional actions, and trying to predict what could change. It’s very easy for the rose colored glasses to take over. Second, and more serious, the post-mitigation quantification sometimes is used instead of the current quantification, and that is really counting your chickens before they hatch. Keep in mind that for the post-mitigation quantification to be real, all the mitigations have to happen!
8. Bystander mitigations
This is related to #7. The bystander effect is when everyone expects that someone else will take care of it, so nobody does. This can also happen with mitigation actions, and there are two ways for this to be a problem. The milder version of this is if the team lists the mitigation action in the register, but it’s nobody’s direct responsibility and so it never happens. The worse case is when the team just assumes that the mitigation will happen — i.e. of course we’re going to do regular inspections during construction — and it is never even listed as an action, so it doesn’t happen. When in doubt, write it down.
9. Risk as a product, not a process
If the team created the register just to tick the box and now it sits on a hard drive, that’s a lot of wasted time. For maximum value, the team needs to be aware of the project risk landscape (and needs to avoid #1 and #2). Risks change over time and the register should be a living document that reflects current reality. In addition, mitigations need attention (see #7 and #8). In an ideal world, a risk perspective would be incorporated into every project decision: does option A or option B lower risk? Do either of these options introduce new risks? One of the major reasons regular risk review is so useful is because it keeps risk fresh in the team’s mind.
10. Not doing risk management!
If you’ve recognized your previous or current projects in the past nine risk mistakes, don’t be too hard on yourself. As potentially damaging as these other mistakes can be, they’re still better than not thinking about risk at all. Risk management is an ongoing process, a register is a living document, and tomorrow is another day. The best time to start risk management was when the project started, but the next best time is right now.
