Project Management Institute

Decision analysis in project management


Marc-david Cohen, SAS Institute Inc., Cary, North Carolina


As a discipline, project management has evolved from its origins in scheduling to a compendium of tools to collect and monitor project data; to schedule projects with precedence, resource, and time constraints; and to report project schedules, progress, and resource usage. Currently, project management tools are moving toward greater integration of the scheduling and reporting capabilities into data bases and the enhancement of the user-interface. One direction for future change is toward imbedding project management tools in general decision support frameworks.

To serve as a framework for decision making a decision support system should provide tools appropriate to the various needs of the management team. Planning and decision making tend to come from the upper levels of the organization, while project execution and data collection tend to come from the lower levels of the organization. As a result, the lower organizational levels need features such as easy data entry, feedback on subproject progress, variance reports, and short term activity plans. On the other hand the upper organizational levels need quick access to data and analysis tools so that data can be viewed from various perspectives for analysis and summary. Upper levels of management require a larger perspective with an emphasis on decision making.

An effective decision support system supports both sides of this structure. It provides a data collection framework which simplifies data entry and the capturing of information for the lower levels of the organization and an integration model that blends the database systems, schedulers, report writers, and optimizers, for the decision makers. However, in addition to supporting these features, such a framework could provide managers access to tools that currently fall outside the realm of “traditional” project management functions. For example, methods to optimally solve resource allocation, distribution, and inventory problems are several analytical tools that would be valuable additions to a decision support toolbox. Consider the benefit of an easily accessible method for optimally crashing projects or sub-projects

This article focuses on decision analysis, a tool that is valuable in the early planning stages of a project and during crucial high level periodic reviews of project progress. Decision analysis is a technique for solving decision problems when there is uncertainty in decision outcomes. Since this is a problem that is at the very core of project mamagement, there are a plethora of applications. Several key areas which can be impacted by the use of such tools are:

  • obtaining good estimates of activity durations
  • subcontract awarding
  • risk-analysis
  • “what-if” analysis
  • subproject termination in an R&D setting.


Decision analysis is a tool that attempts to provide an analytic basis for management decisions under uncertainty. At the core of the technique is a structure called a decision tree.

A decision tree contains two types of nodes, decision nodes and chance nodes. A decision node is a node at which a decision is to be made and a chance node is a node at which a random outcome is realized. Movement from node to node through the tree represents movement in time so that passage from node to node represents the need either to make a decision or to realize a random outcome.

An example can illustrate these concepts quickly. Suppose you are planning to bid on a project to manufacture a new type of machine tool. The evaluation of the bid will likely be more favorable if the bidder has built a prototype of the tool and includes it with the bid. The decision maker must decide whether to build the prototype and the value of the bid to offer. Keep in mind that this example is simplified to illustrate the methods involved.

Decision problems can be described with three types of tables, a node description table, a conditional probability table, and a payoff table. The node description table for the example, shown in Table 1, defines four nodes: CHOOSE, BID, CONTRACT, and BUILD PROTOTYPE. CHOOSE and BID are decision nodes. You can either choose to build a prototype or choose not to build a prototype. If you choose not to build a prototype the next node is the BID node. Here, you either propose a HIGH BID or a LOW BID. In either case, your next node is the chance node, CONTRACT; either you win or lose the contract. If you had chosen to build the prototype, then the cost of the prototype would be either EXPENSIVE, MODERATE, or INEXPENSIVE. The return column in the table gives these three alternatives. Regardless of the cost of building the prototype, the next node is the BID node.

The conditional probability table, Table 2, assigns probabilities to the various outcomes. For example, the last line of the table shows that if a low bid (LOW BID) is made and the prototype is built (BUILD PROTOTYPE) then the probability of winning the contract (WIN CONTRACT) is estimated to be 0.8 and the probability of losing the contract is estimated to be 0.2. In some cases there is no given information. For example, the probabilities of an expensive, moderate, or inexpensive prototype are 0.4, 0.5, and 0.1, regardless of any other information.


Table 1. The Node Description Table


Table 2. The Conditional Probability Table

The payoff table, Table 3, assigns returns to various outcomes. For this simple example, if you win the contract (WIN CONTRACT) the return from a low bid (LOW BID) offer is 35000 while the return from a high bid (HIGH BID) offer is 75000.

As an integral component of a decision support system, decision analysis software should take a problem as posed in the above tables and make some sense out of it. For starters, one would hope to obtain the decisions that optimize the return based on some measure of performance. One possibility is to identify the course for the decision maker that maximizes the expected value of the return. See Raiffa (1970) for a discussion of the use of expected value of the return as a performance measure. The decisions are to either build or not build a prototype and to either submit a high or low bid.

