Rather than merely holding completed work, if work on a task proceeds extremely well (which normally would enable the work to be completed before the due date), there is a tendency among some resources to continue improving the completed work. This sometimes is referred to as "polishing" work and has come to be known as Parkinson's Law which states that work expands to fill the time available (Parkinson, 1957).

Not infrequently, these resources think they are improving the quality of their product by adding "extras" not included in the original specifications for the task. (In our experience, this is especially true on software projects.) However, the unspecified and undocumented addition may cause problems, sometimes major problems, further along in the project.

Management rarely distinguishes between task uncertainty and the time that is lost when tasks are started late, constantly interrupted, or when workers fail to turn over finished work. CC acknowledges these dysfunctional behaviors and establishes policies to deter their occurrence. The next section summarizes the basic elements of CC.

Key Elements of Critical Chain

While many of the basic project management concepts are preserved in CCPM, it is designed to overcome the most egregious issues that have resulted in the poor performance of projects as described in the previous chapter and in all-too-familiar press reports. The magnitude of change required demands a different approach. When people are doing their best and outcomes are unacceptable, as Deming (1993, 172175) so strongly advised, we must change the system.

Changes are required in planning, scheduling in single and multi-project environments, and in managing the project.

Issues in Creating a Project Plan

Most stakeholders involved in a project are quite familiar with the general requirements of the project that include issues such as identifying the project objective, having a project charter, understanding the work breakdown structure, acquiring resources, and creating a plan for the budget and scheduled tasks.3 Once planned, most project management books suggest that the critical path, the longest chain of dependent tasks, is the most important in project completion. Therefore, this path is given preferential treatment when assigning scarce resources.

When planning a CC project, the total budget may be the same, but there are particular scheduling requirements that differ from the traditional critical path approach. However, we will discuss the scheduling differences then return to the project budget toward the end of this chapter.

Task Duration Estimates

Human resources naturally include safety time in their duration estimates. In defining a CC schedule, this safety is removed from individual (local) tasks and aggregated to protect the entire project. It can be helpful if the PM has some historical knowledge of an individual resource's safety preferences. In general, about half of a task's "safe" time, the time required to be 90 to 95 percent confident of task completion, is there to cover interruptions, surprise rework, urgent unanticipated assignments, and task estimation error.

Rather than providing "start" and "finish" times for every task, as recommended by traditional project management, CC uses task durations and asks resources to work on a first-in, first-out (FIFO) basis for all queued tasks. Start times are provided only for initial activities on a path-those with successor activities but no predecessors.

Task Uncertainty

Just as a management reserve is established to cover the uncertainty of estimated costs, task uncertainty is managed in CC with buffers of time. Besides referring to these blocks of time with no scheduled activities as buffers, some U.S. government guides call them schedule reserves or schedule margins.4 (For example, see NASA, 2009, 223224; United States Government Accountability Office [GAO], 2009, 56, respectively, for NASA and GAO best-practices remarks).

Buffers will be explained more fully later and will be illustrated in an example of a project scheduled using CC concepts.

Resource Contention

In most traditional project plans, encountering resource unavailability or tasks delivered late can cause the critical path to shift. Some projects will have the critical path shift several times during project execution. These shifts result in constantly changing priorities and continuously revised task start and finish times. This is especially true if projects are not leveled prior to initiation of project work.

In CC project plans, it is vital to resolve all resource contention with reverse passes through the project schedule; that is, starting from the end of the project schedule, eliminating resource contention all the way back to the start of the project. Following this resource leveling effort, the Critical Chain is identified as the longest chain of task and resource dependencies. Ideally, a Critical Chain remains the same throughout project execution.

Merging Paths

There is special risk in a project schedule where paths or chains5 of dependent activities merge with other chains. If one of the paths is the Critical Chain, the project completion date can be endangered by late completion of a non-critical path. As we will see in a sample CC project schedule, special attention is ascribed to chains of dependent activities that merge into tasks on the Critical Chain.

Communications

There are many policy differences between traditional project management and CCPM and those differences will require changes in organizational and individual behaviors. An especially important process for CC projects is an effective communication system that includes a method of resource notifications, a message to a resource to: (1) start a chain (path) of activities, (2) prepare for upcoming work on the Critical Chain, or (3) perform critical work on a higher-priority project in a multi-project environment. Such notifications help to ensure that CC tasks, which determine project completion, will be given appropriate priority.

Later in the chapter, we will describe how CC overcomes all the forces that pose challenges to successful project completion.

Issues in Managing Project Execution

Ideally, no project should be started unless all specifications have been received, the charter has been approved, an acceptable schedule has been approved, and all other preparatory steps have been accomplished. Further, no task should be started unless all required materials are available and the task is at the start of a FIFO work queue. Having everything ready and on hand before starting a project or a task is referred to as having a "whole kit" or a "full kit." While a research project may violate this "rule," other projects should not.

In traditional project management, once a project is begun, each task is managed as if it were an independent event. That is, a worker is rewarded if an assigned task is completed on or before its scheduled finish date; exhorted to work harder if it is not completed on the finish date; and punished, in several ways, if the finish date is overrun by a significant amount. The rationale for this partitioning of project work is that if every task is completed on time, the project will be completed on time. Of course, this rationale completely disregards the reality that few, if any, tasks are passed on early. Therefore, if only a few tasks complete late, as nearly always happens, the entire project is delayed.

Critical Chain uses buffers to manage task duration uncertainty and to monitor project progress. A later section, entitled "Project Control: The Power of Buffer Management," describes how this is accomplished.

Scheduling a Single Project

