A balance sheet for projects
a guide to risk-based value--part 2
by John C. Goodpasture, PMP, and David Hulett
In Part 1 [May PM Network], we set up the following proposition: Business leaders are really investors, and they make investment decisions when they charter projects. They have expected outcomes that usually are couched in business improvement terms. Project managers have a mission to deliver on the chartered scope, taking measured risks to achieve the value proposition of the project. These three elements make up the project balance sheet: business investment on the left side, balanced with scope and risk on the right side.
Risk as the Balancer. On the executive's side of the balance sheet, the assignment of resources is precise and deterministic. It is not probabilistic, approximate, or statistical. But on the project side of the balance sheet the situation is different. Forecasting project results can only be approximate, at best. So, how is alignment achieved between management expectation and the estimates of the project team? Enter statistics. Statistical estimation provides the project manager a means to reach agreement with the management team on a point solution for the project completion date or budget. Such a point solution is actually a statistic—a data point—that has been picked from a range of possibilities with agreement between the project manager and the executive. Once picked, it is conveyed to the project balance sheet as the project estimate. The project manager must then manage the project in a manner that defeats the statistical possibility that this estimate may, in fact, be overrun! The task of the project manager in risk management is to defeat the quantitative prediction of a risk analysis and bring the project in for the value assigned by management.
Schedule Risk Analysis. Because schedule has such a high leverage on project success, usually much more than cost, let's focus on the schedule risk as the primary balance sheet risk to manage. (See also “Schedule Risk Analysis Simplified” by David Hulett, PM Network, July 1996). There are three main purposes of a schedule risk analysis: to determine the likelihood of overrunning the schedule; to estimate the likely exposure or contingency needed to drive the remaining risk of overrun down to a level acceptable to the company; and to identify the locus of the key risks in the schedule to guide risk management efforts.
Quantitative schedule risk management is statistically based. The basic statistics terminology can be found in any statistics text. In the PMBOK® Guide chapter on risk management and risk quantification (Chapter 11) can be found the probability density functions most used in schedule analysis: the triangular distribution and the beta distribution. The equations for mean, variance, and standard deviation for these distributions are likewise found in the PMBOK® Guide.
In developing a risk-manageable schedule, an understanding of the following scheduling fundamentals is essential.
Critical path schedules are deterministic. That is, a critical path method (CPM) schedule has at least one path through its network—the critical path—that determines the length of the project. The duration of the critical path schedule is computed by adding single-point estimates of activity durations along the longest contiguous path through the network. The critical path predicts the completion date only if everything goes according to plan. This method is limited because durations really are not certain. Using probabilistic analysis, we find that there is some likelihood that the durations will conspire so that a path that is not the critical path will really become critical. Thus, we define the near critical path: a path that is not deterministically critical, but statistically may become critical, thereby delaying the project.
Activity duration estimates are really probabilistic assessments about what can happen in the future. That is, when the task leader schedules the tasks, the duration, although a single number, is in fact an estimate of the statistically most likely duration of the task.
Exhibit 4. Schedule risk has three basic components.
Well, at least if you use the most likely estimates of duration you'll come up with the most likely completion date, won't you? No, actually you will not, as will be made clear. The completion date is not even the most likely date, much less a date with an acceptable level of risk!
Three Fundamentals of Schedules. To understand how useful statistics can be to risk management of the schedule, consider that schedules are really made up of three basic primitives, as shown in Exhibit 4.
The first component is the single task with an activity duration risk. Each activity appears in the schedule with a duration that represents the most probable number of work periods necessary to accomplish the task.
Reader Service Number 156
Exhibit 5. Duration risk can be managed to reduce variance.
The second schedule risk component is the path. A path is composed of at least two activities linked by a relationship, most commonly finish-to-start when using precedence diagramming methods (PDM).
The third component is the merge point where n-paths join at a milestone. In this case, the milestone is not complete until all paths are complete. Schedule risk often increases at a merge point where any of the paths can delay the project. If each path is statistically independent, then the likelihood of completing the milestone is their probabilities multiplied together.
Schedules and Statistics. Now, let's put schedule elements and statistics together to get a view of the uncertainties in the schedule and a quantitative estimate of what they will do to the CPM dates. Ultimately, a measure of these uncertainties will be transferred to the project balance sheet. We've already made the point that it is common practice to use fairly simple probability distributions to model the uncertainty of the durations caused by various risk factors. Because they model real task behavior quite well, either the beta distribution or the triangular distribution is often used. Their asymmetry is key to modeling the real world, which rarely has perfect symmetry.
The task of the project manager in risk management is to defeat the quantitative prediction of a risk analysis and bring the project in for the value assigned by management.
First, we can deal with the uncertainty in the most fundamental schedule element, the single task. The schedule error in one long task can be “managed” in the following sense. In an example shown in Exhibit 5, the single baseline task is labeled WBS Activity 1.0. It is assumed that its probability distribution can be modeled with a triangular probability distribution. The metrics of interest are the average duration and the standard deviation. The latter is a measure of the dispersion of duration errors, and generally for this statistic, the smaller the better. To examine the risk of the baseline we look at the detailed statistics where the risks can better be identified and quantified. (Also see “Effective Sizing and Content Definition of Work Packages” by Tzvi Raz and Shlomo Globerson, Project Management Journal, December 1998).
In Exhibit 5, we show how subdividing one long task into four subtasks can moderate its risk. Notice that the overall variance and standard deviation are improved for the group of four subtasks as compared to the singular baseline task.
Monte Carlo Simulation. But what about our confidence of making the most probable date, or the average date, or any other date the project manager might have picked from the distribution? To avoid the complexity of the mathematics involved in looking at all the statistics of all the activities, a process known as a Monte Carlo simulation is used to statistically estimate the overall schedule and set confidence limits. This is simply a procedure whereby many iterations of the schedule are calculated, or run. Each iteration uses a different combination of possible durations for the uncertain activities. These durations are chosen at random from the full range of possible durations. The full range is specified by the risk analyst, usually after interviews of experts, and expressed as the probability distribution. We see the results in Exhibit 6, where the probability distribution and the cumulative distribution for a four-task, one-path project are shown. Parameters were selected as minus 10 percent from mean for the most optimistic, and plus 25 percent from the mean for most pessimistic estimate in a triangular distribution. Notice that the average duration date, 30 March, is about 40–50 percent likely, but other dates, particularly the CPM most likely date of 25 March, is about 5 percent likely. In fact, the CPM date is not really close to being the most likely date! The risk analysis shows that to be about 30 March.
Exhibit 6. The CPM date is not close to the most likely date.
The critical path predicts the completion date only if everything goes according to plan.
Next, we want to deal with the whole schedule network and see what insights statistics bring. Exhibit 7 illustrates a Monte Carlo analysis of all three schedule primitives. Triangular distributions are used consistently with the parameters of minus 10 percent, plus 25 percent for minimum and maximum from the most likely, respectively. We've already seen the impact of the simple activity and the activity string. Let's look at the example of the two paths merging. To do this, we examine a new project with two identical paths.
Exhibit 7. Parallel paths cause shift right bias.
Each path is made up of risky activities and the project ends in a finish milestone. We can see that confidence of meeting a date for the merge milestone is approximately the product of the confidences of each path, and for a given confidence, the date is “shifted right.” For instance, in the single path, as previously shown in Exhibit 6, recall that the confidence in meeting 30 March is about 50 percent. At the merge point, as shown in Exhibit 7, the confidence at 30 March is approximately 50 percent times 50 percent, or 25 percent. Note that the CPM date of 25 March, which was about 5 percent likely with one path, is just barely on the map with two paths. Finally, we should pause to remind ourselves that the CPM says each of these projects finishes on 25 March, which is further evidence of the need for risk analysis. What is the most likely date? It is “shifted right” to about 1 April or 2 April with two paths, not 30 March as it is for one path, or certainly not 25 March as predicted by the CPM!
Two very important observations emerge from the schedule risk analysis:
The most likely duration is never the sum of the most likely durations of each schedule activity. That is, most likely calculations (the modes of the distributions) cannot be added! However, averages can be added along a single-path project, so the sum of all the average task durations is the average duration of the whole schedule. But the worst problem, as seen in Exhibits 6 and 7, is that picking the CPM date as the most likely date is rarely a good bet. Even with a single-path project, the CPM date is almost always far too optimistic!
Perhaps most important for risk management purposes, there is a phenomenon at the merge point called merge bias. Merge bias means that at a merge point, the probability that the milestone will finish later than planned is nearly a certainty. (Also see Network-Based Management Systems (PERT/CPM) by Russell Archibald and Richard Villoria, 1967, Wiley, Appendix C, pp. 447–461. The original description of this bias was by Kenneth MacCrimmon and Charles Ryavec while they were at The Rand Corporation.) This is because the likelihood of meeting the merge date is the product of the likelihoods of each of the joining paths, if the paths are independent of each other. Schedule merge points stand out almost automatically as shift-right risk. If the merge point is on the critical path, then any shift-right problems translate directly into a lengthened project schedule! With complex schedules and many parallel paths and merge points, this effect is pronounced. Project managers ignore risk at their peril.
What Have We Learned? Here are the important points:
Risk on the project balance sheet comes from risk analysis. Risk analysis, at least quantitative risk analysis, uses the concepts of statistics. This means, as a practical matter, that schedule elements and cost elements should be statistically estimated. The simplifying tool is the Monte Carlo simulation. The simulation results give the project team and the project manager the information necessary to construct a workable project balance sheet.
Project managers have a mission to deliver on the chartered scope, taking measured risks to achieve the value proposition of the project.
The highest-risk architectural element in a schedule is the merge point of multiple tasks. There is a bias, the merge bias, toward a shift right of the schedule at merge points.
Risk can be quantitatively managed for both cost and schedule elements of the WBS by using the concepts of statistics to minimize the probability of extended durations and overrun cost.
THE PROJECT BALANCE SHEET and the underlying concepts of project value and risk management are effective tools to manage projects for value returned to their investors. These tools provide the mechanisms to relate the traditional triple constraint to the project balance sheet with the project equation. Applying these tools to troubled projects may cause them to be restructured, deferred, or even canceled before harm to the firm is done. But the good news is that many projects that might otherwise get in trouble may stay out of trouble and be successful for all concerned. ■
Reader Service Number 029
John C. Goodpasture, PMP, has 26 years of experience in project and program management. He is vice president for Professional Services Operations, Lanier Worldwide Inc., a company specializing in document management solutions.
David Hulett, Ph.D., is president of Hulett & Associates of Los Angeles, Calif. He consults and trains in project management disciplines, including risk assessment and management, cost estimating, and project scheduling.
June 2000 PM Network