Risk Analysis Basics

) in bright red is enough information. In my experience, managers or other people with organizational power manipulate the numbers to give the answer other managers or other powerful people want to see. It's much harder to manipulate the highs, mediums, and lows.

For all risks, define the date by which you need a mitigation plan, a plan to manage the risk if it does come true. For High exposure risks, define the mitigation plan. (In your organization, you may also need a plan for medium exposure risks. Some organizations require plans for even lower exposure risks. It depends on the risk tolerance of your organization.)

Now, when you go to your project manager to explain that there's a potential problem with testing, it's easier for the project manager to see the potential problems and how they impact the whole project.

Of course, risk management doesn't give you a magic wand and a crystal
ball. Rather, risk management is about looking at likely scenarios (and even at some unlikely scenarios) and taking some action to reduce their potential effects.

Why do risk analysis?
You do risk analysis for only one reason: Would you manage the project differently if any of your risks happened? I especially look for risks that could put us out of business, or prevent us from shipping product.

When I work with people on generating risk scenarios in the project, I ask them to look at risks in these areas:

• Risks to getting the project completed. (The machine availability problem above is a great example of that risk.)
• Risks to using the product in the field. (I find use cases or other forms of customer-scenario generation work well here.)
• Risks to the business from using the product in the field. (If your customers find this problem, could their reaction impair your ability to do business?)

Then you make plans to deal with the risks you never want to come true. In Tim's project, for example, the lack of the machine when it was needed would prevent them from doing load testing. How bad a problem is that, really? Would Tim's company have shipped anyway? If so, then there was no risk. (I'm not saying this is good business, but if Tim's company already decided that the potential down side, the severity, is not high enough, then there is only limited business risk if a server is not available and the testing is not done.)

Risk analysis can't be exact. If it were exact, you'd be predicting the future (and by the way, if you figure out how to predict the future, please do let me know). But having a place to start the discussion about what the problem is, and how it affects the project, is much better than the frustrating and inadequate dialog we saw at the beginning of this column.