What to do with Risk

Posted by Keith McMillan

July 17, 2014 | Leave a Comment

When you’re running a software development project, you have to deal with risks to the project. Some teams just trundle along, not really adopting a formal risk management process. But for those who do, what do you do with a project risk once you’ve identified it?I’ve seen a lot of teams try to manage risks, and it’s surprising how few of them are really good at it. First, you have to decide if what you have is really a risk, then you need to decide what (if anything) you’re going to do with it. When you boil it down, you’ve really only got three (and a spare) things you can do with a project risk, but more on that in a minute.

Evaluating a Risk

The first thing you should decide when you’re presented with a risk is whether it’s really a risk or not. A risk is defined as something that has a negative impact on the project, usually from a money, time, or quality point of view. Risks aren’t confined to those kinds of impacts, but those are the usual ones.

Once you’ve decided if the risk is really something that could happen to the project, it’s a good idea to determine the impact should the risk manifest into a problem, and the likelihood that will happen. These two factors will determine how important it is for you to do something about the risk.

Risk Acceptance

Let’s pretend that you decide that your software architect is key to the project, and that he also likes to play the lottery. If he wins, he’ll quit. If he quits, the project will fail, but the likelihood is that he’ll be hit by lightning (twice) before he wins the jackpot.  In our estimation, the risk is severe, but the probability is low, so we really don’t want to go out of our way to deal with that risk: we’ve accepted this risk.

Let’s further assume that your software architect’s uncle is rich, and that he’s named our software architect as his heir. Let’s also assume that our architect’s uncle is 92, and plans on going parachute jumping next month. That probability is that he may not survive the jump, and *poof* there goes our architect.

At this point, we have an accepted risk, but our probability is uncomfortably high. We should mitigate the risk (this is our “plus a spare” from before) which just means we should take steps to reduce the probability or impact of the risk.  We can’t really change the probability that the architect’s uncle will perish sometime soon, or that he’ll leave his vast fortune to our architect. We can however lessen the impact of the architect leaving by getting someone else to work with our architect, and try to get as much knowledge out of his head and into a spare head as possible.

Once you’ve accepted a risk, you should monitor to determine if its probability or impact change, and decide if you need to take steps. If it’s acceptable, then just leave it on the list for monitoring.

Risk Avoidance

Another valid strategy is to avoid the risk. For an example of risk avoidance, consider the Java programming language. Now that Oracle has bought Sun MicroSystems (former owner of Java) there’s the risk that Oracle will do something dastardly (just for the sake of argument, Oracle please don’t sic your lawyers on me…) and that we won’t have access to the Java any more.  One way to avoid this risk is to use Microsoft’s C# instead of Java (although in my opinion, we’re trading one problem for another…)  This is an example of risk avoidance: changing the rules so the risk doesn’t apply any more.

Risk Transfer

A final approach to risk is to transfer it to someone else. The best example of this is insurance: most of us in the US purchase automobile insurance. We do this because of the risk we get into an accident and can’t pay for the damages. We transfer the risk to the insurance company, and pay them to take the risk away from us.

Once you’ve decided you have a risk, you have a few simple choices: transfer it to someone else, avoid it, or accept it and decide if you need to mitigate as well.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.