In his 1997 work of fiction, Dr. E. M. Goldratt introduced the Critical Chain concept. The book’s publication triggered a seemingly unending discussion regarding the virtues of the Critical Chain versus those of the Critical Path. The discussions always focused on the one minor distinction between the definitions of Critical Chain and Critical Path, the fact that the definition of a project’s Critical Chain accounts for resource dependencies explicitly, whereas the Critical Path definition does not. This was most unfortunate. The more significant contribution of the Critical Chain model is that it is the first logistical model of projects that facilitates and even popularizes attempts to estimate and manage variation.
The Critical Chain of a project is defined as the longest sequence of dependent events that prevents the project plan from being any shorter. This differs from the popular definition of a Critical Path in that the Critical Chain definition, by stipulating dependent events, opens the door to resource dependencies as well as to precedence dependencies.
The Critical Chain definition is illustrated in the next figure. In that figure, each of the task-bar colors denotes a different skill. Further, for the sake of simplicity, the model in the figure presumes that only one person of each skill set is available.
The Critical Chain includes the tasks denoted by GR10, Blue30, Blue15, and Red15. The sequence of the tasks is determined as much by the limited availability of resources as it is determined by precedence dependencies. For this reason, the tasks in the Critical Chain typically span multiple paths of the project plan, a characteristic that at times creates a certain degree of visual confusion.
A more readily understood representation of the same project plan shows the Critical Chain tasks all at the same (middle) level. This “fishbone” representation (next figure), with each component sequence either above or below the Critical Chain, is most useful when determining where component tolerances are needed.
The Critical Chain model stipulates that a component tolerance is needed wherever a non critical component sequence provides an input for a critical chain task. The component tolerances are indicated by the shorter, blue line segments with round ends.
The commitment duration of the project is represented by the distance from the wall at the left of the figure (which represents the project's start date) to the yellow circle at the right of the figure. The long, blue bar at the right end of the figure denotes the project tolerance.
Notice that in this case the upper component sequence requires a tolerance that “stretches” the Critical Chain. That is, the component tolerance is large enough to create a so-called gap in the Critical Chain of the project. This apparent gap often becomes a point of contention for many managers. But the contention is created more by an insufficient understanding of variation and by a complete lack of understanding of multiproject operations. The latter causes many managers to conclude that all newly defined projects must be started immediately. In fact, within a properly managed multiproject operation, entire projects are scheduled so that they can start well after they are planned. Thus, in such an operation there is no “wall” that would prevent the entire upper sequence of tasks from being moved earlier (to the left), relative to the Critical Chain of the project.
Further, it is worth observing that the concept of a Critical Chain is no less deterministic than the concept of a Critical Path. The very concept of criticality, in fact, is a deterministic concept. Still, the complete Critical Chain model is considerably more useful than the Critical Path model, in large part because it brings with it an explicit reminder of two assumptions that are the foundation of all project models. First, the Critical Chain model assumes that resources work each task at a full level of effort, from start to finish. This runs contrary to the practice of institutionalized multitasking, which today is the most wasteful of management practices, as anyone even remotely aware of queuing theory can verify.
Second, the Critical Chain model assumes that downstream tasks are started as soon as their inputs are available, rather than being started at scheduled times. In other words, the behavior of the resources is event-driven rather than being date-driven, not unlike the behavior of the members of any relay race team.
The Critical Chain model is not the end-all of project models. A skilled statistician with a computer and an appropriately designed Monte Carlo package could do better than the Critical Chain model, but not by much and certainly not with the same minor level of effort needed to construct a Critical Chain project plan.
[So that others also might subscribe to The Project Management Soap Box, please share the following link with friends and colleagues.Subscribe!]
