Using Critical Chain Project Management

In 1984, Eliyahu M. Goldratt introduced the Theory of Constraints (TOC) in a book entitled The Goal (North River Press, 1992). The basic idea behind the TOC is that every organization is constrained by at least one factor. That factor ultimately constrains the activities of the organization. In projects, that constraint is often the availability of people either in terms of numbers or skills. Peter Senge, in his book The Fifth Discipline (Currency/Doubleday, 1994), stated that “to change the behavior of a system, you must identify and change the limiting factor,” which Lawrence P. Leach, in his book Critical Chain Project Management, Second Edition (Artech House, 2005), called the best definition of TOC that he has heard. Still, it was not until the late 1990s that practitioners were able to link TOC to project management. Critical chain project management (CCPM) is the result of the linkage between TOC and project management. CCPM has grown in popularity and is making an impact on project success.

The second edition of this book contained a brief paragraph on CCPM. At the suggestion of several readers, I decided to expand my treatment of CCPM. That is the purpose of this chapter. I am aware that many project management practitioners and writers dismiss CCPM as just another way of managing risk, and suggest that it does not represent any new thinking about project management. It is not my purpose to settle that debate. I merely want to give some space to an idea, an approach, that all project managers will appreciate. The interested reader should consult Leach's Critical Chain Project Management.

What Is the Critical Chain?

As mentioned in Chapter 5, the critical path is the longest duration path through the project. It is built by considering only the task dependencies and their individual durations in an additive fashion. CCPM claims that the critical path approach to project management is flawed. Instead, CCPM claims that the focus should not be on the critical path, which is resource-independent, but on the path that is task-dependent and resource-constrained, the so-called critical chain. The critical chain is defined as the longest duration path through the project, if you consider both the task dependencies and the resource constraints. Critical chain project management is defined as the planning, scheduling, and maintenance of the critical chain throughout the course of the project. Furthermore, by giving priority to the critical chain, the project manager identifies and schedules tasks around the most constrained of the resources, increasing the probability of completing the project in less time than the critical path approach. This chapter includes a simple example to illustrate how that schedule compression happens.

In the critical path approach, resources are allocated first to the critical path, which is known to not be the optimal way to create the shortest schedule. Two concepts form the justification of the CCPM approach, described in the next two sections.

Variation in Duration: Common Cause versus Special Cause

The first concept that justifies the CCPM approach is that there are two basic kinds of variation that you experience in task duration. They are as follows:

What do these mean to the project manager? Common cause variation is accounted for in the contingency attached to each task. Common cause variation occurs naturally and is always present. You live with that and plan accordingly. Special cause variation is dealt with as part of your risk management plan. These are the variations you can manage as project manager.

Statistical Validation of the Critical Chain Approach

The second concept that lends credence to the CCPM approach is based in statistical distribution theory. Here you call on a basic concept from statistics: the variance of a sum is the square root of the sum of the variances of each of the components in the sum. The square root of the sum of squares is less than the sum itself. That may sound like gibberish to most of you, so let's take a look at how it translates to project duration. Figure 10-6 shows a sequence of four consecutive tasks. Each one has a contingency associated with it (the shaded area after the task). Contingency is defined as the difference in duration between a 50-percent probable estimate and a 90-percent probable estimate. For example, suppose that about half the time a particular activity completes in 10 hours or less. That is the 50-percent probable estimate. In addition, that same activity completes in 15 hours or less approximately 90 percent of the time. That is the 90-percent probable estimate. The difference between the two (15 – 10, or 5 hours) is the contingency.

Figure 10-6: Using contingency can reduce project time

In the lower part of the figure, I have moved the contingency of each task to the end of the sequence of tasks. Note that the variance of the sum of the contingencies is less than the sum of the variances of the contingencies. Calling on that statistical property has enabled me to shorten the duration of the sequence of tasks. You might say that I haven't really done anything; I've just defined things a little differently. Not quite. I have used the average task duration as the point estimate of task duration. (A point estimate is a single number that represents your best guess as to the real value of the number you are trying to estimate, whereas a range estimate is a low and high number that you believe spans the unknown number you are trying to estimate.) The average is the number that the duration will exceed half of the time and be less than half of the time. Because of the variation in duration as a result of common causes, you can expect some of the tasks to take more time than their average duration and some to take less time. That variation is collected into the contingency at the end of the sequence. To bring the sequence in by the shorter time, the project manager has to manage the contingency. So what I have accomplished by collecting the contingencies at the end of the sequence is to change the focus of the project manager to that newly aggregated contingency. The contingency has been made visible, and therefore it is manageable.

A final comparison of the critical path approach versus the critical chain approach will help you understand the fundamental differences between the critical path and the critical chain approaches is one of a sequence of activities. Some of them will take longer than their estimated duration, and others will take less time. The project manager reviews the status of the contingency and decides whether to act or to let the statistical variation correct the overage.

