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