Critical Chain Method (CCM) in Project Management

I’ve sat through a few CCPM training sessions over the years, and they all have the same shape: compelling theory, impressive case studies from manufacturing plants in the 1990s, and a largely optimistic view of how organisations respond to being asked to change how they estimate, schedule, and measure progress. The critical chain method addresses something real — the systematic inflation of task estimates and the predictable waste of safety margin — but the gap between Goldratt’s model and a typical project environment is wider than the training materials suggest.

What Is the Critical Chain Method?

Goldratt was a physicist who became a management consultant. His 1997 novel Critical Chain — a novel, not a textbook — made the case that projects fail not because of bad engineering or bad planning but because of predictable human behaviour around time estimates. The critical chain method (CCM / CCPM) is the scheduling approach that came out of that argument.

When people estimate task durations, they build in a safety margin. A task that might take 5 days gets estimated at 8 or 10. Nobody wants to miss a deadline. Those individual buffers accumulate across every task in the schedule — and then Parkinson’s Law consumes them. Work expands to fill the time available. The buffer gets absorbed through late starts, over-refinement, or the simple reluctance to report something finished ahead of schedule. The project ends up late despite every task having a safety margin built in.

Goldratt’s answer was to strip the safety margins out of individual tasks — cut durations to around 50% of the padded estimate — and pool the recovered time into a buffer at the end of the chain. Track the buffer, not the task dates. The schedule gets shorter, the buffer absorbs real uncertainty, and the question changes from “is this task on time?” to “how much of the buffer has gone?”

The Problem CCPM Was Designed to Solve

Goldratt’s position was that most project delay isn’t bad luck. It’s the same few behaviours, appearing in the same way, on project after project.

Student syndrome

Given 10 days to complete a 5-day task, people don’t start on day one. They start on day six. The safety margin is wasted before the work begins. If anything goes wrong in the last four days — which is when they’re actually working — the task runs late despite having had plenty of buffer.

Parkinson’s Law

Even when people start on time, work expands. A task estimated at 10 days that actually takes 6 is rarely reported done on day 6. The remaining time gets absorbed — extra review cycles, documentation that could have waited, meetings that happen because there’s time for them. I asked a project manager once why an activity that finished Thursday wasn’t reported until Monday. He said nobody wanted to set a precedent for being done early. That’s Parkinson’s Law in one sentence.

Bad multitasking

When resources are split across multiple concurrent tasks, context switching destroys efficiency — not just for developers but for any specialist who’s being pulled in three directions. I’ve seen commissioning engineers on construction programmes who were nominally assigned to four workstreams simultaneously and were actually productive on none of them. CCPM handles this by building the schedule around the constraint rather than ignoring it. One task at a time on the critical chain. It sounds obvious. It conflicts with how most organisations actually assign people to work.

The Three Buffer Types in Critical Chain Method

Where the safety margin goes — and how it’s managed — is the core of the method. CCPM uses three types of buffer, each sitting in a different position in the network.

Project buffer

The project buffer sits at the end of the critical chain, between the last task and the project finish milestone. It absorbs delays that propagate along the critical chain. If the critical chain runs 10 days late, those 10 days come out of the project buffer rather than moving the finish date — unless the buffer runs out.

The project buffer is typically sized at 50% of the total safety margin removed from the critical chain tasks. If the original padded estimates totalled 100 days and the CCPM durations are 50 days, the project buffer would be around 25 days. The exact sizing method varies — some practitioners use statistical methods; most use the 50% rule. I’ve seen programmes where the project buffer was set by negotiation rather than calculation, which rather defeats the purpose.

Feeding buffers

Non-critical chains feed into the critical chain at merge points. A feeding buffer sits between the end of each non-critical chain and the point where it joins the critical chain. It protects the critical chain from delays on non-critical paths — similar in purpose to float in CPM, but explicitly managed and visible rather than implicit.

Float in CPM is a property of the schedule that many project managers never actively manage. A feeding buffer in CCPM is a named, measured quantity that gets reviewed at every status update. When a feeding buffer is 50% consumed, it triggers attention. When it’s 80% consumed, it triggers intervention. The explicit management of the buffer — rather than leaving float to be consumed passively — is where CCPM claims its advantage.

Resource buffers

Resource buffers aren’t time buffers. They’re alerts — advance warnings to key resources that they’ll be needed on a critical chain task soon. In CPM, a resource might not know they’re needed until the day before. A resource buffer gives them notice, typically one or two tasks in advance, so they can be available when the critical chain reaches their task rather than causing a delay by being committed elsewhere.

Critical Chain vs Critical Path

CPM and CCPM both work from the longest path through the network. What they do differently is everything else.

 

	Critical Path Method (CPM)	Critical Chain Method (CCPM)
Longest path basis	Task durations + dependencies	Task durations + dependencies + resource constraints
Safety margin	Embedded in each task estimate	Stripped from tasks, pooled into buffers
Resource conflicts	Resolved separately (levelling)	Resolved as part of critical chain identification
Progress monitoring	Task % complete vs baseline dates	Buffer consumption rate
Task dates	Fixed start/finish dates per task	Tasks start as late as possible; finish dates flexible
Multitasking	Not explicitly addressed	Explicitly discouraged on critical chain

