We should want to take the time to analyze, assess, plan for and manage risk on the projects that we lead. The bottom line is…most of us really don’t. Or at least our customer’s don’t see the need to spend the time or our senior management, doesn’t…or we are just swamped and pushed to get the project running.
No question – the process of performing risk management on the projects that we run should be a given – it should be an essential part of every single project and it should have the proper amount of time and attention given to it. The reality is, we often skip over it or we spend very little ‘planned time’ on it. I tout risk planning and the creation of a Risk Management Plan as a deliverable, but due to time constraints, budget constraints, and lack of customer interest, it happens on less than half of the projects that I manage. 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.
Make assignments. 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.
Summary / call for input
A very detailed and well-documented risk management process is the best strategy to take – and I highly recommend it for all high-dollar and highly visible mission-critical projects. However, the reality is that there usually isn’t enough money in the project budget to go that far with your risk strategy. 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.
What about our readers? What are your thoughts on risk planning? How much time do you dedicate to it? Do you perform real risk planning on all of your projects? 50%? 25%? Please share your thoughts and discuss.
