Project Management, as Taught by Eli Goldratt · Lesson 7 of 7
Buffer management, measurements and action
The next leap comes from execution: set every priority by buffer consumption. Two rules settle any contest for a resource, three measurements tell the true status of a project, and the last 10% stops taking forever. Then the actions that start it, and Goldratt's answers to the usual questions.
Buffers as a priority system
The completion and feeding buffers aren’t only protection; they give a robust mechanism for setting priorities, based on which buffer a task’s chain is consuming, and how much of it.
What is buffer consumption? A delay in a critical-chain task is passed on and consumes the completion buffer. Another delay consumes more. A delay in a non-critical task first consumes its feeding buffer; once the feeding buffer is gone, any further delay on that chain consumes the completion buffer.
To track buffers, people must report progress often. Traditionally they report hours invested in the task. But it doesn’t matter how much work has gone in; it matters when the task will be finished. So people report their estimate of when the task they’re working on will be completed.
Two rules for priorities
- A task on a chain that has started consuming the completion buffer always comes before a task on a chain consuming a feeding buffer.
- Among tasks of the same kind, the one whose chain has consumed the greater percentage of its buffer comes first.
Two tasks wait for resource A. Task 1 is on a chain that has consumed 10% of its completion buffer. Task 2 is on a feeding chain that has consumed 50% of its feeding buffer. Which goes first?
- Task 1
- Task 2
Rule 1: completion-buffer consumption always beats feeding-buffer consumption, whatever the percentages.
Two tasks wait for resource A, maybe from different projects. One chain has consumed 10% of its completion buffer; the other, 20% of its completion buffer. Which goes first?
- The 10% one
- The 20% one
Rule 2: same kind of buffer, so the higher percentage consumed goes first.
Priorities now come from the plan, not from the loudest project manager. Goldratt’s simulator changed only one thing: whenever a resource could do two tasks, it chose by these rules.
| Days to complete | 10% | 50% | 90% |
|---|---|---|---|
| Project 2, with buffer management | 140 | 160 | 180 |
| Project 3, with buffer management | 170 | 190 | 210 |
| Each project, before any change | about 315 | about 370 | about 430 |
And a side effect: before, the resources were busy on these three projects for about 370 days. With staggering, buffers and buffer management, there is a 90% chance all projects are done in 210 days. A great deal of capacity is freed for more projects.
Where should the project manager concentrate?
Even so, disruptions can endanger a commitment. It’s the project manager’s job to finish on time no matter what, and that is possible if they know exactly where to focus, and can convince peers and bosses to help with resources or budget. The focus: the task on the chain that is consuming most of the completion buffer.
Three measurements of a project
Traditionally, progress is measured as the percentage of work done against total estimated work. Picture a project where one critical task has a problem. If progress is measured by work done, everyone works on the other available tasks first, because that shows progress. The problem task is dealt with last. That is why the last 10% of a project takes so surprisingly long.
Goldratt’s three measurements:
- Progress: the percentage of the critical chain that is complete. Now a task that stops the critical chain is worth fixing, because nothing else moves the measure.
- Status: the percentage of the completion buffer consumed, relative to the percentage of the critical chain completed. 50% of the chain done with 20% of the buffer used: no concern. 50% done with 80% used: concern.
- Trend: the rate at which the completion buffer is being consumed. The buffer is a third of the lead time, so over any interval, if the buffer is consumed faster than a third of the elapsed time, there’s a problem; slower, and relative safety is growing.
Monday’s project review at Arcadia, three months later.
Project manager 1: “Going very well. 60% of the critical chain complete, only 10% of the buffer used.”
Leo, project 2: “We have a problem. Only 20% complete, 30% of the buffer gone. We’ve found the task eating the buffer, and we need this help…”
Project manager 3: “Back on track. The extra engineer made up the delay: we used only 2 days of buffer in the last two weeks.”
Only actions change reality
- Rebuild each project network around a protected critical chain: review the task dependencies, reschedule for resource dependencies, find the critical chain, halve the estimates, place the buffers, check the completion buffer is a third of the new lead time. Do it with the people who give the estimates, after they have been taught the method.
- Stagger the projects according to a drum, the most loaded resource type. The people who manage the projects must agree on the sequence.
- Put buffer management in place: buffer status on line for everyone; frequent “time to complete” reports; resource managers prioritise by type and percentage of buffer consumed; project managers focus on the tasks consuming most of their buffer; and the three measurements replace percent-of-work-done.
Two refinements for later. After a few projects under critical chain, people stop padding their estimates, because bad multitasking has gone and estimates are no longer commitments. Then halving them again would be a mistake; the rule that remains is buffers are a third of the lead time. And as capacity is freed and more projects come in, a real bottleneck eventually appears. Then make sure it never starves: the resources before it must always see that it has work.
Questions managers ask
“When we bid, should the due date include the buffer?”
- No: quote the critical chain alone to win the bid, and use the buffer as a hidden reserve
- Yes: without it you are unprotected, and you’re still shorter than competitors
The buffer is an integral part of the project.
“Isn’t a more detailed network better for control?”
- Not necessarily: tiny tasks are too uncertain, and hundreds hide the picture
- Yes, always: the more detail, the earlier a problem shows and the more precisely it can be located
Reduce the noise first. Then add detail by nesting: treat parts of chains as sub-projects.
“How does this relate to concurrent engineering?”
- It replaces it, since critical chain also overlaps tasks to save time
- Different jobs: one decides content, the other how tasks are managed
Content and management are separate questions.
Check your understanding
Answer all five. Get four right to complete the course.
1. People should report progress as…
- Hours worked
- Percent of budget used against the plan
- Their estimate of when the task will be completed
- Nothing
What matters is when it finishes.
2. Completion-buffer consumption versus feeding-buffer consumption: which wins?
- Completion buffer, always
- Whichever percentage is higher
- Feeding buffer
- The older task
Rule 1.
3. Why does the last 10% of a project take so long?
- People get tired
- Clients add changes once they see the work nearly done
- Budgets run out
- Measuring percent of work done pushes problem tasks to the end
Measure critical-chain progress instead.
4. 50% of the critical chain is done and 80% of the buffer is used. The project is…
- Fine
- In trouble: buffer use is running far ahead of progress
- Early
- Impossible to judge without a full schedule review
Measurement 2.
5. After a few projects under critical chain, the rule that must still be followed is…
- Halve every estimate
- Double every buffer
- Buffers are a third of the lead time
- No buffers are needed
Estimates lose their padding, so halving them again would be a mistake.