CHAPTER 12

Project Valuation Models

Quantitative project decision analysis can be performed using a project valuation model, which in most cases consists of a project schedule or an economic model. A number of techniques for schedule network analysis are used in project management, including the critical path method, critical chain methods, Event chain methodology, and resource leveling. Influence diagrams can also be used to create a project valuation model. Modeling based on the agile approach to project management does not require determining all project details up front, because it focuses on short project iterations with tangible deliverables.

Model of the Project

Who do you think are the best project managers? One could argue that they are those who use valuation models to help them understand the process without actually experiencing the process. A project manager can even learn how to model a project from the criminals in popular action movies, who always seem to have amazing abilities for precise project planning and execution. Unfortunately, for these characters, in most movies they also have problems with project closing, so the loot ends up on a bus overhanging a cliff. In spite of this, you really believe that they deserve some reward for the slick execution of the project (figure 12-1).

A great example is the 1960 version of Ocean’s Eleven, with Frank Sinatra, and its 2001 remake with George Clooney, Julia Roberts, Brad Pitt, Matt Damon, and Andy Garcia. In the 2001 version, Danny Ocean is an experienced “project manager.” Less than 24 hours after his release from a New Jersey penitentiary, he has already initialized a new project: the most elaborate casino heist in history. First, he assembles a project team of the best professionals money can rent. Then he arranges financing. But, most important, he creates a detailed model of the robbery—an intricately choreographed plan, with every action detailed down to the second. The team analyzes all possible obstacles and carefully models the behavior of their counterparts, the casino security team. If real project managers were able to manage their projects as precisely as Danny Ocean, that would create a revolution in most industries. Perhaps the issue lies in motivation: Danny Ocean and his colleagues stand to make $150 million if they manage to pull off their heist (that, or a lengthy stay in the pen).

Figure 12-1. Robbing a Bank Involves Complex Modeling

Whether you’re a criminal or a project manager, it helps to predict what could happen during a project and what would be the best choices, given the results of this analysis. For example, climatologists create weather models to predict climate change, aircraft engineers build models of new planes to research aerodynamics, and bank robbers draw up plans to rob a casino.

In all these cases, project management models contain inputs, outputs, and calculation algorithms. The inputs include:

• Project activities and their relationships, including estimates of start and finish times, costs, resources, and other parameters

• Risks, with their probabilities, outcomes, and other properties

• Financial information associated with the project, including risks and uncertainties related to financial projections

• Inputs related to quality, safety, and environment

A model’s outputs could include:

• Project schedules, including estimates of project duration and cost

• Project budgets

• Quality and safety-planning evaluations

What kinds of models are we talking about? We’ll discuss two: the schedule model and the economic model.

SCHEDULE MODEL

A schedule model is defined in the PMBOK Guide as “a model used in conjunction with manual methods and project management software to perform schedule network analysis and generate the project schedule . . . .” Schedule network analysis employs a schedule model, together with various analytical techniques, such as critical path, critical chain, and resource-leveling, so to calculate the project schedule. We will learn how this schedule model can be used to come up with certain decisions in part 4 of this book, which focuses on quantitative analysis.

ECONOMIC MODEL

When criminal masterminds are planning a heist, they are concerned about more than timing and scheduling. They also make decisions based on certain financial considerations. How much would it cost to buy a machine gun? What is the chance that they could rob a bank without one? How much money is required to bribe the bank’s security officer to obtain insider information about the vault code? And, most important, how is the gang going to share the loot among themselves? In fact, the criminal mastermind is concerned about the complete project life cycle. The project schedule may also include costs associated with activities and resources. But in many cases, a special model is required for decision-making based on monetary criteria.

Economic models can include an analysis of project performance derived from incremental project cash flows. The foundation of financial analysis is discounted cash flow analysis, which assesses the value of an investment based on predicted cash flows at a discounted value to account for the reduced value of money over time. The economic model should be quite complete and include many details: various sources of revenue and cost, as well as inflation rates, tax rates, and royalties, among other parameters. These models can be created with general-purpose spreadsheet tools or with specialized financial software.

