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 today―the
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 project―exactly
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 5 0%
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.
|