Planning risk responses

If you were following the PMBOK religiously, the next thing you would do is quantify risk which “is the process of numerically analyzing the effect of identified risks on overall project objectives.” ¹ Choices here are:

·Sensitivity analysis – looking at the impact of an individual risk on a project objective
·Expected Monetary Value – probability X impact, often to provide you with a contingency reserve
·Decision Tree – to make a decision between two choices using EMV
·Monte Carlo – a way to simulate your project hundreds of times to see where the risk lies

But since quantification often doesn’t happen, we’ll jump right to creating risk responses. (People do create contingency reserves. But I would argue that they don’t necessarily use quantified risk analysis to do it.)

Now that you’ve identified and prioritized your risks, you’ve got to decide what you’ll do should they occur. Remember – you’re looking into a crystal ball when you do risk planning. You’re trying to figure out what MIGHT happen and then what – if anything – you will do should it happen. Let’s look now at the possible responses to threats AKA negative risk. (You should also consider opportunities or positive risks). Firstly, there is

Avoid – this means to not do the thing that is causing the risk. For example, let’s say you are the PM on a project and are planning to use your company’s version 2.0 of software. And you have noted this in your project management plan. Now let’s say that one day your lab people approach you and tell you that version 2.0 is buggy. They have a number of Sev 1’s and Sev 2’s and are no longer sure it will be ready for your first milestone, a trade show. So you go to your sponsor and explain the problem. Now she may well say,”I don’t care what it takes. Fix it!” Or she might say, “What do you recommend to get us through this trade show?” And so, it’s just as likely that you might recommend going back to version 1.x for the trade show and work towards version 2.0 for the full release. And if she agrees, then you go to the project management plan, cross out version 2.0, write in 1.x and thereby you’ve avoided the problem. You just don’t do the thing that causes the risk. Now of course you haven’t necessarily avoided it forever. But you have for now.

Transfer – Many people assume that transfer means that, say, Bob in Operations can transfer the risk to Joe in Engineering. Not so. For one thing, transfer implies that you’re transferring it to a third party. For another, you’re not just handing it off. Typically you transfer to handle some sort of financial risk. This is done through bonds, guarantees, insurance, subcontracting and the like. Here’s an example: Let’s say that I drive a car and I have to insure it. And so if I get in an accident, then the insurance company pays for the damages (minus deductible). So they take on the cost risk. But guess what? I still own the risk do I not? The insurance company is not driving the car. I am. So I am the one who can get hurt. In a project sense, contracts can be used as risk transfer mechanisms.

We’ll look at the other two responses, accept and mitigate, in my next post later this week.

1. PMBOK Fourth Edition, p, 294 (electronic edition)