Critical Chain Project Management: Motivation and Overview

Motivation for Critical Chain Project Management

To understand the motivation for critical chain project management, we must look at project management in its most basic form. At its core, it involves making and keeping commitments under uncertainty, accompanied by complexity and interdependency. In most project management environments, making binding commitments is expected in three separate dimensions: 1) schedule or time, 2) resource or budget, and 3) scope, quality, or performance objectives. Falling short of a commitment can result in the project being deemed a failure, with attendant negative consequences to stakeholders. Evidence suggests a high rate of project management failure exists industry-wide. 

Searching for solutions to the problem of high project failure rates yields many valuable contributions. However, a need remains of finding an approach to project management that is effective across diverse domains, and that can be taught to, and successfully applied by, the majority of project managers of average abilities and experience. A technique called Critical Chain has potential in this regard and is backed by over a decade of field testing and refinement. 

Critical Chain takes a different approach to handling risk versus most traditional methods of project management such as critical path project management. Traditionally, the risk associated with a task is handled by the duration estimate of the individual task. Due to the Student Syndrome and Parkinson’s Law, this method has not proven to have the desired effect. By utilizing a pooled or aggregated risk methodology, task durations can be shortened to the task’s average time to completion, and the variability of the tasks in actuality can be planned for and handled via buffers placed in locations that protect the project as a whole. The buffers utilize the safety time removed from individual tasks. However, it has been found that using more aggressive task durations in conjunction with the buffers results in shorter overall project durations and better on-time performance.

The Core Principles Of Critical Chain Scheduling

Pipeline Balance or Elimination of Multitasking 

Pipeline Balance is one part of the Critical Chain Solution. Specifically, in order to ensure that resources are able to dedicate a full level of effort to each task to which they are assigned, the Critical Chain approach to project management insists on the elimination of multitasking to the greatest possible extent. 

To eliminate multitasking, the Critical Chain Solution initiates numerous approaches.

• Resources are instructed to work each assignment to completion before starting a new one, and all other pending assignments are to be queued up in such a manner that any available resources with the minimum prerequisite skills can be assigned as soon as they become available. 
• A system of work prioritization is strictly enforced. 
• To ensure that resources are not overwhelmed with a large backlog of unassigned work, projects are delayed in their start dates until resources are available to take on the new work. 
• Excess capacity is maintained in the resource pool to absorb potential delays in work execution. 

With these changes, work moves swiftly yet smoothly, resulting in shorter cycle time per individual project and the completion of more projects in a given period of time compared to the case in which multitasking is the normal mode of operations. 

Critical Chain Scheduling or Strategic Aggregation of Contingency 

Critical Chain Scheduling or Strategic Aggregation of Contingency is another part of the Critical Chain Solution. 

• Project networks are rebuilt in a way that removes the entire disguised contingency from task or activity durations. 
• Explicit contingency provisions strategically located at key points within the project network or project model replace the disguised contingency. 

The result of this is project models that reflect a shorter overall cycle time while at the same time provide a higher degree of schedule and cost risk protection. 

The following steps describe the Critical Chain planning process: 

• Create a project network that reflects the logical dependencies between activities in a project. 
• Resource requirements are then added (represented in the exhibit by different colors). 
• Task durations are estimated according to the new rule of scheduling activities with no contingency embedded. 
• The entire network is then scheduled to level the workload of each resource to fit within their stipulated capacity. 
• The list of tasks comprising the “Resource Constrained Critical Path” (which is the Critical Chain), is then identified. 
• All remaining tasks are assigned to one or more feeding paths.

For an example, see the yellow outlined sequence of tasks in Figure 3 and the yellow filled-in boxes in Figure 4. In Figure 4, the process is shown in actual software (in this case Aurora-CCPM) to better illustrate what a user will see in actual software. Most software looks similar to that shown in Figure 4, so the idea is to show the concepts with an illustration that is easier to understand and then complement this with an illustration of how the concept appears in actual software. At this point, the network is a very aggressive representation of the schedule, as it has no provisions for uncertainty. The model, at this point, is therefore considered to be too high-risk to be used as the basis for committing to a schedule or budget. 