The “as late as possible” scheduling in CCPM is a significant departure from CPM convention. In CPM, activities are usually scheduled to start as early as possible (Early Start). In CCPM, activities start as late as possible to reduce the risk of early completion being wasted (Parkinson’s Law) and to keep resources focused on one task at a time. The schedule looks uncomfortably tight to people used to CPM — less float visibility, more sensitivity to any delay — which is why CCPM advocates have to work hard to get buy-in from project managers who’ve only ever worked with CPM.

For how the critical path method works — including forward/backward pass calculations and float — the critical path method article covers the fundamentals that CCPM builds on.

Implementing the Critical Chain Method

The order matters more than most CCPM guides emphasise. Standard CPM: build the logic network, find the critical path, then level resources as a tidy-up exercise at the end. CCPM: resolve resource conflicts first, then find the critical chain through the resource-constrained network. Getting the sequence wrong means you’re doing CPM with a buffer bolted on, which is not the same thing and doesn’t produce the same results.

Start with the standard activity network. Durations at this stage should be “most likely” estimates — not the padded estimates that normally enter schedules, which is itself a challenge because people don’t easily separate the two.

Add resource assignments and identify conflicts. Where the same resource is needed on concurrent tasks, resolve by sequencing — one task moves. This is where CCPM diverges from standard CPM levelling: the sequence change is deliberate and feeds into critical chain identification rather than being an afterthought.

The critical chain is the longest path through the network accounting for both task dependencies and resource constraints. It’s often longer than the CPM critical path, because resource dependencies add implicit sequencing that doesn’t appear in the logic network. This is the part most CCPM training materials under-explain: the critical chain may look nothing like the critical path once resource conflicts are resolved.

Cut task durations — typically to 50% of the padded original — and insert the three buffer types. Project buffer at the end of the critical chain. Feeding buffers at non-critical chain merge points. Resource buffer alerts before key critical chain tasks.

During execution, monitor buffer consumption rather than task dates. Green, amber, red zones on the project buffer. The ratio of buffer consumed to project completion percentage is the signal: consuming 30% of the buffer when the project is 30% complete is fine; consuming 60% of the buffer when the project is 30% complete is not.

Why Critical Chain Implementations Fail

The first problem hits before the project starts. Cutting task estimates to 50% of the padded value requires people to trust that the project buffer exists and that running over the “official” duration won’t be used against them. That trust requires a genuine cultural shift in how lateness is treated, which is something organisations almost universally overestimate their ability to deliver. The task durations get cut on paper. The actual work doesn’t change. The buffer gets consumed from day one, and nobody quite says why.

Project managers trained on CPM instinctively track task dates. In CCPM there are no fixed completion dates per task — only buffer consumption matters. This sounds simple but it requires a complete change in what a status meeting looks like, what a RAG report contains, and what gets escalated when. A project manager who treats the absence of a task finish date as alarming — and most do — will pressure teams to produce dates, which reintroduces exactly the dynamic CCPM was designed to remove.

Multitasking persisting. CCPM explicitly requires that critical chain resources work on one task at a time. In most organisations, people are assigned to multiple projects and multiple tasks regardless of what the schedule says. Removing multitasking requires either organisational authority or a strong project management office. Without it, the student syndrome and context-switching problems that CCPM was designed to address remain fully intact.

Feeding buffer mismanagement. Feeding buffers are supposed to protect the critical chain from non-critical path delays. If a non-critical chain consumes its entire feeding buffer and starts eating into the critical chain, the project is in trouble. But in practice, feeding buffers are often sized too small, not monitored, or consumed without triggering any escalation. I’ve seen feeding buffers of 2 days on non-critical chains that had 15 days of work — optimism dressed up as methodology.

Single-project CCPM in a multi-project environment. CCPM was designed for single projects. Applying it in an organisation where resources are shared across many projects requires a more complex approach — Goldratt addressed this in later work on multi-project CCPM — but most implementations treat it as a single-project tool. The resource competition between projects undermines the scheduling logic even when the individual project buffers are correctly maintained.

When the Critical Chain Method Actually Helps

CCPM implementations that actually work — not just get adopted and then abandoned after the first scheduling crisis — are genuinely uncommon. The conditions required are narrow: a single project, dedicated resources who aren’t simultaneously working three other things, significant uncertainty in duration estimates, and an organisation willing to stop managing to task dates. Most project environments satisfy one or two of those conditions, not all four.

The method is better suited to projects where:

• Resource contention is a known driver of delays — particularly where the same specialists are needed on multiple sequential tasks and the sequencing of their availability is the real constraint, not the task logic
• Task estimates are demonstrably padded — comparing past estimates to actuals on similar projects usually shows this clearly, and if the project team genuinely doesn’t know whether they pad estimates, that itself is diagnostic
• Project duration matters more than hitting specific milestone dates — CCPM tends to deliver faster overall completion at the cost of less predictable individual task timing, which is a trade that not all clients or sponsors will accept
• The organisation has actual authority to enforce single-tasking on critical chain resources, not just theoretical authority

In construction, manufacturing, and R&D environments where the same specialist resources are sequentially critical — a commissioning engineer who has to move from one system to the next, a quality inspector who holds up multiple workstreams — CCPM’s explicit treatment of resource dependencies can surface a more realistic critical chain than a CPM analysis that treats resource levelling as a post-scheduling adjustment.

CCPM is a better model of how humans actually behave on projects than CPM. CPM treats estimates as accurate and resources as infinitely available. Neither is true. Whether a CCPM schedule is more useful than a CPM schedule depends almost entirely on whether the organisation can manage buffer rather than dates — and in my experience, most can’t maintain that discipline consistently enough for the method to fully deliver what Goldratt described.