Appendix 7.2
The critical-chain approach
In practice, project managers carefully manage 'slack' on sensitive resource-limited projects. If
possible, they will add slack at the end of the project by committing to a completion date that goes
beyond the scheduled date. For example, the plans say the project should be completed on 1 April,
although the official completion date is 1 May. Other managers take a more aggressive approach to
managing slack within the schedule. They use an early start schedule and prohibit use of slack on
any activity or work package to be used, unless authorised by the project manager. Progress, by
percentage completed and by remaining time, is carefully monitored. Activities that are ahead of
estimated completion times are reported, so that succeeding activities can start ahead of schedule.
This ensures that the time gained is used to start a succeeding activity earlier so that the time is not
wasted. The overall intent is to create and save slack as a time buffer to complete the project early or
to cover delay problems that may creep in on critical activities or paths.
Eliyahu Goldratt, who championed the 'theory of constraints' in his popular book The Goal,
advocates an alternative approach to managing slack. He has coined the term ‘critical-chain’ to
recognise that the project network may be constrained by both resource and technical
dependencies. Each type of constraint can create task dependencies, and in the case of resource
constraints, new task dependencies can be created! Remember how resource constraints shifted the
critical path? If not, revisit Figure 7.27 in the text. The critical chain refers to the longest string of
dependencies that exist on the project. Chain is used instead of path, since the latter tends to be
associated with just technical dependencies, not resource dependencies. Goldratt uses the critical
chain concept to develop strategies for accelerating the completion of projects. These strategies are
based on his observations about the time estimates of individual activities.
TIME ESTIMATES
Goldratt argues that there is a natural tendency for people to add safety (just-in-case) time to their
estimations. It is believed that those who estimate activity times provide an estimate that has an 80
to 90 per cent chance of being completed on or before the estimated time. Hence, the median time (a
50/50 chance) is overestimated by approximately 30 to 40 per cent. For example, a programmer
may estimate that there is a 50/50 chance that he can complete an activity in six days. However, to
ensure success and to protect against potential problems, he adds three days of safety time and
reports that it will take nine days to complete the task. In this case the median (50/50) time is
overestimated by approximately 50 per cent. He now has a 50/50 chance of completing the project
three days ahead of the schedule. If this hidden contingency is pervasive across a project, then most
activities, in theory, should be completed ahead of schedule.
Not only do workers tend to add this kind of safety net, but project managers like to add a safety
buffer to ensure that they will be able to bring the project in ahead of schedule. They might typically
add a month to a nine-month project to cover any delays or risks that might occur. This situation
raises an interesting paradox:
Why, if there is a tendency to overestimate activity durations and add in a safety net to the end
of a project, do so many projects come in behind schedule?
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 1
Critical-Chain Project Management (CCPM) offers several explanations:
1.
Parkinson’s law
Work fills the time available. Why hustle to complete a task today when it isn’t due until tomorrow?
Not only will the pace of work be dictated by the deadline, but workers will take advantage of
perceived free time to catch up on other things. This is especially true in matrix environments where
workers can use this time to clear work backlogs on other projects and duties.
2.
Self-protection
Participants fail to report early finishes out of fear that management will adjust their future
standards and demand more from them next time. For example, if a team member estimates that a
task will take seven days and delivers it in five, the next time he or she is asked for an estimate, the
project manager may trim the time estimate based on past performance. Peer pressure may also be a
factor here; to avoid being labelled a ‘rate-buster,’ members may not report early finishes.
3.
Dropped baton
Goldratt uses the metaphor of project as relay race to illustrate the impact of poor coordination. Just
as a runner’s time is lost if the next runner is not ready to receive the baton, so is the time gained
from completing a task early lost if the next group of people are not ready to receive the project
work. Poor communication and inflexible resource schedules prevent progress from occurring.
4.
Excessive multitasking
The norm in most organisations is to have project personnel work on several projects, activities, or
assignments at the same time. This leads to costly interruptions and excessive task splitting, which
in turn adds time to each activity. When looked at in isolation the time loss may seem minimal, but
when taken as a whole the transition costs can be staggering.
5.
Resource bottlenecks
In multi-project organisations projects are frequently delayed because test equipment or other
necessary resources are tied up on other project work.
6.
Student syndrome (procrastination)
Goldratt asserts that just as students delay writing a term paper until the last minute, workers delay
starting tasks when they perceive that they have more than enough time to complete the task. The
problem with delaying the start of a task is that obstacles are often not detected until the task is
under way. By postponing the start of the task, the opportunity to cope with these obstacles and
complete the task on time is compromised.
CRITICAL-CHAIN IN ACTION
CCPM’s solution to reducing project time overruns is to insist on people using the ‘true 50/50’
activity time estimates (rather than estimates that have an 80 to 90 per cent chance of being
completed before the estimated time). The 50/50 estimates result in a project duration of about half
the low risk of 80 to 90 per cent estimates. This requires a corporate culture that values accurate
estimates and refrains from blaming people for not meeting deadlines. According to CCPM, using
50/50 estimates will discourage Parkinson’s law, the student syndrome, and self-protection from
coming into play because there is less ‘free time’ available. Productivity will be increased as
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 2
individuals try to meet tighter deadlines. Similarly, the compressed time schedule reduces the
likelihood of the dropped baton effect.
CCPM recommends inserting time buffers into the schedule to act as ‘shock absorbers’ to
protect the project completion date against task durations taking longer than the 50/50 estimate.
The rationale is that by using 50/50 estimates you are in essence taking out all of the ‘safety’ in
individual tasks. CCPM also recommends using portions of this collective safety strategically by
inserting time buffers where potential problems are likely to occur. There are three kinds of buffers
in CCPM.
1.
Project buffer
First, since all activities along the critical chain have inherent uncertainty that is difficult to predict,
project duration is uncertain. Therefore, a project time buffer is added to the expected project
duration. CCPM recommends using roughly 50 per cent of the aggregate safety. For example, if the
modified schedule reduces the project duration by 20 days from 50 to 30, then a 10-day project
buffer would be used.
2.
Feeder buffers
Buffers are added to the network where noncritical paths merge with the critical chain. These
buffers protect the critical chain from being delayed.
3.
Resource buffers
Time buffers are inserted where scarce resources are needed for an activity. Resource time buffers
come in at least two forms. One form is a time buffer attached to a critical resource to ensure that the
resource is on call and available when needed. This preserves the relay race. The second form of
time buffer is added to activities preceding the work of a scarce resource. This kind of buffer protects
against resource bottlenecks by increasing the likelihood that the preceding activity will be
completed when the resource is available.
All buffers reduce the risk of the project duration being late and increase the chance of early
project completion.
CRITICAL-CHAIN VERSUS TRADITIONAL SCHEDULING APPROACH
To illustrate how CCPM affects scheduling, let’s compare it with the traditional approach to project
scheduling. We will first resolve resource problems as described in Chapter 8 and then the CCPM
method. Figure A7.10A shows the planned Air Control project network without any concern for
resources. That is, activities are assumed to be independent and resources will be made available
and/or are interchangeable.
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 3
FIGURE A7.10A
Air Control Project: time plan without resources
Figure A7.10B depicts the bar chart for the project. The dark pink bars represent the durations of
critical activities; the light pink bars represent the durations of noncritical activities; the grey bars
represent slack. Note that the duration is 45 days and the critical path is represented by activities 1,
4, 6, 7, and 8.
FIGURE A7.10B
Air Control Project: time plan without resources
Parallel activities hold potential for resource conflicts. This is the case in this project. Ryan is the
resource for activities 3 and 6. If you insert Ryan in the bar chart in Figure A7.10B for activities 3 and
6, you can see activity 3 overlaps activity 6 by five days—an impossible situation. Because Ryan
cannot do two activities simultaneously and no other person can take his place, a resource
dependency exists. The result is that two activities (3 and 6) that were assumed to be independent
now become dependent. Something has to give! Figure A7.11A shows the Air Control project
network with the resources included. A pseudo-dashed arrow has been added to the network to
indicate the resource dependency.
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 4
FIGURE A7.11A Air Control Project: schedule with resources limited
The bar chart in Figure A7.11B reflects the revised schedule resolving the over-allocation of Ryan.
Given the new schedule, slack for some activities has changed. More importantly, the critical path
has changed. It is now 1, 3, 6, 7, 8. The resource schedule shows the new project duration to be 50
days rather than 45 days.
FIGURE A7.11B Air Control Project: schedule with resources limited
Now let’s apply the CCPM approach to the Air Control project. Figure A7.12 details many of the
changes. First, notice that task estimates now represent approximations of the 50/50 rule. Second,
observe that not all of the activities on the critical chain are technically linked. Manufacture custom
parts is included because of previously defined resource dependency. Third, a project time buffer is
added at the end of schedule. Finally, feeder buffers are inserted at each point where a noncritical
activity merges with the critical chain.
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 5
FIGURE A7.12 Air Control Project: CCPM Network
The impact the CCPM approach has on the project schedule can best be seen in the Gantt chart
presented in Figure A7.13. Notice first the late start times for each of the three noncritical activities.
For example, under the critical path method, order vendor parts and software development would
be scheduled to begin immediately after the order review. Instead they are scheduled later in the
project. Three-day feeder buffers have been added to each of these activities to absorb any delays
that might occur in these activities. Finally, instead of taking 50 days the project is now estimated to
take only 27 days with a 10-day project buffer!
FIGURE A7.13 Air Control Project Gantt chart: CCPM Network
This example provides an opportunity for explaining the differences between buffers and slack.
Slack is spare time inherent in the schedule of noncritical activities and can be determined by
differences between the early start and late start of a specific activity. Buffers, on the other hand, are
dedicated time blocks reserved to cover the most likely contingencies and are monitored closely so,
if they are not needed, subsequent activities can proceed on schedule. Buffers are needed in part
because the estimates are based on 50/50 approximations and therefore roughly half of the
activities will take longer than planned. To protect against these extended activity durations, buffers
are inserted to minimise the impact on the schedule. Buffers are not part of the project schedule and
are used only when sound management dictates it.
While not depicted in these figures, an example of a resource buffer would be to add six days to
Ryan’s schedule (remember he is the critical resource that caused the schedule to be extended). This
would ensure that he could continue to work on the project beyond the 18th day in case either
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 6
produce standard parts and/or manufacture custom parts takes longer than planned. Progress on
these two tasks would be monitored closely, and his schedule would be adjusted accordingly.
CCPM AND SPLITTING TASKS
Buffers do not address the insidious effects of pervasive task splitting, especially in a multi-project
environment where workers are juggling different project assignments. CCPM has three
recommendations that will help to reduce the impact of splitting activities:
1. Reduce the number of projects so people are not assigned to as many projects concurrently.
2. Control start dates of projects to accommodate resource shortages. Don’t start projects until
sufficient resources are available to work full time on the project.
3. Contract (lock in) for resources before the project begins.
MONITORING PROJECT PERFORMANCE
The CCPM method uses buffers to monitor project time performance. Remember that as shown in
Figure A7.12 a project buffer is used to insulate the project against delays along the critical chain.
For monitoring purposes, this buffer is typically divided into three zones—OK, Watch and Plan, and
Act, respectively (see Figure A7.14). As the buffer begins to decrease and moves into the second
zone, alarms are set off to seek corrective action. To be truly effective, buffer management requires
comparing buffer usage with actual progress on the project. For example, if the project is 75 per cent
complete and you have only used 50 per cent of the project buffer, then the project is in pretty good
shape. Conversely, if the project is only 25 per cent complete and 50 per cent of the buffer has
already been used, you are in trouble and corrective action is needed. A method for estimating
percentage complete is described in Chapter 13.
FIGURE A7.14 Project Control—Buffer Management
THE CCPM METHOD TODAY
CCPM has generated considerable debate within the project management community. While sound
in theory, support at this time is limited but growing. For example, Harris Semiconductor was able to
build a new automated wafer fabrication facility within 13 months using CCPM methods when the
industry standard for such a facility is 26–36 months. The Israeli aircraft industry has used CCPM
techniques to reduce average maintenance work on aircraft from two months to two weeks. The US
Air Force and Navy as well as Boeing, Lucent Technologies, Intel, GM, and 3M are applying criticalchain principles to their multi-project environments.
CCPM is not without critics. First, CCPM does not address the biggest cause of project delays,
which is an ill-defined and unstable project scope. Second, some critics challenge Goldratt’s
assumptions about human behaviour. They question the tendency of experts to pad estimates and
that employees act deliberately against the organisation for their own interest and benefit. They also
object to the insinuation that trained professionals would exhibit the student syndrome habits.
Third, evidence of success is almost exclusively anecdotal and based on single case studies. The lack
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 7
of systematic evidence raises questions about the generalisability of application. CCPM may prove to
work best for only certain kinds of projects.
One of the keys to implementing CCPM is the culture of the organisation. If the organisation also
honours noble efforts that fail to meet estimates as it does efforts that do meet estimates, then
greater acceptance will occur. Conversely, if management treats honest failure differently from
success, then resistance will be high. Organisations adopting the CCPM approach have to invest
significant energy to obtaining ‘buy-in’ on the part of all participants to its core principles and
allaying the fears that this system may generate.
APPENDIX SUMMARY
Regardless of where one stands in the debate, the CCPM approach deserves credit for bringing
resource dependency to the forefront, highlighting the modern ills of multitasking and forcing us to
rethink conventional methods of project scheduling.
Appendix 7.2 Review Questions
1. Explain how time is wasted in management of projects.
2. Distinguish between project and feeder buffers.
3. Buffers are not the same as slack. Explain.
Appendix 7.2 Exercises
1. Check out the Goldratt Institute’s homepage at www.goldratt.com for current information
on the application of critical-chain techniques to project management.
2. Apply critical-chain scheduling principles to the Print Software Pty Ltd, project presented
in the text chapter on page 197. Revise the estimated time durations by 50 per cent
(round up the odd time durations, i.e. 3 becomes 4). Draw a CCPM network diagram
similar to the one contained in Figure A7.12 for the Print Software project as well as a
Gantt chart similar to Figure A7.13. How would these diagrams differ from the ones
generated using the traditional scheduling technique?
CASE: THE CCPM DILEMMA
Pinyarat worked in the IT department of a diversified IT firm. She described the firm’s early
encounters with critical chain scheduling to a friend in another IT firm.
Three years ago management decided to add 10 per cent time to all activity estimates because
almost all projects were coming in late. One thought was people were simply working too hard and
needed some relief. This approach did not work! Projects still came in late. Next, management
decided to take away the extra time for activities and add 10 per cent for project estimates to ensure
project durations would be met. Again, nothing improved and projects continued to come in late.
Recently, the firm hired a consultant who promoted critical chain scheduling, which was
implemented for all projects in her division. Almost all failed to perform.
Pinyarat explained, ‘The estimates were basically impossible. The activity durations were
squeezed down to less than the 50 per cent guideline. We were late on nearly every task. In addition,
I was not allowed to put in a big enough project buffer, which only added to projects being late. One
colleague who was working on six projects gave up and quit; he said he was killing himself and saw
no hope of things getting better. My projects are not the only ones having big problems. Some people
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 8
had no idea why anyone would use CCPM scheduling. To quote one of my best programmers: "They
ask for an estimate and then they cut it by 50 per cent or more. What kind of game is this?
Apparently they don’t trust us."’
A week later, to Pinyarat’s surprise, she was called to the IT manager’s office. Pinyarat imagined
numerous bad scenarios of how the meeting could go—even to the remote possibility of being fired!
The manager wanted the division to straighten out their project management practices and stop this
business of nearly all IT projects being late. There are rumors of cleaning house or outsourcing IT
work.
The manager believed Pinyarat, who passed the PMP exam, had the best chance of turning
things around. He said, ‘Pinyarat, I’m desperate; top management is reaching the end of the rope
with our division. We need to turn this around for both our sakes. Give me a plan that I can sponsor
within the week.’
Pinyarat explained to her friend a few of her ideas—like squeezing estimates too far. But she
said she would take any ideas she can get from anyone.
Give Pinyarat a report that identifies the key problems and a plan of action she can present to
her sponsor. Limit your report to 800 words or less.
APPENDIX 7.2 REFERENCES
Goldratt, Critical Chain (Great Barrington, MA: North River Press, 1997).
Herroelen, W., R. Leus, and E. Demeulemeester, ‘Critical Chain Project Scheduling: Do Not
Oversimplify’, Project Management Journal, Vol. 33 (4), 2002, pp. 48–60.
Leach, L. P., ‘Critical Chain Project Management’, Proceedings of 29th Annual Project Management
Institute, 1998, Seminars and Symposium (Newtown, PA: Project Management Institute, 1998), pp.
1239–44.
Levine, H. A., ‘Shared Contingency: Exploring the Critical Chain’, PM Network, October 1999, pp. 35–
38.
Newbold, R. C., Project Management in the Fast Lane: Applying the Theory of Constraints (Boca Raton,
FL: St. Lucie Press, 1998).
Noreen, E., D. Smith, and J. Mackey, The Theory of Constraints and Its Implication for Management
Accounting (Great Barrington, MA: North River Press, 1995).
Raz, T., R. Barnes, and D. Dvir, ‘A Critical Look at Critical Chain Project Management’, Project
Management Journal, December 2003, pp. 24–32.
Sood, S., ‘Taming Uncertainty: Critical-Chain Buffer Management Helps Minimize Risk in the Project
Equation’, PM Network, March 2003, pp. 57–59.
Zalmanson, E., ‘Readers Feedback’, PM Network, Vol. 15 (1), 2001, p. 4.
Appendix t/a Project Management in Practice by N Pearson, EW Larson, CF Gray
Copyright ©2013 McGraw-Hill Education (Australia) Pty Ltd Page 9