Tuesday, March 23, 2010

Critical Chain - Is this the answer for project monitoring?

Critical Chain Management

Critical Path: The longest chain of dependent steps, the longest in time (determines the time it would take to finish the project).

Critical Chain: It will be composed of sections that are path dependent and sections that resource dependent.

Critical Chain has been suggested an alternate to PERT and EV as both fail to take into consideration the “Critical Path” and / or “Critical Chain”. The critical path may change as you execute the project, and EV analysis won’t give you any information on this.

Before, we get into details “What each approach can, or cannot provide”, let’s see how “Critical Chain” principle works.

1. Assumption – 1: Persuading the various resources to cut their lead time estimates.
a. What it means is that all projects and their tasks have in-built buffers / safety built-in, in given estimates.

2. Assumption – 2: Eliminating milestones / tollgates; Eliminating completion due dates for individual steps / tasks.
a. It is the end goal, the project completion which should be the driving factor. Individual milestones / tollgates should not drive the project.

3. Assumption – 3: Frequent reporting of expected completion date.
a. The project progress should be monitored and reported frequently to check the deviation(s) in time.

4. There are four kind of buffers in a “Critical Chain”, namely, “Project Buffer”, “Feeder Buffer”, “Resource Buffer”, and “Constraint Buffer”. The idea is to have buffers at critical stages, rather than having those spread across tasks in a project.

5. Measurements should induce the parts to do what is good for the system as a whole.

6. Measurements should direct managers to the point that needs attention.

7. Progress is measured according to the amount of work or investment already done, relative to the amount still to be done.

8. Measurement did not differentiate between work done on the critical path and work done on other paths.

9. It is important to have tasks to be monitored on Critical Path; however, you can’t ignore the tasks on non-critical path. Non-critical path does not mean non-critical tasks. It all means is that those tasks do not fall on the path created by “longest” time period.

10. Dependencies cause delays to accumulate and advances to be wasted.

These truly are some good points, and may be because of this quality the “Critical Chain” has been considered an alternate approach for project monitoring. However, is it truly a unique one? Does it answer all points missed out by EV? Does it address tasks differently than PERT? Is it really a complete approach?

May be, may be not. Let’s find out.

The Critical Chain suggests that resources have their “safety” built-in in their tasks against the uncertainties; probably to a large extent this is true. If that were the case, what it essentially means people knowingly or unknowingly are making use of PERT in order to arrive at estimates. They give the pessimistic (loaded with buffers) effort to stakeholders, and work with optimistic or estimated one (the most probable one). May be this is what leads to “Student’s Effect”, which “Critical Chain” mentions in its literature.

However, safety / buffer in itself is not bad, it’s the wastage of it, or complacency that it brings in, which is bad. Even the “Critical Chain” does not forbid you from taking into consideration buffers (Project / Feeder / Resource / constraint), and quite rightly so. As even “Critical Chain” can’t predict the unpredictable and can’t remove the uncertainties.

The question is, if buffer / safety in itself is not bad, why is it that PERT can’t be an effective methodology / approach? The way I see / interpret it,
• Optimistic – Tasks with no or little buffer, or stretch goals
• Pessimistic – Tasks with built-in safety
• Estimated – Most likely cases

What it means is that “Optimistic” is the one by which project needs to be executed, “Pessimistic” is the reference point, and “Estimated” is the one for you to monitor the progress against, and to be warned against deviations.

What it also means is that you keep the buffer at places, which are critical from “switch over”, “dependency”, “constraints” and “lead time” perspective. As per my information, PERT did not suggest spreading of buffers across tasks; instead those were there for you to assess the “need” for buffer. Where you want to “host” those buffers is your call.

Interestingly, what it also means is that “tollgates” are important from above given attributes perspective; however, tasks / activities within those are flexible, as long as those do not violate the “time / buffer constraint”.

It is also interesting to note that, these buffers actually map to “Feeder”, “Project”, “Constraints”, and “Resource” buffer in “Critical Chain”. And, it is to be noted that these are the first two assumptions / points covered under “Critical Chain”.

The third assumption, or point of “Critical Chain” suggest, frequent monitoring and reporting of project. This understanding has been there for ages, may be since initiation of Project Management practice. However, the key is “frequent”.

What is frequent? Is it monthly, fortnightly, weekly, daily, or hourly? I would say, the project need defines it. If you are at a critical stage of your project / tasks, say UAT, SIT completion, Production Fix, even an hourly update would be justifiable. However, when you are executing a project where there is minimal interference from external factors / environment, even a daily, or weekly reporting can be justified.

So, even in that case there had not been any disagreement between “Critical Chain” and “conventional” project management approach / practice.