Economic models are used in the decision-making process. Choices can be based on the analysis of outcome indicators and of value measures. Two value measures used for discounted cash flow analysis are net present value (NPV), which is the present value of a series of future net cash flows, and rate of return (ROR), which is a measure of the profitability of an investment.

ALTERNATIVE MODELS

In addition to schedule and economic models, you can create many types of models for the same project. You can analyze technical and business benefits, performance, safety, quality, and environmental issues, and many others, as well. In this book we concentrate mostly on schedule models; however, project decision analysis processes, including quantitative analysis methods, can be similar for other types of models.

If a model contains information related to risks and uncertainties, it is called a probabilistic approach. Otherwise, it is considered a deterministic approach. In this chapter we will discuss modeling techniques for both approaches. Sometimes you will need to create different models for different project alternatives by using common value measures. But in most cases, single probabilistic models should handle most of the possible uncertainties.

The Critical Path Method

Although it was invented way back in the 1950s by the DuPont Company and Remington Rand Univac, the critical path method (CPM) remains one of most popular planning tools, despite all its limitations. It employs the deterministic approach.

The steps in the critical path method are:

• Calculate the start and finish times of each activity chronologically through a network diagram or Gantt chart (from left to right). These are the earliest start and finish times.

• Calculate the start and finish times of each activity the same way, but this time from right to left. These are the latest start and finish times.

• The difference between the latest and earliest times represents “free float” or “slack,” the amount of time the activity can be delayed without delaying any other immediately following activity.

• Activities with zero free float lie on the critical path.

Let’s say a bank robbery project manager creates a schedule that includes the four activities shown in the Gantt chart in figure 12-2. In this case, the activity “secure escape route” has three minutes’ slack: the robbers cannot leave the bank without taking money. Taking money from the vault takes longer than securing the escape route. As a result, the critical path includes, first, “break into the bank,” second, “take money from the vault, and third, “leave the bank.” To reduce project time, this critical path and in particular the activity “take money from the vault” need to be optimized. Maybe the robber needs to consider a better blowtorch or the use of explosives. (Although, if you remember from chapter 3, Gopher’s explosives were rejected as a strategy for getting Bear out of Rabbit’s doorway. They might be helpful here!)

Figure 12-2. Gantt Chart for Bank Robbery Project

But here is the problem. Let’s assume that something happens while the robber secures the escape route. A security guard could notice something, or the rear door might be locked and cannot be opened. This is a scenario that you see in the movies all the time. Because of such risk events, the activity “secure escape route” will become critical. However, the robber spent all his efforts on optimizing the “take money from the vault” activity that was on the critical path and probably spent no time planning for any risk events that might occur during the “secure escape route” activity.

A problem with the critical path method, then, is that it does not take resource allocation into account. The activity “secure escape route” may require more resources than breaking into the vault, and as result it might deserve greater planning and attention. Due to that shortcoming in the critical path method, the robbery attempt may be in jeopardy.

The critical path method sounds very simple, but keep in mind that in reality a number of contingencies can significantly complicate the calculations. Among these contingencies are:

1. Activities may have different logical relationships between them. In addition to finish-start relationships (when previous activity finishes, new activity starts), they can be start-start, finish-finish, and start-finish relationships. Moreover, there can be a time delay between activities.

2. Nonworking time that occurs during the course of the project must be accounted for. Also, different resources may have different calendars.

3. In most cases, project schedules include summary tasks and subtasks. If a summary task is the predecessor or successor of other tasks, this can significantly complicate the algorithm.

4. Schedules may include time constraints. For example, an activity must start or finish on a certain date. This can lead to scheduling conflicts.

Fortunately, many project-scheduling software tools are available to help you perform the critical path analysis.

The critical path method by itself is a deterministic approach. Probabilistic analysis can be implemented in conjunction with the critical path method. The PMBOK Guide mentions a number of other deterministic techniques to use in schedule network analysis. One of them is the what-if scenario analysis, which is the analysis of project schedules under a multitude of conditions and situations.

The PMBOK Guide also describes resource leveling, another schedule network analysis technique that can be implemented at the top of the critical path method. Resource leveling helps you come up with a project schedule when resources are limited.

The Critical Chain Method

