Decision Trees and Cost/Benefit Analysis
A Note Encouraging the Use of Structured Decision Making Using Decision Trees

 
A decision tree structures a question/answer pattern. Each tree may support multiple sub-trees in a complex decision. The root of the tree is a broad question where each encounter has several significant possible outcomes. Reaching an outcome involves one or more sub-decisions (sub-trees). The granularity of the tree is expressed by level of breakdown of any decision into sub-decisions and discrete outcomes. Decision trees are applicable at many business levels from go-no-go decisions to impactful implementation choices.

The main functions of decision trees are:

• Regularize the decision making process
• Add transparency into decision making
• Ensure complete consideration of decision paths

As an example (from the project management perspective) a root question might be: How do we handle a change in requirements? Figure 1. shows a possible tree supporting this question. Depending on the project and organization the example tree given may be too simple or too complex (e.g. change in deadline is not considered explicitly, neither is there any reference to arbitration).

Figure 1. A simple project management decision tree

 
As a rule of thumb (as opposed to a hard and fast rule), where decisions are potentially contentious it makes sense to provide a flow-through option that is easily identifiable as a shortest path—as shown in Figure 2. Further it makes sense that this flow-through be the option that is reasonably expected to seem like the logical outcome to both (all) parties concerned.

Figure 2. The flow-through structure of the same tree highlit

 
Trees relax generality and specificity to fit the concerns of the group making a specific decision. Each decision point has some uncertainty and several concrete options per path. Decision paths generally will not show each concrete implementation option, in order to limit complexity and increase productivity. Productivity is enhanced at the implementation layer by setting the tree aside and documenting the decision in narrative form—a necessary and uncontroversial iteration.

For instance, in developing an enterprise web application at some point there is an architectural decision on how the web front end meets the business API. An architect's tree may have a node representing the MVC framework option. At some point after that, another version of the tree may include the possible frameworks. Later still, decisions relating to the best use of the frameworks may be added. At some point the tree will loses its impact and attention turns to documenting the details of the decision. However, saying that a decision tree may stop at a certain granularity does not imply that important decisions should ever be made without a regular decision making structure appropriate to the concern.

At each decision point in a decision tree information is needed before a direction can be chosen. In a business situation the information collected is dominated by dollar or dollar-equivalent cost/benefit. There is substantial literature on different means of mapping dollars to decisions (some references given below). In order for the cost/benefit analysis to make sense uncertainty, or risk, must also be factored in. Analyzing risk—or estimating software development, for that matter—is beyond the scope of this note, but see the references below.

A simple approach to cost/benefit analysis is outlined in Example 1. This is not the be-all-and-end-all of outlines, but it is a reasonably complete and fairly light weight approach. When this or any approach is used the decision makers must realize that they are highly unlikely to have complete information. (E.g. an architecture team is not likely to have precise information about how the CEO and Board are weighing investor input, regardless of any trickle down impact that may have on a product architecture). The trick is to balance the cost of the decision making process with an effort to consider fully all reasonable options—and to explain how those options were selected. Done well, this completeness-within-reason and explanation of the process will add value to the decision by increasing transparency.

 
Using this or another outline to summarize cost/benefit, the analyst must remember to factor upstream and downstream (up-tree and down-tree) costs, benefits, and risks. It is the cumulative and term effect of decisions that is finally important to a business—not their simple immediate impact.

 
SUMMARY

This note advocates used of decision trees with a cost benefit analysis—a tried and true method for improving consistency, communication and completeness in decision making. Using the decision tree form and the example cost benefit outline provided should make taking this approach to project and architecture decisions relatively easy.

RESOURCES

• Decision Trees
• Project Management Institute
• Monte Carlo and a comparison with decision trees
• Gov't cost/benefit links
• Simple cost/benefit and pointers to more info