Business Project Management

Critical Chain (Summary)

by Eliyahu M. Goldratt

Why does adding 'safety time' to every task in a project almost guarantee it will finish late? Because you've just incentivized two of the biggest project-killers: Parkinson's Law (work expands to fill the time available) and Student Syndrome (procrastinating until the last possible minute). The secret isn't more padding—it's getting rid of it.

Individual Safety Buffers Are the Enemy of Speed

Instead of padding each task estimate with a safety margin, the Critical Chain method uses aggressive (50% probability) estimates and pools the saved time into a single, shared 'project buffer' at the end.

A software developer estimates a coding task will take 5-10 days. Traditionally, they'd commit to 10 days. With Critical Chain, they commit to 7 days (the 50/50 estimate) and the 'saved' 3 days are contributed to the overall project buffer, which can be used by any task that genuinely runs into trouble.

Focus on the Resource, Not Just the Task

The true bottleneck in a project is often not the longest sequence of tasks (the critical path), but the sequence of tasks dependent on a constrained resource—the 'critical chain.' Managing this chain is the key to project speed.

In a new product launch, the critical path might be the engineering timeline. But if the company's single expert legal reviewer is needed for multiple, non-sequential tasks, that reviewer is the constraint. The critical chain is the sequence of tasks that depend on the legal expert, and their schedule must be protected above all else.

Multitasking Is a Myth That Kills Productivity

Juggling multiple projects or tasks simultaneously introduces massive delays due to context-switching. The Critical Chain method insists that resources working on the critical chain focus exclusively on that one task until it is complete.

An engineer is assigned to three urgent projects (A, B, C) and spends a day on each in rotation. Each time they switch, they lose time re-familiarizing themselves with the code and project status. If they instead worked on A for three straight days, A would be finished much faster, and the total time for all three projects would also be less due to the elimination of these switching costs.

Your Project Buffer Is a Fever Chart, Not a Cushion

The project buffer isn't just a pool of extra time; it's a powerful management signal. The rate at which the buffer is consumed tells you the health of the project and when to intervene.

If a project is 25% complete but has already used up 50% of its time buffer, it's a 'red' signal requiring immediate management attention. If it's 75% complete and has only used 50% of its buffer, it's 'green' and on track, requiring no intervention. This prevents micromanagement and focuses attention where it's needed most.

Go deeper into these insights in the full book:
Buy on Amazon
Listen to the full audio book with an Audible Free Trial.
As an Amazon Associate, qualifying purchases help support this site.