You’re doing some risk management. You’ve identified risks and you’ve decided they are significant enough to warrant some kind of action. You need to take steps to minimize the risk should it happen – and ideally squash it totally.
Table of Contents
But what risk mitigation options are open to you? Below, we look at five different risk mitigation approaches that you could use on your project.
The correct mitigation strategy will depend on the nature of the risk and the company’s risk appetite. However, hopefully, the ideas below will give you a starting point for talking about mitigating actions for your risk log.
Time and time again, I’ve worked on projects where the development time got longer while the testing time got shorter.
An easy way to mitigate development risks is to make sure there is enough time for testing. That means enough time for one round of testing to uncover the bugs, then bug fix time, then more testing to ensure it is actually fixed and that no other bugs were introduced accidentally. Ideally, I’ve always tried to aim for at least three rounds of testing but be guided by what your test experts say is appropriate for your project.
Testing is so important for managing product and project-related risk. The more you test, the more you can uncover issues and put them right before the project is affected. Whatever risk you are facing, see if doing some kind of testing would help build confidence in the solution and mitigate the risk.
One of the main reasons I’ve seen why risk mitigation actions don’t get done is that the person tasked with doing them is too busy. Early on in my career, I learned that it shouldn’t be me as the project manager taking responsibility for all the risk management actions. I have an actual job to do as well, and being the project’s risk manager is a risk – the risk turns into a full-time job!
Spread the load between the team. Subject matter experts can pick up the analysis for risks that fall into their area. They are better placed at doing that work than you as project manager.
Small, incremental deliveries are less risky than a ‘big bang approach.
We’ve known that for a long time, and yet incremental delivery isn’t always seen as a valid risk response strategy.
Make the most of the options to deliver value in small increments. Use prototypes to test a solution before it moves forward. Wireframes and demos can also be helpful in ensuring you’ve got things right before you move on to later stages of development. And they can also flag up new risks early – which is better than finding out about the risk at a later point.
Incremental delivery allows you to check the processes for project management as well. You’re testing the ‘how’ as well as the ‘what’. This can be really useful if you are using new methods for delivery, for example, a new design approach or a different supplier to normal.
Contingency is that little bit extra added to your plans to help offset any unforeseen issues. We normally think of contingency as something added to budgets, but you can also have schedule contingency – extra time in the plan. In fact, you can add a contingency to pretty much anything. It’s a useful buffer and that can help offset some project risk.
For example, if you have a risk of not getting a task done in time for whatever reason, your response can be to add a contingency to the task to allow for any delay. If you don’t need it, the contingency is taken away – you can’t simply deliver late just because there is a contingency in the timeline! Add contingency as an explicit, extra time period (a totally separate task on your Gantt chart) so you can delete it if it isn’t required and move subsequent dates up.
Managing contingency on your project schedule is easier with experience, but my golden rule is to make it transparent. In other words, everyone should know the anticipated finish time and the contingency-in-case-of-problem time. No problem, no contingency gets used.
Finally, think about using the goals of the project as your compass to drive risk mitigation through the life cycle. When you come across a risk, ask how it will affect the project’s objectives. Make decisions based on that.
This approach relies on you fully understanding the project’s objectives! So if you are even the slightest bit unsure about the requirements or the vision, take some time to sit down with people who know about that stuff and get it clear in your own mind.
Having clear guiding principles has helped me on many projects. I can ask myself, “Will this course of action take us closer to our goals?” If the answer is yes, then it’s easy to see that’s an appropriate next step.
Risk mitigation actions depend on what you are doing and how far you want to go with your mitigating activities. Above, I’ve shared some strategies that have worked for me and are transferable to your own projects. Use them as a starting point to address the risks in your work.