# Using decision models in the real world

*by Alan Gump*

Here are some real-life suggestions on when to calculate EMV, use decision trees, or apply probability distributions.

PROJECT MANAGERS ROUTINELY have to choose between a variety of options to achieve their project objectives. Is Vendor A or Vendor B the better choice? Would the sponsor prefer an on-time delivery with most of the targeted functionality, or a late delivery with all the warples glued on and in place? What's the actual impact of a certain risk if it happens? What's the right choice between two evils that have different likelihoods of occurring, as well as different impacts on the project? Risk quantification attempts to provide models that allow the project manager to make usable comparisons between alternatives and to select the option that will best serve the sponsor's prioritized objectives. The problem is that the terrain is full of minefields; for example:

The probability of a certain risk occurring is an approximation at best.

Simple “decision tree” modeling may not capture the complexity of the problem.

Even if the probability of a certain risk occurring is low, if it does happen, it may wreak the *full* monetary value of the impact, rather than its calculated “expected monetary value.”

**Risk Quantification Primer.** Risk quantification begins with attempting to calculate the “expected monetary value (EMV)” of a risk.

A simple way to quantify the “expected monetary value” of a risk is to:

Estimate the “risk event probability,” from 1 percent to 100 percent, of a certain risk occurring

Estimate the “risk event impact” of the risk in dollar terms

Multiply the “risk event probability” by the “risk event impact” to calculate “expected monetary value.”

For example, you are planning an outdoor fundraising event in Seattle on the second weekend in February. Being an optimist, you calculate the chances of rain to be only 80 percent. Canceling the event would cause you to lose $30,000 in revenue that could not be recouped through other efforts.

Risk Event Probability | x | Risk Event Impact | = | Expected Monetary Value |

80 percent | x | $30,000 | = | $24,000 |

What does “$24,000” represent? It's the *value of the risk of rain.* But note: The *cost* to the project would be $30,000 if the event were actually rained out! The EMV is simply a number that helps you choose between multiple options.

**Alan Gump** is the West Coast professional development manager for PMSI • Project Mentors. He can be reached at [email protected].

**Exhibit 1.** Using probabilities of reaching compression targets, combined with the total costs associated with each compression target, yields an EMV for each target, and a total EMV for the entire range of outcomes.

Although $24,000 is a nice, clean, “objective” number, it's only as good as your assessment of the probability and your determination of the impact. To avoid the “garbage in, gospel out” syndrome, you would have to develop a solid basis for your numbers. So do your homework.

It's clear from this formula that there are three ways to lower (or raise) the expected monetary value of a risk: change the probability, change the impact, or change both. But that's a subject for a separate article on risk response development (how to avoid, mitigate, or absorb the risk).

**Using Expected Monetary Value.** Expected monetary value can be useful in planning realistic costs for a given event. For example, you are contemplating using a known vendor who does great work, but who has a track record of delivering late. By contract, late delivery of your product to your client will cost you $1,500 per day. The vendor will charge $100,000 for the job. You assess the likelihood of an on-time delivery to be 50 percent, and the likelihood of a 10-day delay to be 50 percent. The total cost of the delay is $15,000. What's the EMV of using this vendor?

Probability | x | Impact | = | Value |

50 percent | x | $100,000 | = | $50,000 |

50 percent | x | $115,000 | = | $57,500 |

Total EMV: $50,000 + $57,500 = $107,500

Planning on the total costs of using this vendor to be only $100,000 would be cavalier when there is such a substantial probability that the vendor will deliver late and cause you to incur penalties.

**Using Decision Trees.** Decision trees create EMVs for multiple options. Suppose two equally reputable vendors are bidding on a project, and you must select one of them. A decision tree allows you to compare the EMVs of the two vendors. Vendor A will charge $100,000 for the project (but has a significant probability of delivering late), while Vendor B is bidding it at $105,000. Once again, you face a $1,500-per-day penalty for late delivery:

**Vendor A**

Probability | Impact | Value | ||

50 percent | x | $100,000 | = | $50,000 |

50 percent | x | $115,000 | = | $57,500 |

Total EMV: $50,000 + $57,500 = $107,500

**Vendor B**

Probability | Impact | Value | ||

95 percent | x | $105,000 | = | $99,750 |

5 percent | x | $120,000 | = | $ 6,000 |

Total EMV: $70,000 + $34,500 = $105,750 Vendor B is the better choice (though not by much).

**Probabilities.** Using software to calculate probabilistic distributions of possible events forces the project manager to think more deeply about ranges of possible outcomes on a task-by-task basis; however, the benefit of such modeling often outweighs the cost. Running Monte Carlo simulations can produce a range of distributions very quickly in a way that intuition alone could never achieve. Some higher-end project management programs have Monte Carlo simulation capability built in, while the most popular low-end project management software requires an add-on product.

Monte Carlo simulations allow the project manager to specify optimistic, most likely, and pessimistic estimates for task durations and/or costs, to assign a distribution curve (for example, normal, triangular, or other), and then to run any number of simulations the user chooses. The simulator randomly selects numbers within the specified ranges for each task. The higher the number of simulations the user assigns, the greater the confidence factor he or she will have, because the simulator has used a sufficient number of samples to render an accurate model. The output usually consists of a table and a graph showing the range of possible outcomes, with individual probability assigned to each data point, and the “cumulative probability” of meeting or beating that particular data point. Cumulative probability is simply the sum of all the individual probabilities up to that particular point. After running the simulation, the project manager who is counting on a 125-day project according to his critical path method (CPM) calculation may be jolted back to reality by seeing that he may have only a 5 percent probability of the project coming in at exactly 125 days and only a 25 percent cumulative probability of the project finishing *on or before* that 125-day calendar point. In other words, the project has a 75 percent chance of coming in *later* than the target CPM date.

**Combining Probability Distributions with EMV.** As useful as decision trees can be when a choice lies between two options that share a sufficient number of comparable variables, they break down when the choices are complex. Consider a situation in which you have to decide whether or not to buy a $40,000 software package that could substantially decrease the duration of a task that requires a very expensive team. In this case, each week of task duration costs $30,000, and the current estimated duration is 10 weeks. How would you model this problem?

You would have to consider a range of possible outcomes that purchasing the software could produce; from the maximum number of weeks (for example, four) you could compress the task all the way to no compression. Using probabilities of achieving specific target points would be the only way to determine whether or not to purchase the package (see Exhibit 1).

In this case, it appears prudent to invest the $40,000 for the software, understanding that there is still a 15 percent chance that the software purchase will cost you more than accepting the original duration without the software purchase.

IT'S NOT ROCKET SCIENCE: Calculating EMV, using decision trees, and working with probabilities ends up being simple math. The hard part is developing reliable *inputs* to the formulas, particularly probability. Develop your scenarios and try to come up with a *reasonable* justification for the numbers. Use the simple EMV calculation when trying to determine the *value* of a risk event. Use decision trees when you need to compare two choices that can be compared. Use probabilities with EMV when you need to develop a range of possible outcomes. Refer to PMI's 1992 publication, *Project and Program Risk Management,* edited by R. Max Wideman, for detailed examples of risk quantification methods, as well as for an overview of the other three risk management modules. Review the series of articles by John Schuyler published in *Project* *Management Journal* and *PM Network.* Check out David Hulett's and Arnold Ruskin's articles in the February 2000 edition of *PM Network.* Finally, don't be afraid of (or seduced by) your calculator! ■

What's the right choice between two evils that have different likelihoods of occurring, as well as different impacts on the project?

**Reader Service Number 043**

January 2001 *PM Network*

Advertisement

Advertisement

## Related Content

Advertisement