Message to Som Gollakota

Please Enter All Requested Information Below
Your Name
Email Address
Message
Leave this Blank:
Hyderabad, India
Risk Management - Quantitative Risk Analysis
January 2, 2010
...numerically analyzing the effect of identified risks on overall project objectives.
-Definition of Quantitative Risk Analysis, PMBOK 4
Q
uantitative Risk Analysis is a numerical analysis of risks that typically follows the Qualitative Risk Analysis. Simply put, it is the process of breaking a risk apart and analyzing the best case, worst case, and most likely scenarios of a risk. In other words, it involves asking and answering question - what would be the numerical impact of a risk when the impact occurs in
  1. The best case scenario (example - 20% negative budget impact, or $50,000 in additional costs)
  2. The worst case scenario (example - 40% negative budget impact, or $100,000 in additional costs)
  3. The most likely scenario (example 30% negative budget impact, or $75,000 in additional costs)
The most likely scenario, as you may have noticed, is usually (not by rule) the mid-point of best and worst case scenarios. While this process can be applied to any risk area depending on the complexity of the risk/criticality of the impact, most often, I use this process for risks that have direct impact on schedule and budget. Therefore, the inputs to this process would be the risk register (log of all risks), scope and budget management plans, and (of course) the risk management plan. Organizational assets, if any available, will also play a role to bring the numbers close to reality from a historic perspective.
Analysis Techniques:
  1. Probability Analysis and Distribution - Gather the required data by interviewing experts (or experienced personnel) and examining historical data. Quantify the probability and impact in terms of best (or most optimistic), worst (or most pessimistic), and most likely (or realistic) scenarios. The most likely scenario is the result of the experience and/or historical data. In the absence of such information/ experience, a mid-point may serve as baseline for most likely scenario. Spread the data in a table. Move on to the next part of the analysis.
  2. Sensitivity Analysis - Determine which risk has most potential impact on the project, examining the extent to which each uncertainty of a risk affects the project when everything else remains the same.
  3. Expected Monetary Value (EMV) - It is a statistical analysis done, when there are multiple possible outcomes, assessing the monetary value of each outcome. It is commonly depicted in a decision tree where the value of each possible outcome is multiplied by its probability of occurrence and adding the products together.
  4. Expected Monetary Value (EMV) - It is a statistical analysis done, when there are multiple possible outcomes, assessing the monetary value of each outcome. It is commonly depicted in a decision tree where the value of each possible outcome is multiplied by its probability of occurrence and adding the products together.
  5. Modeling and simulation - Translates uncertainties into their potential impact in an iterative manner (such as in Monte Carlo simulation). With cost risk analysis, for example, it uses cost estimates of each uncertainty to arrive at total cost (final impact).
  6. Expert Judgment - There is no substitute to it. It is always there. The judgment of experts that have been through similar risks in the recent past is taken to identify potential impacts.
Output:
  1. The risk register is updated with the outcome of analysis for each risk analyzed
  2. Detailed estimates and schedules are built for each possible outcome
  3. Probability of achieving the cost and schedule objectives
  4. Prioritized list of risks analyzed
  5. Any trends observed in the iterative analysis
Conclusion: As good and useful as Quantitative Risk Analysis is, the last (and only) time I truly used the process (being an IT Project Manager) was when I was undergoing Risk Management Training a few years ago. That is not to say that the process, tools and techniques are useless in IT or in Project Management. I use the tools and techniques quite often in other areas (such as building an effort estimation, a budget, or a schedule), thereby reducing overall risk to the project. It is still Risk Management, although not in the pure sense of managing a particular "identified" risk.
For example, when I go through a project estimation process (to build a schedule), I typically map three different kinds of estimates - optimistic, pessimistic, and likely estimates. I take the pessimistic estimate to build my budget and the initial schedule. However, I use the optimistic and likely estimates to track the schedule (if we miss the optimistic, I closely monitor the likely estimate. If we miss the likely estimate, I start raising threat levels and awareness as we get close to the pessimistic estimate). The same goes with budget estimation and tracking process as well. In the end, when the risk is managed effectively, either under the stated process or elsewhere, it is still a strategy for handling a potential (identified or unidentified) risk, and culminates in successful delivery.
----------x----------