Top Ten Reasons Why Projects Fail – Reason #6

Reason #6 – Risk

Put simply, risk management is one of the most powerful (and, I think, easiest) techniques you can use in managing projects. Why is it so powerful? Because projects have uncertainty. And by predicting risk, you can lower that uncertainty and increase the likelihood of completing your project on time. And so if I tell you that I once saw a study that said risk management had a very low maturity level in our culture, or if I told you that many of my students could not apply their new-found skills at their companies you will surely wonder way. I have some opinions on that but I will save them till later, after we have discussed the subject more thoroughly.

So now that I’ve trumpeted the virtues of risk management, what exactly is it? First, let’s look at the definition of risk as stated by PMI. According to them, risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” Interesting. Positive OR negative. So on the positive side, I can see if some good can come out of it, called opportunity by PMI. But for brevity’s sake, let’s deal with the negative for now. So what we’re saying here is that there is some uncertainty in your project and due to that uncertainty, something bad MAY happen. (Remember that “may” statement. It’ll be important later).

In just about every case where I ever helped a customer develop a schedule, we also developed a risk register. This is a document, detailed a little later, that you and the team create early in the project. Now it’s possible that some initial risks may be identified in the charter. But a further fleshing out should happen during planning. So you bring the team together and as part of your Work Breakdown Structure/schedule planning, you ask them to think about things that may go wrong and how they would handle them.

I mentioned above that risk management was easy to learn and do. And I think it is, because really it comes down to the team coming together and thinking about the things, bad or good that might happen on a project. And if they’ve been on similar projects before, or have worked together as a team before, then surely they can assess what events might occur that would prevent the project meeting its objectives. This can be done, typically, by putting stickies on the board on what is called a probability/impact matrix. (A picture of which can be seen at the top of this post). So the team would have, in advance, come up with metrics for high, medium, and low for probability, and high, medium, and low for impact. So, for just one example, “low” on the probability side might mean that there is a less than 10% chance that the risk will occur.

Once the team has identified all the risks, it can then transfer them to a risk register. What is that? Basically it’s a table, usually in a spreadsheet, that details (at least) the following:

-Risk statement- For example, a dock strike may happen in an import/export environment
-Impact on project-  A number subjectively determined by the team based on experience
-Probability of occurrence – A number subjectively determined by the team based on experience
-Current risk exposure – probability times impact. A number greater than, say, 15 might be treated as a high risk
-Description of impact – a written description of the impact on the project
-Response – what will you do to either avoid, mitigate, transfer or (in low impact cases) accept the risk.
-Owner – who on the team owns and tracks the risk

Once the risk register is developed, what do you do with it? Well, a lot of people stick it in a drawer. Maybe not literally but for all they ever use it, they might just as well. Because they completely forget about it. But the risk register is, and should be, a living document. So the PM should bring it to every team meeting and the owners should report on their risks on a regular basis. Is a low-ranked risk still low-ranked or is it bubbling up? Is a more highly-ranked risk ready to occur? Have new risks surfaced that should be added to the register? Using the register in this way will allow you to continue to proactively foresee and react to any possible new risks.

Now I wanted to return to one topic that I alluded to before. That is, if I say that risk management is so great, why don’t more organizations use it, even after being trained on it? I can think of two reasons. One is that when you mitigate a risk, you are basically saying, “I will take certain proactive steps that will add time and money to the schedule for something that may never occur.” And management is just as likely – maybe even more likely – to say, “No thanks”, as much as they might say, “Ok.” Why should they spend money on something that may never occur? (Remember Y2K? I personally think all the preparations were worth it. But you will still find people who say, “Look. Nothing happened.”) The other reason I can think of that organizations might not use it is more subtle. Basically if you come to your manager and say, I want to proactively plan for things that might go wrong, he may say something like, “We’ll worry about that when and if it happens” OR “Stop being a negative thinker.” I have encountered both these types in my travels. Education here is needed.

One possible solution to this is to try risk management on a smaller project, perhaps creating a register by yourself or with your select team. Try to incorporate it slowly if at all possible, gradually introducing your bosses to the value of this technique.

The bottom line is that a project run with risk management techniques employed will, generally speaking, be much more successful. Because we all know that if something can go wrong on a project, it eventually will. And if you can anticipate problems in advance and react to them, then shouldn’t you?

(Next reason – project management not supported by company culture).