Critical Chain Scheduling-Steps 1 through 4

To schedule the project shown in Fig. 3-3 as a CC project, the safety embedded in each task is removed from protecting the task (a local optimum) and half of the safety related to the CC tasks is moved to a place where it can protect the entire project from uncertainty. That means that the starting point for developing a CC schedule is shown in Fig. 3-2, i.e. the project with the estimated dedicated task times.

Step 2, resource leveling, then is accomplished by starting at the end of the project and working backward, rescheduling or shifting each task so that there is no overlap of tasks assigned to the same resource while keeping the total length of the project as short as possible. Unlike the traditional approach where resource leveling occurs after identification of the critical path, with CC the leveling is accomplished prior to identification of the Critical Chain.

Step 3 involves another backward pass through the project in order to identify the most obvious candidate for the longest path. Once again, starting from the end of the project, and working backward on the chosen path, the Critical Chain () is identified as Task J, C, and B, but then, because Task E uses the same resource as Task B, the Critical Chain moves up to Task E and finally Task D.11 Step 4 results in the insertion of the project buffer. The size of the buffer, technically, is half the number of time units (days in this example) of safety that were removed from the activities that comprise the Critical Chain. Most practitioners understand that it is half the total length of the Critical Chain. The project buffer is placed at the end of the Critical Chain, thus pushing the end date past the apparent end point of the last task.

Figure 3-4 demonstrates the first four steps in CC scheduling: (1) using shortened or dedicated task times, (2) resource leveling, (3) the identification of the Critical Chain, and (4) insertion of the project buffer. The Critical Chain is identified with white stars beside the task identifications in Fig. 3-4.

