The TOC Center

 

Home
Site Directory
About TOCC
Project Management
Supply Chain
Contact Us
Surveys
Search

 

Join our professional site

Already a member? Enter

 

 

 

 

 

 

 

 
Inside Section
How Projects Go Late ] [ Critical Chain ] Case Studies ] Survey Project Managmement ] Survey Getting More from PM ] White Papers ]
 

Critical Chain: Addressing the Cascade Effect

 

We have seen how delays multiply and gains don’t add up with the Cascade Effect, and how this extends projects and contributes to missed delivery dates (for more click here). It is also apparent that the conventional methods (more precise data, cross-functional teams, and better task discipline) are ineffective at dealing with this reality. So what can be done to address the situation, and bring our projects back on track?

 

Eli Goldratt's novel, Critical Chain, opened the door to a re-thinking of project management and introduced Critical Chain. Critical Chain Project Management has three major elements or steps:

 

Step 1- Creating reliable project plans

 

The first step is creating complete, realistic, and optimized project plans. For years, this has been driven by PERT/ CPM (critical path method), which sought to identify and focus on the longest chain of sequential activities as the key to reducing and managing project duration. Since it was developed more than 50 years ago, this insight has been very powerful, enabling a significant advance in project performance.

 

At the same time it did not address a factor that has become increasingly important todaythe impact of scarce resources. Many project managers have felt this for some time, but it has become increasingly acute as the demands of technology and the loads on resources have increased while timelines have contracted. It is a common joke that to arrive at a feasible delivery date, one would first identify the critical path and then multiply it, or add significant time to it. During execution many project managers would report that the critical path had shifted―the result, in most instances, of resource contention.

Critical Chain (CCPM) takes into account resource contention along with task dependencies to determine the longest "chain" in the project. In the example below, the critical path of the project is the task dependencies A1-B-D, clearly a delay on any o f these tasks will delay the project. But since the same resource, A, is required to perform tow task in the same time window this is not feasible in reality. CCPM considers this and addresses it by leveling project plans as above. The resource A now creates a new longest chain which cuts across different legs of the projectexactly what project managers have been seeing in reality for years. Efforts to optimize project durations now can be focused not only on the task dependencies, but also on the critical resources contributing to the Critical Chain.

Improving the reliability of project plans also demands addressing uncertainty. The conventional approach has been to estimate task times conservatively in the event of variation in the work involved. This safety time is largely lost due to the student syndrome/ Parkinson's law. (see the Cascade Effect for more)

The second aspect of achieving reliable project plans is providing for uncertainty. The conventional approach has been to add time (a buffer) to each task duration in the event of variation in the work involved. This added time is largely squandered by the student syndrome/ Parkinson’s Law , and it is very difficult for anyone to see how long a task is actually taking.

To provide for uncertainty, CCPM moves the safety from the tasks into two strategic places (buffers), where protection is most needed. The first is at the end of the project, between the last task on the CC, and the project delivery date to protect the due date against uncertainty on the CC tasks. The second is at each point where a feeding chain of activities intersects the CC. Here it is essential to stop delays on other chains from cascading onto the critical chain. The result is a project plan that is both aggressive, and still realistic in light of uncertainty (due to the buffers).

Step 2- Pipelining to consider cross-project demands

Most organizations today operate in multi-project environments where resources are shared between projects. So arriving at sound project plans in isolation is insufficient to resolve all the possible contentions between resources. Once realistic project plans are created it is essential to level load the pipeline based on the critical or constraint resources, before reliable delivery dates can be determined.

CCPM takes the individual project plans and staggers them according to the capacities of the constraints. This smoothes the load on these resources insuring that plans will not be based on unrealistic overloads from the start. This step also minimizes the likelihood of multi-tasking, and spreads out the naturally available spare capacity of resources to reduce the likelihood of delays propagating across projects.

As new projects are considered or delivery dates estimated, it is essential to evaluate how new commitments will be impacted by existing work. Many have experienced the situation where adding work to the pipeline reduces the overall output and lengthens the delays on all projects. Pipelining in this way insures that cross-project influences are evaluated and commitments made with confidence.

Step 3- Buffer Driven Task Priorities

While Critical Chain project plans, and pipelining are significant breakthroughs, what makes CCPM work more than anything is buffer driven task priorities. Level loaded schedules with buffers provide for a plan that is feasible. But as we know, as soon as the project starts (and sometimes before!) things will change. These changes will wreak havoc with our leveled schedules. The nice smooth loads will suddenly stack up into peaks and valleys of work, as “uncertainty happens.”

The two diagrams above show how a smoothly loaded plan is turned into peaks and valleys of work as a result of variability. While the plan in total is still feasible, because the total work was loaded according to capacity, the peaks of work that now exist mean that some tasks will have to wait while others are done.

These pictures highlight the need for our buffers—they exist to absorb the impacts of such delays. Since every task in a project plan has at least one downstream buffer (either the project or a feeding buffer), a delay on any task, will show up as a penetration into a buffer. In the diagram, the first task took longer than expected to complete, due to an unforeseen problem. Immediately the delay shows itself as a penetration into the buffer. By monitoring the buffers it is readily apparent, very early on that a project is at-risk, and corrective action can be initiated. 

In terms of priorities, the buffers also serve to establish the relative importance of each task. The percentage of buffer penetrated is compared to the percentage of work completed on that chain to establish the relative “buffer burn-rate.” Obviously a buffer penetrated by 50% with only 5% of the work completed on that chain is much worse than a 50% penetration with 95% of the work completed. Since each task feeds a buffer, the status (buffer burn-rate) can be used to determine which tasks should have priority. Resources with more than one task to do at one point in time can readily see which is the most urgent. The work can literally be “colored” green, yellow, and red based on the buffer burn-rates. This means that not only is it easy to establish within and across projects the relative priority of tasks, but that this can be done by the resources themselves. Driving this decision down to the lowest levels of the organization insures that the right decisions are made by those closest to the work—with no management intervention required.

The impact of this step on projects is profound. The inefficiency of multi-tasking is greatly reduced because priorities are clear and won’t be changed simply because a PM is playing the “squeaky wheel.” Because priorities are set correctly the first time by the people themselves, they are not likely to need re-prioritization, eliminating perhaps the most common complaint of project resources—that priorities are always shifting. And finally PM’s and other managers can readily see if people are working on the right things, so there is no loss of control in empowering the teams.

The real proof of course is in the results being achieved from deploying CCPM. Organizations in a broad array of industries and project applications are universally reducing project lead times by 25-50%, maintaining on-time delivery near 100%, and increasing their overall project output by 30-60%, without adding resources or cost. TOCC clients claim that they achieve full payback on the cost of implementation of CCPM within 4 to 9 months of the start of implementation.

Click here for more on implementing CCPM.

 

   

 
©2002 The TOC Center, Inc. 6121 Washington St Gurnee, IL 60031 Phone: 847-625-8775