Theory of Constraints Handbook - James Cox Iii [49]
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.
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