The decision tree in Figure 1 was built from the above tables by an experimental procedure in SAS/OR® software, Version 6.06. It shows the optimal decisions, in the sense of maximizing the expected value of the return. The expected value of submitting a bid is 25850 as is indicated by the EV=25850 on the horizontal line at the root of the tree. The branches indicate the optimal decisions. In this case the expected return from building a prototype is 25850 which is larger than the expected return of 24500 if no prototype is built. As a result, the program recommends building the prototype. If the decision maker decides not to build the prototype anyway, the tree shows that the preferred decision is to make a low bid which results in an expected return of 24500. Similarly, the tree shows the types of bids that should be submitted if the prototype is built and each of the three possible prototype cost outcomes are realized.


Table 3. The Payoff Table


Figure 1. Decision Tree


With all analytical tools, the value of the solution is only as good as the value of the data and information that went into forming that solution. This certainly can be said for decision analysis. Perhaps the greatest value of this tool is in forcing structure on the problem and in enabling the manager to examine the sensitivity of the decisions to changes in assumptions. The most simple approach for “what if” analysis is to modify data, for example, the returns or the probabilities associated with the various outcomes, and redo the analysis. Although this approach provides the greatest flexibility, it can be very tedious and can lead to misunderstandings unless care is taken in interpreting the results.

Several tools for sensitivity analysis have been developed to aid in understanding the decision problem. Two quantities that can be useful are called the value of perfect information and the value of perfect control. The value of perfect information answers the question: What is the value of knowing the outcome of a chance node before a decision is made? For example, what is the value of knowing that the bid will be accepted before the bid is submitted? (An unethical question which won't be debated here.) The value of perfect information is an upper bound on the amount that could be spent profitably to improve data on which of the possible outcomes will occur.

On the other hand, the value of perfect control for the build prototype chance node might be useful. It would tell us the value of controlling the cost of the prototype before the decision to build the prototype is made. It is given automatically by the software (not shown here) and in this case has the value of 9150. This indicates the maximum amount to spend to obtain control over the cost of the prototype.

Clearly this is not a complete discussion of the issues surrounding “what if analyses. There are many other quantities for measuring model sensitivity which can give the prudent decision maker confidence in his or her decision.


Another extension to decision, analysis incorporates the managers attitudes towards risk into the model. The simple expected value criterion assumes that the decision maker is risk neutral. In some cases it is preferable to make decisions in a risk averse position. That is, biasing decisions toward avoiding highly risky ventures (even though they may have a large payoff) in favor of more likely (but lower) returns. This facility is captured using utility theory and maximizing the expected utility of the return rather than its expected value. When using this approach, the manager has another analytic tool to test the sensitivity of the model to changes in attitudes towards risk. See Raiffa (1970) for a thorough discussion of this topic.


As decision support systems for project management applications mature, the need for tools that enhance the analytic capabilities available to managers will become greater. While many of these tools have been available for some time, access to them has been the barrier to wider use. Decision support systems are one approach that can improve access and provide more general exposure. Decision analysis is one such tool which helps managers in defining and planning projects, and in reviewing progress. It is hoped that this brief introduction will generate some interest from the project management community in this powerful and useful area.


1. Burman, P.J. 1980. Precedence Networks for Project Planning and Control. McGraw-Hill. London.

2. Raiffa, H. 1970. Decision Analysis Introductory Lectures on Choices Under Uncertainty. Addison-Wesley. Reading, Mass.

3. SAS Institute Inc. 1989. SAS/OR User's Guide Version 6 Edition. SAS Institute Inc. Cary, NC.


Marc-david Cohen, Manager of Operations Research R&D, received a B.S. in mathematics from Brandeis University and a Ph.D. in Operations Research from the University of North Carolina at Chapel Hill. In past positions be has been involved in applications of operations research to land use planning and the management of renewable resources.

Dr. Cohen joined SAS InstituteInc. in 1981 and is currently product manager of SAS/OR, a software product which includes components for resource allocation, project management, and decision analysis.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

April 1990



Related Content

  • Sponsored Research

    Reinventing Megaproject Delivery Models

    By Denicol, Juliano Megaprojects are usually proposed by the public sector as a reflection of the government delivering a new physical asset to address a necessity of the society, improve living conditions, foster…

  • PM Network

    Battle Plan

    By Mustafa, Abid At a time of increasingly complex business problems, it's natural for project teams to turn to war rooms to solve those challenges. The war room concept gathers all key stakeholders and critical…

  • PM Network

    Plano de batalha

    By Mustafa, Abid Em um momento de problemas de negócios cada vez mais complexos, é natural que as equipes de projeto se voltem para as salas de guerra para resolver desafios.

  • PM Network

    Plan de batalla

    By Mustafa, Abid En un momento de problemas comerciales cada vez más complejos, es natural que los equipos de proyectos recurran a las salas de guerra para resolver esos desafíos. El concepto de sala de guerra reúne…

  • Project Management Journal

    Contingency Release During Project Execution member content locked

    By Ayub, Bilal | Thaheem, Muhammad Jamaluddin | Ullah, Fahim Risk is inherent in construction projects and managed through contingency. Dynamic management of contingency escrow accounts during project execution poses decision-making challenges. Project…