Tip of the Week #110                   Tip Index       Categorized Tip Catalog

Go to the Prior Tip  EMV and Shareholder Value
Go to the Next Tip  Ahead of the Curve by Joseph Ellis
Return to MaxValue Home Page

Critical Chain Project Management, 2nd Edition by Lawrence P. Leach
2005, Artech House, Inc. Norwood, MA, hardcover, 263 pages, $79 list

The critical chain is the sequenced chain activities—often resource-constrained—that determines the time to complete a project. Critical chain project management (CCPM) is likely the most important development in the practice of project management since the 1950s. When there are ample resources, the critical chain is the same as the critical path.  With operable resource constraints the critical chain often jumps paths.

Overall, this is a good book about an important topic in project management. While I recommend using only selected features of the critical chain approach, there many good ideas and recommended practices contained in this book. It is very worthwhile reading for project managers, task managers, project schedulers, and researchers.

Some Background

In January, 2006, Kelvin Rice, a colleague and friend in Denver, gave a presentation  about critical chain project management to our local consultants' lunch group. Upon seeing the simulation demonstration, I came away with heightened appreciation for the importance of resource constraints in determining time to complete projects. Kelvin brought along Larry Leach's book, Critical Chain Project Management. I immediately ordered a copy, which turned out to be the recent 2nd edition.

Despite my misgivings about CCPM, this approach to project scheduling and management continues to accumulate advocates. Please see these prior tips for some details of the method:

• Critical Chain by E. Goldratt
• Project Management in the Fast Lane: Applying the Theory of Constraints by Robert Newbold

In the second reference, I compare and contrast CCPM to Monte Carlo simulation modeling and optimization. Further details are in "Exploiting the Best of Critical Chain and Monte Carlo Simulation" and "Optimizing Project Plan Decisions," chapters 14 and 15 of Risk and Decision Analysis in Projects, 2nd ed.

Highlights from the CCPM Book

Larry Leach is a disciple of Eliyahu Goldratt, and he frequently references the originator—at least primary promoter—of critical chain thinking. I'm reluctant to give Goldratt all the credit for constraints-based reasoning because the methods seem like those long used in queuing and other optimization problems. Queuing theory is about waiting-line problems, such as used in modeling a service facility.  Modeling constraints is standard practice.

Mr. Leach, who holds masters degrees in business and mechanical engineering, works to integrate concepts from theory of constraints (Goldratt), Project Management Institute's PMBOK® Guide, lean manufacturing, and Six Sigma (the last two are manufacturing quality control approaches). He does this reasonably well, building upon and extending the foundation laid by Goldratt.

He also credits system dynamics as the basis for many of the ideas. Indeed, the Goldratt-inspired diagram types, such as the "current reality tree," look much like influence diagrams common in decision analysis and system dynamics.

Some standout sections in the book include:

• The Immutable Laws of Management (Table 1.2, p. 7).  A compilation of humorous sayings, such as "Law 2. One advantage of fuzzy project objectives is that they let you avoid embarrassment in estimating the corresponding costs." Throughout the book, Leach makes comments from his apparently extensive project management and consulting experience. These comments appear honest and well-founded, though sometimes there is a bit too much self-promotion (I'm sometimes guilty of this, also J). The book is clearly a textbook written to accompany his courses.
   
• There are extensive discussions about implementing CCPM in the organization. Leach has done much consulting in this area and has experienced the usual barriers to change.
   
• Leach works to integrate ideas from other areas. Goldratt's theory of constraints (TOC) and critical chain are given the greatest attention. References to other concept areas are numerous though often non-satisfying due to brevity or weak relevance. There are solid bibliographies at the end of most chapters.
   
• A table of steps to check project (model) logic (p. 117).
   
• Two sections about Frequently Asked Questions are very useful in apparent response to frequent confusions and implementation arguments.
   
• Extensive notes about implementation, including an entire chapter (9) to "Implementation Model."

Chapter 10 on Risk-Management Process is particularly unsatisfying. Leach thinks CCPM is sufficient for all internal ("common cause") risks, and leaves project risk management to handle only external risks (and opportunities).  He ignores the value of expected value calculations in assessing duration times and costs and in evaluating risk-mitigation alternatives.  Leach advocates qualitative risk management. He gives scant attention to practices to improve time and cost estimates.

The frequent repetitions, typographical errors (next time, Larry, use spell-check!), and some minor inaccuracies were annoying.

I bought the book primarily to learn about CCPM planning and calculations. Unfortunately, these are mostly left to black-box software. He brushes aside the details with casual references to optimizing network problems. I bought the book partly because a Google search with 'genetic' among keywords which turned up this book. Yet, I was unable to find any reference to genetic algorithms (GA; an optimization method) inside the book. This is disappointing, as GAs are one of the best methods to optimize a project plan.

I continue to maintain that a Monte Carlo simulation model, frequently updated, will provide project and task managers with better information for decisions. Despite my bias, this book was very helpful in understanding CCPM as an alternate method. Even with misgivings, mentioned above, I've very glad to have read Leach's book. The good features far outweighs the bad.

Criticality Index — An Updated View

In re-examining CCPM, I've learned a new insight about the:

criticality index

For an activity:  the probability that an activity lies on the critical chain, obtained from the fraction of trials in a Monte Carlo project simulation where this specific activity or the release of its resource was critical (i.e., contributed to lengthening the project completion time).

For a resource (proposed definition):  the probability that this resource is critical for any part of the project.                         (update cgloss.doc)

activity chain

A sequence of near-contiguous activities with each subsequent activity having a finish-to-start relationship with its predecessor.  With resources for the next activity available, the activity chain is analogous to a relay race.  These chains are sometimes groupings for appearance (few activity lines on the network diagram) or convenience (e.g., performed at one location) rather than for representing project logic.

If simulating a simple activity network with Monte Carlo simulation without constraints, we can find the deterministic critical path for every trial in the simulation.  This is the sequence of activities that determines time to complete.  With resource constraints, the critical path is usually stretched out, and the constraints are either of: activity predecessors (most often, finish-to-start) or resource availability.  A key concept in CCPM is to put buffers at the end of paths that feed into the main, most-critical chain.  Adding feeding buffers will make the feeding path less critical.  However, delaying the start of feeding paths (thus reducing multi-tasking and likelihood of rework due to changes) will make that path more critical.

I see two good situations for calculating criticality indexes:

• Initial planning:
  1) Set up the activity network and define resources.  Model all activity + resource chains to start as soon as possible, and calculate criticality indexes for each chain.  The most-critical chain becomes the project backbone (mainly for illustration), and side chains will become feeding chains.
  2) Plan the project, allowing later starts for feeding chains.
        There are no explicit buffers between activities, at the end of feeding chains, or end of project.
        The buffers are distributions for the time between activities, the end of feeding-chains, and
        the start of the merge point activity (which may be the project due date).
  Buffer periods are adjusted by either changing the tasks, network, resources, or activity start times.  The latter, especially, are the decision variables to optimize.  The solution is obtained by means of Monte Carlo simulation using a genetic algorithm or other optimization technique.
   
