The Decision Tree
The decision tree is a tool to be applied in a decision methodology. In effect, the decision tree, and its cousin the decision table, sums up all the expected values of each of the alternatives being decided and presents those expected values to the decision maker. At the root of the tree is the decision itself. Extending out from the root is the branch structure representing various paths from the root (decision) to the choices. For those familiar with the "fishbone" diagram from the Total Quality Management toolkit, the decision tree will look very familiar. Along the pathways or branches of the decision tree are quantitative values that are summed along the way at summing nodes. Normally, the project manager makes the decision by following the organization's decision policy in favor of the most advantageous quantitative value. In some cases, deciding most advantageously means picking the larger value, but sometimes the most advantageous value is the smaller one.
The Basic Tree for Projects
Figure 43 shows the basic layout. It is customary, as described by John Schuyler in his book, Risk and Decision Analysis in Projects, Second Edition, ^{[3]} to show the tree laying on its side with the root to the left. Such an orientation facilitates adding to the tree by adding paper to the right. We use a somewhat standard notation: the square is the decision node; the decision node is labeled with the statement of the decision needed. Circles are summing nodes for quantitative values of alternatives or of different probabilistic outcomes. Diamonds are the starting point for random variables, and the triangle is the starting point for deterministic variables.
Figure 43: Decision Tree.
In Figure 43, the decision maker is trying to decide between alternative "A" and alternative "B". There are several components to each decision as illustrated on the far right of the figure. Summing nodes combine the disparate inputs until there is a value for "A" and a value for "B". An example of a decision of this character is well known to project managers: "make or buy a particular deliverable."
Since our objective is to arrive at the decision node with a quantitative value for "A" and "B" so that the project manager can pick according to best advantage to the project, we apply values in the following way:

Fixed deterministic values, whether positive or negative, are usually shown on the connectors between summing nodes or as inputs to a summing node. We will show them as inputs to the summing node.

Random variable values are assigned a value and a probability, one such valueprobability pair on each connector into the summing node. The summing node then sums the expected value (value * probability) for all its inputs. Naturally, the probabilities of all random variables leading to a summing node must sum to 1. Thus, the project manager must be cognizant of the 1p space as the inputs are arrayed on the decision tree.
Figure 44 shows a simple example of how the summing node works. Alternative "A" is a risky proposition: it has an upside of $5,000 with 0.8 probability, but it has a downside potential of $3,000 with a 0.2 probability. "A" also requires a fixed procurement of $2,000 in order to complete the scope of "A". The expected value of the risky components of "A" is $3,400. Combined with the $2,000 fixed expenditure, "A" has an expected value of $5,400 at this node. The most pessimistic outcome of "A" at this node is $1,000: $2,000  $3,000; the most optimistic figure is $7,000: $2,000 + $5,000. These figures provide the range of threat and opportunity that make up the risk characteristics of "A".
Figure 44: Summing Node Detail.
Now, let's add in the possibility of event "A_{4}". The situation is shown in Figure 45. If the project team estimates the probability of occurrence of "A_{4}" as 0.4, then the probability of the events on the other leg coming into the final summing node becomes equal to the "1p" of "A_{4}", or 0.6. Adding riskweighted values, we come to a final conclusion that the expected value of "A" is $4,840.
Figure 45: Summing Node A.
The most pessimistic outcome of "A" at this node remains $1,000 since if "A_{2}" should occur, "A_{1}" and "A_{4}" will not; the most optimistic figure remains $7,000 since if "A_{1}" occurs, then the other two will not. If "A_{4}" should occur, then "A_{1}" and "A_{2}" will not. However, "A_{3}" is deterministic; "A_{3}" always occurs. So the optimistic value with "A_{4}" is $6,000: $2,000 + $4,000. Obviously, $6,000 is less than the outcome with "A_{1}".
If the analysis of "B" done in similar manner to that of "A" should result in "B" having a value less than $4,840, the decision would be to pick "A". Of course, the risk tolerance of the business must be accommodated. At the decision node there will be an expected value for "A" and another of "B". The project manager can follow the tree branches and determine the most pessimistic outcomes. If the most pessimistic outcomes fit within the risk tolerance of the business, then the outcome, "A" or "B", is decided on the basis of best advantage to the project and to the business. If the most pessimistic outcomes are not within the risk tolerance of the business, and if there is not a satisfactory plan for mitigating the risks to a tolerable level, then the choice of project defaults to the decision policy element of picking on the basis of the risk to the business. Risk managing the most pessimistic outcome is a subject unto itself and beyond the scope of this book.
By now you may have picked up on a couple of key points about decision trees. First, all the A_{i}s and B_{i}s must be identified in order to have a fair and complete input set to the methodology. The responsibility for assembling estimates for the A_{i}s and B_{i}s rests with the project manager and the project team. Second, there is a need to estimate the probability of an occurrence for each discrete input. Again, the project team is left with the task of coming up with these probabilities. The estimating task may not be straightforward. Delphi techniques ^{[4]} applied to bottomup estimates or other estimating approaches may be required. Last, the judgment regarding risk tolerance is subjective. The concept of tolerance itself is subjective, and then the ability of the project team to adequately mitigate the risk is a judgment as well.
A Project Example with Decision Tree
Let's see how a specific project example might work with the decision tree methodology learned so far. Here is the scenario:

