Me: "Could you show me your risk register?" PM: "There are no risks. This project is 100% safe."
Risks are all around us. There is a risk that I might get struck by a meteorite. There is a risk that I might win the lottery (yes, risks can have positive outcomes). In a project management context, a risk is something – anything – that might happen that has an impact on the project outcome.
Most project managers understand the basics of risk management, yet (in my experience) it is often a sadly neglected area. I have yet to see a project that didn’t have a plan of some description, but I have certainly seen quite a few that don’t have a risk register. Personally, given a choice of the two, it is the plan that I would ditch first!
The process of risk management is straightforward:
- Identify potential risks.
- Classify them, in terms of likelihood and impact.
- Identify some mitigation actions – to reduce the probability and the impact.
- Identify contingency actions – what will we do if this risk becomes realised?
- Review and repeat, frequently.
Identification is not just down to the project manager. The whole team should be involved. A risk review is an opportunity for a high-value discussion with the team members.
There is a reason why “risk” is the seventh and last of The Seven Essentials. It is because the other six are all possible sources of risk. So when reviewing risks, make sure you consider: Benefits, Scope and Quality, Stakeholders and Communications, Plan, Team, and Suppliers.
Also, look at past experience. Ever wondered what “Lessons Learnt” reports are for? Here’s your answer! Review what happened on earlier similar projects, and learn from the mistakes they made. If there isn’t a Lessons Learnt library, seek out PMs with relevant experience. Have your team members done anything similar before? What did they learn?
Estimation of probability and impact may not be an exact science – a “gut feel” may be all you have to go on – but your guess will surely be better than anyone else’s. That’s why you are the project manager. Of course, the result of classifying the risks is the ability to focus on the most damaging and most likely dangers, whilst being aware of but not wasting time on the noise.
Mitigation actions are things you do now to reduce the probability and/or impact of a future risk. Some risks might warrant multiple mitigations. They are actions. They need to be carried out. Put them in your plan. And you don’t have to do them all yourself… that is what the team is for.
Contingency plans are things you do in the future if a risk actually happens, i.e. if it turns into an issue. By having “if this, then that” sub-plans already thought through, you can react quickly to a change in circumstance, thus reducing the impact on your project.
It is no disgrace if a truly unforeseeable event sends your project off-track. But if something that could reasonably have been foreseen takes you by surprise… well, frankly, I would start to question your choice of profession.
None of this is particularly difficult, is it? Nevertheless, in the hundreds of projects that I have reviewed over the years, it is the area most commonly found wanting. Neglected risk registers, or none at all, set my mental alarm bells ringing: is this project manager really in control?
The conversation at the start of this article really happened to me during a project review. It was a high-profile and fairly sizeable IT project. What would your opinion be of the PM?
Q2 Associates 