Theory of Constraints Handbook - James Cox Iii [27]
This is addressed by Guideline IV.
Cause: The resource and project managers are unable to plan resource use across activities in the same project or across activities in different projects.
Cause: Murphy has struck and some activities have been delayed into the time allocated for other activities connected to the activity by technological precedence or by the use of a common resource (resource precedence).
These are addressed by Guidelines V and VI.
Development of a Project Network
In theory, the development of a project network is straightforward. First, we ask, “What are the activities of the project?” Then we ask, “What goes first? What goes next? What can be done in parallel?” These steps are over simplifications to say the least.
In reality, activities cannot start for a multitude of reasons not related to those activities preceding the delayed activity (e.g., the tools were not available, the materials didn’t come in from the vendor, the workforce wasn’t scheduled, the application was not made for a needed permit, etc.). In practice, each activity (node) in the network must be examined to determine what has to be present to perform the activity. The mere completion of the previous activities does not always constitute the starting condition for the activity. For example, in a recent upgrading of a computer network for a building, the work crew was scheduled, the users were notified that the building would be closed on the weekend, the computer was scheduled to be down, police were notified of workers crawling through ceiling spaces, etc., but the necessary cable did not arrive. Therefore, we find that while several activities were planned, one missing activity could delay the completion of the project and this activity was not anticipated. There are many penetration points in a project that if something is not present, the activity (or activities) and possibly the project will be delayed. We have no means or warning of such situations in the traditional project management literature—we do use a beta distribution and place 1/6 probability of this pessimistic activity duration occurring. We need to re-examine the steps used in constructing a project network to reduce the likelihood of pessimistic activity times occurring. We need to fail-safe the activities.
For example, in Critical Chain project network development (using Theory of Constraints [TOC]), network developers use a prerequisite tree to identify obstacles to achieving each intermediate objective (activity). They ask, “What is preventing us from starting this activity?” Numerous obstacles are identified; in most cases, these are items not included on the original network. Then an activity to overcome this obstacle is identified and included in the network. In this manner, the network developers identify and include many “assumed activities” in the project and many connecting arrows (dependencies) that were omitted in the original network. Most networks created in this manner have at least 25 percent more activities (nodes) and are 50 percent denser (more arrows). A quick review of the causes of project failure from the literature review of 40 years of failures shows: techniques of estimating are poorly developed (project completion estimates are usually optimistic); too detailed or too broad activity structure; lack of planning; ineffective scheduling; critical tasks are left off the project plan; and, again, poor planning. All of these “causes of project failure” can be caused by activities (nodes) and missing dependencies (arrows).
A project network should include all of the activities and dependencies required to achieve the goal of the project—legal requirements, purchasing, designing, production, accounting, finance, marketing, sales, personnel, etc. Most networks are used for the design and development stages and do not take a systems perspective to a project. The consequences are that the project may be completed in time (that time shown on the network),