A Short Tour Through Risk Management
by Jim Stewart,
Project Management Consultant and Trainer of JP Stewart Associates
Every project manager I know loves to talk about, teach, or just practice risk management. Why? Because done correctly, it’s one of the most proactive things you can do on a project to help keep it on track. That’s because instead of waiting for potentially bad events to happen, you anticipate them and plan for exactly what you would do should they occur. Can you realistically plan for the eventuality of every risk? Of course not. But you can brainstorm and anticipate many of them, which will give you the peace of mind that you need on a project to proceed with confidence.
The Project Management Institute, in its PMBOK Guide, Third Edition defines risk as, “An uncertain event or condition that, if it occurs, has a positive or (emphasis mine) negative effect on a project’s objectives.1 In the previous sentence I emphasized the fact that a risk can be considered positive (that is, an opportunity) or negative (a threat). It comes as a surprise to many people that a risk might have upside advantages. And while I don’t have space in this article to cover both positive and negative aspects in depth, as part of your risk planning you should be considering whether a potential risk could be an opportunity. (For example, if a competitor comes to market with a new technology, is that always a bad thing? Could you benefit from it?)
I recently saw a study that indicated risk management has one of the lowest levels of maturity in organizations, even ones that practice project management regularly. If risk management is, as I suggest, so important to a well-planned, successful project, why isn’t it performed more regularly in organizations? I believe the reason for this to be several-fold. One is that project managers are often not trained in risk management. So they don’t know how to perform risk meetings nor do they know how to plan risk responses. Another major reason is that those who plan proactively for dealing with risk are often seen as negativists. “Why worry about what might go wrong?” they are asked. “We’ll handle that when or if it occurs.” To me that’s like saying I’ll do my estate planning in my nineties.
Risk Management Planning
Despite what I said above about risks having potential upsides, for the sake of brevity we’ll deal only with how to handle downside risks. The first thing you (and your team) need to do is identify risks. Generally speaking, this is done all throughout the project but as a practical matter, the first time you’ll identify risks is when you define the scope of the project, ideally using the Work Breakdown Structure (WBS) as a guide. As I mentioned in a previous article, the WBS is a hierarchical structure that gives the team a visual sense of exactly what the scope of the project is. Since it contains all of the deliverables, it’s a good pointer as to exactly where the risks are.
So, for example, if a deliverable on a networking project is a software component, what are the risks inherent in delivery of that component? A team of developers in a room can probably think of many risks that would impede the chances of on-time delivery: poor estimates, undertrained developers, late delivery from vendors, and so on. The key in risk identification is to recognize all possible risks that the team can think of. Do you then have to do something to prevent all possible risks? In a word, no. You first have to decide what the probability and impact of each risk is. Is it likely to occur? How likely? What would the impact be? High? Low? Somewhere in between? All of this is subjective, but subject matter experts are likely to make sound judgments about the probability and impact of any particular risk. So the risks that you wind up managing are those that are deem to be highest-impact and highest-probability. (For the record, you don’t ignore the other risks. You monitor them so that they don’t become higher-impact risks).
Once you’ve identified the risks and decided which ones you should monitor, you create a risk response plan that details how you are going to deal with each risk. You have several responses from which you can choose:
- Avoid – if, in the aforementioned network example you are using a new, unproven release of software, you can avoid the risk by using an older release. In this instance, you would modify the project management plan to accommodate this.
- Transfer – in this instance, you transfer the risk to some third party. So, you could outsource the work. This doesn’t mean the project no longer has this risk. It just means you’ve decided to put the onus for it somewhere else.
- Accept – you passively accept (“let’s do nothing and deal with it if it occurs”) or actively accept (“let’s create a contingency plan should it occur”) the risk.
- Mitigation – you come up with a way to reduce the probability or impact of the risk occurring. So let’s take the instance of the software module a little further. Perhaps one of the identified risks is that you’ve hired an out-of-state contractor to do work. You’re worried not only that he’ll miss deadlines but also that he might lose his hard drive at a key time. Or that the knowledge is all in his head. You can mitigate the hard drive crash problem by having him back up across your secure network on a regular basis. And you can lessen the risk of him as a single point of failure by having someone trained to take over and by making sure that all his code is commented. And by all means, have another contract house ready to go at a moment’s notice.
This is just a quick tour through a complex procedure. But hopefully you can see that the judicious application of risk management can help keep your project on course.
Jim Stewart has been an independent project consultant and instructor since early 2003
and has worked in project management for 15 years. He has managed
several multi-million dollar projects for companies such as Lotus
Development and Genuity and currently teaches at both Brandeis
University and Babson College. He can be reached at
jpstewar@rcn.com or view his website at
http://www.jpstewartassociates.com/
