Critical Chain: What Benefits does it Offer?

21 October, 2016

Eli Goldratt is famous for developing his Theory of Constraints. Put simply, every system has a constraint and, if you can identify and reduce that constraint, you will be able to enhance the performance of the system as a whole. When he applied this thinking to project scheduling, he determined that the Critical Path was the constraint we should focus on and his systems perspectives led to what is known as the Critical Chain Method.

If you look at scheduling and estimation, what we try to do is come up with estimates for our tasks that have the best possible chance of being achieved. Goldratt calls these “90% estimates”. In other words, we look for estimates that have a 90% chance of being met. We would like to achieve 100% but, realistically, there are always unknown unknowns that can derail the best planned task.

The problem with this process is that we build contingency reserves into the task estimate implicitly. This would be fine if it was not for human nature. Suppose, for example, that a team member is given a task on Monday and is told it must be finished on Friday. Then suppose that that person gets the work done by Wednesday. The problem is: the work is rarely delivered on Wednesday. Lazy individuals will spend the rest of the week catching up on social media, while more dedicated ones will carry out more testing and polishing to make sure their work is the best it can be. In other words, Parkinson’s Law comes into play – “work expands to fill the time available for its completion”.

In other organizations, the team member will spend the first three days telling everyone who will listen how difficult this task is and then make a start on Thursday morning. S/he will work all night and present the work on the dot of close of business Friday, making sure that the Project Manager can see their exhaustion and dedication. This is called “student syndrome”, after the tendency of certain students to wait until the last minute and then cram for exams.

For the project manager, these behaviours mean that all the task’s contingency gets used up, whether it was needed or not. The only time s/he learns of a change in the task’s duration is when the team member needs extra time. So you get punished if the task runs into serious problems, but there is no reward if the task goes smoothly.

Being aware of human tendencies, Goldratt proposed not using 90% estimates. Instead he asked for 50:50 estimates. The idea being to come up with estimates that would have an even-money chance of completion in that time. Naturally, a 50% estimate will be considerably shorter than a 90% one.

The next step now is to assign the 50:50 estimates to all tasks in the schedule. Then subtract the 50% estimates from the 90% estimates and total the difference for all tasks on a particular path. This is the contingency reserve for that path. Now this is the clever part: remember that the 50:50 estimates have an equal chance of being over-estimated as under-estimated so, on average, over the path, only half the tasks should be over-estimated. So Goldrath tells us to half the contingency figure we have calculated (from the differences between the 50% and 90% estimates) and create a buffer at the end of the path for this contingency.

The buffer at the end of the critical path is called the project buffer, while the buffers at the end of the non-critical paths are called feeder buffers. During the course of the project, the project manager will allocate contingency from the buffers as and when it is needed. This means that team members are given more realistic durations and have to request contingency reserves if things go wrong.

So far, this looks like critical path with explicit contingency. So where does the Critical Chain name come from? During the Sequence Activities process, we are encouraged to ignore resource constraints, in order to highlight areas where work could happen in parallel if we had the resources to do it. This is a useful thing to do because, if the project sponsor desperately wants this finished by a certain date and is willing to throw resources at it, the project manager knows where these extra resources will help. However, when developing the schedule, we need to factor in resource limitations and carry out what is called “resource levelling”. This introduces new dependencies because we often have to carry out tasks that have no connection except that they employ the same resource. It is to emphasize that fact that the schedule has resource constraints included that Goldratt came up with the tem “critical chain” instead of “critical path”.

From a management perspective, all focus goes into the critical chain. People working on the chain are allowed concentrate on their critical tasks. Without distractions, they should be able to dedicate more time to the project and be more productive. This increases the odds of tasks on the critical chain being done on time (on even ahead of schedule).

At the same time, we are advised to schedule non-critical tasks to commence at their late start dates. There are two ideas at work here. The first relates to student syndrome – they are going to start as late as possible anyway, so this might as well be institutionalized. The second relates to resource constraints. The needs of the critical chain take priority, so pushing non-critical tasks back as far as possible will allow them to benefit when resources on the critical chain are freed up.

For Critical Chain to work there needs to be a culture change. Team members should not be punished for requesting contingency. After all, we expect that half of the tasks will need it. Similarly, the project manager will report schedule performance in terms of buffer utilization. For instance, if we are half way through the project and the project buffer is less than 50% used then things are looking good. However, if the buffer utilization is greater than our progress then our estimates need to be revisited.

If your projects tend to run late, the critical chain approach may be worth investigating further.

By Velopi Seamus Collins

© 2017 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital