Charan/ October 13, 2011/ Agile

The buffer penetration line crept up with renewed intensity. Worse, this was the second week it remained in the Red zone. My earlier conversations with the powers that be did not appear to help. Developers were being pulled into higher priority tasks. But now I had data. A week of people unable to work to the plan meant the project was going to be delayed by a month; and we had just kicked off the project. Sigh! … Some time later … “What I like about the fever chart is that it highlights a project is heading into a ditch long before it gets near a ditch.” Did a non-believer just get converted?

The quote just about sums up the power of Fever Charts created using the critical chain project management methodology. Make no mistake, critical chain project planning is no silver bullet. You will still run into all the problems when Murphy strikes. You will still find people are late completing tasks. But you will also find them reporting early task finishes. You will also find an incredibly accurate early warning system at your disposal to predict project delays. You will find yourself taking steps early enough to prevent the project from going into the ditch.

What’s wrong with using earned value or burn-down charts

Earned value cannot predict project failure. Neither can the burn down charts. These measurement systems compare the plan to where we are now. These are lagging indicators. It assumes the plan was correct to being with. But what if it was not? Anyone with a basic stats knowledge knows that there is normal variation in the work that gets completed. Neither the burn down nor the earned value methods tell me what is not a normal variation and when to react. These measurement systems also assume the estimates provided are accurate and ignore task variability. Critical chain, on the other hand, compares project buffer consumed to work completed. If the project is consuming buffers at a greater rate than the project completion rate, the project is in trouble. The upward tick of the buffer penetration into the red zone in the image above shows that the project will be off the rails in the future.

What the heck is buffer management

The power of critical chain planning comes from its use of buffer management. Buffers go by many names – risk contingency, safety, padding or whatever other name you use to protect your project & tasks. Only a foolish project manager will provide estimates with no buffer. If an estimate is provided with a high degree of confidence (say 90%), then there are one of the following scenarios:

1. The task is so routine that task variation is very low. Such tasks are so far and few inbetween that even a novice project manager can sniff them out.
2. The estimator has probably not considered all risks that would blow his/her estimation away. Asking questions like, “What needs to happen for you to meet this estimate?” or “List down all factors that will increase your effort and duration on this task” helps validate the estimate.
3. The estimator has 200% safety built into the estimate

That’s right – 200%. Goldratt did an awesome job of explaining this concept in his book “Critical Chain” – a must read for every project manager. In fact I think it should be part of the PMI certification curriculum. Some project managers I have spoken to have not even heard the term “critical chain”. Pity.

Critical chain strongly recommends the use of buffers. It is the right thing to do. But just as local optimization does not necessarily lead to global optimization, adding safety to every task does not mean the project will be protected, which was the objective of adding buffers to being with. On the contrary, Parkinson’s Law and Student Syndrome will probably kick in and your project will end up late. The right thing to do is to add the buffer right after your last task and before the project complete milestone. That’s the only way to ensure global optimization; a.k.a. ensuring the project end date is protected.

How does this buffer thing work

So how does this buffer management work? In the image below, I have defined just two milestones on the project – an aggressive project end date (APED) and the project end date (PED). The project risk (buffer) is between the APED and the PED. There is a hard date constraint on the PED. I do not manage to the task end dates. The only date I am concerned about is the PED.

Every time a task on the critical chain is late, it will push out the APED. You will need to reduce the buffer size in order to maintain your “Estimate at complete (EAC)” value and/or the project duration. This causes an upward tick of the buffer penetration line. If tasks finish early, the APED will be reeled in and you gain buffer time. This will cause your EAC value to drop. You need to then up your buffer size to maintain your original EAC value and/or your project duration.

As your project progresses, you will find your APED date oscillate, but your PED will be fixed. All other things being equal, and if you have a high trust team, you will find your projects finishing anywhere between 1% to 20% sooner. If you have a team that engages in adding quite a bit of padding, you will find that your projects will complete at least 20% to 30% sooner. I have not done any statistical analysis on these percentages – they are just my gut feel.

Buffer management is like a crystal ball. What other measurement system will highlight that we are at risk of missing the project end date only 10% into the project?