Critical Chain Project Management: Buffers, Not Padding

Most schedule risk conversations end the same way: the sponsor wants two weeks cut, the PM says the estimates are already tight, and everyone quietly knows the "tight" estimates have a few days of safety baked in anyway. Critical chain project management throws out that negotiation entirely. It strips the padding out of every task estimate on purpose, then pools all of it into one buffer that sits in the open where a PM can actually manage it, instead of scattered across a schedule as hidden days nobody is watching.

The direct answer: critical chain project management (CCPM) removes the safety margin from individual task estimates, cuts each one to an aggressive but achievable duration, and moves the removed time into a single project buffer at the end of the chain, plus smaller feeding buffers wherever a parallel chain merges into it. The schedule is built around the critical chain, the longest sequence of dependent tasks once resource contention is resolved, not just once task logic is resolved the way the classic critical path is. Progress is tracked as buffer consumption against chain completion, not as variance on each task's own date.

Critical chain project management pools the safety that used to be hidden in every task estimate into one visible project buffer at the end of the schedule, with smaller feeding buffers where parallel chains merge in. Task estimates get cut to an aggressive, achievable duration, and the schedule tracks buffer consumption against percentage of the chain complete instead of individual task dates. The result is a schedule that gives an early warning when it is genuinely at risk, instead of reading green until the hidden padding runs out.

A real-world result gives a sense of what the method is actually worth: Marris Consulting's aircraft-maintenance case study at Embraer, presented at TOCPA Paris in March 2018, cut Check C maintenance turnaround from ten weeks to five and lifted mechanic productivity more than 30 percent by rebuilding the schedule around a pooled buffer instead of padded task estimates (Marris Consulting, Embraer case study).

What Critical Chain Project Management Actually Removes

CCPM starts by asking every task owner for a 50/50 estimate: a duration the task will beat about half the time, not the 90-percent-confident number most people give when asked "how long will this take." The gap between the two is where the hidden padding lives, and CCPM removes it from the task and does not throw it away.

That removed time gets pooled, typically at 50 percent of what was stripped, into a project buffer placed at the end of the critical chain, before the committed finish date. Where a shorter, parallel chain of tasks feeds into the critical chain, a smaller feeding buffer protects the merge point, so a delay on the feeding chain does not silently eat into the critical chain's own margin. The chain itself is not the classic critical path: it is the longest sequence of dependent tasks once the schedule also accounts for the same people or equipment being needed by more than one task at a time, which resource leveling resolves before the chain is finalized.

Student Syndrome and Parkinson's Law: Why Padding Backfires

Distributed padding fails for two well-documented behavioral reasons, and CCPM is built specifically to route around both.

Student syndrome is the tendency to start a task at the last responsible moment regardless of how much lead time the estimate contains. A task padded to ten days for work that takes six does not get six calm days and four spare; it gets six days of work compressed into the final six days before the deadline, because the extra four days did not feel urgent until they were gone.

Parkinson's Law, in its scheduling form, is the observation that work expands to consume the time allotted to it. A padded estimate does not get finished early and handed back; it gets finished exactly on time, because there was no reason to stop early and no process that rewarded doing so.

Together, these two effects mean that individual task buffer is nearly always consumed, whether or not the task actually needed it. Pooling the buffer breaks the link between one task's psychology and the project's real schedule risk: no single task owner controls the shared project buffer, so there is nothing for student syndrome or Parkinson's Law to quietly absorb.

Critical Chain vs Critical Path

Dimension	Critical Path (CPM)	Critical Chain (CCPM)
What determines the chain	Task dependencies and durations only	Dependencies, durations, and resource contention
Estimate style	Often includes individual, undisclosed padding	Aggressive 50/50 estimate, padding removed
Where buffer sits	Implicit, buried inside each task's duration	Explicit: one project buffer, plus feeding buffers at merges
Resource conflicts	Not resolved by the method itself	Resolved before the chain is finalized
What gets tracked weekly	Percent complete and schedule variance per task	Buffer consumption rate versus percent of chain complete
What "on schedule" means	Each task hitting its own date	Buffer holding relative to chain progress
Best fit	Any dependency network where the longest path needs identifying	Environments where shared people or equipment, not just task logic, drive the schedule

Critical Path: pros and cons. It is universal, built into every scheduling tool without configuration, and easy to explain to a sponsor in one sentence. It says nothing about resource contention, and padded task estimates make its float calculations unreliable exactly when they matter most.

Critical Chain: pros and cons. The pooled buffer resists both student syndrome and Parkinson's Law, and buffer consumption gives an earlier, more honest warning than a schedule that reads green until it suddenly does not. It demands estimating discipline from every task owner and a cultural shift away from treating an early finish as evidence the estimate was padded, which is a harder sell than adopting a new Gantt view.

The diagram below shows where the two buffer types sit relative to the chain.

Why Adoption Is Hard in a Matrix Organization

CCPM's math assumes the critical chain can be fixed once resource contention is resolved for this project. That assumption gets shakier the moment the same specialists sit on several projects at once, which is the normal state in a matrix organization. A chain built on the assumption that the database specialist is available on days 12 through 18 can stop being the critical chain the moment a different project renegotiates that same person's time on day 14, and CCPM's single-project buffer math has no built-in way to see that renegotiation coming.

That does not make CCPM the wrong tool in a matrix org; it means the buffer math has to sit on top of a live, cross-project resource view rather than a one-time leveling pass done at project kickoff. Teams that adopt CCPM without that view tend to see their carefully sized project buffer consumed by resource conflicts the schedule never modeled, and conclude the method does not work, when the actual gap was visibility into contention outside their own project.

Buffer Discipline Still Needs a Clean Baseline

None of the buffer math above means anything if the task network it is built on is already wrong: dangling dependencies, artificial constraints, or padding still hiding in a handful of tasks will throw off both the aggressive estimates and the buffer size calculated from them. The same kind of hidden padding that distorts buffer placement generally is exactly what the free Schedule Health Check flags when you upload a Microsoft Project .mpp file, before you commit to a project buffer sized off numbers that were never real. This sits alongside the rest of the schedule-risk practice on the Onplana blog, from float math to resource contention.

Run the free Schedule Health Check Upload your .mpp or MSPDI export and get a structural audit: hidden padding patterns, dangling tasks, and constraint conflicts that would throw off any project buffer calculated on top of them. No signup required. → Run the Schedule Health Check

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.