Theory of Constraints Handbook - James Cox Iii [36]
In practice, 90 percent of projects occur in a multi-project environment and little research has been conducted in this environment. In practice, few organizations use the project networks to control projects and little research has been conducted on how to control across multiple projects. After the original project plans are established, few bother with constantly updating the plans and rescheduling in the computer. Given all of the causes of failures of projects, one can see why a manager may not go to the trouble to constantly update every delay on every activity in a network.
Cause: No well-defined method of planning and controlling projects in a multi-project environment exists.
This is addressed by Guideline XII.
Summary of the Micro Issues
That which is of the most importance here is not that researchers have not recognized that PERT/CPM is limited by its assumptions, but rather that the effects of these assumptions have been both underestimated and unstated. Many researchers have indeed recognized these assumptions, but there has been no systematic effort to eliminate the effects. By examining the gedankens, the reader will recognize that if the practitioner is forced to commit even one of the errors identified previously, then the project is probably going to be late. Additionally, the magnitude of the system effect (late, over budget, or under completed projects) is increased with each problem and each occurrence of each problem.
A Brief Overview of Critical Chain Project Management
Critical Chain in the Single Project Environment
Goldratt (1997) introduced the concept of Critical Chain Project Management for Single Projects (CCPM-SP or Critical Chain) to begin to address the problems associated with the more traditional methods of PERT/CPM and Gantt charts. As presented later, CCPM-SP addresses many of the guidelines listed previously, but not all of them. Guideline I concerns recognition of project type. Guidelines II and VII deal with the development of the project network, while Guideline XII is concerned with multiple projects. The resulting project network is a feasible, but not necessarily optimal, project plan.
Figure 2-2 shows a typical activity-on-node PERT/CPM project network. Realistically, the completion of project activities requires the use of resources. Furthermore, resources are typically limited—there are only X number of programmers, or bulldozers, or whatever. Assume that the project shown in Fig. 2-2 is to be completed using three different resources. Figure 2-5 shows the same AON network as Fig. 2-2, but with the addition of resources. The shading on the diagram denotes resource use: A and B, C and D, and E and F share a common resource.
The reader will quickly note that the activity times have been reduced by 50 percent. This reduction, at least partially, addresses Guidelines IV, VIII, and X. In addition, there has been another arrow added to the diagram. This dashed arrow represented the priority of resource use within the project—addressing Guidelines III and VI. By using the PERT/CPM technique of forward- and backward-passes through the network considering this newly added dashed arrow, the ES/EF and LS/LF times can be determined. Those activities with zero slack are critical activities. However, the sequence of activities (A-D-C-F) does not correspond to a PERT/CPM path,