Place 20% time buffers around your constraint step, not evenly across all steps
Add 20% time buffers around constraint activities that fail or degrade most frequently under pressure, rather than distributing slack evenly across all workflow steps.
Why This Is a Rule
Buffers placed evenly across a workflow waste slack on steps that don't need it while starving the steps that do. If your constraint is code review and your non-constraint is writing documentation, a uniform 20% buffer on both provides unnecessary cushion for documentation while under-protecting the step that actually fails under pressure.
Goldratt's drum-buffer-rope model concentrates buffers where they matter: before and around the constraint. A time buffer before the constraint ensures the constraint never starves for input (idle constraint = lost throughput forever). A time buffer after the constraint absorbs variability so downstream steps aren't disrupted by constraint output fluctuations.
The 20% figure is a starting heuristic based on project management research — enough to absorb typical variability without creating so much slack that urgency disappears. Adjust based on observed failure frequency: if the constraint fails under pressure more than 30% of the time, increase the buffer.
When This Fires
- Scheduling workflow that includes known bottleneck steps
- Planning sprints or project timelines where one step has high failure/delay risk
- After a constraint step failed or degraded because it ran out of time
- Any planning context where you're deciding how to allocate slack time
Common Failure Mode
Distributing buffer evenly because it feels "fair." Every step gets 20% extra time, which means the constraint gets the same protection as trivial steps. Under pressure, the constraint still fails while trivial steps have unused slack. Fairness is the wrong principle for buffer allocation — system throughput is. Protect the constraint; other steps can absorb their own variability.
The Protocol
(1) Identify your current constraint step (the one that limits overall throughput). (2) Add a 20% time buffer before the constraint (ensures input is ready). (3) Add a 20% time buffer after the constraint (absorbs output variability). (4) Reduce or eliminate buffers on non-constraint steps that rarely fail. (5) Track: does the constraint still fail under pressure? If yes, increase buffer. If the buffer is consistently unused, it's too large — reallocate some to other emerging constraints.