Another interesting point that comes out of above points is the emphasis on schedule. In fact, it had been the only point. However, is a measurement revolving around “schedule” enough to monitor the health of a project? What about effort, cost, quality, on one hand, and customer and employee satisfaction, on another? In fact, even if I leave out the soft aspects, still monitoring from effort, cost and quality perspective can’t be ignored.

Therefore, “Measurements are indeed important and should induce the parts to do what is good for the system as a whole. Hence, measurements should direct managers to the point that needs attention”.

If EV was guilty of not providing importance to “Critical Path”, then “Critical Chain” lacks providing due impetus to “Effort”, “Cost” and “Quality”. It assumes that there would not be any variations in planned / actual effort. Everything is limited to schedule. However, there could be cases where in order to meet the schedule more resources are deployed, thereby increasing the effort and cost.

What it also suggests is that EV in itself was not limiting, it is the “usage” of it, which made it limiting. EV had a purpose of providing the information on health of a project from Effort, Schedule, Cost, and Efficiency perspective. Of course, it does not provide information on “Critical Path” and “Buffer”, because it was not designed to monitor those. Just the way “Critical Chain” is not designed to provide progress made in terms of Effort, Work, and Cost.

EV can be interpreted as the progress measured according to the amount of work or investment already done, relative to the amount still to be done. However, that is where it leaves us. The other aspects of “Critical Path”, “Dependency”, “Constraints”, “Lead Time” (taking quality as given) would still need to be considered in conjunction with results of EV analysis, to come up with holistic monitoring of a project.

Even “Critical Chain” suggests monitoring of tasks on both the paths. Therefore, keeping a focus on “Critical Path” may lead you to a potential trap. Hence, whether you make use of Critical Chain, EV or any other approach, one has to take into consideration the tasks along critical and non critical path. May be the intensity and frequency would differ.


In nutshell, “Critical Chain” makes you aware of dependency on resources, or as matter of fact dependency on everything including the tasks dependency. Though, it had been there for ages, may be not so explicitly. The reason being, as I discussed earlier, evaluation of project progress from “switch over”, “dependency”, “constraints” and “lead time” perspective is also critical (assuming quality is given).


Where Critical Chain score over other conventional approaches is through its use of those individual approaches and combine those into one. For example, Critical Chain monitors from "What would it take finish the task?", than on "How much have we accomplished".

It combines the practices of EV, Critical Path and Influence of Dependencies in order to have an approach, which, is sensitive to inefficiencies and “efficiency” required to complete the task / tollgates / project.

The fact that Critical Chain monitors the health of a task / goal from “buffer management” perspective is different from traditional approach, where the focus is on managing the task date. The intent of Critical Chain is to manage the “withdraw from” and “contribution to” buffers. How do you manage it? It is obvious that you have to define date in order to “manage” these buffers; however, it does so with the help of EV, Critical Path and Dependencies.

There is no silver bullet for project monitoring; instead it’s a careful examination of various attributes, from effort, schedule, cost, work, and quality perspective (keeping the soft aspects aside). The buffers had always been there. It had also been maintained that we should not thin out / spread our buffers, instead accumulate and place those before “critical” (four attributes given above) points.

Can we reduce the tendency for having a buffer, yes, if you remove (or reduce) the uncertainty, and / or, there is an incentive for having an “advance” delivery. Incentive would drive what otherwise is difficult to achieve, i.e. “Reduce the wastage of advance delivery”.

Suggested Steps


  • Create a plan / schedule the way you have been doing till now, i.e. WBS, resource allocation, calendar attachment, sequencing, dependencies, fitment to end date, and balancing of resources.

  • Perform a PERT analysis, i.e. get the Pessimistic, Optimistic, and Estimated schedules.

  • Find out the difference between optimistic and pessimistic; this is your project buffer.

  • Take "Optimistic" schedule and make that as you actual schedule, and add the difference in step #3 as the "Project Buffer".

  • Find out the critical "feeds", or feeds which have the potential to cause delay.

  • Take some portion out of Project Buffer, and assign to these feeds, just before it leads to critical path.

  • Perform the step #5 and #6 for any other dependency, i.e. resource (human, s/w, h/w), approvals etc.

  • Set the notification mechanism for "all", wherever there is potential of tapping into buffer (switch over, dependency, constraint, or project / lead time).

  • Set the notification mechanism whenever the task is completed, or is about to get completed, so that subsequent task can be started immediately, or can be scheduled to start on potential start date.

  • If you want a little more breather, or want to ensure extra safety, do the same exercise with "Estimated" schedule (in that project buffer would be the difference between pessimistic and estimated one), and keep that schedule as a reference. Any RED on this would definitely impact your project.

  • Do all of this by keeping in mind that at every stage you are aware of "What has been accomplished", "What is remaining", and "What would it take to accomplish the remaining, with given constraints".

    1.