Critical chain and buffers

Move the safety to where it protects

We should protect the completion date of the whole project, not of each task. So: take the safety out of each task and place it at the end of the project, where it protects everything. A simple, obvious concept, Goldratt said, but very easy to go astray, usually by asking the wrong questions.

Wrong question 1: how much safety is in each task?

We could make statistical measurements, but estimates are self-fulfilling prophecies, so we’d be measuring a distorted reality. We could ask the people who gave the estimates, but from their experience there is no slack in them, and we’d conclude there’s barely 10% safety. Both are wrong.

Stick to the original intent: cut every task estimate in half. No one will act as if there’s plenty of time, so Parkinson’s Law and the student syndrome are overcome. And we get close to the net time the task needs, since the safety embedded is probably more than half anyway.

Cutting estimates in half needs cooperation, and that needs two things to be made known:

• A lot of safety is put back into the plan, at the end of the project, to protect against Murphy.
• Management won’t turn the new estimates into commitments. Nobody is required to meet the much shorter estimate.

Wrong question 2: exactly how much safety does the project need?

The exact answer depends on the details of every task’s probability curve, and there’s no way to collect that data; only the general shape is known. Trying to calculate it is a waste of effort.

Once Parkinson’s Law and the student syndrome are neutralised, safety isn’t wasted, gains are passed on, and gains and delays compensate each other. So we don’t need all the safety that was in each task. Aggregate the safety taken from the tasks, and cut it in half.

Finding the critical chain with the five steps

Step 1: identify the constraint. What dictates a project’s lead time? The longest chain of dependent tasks. But careful: the classic critical path is the longest chain of dependent tasks without considering resource contention. When the same resource must do two tasks, one has to wait for the other, which creates a dependency the critical path ignores. The longest chain of dependent tasks, considering both task and resource dependencies, is the critical chain. (Where tasks compete for a resource, the critical chain depends on which one is done first.)

Step 2: exploit it. Safety embedded in critical-chain tasks lengthens the project; wasting it is the opposite of exploiting. So: cut each critical-chain task in half, aggregate the time removed, cut that in half, and place it at the end as the completion buffer. Check: the completion buffer should be about one third of the new lead time of the project.

Step 3: subordinate everything else. Delays in tasks off the critical chain must not delay the critical chain. So aggregate the safety removed from each non-critical chain, cut it in half, and place it where that chain feeds into the critical chain, as a feeding buffer.

Early start or late start?

The argument for starting non-critical tasks as early as possible is more safety. The argument for starting them as late as possible is better return on investment and less multitasking. Feeding buffers settle it: start the feeding chain one feeding buffer before it is needed. It has its protection, and it doesn’t start earlier than necessary. Occasionally a feeding buffer forces a small gap into the critical chain itself; that is fine.

In reality projects are complex, and commercial critical chain software does the scheduling. Still, plan one by hand once, to grasp the reasoning.

How much does it help?

In Goldratt’s three-project simulation, adding critical chain buffers to staggering brought the third project’s 90% completion down to about 240 days, from 425 with staggering alone. The first project was now promised for an ambitious 105 days. Impressive, he said, but not good enough: there was still more than a 50% chance of missing 105 days, and more than a 10% chance of missing it badly. Another breakthrough was needed, and it came from execution, not planning. That is the next lesson.

Check your understanding

Answer all five. Get four right to complete the lesson.

1. Goldratt’s rule for task estimates is to…

• Measure their safety statistically
• Ask the estimators how much safety they added
• Cut them in half
• Leave them unchanged

Both alternatives measure a distorted reality.

2. Cutting estimates in half needs management to make known that…

• The new estimates are not commitments, and safety is put back at the end
• Bonuses depend on them
• Late tasks will be reviewed and the people responsible held to account
• Estimates will be cut again

Without that, nobody will cooperate.

3. The critical chain differs from the critical path because it…

• Is shorter
• Ignores resources
• Includes buffers at the end of each path
• Considers resource dependencies as well as task dependencies

Two tasks for one resource can’t run at once.

4. The completion buffer should be about…

• 10% of the lead time
• One third of the new lead time
• Half of the lead time
• Equal to the critical chain

Half the aggregated safety comes out at about one third.

5. Feeding buffers are placed…

• At the start of the project
• On every task
• Where non-critical chains feed into the critical chain
• At the end, after the completion buffer

They subordinate the feeding chains.