Note that the project buffer in Fig. 3-4 (Step 4) has no task or resource assigned. The project buffer can be used to manage the time lost in those tasks that do not complete in their shortened (dedicated) time. Rather than having safety in individual tasks where it may not be required (and typically is wasted due to the student syndrome, sandbagging, and Parkinson's Law), the project buffer protects completion of the project. Note also that we have rescheduled the lower chain of tasks in Fig. 3-4 to start as late as possible without encountering resource contention on Tasks F and H.

The project is now scheduled to complete in 78 days, but there are several more steps. Remember that software is available to perform these steps.

In terms of the TOC Five Focusing Steps (5FS), the CCPM scheduling Steps 1, 2, 3, and 4 would be the TOC focusing Step 1 (identify the constraint) and Step 2 (exploit the constraint).

FIGURE 3-4 Critical Chain incomplete project schedule with only a project buffer.

Merging Paths-Step 5

When non-Critical Chains of dependent activities that merge into the Critical Chain encounter problems, the entire project can be delayed. To provide protection for such possibilities, feeding buffers, Step 5 should be added at the end of each non-critical path at the point where it joins the Critical Chain. Like the project buffer, feeding buffers are blocks of time that do not have assigned tasks or resources.

The size of these buffers is determined using the same logic as with the project buffer. The general rule is to use half of the total estimated, reduced task times of each feeding path. If the feeding path contains a Critical Chain task, the Critical Chain task is excluded from the calculation because the project buffer already protects it. Figure 3-5 illustrates the placement and size of the feeding buffers for our sample project schedule. The feeding buffer for the upper chain (5 days) is half of the time scheduled for Tasks F and G (10 days). The feeding buffer for the lower chain (7 days) is half of the time scheduled for Tasks H and I (14 days).

Figure 3-5 exhibits two important phenomena unique to CC. Notice first that Task A is not on the Critical Chain, but is a predecessor activity for Task B. Since Task A is a 12-day task, it should have a 6-day feeding buffer. However, that amount of buffer would push the start of Task A to 4 days earlier than the start of the Critical Chain, which is illogical even if possible. Therefore, a dark line in the 6-day feeding buffer denotes the fact that 4 days of the 6-day buffer are consumed before the project begins. Some CC scheduling tools add the "days earlier" to the project buffer for additional protection, others simply register the fact that one of the buffers has already been partially consumed, and others push everything out to make room for the buffer. For this example, 4 days have been added to the project buffer, increasing it from 26 to 30 days.

A second item to note is the apparent violation of the practice of starting all tasks as late as possible. In this case, the PM has decided that because Resource 3 on Task I has the possibility of delaying the start of Task C on the CC if Task H and I are delayed more than a total of six days (a distinct possibility since the feeding buffer is seven days), that the lower path in Fig. 3-5 should begin as soon as possible.12 This action results in a large gap between Task I and the feeding buffer, at the end of which the lower path joins the CC. It is not uncommon for such gaps to occur, given reasoned analysis of risk and additional resource leveling due to the insertion of feeding buffers. Gaps on non-critical paths such as the gaps between Tasks E and F on the upper path in Fig. 3-5 also are no cause for concern.13 FIGURE 3-5 Critical Chain project schedule with project and feeding buffers.

In terms of the original 5FS, dealing with merging paths would be the subordination step, Step 3.

Another Look at Resource Contention

In order to develop a project plan that has any chance of on-time completion, we must schedule tasks in such a way that the assigned resource is not scheduled to work on more than one task at a time. In CC scheduling, we typically start tasks as late as possible and, when scheduling manually, schedule shorter tasks toward the end of the project when possible. This usually will result in less resource contention as the rescheduling proceeds and provide better opportunities for time recovery earlier during project execution.

As mentioned previously, the critical path in traditional projects may change many times. In CC scheduling, resolving resource contention is doubly important and the possibility of resource contention must be checked in every step of the process.

Looking at the intermediate project schedules in Fig. 3-4 and Fig. 3-5, we see that Task F and Task G are forced earlier in time by the insertion of a 5-day feeding buffer. However, no new resource contention arises due to the insertion of this buffer. Task I, Resource 3, which was pushed earlier by previous action by the PM, is not affected by the insertion of a 7-day feeding buffer. If work on Task I has not been completed by the time Task B (that precedes Task C) is completed, normally the PM will inform Resource 3 to cease work on Task I and move to Task C on the CC.14 Since Task D is on the CC, Resource 4 first will complete that task, then begin Task H. Should Task D require more than 8 days to complete, Task H might be delayed starting, but the feeding buffer and project buffer can absorb any delays. This simple project example is unusual in that new resource contention does not result from the insertion of feeding buffers. You always should expect new resource contention arising when feeding buffers are added to a project schedule.

Scheduling a resource to work on more than one task at a time can easily result in the resource multitasking in order to show "progress" on all assigned tasks. Making sure this does not occur in a single project, by leveling all resources, avoids this type of unproductive multitasking. Of course, in a multi-project environment, it is impossible to level all resources over all projects with any confidence that resource contention can be avoided. We must use another CC technique, discussed later, to avoid resource contention in a multi-project environment.

Communications-Step 6

It is imperative that a resource that is assigned to a task on the Critical Chain immediately begin that task as soon as the preceding task is completed. CC uses a notification system that informs the next resource that she or he will be required to work on a CC task. This notification is given a brief time interval before the previous CC task has been completed. In the sample project, this time interval would be two or three days at most.

FIGURE 3-6 A complete and fully protected Critical Chain project schedule.

Step 6 of CC project scheduling15 ensures this notification occurs by placing resource buffers in the project schedule at appropriate points. Resource buffers do not have any task time: they are communication tools. In addition, resource buffers should be placed in the project plan to inform resources assigned to tasks with no predecessor when they should begin work. Tasks A and D have no predecessors and therefore require early warning signals.16 The problem of ineffective multitasking was discussed previously. A general policy should be established that states that once a task is begun, it should be completed before another queued task is begun. Certain exceptions can be allowed, such as when the resource must wait for some requirement before he or she can complete the current task. However, the most important exception is when the resource is required on a CC task. The notification time, mentioned previously, should be set at a sufficient time for the resource to "set down" his or her current work in an orderly fashion and prepare for the CC task.

Now we have a fully protected CC project schedule, shown in Fig. 3-6, with no resource contention and with three feeding buffers and a project buffer. The project is now scheduled to complete in 82 days.

There are alternative CC project schedules that are possible for the sample project used in this chapter. This is because the scheduler or scheduling tool may opt to move different tasks forward or backward and thus achieve a somewhat different schedule.17 The most important concern is not that the schedule is the shortest possible schedule (as most academic literature suggests), but that the promised project completion date is adequately protected.

In Fig. 3-6, resource buffers (one or two days) have been placed in the project schedule to notify Resources 4 and 5 when they should begin work on this project. Resource 4 is informed to begin Task D, then go immediately to Task H. Proper notification (a resource buffer) is given to Resource 2 when work is scheduled to start on Task E on the Critical Chain. Resource 2 is instructed to proceed from Task E as soon as that work is completed to Task B. Like Task H, whose start was transmitted in Task D's resource buffer, a separate resource buffer for Task B is not required.

Even though Resource 3 may still be working on Task I (late completion) when Task B is nearing completion, the resource buffer or other communication about an upcoming CC task may advise Resource 3 to start setting down work on Task I in an orderly way and be ready to begin work on Task C as soon as Task B is completed. Once Task C has been completed, Resource 3 immediately can return to Task I and complete that work.18

Three Sources of Critical Chain Project Protection

The previous discussion and Fig. 3-6 illustrate that there are three types of protection to improve the likelihood of completing CC projects on schedule: 1. One project buffer of time that can be used for Critical Chain tasks that are not completed in their shortened duration times.

2. Multiple feeding buffers of time that can be used to protect the Critical Chain activities' starts if there are problems with activities on merging paths.

3. Multiple resource buffers that do not add time to the project schedule but provide early warnings to certain resources either to start a path or that they must move to a CC task when needed and sometimes deviate from the standard policy (of not stopping work on a task until it is completed) in order to start a CC task on time.

In order to present the principles of CC project scheduling, this section considered a simple schedule in a single project environment. We have also presented some clues about basic behavioral changes that are required to make CC project scheduling more effective. Responsibilities for behavioral change will be covered later, but first we will look at the complicated world of scheduling in many or perhaps most environments where many projects coexist.

Scheduling Projects in Multi-Project Environments

A major problem in a multi-project environment is establishing priorities. Not every project can be "Number One." Setting priorities for projects in a multi-project environment is difficult, but essential. In our experience, many organizations forgo this politically sensitive task and simply cram as many projects as possible into the system in order to take advantage of new business opportunities. Doing so, however, frequently jeopardizes progress on the projects currently underway. The assumption that an early start makes possible an early finish is incorrect. As described previously and in Chapter 2,19 flooding the organization with projects creates chaos in the project management process, stresses conscientious workers, and tends to burnout the organization's best people.

Because multitasking is rampant in multi-project environments, and generally is highly valued by management, we wish to stress again its negative effect on productivity. So that you can experience the harmful effects of multitasking, we have included a "Wafer Experiment," located at www.mhprofessional.com/TOCHandbook that you should conduct. The experiment compares traditional multitasking on three projects with the CC approach. This is a nice experiment to perform with your children, who may be far better than you may be at manipulating objects on a computer, and who will benefit from being involved in the experiment.

Establishing Project Priorities

It is beyond the scope of this chapter to solve all the problems of prioritization, but it is imperative for every organization in a multi-project environment to use some priority scheme. It does not make sense to permit, by default, the setting of priorities by a resource manager or other person who may not have a global perspective of the organization's many ongoing projects.

Many organizations have established a Project Management Office (PMO) for the management of their project portfolio. Some of the possible functions of a PMO are described in Fig. 3-7. Notice the establishment of project priorities based on business priorities, resources, and organizational skills.

Selecting a Scheduling Resource and Establishing Scheduling Buffers

Once project priorities are established, the key TOC concept of buffers can be employed to control the initiation of new projects. In a multi-project environment, each project is scheduled in the same way as in a single project environment, but without regard to resource usage in other projects. Due to massive task duration uncertainty, it is not possible to level all resources across all projects and expect such initial leveling to remain effective for any period of time once project execution is begun.

In order to minimize the need for resources to multitask and to make sure delays on one project do not affect other projects, entry of new projects into the system must be controlled. We have chosen to use the descriptive terms of "scheduling resource" and "scheduling buffers" in this chapter to restrict the entry of new projects. However, standard terminology has not been established. A search of CC software vendors' training materials and an investigation of materials and resources used by consultants, academicians, and other CC experts have yielded references to "pipeline buffer," "staggering buffer," "drum feeding buffer," "scheduling resource buffer," "synchronizing buffer," "drum buffer," "sequencing buffer," "capacity buffer,"20 "drum schedule buffer," "pacing buffer," and "capacity constraint buffer."

FIGURE3-7 Functions of a Project Management Office. (Reprinted with permission from A Practical Guide to Earned Value Project Management, 2nd ed., Charles I. Budd and Charlene S. Budd. 2010 by Management Concepts, Inc. All rights reserved.) A scheduling resource (SR), somewhat similar to the constraint resource in Drum-Buffer-Rope (DBR) implementations for manufacturing, is used to minimize resource conflicts and prevent choking the organization with too many projects. Just as material is scheduled into a production line based on the system's constraint (the drum that controls the pace of production), we can schedule the initiation of projects into our operations based on the scheduling resource's availability.

Of course, identifying a resource constraint in most multi-project environments is impossible and unnecessary. Therefore, choosing the "right" SR is not critical, but the SR should be one that is utilized across most projects. In software projects, the integration21 resource typically is chosen as the scheduling resource.

The initiation of each project (in the predetermined priority order) is scheduled such that the SR is leveled across the projects. That is, the SR's22 tasks are never overlapped. New projects can be initiated only at the time that the SR's first task in the new project occurs after the SR's last task in the current project is scheduled to complete.

In addition, we do not want to schedule the SR's tasks in the different projects back-to-back in case one of the tasks should overrun its estimated duration. To provide some protection for the overall multi-project schedule, a scheduling buffer is used in each project.

The scheduling buffer is inserted into each project in front of the first task to be performed by the SR. When problems arise in any project, a time buffer in front of the SR's task in the next project will minimize slippage in the entire portfolio schedule. The size of the buffer is optional, but it should be relatively large. Because our entire project portfolio schedule depends on the scheduling buffer, a general rule is to make the buffer at least as large as the duration of recent task times scheduled in the higher-priority project. This is especially true when first establishing a CC multi-project environment. However, buffer size can depend on experience, individual project configurations, and other factors.

For example, suppose we select Resource 4 as a SR. The last two tasks of Resource 4 in the sample project (see Fig. 3-5 or Fig. 3-6) are scheduled with sequential durations that total 20 days. This project is unusual in that Resource 4 was required to perform four separate tasks on this project. The next priority project only requires Resource 4 to perform two tasks, about the average for this organization. Therefore, the organization has decided that 20 days is a sufficient scheduling buffer to delay the start of Project 2.

Figure 3-8 shows the latter part of the current project, "Project 1," and two additional projects being initiated as Resource 4 (black color) is available to perform work on them. (Only the latter part of Project 1 and only the beginning part of Project 3 are shown in Fig. 3-8 because the figure is designed to show how the scheduling buffers in Projects 1 and 2 sequence the release of Projects 2 and 3 based on availability of black Resource 4.) The previously described Strategic-Resource-Buffer methodology sufficiently staggers the entry of work into the organization's system, according to a project's priority, to avoid, to a great extent, any temptation for resources to multi-task. Should there be an occasional example of a resource being required to perform work on different projects at the same time, the PMO or the resource manager can decide which task should have priority.

FIGURE 3-8 Scheduling resource (black) and scheduling buffers space the entry of new projects.

The CC in each project in Fig. 3-8 is identified with white stars (). Project 2 has black Resource 4 scheduled on two tasks for a total of 25 days. Therefore, the scheduling buffer to sufficiently delay the start of Project 3 is 25 days.

Establishing clear project priorities to support an organization's strategy is the responsibility of top management. Priorities should be clear and firm. Should a more desirable project opportunity arise, project scheduling can be adjusted. However, the impact of delaying projects already scheduled should be computed and considered carefully prior to adding a new project. Change control at the portfolio level is as important as change control on an individual project.

Project Control: The Power of Buffer Management

We previously discussed the purpose of buffers as a project-planning device to concentrate protection for individual projects and to control the initiation of projects in a multi-project environment. Another very important use of CC buffers is to provide a project management tool so a PM knows when to take action and when to avoid doing so unnecessarily.

Tracking Buffer Consumption

To calculate buffer consumption, the PM must have current information on every task that has been started and has not been completed. At each checkpoint (daily or once or twice a week), each project staff member currently working on a task should be asked for the amount of time remaining to complete the task. It is unproductive, for project management purposes, to ask for a completion date or percentage of the work that has been completed. (Historically, "percent complete" has often been overestimated.) A "remaining" time estimate is necessary for the PM to know if action is warranted. The remaining time, added to the time elapsed since the task was started, can be compared to the original estimated aggressive time to determine the buffer penetration or recovery. The reported remaining time changes (i.e. is not always decreasing) each time a query is made.

A task duration overage, meaning the task will complete some time beyond the reduced estimated (aggressive) duration, can be calculated as follows: For a task that has been started and not completed, add the amount of time remaining to complete the task (provided by the assigned resource) to the time elapsed since the task was initiated and compare the current expected total duration to the original estimated aggressive duration. If the current duration is greater than the estimated aggressive duration, the difference between the two is the amount of overage that must be reflected in the appropriate buffer as "used."23 The overage calculation is not based on when the task was originally planned to start. There is no concern about "start dates" or "finish dates" as each activity time is calculated only on its own planned duration. More will be discussed on this matter later, but as we have already intimated in the preceding section "Communication Plan," start dates are not emphasized. Instead, CC concentrates on task durations and provides notifications of impending work for each resource on the Critical Chain and for each task without a predecessor task. Otherwise, work is performed in the order in which it arrived in a resource's queue.

If the overage task is on a feeding chain, the amount of the estimated overage is subtracted from the feeding buffer. If, at some point, a feeding buffer becomes fully consumed, then any remaining overage is shown as utilized in the project buffer. For any task on the Critical Chain, the overage must be subtracted from the project buffer. In a multi-project environment, the project management office (or the equivalent function) should track the performance of the SR (see Fig. 3-8) so that scheduling buffers can be adjusted if the SR indicates a shorter or longer than planned duration for one of its assigned tasks.

FIGURE 3-9 Buffer variation areas. (Reprinted with permission from A Practical Guide to Earned Value Project Management, 2nd ed., Charles I. Budd and Charlene S. Budd. 2010 by Management Concepts, Inc. All rights reserved.)