You are the project manager making a make or buy decision on a particular item on the work breakdown structure (WBS). Alternative "A" is "make the item" and alternative "B" is "buy the item."

There are risks in both alternatives. The primary risk is that if the outcome of either "A" or "B" is late, the delay will cost the project $10,000 per day.

If you decide to make the item, alternative "A", then there is a fixed materials and labor charge of $125,000. If you decide to buy the item, alternative "B", there is a fixed purchase cost of $200,000. Putting risks aside, "A" seems to be the more attractive by a wide margin.

Although manufacturing costs are fixed, your team estimates there is a 60% chance the "make" activity will be 20 days late. Your judgment is that you simply do not have a lot of control over inhouse resources that do not report to you. However, your team's estimate is that there is only a 20% chance the "buy" activity will be late 20 days, and the purchase price is fixed.
What is your decision? Figure 46 shows the decision tree for this project scenario. The decision node is the decision you are seeking: "make or buy." The tree branches lead back through each of the two alternatives. Inputs to the decisionmaking process are both quantitative and qualitative or judgmental. You know the manufacturing cost, the alternative procurement cost, and the cost of a day's delay in the project. You make judgments about the performance expectations of your inhouse manufacturing department and about the performance of an alternative vendor. Perhaps there is a project history you can access of former "similarto" projects that provide the data for the judgments.
Figure 46: Project Decision Example.
As the mathematics show, there is only a $5,000 difference between these two alternatives when all the risk adjustments are factored into the calculation. In fact, the decision favors a "buy" based on the decision policy element to take the alternative of most advantage to the project, just the opposite from the initial conclusion made before risk was taken into account.
How about the downside considerations? If you make the item and the 20day delay materializes, you are out $325,000. If you buy the item and the 20day delay happens, you are out $400,000. Since you budget for expected value, either $245,000 or $240,000, the most pessimistic figures provide the information about how much unbudgeted downside risk you are managing:

Downside risk (buy) ≤ $240,000  ($200,000 + $200,000) = $160,000
or

Downside risk (make) ≤ $245,000  ($125,000 + $200,000) = $80,000
You, or your project sponsor, must also decide if the unbudgeted risk is affordable if all risk mitigations fail and the 20day delay occurs.
Probability Functions in Decision Trees
You might be asking: What about delays other than 20 days, or why 20 days? The project manager and project team may be able to estimate much finer segments than 20 days. There really is no limit to how many individual discrete estimates could be made and summed at a node. It is required that the sum of all probabilities equal 1. So as more discrete estimates are made, say for 1, 2, 5, 10, or other days of delay, the individual probabilities must be made individually less so that the total summation of the "p"s equaling 1 is honored.
Now you may recognize this discussion as similar to the discussion in the chapter on statistics regarding the morphing of the discrete probability distribution into the continuous probability function. Obviously, the values at the input of the summing node are the values from the discrete probability function of the random variable or event that feeds into the summing node. There is no reason that the random variable could not be continuous rather than discrete. There is no reason that the discrete probability function cannot be replaced with a single continuous probability function for the event.
Suppose the inputs to the summing nodes are replaced with continuous probability functions for a continuous random variable. Figure 47 shows such a case. Now comes the task of summing these continuous functions. We know we can sum the expected values, and if they are independent random variables, we know we can sum the variances with simple arithmetic. However, to sum the distribution functions to arrive at a distribution function at the decision square is another matter. The mathematics for such a summing task is complex. The best approach is to use a Monte Carlo simulation in the decision tree. For such a simulation you will need software tools, but they are available.
Figure 47: Decision Tree with Continuous Distribution.
^{[3]}Schuyler, John, Risk and Decision Analysis in Projects, Second Edition, Project Management Institute, Newtown Square, PA, 2001, chap. 5, p. 59.
^{[4]}The Delphi technique refers to an approach to bottomup estimating whereby independent teams evaluate the same data, each team comes to an estimate, and then the project manager synthesizes a final estimate from the inputs of all teams.