QUẢN TRỊ DỰ ÁN - Project management chapter 11

QUẢN TRỊ DỰ ÁN - Project management chapter 11

Notes 341

Notes

1 "Zoom-Zoom, Splish-Splash: The Odd Tale of the Cougar Ace

and Its Automotive Cargo," www.edmunds.com/insideline/do/

Columns/articleId=116606/subsubtypeId=218; "High Tech

Cowboys of the Deep Seas: The Race to Save the Cougar

Ace," www.wired.com/science/discoveries/magazine/16-03/

ff seacowboys; "A Crushing Issue: How to Destroy Brand-New

Cars," Wall Street Journal, April 29, 2008, pp Al, A9

2 Nicholas, J M (1990), Managing Business & Engineering

Projects Englewood Cliffs, NJ: Prentice-Hall; Hulett, D (1995),

"Project schedule risk assessment," Project Management

Journal, 26(1), pp 23-44; Lock, D (2000), Project Management,

7th ed Aldershot: Gower; Oglesby, P., Parker, H., and Howell,

G (1989), Productivity Improvement in Construction New

York: McGraw-Hill

3 Cooper, K G (1998), "Four failures in project management,"

in J K Pinto (ed.), The Project Management Institute Project Management Handbook San Francisco, CA: Jossey-Bass,

pp 396-424

4 Gray, C F and Larson, E.W (2003), Project Management

Burr Ridge, IL: McGraw-Hill

5 Shtub, A., Bard, J F., and Globerson, S (1994), Project Management: Engineering, Technology, and Implementation

Englewood Cliffs, NJ: Prentice-Hall; Navarre, C and Schaan, J (1990), "Design of project management systems from top management's perspective," Project Management Journal, 21 (2)

Critical Chain Project Scheduling

Chapter Outline

PROJECT PROFILE Canada's Oil Sands Recovery Projects INTRODUCTION

11.1 THE THEORY OF CONSTRAINTS AND CRITICAL CHAIN PROJECT SCHEDULING

Theory of Constraints Common Cause and Special Cause Variation

11.2 CCPM AND THE CAUSES OF PROJECT DELAY

Method One: Overestimation of Individual Activity Durations Method Two: Project Manager Safety Margin

Method Three: Anticipating Expected Cuts from Top Management

11.3 HOW PROJECT TEAMS WASTE THE EXTRA SAFETY THEY ACQUIRE

Method One: The Student Syndrome Method Two: Failure to Pass Along Positive Variation Method Three: Negative Consequences of Multitasking Method Four: Delay Caused by Activity Path Merging

11.4 THE CRITICAL CHAIN SOLUTION TO PROJECT SCHEDULING

Developing the Critical Chain Activity Network Critical Chain Solutions vs Critical Path Solutions PROJECT PROFILE

BAE Systems and Critical Chain Project Management

11.5 CRITICAL CHAIN SOLUTIONS TO RESOURCE CONFLICTS 11.6 CRITICAL CHAIN PROJECT PORTFOLIO MANAGEMENT

PROJECT MANAGEMENT RESEARCH IN BRIEF Advantages of Critical Chain Scheduling

11.7 CRITIQUES OF CCPM

Summary Key Terms Solved Problem Discussion Questions

342

Project Profile 343

Problems

Case Study 11.1 Judy's Hunt for Authenticity

Case Study 11.2 Ramstein Products, Inc

Internet Exercises

Notes

Chapter Objectives

After completing this chapter, you should be able to:

1 Understand the difference between common cause and special cause variation in organizations

2 Recognize the three ways in which project teams inflate the amount of safety for all project tasks

3 Understand the four ways in which additional project task safety can be wasted

4 Distinguish between critical path and critical chain project scheduling techniques

5 Understand how critical chain methodology resolves project resource conflicts

6 Apply critical chain project management to project portfolios

PROJECT MANAGEMENT BODY OF KNOWLEDGE CORE CONCEPTS COVERED

IN THIS CHAPTER

1 Activity Sequencing (PMBoK sec 6.2)

2 Activity Duration Estimating (PMBoK sec 6.3)

3 Schedule Development (PMBoK sec 6.4)

4 Schedule Control (PMBoK sec 6.5)

5 Resource Planning (PMBoK sec 7.1)

PROJECT PROFILE

Canada's Oil Sands Recovery Projects

When we think of countries rich in oil deposits, what are the most common names that come to mind? Saudi Arabia? Iran? Kuwait? Venezuela?

How about Canada?

The world's demand for oil continues to grow at insatiable rates Newly industrialized and rapidly growing regions like China and India have added to the demand for petroleum products, contributing to a chaotic pricing market that, in the space of one year, whipsawed over a range of $140 to $36 a barrel Because gasoline prices have soared in recent years to record levels, they have seriously affected inflation rates and many countries' ability to avoid recession and industrial downturns It is against this demand that Canada has been aggressively developing its strengths in mineral deposits, encouraging national and international oil firms to invest in its oil sands recovery Oil sands are deposits of bitumen, heavy viscous oil that must be rigorously treated to convert it into an upgrad-