The critical chain method, another schedule network analysis technique, derives from Eliyahu Goldratt’s theory of constraints. In his book The Goal (Goldratt 2014), he applied the theory to manufacturing processes. The idea was to improve manufacturing processes by identifying and removing bottlenecks. In 1997 he wrote Critical Chain, in which he applied the theory of constraints to project scheduling (Goldratt 2002). The critical chain method is included in the PMBOK Guide as a schedule network analysis technique.

The critical chain method focuses on managing constrained resources and buffer activities. It applies both deterministic and probabilistic approaches, because it combines deterministic project schedules with buffers designed to deal with uncertainties.

The three key steps in the critical chain method are:

1. Create a project schedule and calculate the critical path in the same manner as performed for the critical path method. This project schedule is deterministic. Goldratt suggested using a median (50% confidence) estimate of duration for the activities.

2. Enter resource availability. You may need to adjust the project schedule to exploit constrained resources. As a result, the critical path can be altered. Using this method, you can then identify the critical chain, which is a resource-constrained critical path.

To deal with uncertainties, you may need to add buffers to the end of the project and also add a “feeding” activity chain, which merges into the critical path. These feeding buffers, which are nonwork schedule activities, will protect activities from the slippage of preceding activities. Slippage may occur because of uncertainties and the student syndrome, but buffers are supposed to absorb the uncertainties of future events.

Several software tools (see appendix A) are specifically designed to implement the critical chain method in project management. The critical chain method has become increasingly popular in some organizations.

Event Chain Methodology

Event chain methodology is another probabilistic technique used to perform schedule network analysis. We will discuss the methodology in detail in part 4, because it is a quantitative analysis method, but here is a short introduction (Virine and Trumper 2013, 2017).

Event chain methodology is based on the notion that regardless of how well we develop a project schedule, something may happen that will dramatically affect it. Identifying and managing these events or “event chains” (when one event causes another event) is the focus of Event chain methodology. Why do we focus on events, rather than a continuous process for a changing project environment? We do so because when continuous problematic events come up within a project, it is possible to detect and fix them early.

Another function of Event chain methodology is mitigation of the negative effects of cognitive and motivational biases. As we have seen, in many cases we intentionally or unintentionally create project schedules that are not possible to implement.

In Event chain methodology, you first need to create a schedule model, using a best-case estimate of duration, which in most instances will be optimistic. Why optimistic estimates? As a result of a number of cognitive and motivational factors—including the planning fallacy or optimism bias, overconfidence, and the rule of pi—we tend to create optimistic estimates even when we are trying not to. Since it is impossible to prevent project managers from defining an over-optimistic schedule, we have to accept it and work with it.

Next, define a list of events and event chains with their probabilities and impacts on tasks or resources. In this process we need to identify events separately (separate time, meeting, experts) from the schedule model in order to avoid confirmation bias, where our expectations about the project (cost, duration, and so on) affect event identification. You can visualize these events using event chain diagrams. Then you perform a quantitative analysis to generate a new schedule that takes these risk events into account. You can repeat the analysis regularly during the course of a project to provide up-to-date forecasts of project duration or cost.

If you are using a critical chain project management process, you may apply Event chain methodology to determine the size of a buffer. The buffer duration is the difference between project duration with risks and uncertainties and the original optimistic project schedule.

Although Event chain methodology is a relatively new approach, it is used in many organizations, including large corporations and government agencies. You can find a list of software tools that implement Event chain methodology in appendix A.

Modeling with Influence Diagrams

Influence diagrams are a useful graphic tool to help you model problems. The concept of influence diagrams originated at Stanford University and the Strategic Decision Group in Menlo Park (Howard and Matheson 1984/2005; Shachter 1986). In chapter 11 (“Project Risk Management”) of the PMBOK Guide, influence diagrams are recommended as one of the diagramming techniques for information gathering.

Figure 12-3. Different Types of Nodes

Figure 12-4. Influence Diagram

Elements of decision problems are represented by different types of nodes (figure 12-3). An example of an influence diagram is shown in figure 12-4. It represents a decision about the design and development of a new product that has to be made at the project launch. Construction of an influence diagram starts with defining a value measure. In this example, it is the project’s net present value. The decision to launch the project is affected by three uncertain variables: availability of resources, requirements, and abilities to solve technical issues.

