References


References

1. Editor, MIL-HDBK-881, OUSD(A&T)API/PM, U.S. Department of Defense, Washington, D.C., 1998, paragraph 1.4.2.

2. Editor, MIL-HDBK-881, OUSD(A&T)API/PM, U.S. Department of Defense, Washington, D.C., 1998, paragraph 1.6.3.

3. Haugan, Gregory T., Effective Work Breakdown Structures, Management Concepts, Vienna, VA, 2001, chap. 1, pp. 7–13.

4. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 2000 Edition, Project Management Institute, Newtown Square, PA, chap. 5.

5. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 2000 Edition, Project Management Institute, Newtown Square, PA, chap. 2.



Chapter 4: Making Quantitative Decisions

Overview

Decision analysis...is the discipline for helping decision makers choose wisely under conditions of uncertainty.

John Schuyler
Risk and Decision Analysis in Projects, 2001

In this chapter we will discuss making project decisions using quantitative methods. We will focus on the so-called decision tree and its companion, the decision table. Quantitative decisions, whether in trees or tables, often employ an interesting extension of statistical methods called Bayes' Theorem. We will take a look at Bayes' Theorem and see how it can help with making decisions conditioned on other decisions and events.



A Project Policy for Decisions

Quantitative decision making is most useful when there is a rational policy for obtaining the outcomes. Rationality, used in this sense, means that the decision is a consequence of all the inputs having been applied systematically to a decision-making methodology. Given the inputs and the methodology, the decision outcomes are predictable. If only it were so easy in real projects!

Decision Policy Elements

Consider what many would say are necessary policy elements in order that quantitative decisions can be made. [1]

Let's start with an obvious one. If we are trying to choose between one project or another, the first element of decision policy is that we would give priority to those projects that are traceable to goals through strategy. If such is the case, we are assured that the deliverables, applied according to the concept of operations, will yield benefits to the business.

Second, all things otherwise being equal, we would decide in favor of that initiative that brings the most financial gain to the business. Now, if the project or initiative is in the public sector, this principle might not be second. Indeed, this principle may not even be a part of the decision policy. But for profit-making businesses, the financial benefit is always available as a tiebreaker.

Third, as among financial benefits, we would decide in favor of those benefits that are measurable consequences of project outcomes. If cause and effect can be established, then we say we have a consequential benefit. Project managers call such benefits "hard benefits." For example, a project targeted as improving operational efficiency has hard benefits if the cost input of the organization is reduced as a result of project activity. However, if the benefit of the project is "avoided increased costs" in the future, then the benefits are said to be "soft." Between two projects with benefits as described above, the former would have precedence over the latter.

Sometimes financial benefits are not specifically estimated. Project managers say that there is no ROI (return on investment) for the project. Such can be the case for projects in the public sector, but so can it also be the case for research projects. Corporate "internal research and development (IR&D)" projects are done many times because we must explore and innovate. The invention of nylon is said to be more of an accident than anything planned. Was going to the moon in the Apollo program decided on the basis of an ROI? No, but there were benefits set for Apollo and its companion Mercury and Gemini programs. As a matter of policy, projects that advance the mission or respond directly to the commitments of senior managers are often selected first.

Policy should dictate that a quantitative statistical estimate of risk be made. Each risk has a downside and an upside. Every manager and every organization has a risk tolerance. Tolerance usually controls the downside. If the downside is unaffordable, the decision may be that the project cannot go forward. So the policy statement is that for projects of equal quantitative risk estimates, the project that is most risk averse is to be selected over projects of greater risk; if the downside risk exceeds a threshold, then the project cannot be selected, even if it is the least risky of all alternatives.

Finally, the policy should always state that projects must be lawful, ethical, and consistent with all regulatory controls and organizational policies. Of course, the latter two are subject to waivers and set-asides by senior authority.

Table 4-1 summarizes the rational decision-making discussion.

Table 4-1: Decision Policy Elements

Policy Element

Policy Justification

Project alternatives traceable to business goals and strategies

Project choices are most supported and more likely to result in recognizable business results when the choices have clear links to the business goals and strategies. Such linkage is all the more important when the project's resources are challenged for reassignment elsewhere, or when project risks call into question the wisdom of proceeding to invest in the project's progress.

Financial advantage is a tie breaker

