Managing risk is one of those afterthoughts for many of us. We should plan early for it, think of ways to mitigate it, avoid it in certain areas, and help ensure our project’s success by dedicating a chunk of that early project budget to it. In reality, how much time – and on how many projects – do we actually sit down as a team (or as team and customer) and really plan for risk? Seems like planning for when the tire might blow out on our car. We’ll deal with it when it happens.
I’ve written articles that suggest risk planning and the creation of a Risk Management Plan as a deliverable on all of our projects, but often due to time constraints, budget constraints, and lack of customer interest, it either doesn’t happen or very little time and effort is dedicated to it and it becomes a very short spreadsheet list that is tucked away till later in the project. I’m not proud of it, but it is reality.
Risk management really shouldn’t be a once and done activity either. It needs to be a living, breathing end-to-end project activity. So in what time I do dedicate to risk management on each project I least do this….create a combined Issues/Risks list that becomes part of the weekly project status report and part of the weekly status call and review process. That way, it has all project eyes on it every week and we spend at least some time discussing the potential risks on the project and occasionally adding to it as the project is in progress. Some practical risk management is better than none…definitely.
In lieu of spending a large amount of time on an upfront risk management strategy with a full fledged, fully documented risk management plan, I’ve found that at least performing the following during a 1-2 hour session at kickoff time or during early planning phases can get key risks documented and monitored throughout the project.
Determine thresholds and identify potentials
During the formal project kickoff or during a very early planning session, sit down with your team and customer and consider what risk threshold you’re comfortable with. Obviously, you can’t cover everything – you can’t plan for every risk that might come up. You need to figure out what probability you care about. That may depend on your time and budget, but a good starting point is often 50%….meaning look at risks that would have an approximate 50% likelihood of occurring and affecting your project. Then brainstorm on potential risks. If it’s above 50%, document it. If it’s below 50%, toss it out. You could also look at it in terms of dollar impact, though that’s often a harder threshold to manage and that depends even more on the size of the project so it can vary a lot from project to project.
Discuss mitigation / avoidance activities
I always consider risk avoidance to be better than risk mitigation. However, if you can’t completely avoid a risk, then you need to figure out how you’re going to react to it if it becomes a reality. For example, if you need 20 developers on your project and only 5 are available you may look at outsourcing the development work. That could be a huge risk and a mitigation strategy might need to be finding another outsourced development staff during the project – with a potential for a huge amount of re-work. An avoidance strategy could be to hire more development staff internally – depending on the overall need for developers in your portfolio of projects. The cost will be higher, but the potential risk has been greatly reduced – possibly even avoided for your project needs.
Finally, make assignments. It won’t mean as much as the assignments you make on individual issues, but it’s critical that you have a primary person assigned and possibly a secondary resource assigned as well. The reality is, the entire project team will likely be involved in any risk response strategy, but a point person should keep their eyes on the risk item throughout the project.
A well-documented risk management process is always going to be a great strategy to follow. And the bigger the value placed on the project, the more important that risk strategy becomes. Unfortunately, the reality is that there usually isn’t enough money in the project budget to go that far with your risk planning and managing effort. So, figure out ways to do it in the real world – identify what you care to manage (thresholds), how you’ll react (mitigation/avoidance), and assign the risks so there is accountability throughout the project engagement. And do that well…it’s a start and it will help you mitigate and avoid some key risks along the way.