Risk Analysis Basics


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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.