Almost all projects have some functional benefit to the business. The only common denominator universally recognized and understood by all business managers is the dollar value returned to the business for having done the project. In the face of essentially equal functional benefit to the business, the tie breaker is always the financial advantage brought to the business by the project. The project with greatest advantage is selected.

Hard benefits trump soft benefits

Hard benefits are measurable and tangible and have clear cause-effect relationships to the project; hard benefits are most often measured in dollars and are therefore most easily understood and evaluated by business leaders. Soft benefits have uncertain cause-effect and the benefits to the business are largely functional. Soft benefits are often difficult to reduce to dollars. The "before and after" principle can be invoked to obtain dollars, but the cause-effect ambiguity discounts the dollars calculated in such a method.

Mission trumps financial when directed by senior authority

Sometimes "we have to do it" and the dollars are much less important. Technically speaking, such a decision is not "rational" based on the definition used in this book, but the decision is most certainly rational considered in a larger context often not involving the project manager or sponsor.

The least risky project trumps a more risky project

All else being equal, a project of lesser risk is always chosen over one with more risk.

All alternatives are legal, ethical, and in compliance with regulation and policy

Project choices should reflect the standards of conduct of the organization. American business usually adopts a standard that prohibits behavior that would jeopardize the business and obviate any benefits returned from the project.

A Context for Quantitative Decisions

Figure 4-1 illustrates the space containing policy, method, inputs, and outcomes. Policy we have discussed. Specific methods will be discussed in subsequent sections, but methods are the tools and processes we apply to input to generate outcomes. Processes can invoke or be constrained by policy, such as applying the hurdle rate for internal rate of return (IRR) and being held to the number of years that go into the calculation. Such policies may be project specific or project portfolio specific, with different figures for each. We will discuss IRR and other financial measures in another chapter.

click to expand
Figure 4-1: Context for Decisions.

Inputs are all the descriptions, data, assumptions, constraints, and experience that can be assembled about a prospective project, event, or alternative that is to be decided. Project managers should have wide latitude to bring any and all relevant material to the decision process. Policy will control the application of input to method, so there is no need to otherwise constrain the assembling of input. The first bit of input needed is a description of the scope of the thing being decided: Is it a choice among projects; a choice among implementation alternatives; a choice of tools, staff, or resources to be applied in a project; or just what? Decisions, by their very nature, are choices among competing alternatives, so a full and complete scope statement of each choice is required. The second component of input is all the attributes of the alternatives. Attributes could include cost, availability, time to develop or deliver, size, weight, color, or any number of other modifiers that distinguish one alternative from another. Third, of course, if there are any constraints (whether physical, logical, mathematical, regulatory, or other), then whatever constraints apply should be scoped and given a full measure of attributes as well.

Once all the inputs, assumptions, experience, and constraints are assembled and organized into separable choices, then a decision methodology can be applied. The fact is that many project managers have trouble organizing the choices and fail to resolve the "if, and, or but" problems of presenting alternatives. However, assembling the choices is the place to stop if the team cannot decide what the alternatives are. If the choices are ambiguous, there is no point in expending the energy to make a decision.

The Utility Concept in Decision Making

When the project manager begins to apply the decision policy to the project situation, the risk attitudes of the decision makers need to be taken into account. If the decision maker is risk neutral, then the decisions will be based on the risk-adjusted estimates without regard to the affordability of the downside or the strategy to exploit the opportunities of the upside. However, decisions are rarely risk neutral if the amount at stake is material to the well being of the organization. In situations where the decision making takes into account the absolute affordability of an opportunity, we call decision making of this type "risk averse." A quantitative view of this concept is embodied in the idea of "utility." Utility simply means that the decision maker's view of risk is either discounted or amplified compared to the risk-neutral view. Figure 4-2 shows this concept. The principal application to projects is evaluating the downside risks attendant to one or more alternatives that are up for a decision. Regardless of the advantageous expected value of a particular opportunity, if its downside is a "bet the company" risk, then the decision may well go against the opportunity.

click to expand
Figure 4-2: Utility Function.

[1]These principles of decision policies are a summarization of the author's experience in many project situations over many years. The material is an expansion of that given in the author's book, Managing Projects for Value. [2]

[1]Goodpasture, John C., Managing Projects for Value, Management Concepts, Vienna, VA, 2001, chap. 3, p. 39.