THE CONCEPT OF “CRITICAL CHAIN,” introduced by E. Goldratt [Critical Chain, The North River Press, 1997], deals with project management principles, of which few can be considered as relatively new. This article discusses some of the major critical chain issues, with the objective of identifying those that can be integrated into A Guide to the Project Management Body of Knowledge (PMBOK® Guide) [pmi Standards Committee, 1996].
Before continuing discussion on the critical chain, I'd like to share with you my major motivators in writing this article:
■ Critical chain is presented by its followers as a new approach. Therefore, professionally, it generates an unacceptable situation where a project manager has to decide either to adopt the critical chain or the PMBOK® Guide.
■ There should be just one body of project management knowledge. Therefore, our continuous mission is to evaluate any idea, new or old, and merge relevant knowledge into the PMBOK® Guide.
■ No sufficient efforts were made by the creator of the critical chain and his followers, or by PMI members who preach and practice the PMBOK® Guide concepts (including myself), to discuss the fit of different critical chain notions to the project management body of knowledge.
■ Some of my practitioner friends—such as Gai Bril, a CEO in Elbit, which is a successful high-tech company—introduced, to their satisfaction, the critical chain concepts.
Exhibit 1. The example project consists of four activities, with a simple precedence relationship.
Exhibit 2. The assumption in this stage is that resources are unlimited.
■ Some of my academic colleagues—such as Professor Aaron Shenhar, also a member of the Project Management Institute—share with me the feeling that few of the critical chain concepts are valid and, therefore, should be integrated into the PMBOK Guide.
The three major issues that I will discuss are the critical chain concept, the issue of time estimation, and slack management. In discussing these issues, I will not dwell on whether or not the concept is new, but rather if it warrants inclusion in the PMBOK® Guide.
Critical Chain. As defined by Goldratt, the “critical chain” is the longest path that dictates project completion. Since it is rare for a project manager to function in an unconstrained resource environment, the critical path is determined not only by dependencies among activities, but also by limitation of resource capacities that force activities to be performed in sequence rather than simultaneously. Let's consider a project consisting of the activities presented in Exhibit 1.
As can be seen from Exhibit 1, the project consists of four activities, with a simple precedence relationship. For example, Activity B, which follows Activity A, requires 36 hours of design engineering and is expected to be completed within three working days. Assuming linear resource consumption, 12 engineering hours are required per working day (36/3=12).
Exhibit 2 presents the project's Gantt chart, using the early start strategy and disregarding resource requirements. The critical path consists of Activities A, C, and D; Activity B has a slack of two days, which is represented by the dashed line. The resource profile is represented by Exhibit 3.
Thus, for example, Activities B and C are worked on during the third day. Since Activity B requires 12 labor-hours per day and Activity C requires eight labor-hours per day, the total labor requirements during the third day are 20 hours—and so on. To keep to the schedule presented in Exhibit 2, the number of available labor-hours per day should exceed the number of required hours. If only 12 labor-hours are available per day, Activities B and C cannot be performed simultaneously, but only sequentially, as shown in Exhibit 4.
This means that, due to resource constraints, the project completion time has been extended to 11 days and all activities have become critical. That is, the new critical path, which may be referred to as the “critical chain,” now includes additional activities. Activity B has become critical not out of a precedence relationship, but due to resource constraints. Whatever the reasons for this situation, any further delay in performing any activity along the critical chain will cause an additional delay in the completion of the project beyond the 11 days. The critical chain focuses attention on both critical activities that need to be performed within specific time frames and critical resources that need to be available at certain times in order to avoid further delay. In the case serving as my illustration, the resource is particularly critical during the period when it is required in its entirety—that is, during the time period it is scheduled to work on activities B and D.
The conventional practice preached in the PMBOK® Guide is to schedule the project according to the available resources. Since, in most of the cases, resources are limited, a project manager will reschedule the activities in order to avoid resource violation. It means that the new path will be longer than the critical path and will be dictated by the constrained resources—in other words, critical resources are being considered as well as when using the conventional approach. Therefore, the main contribution of the critical chain notion is the addition of a new and relevant concept that states that the critical path does not remain the same under constrained resources, and that it consists of both critical activities and critical resources. Although project managers are aware of it, it makes sense to introduce the concept, since the critical path attracts attention just to critical activities, while the critical chain attracts attention to other critical attributes as well.
Exhibit 3. Resource profile is obtained by summing the resources required for all single activities.
Exhibit 4. Activities are shifted to the right in order not to violate both precedence relationship and resource constraints.
My recommendation with regard to the above discussion is to adopt the wider concept of critical chain. Its natural place in the PMBOK® Guide is in the “Tools and Techniques” of the “Scheduling Development” process.
Time Estimation. Goldratt claims that, to be on the safe side, the time estimate for executing an operation is conservatively given at around 200 percent that of the median time for the operation—in other words, a project's estimated completion time is made up largely of safety time. Although there are no scientific data to support this claim, it makes sense to many project managers. Exercises that I have conducted as part of project management seminars have confirmed that when project managers want to play it safe, they more than double their duration estimate.
Another interesting finding from the seminars is that the criticality of an activity impacts the estimation. That is, when a certain activity is expected to be on the critical path, the executor will give it a higher estimate than when it is not expected to be on the critical path.
Despite the importance of the issue of duration estimation, it is not altogether obvious that it is the main reason for an inability to complete a project on time. Levi and Globerson [“Improving Multiproject Management by Using Queuing Theory Approach,” Project Management Journal, Dec. 1997] claim that the main reason for delays in project completion is the long waiting lines of work packages queuing at the functional departments where they are to be processed, rather than poor duration estimates of any given activities.
The whole issue of time estimation, although recognized, does not get sufficient support in project management literature. The issue should be discussed and raised, using the earlier-mentioned notion during the estimation process of every single project. The place for this concept in the PMBOK® Guide is in the “Tools and Techniques” of two processes: the “Activity Duration” and “Schedule Development” processes, where resource requirements are estimated.
Slack Management. After the precedence diagram has been established, and the activity durations and resource needs have been estimated, scheduling can take place. Goldratt claims that even if an activity is completed earlier then expected this fact is not reported. In other words, any slack time is consumed by the activity, although a delay in completing an activity is invariably passed on in full to the activities that follow.
Thus, Goldratt makes the following suggestions:
■ Use a median time estimate that assumes just 50 percent completion chance.
■ Use an early start approach in scheduling the project, and collect all local slacks of activities to become the buffer for each path.
■ Ensure that project buffers are managed by the project manager, according to actual results.
■ Prioritize each work package waiting to be processed at each workstation, based on the path buffer.
The last item above highlights the scheduling problem that is faced by the functional manager. I know that this item is considered by the users of the “path buffer” approach as a major contributor to better project management. Prioritization helps establish a systematic functional scheduling in a project environment, which otherwise may be arbitrary.
Goldratt's approach to scheduling makes a lot of sense. Its application depends, however, on resolving the problem of getting the various executors to “contribute” their slack to the project's overall slack.
The issue of slack management can nicely fit into the “Tools and Techniques” of two processes within the PMBOK® Guide’s “Project Time Management”:namely, “Schedule Development” and “Schedule Control.”
I BELIEVE THAT PMI has an ongoing commitment to continuously revise the project management body of knowledge in a manner that will enable project managers to consider the PMBOK® Guide as their most dependable and complete source of project management knowledge. ■