I'll have more to say on that by way of an example in the next section, but for now it is important to see the distinction and the real strength of CCPM. The TPM project manager reacts to the performance of a single task in a sequence of dependent tasks and expends management time. The CCPM project manager dismisses that as a waste of time, reasoning that attention should be given to the sequence and not to any single task. CCPM relies on the statistical properties of a sequence of dependent tasks, whereas TPM does not.

The Critical Chain Project Management Approach

The CCPM approach is identical to the TPM approach up to the point where the project network diagram is defined and the critical path is identified. The traditional project manager would next conduct a resource-leveling exercise targeting resource usage on the critical path. At this point, the critical chain project manager develops the critical chain plan. In the discussion that follows, I describe each of the CCPM planning steps for you by way of a simple example.

Step 1: Creating the Early Schedule Project Network Diagram

Figure 10-7 shows the early schedule for a simple seven-task project. This early schedule is the same one someone using TPM might make. Note that the project duration is estimated at 16 days using the original task duration estimates, which include contingencies for each task. Figure 10-7 shows the critical path (C1–C2–C3) for a project manager using TPM, and it is the starting point for resolving any resource contention problems.

Figure 10-7: The early schedule

Step 2: Converting the Early Schedule to the Late Schedule and Adding Resources

After calculating the earliest start (ES), earliest finish (EF), latest start (LS), and latest finish (LF), a project manager using CCPM converts the task schedule to the late schedule, as shown in Figure 10-8. Note that this conversion removes the slack associated with the sequence defined by tasks A1–A2 and B1–B2. In fact, it removes all of the free slack and total slack associated with any task or task sequence in the project. Note also that the 50-percent duration estimates have replaced the original estimates, which included contingencies. In doing that, the project duration has been reduced from the original 16 days to 8 days. I have also added the three resources (Duffy, Ernie, and Fran) to the tasks to which they have been assigned. Note that there is a resource conflict with Ernie on tasks A2 and B2. In addition, note that the project duration is reduced to eight days when the contingencies are removed.

Figure 10-8: The late schedule with resource assignments

Step 3: Resolving Resource Conflicts

In general, resource conflicts are removed by beginning with the task sequence that has the least slack. After resolving that conflict, move to the task path that now has the least slack. Continue in this fashion until all resource conflicts have been resolved. In the example, the critical chain (C1–C2–C3) does not have any resource conflicts. The next task path to consider is A1–A2. In this case, Ernie would be scheduled to work on A2, which means pushing his work on B1 to an earlier date. This resolution is illustrated in Figure 10-9.

The other way to resolve the resource conflict is to have Ernie work on B2; then after Duffy has completed A1, Ernie can work on A2. This resolution is illustrated in Figure 10-10. The second option extends the duration of the project.

This simple example illustrates the major difference between TPM and CCPM. TPM uses the early schedule as the base for all management decisions. CCPM uses the late schedule. TPM focuses only on the critical path and manages in accordance with that. CCPM focuses on the paths with resource constraints and manages in accordance with the best use of the resources. It does so by using the critical path but only to identify the chains with the least slack, and prioritizing resource use based on the minimum slack paths. To protect the scarce resources, CCPM uses the concept of buffers, which is the topic of the next section.

Figure 10-9: One way to resolve the resource conflict

Figure 10-10: Another way to resolve the resource conflict

Establishing Buffers

Now that I have adjusted the late schedule for the resource conflicts, I can add the appropriate buffers to the project schedule. There are many different kinds of buffers and many different purposes for which they are used. I discuss and illustrate three of them with this simple project.

Defining Buffers

Buffers are segments of time that are placed at the end of a sequence of tasks for the purpose of protecting the schedule of those tasks. Buffers can also be used to protect cost, much like a contingency for unexpected expenses in a budget. The size of time buffers is based on the total duration of the task sequence to which they are attached. Basically, the size of the buffer is determined by calculating the total of the contingencies in the tasks that make up the sequence.

Types of Buffers

Although there are others, I focus on the following three types of buffers in this chapter:

• Project buffers
• Feeding buffers
• Resource buffers

Project Buffers

The project buffer is a time buffer placed at the end of the critical chain to protect the overall project schedule. Its size can be calculated as the square root of the sum of the squared differences between the original task duration estimate and the reduced task duration estimate.

Feeding Buffers

The feeding buffer is a time buffer placed at the end of a sequence of tasks that lead into the critical chain. Its size is calculated the same way as the project buffer size.

Resource Buffers

The resource buffer is different from the previous buffers. It is not a time buffer. It is a flag, usually placed on the critical chain to alert a resource that it is needed. The flag can be placed at intervals such as one week before the resource is needed, three days before the resource is needed, or one day before the resource is needed. Because it does not contain any time interval, it does not affect the project's scheduled completion date. It serves merely to protect the critical chain.