ed crude oil before it can be used by refineries to produce gasoline and diesel fuels Bitumen is so thick and sticky that

it will not flow unless heated or diluted with lighter hydrocarbons At room temperature, it is much like cold molasses The oil sands region is located in the upper half of the province of Alberta, sited around the city of Fort McMurray, or "Fort McMoney," as it is referred to locally in reference to the enormous wealth flowing from the region and the boom town feel of the area The total known oil sands deposits are found in three places in Alberta—the Athabasca, Peace River, and Cold Lake regions—and cover a total of nearly 140,200 square kilome-ters That is approximately the size of the state of Florida

Alberta's oil sands comprise one of the world's two largest sources of bitumen; the other is in Venezuela To put this in perspective, Canada's proven oil reserves are second only to Saudi Arabia's and constitute 15% of the world's proven reserves In quantity, the oil sands region accounts for 174 billion barrels of oil That is just what is

on the surface or can be recovered with current techniques The estimate of total reserves below the surface is staggering, with estimates of 2 to 3 trillion barrels of oil That's eight times the reserves in Saudi Arabia

Why has it taken Canada so long to realize the potential for oil sands in the face of a continuing spike in oil prices and high demand? The chief answer is because of the difficulty and cost associated with extracting oil from

(continued)

344 Chapter 11 • Critical Chain Project Scheduling

FIGURE 11.1 Canada's Oil Sands

this source Oil sands are significantly denser and heavier than other crude oils Because of the unique properties

of oil sands, they require an entirely different approach to their recovery While conventional crude oil flows rally or is pumped from the ground, oil sands must be mined or recovered in place

natu-Oil sands recovery processes include extraction and separation systems to remove the bitumen from sand and water The process of converting oil sands to crude oil is painstakingly slow and requires careful processing Nearly two tons of oil sands must be dug up, moved, and processed to produce just one barrel of oil Roughly 75% of the bitumen can be recovered from sand; processed sand has to be returned to the pit and the site reclaimed Bitumen makes up 10-12% of the actual oil sands found in Alberta The remainder is 80-85% mineral matter, including sand and clays, and 4-6% water Mineable bitumen deposits are located near the surface and can be recovered by open-pit mining techniques The Syncrude and Suncor operations near Fort McMurray use the world's largest trucks and shovels to recover bitumen One giant truck (they each cost $5 million) can carry 400 tons of oil sands After processing, that's about $10,000 per truckload

Until the price of oil held at a constant rate above $40 a barrel, the extraction costs for oil sands were just too high to make the process feasible Now, with oil price levels generally above that figure, a number of international oil companies, including Shell and BP, have invested billions in extraction facilities and pipelines to mine and process oil sands for shipping to points south The table gives a sampling of the number of projects, the amount invested, and the productivity of their operations

A Sampling of Current Oil Sands Projects

Petro-Canada $2 billion 50,000 bpd by 2009 OPTI Canada $450 million 70,000 bpd SynEnCo Energy $3.5 billion 100,000 bpd Husky Energy $1.6 billion 50,000 bpd Exxon Mobil $5-8 billion 100,000 bpd by 2010 Syncrude Canada $8 billion 350,000 bpd

Shell/ChevronTexaco $5.7 billion 155,000 bpd

*In bpd (barrels per day)

11.1 The Theory of Constraints and Critical Chain Project Scheduling 345

Not all the oil companies' money is being spent on plant and equipment costs Finding skilled oil workers willing

to work in the often frigid temperatures of northern Alberta has been on ongoing challenge A skilled welder, for example, can earn upward of $200,000 a year at the site Shell Canada has just inaugurated a sophisticated housing project for its 2,500 workers, as part of a $12 billion investment in the region Workers are fed and housed in comfortable private quarters, given generous travel allowances, and have state-of-the-art exercise and recreational facilities

The huge increase in the price of oil in the past decade has been a significant problem for most of us; this is decidedly not the case for the Canadian oil sands recovery industry With prices at a point where recovery efforts are economically feasible, we are likely to see an increase in these recovery ventures Oil companies continue to scrape the surface for unburied riches 1

INTRODUCTION

Scheduling approaches that rely on CPM/PERT are generally accepted as standard operating procedure by most project-based organizations Complications often occur, however, when we begin linking resource requirements to our developed schedules As we will see in Chapter 12, the problem of constrained resources often reduces the flexibility we may have to create an optimal project schedule In recent years, however, an alternative scheduling approach by the name of Critical Chain Project Management (or CCPM) has become increasingly popular This alternative approach was developed in the mid-1990s by Dr Eli Goldratt CCPM offers some important differences and advantages over more commonly used critical path methodologies Lucent Technologies, Texas Instruments, Honeywell, and the Israeli aircraft industry are among a diverse group of major organizations that have found the underlying premises of CCPM intriguing enough to begin disseminating the process throughout their project operations (Leach, 1999)