The final step of creating the single project Critical Chain schedule is to: 

Calculate and insert appropriately sized and located contingency buffers (feeding buffers and a project buffer, see below) designed to render the schedule practically immune to the normal levels of uncertainty one is likely to encounter during execution of the typical project plan. 

An example of a fully protected Critical Chain schedule is illustrated in Figure 5 and Figure 6. 

A generously sized Project Buffer (PB) of approximately 50% more time (than the length of the Critical Chain) is added to the end of the Critical Chain while similarly sized Feeding Buffers (FB) are inserted at the point where each feeding path joins the Critical Chain. The schedule is always re-leveled post buffering and cycle time commitments are made based on the entire schedule, including the buffers.

Note that the Critical Chain, unlike the Critical Path, will cross between logistical pathways as necessary to reflect resource constraints. All other factors being equal, when the 50% buffer sizing rule is used, the Critical Chain schedule is typically approximately 25% shorter than its resource leveled Critical Path equivalent but is substantially better protected from uncertain events due to the explicit use of buffers as a means of containing schedule risk. For purposes of schedule stability, even though feeding paths may overwhelm their buffers and impact the Critical Chain, only under extreme circumstances is the Critical Chain ever allowed to be recalculated during project execution. 

Buffer Management or Real-Time Execution Management using CCPM 

For organizations and projects that are sufficiently large and complex, a real-time execution management system is another essential component of the Critical Chain Project Management solution. Buffer Management provides such an environment, with updated priorities that are consistently applied across the organization on an hourly, daily, or weekly basis depending on the tempo of the decision-making cycle within the environment. In order to support decision-making effectiveness, a set of supporting practices has also been developed to accommodate the prioritization system.

The execution priorities are calculated based on the relationship [ratio] between the amount of buffer depleted and the remaining length of the Critical Chain. To compute these parameters, it is essential that as each task is assigned and completed, feedback is provided regarding starts, completions and partial progress, in terms of estimated time remaining to complete each incomplete task. The traditional ‘percent complete’ by task is not used. 

The Project Buffer is depleted as delays along the Critical Chain accumulate. The remaining length of the Critical Chain is computed as a percentage of its original length and the same is done for the project buffer. These percentages are further compared as a ratio where the larger the value, the better shape the project is in. 

A value greater than 1.0 indicates that the rate of Project Buffer loss or delay accumulation is greater than the rate at which work is being completed along the Critical Chain. At any point during the execution of the project, this would be an indication that the risk of the project going late is substantial and that actions should be taken immediately to recover the schedule and therefore increase the buffer. 

A simple Fever Chart is used to depict the current status of a project. A Red/Yellow/Green convention is used to depict the overall status of each project at regular intervals, and a trend chart is used to project whether or not the project’s status is changing for the better or for the worse. See Figure 7 for an illustration of a Fever Chart.

Although the trend chart is only displayed at the project level, the data behind it is available for all buffers in a given Critical Chain project. Since all tasks feed at least one buffer, it is possible to compute for each task its current impact to all buffers, and therefore, the relative risk it poses to the project as a whole. This information can then be used to establish the priority of every task in the project based on relative current risk to the project. When all projects in an organization have critical chain schedules, the result is the ability to have organization-wide priorities for all project assignments at the task level. When this condition is in place, the organization can be operated as a highly synchronized and adaptive system, resulting in maximized effectiveness and speed of execution.

Critical Chain Project Management (CCPM) Software

Aurora-CCPM is the world’s most powerful enterprise-level, multi-project, critical chain project management software available. In addition, Aurora-CCPM is easy to use and is designed to interface with current project management and enterprise applications. By using sophisticated scheduling software as the underpinnings for Critical Chain reasoning, Aurora-CCPM can be applied to projects encompassing thousands of heavily constrained tasks and requiring hundreds of different kinds of resources. Giving the Critical Chain method such a solid scheduling basis also allows it to more easily handle complex situations including new tasks being inserted during the actual plan execution and other radical changes during execution. Moreover, Aurora-CCPM is designed to work seamlessly in your environment; it can be run from the cloud, hosted on an internal cloud, and run as a standalone application.