Critical Chain Method

Schedule technique · See it on the map

Runnable here

Scheduling around resource limits, removing padding from individual tasks, and pooling that padding into shared buffers.

When to use it

Use it when resource contention, not just task dependency, is what's actually constraining your schedule — the same specialist needed on three chains at once, a single test rig every team wants at the same time — and when individual task estimates are known to carry hidden personal safety margin that's masking the project's real risk rather than managing it.

When to avoid it

Don't use it on a resource-unconstrained schedule where critical path method's simpler float-based view already answers the question — pooling buffers and tracking consumption is real overhead that only pays off once resource contention is a live problem. It also asks a lot of a team culturally: it requires people to submit estimates without their usual personal padding, which needs trust that the padding won't just be cut and never restored elsewhere.

Steps

1. Build the dependency network as in critical path method, but this time also identify every point where the same resource is needed on more than one chain at once.
2. Re-sequence the network to resolve resource conflicts — the same person or resource can't be in two places, so one chain has to wait, changing which chain is actually longest.
3. Strip individual safety margin out of each task's estimate, aiming for a realistic (roughly 50% confidence) duration rather than a padded one, and pool the removed safety into a single project buffer at the end of the critical chain and feeding buffers where a non-critical chain feeds into it.
4. Track progress by buffer consumption rather than by individual task lateness: watch how much of the pooled buffer has been used relative to how much of the critical chain has been completed, and act when consumption is outpacing progress.

What it produces

• A resource-feasible schedule with the true critical chain identified, individual task padding removed, and pooled buffers (project buffer plus feeding buffers) whose consumption rate is the tracking signal — again outside Driftless's current single-estimate task model, since it has no concept of a shared buffer or a feeding chain today.

Common pitfalls

• The safety-stripping step happens without the buffer-pooling step actually landing anywhere the team trusts, so people quietly keep their personal padding anyway — the estimates look reduced on paper but aren't in practice.
• Buffer consumption is tracked but never acted on — the whole point of watching the rate is to trigger intervention before the buffer runs out, and a buffer chart nobody responds to is just a critical path with extra math.
• This gets confused with critical path method because both produce a "the chain" answer — but a critical chain answer that ignores resource contention is just a critical path with the wrong name on it, and float and buffer are not interchangeable concepts.

Worked example

Two workstreams on a lab-equipment installation both need the same certified electrician at the same point in the schedule: wiring the fume hood and wiring the centrifuge bay. Critical path method, ignoring the conflict, would show both chains as independently non-critical. Critical chain method resequences the electrician onto the fume hood first, which makes that chain the true critical chain, strips the padding each task lead had privately added, and places a single project buffer at the end plus a feeding buffer where the centrifuge chain rejoins — tracked afterward by how much of that buffer has burned relative to how far along the chain is.

Where it comes from: Driftless added this technique to its own vocabulary. No PMBOK-6 clause defines it, so none is cited.

Why it is an extension: PMBOK-6's Develop Schedule (6.5) narrative treats it as a schedule technique but 6.5.2's tools-and-techniques bullets never list it the way they list critical path method, so no process here can honestly be said to use it per the edition. The product needs it, so Driftless adds it as an extension rather than folding it silently into the PMBOK-6 vocabulary.