Remember that influence diagrams do not have feedback loops: variable-predecessors cannot rely on variable-successors. Sometimes influence diagrams can be very complex. In these cases, it is important to break the diagram into a number of smaller diagrams.

An influence diagram can be converted to a decision tree, which is another representation of the decision problem. We will discuss decision trees in chapter 15.

In many cases, it is easier to create valuation models using influence diagrams than to create them in spreadsheets or other software. In appendix A, you will find information on software that will generate project models using influence diagrams.

The Agile Approach and Project Decision Analysis

In February 2001, a group of 17 software gurus met at a Utah resort to talk, ski, relax, and eat. Out of that meeting came what they called the “Manifesto for Agile Software Development” (Manifesto 2006). It defined high-level guidelines for software development processes. Here are few ideas from that document:

• Customer satisfaction is increased by rapid, continuous delivery of useful software.

• Changing requirements are welcomed, even late in development.

• Working software should be released frequently, within periods ranging from a couple of weeks to a couple of months.

• Business-people and software developers must work together every day throughout a project.

• Team motivation and creative environments are important to deliver good projects, and individuals should be trusted to get the job done. To quote from the manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.”

• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

• “Working software is the primary measure of progress.”

• “Continuous attention to technical excellence and good design enhances agility.”

• “Simplicity—the art of maximizing the amount of work not done—is essential.”

Few successful business ideas are absolutely new. An idea becomes successful when the right individual is able to express and popularize it in such way that the idea becomes appealing to many people. Surprisingly, if you think about it, we use the agile approach all the time in our lives. We humans cannot define right at the start every single step that we will have to take to accomplish our goals. Therefore, we tend to solve problems iteratively, based on the results of our previous activities. This is partially related to our bounded rationality, which we discussed in chapter 2. That is, we are not capable of comprehending all of life’s complexities, so we apply simplified mental models to our problems. As a result, we develop specific methods to implement our general plans as we progress.

The agile approach is actually a family of different methods, the development of which started in the mid-1990s as a response to “heavyweight” methodologies that focused on micro-management of projects. Essentially, these “waterfall” methods, which required defining all requirements up front, contradicted the ways in which engineers were actually performing their work. Waterfall methods are sequential project management processes in which project development is seen as flowing steadily downward like a waterfall through the various phases such as requirements analysis, design, and implementation.

Agile has become increasingly popular for research and development projects, not only in the area of software development but also in other industries. The agile approach is not a panacea and cannot be completely implemented in many situations. It is hard to rob a bank iteratively. And criminal masterminds may not allow members of the gang to express the full extent of their creativity, because creativity during a robbery can bring unexpected results. However, often, in projects where an agile approach would be appropriate, it lies unused. At first glance, the idea of not defining all the requirements and designs up front and trying to develop a product iteratively may appear counterintuitive. How can we produce something without knowing exactly what the end result is supposed to be? Do self-organizing teams equal team anarchy? These are valid questions, yet the measured results of projects managed on agile principles confirm the benefits of the approach (Highsmith 2009).

How do decision analysis and agile project management relate to each other? An effective decision analysis process shares the same foundations as agile project management:

• Creative environments free of frustrated employee syndrome (FES) are a component of effective agile management and a necessary condition for effective decision analysis.

• Identifying and managing risks is one of the cornerstones of agile processes and a fundamental element of the decision analysis process.

• Adaptive management and review of decisions made (phase 4 of the decision analysis process) is also an important step in the agile approach.

• Decision analysis processes include a mechanism for improving decisions in an environment where requirements are always changing. Decision analysis includes a notion of target-oriented decision-making, which we discussed in chapter 3. Similar to agile project management, target-oriented decision-making is a process that increases the probability of meeting changing project requirements.

The agile approach is a highly rational concept in project management, because it helps to mitigate several common biases and mental traps that may arise in waterfall approaches. For example, the sunk-cost effect that may occur in waterfall approaches prevents us from giving up on an activity that is failing or not meeting its objectives despite many resources having already been spent on it. Another psychological bias, also related to the waterfall approach, is the illusion of control: project managers believe that they are in control of situations when in reality they are not.