Other Buffers

As indicated earlier, several other buffer types are used, but they relate to a multiproject environment and are beyond the scope of this overview chapter. The interested reader should consult Leach's book Critical Chain Project Management. Some of the other pertinent buffers found in Leach's book are as follows:

• Capacity constrained buffer — A buffer placed between projects to ensure a specific sequence of projects in a multiproject environment
• Cost buffer — A contingency added to a project or sequence of tasks to protect overall cost
• Drum buffer — The capacity of a single resource that is scheduled across several projects

Managing Buffers

The CCPM project manager is concerned about the starting time of a sequence of tasks, including the critical chain, but isn't concerned about the finish time of the sequences. The finishing times are not even in the CCPM project plan. Instead, the CCPM project manager manages the buffers. In managing the buffers, the CCPM project manager is protecting the actual duration sequence and hence the completion time of the project.

The TPM treats the buffer as nothing more than management reserve, which was discussed in Chapter 5. The only real similarity between a management reserve and a buffer may be in how they are managed. Managing management reserve and managing buffers can follow very similar logic. The three decision trigger points in buffer management are as follows:

• When the schedule for the sequence of tasks slips and penetrates into the first third of the buffer
• When the schedule for the sequence of tasks slips and penetrates into the middle third of the buffer
• When the schedule for the sequence of tasks slips and penetrates into the final third of the buffer

Let's take a closer look at each of these trigger points and the appropriate action that the CCPM project manager should take.

Penetration into the First Third of the Buffer

Unlike the project manager using TPM who chases every slippage on the critical path or any change in the critical path, the project manager using CCPM is looking at the performance of a sequence and is less likely to respond immediately to the first slippage. Penetration into the first third of the buffer means that the cumulative slippage in the sequence is less than one-third of the buffer. There is no defensible reason why the CCPM project manager would want to take any action.

Penetration into the Middle Third of the Buffer

Penetration into the middle third of the buffer does call for some action on the part of the CCPM project manager. In this case, the correct action is to investigate the cause of the slippage and put a get-well plan in place. The earlier in the sequence the slippage occurs, the more serious the problem.

Penetration into the Final Third of the Buffer

Penetration into the final third of the buffer is serious regardless of when in the sequence it occurs. Obviously, if it is in the first third of the duration of the sequence, it is very serious. If it occurs late in the final third, there may be little that can be done. In any case, action is called for.

Figure 10-11 illustrates a matrix that can be used to determine schedule slippage severity and the need for action as a function of buffer penetration and distance into the task sequence.

Figure 10-11: Buffer penetration and action decisions

To grasp the significance of the penetration matrix, first consider the diagonal from the top-left cell to the bottom-right cell in Figure 10-11. The cells on the diagonal reflect situations where task sequence penetration is about equal to buffer penetration. The statistician would say that is what you should expect on the average. However, the further you move into task sequence penetration (moving down the diagonal), the more you should be paying attention to the team's performance on the tasks in the sequence. The nearer you are to the ending tasks in the sequence, the less likely it is that you can formulate and execute a get-well plan should things go poorly. For example, if you are in the second third of the task sequence, it might be a good idea to take a look at the problem situation and formulate an action plan in the event that things deteriorate. The problem is not serious, but it does deserve your attention. In the final third of the task sequence, all you can do is closely monitor things and take action at the slightest aberration in the task sequence schedule.

The best place to be is below the diagonal I've been discussing. You could even be experiencing a situation where the task sequence will finish ahead of schedule, and the time saved can be passed to the successor task sequence. However, you're probably more used to situations that are above the diagonal. If you are in the first third of the task sequence and have penetrated into the second third of the buffer, you have a serious problem that needs immediate investigation and solution implementation. There may be a systemic flaw in the project plan, and early intervention is needed. If the schedule continues to slip and you find that you have penetrated into the final third of the buffer, you are in real trouble, as the matrix suggests. You could be looking at a significant slippage that may impact the project buffer as well.

Track Record of Critical Chain Project Management

It was not until the 1997 publication of Eliyahu M. Goldratt's book Critical Chain (North River Press, 1997) that people began to see the connections between TOC and project management. CCPM has a history of more than 10 years to draw upon for its successes. Leach cites a few of them in his book Critical Chain Project Management. Here are brief summaries of some of those success stories.

These stories do not in any way validate CCPM as better than TPM. It is too early to tell that, but it is a fact that there have been many successes using it. You be the judge. You decide whether or not CCPM presents a more advantageous approach for your projects than TPM. I have simply presented another way of managing resources and leave it up to the project team to decide which approach makes more sense, given the situation.