Shared specialist
Two teams both need the same database expert. The board shows the migrations as parallel. The chain sequences them and puts a feeding buffer on the second, so the expert is no longer the invisible reason every date slips.
0/6
Topic 03 · Critical Chain
Roadmaps slip even when every estimate looked generous. The safety was hidden inside the tasks, then spent on late starts, work that grew to fill the time, and people switched across too many initiatives. Critical chain pulls that safety out and puts it where it protects the date.
01
The estimate was not too short. The safety inside it was used up before the surprise arrived.
Student syndrome
People start late because they know the estimate has padding.
Parkinson’s Law
Work expands to fill the days you gave it. A five-day task rarely comes back in three.
Bad multitasking
Switching initiatives costs the focus the estimate assumed you still had.
A person, not a bar
The critical path pretends the senior engineer, the database expert, or the product owner can be in two meetings at once.
Wait
Wait
Work
Work
Work
Work
Work
The estimate was five days, with two days of safety buried inside it. You finish on day 7. The date is missed. The padding was spent before the work started, so the two-day surprise had nowhere to land.
02
The critical path is the longest sequence of tasks. The critical chain is that sequence once the same person cannot do two of them at once.
Critical path: 12 days, if Sam can review the migration and the permissions change in the same week. They cannot.
03
Estimate the focused effort, roughly the time you would bet on half the time. Put the protection at the end of the chain, and where side work joins it.
Each task is padded to feel safe. The plan says day 24, but the safety is spent on late starts and on work that grows to fill the estimate. Nothing is left when the chain slips.
Project buffer
At the end of the critical chain. This is what protects the delivery date.
Feeding buffer
Where a side path merges into the chain, so that side work does not steal the project buffer.
Resource buffer
A warning so the scarce person is ready when the chain needs them. It is not extra days.
04
Once the plan is set, stop asking whether each task hit its original date. Ask whether the buffer is still healthy for how far the chain has moved.
Healthy. Chain 60%. Buffer 30%. Buffer consumption is behind progress. Continue. Do not re-plan every ticket.
05
The usual organisation does not have one project. It has a portfolio, and one scarce person inside all of them. Stagger the starts.
Every initiative looks active. None finishes before day 24, and each switch spends the focus the estimates assumed you still had. The portfolio is late because it was all started.
Two teams both need the same database expert. The board shows the migrations as parallel. The chain sequences them and puts a feeding buffer on the second, so the expert is no longer the invisible reason every date slips.
Tasks were padded so the six-month plan felt safe. Cut them to focused effort, put a project buffer at the end, and stop pulling the team onto three other urgent features. Review the buffer each week. Do not re-plan every slip.
The chain runs through integration and launch, which depend on a few people. Feeding buffers protect those merges. Other squads do not start new feature work until that chain has capacity.
06
Pick a date that matters. Find the people who are on the chain twice. Move the safety into the open.
0/6
5 questions. No timer.