This chapter will explore in detail some of the important components of Critical Chain Project Management We will see how, as supporters contend, this alternative scheduling mechanism promises to speed up project delivery, make better use of project resources, and more efficiently allocate and discipline the process of implementing projects The model is based on Goldratt's theory of constraints (TOC) methodology, which was originally proposed as a process for removing bottlenecks from production processes In its current configuration, TOC also offers some important guidelines for project management One key feature of CCPM is that it represents both a cultural shift and a change in scheduling processes In practice, if CCPM theory is to be correctly applied, important technical and behavioral elements must be understood in relation to each other The chapter will focus on these aspects of the process

11.1 THE THEORY OF CONSTRAINTS AND CRITICAL CHAIN PROJECT

SCHEDULING

In practice, the network schedules we constructed in the previous two chapters, using PERT and bilistic time estimates, are extremely resource dependent That is, the accuracy of these estimates and our project schedules are sensitive to resource availability—critical project resources must be available to the degree they are needed at precisely the right time in order for the schedule to work as it is intended One result of using "early start" schedules is to make project managers very aware of the importance of protect-ing their schedule slack throughout the project The more we can conserve this slack, the better "buffer" we maintain against any unforeseen problems or resource insufficiency later in the project Thus, project man-agers are often locked into a defensive mode, preparing for problems, while they carefully monitor resource availability and guard their project slack time The concept of theory of constraints as it is applied to Critical Chain Project Management represents an alternative method for managing slack time and more efficiently employing project resources

proba-Theory of Constraints

Goldratt originally developed the theory of constraints (TOC), first described in his book The Goal (1984), for

applications within the production environment 2 Among the more important points this author raised was the idea that, typically, the majority of poor effects within business operations stem from a very small number

of causes; that is, when traced back to their origin, many of the problems we deal with are the result of a few core problems The key idea behind TOC might be the notion that any "system must have a constraint

346 Chapter 11 • Critical Chain Project Scheduling

1 Identify the system constraint

5 leeviiIttate 2 F.xploil the