• After the project plan is complete and during execution:  Model activity chains to start as currently scheduled.  A feeding buffer is the gap (usually short, hopefully) between the last activity on a feeding chain and the start of the successor (merge) activity or resource on the critical chain.  Re-optimize the decision variables from time-to-time.  During each simulation trial, determine which activities (and attendant resource) delayed project completion.  Use these determinations to calculate the criticality indexes activity (and resource for that activity).
        There may be gaps between activities (intra-chain buffers) if the optimization determines that there there should be.
        The culture should still operate with a relay-race handoff approach to the extent possible.  The main reason
        (that I have thought of) is the cost of an activity either a) starting later or b) needing
        to start earlier than planned.  Goldratt's Critical Chain suggests negotiating with resources (especially
        vendors) to be ready to start work near-immediately on the project in return for a price premium.
        Most resources, whether internal or external, will be reluctant to interrupt or push-back other work.
        Work needs to be scheduled, and there is typically a crash start cost or idle cost if the activity doesn't
        begin as expected.  Planning with buffers inside chains, especially feeding chains, will provide a better solution.

The criticality index is a crucial piece of information for the activity manager.  He or she will use this in evaluating options for crashing the activity (recovering buffer and schedule) and for reallocating spare resources.  Having a gap (feeding buffer) at the end of a feeding chain should do its job: ensuring, with high confidence, that the feeding chain does not delay the project.

I have experimented with CCPM modeling approaches.  Discrete-event simulation seems most appropriate modeling approach:  Time advances to the next event in the system model.  Events include activity starts (and resource assignments) and activity finishes (and resource releases).  Project risks and uncertainties would be included in submodels of activity completion.  It seems best (easier) to back-solve for critical chain activities (and their resources) rather than by trying to solve as the activity network is forward-solved.

What Defines the Project Plan Network?

With CCPM, criticality can jump between paths.  It's simple like a critical path method solution, where there is clearly one critical path.  The CP defines the project backbone, and off-critical paths merge into the CP.  With critical chain, critical constraints jumps paths and the project appears in disarray.

Part of the confusion is due to over what makes a path.  A natural diagramming approach is to group contiguous activities in a chain sequence.  A typical project diagram shows several to many sequences as horizontal chains. "Feeding chains" will merge into activities along the critical chain.  Optimized activity schedule dates may introduce gaps in these chains, and Monte Carlo simulation will reveal fuzziness in the schedule.  In modeling to exploit the best of CCPM and Monte Carlo simulation, several points are key:

1. The activities network is somewhat amorphous.  The sequence depends upon activity completion times and the scheduling rules.
2. Assigning resources to activities can be simple to complex.  Perhaps the simplest rule is to schedule the next activity start to be for the activity that next has all its predecessors complete and has the resource available.  That is, a resource is assigned next to the task that uses it and is ready to start.
         The 'early-starts' practice is often detrimental, and the model should include a penalty for the time to make the handoff to the successor activity(ies).
   A more-advanced scheduling algorithm would "look ahead" to determine the optimal activity to begin next.  For example, it might be preferable for the resource to be idle awhile and wait to perform a short activity instead of committing to the long-activity that could start now.
3. I suggest laying out the activity network map to have a visually-pleasing arrangement, based upon criticality indexes and chains of nearly contiguous activities.  This diagram is important in assisting the intuition of project team members and other stakeholders.

—John Schuyler, Jan. 2006.  Revised 1/24/06

Copyright © 2006 by John R. Schuyler. All rights reserved. Permission to copy with reproduction of this notice.