Wednesday, October 03, 2007

Critical chains: a decade later

I first read Eliyahu Goldratt's Critical Chain : A Business Novel in 1998. I was sufficiently intrigued by the critical chain approach to project management that I summarized my notes for an internal Web page at my company in March 1998. Tom von Alten worked for the same company and also wrote up his thoughts on critical chains; we cross-linked our pages to give people two somewhat differing views of the approach.

It's now almost a decade later, and Tom and I have been discussing project management again. We decided to post slightly edited and reformatted versions of our original pages to let you see what we were thinking back then and to provide a reference for those of you who might want to know more. I've integrated my three pages into one long post so that it's easier to find as a whole.




Project Management Revisited: The Theory of Constraints



Eliyahu M. Goldratt's book, Critical Chain, applies the theory of constraints to project management. He implies ~25% improvements in project duration are possible the first time it is applied.

The basic steps




  1. Draw the project plan in PERT chart form; make sure each activity has a time estimate. Assign resources to the steps, and shuffle steps in time until no resource conflicts (i.e., two steps needing to be done at the same time by the same resource) occur. Identify the critical chain (the longest chain of dependent steps, including path and resource dependencies).

  2. Cut the time estimates of each step in the critical path in half (this approximates the median step duration). Add a project buffer at the end of the critical path equal to half the time you cut from the critical path.

  3. For each path which feeds into the critical path (so-called feeding paths), cut the times of the individual tasks in half and place a feeding buffer just before that path feeds into the critical path.

  4. When a person or group is a week away from entering the critical path, send them a reminder. Repeat that reminder at 3 days and 1 day prior to their projected entering of the critical path. When the time comes for them to start a step on the critical path, they are expected to drop whatever else they are doing to focus on the critical path step (this provides a resource buffer by ensuring that the critical path won't have to wait for them to come free).

  5. Set up a daily (one colleague suggested that weekly might be more appropriate) metrics collection and reporting program.


    • For each step in the critical path, capture the number of days until that step hands off to the next step.

    • If that number increases by x, remove x days from the project buffer. If it decreases by x, add x days to the project buffer.

    • Do the same things for each feeding path.

    • Report those numbers daily (weekly), prioritized by those steps which are decreasing the project buffer and then by those which are decreasing a feeding buffer.



This cuts ~25% off the current plan without a change in work content or resources. Future improvements are possible and expected; see the next section for more details.

The five steps of the theory of constraints



These steps restate the above process with more focus on TOC terminology. Any book or paper on the theory of constraints will reference these five steps using Goldratt's unique terminology.


  1. Identify the system's constraint.

    For project management, the constraint is, to a first order approximation, the critical path from the PERT chart. By incorporating resource needs, one arrives at the critical chain, the precise constraint.

  2. Decide how to exploit the system's constraint.

    Make sure it stays busy. First, remove time buffers from the individual steps by using 50%, not 80% or 90%, confidence values for expected durations. Cutting traditionally estimated times in half is the suggested heuristic.

    Next, install feeding buffers to ensure lateness in a non-critical chain step won't impact the critical chain and resource buffers to ensure that resources are available when their contribution is needed to the critical chain. The suggested length of such a resource buffer is half the amount that was removed from the path it's protecting, thus giving a 25% savings on each feeding path.

    Finally, because there is variation (uncertainty) in the estimates for the durations of critical chain steps, install a single project buffer at the end of the project to buffer the scheduled completion date (and the customer) from that uncertainty. Use the same algorithm as for feeding buffers, giving a 25% savings on the overall project duration.

  3. Subordinate everything else to the above decision.

    Don't work on something just because you think you have to keep busy or be more efficient or productive. Ensure you have excess capacity in all the feeding paths to keep the constraint (the critical chain) busy and to catch up from any delays in the feeding path steps.

  4. Elevate the system's constraint.

    Increase its capacity. Add resources in ways that shorten the critical chain; improve processes along the critical chain.

  5. Repeat the process.

    If the constraint has been elevated successfully, it may very well no longer be the real constraint. When the constraint has been elevated, re-assess the current critical chain, which may lead to repositioning and redimensioning buffers.


A change in work philosophy



In the traditional way of managing projects, people are expected to stay busy, and departments are expected to avoid wasting money by eliminating excess capacity. This presumes that having uniformly busy people contributes directly to faster project completion and better business results.

The TOC approach calls for a focus on the system's constraint (the critical chain). The parts of the organization on the critical chain should be running at capacity.

The difference is how one treats work off the critical chain. Those areas should be running explicitly at less than full capacity, because they need reserve capacity to make up for the unavoidable slips which occur due to activations of Murphy's Law.

A change in metrics



The fundamental changes are to stop measuring what percentage of the total work is done, how busy everyone is (area capacity utilizations), and when individual steps should be and are completed.

The fundamental and perhaps only measure becomes how much of the various buffers (project buffer first, then feeder buffers) remains. Changes which reduce those buffers are warning signs; changes which increase them increase the likelihood of completing the project by the scheduled date.

Assumptions



I have listed the assumptions which seem to underlie the critical chain approach to project management here for people to attempt to disconfirm them. Lack of success at such disconfirmation attempts would seem to indicate strength in this approach. I've tried to list them as major points with underlying corollaries capable of being derived from those major points.



  • Traditional business philosophy says improving any parts of the whole provides equivalent benefits to the whole; in reality, a very few parts have an overwhelming contribution to the performance of the whole (much more concentrated even than the "80-20" rule).



    • Monitoring the percentage of work completed causes a focus on tasks which works against on-time completion of the project.

    • Focusing on ensuring that each step completes on time will not ensure the project completes on time.


    • You don't protect the integrity of the project schedule by protecting the integrity of the schedule of each step (by adding safety factors at each step); you must protect the goal of the project schedule by putting in safety factors (time buffers) just in front of the customer (at the end of the project) and just in front of the project's constraint (the critical chain) (i.e., putting feeding buffers where any path in the PERT feeds into the critical chain or where any resource constrain threatens the critical chain).



  • There is excess time in most project schedules (analogous to excess inventory on most production floors) which can be removed by proper focus.


    • We inflate our normal task (step) estimates to

      • account for interruptions and multi-tasking, and to
      • give ourselves an 80% or 90% chance of completing the task on time.



        • Given the skewed right nature of the probability distribution of most task duration estimates, this easily translates into about a 200% inflation in time when compared to the median of the distribution.





    • We often waste safety buffers we give ourselves by


      • not starting a task until any such buffer has gone by (procrastination),


        • Since we don't know until we're well into a task whether there are unfortunate surprises ahead, by waiting to the last minute to start, any surprises we find affect the completion date directly.


      • trying to do multiple tasks simultaneously (multi-tasking), and

      • allowing dependencies between tasks to accumulate delays and waste advances.





  • Local efficiencies and productivities don't count.



    • People don't have to stay busy all the time.

    • People shouldn't stay busy all the time, because then you don't have the excess capacity you need to protect the system constraint.



      • If you don't protect the system constraint (in project management, the critical chain), your overall goal will suffer, even if your metrics at individual steps appear in order.


        • Measuring individual steps, unless they are a part of the constraint, is likely to lead you to do exactly the wrong thing.


      • There is a new work philosophy:


        • If it's too early to start a step (on the PERT chart), do nothing.
        • If it's not too early, work as fast as possible on that step.


          • By having removed the safety from each step, you have nominally only a 50% chance of completing the step on time.







  • Conflicts are a clear indication that someone has made a faulty assumption and not a signal to compromise. (This is a lesson Goldratt claims to have taken from the scientific world into the business and sociological world.)




To find out more



The original article listed several references. I've already listed Critical Chain and some of the others elsewhere. I once pointed to a Robert Newbold article I can no longer find, but there is a long list of papers he and others have written on the subject.

For Tom Tom von Alten's insights on the critical chain approach, see his book review of Critical Chain, which includes snippets of PERT charts showing this more graphically.




That's what I thought almost a decade ago, and you can find out what Tom thought back then, too.

I'm curious: have any of you tried critical chains in your organizations? What have you learned?

Labels: , ,

8 Comments:

Blogger Pinto said...

Hi Bill,

Very interesting reading about this subject. It looks like a very thoughtful and analytical approach to project management. However my recent experience has been quite different.

Lately, I've been applying more of the philosophy, methodology and toolkit associated with the Agile/SCRUM approach to project management. In the IT innovation projects I've been leading, an agile approach has proven more valuable than "traditional" PM approaches. With Agile, projects are structured in short sprints delivering faster releases of the most important customer requirements. Customer feedback is then immediately incorporated into subsequent sprints and the next cycle begins (requirements to release).

This approach is better when dealing with the high degree of uncertainty and risk associated with IT innovation. Compared to my experience with legacy PM approaches, 3 key benefits spring to mind:

1. Customer satisfaction. The customer becomes involved earlier concentrating on requirements, features and functions versus focusing on a complex project timeline typical of longer waterfall approaches (i.e. "are you on schedule").

2. The focus is on action versus planning and analysis. Given that the project is setup in short sprints (these are usually 1-2 weeks in duration), the focus is inherently on activities that provide a customer deliverable.

3. Requirements management is much easier. In an innovation project, there are few standards and past "implementation" experiences. Customers know little about their total requirements until they've seen a release or two. So we can build a better product by getting the key requirements done earlier, delivering this to customers and when they review this, new requirements spring-forward naturally.

There's a lot more to Agile and SCRUM than the above. Info is increasingly available on the web and in books about Agile project management and SCRUM methodology. Like Critical Chain, it will become another methodology that needs to be part of a versatile PM's toolkit. It becomes invaluable on projects that have a high degree of variability and uncertainty.

08 October, 2007 07:06  
Blogger Bill Harris said...

Pinto, thanks for your comments! As I said, my comments are a decade old, and things have changed in the interim. Bringing Agile/SCRUM into the discussion adds a valuable dimension.

I like the benefits you mention with Agile/SCRUM. I wonder if there is room for both approaches, either with one better for one type of project and the other for another or with both used in some synergistic combination.

In a bit of quick Googling, I did find a comment near the end of http://osdir.com/ml/programming.scrum.general/2003-11/msg00086.html that suggests at least one person uses critical chains to estimate projects and SCRUM to manage them.

I wonder if SCRUM is particularly well suited to software projects and something like CC is still more suited to projects with more physical constraints (think construction, hardware engineering, aerospace, and the like).

08 October, 2007 09:00  
Blogger SKI said...

Bill

Thanks for sharing this post, and the fact that it was number four on your "hit parade" for 2007.

I had been thinking of doing something like this as well. I especially like the Letterman-style count down from ten.

For me, CCPM has been very good for all sorts of projects including software development. And custom motorcycle fabrication. I too read the book when it first came out. Then I attended AGI to learn it in June 1998.

In my applications today, I focus more on the transformation of TOC into Constraints Management Model (CMM) and CCPM into Total Matrix Planning. I am after Tony Rizzo to write the definitive book on this transformation of project tools.

Bottom line: yes, TOC and CCPM have evolved. Agile/SCRUM may hold value (I have not studied them at length), but with the significant results of my present approach (based on the aforementioned evolutions), I see no reason to explore another approach.

Thanks again for your thorough post.

-ski

27 December, 2007 13:13  
Blogger Bill Harris said...

Thanks for stopping by, and thanks for your note. It indeed sounds as if you've continued to find this approach of use; it's good to hear from a user of the ideas I write about.

27 December, 2007 14:08  
Blogger Richard Zultner said...

Your summary is fine for single-project critical chain, but the biggest gains are from multi-project critical chain. That is, the application of critical chain to the entire set of projects, not (just) to individual projects.

Interestingly, this is also where the devastating effects of multitasking become clear. Many folks think multitasking on projects is good because it maximizes utilization. But we don't do projects to achieve utilization. With multi-project critical chain, you eliminate multi-tasking to finish more projects, faster. This is true productivity in project work.

15 May, 2008 20:05  
Blogger Bill Harris said...

Richard, thanks for stopping by. While I don't know much about multi-project critical chains, I sense that might make a big contribution. Do you have a quick reference available?

Incidentally, I agree with your multitasking comment. I wrote a short posting called Multitasking last year.

22 May, 2008 20:26  
Blogger Element8 said...

This comment has been removed by a blog administrator.

30 April, 2010 01:56  
Blogger John Davis said...

Excellent post Admin. Now I have to really think about what I say here ;)
I think it's important for people to also think about how powerful an effect comments can have, especially for new bloggers. A comment is both a validation that someone has read the content and connected with it - that can inspire someone to continue on interimmanager, or if too negative, make others consider shutting down.
At any rate, I'll give this more thought but I'm bookmarking this post to share with Friends. Thanks again.

14 July, 2011 00:01  

Post a Comment

<< Home