4 Hevate the 3 Sul )(tt-tlitt11('

the sy! ;tern cc ^nstr^lint

FIGURE 11.2 Five Key Steps in Theory of Constraint Methodology

Otherwise, its output would increase without bound, or go to zero" (quoted in Leach, 1999) 3 The key lies in identifying the most central constraint within the system Five distinct steps make up the primary message behind TOC methodology (see Figure 11.2):

1 Identify the system constraint First, an intensive search must be made to uncover the principle constraint, the root cause, which limits the output of any system It is important not to get bogged down in identifying numerous secondary causes or "little problems."

2 Exploit the system constraint Once the constraint is identified, a strategy for focusing and viewing all activities in terms of this constraint is necessary For example, if the constraint within a software development firm is having only one advanced application programmer, the sequence of all project work to be done by the programmer has to be first scheduled across the organization's entire portfolio

of active projects

3 Subordinate everything else to the system constraint Make resource commitment or scheduling decisions after handling the needs of the root constraint Using the above example, once the "critical resource constraint" of one programmer has been identified and the programmer's time scheduled across multiple projects, the rest of those project activities can be scheduled

4 Elevate the system constraint The first three steps acknowledge that the system constraint limits an organization's operations According to Goldratt, the fourth step addresses improvement of the system

by elevating the constraint, or seeking to solve the constraint problem by eliminating the bottleneck effect In our software-programming example, this may mean hiring an additional advanced applica-tions programmer For many project-based examples, "elevating the system constraint" may be as simple

as acquiring additional resources at opportune times

5 Determine if a new constraint has been uncovered, then repeat the process Clearly, the removal

of the key system constraint will lead to positive advantages for a time Since there is always a system constraint, however, removing one constraint is only likely to identify a new source of constraint for the operation TOC argues for the need to always prepare for the next potential problem before it becomes too serious, so this final step is really only one step in continuous improvement cycles

When examining a project schedule from the perspective of TOC methodology, it is again possible to focus

on the key system constraint; that is, there is one root cause from which all other scheduling problems evolve The system constraint for projects is initially thought to be the critical path Remember, the critical path is defined as the earliest possible time on the activity network it can take to complete a project If activities on the critical path are delayed, the effect is to cause delays in the overall project Critical path is determined by the series of activities whose durations define the longest path through the network and therefore identify the project's earliest possible completion Goldratt notes that all scheduling and resource problems associated with projects typically occur due to problems with trying to maintain the critical path, hence its oft-made identification as the chief system constraint.4

•

♦♦

♦ ♦♦

11.1 The Theory of Constraints and Critical Chain Project Scheduling

Common Cause and Special Cause Variation

A common mistake made in many organizations is to routinely assume that every event (mistake, accident, or defect) is attributable to some direct source or person It is more typical, in fact, that errors are indicative of general problems within the organization and its operations 5 We routinely err by assuming that variation (faults in the system) represents special causes rather than common ones One of the foremost industrial authors of the latter part of the twentieth century, Dr J Edwards Deming, suggested that an "understanding

of variation" was one of the principal sources of profound knowledge to be acquired from studying tional activity He identified two types of variation: 6

organiza-1 Common cause variation is inherent in the system; that is, a chance error exists because of flaws in how

the system was originally created

2 Special cause variation is attributable to a special circumstance For example, it may be specific to

some set of workers, piece of machinery, or local condition

The concepts of variation highlight how important it is to identify a system's chief constraint All projects contain common cause variation in terms of how long it takes to complete project activities This variation refers to the normal range of uncertainty in any activity's performance time Because the most common sequencing approach for scheduling is the finish-to-start connection, it follows that projects will contain a degree of statistical variation based on the chain of dependent events According to Deming, assuming that this statistical, common cause varia- tion is in fact a special cause variation is a common mistake This happens because along with defining projects as

"one of a kind" comes a tendency to also define all project activities as unique, or rooted in special cause variation and not subject to statistical control Therefore, when problems occur, we react to them individually rather than looking at the system for the source of the underlying cause It has been pointed out that this type of response to variation leads management to overreact, to mistake the correct response for the immediate one, or to fail to cor- rect systemic problems (common cause variation) because they are perceived as unique (special cause variation) 7

An example of the problems firms have when they mistake difficulties arising from common cause variation for special cause is illustrated by the case where top management at a company demanded a detailed exception report every two weeks from the project manager on project status Suppose that at one such exception report meeting, the senior executives noted a 5% divergence from the project's planned schedule Rather than treating this occurrence as a simple case of common cause variation, which might very likely be corrected in the natural course of project development over the coming weeks, the top management group overreacted, ordering detailed (and expensive) project assessment to "correct" the problem In this case, management chose to treat the variance result as a special cause variation, assuming a unique problem had surfaced The ultimate result of situations such

as this, in which common cause variation is treated as a special cause, is to lead the organization to search for the specific "problem," while wasting considerable time and money on the task, when it may not be necessary Deming illustrates his distinction between common cause and special cause risk with a funnel exercise The funnel drops a marble onto a sheet of paper below that has been quartered, with a midpoint indicating the origin of the problem (see Figure 11.3) The object is to drop the marble directly onto the origin point,

1 5

• 0.• • •

I I • • -0.5 • •s

-1.5 -2 -2 -1.5 0.5 l.5 2

FIGURE 11.3 Distribution Based on Common Cause Variation

Source: L P Leach (1999), "Critical chain project management improves project performance," Project Management Journal, 30(2), 39-51, figure

on page 42 Copyright © 1999 by Project Management Institute Publications Reproduced with permission of Project Management

348 Chapter 11 • Critical Chain Project Scheduling

FIGURE 11.4 Distribution Based on Misinterpretation of Variance

Source: L P Leach (1999), "Critical chain project management improves

project performance," Project Management Journal, 30(2), 39-51,

figure on page 42 Copyright © 1999 by Project Management Institute Publications Reproduced with permission of Project Management Institute Publications via Copyright Clearance Center

indicating no variance As the figure demonstrates, in a sample exercise where the funnel remains fixed in place, the pattern of marbles that fell onto the paper is clustered around the midpoint This pattern would represent an example of common cause variation

Now, assume that the person dropping the marble reacts to each strike on the paper by repositioning the funnel to compensate for the error (distance from the origin at which the marble landed) He moves the funnel the same amount, but in the opposite direction, from the point where the marble struck the target This is the sort of reaction a manager may make to respond to the variance and correct for it For example, if

a project activity is projected as coming in 10% over schedule, the project manager may redirect resources to respond to the problem Note the result, as Deming pointed out, when the manager makes a series of discrete, reactive moves in response to each case of variance Figure 11.4 shows the new marble pattern based on movements made to compensate for suboptimal (not centered on the origin) responses Variation has increased because, Deming notes, the manager is misinterpreting common cause variation (inherent in the system) to be special cause variation (unique to the activity)

On the other hand, treating special cause variation as if it were common cause variation can lead to its own form of trouble Mistaking discrete forms of project risk for overall common cause variation in the system makes it nearly impossible to conduct adequate risk analysis and response exercises Any identifiable risk is, by definition, a source of special cause variation

In applying the principle of common cause variation to the theory of CCPM, writers have offered the following recommendations, based on Deming's analysis

1 Understand the difference between common and special cause variation

2 Do not make adjustments to projects when the variation in project performance (or activity durations) lies within the range of common cause variance

3 Do not include special cause variation in project risk simulation This causes the project team to estimate project schedule contingency

over-4 Perform project risk management on discrete project risks; do not aggregate the risks

Even when using Monte Carlo simulation models, it is possible to widely misestimate the time necessary to complete activity tasks Statistical controls of project scheduling imply that managers must take a realistic view when allocating contingency time One reason for errors in estimation is based on the concept of common versus special cause variation Other reasons, Goldratt and others point out, are more behavioral in nature!'

11.2 CCPM AND THE CAUSES OF PROJECT DELAY

CCPM has much to say about the nature of the causes of inaccurate project activity duration estimation First, the real world is one of statistical fluctuations, so according to CCPM using a point estimate does not make sense and renders most duration values meaningless Deming would argue that this process is another

11.2 CCPM and the Causes of Project Delay 349

example of project teams' inability to understand variation However, even providing for the fallacy of guided single-point duration estimates, a number of issues can distort accurate duration estimation Many of these causes, Goldratt contends, are behavioral in nature, rather than technical (related to poor estimation metrics) Specifically, CCPM suggests that there are a number of ways project members can routinely add safety (project slack or buffer) to the estimated length of project activities

mis-Method One: Overestimation of Individual Activity Durations

When estimating the amount of time needed to complete an activity, it is common for team members to build in, or pad, their estimates with enough safety to feel confident that they will be able to complete the project within their estimated time For example, when someone traveling to a meeting asks how long it will take to drive from Washington, D.C., to Baltimore, Maryland, the reasonable answer might be 45 minutes If penalties are associated with being late to the meeting, however, it is more likely that the answer will include allowing extra time for unforeseen events disrupting the trip (detours, flat tire, speeding ticket, or heavy traffic) With these contingencies in mind, a new, reasonable guess might be one, two, or even more hours just to travel a route that we normally could drive in 45 minutes The same principles apply when we change the example to a project case A member of the project team charged with a task is likely to factor in suffi- cient extra slack time (safety) to feel reasonably confident that it can be done when promised

Figure 11.5 shows an example of a Gaussian or lognormal distribution for estimated activity time needed

to complete a work package Note the probabilities for the task's completion as a function of time The more time allocated to the task, the higher the probability it will be finished within the designated time Unfortunately,

as the distribution suggests, in order to estimate completion of an activity with a 90% or higher degree of dence, the time may be overestimated by as much as 200% A project activity we could reasonably expect to be completed by day 6 (based on a mean estimate), * may not be promised until day 18 This overpadding of indi- vidual tasks adds an enormous amount of additional time to the project estimate

confi-Method Two: Project Manager Safety Margin

Once each team member has made his own estimates of activity duration (factoring in padding for each task), the project manager aggregates these estimates into an overall project estimate However, project managers tend to pro- tect their safety just as their team members do They typically add to their own margins at the aggregate project level Consider a case in which three team members each provide their manager with estimates of 2 weeks each per activity A normal aggregation of these individual estimates would be 2 + 2 + 2 = 6 weeks However, because proj- ect managers are themselves fearful of the impact of missing deadlines, they often factor in some margin for addi- tional, project-level safety Thus, 2 + 2 + 2 may equal 8, 9, or even 10 weeks, rather than 6 The project manager has added the additional time after the fact to build in some personal protection for the overall project schedule

Method Three: Anticipating Expected Cuts from Top Management

The third manner in which additional safety is routinely added to project activities is based on the fact that an organization's top management typically endorses aggressive schedules Often, members of the top manage- ment team will examine a schedule, decide it is too long, and mandate significant cuts In one case, a firm's

FIGURE 11.5 Gaussian (Lognormal) Distribution

The idea of mean estimation with the Gaussian distribution is necessary in order to distinguish it from the 50% likelihood estimate based on median Means are added linearly regardless of distribution, whereas a 50% likelihood refers to the median, which in a skewed distribution such as that shown in Figure 11.5, can be significantly different from the distribution mean

350 Chapter 1 I • Critical Chain Project Scheduling

top management was noted for their insistence on cutting duration estimates by a minimum of 20% Eventually, project teams began to recognize this process and simply added an extra 25% to the initial plan in order to protect their "real" time frame

When combined, these three practices can lead to grossly overinflated duration times, but more tantly, they speak to a central lack of trust within the organization When an organization's culture does not encourage authentic behavior, it sends the signal that what is "really" rewarded are acts aimed less at project delivery and customer satisfaction than at self-protection and deception All in all, they speak to a lack of organizational discipline in running projects 9

impor-11.3 HOW PROJECT TEAMS WASTE THE EXTRA SAFETY THEY ACQUIRE

Some of the ways projects lose time is institutional; they result from cultural attitudes propagated by the firm

or are caused more directly by policies the organization promotes Other reasons for such delays are behavioral

in nature, stemming from individual work habits and poor self-discipline

Method One: The Student Syndrome

The first analysis of why team members waste project activity time is called the student syndrome or the term paper model, and it is basically procrastination, the tendency to put off maximum effort until the last possible moment We see this effect occurring in our illustration (see Figure 11.6), which links the percentage of time elapsed on an activity with the percentage of the work completed This figure represents the type of progress often found in the completion of a project activity Although an idealized process line would show steadily increasing progress from the starting date to final project completion, many individuals tend to delay the start

of the activity as long as possible, concentrating on more immediately visible or critical tasks Eventually, however, as Figure 11.6 notes, project team members begin to realize the milestone date is approaching and their effort starts ramping up dramatically The student syndrome is a useful model for highlighting common project effort because:

1 People have a tendency to minimize responsibilities with long end-date completions in favor of more immediate or critical deadlines

2 If people believe that they built extra time into their initial estimates, it further demotivates them from addressing these commitments early

3 Project resource personnel in "high demand" must routinely juggle their schedules to accommodate

multiple commitments, precluding them from addressing tasks with long deadlines in a timely fashion

11.3 How Project Teams Waste the Extra Safety They Acquire 351

Parkinson's Law states that work expands to fill the time available Rarely do team members finish in less than the amount of time initially projected to accomplish a task The reason for this phenomenon lies, in part, with the second method for squandering safety time

Method Two: Failure to Pass Along Positive Variation

When multiple activities are linked in a finish-to-start format, as in the case of most standard activity works, each subsequent activity is at the mercy of its predecessors in terms of when it can begin Delays in a project activity (negative variation) lead to additional delays downstream, as subsequent activities must be started later, path slack is used up, and so forth When a preceding activity is actually completed early, it would be natural to expect that the early completion (positive variation) will also be passed along and the network path in which this activity lies will gain additional time downstream However, one of the arguments underlying the behavioral consequences of project management suggests that the opposite case is bound to occur more often; positive variation is not passed along Why is this the case? There are a number of reasons:

net-1 Finishing a task early gives project team members the opportunity to work on other projects or work assignments that have backlogged on their desks In effect, early completions represent an Opportunity

to put a project on hold for some period of time in order to reduce other commitments

2 Team members may fear that their future work time estimations will no longer be taken seriously if they deliver early When asking team members to estimate the amount of time necessary to complete a task, the project' manager trusts their technical judgment If a team member estimates that a task will require 6 days and delivers it in 4, the next time she is asked for an estimate, her project manager may want to trim the estimate based on past performance

3 Some individuals feel the need to continually tinker with their tasks assignment, so they may use the extra time to further refine or modify the output Positive variation for these team members is treated

as an opportunity to improve their initial efforts

I WORKED AROUND THE

CLOCK AND FINISHED

A PROJECT THAT WOULD

NORMALLY REQUIRE

TEN PROGRAMMERS

UM DID I JUST ESTABLISH A NEW BASELINE EXPECTATION THAT WILL TURN MY JOB INTO A TRAGIC DEATH MARCH?

Source: DILBERT: © Scott Adams/Dist by United Features Syndicate, Inc

Method Three: Negative Consequences of Multitasking

We may use the word multitasking to describe how we commonly become involved in multiple efforts or tasks simultaneously Project personnel for most organizations are routinely expected to be active in several projects, activities, or assignments at the same time and must use time management and prioritization skills

to effectively balance their workloads When project team members are expected to devote their time to, say,

10 projects instead of focusing exclusively on one at a time, time management can be a tremendous challenge The nature of multitasking also lengthens the time necessary to complete individual project assignments, as Figure 11.7 illustrates Let us assume that a project team member has three tasks to perform, each with an expected duration of 10 days The top line shows the activities laid out end to end In this scenario, because the individual's efforts are fully devoted to only one activity at a time, the total time necessary to complete all three assignments is given as 30 days

If the individual is expected to work on all three project assignments simultaneously, devoting five days

to one project before moving on to the next, and so on, note the effect as shown in the second, or bottom, line Expected duration for each project activity has just grown dramatically, from the original 10 days to something

352 Chapter 1 1 • Critical Chain Project Scheduling

20

20

2()

FIGURE 11.7 Effects of Multitasking on Activity Durations

Source: E M Goldratt, © 1997, "The Critical Chain." Reproduced by permission of The North River Press

Publishing Corporation

approaching 20 days for each activity Through the effects of working in a multitasked environment, the

actu-al expected duration needed to complete each project assignment has doubled Of course, the problem is further compounded by the effects of transition time, or the extra time required to move between tasks It is usually a mistake to assume that a multitasked individual can move seamlessly from one assignment to the next In delaying or leaving unfinished project work for an extended time, we must account for some addi-tional wasted start-up time between assignments As a result, multitasking is likely to not just double the real activity duration; it may increase it beyond that level

Method Four: Delay Caused by Activity Path Merging

The majority of projects have multiple activity paths For example, a simple PERT chart, shown in Figure 1 1.8, shows three distinct paths, the critical path and two additional feeder or noncritical paths At the merge point, near the end of the project's activity network, three paths merge into the final, critical path just prior to project completion Activity path merging has the effect of creating a filter to eliminate any positive slack All merging activity paths are held captive to that path with the longest delay Figure 11.8 illustrates this phenomenon Assume that paths A, B, and C have schedule status associated with them of 15 days late, on time, and 15 days early, respectively The problem is that, moving downstream from the merge point, the earliest the subsequent activity can begin is determined by the completion of the latest preceding activity; that is, path A, which is

15 days late As a result, paths C and B, which are either early or on time, lose their positive slack due to the delays associated with the other merging path

The Project Management Institute's Body of Knowledge (PMBoK) identifies this particular problem when it notes, "traditional mathematical analysis techniques such as the Critical Path Method do not account for path convergence and thus tend to underestimate project durations." 1°

The impact of these two sets of behavior processes—behavior designed to increase project activity safety and behavior resulting in loss of safety—illustrates the challenge faced by teams in attempting to more efficiently schedule and manage their projects

15 (iiivs 'Me

15 (iiiys

Merged Path

FIGURE 11 8 The Effect of Merging Multiple Activity Paths

Source: L P Leach (1999), "Critical chain project management improves project performance," Project Management Journal, 30(2), 39-51, figure on page 44 Copyright © 1999 by Project Management Institute Publications

#4

# 1 1 #2

11.4 The Critical Chain Solution to Project Scheduling 353

11.4 THE CRITICAL CHAIN SOLUTION TO PROJECT SCHEDULING

Goldratt's solution to the variables involved in project scheduling involves the aggregation, or collectivizing,

of all project risk in the form of uncertain duration estimates and completion times The aggregation of risk

is a well-known phenomenon in the insurance business." The central limit theorem states that if a number

of probability distributions are summed, the variance of the sum equals the sum of the variances of ual distributions This formula is given, where there are n independent distributions of equal variance v, as:

individ-171, = n • V

where VI is the variance of the sum

The standard deviation 6 can be used as a surrogate for risk, and since 62 = v, we find:

This same principle of aggregation of risks can be applied in a slightly different manner to the critical

chain methodology We have used the term safety orproject buffer to refer to the contingency reserve for vidual activities that project managers like to maintain When we aggregate risk, this reserve is dramatically reduced so that all activity durations are realistic but challenging That is, rather than establish duration esti- mates based on a 90% likelihood of successful completion, all activity durations are estimated at the 50% level The provision for contingency, in the form of project safety, is removed from the individual activities and applied at the project level Because of the aggregation concept, this total buffer is smaller than the sum

indi-of the individual project activity buffers Thus project duration is reduced

Apple Computer Corporation's recent success story with its iPod MP3 music player illustrates some of the advantages to be found in aggregating risks Apple made a conscious decision with the iPod to subcontract most of the components of the product to a variety of suppliers The company determined that to engineer the entire product would have been a complex and risky alternative Instead, it contracted with a number of suppliers who had produced proven technology The decision to combine these product components from other sources, rather than manufacture them in-house, led to a much faster development cycle and greatly increased profitability 12

Two fundamental questions to be answered at this point are: Exactly how much is the_project"s duration reduced? How much aggregated buffer is sufficient? Goldratt and his adherents do not advocate the removal

of all project buffer; merely the reapplication of that buffer to a project level (as shown in Figure 11.9) The determination of the appropriate amount of buffer to be maintained can be derived in one of two ways: (1) a

#1 #2 #3 1 , #4 \Project Butter/

FIGURE 11.9 Reduction in Project Duration After Aggregation

Source: L P Leach (1999), "Critical chain project management improves project

performance," Project Management Journal, 30(2), 39-51, figure on page 44

Copyright © 1999 by Project Management Institute Publications Reproduced with

permission of Project Management Institute Publications via Copyright Clearance

354 Chapter 11 • Critical Chain Project Scheduling

"rule of thumb" approach that Goldratt suggests; namely, retain 50% of total project buffer:, and (2) a more mathematically derived model suggested by Newbold (1998): 13

Buffer = 6 = 00/2) 2 ± ((/1/2 a2)12) 2 + + ((Iv; — ai)/2) 2 1 1/2 where wi is the worst-case duration and ai is the average duration for each task that provides part of the aggregated buffer value The presumed standard deviation would be (w i — (0/2 Suppose, for example, that the project team sought a buffer that is 2 standard deviations long The formula for calculating an appro-priate buffer length is:

Buffer = 2 • = 2 • [((w 1 — a1)12) 2 + ((w2 — a2)/2) 2 + + ((iv; aiv2)211/2 Visually, we can understand the application of CCPM in three distinct phases First, all relevant project tasks are laid in a simplified precedence diagram (shown on line 1 in Figure 1 1.9), with anticipated dura-tions specified Remember that the original duration estimates have most likely been based on high prob-ability of completion estimates and therefore require a reexamination based on a more realistic appraisal

of their "true" duration The second step consists of shrinking these duration estimates to the 50% hood level All individual task safety, or buffer, has been aggregated and now is given as the project-level buffer

likeli-At this stage, the overall length of the project has not changed because the individual task buffer is simply aggregated and added to the end of the project schedule However, line 3 illustrates the final step in the reconfiguration, the point where the project buffer shrinks by some identifiable amount Using the rule of thumb of 50% shrinkage, we end up with a project schedule that is still significantly shorter than the original This modified, shortened schedule includes some minor slack for each activity As a result, CCPM leads to shortened project schedules

Suppose that a project activity network diagram yielded the initial values given in Table 11.1 Note that the modified network shortens the overall project duration by 22 days, from the original 40 to 18 Because all risk is now aggregated at the project level, there are a total of 22 days of potential slack in the schedule resulting from shrinking activity estimates at each project step A CCPM-modified project schedule would reapply

11 days of the acquired schedule shrinkage to serve as overall project buffer Therefore, the new project ule will anticipate a duration estimated to require 29 days to completion

sched-What are the implications of this reapplication of project slack to the aggregated level? First, all due dates for individual activities and subactivities have been eliminated Milestones are not used in the CCPM activity network The only firm commitment remains to the project delivery date, not to the completion of individual tasks Project team members are encouraged to make realistic estimates and continually commu-nicate their expectations Clearly, in order for CCPM to work, a corporate culture that supports a policy of

no blame" is vital Remember, the nature of requiring 50% likelihood estimates for individual activity durations implies that workers are just as likely to miss a commitment date as achieve it Under a culture that routinely p-unishes late performance, workers will quickly reacquire the habits that had once protected them*inflated estimates, wasting safety, and so forth.:

A second implication may be more significant, particularly when dealing with external tors Because individual activity dates have been eliminated and milestones are scrapped, it becomes problematic to effectively schedule subcontractor deliveries When subcontractors agree to furnish mate-rials for the project, they routinely operate according to milestone (calendar) delivery dates CCPM, with its philosophy that deemphasizes target dates for individual tasks, creates a complicated environment for

subcontrac-TABLE 11.1 Critical Chain Activities Time Reductions

Duration Based on 50% Probability

11.4 The Critical Chain Solution to Project Scheduling 355

scheduling necessary supplier or subcontractor deliveries Writers on CCPM suggest that one method for alleviating this concern is to work with contractors to negotiate the early completion and delivery of components needed for critical activities 14

Developing the Critical Chain Activity Network

Recall from earlier chapters that with traditional PERT/CPM networks, individual activity slack is an fact of the overall network Activity start time is usually dictated by resource availability For example, although an activity could start as early as May 15, we may put it off for three days because the individual responsible for its completion is not available until that date In this way, float is used as a resource-leveling device

arti-With CCPM, resource leveling is not required because resources are leveled within the project in the process of identifying the critical chain For scheduling, therefore, CCPM advocates putting off all non- critical activities as late as possible, while providing each noncritical path in the network with its own buffer (see Figure 11.10) These noncritical buffers are referred to as feeder buffers because they are placed

where noncritical -paths Teed into the critical path As Figure 11.10 demonstrates, a portion of the critical

path and one of the noncritical feeder paths join just past the point of activity C Feeding buffer duration

is calculated similarly to the process used to create the overall project buffer, attached to the end of the critical chain

To understand how the logic of the critical chain is constructed, note that the first steps lie in making some important adjustments to traditional scheduling approaches, such as:

1 Adjusting expected activity durations to reflect a 50% probability; of completion on time (shrinking the schedule)

2 Changing from an early-start process to a late-finish approach

3 Factoring in the effects of resource contention if necessary

Figures 11.11a, b, and c present a simplified series of examples that follow these steps Figure 11.11a shows a standard activity network based on a PERT approach A total of five activities are identified (A, B, C,

Noncritical Activity X

Noncritical Activity Y

Feeder Buffer

Critical Activity A

Critical Activity B

Critical Activity C

Critical Activity D

r

NV PrOject 7

\ Buffer

FIGURE 11.10 CCPM Employing Feeder Buffers

Note: Feeder buffers are intended to prevent delays on critical activities

A (10) B (50)

(30)

C (20) D ( 10 ) Slack

90 Days

356 Chapter 11 Critical Chain Project Scheduling

FIGURE 11.11c Critical Chain Schedule with Buffers Added

I), and F) along two separate paths, finally feeding into activity E at the project's conclusion All activities are scheduled to begin as early as possible (early start) and are based on a standard method for estimating dura-tions Table 11.2 lists these expected durations

Figure I 1.1 la demonstrates an expected overall project duration of 90 days, based on the longest set

of linked activities (path j-k E) The second path, C — 1) — E, has an overall duration of 60 days and hence, has 30 days of slack built into it In order to adjust this network, the first step involves changing to a late-finish schedule Second, CCPM challenges the original activity duration estimates and substitutes ones based on the mean point of the distribution The modified activity network makes the assumption of shrinking these estimates by 50% Therefore, the new network has an overall duration of 45 days, rather than the original 90-day estimate (Figure 11.1 lb)

The next step in the conversion to a critical chain schedule involves the inclusion of project and feeder buffers for all network paths Recall that these buffers are calculated based on applying20% of the overall schedule savings The feeder buffer for the path C I) is calculated as 50 x (10 + 5), or 7.5 days The project buffer, found from the values for path A — B E, is calculated as 50 x (5 + 25 + 15), or 22.5 days Hence, once buffers are added to the modified activity network, the original PERT chart showing duration of 90 days with

30 days of slack, the new critical chain network has an overall duration of 67.5 days, or a savings oft 2.5 days (Figure 11.11c) Through three steps, therefore, we move from an early start to late start schedule, identify the critical path (sequence of longest linked activities), and then apply feeder and project buffers The result is a modified project schedule, which, even with buffers inserted, significantly reduces scheduled completion time for the project I5

TABLE 11.2 Activity Durations