Critical Path vs Critical Chain

Critical path is the default in most scheduling tools and is sufficient for many projects. Critical chain solves specific problems it does not — but at the cost of considerably more complexity.

Quick answer: Critical path finds the longest chain of dependent tasks and assumes the resources to do them are available. Critical chain adds resource contention to that calculation, strips padding out of individual task estimates, and holds the recovered time as visible buffers instead. The two methods can produce different answers on the same project, and the difference is usually resource conflicts that critical path did not see.

The Difference in One Paragraph [IMG]

Both find the constraint that determines the finish date; critical path considers only task dependencies, while critical chain also considers whether the same people are needed in two places at once.

Critical path ignores resources

The critical path method links tasks by dependency and finds the longest chain. It assumes that whenever a task is ready to start, someone is available to do it.

For projects with plentiful resources, that assumption holds. For projects where two parallel streams both need the same specialist, it does not — and the schedule the method produces is optimistic in a way that will not be obvious until delivery.

Critical chain adds resource contention

Critical chain, developed from Theory of Constraints thinking, resolves resource conflicts before identifying the constraint.

If two tasks are scheduled simultaneously and both need the same engineer, critical chain sequences them. The resulting longest chain — accounting for both dependencies and resources — is the critical chain, and it is often longer than the critical path.

Why that changes the answer

A critical path showing an eight-week delivery on a project where one specialist appears on four parallel tasks is not a schedule; it is arithmetic that ignores reality.

Critical chain surfaces that immediately. This is its main practical contribution, and it matters most on resource-constrained projects, which describes most projects in practice.

The Two Methods Compared

How Critical Path Works [IMG]

Considers dependencies Yes Yes Considers resource conflicts No Yes Task estimates Include individual contingency Deliberately aggressive, padding removed Where contingency sits Inside each task Aggregated into visible buffers Buffer types None formally Project buffer, feeding buffers, resource buffers

Primary focus Schedule structure Protecting the delivery date Tool support Universal Limited, often specialist Complexity Moderate High Best for Most projects Resource-constrained, multi-project environments

How Critical Chain Works

Critical path identifies the longest chain of dependent activities, which sets the earliest possible finish date, and calculates how much slack every other task has.

Finding the longest dependent chain

Link every task by what genuinely must precede it, apply durations, and calculate the longest route through the network.

That route is the critical path. Any delay to a task on it moves the finish date directly, which is why those tasks warrant daily attention while others do not.

Float and what it tells you

Float, or slack, is how long a task can slip without affecting the end date. Tasks on the critical path have zero float by definition.

Float is the most actionable output. It tells you where you can absorb a problem and where you cannot, which turns a schedule from a picture into a management tool. Most scheduling tools calculate and recalculate this automatically — Taskzin's timeline view recalculates the critical path when dates change, which matters because the path moves.

Where it breaks down

Two situations. First, resource conflicts: parallel tasks assigned to the same person, which the method cannot see.

Second, padded estimates. If every task carries hidden contingency, the critical path is calculated from inflated durations, and the padding gets consumed anyway — which brings us to critical chain.

How Critical Chain Works Critical chain resolves resource conflicts first, strips contingency out of task estimates, and reinserts it as explicit buffers positioned where they protect the delivery date.

Resource-levelled sequencing

Before finding the constraint, critical chain resolves every case where the same resource is needed simultaneously.

This is a real scheduling exercise, not a note. The output is a sequence that could actually be executed by the people you have, which is a stronger claim than critical path makes.

Stripping padding from tasks

Critical chain assumes individual estimates contain substantial hidden contingency — people estimate at a level they are confident of hitting, not at a realistic median.

It asks for aggressive estimates instead, roughly the duration you would hit half the time, and removes the padding. This is behaviourally difficult and is the part teams find hardest to accept.

Buffers where they can be seen

The removed padding is aggregated into buffers: a project buffer before the delivery date, feeding buffers where non-critical chains join the critical chain, and resource buffers to warn a specialist that they are needed soon.

Aggregating works because not every task overruns. Held individually, contingency is consumed by whichever task it sits in — held collectively, it covers whichever tasks actually need it, and less total contingency is required.

Buffer consumption also becomes the progress metric. If you are halfway through the chain and have used a quarter of the buffer, you are fine; if you have used three-quarters, you are in trouble — and you know it early.

Choosing Between Them [IMG]

Critical path is sufficient for most projects; critical chain earns its complexity where resources are genuinely contended, and its buffer idea can be borrowed without adopting the whole method.

When critical path is enough

Projects with dedicated resources, moderate complexity, and no significant contention between parallel streams.

It is universally supported in tooling, widely understood, and adequate. Adopting critical chain where critical path suffices adds complexity for no gain.

When critical chain earns its complexity

Resource-constrained environments — a few specialists shared across many projects, or a multi-project portfolio where the same people appear everywhere.

This is where critical path is most misleading and critical chain most valuable. It is also common in engineering, professional services and R&D.

Borrowing the buffer idea without the full method

Most teams should do this. Keep critical path scheduling, but stop padding individual tasks and hold one visible project buffer instead.

You get the main behavioural benefit — visible, measurable contingency that is not silently consumed — without resource-levelling every task or adopting specialist tooling. This is the highest-value partial adoption available.

Common Mistakes With Both

The three errors are treating the critical path as fixed, padding individual tasks, and ignoring resource conflicts altogether.

Treating the critical path as fixed

The path moves. A task with three weeks of float can become critical after one delay elsewhere.

Recalculate with every schedule update. Identifying the critical path once at the start and managing it thereafter means you are watching the wrong tasks by month two.

Padding tasks instead of the project

Adding 20 percent to every estimate produces a schedule that is both too long and has no visible contingency.

Each task consumes its own padding — work expands to fill the time available — and you reach the end with nothing left. This is the specific behaviour critical chain was designed to correct, and it is worth correcting regardless of which method you use.

Ignoring resource conflicts entirely

A schedule where the same person is on three simultaneous critical tasks is not a schedule.

Even without full critical chain, check the resource view before committing to dates. Most tools with a workload view will show overallocation, and finding it at planning time costs minutes rather than weeks.