Critical Chain Analysis Using Project Management Software

Jaydeep Balakrishnan

Jaydeep Balakrishnan

HaskayneSchool of Business

University of Calgary

Calgary,Alberta T2N1N4

CANADA

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

1

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-schedulingsoftware 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 themcorrectly. Incorrect identification of slacks may result inincorrect 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.


Figure 1: Example Project with Critical Path Highlighted

Figure 2: Project Gantt Chart for Example 1

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 10days 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 part-time 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 chainis shown in figure 3.

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.

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 12days 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 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). Thisgives 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.

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 tasksmay 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 helpmanage 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.Criticalchain 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 working on H on 01/15/2001.The approach presented hereprovides 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 thatactivities 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, projectC will require three hours on equipment A daily. Tables 1 and 2 show the idle time on equipment A when H is completed before I and when I is completed before H respectively. EquipmentA is available eight hours a day and is not generally considered a scarce resource.

Dates
(based on figure 5) / Daily Equipment A Requirements (hours)
H / I / Project B / Project C / Total / Idle
15/01/2001 – 26/01/2001 / 4 / 2 / 6 / 2
27/01/2001 – 31/01/2001 / 5 / 2 / 7 / 1
1/02/2001 – 11/02/2001 / 5 / 3 / 8 / 0

Table 1: Resource Idle Time When H Is Completed Before I

Dates
(based on figure 6) / Daily Equipment A Requirements (hours)
H / I / Project B / Project C / Total / Idle
17/01/2001 – 31/01/2001 / 5 / 2 / 7 / 1
1/02/2001 – 1/02/2001 / 5 / 3 / 8 / 0
2/02/2001 – 13/02/2001 / 4 / 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 secondschedule (figure 6) may be preferable to management as it provides more buffer, especially if the activity times for H and I (or 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 arecarefully monitored, prevent idle time on scarce resources. Resource buffers, on the other hand, prevent delays in activities byensuring the availability of resources withidle capacityand 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 ruleofthumb 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 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 ruleofthumb,because 28days of safety were stripped from the normal project time to get the schedule in figure 7, half that time (14days) should be added back as the project buffer (Goldratt 1997, 156). A14-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 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 14days 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 criticalchain 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 criticalchain principles are useful in project scheduling using MS Project. Explicitly defining a critical chain will ensure that the slacks in a resource-constrained project schedule are calculated correctly. The slacks can then help determine the various buffers used in criticalchain 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.

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. andTaylor, 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