Critical Chain Analysis Using Project Management Software
Jaydeep Balakrishnan
Jaydeep Balakrishnan
Haskayne School of Business
University of Calgary
Calgary, Alberta T2N1N4
CANADA
[email protected]
Appeared in the Production and Inventory Management Journal, 45,1, 2009 pp 13-20.
Critical Chain Analysis Using Project Management Software
Abstract
Previously in this journal, Umble and Umble (2000) discussed Goldratt’s “critical chain”
(Goldratt 1997) for project scheduling. In this article, we show that explicitly defining the
critical chain in a resource constrained project schedule will help avoid errors in slack
calculation. Because these slacks can help identify the feeding buffers in critical chain
analysis and prepare the backward schedules for the activities, it is important to identify
them correctly.
Keywords:
Critical Chain, Project Scheduling, Resources, Activity Slacks, Buffer
2
Critical Chain Analysis Using Project Management Software
Introduction
Previously in this journal, Umble and Umble (2000) discussed the concepts of the “critical
chain” in project scheduling networks. These concepts are based on Goldratt’s (1997) novel
Critical Chain. Goldratt (1990) uses theory of constraints (TOC) concepts in his discussion
of the critical chain and discusses many types of buffers for project schedules. While the
role of bottlenecks in process management has been recognized for a long time (Bock
1962), Goldratt has been successful in translating these bottleneck issues into principles
that can be understood by any audience through his work on TOC. Similarly while many
of the principles discussed in Critical Chain are not new (Piper 2000; Wiest 1967; Wiest
and Levy 1977), the novel has provided renewed focus on project scheduling. Reviews of
the novel and the principles within can be found in Cather (1997), Elton and Roe (1998),
Raz (2003), and Trietsch (2005), while Newbold (1998) further explains the use of critical
chain principles. Information on project management software that uses critical chain
principles can be found by typing “critical chain project management software” into any
Internet search engine.
In this article we use the example from Umble and Umble (2000) to explain how explicitly
defining the critical chain can help correctly identify the slacks in a resource constrained
project schedule. This is shown using the widely available project-scheduling software
1
Microsoft (MS) Project 2003, which many users of critical chain principles most likely use
to schedule projects.
Because the feeding buffer concept in the critical chain depends on slacks, it is important
to identify them correctly. Incorrect identification of slacks may result in incorrect feeding
buffers.
Critical chain analysis
Consider the example from Umble and Umble shown in figure 1, using an activity-on-node
convention with times in days. There are three paths—ADGJM, BEHKM, and CFILM—
with lengths of 36, 44, and 46 days respectively. The longest path, i.e., the critical path
(different from the critical chain), CFILM, in the project is shown in bold. Figure 2 shows
the Gantt chart for this project in the dd/mm/yy format. The critical path is indicated by the
dark shaded bars. Initially, resources are assumed to be unlimited. The chart shows the task
name, the (early) start and finish times, late start and finish times, and the free and total
slacks.
6
4
8
A
D
10
G
J
8
8
6
B
E
F
10
H
10
6
C
12
16
A
I
K
M
6
L
2
Figure 1: Example Project with Critical Path Highlighted
Figure 2: Project Gantt Chart for Example 1
3
As the Total Slack column (the amount of delay that is allowed in the task before the project
is delayed) in the Gantt chart shows, tasks on path ADGJM have 10 days of slack (because
the path time is only 36 days versus 46 for the critical path), whereas tasks on path BEHKM
have only 2 days of slack (because the path time is 44 days). The Free Slack column shows
the amount of delay allowed before the succeeding task is delayed. Thus any delay in A
would delay D and the free slack is 0. But assuming that tasks A, D, and G are completed
by the early finish time (day 28), there is a slack of 10 days for J because M need not start
till task L, on another path, is completed (as late as day 38). Thus, the free slack for feeding
activities is an indication of the available feeding buffer used in the critical chain principles.
The available feeding buffer is 2 days between K and M and 10 days between J and M.
However, normally the feeding buffers would be calculated after stripping away the
implicit safety times that task estimators often add to individual activities (Goldratt 1997,
154). This aspect is discussed later.
Now assume that employee 1 is responsible for performing tasks H and I. In figure 2, H
and I overlap. This overlap cannot be allowed if resources are taken into consideration, as
employee 1 cannot do two tasks simultaneously. If the employee is assigned to more than
one task during the same time period, the task lengths can be increased to reflect these parttime assignments. Because Goldratt (1997) discourages assigning the same person to more
than one task during the same time period, for the purpose of our discussion we assume the
same. Employee 1 is assigned to do H first and then I because this order will give a shorter
resource-constrained project completion time than doing I first and then H. The new logical
network that Goldratt calls the critical chain is shown in figure 3.
4
6
4
8
A
I
D
10
G
J
8
8
6
B
E
F
10
M
H
10
6
C
12
16
I
6
L
Figure 3: The Critical Chain
The critical chain consists of the tasks connected by bold arrows (including the dotted
one between H and I). Tasks C and F now are no longer critical; delays in their
completion (up to 10 days) will not affect I because I now depends on H. With a length of
26 days, BEH is 10 days longer than CF. So BEH is critical—any delays in these tasks
will delay the project. ILM remains part of the critical path as before. Thus the critical
chain identifies the critical tasks when resource constraints exist. Figure 4 shows the
critical chain Gantt chart, where employee 1 is assigned to do both H and I, in that
sequence. H and I are accomplished by using resource levelling and assigning a higher
priority to H so that it is performed first.
5
Figure 4: Project Gantt Chart with Resource Levelling
As seen in the figure, H and I are being done sequentially by employee 1. The project is
delayed by 10 days and now will take 56 days (based on BEHILK). This is correct.
However, figure 4 also shows the importance of using critical chain principles. Though it
is clear from figure 3 that B, E, and H are critical, in figure 4 they are incorrectly shown
as having 12 days of total slack.
The incorrect slacks appear to result from the fact that they are calculated based only on
the original unconstrained paths. Resource links are ignored. As seen in figure 4, CFIL
has the latest early finish time among the three portions ADGJ, BEHK, and CFIL. Thus C
and F are considered critical and are shaded, while B, E, and H are not, though BEHILK
is actually the resource-constrained critical path. Slacks are calculated based on the
6
CFILM completion time of 56 days. As I was delayed by 10 days, L and M start 10 days
later. The example correctly calculates that M can start only 48 days into the project (as
opposed to 38 days in the unconstrained schedule). However, the calculation does not
take into account the fact that the 10-day delay results from the new relationship of path
CFIL to H due to the sharing of resources.
The BEHK portion of path BEHKM can be completed by day 36. Because M cannot start
until day 48, tasks B, E, and H are shown to have a slack of 12 days, although in fact they
are critical. Similarly on path CFILM, C and F are shown to have a slack of 0, though in
fact they can be completed as early as day 16, whereas I cannot start till H is completed
on day 26 (i.e. a slack of 10 days). Similar errors will occur even if I is done before H.
The slacks on ADGJ are correct because this path does not share a resource with any of
the other paths.
Fortunately, the notion of a critical chain can be used to establish the correct start date.
In figure 5, task I is explicitly made dependent on H by connecting the Gantt bars for H
and I with a precedence relationship (shown by an arrow). This gives the critical chain
with the correct critical tasks shaded and the correct slack values. In effect, a pseudo-path
BEHILK has been created, ensuring that no new implicit paths are created when actual
resource levelling is done, which in turn means that the critical path will not change from
the unconstrained to the constrained situation. Thus, the correct slacks will be calculated
regardless of the situation.
7
Figure 5: Project Gantt Chart with Explicit Resource Dependent Connections
In general, to identify the critical tasks and slacks correctly, the tasks that share the same
resource have to be explicitly connected. If the unconstrained critical path does not share
a resource with the other paths, then the correct critical path and slack are always
identified. For instance, if ADGJM were the critical path, there would be no need to
connect H and I explicitly because ADGJM does not share any resource with the other
paths.
Resource and constraint buffers
In the example, only one resource affected only two activities, H and I. We could easily
examine two schedules, one with I being performed after H and the other with the
sequence reversed, to determine the sequence that gave the shortest schedule. However,
when many tasks share resources, examining every possible priority sequence for the
8
tasks may not be possible. There will be too many combinations. In such situations, good
sequences can be identified by using rules similar to those discussed in Patterson (1976).
The rules include giving priority to the tasks with the least slack, the highest resource
requirements, and so on. In addition to helping determine shorter schedules, using these
rules may help manage the different buffers discussed in Umble and Umble (2000).
The constraint buffer ensures that predecessor activities are completed on time or early so
that the constrained (scarce) resource can work on the scheduled activity without its
valuable capacity being wasted. Because different priority rules may result in different
completion dates for the activities, one can choose the schedule that gives the best buffer
for the constrained resource. As an illustration of the constraint buffer, assume that in the
example project, activities I and H require the services of an expert, employee 2. Because
the company also is undertaking other projects that require the services of employee 2,
this person is a scarce resource. For the example project, employee 2 is available from
01/15/2001, and management will reassign the person to another project as soon as
activities H and I are completed. Employee 2’s availability would fit well with the
schedule shown in figure 5 for activities H and I. However, if I is completed before H
(different priority rule), as in figure 6, activity H can start only on 01/17/2001 because of
precedent activities. Therefore, employee 2 may be idle on 01/15/2001 and 01/16/2001.
Critical chain principles consider this a waste of a scarce resource, as employee 2’s lost
time may result in delayed projects. Thus, the schedule in figure 5 would be preferred to
that in figure 6. Management should also make every effort to ensure that E is completed
on schedule, by 01/14/2001 or even a little early (buffer), so that employee 2 can start
9
working on H on 01/15/2001. The approach presented here provides management with
focus as to which activities need to be monitored carefully.
Figure 6: Gantt Chart with I Scheduled Before H
The resource buffer represents protective capacity in a non-scarce resource. Different
priority rules may result in different buffers (levels of protective capacity). So by using
different priority rules the decision maker can choose the one that gives the best schedule
protected by the required resource buffer. As an illustration, assume that activities H and
I need equipment A which is also needed on project B and project C. Activity H requires
four hours a day on equipment A and activity I requires five hours a day on Equipment A.
Between 01/15/2001 and 01/31/2001, project B will require two hours on equipment A
daily and between 02/01/2001 and 02/15/2001, project C will require three hours on
equipment A daily. Tables 1 and 2 show the idle time on equipment A when H is
10
completed before I and when I is completed before H respectively. Equipment A is
available eight hours a day and is not generally considered a scarce resource.
Dates
Daily Equipment A Requirements (hours)
(based on figure 5)
H
15/01/2001 – 26/01/2001
4
I
27/01/2001 – 31/01/2001
5
1/02/2001 – 11/02/2001
5
Project B
Project C
Total
Idle
2
6
2
2
7
1
8
0
3
Table 1: Resource Idle Time When H Is Completed Before I
Dates
Daily Equipment A Requirements (hours)
(based on figure 6)
H
I
Project B
17/01/2001 – 31/01/2001
5
2
1/02/2001 – 1/02/2001
5
2/02/2001 – 13/02/2001
4
Project C
Total
Idle
7
1
3
8
0
3
7
1
Table 2: Resource Idle Time When I Is Completed Before H
When H is completed before I, there are eleven days (1/02/2001 – 11/02/2001) when the
equipment is being used 100%, whereas when I is completed before H, the equipment is
used 100% only on 02/01/2001. Thus, the second schedule (figure 6) may be preferable
to management as it provides more buffer, especially if the activity times for H and I (or
11
project B and project C) have uncertainty involved in the duration. On days when the
resource is being used 100%, the uncertainty may cause not only this project but also
project B or project C to be delayed because more time on the resource is needed than
was originally planned. For that reason, a buffer may be valuable and completing I before
H may be preferable.
Constraint buffers, in which activities are carefully monitored, prevent idle time on scarce
resources. Resource buffers, on the other hand, prevent delays in activities by ensuring
the availability of resources with idle capacity and providing warning to the resource
manager to plan for the upcoming use of the resource (Newbold 1998, 267).
Backward scheduling using feeding buffers
Figure 7 shows the project schedule stripped of the safety times (half the normal
duration) as suggested by Goldratt (1997). The free slacks for activities J, K, and F
denote the available feeding buffer for critical chain activities I and M. These buffers can
then be used to backward-schedule activities not on the critical chain. For example, if we
assume that the feeding buffer for I is equal to the free slack, i.e., five days, then the
(Early) Start and Finish columns in figure 7 give the backward schedule. Activity C will
start on 01/01/2001 and activity F will start on 01/04/2001. Goldratt’s rule of thumb
states that half the number of days stripped can be added back as the feeding buffer
(Goldratt 1997, 158). Since a total of eight days were stripped from CF, four days of
feeding buffer between F and I would be needed. In this case the start date for C can be
12
manually set as 01/02/2001, i.e., one day later. This will result in the free slack (feeding
buffer) being reduced to four days and the appropriate backward schedule for activities C
and F (one day later than the dates shown in the Start and Finish columns in figure 7). For
further insight on buffer determination, the reader is referred to Hoel and Taylor (1999,
4337).
Figure 7: Gantt Chart with Stripped Times
The project buffer
The project buffer, used to protect the whole project, can be added by creating a dummy
activity, the same duration as the project buffer, at the end of the project. Based on
Goldratt’s rule of thumb, because 28 days of safety were stripped from the normal project
time to get the schedule in figure 7, half that time (14 days) should be added back as the
project buffer (Goldratt 1997, 156). A 14-day dummy activity can be added at the end of
the project. The finish date of the last actual activity, M, will give the project completion
13
date without the buffer, and the finish date of the dummy activity will give the project
completion date including the buffer (promise date).
While one can achieve the same project completion date by manually setting the
completion date of M to be 14 days later, doing so will have the domino effect of
changing the dates and slacks of all the activities, compromising the integrity of the
activity completion dates, and defeating the purpose of critical chain project scheduling.
Adding a dummy activity will ensure that the times and slacks for the activities are not
changed. If during the project the actual completion date has to be delayed, the duration
of the dummy activity (the project buffer) can be reduced correspondingly and the project
promise date will not be affected.
Conclusion
This article has shown why critical chain principles are useful in project scheduling using
MS Project. Explicitly defining a critical chain will ensure that the slacks in a resourceconstrained project schedule are calculated correctly. The slacks can then help determine
the various buffers used in critical chain analysis for effective project scheduling. We
have also shown that different task priority rules can be used to schedule buffers that will
prevent delays in activities and eliminate wasted idle time on scarce resources.
Acknowledgement
The author would like to acknowledge the financial support provided by the Natural
Sciences and Engineering Research Council of Canada.
14
References
Bock, R.H. 1962. “A New Method for Teaching Linear Programming,”
Academy of Management Journal, 5: 82-86.
Cather H, 1997. “Is the ‘Critical Chain’ the Missing Link?” Project Management
Today, November-December 1997, pp 22-25.
Elton J. and Roe J., 1998. “Bringing Discipline to Project Management,” Harvard
Business Review, 76, (2):153-157.
Hoel K. and Taylor, S.G. 1999. “Quantifying Buffers for Project Schedules,”
Production and Inventory Management Journal, Second Quarter 40, (2): 43- 47.
Goldratt E.M., 1990. Theory of Constraints. Great Barrington, MA: North River Press
Goldratt E.M., 1997. Critical Chain. Great Barrington, MA: North River Press
Newbold, R.C., 1998. Project Management in the Fast Lane: Applying the Theory of
Constraints, Boca Raton, FL: St Lucie Press
Patterson J.H., 1976 “Project scheduling: the effects of problem structure on heuristic
performance,” Naval Research Logistics Quarterly, 23, (1): 95-123.
Piper, C.J., 2000 CPSIM: The Critical Path Simulator, London, Ontario: Ivey
Management Services, Case No. 9B00D019.
Raz, T., R. Barnes, and Dvir, D., 2003. “A Critical Look At Critical Chain Project
Management,” Project Management Journal, 34, (4): 24-32.
15
Umble M. and Umble E., 2000. “Manage your Projects for Success: An Application
of the Theory of Constraints,” Production and Inventory Management Journal,
Second Quarter, 41, (2): 27-32.
Trietsch, D., 2005 “Why a Critical Path by Any Other Name Would Smell Less
Sweet: Towards a Holistic Approach to PERT/CPM,” Project Management Journal,
36. (1): 27-37
Wiest, J.D., 1967 “A Heuristic Model for Scheduling Large Projects with Limited
Resources,” Management Science, 13, (6): B359-B377.
Wiest, J.D., and Levy, E.K., 1977. A Management Guide to PERT/CPM, Englewood
Cliffs, NJ: Prentice-Hall
16