One of the easiest ways to illustrate the way CC addresses the issues presented previously is by contrasting what is done in traditional project environments with a single project example. To illustrate the scheduling steps, we use a simple project with 5 resources and 10 activities (tasks). There is only one of each of the five uniquely qualified resources; each resource can perform its own work but cannot perform the work of any other resource.

To provide a better understanding of single-project scheduling, a manual CC process is described in the following section. However, there are software programs now available that can perform these scheduling steps in both single project and multi-project environments. The advantages of the CC solution in a multi-project environment are even more dramatic and will be discussed later.

Modifying Task Duration Estimates

Following initial project planning activities (i.e., identifying the project objective, authorizing the project charter, determining required tasks and the work breakdown structure, etc.), a most critical step in preparing a project plan is getting estimates for task durations. In most organizations with a functional or matrix structure,6 project resources are primarily responsible to a line manager and only secondarily to a PM. The resources know that project tasks will be in addition to their usual job responsibilities. They often do not know how much of their time the task will take. They do know that they will be expected to complete their project tasks within the estimated (promised) time.

FIGURE 3-2 Estimated dedicated task times.

If resources could work uninterrupted on a task until it is completed, they probably would provide the estimated durations shown in Fig. 3-2. However, they would be risking their jobs to report these durations to their PM.

Veteran resources (all of whom have experienced unplanned work assignments and interruptions that affect their ability to complete their assigned tasks on time) rely on their intuitive knowledge that the actual task time will be an element of a skewed distribution having some minimum time but possibly a very high maximum. Therefore, knowledgeable resources typically give a task duration estimate that they can expect to meet at least 90 percent of the time. (Recall that resources in traditional project management are held responsible for completing the task by their estimated times.) Assume, for our simple example, resources provide the task times illustrated in Fig. 3-3 for a traditional, resource-leveled project.7 Task D, on the top path of Fig. 3-3 and Task J at the very end of the project, show the skewed continuous distributions associated with the task estimates of 16 days and 28 days for Tasks D and J, respectively. All of the tasks have similar distributions that justify the times submitted, although they are not shown in the figure. The tasks that comprise the critical path are highlighted with a solid thick grey line from Task D and two-thirds of Task E, to Task B, shifts back to Task E (to complete the final 4 days of the 12-day task) estimate, and then continues to Tasks F, G, and J.

Note that the lower path of activities in Fig. 3-3 is scheduled to begin as soon as possible (immediately after Resource 4 completes Task D), as is the general practice in traditional project scheduling. The generally held erroneous assumption that an early start helps ensure an early finish guarantees path starts as soon as possible. The project is scheduled to complete in 104 workdays. Microsoft Project 2007TM software splits the work on Task E into two parts and includes Task B on the critical path, as reflected in Fig. 3-3.

FIGURE 3-3 Traditional resource-leveled project schedule (showing 2 of 10 distributions).

A major precept of the Theory of Constraints (TOC) states that the sum of local optima is not equal to global optima. In managing a project, the concept implies that concentrating on individual task completion does not ensure that the project will complete on time. The entire project may be in danger of not completing on schedule when even a few tasks are late (especially if they are on the Critical Chain). This means that we should change our focus from individual task completion to project completion. This focus is accomplished in a CC schedule by removing the safety (time) built into the individual tasks and concentrating this safety where it will protect the project's completion rather than the completion of individual tasks.

Can we really do this and not jeopardize the completion of every task? Yes, but it will take some changes in organizational behavior patterns, which we will discuss later. First, let's look at the statistics that really indicate that there is little overall danger in removing some time from task duration estimates.

A Bit of Statistics

Basic statistical understanding informs us that about half a project's tasks will complete before their dedicated duration and about half will complete after. The uncertainty in the sum of tasks is equal to the square root of the sum of the squares of the individual task variations. Variation here is the difference between the estimated and actual time.

Of course, the above formula technically is only applicable in repetitive situations where task durations are independent, but it helps us understand a complex issue.

Intuitively, when we amass all the protection in one place (a buffer), the early and late finishes should offset each other. Thus, TOC argues that we need only about half the safety used to protect each individual task. For shorter projects, where the offsets might not happen as expected, we might need more than 50 percent of the safety removed from individual tasks; on larger projects, we may not need as much. However, 50 percent is a good rule of thumb for establishing a project's buffer, the schedule reserve that we establish at the end of the Critical Chain.

Critical Chain Scheduling

Armed with knowledge of CC issues and the single project environment, we are prepared to schedule the sample project introduced previously. There are six generic steps in CC scheduling 1. Build an initial project schedule that has safety times (assumed here as approximately 50 percent of the original task time estimate) removed from task durations.8 2. Working from the end of the project, eliminate all resource contention (first backward pass).

3. Identify the longest path of resource and task dependencies: the Critical Chain (the second backward pass).

4. Calculate and insert the project buffer (typically about half the safety removed from tasks on the Critical Chain).

5. Calculate and insert feeding buffers for all paths (chains) merging into the Critical Chain, resolving any newly discovered resource contention within the project. (Compute buffer sizes using the same procedure as that for the project buffer.) 6. Add communication resource buffers9 to ensure timely notifications to resources that have no predecessors to begin work, and to all resources that have work assigned on the Critical Chain.

An optional seventh step may be required if the planned completion date is too far in the future.

7. Analyze the schedule and evaluate options to complete the project at an earlier date; make selected changes, review and approve changes, and update the schedule.

As we will see, for most CC projects it is easy to know which additional resources should be acquired, and for what periods of time.10 Therefore, we will concentrate on the first six steps in our sample illustration.