Structured edition
Critical Chain
by Eliyahu M. Goldratt
Faroa rebuilt the whole book as 11 concepts you read in order, at the depth you choose. The first concept is free to read in full - a 5-minute read.
Overview
Most projects finish late, over budget, and under scope. Goldratt argues the cause is not bad execution but bad thinking about time, resources, and uncertainty.
Goldratt built his reputation dismantling factory-floor assumptions with the Theory of Constraints. Here he turns that lens on project management, and the diagnosis is equally uncomfortable.
- Padding estimates individually makes the whole project slower, not safer
- Multitasking feels productive while quietly destroying throughput
- Local optimizations at each task erode the schedule for everyone else
- The critical path ignores the one thing that actually limits progress: shared resources
A novel as a vehicle
Goldratt delivers these ideas through a business novel. A professor and his MBA students work through a real project crisis together, so the reasoning unfolds as discovery rather than lecture.
Insight arrives through conflict, not chapter headings.
What lies ahead
The concepts ahead move from diagnosing hidden waste, to locating the true constraint, to protecting the whole project with a shared buffer rather than padding every task. Each idea builds on the last.
What is inside
The Project Problem
- 01Why Projects Always Run LateStrip safety buffers from individual task estimates and pool them into a shared project reserve that protects the whole sequenceFree, in full
- 02Student Syndrome and Parkinson's LawStrip safety from individual task estimates and pool it into a single project-end buffer where it stays visible and manageable.
- 03The Multitasking IllusionSequence your open tasks and finish each before starting the next, even under pressure to appear busy on all fronts.
- 04Local Optimization Versus System PerformanceFind your system's real constraint before changing anything else, because all other improvements depend on that answer.
The Critical Chain Solution
- 05Identifying the Critical ChainFind resource conflicts first, then longest path: that sequence, not the critical path, is what you actually manage.
- 06Stripping Safety from Tasks and Pooling ItDemand honest median estimates for every task and strip personal safety padding before building your schedule.
- 07Project Buffer and Feeding BuffersStrip safety from individual tasks and pool it into explicit project and feeding buffers rather than letting it hide inside estimates.
- 08Resource Buffers and Drum ResourcesIdentify your drum resource before the project starts and make its queue the first escalation priority.
Making It Stick
- 09Buffer Management as a Control SystemDivide your project buffer into green, yellow, and red zones and match your response level to the zone, not to individual task lateness.
- 10The Full-Kit DisciplineBefore starting any task, confirm that every input it needs is either in hand or committed to a firm date.
- 11Changing the Measurement CultureReplace local efficiency metrics with measures tied to whole-system throughput before adding any new tracking layer.
Concept 01 of 11
Why Projects Always Run Late
Every project carries hidden time-traps baked into the way estimates are made and work gets scheduled, long before the first task begins.
The Estimation Trap
People padding task estimates is the first link in a chain of delays. Each person, protecting themselves from blame, inflates their honest guess with a private safety buffer.
That padding should make projects finish early. Yet they almost never do. Something consumes every buffer before it can help.
Why Safety Time Vanishes
Three forces drain the hidden cushion before it reaches the deadline. Goldratt treats each as a structural flaw, not a personality failure.
- Student syndrome: work expands to fill the time allocated, so teams start late and spend their buffer catching up
- Parkinson's Law: a task finished early is rarely reported early; the spare time gets quietly absorbed
- Multitasking penalty: jumping between tasks fragments attention, stretches every job, and erases the gains that buffers were meant to protect
Together these forces mean that even generous individual buffers produce chronic lateness at the project level.
A Day in Any Office
Imagine a developer who estimates a feature at five days but genuinely believes three days is enough. The two extra days are her private safety net. She starts on day three, runs into a late-arriving requirement on day four, and delivers exactly on day five. The buffer was used, not saved.
One task done, zero time banked.
The One Shift That Changes Everything
Strip buffers out of individual tasks and pool them at the end of the project as a shared reserve. This project buffer absorbs genuine surprises without triggering a cascading delay.
The Classic Mistake
Managers who see padded estimates often demand cuts without removing the pressures that caused the padding. Workers simply hide the buffer more creatively, and the project still runs late.
The Sequence That Creates Lateness
- Estimate inflation: Each contributor adds a private safety margin, often doubling the honest duration.
- Late start: Student syndrome kicks in: with ample time, starting now feels unnecessary.
- Multitasking interrupt: A second project grabs attention mid-task, breaking flow and stretching elapsed time.
- Buffer absorbed: The task finishes close to its padded deadline; spare time is not passed forward.
- Downstream cascade: The next task in sequence gets a late handoff with no remaining cushion to absorb it.
The cascade means early tasks waste their buffers individually while late tasks inherit all the pain.
Two Projects, One Pattern
Compare two teams tackling similar work. One keeps buffers inside tasks; the other strips them out and pools a shared reserve.
| Approach | How buffers work | Typical outcome |
|---|---|---|
| Traditional scheduling | Buffer embedded in each task estimate | Each task finishes near its padded date; delays accumulate; project is late |
| Pooled buffer (Critical Chain) | Tasks at aggressive estimates; buffer placed at project end | Early finishes donate time to the pool; late tasks draw from it; project more often on time |
The pooled approach does not remove uncertainty; it moves protection to where it can actually be used.
When This Pattern Holds and When It Bends
- Critical chain
- The longest sequence of dependent tasks and resources, the true constraint on when a project ends.
- Feeding buffer
- A time reserve placed before a non-critical task joins the critical chain, protecting the main sequence.
- Resource contention
- Two or more tasks needing the same person or machine simultaneously, a frequent hidden cause of delay.
The pattern holds strongly when tasks are sequential and resource-dependent. It weakens when work is highly parallel with few handoffs, or when external dependencies dominate.
Putting the Insight to Work
- Surface honest estimates: Ask contributors for the median realistic duration, not the safe worst-case.
- Remove embedded buffers: Shorten individual task estimates and move the aggregate safety to a shared project buffer.
- Identify the critical chain: Map task and resource dependencies together to find the true longest path.
- Place feeding buffers: Protect where non-critical paths meet the critical chain to prevent side branches from stalling the main sequence.
- Track buffer consumption: Monitor how quickly the project buffer is being used; rapid consumption signals a real problem earlier than a deadline does.
The Deeper Mechanism: Asymmetry of Delay
A task can finish early by only so much, but it can finish late by an arbitrarily large amount. This asymmetry means that averaging many task durations always drifts toward lateness at the project level, even when each individual estimate is statistically unbiased.
Early gains vanish. Late overruns compound.
Pooling buffers exploits the one side of this asymmetry that favors the project: when some tasks finish ahead of estimate, the saved time is visible and available rather than silently absorbed.
Edge Cases Worth Knowing
| Situation | Why it is an edge case | Adjusted response |
|---|---|---|
| Highly creative or research tasks | Duration is genuinely unknowable; estimates are fiction | Use time-boxed sprints rather than fixed buffer math |
| Single-resource bottleneck dominates | One person is on every critical task; pooling helps less | Protect that resource first; subordinate all else to their schedule |
| External dependency is the real constraint | A supplier or regulator controls the schedule | Place a buffer before each external handoff, not just at project end |
| Very short projects | Little statistical benefit from pooling a tiny buffer | Focus on removing multitasking rather than buffer restructuring |
Second-Order Effects
Removing embedded buffers changes the social contract around estimates. Workers who once hid safety time must now trust that the shared buffer will protect them. Without that trust, they resist giving honest estimates and the system regresses.
- Management must visibly protect honest estimators from blame when the project buffer is used
- Reporting buffer consumption, not task completion dates, shifts attention to system health over individual performance
- Over time, a history of buffer-consumption data reveals which task types chronically underestimate, enabling better planning
Main Objections and Their Answers
- Objection: cutting estimates demoralizes teams
- Reply: the buffer exists precisely to absorb genuine difficulty; workers are not exposed to punishment for honest durations.
- Objection: clients demand task-level dates
- Reply: feeding buffers can be shown as schedule margins on non-critical paths while the project end date remains protected.
- Objection: multitasking is unavoidable
- Reply: the method demands staggered starts and explicit priority rules; it does not assume multitasking away but attacks it directly.
- Objection: one buffer cannot cover all risks
- Reply: feeding buffers supplement the project buffer at specific merge points; together they address both main-path and branch risk.
The deepest objection is organizational: standard accounting and performance reviews reward individuals who finish on time, not projects that pool risk. Adopting Critical Chain ideas without changing measurement systems produces conflict, not improvement.
More structured editions
Reading something else? Faroa builds a structured edition of any book you name. Start free