Your schedule may be perfectly correct — and your project will still be late
Critical chain and critical path look similar but drive very different project realities. Understanding the difference changes how you manage projects for good.
2026-05-13 · updated 2026-05-13
The paradox of the well-planned project that still finishes late
You have built a clean schedule. Every task has a duration. Dependencies are mapped. The critical path is identified. And yet, the project slips.
This is one of the most frustrating situations in project management — and one of the most common. It reveals a fundamental limitation of the critical path: it ignores resources.
The critical chain in project management was developed precisely to close this gap. Understanding the difference between these two concepts means understanding why some projects look well-managed on paper yet accumulate delays in practice.
Critical path: what everyone knows (and what it misses)
The critical path, born from the CPM (Critical Path Method) developed in the 1950s, is the longest sequence of tasks in a project. As long as no task in this sequence is delayed, the end date holds.
It is a powerful tool for visualising the logical structure of a project: which tasks must precede others, which tasks can slip without impact (float), and where structural delay risk concentrates.
But the critical path rests on a silent and problematic assumption: resources are infinite and always available.
In practice, this is never the case. An engineering team, a development squad, a quality reviewer — these resources are shared across multiple tasks, often across multiple projects. When two critical path tasks demand the same resource at the same time, one waits. The schedule slips. And the project manager discovers a delay that the critical path never predicted.
The classic trap
A schedule built on the critical path alone can be technically perfect and still produce significant delays — as soon as resources are shared or constrained.
Critical chain: the same question, with real constraints
The critical chain in project management was formalised by Eliyahu Goldratt in his book Critical Chain (1997), applying to projects the principles of the Theory of Constraints he had developed for industrial production.
Definition: what is the critical chain?
The critical chain is the longest sequence of tasks in a project, accounting for both task dependencies and resource constraints.
In practice: if two tasks cannot run in parallel because they share the same resource, the critical chain accounts for this and sequences those tasks accordingly. The true project duration is then driven by this chain — not by the dependency logic alone.
This is an apparently simple difference in definition, with far-reaching consequences.
An example to make the difference concrete
Imagine a project with two parallel tasks: Write the specification (5 days) and Prepare the prototype (4 days), both assigned to the same technical expert.
- Critical path view: the tasks are parallel, the project takes 5 days (the longer one).
- Critical chain view: the expert can only do one task at a time. A choice must be made. The project now takes 9 days — and that is the reality.
The critical path gave you false confidence. The critical chain gives you an honest date.
Comparison: critical path vs critical chain
| Criterion | Critical Path (CPM) | Critical Chain (CCPM) |
|---|---|---|
| Foundation | Task dependencies | Dependencies + resource constraints |
| Resources accounted for | No | Yes |
| Origin | CPM, 1950s | Goldratt, 1997 |
| Safety margins | Embedded in each task | Removed from tasks, consolidated into buffers |
| Tracking indicator | Tasks with zero float | Project buffer consumption |
| Focus of attention | Tasks on the path | Constrained resources (the "bottleneck") |
| Common usage | Initial planning | Planning + active execution management |
| Suited to multi-project | Difficult | Yes, with resource buffers |
CCPM: what the critical chain changes in practice
Critical Chain Project Management (CCPM) goes beyond a better definition of the critical sequence. It also transforms how safety margins are handled.
The problem with individual safety margins
In a traditional schedule, each task includes a safety margin. A 3-day estimate becomes 5 days "just to be safe." This natural behaviour — known as padding — creates several well-documented dysfunctions:
- Parkinson's Law: work expands to fill available time. A task estimated at 5 days will take 5 days, even if 3 would have sufficed.
- Student Syndrome: knowing they have 5 days, the person starts late and has no margin left if something goes wrong.
- Lost early finishes: if a task ends ahead of schedule, the gain is not passed on to the next task. But delays do propagate.
The CCPM solution: the project buffer
CCPM removes individual margins and consolidates them into a single project buffer placed at the end of the critical chain. This buffer is not a hidden reserve — it is a live tracking indicator.
During execution, the focus is not on whether each task is "on time." It is on how much buffer has been consumed relative to actual progress. This is what the Fever Chart visualises: a simple graph that places the project in a green, amber, or red zone based on the balance between progress and margin consumption.
What the buffer reveals
A project that is 40% complete but has consumed 60% of its buffer is in danger — even if every active task appears "on time." The critical chain detects this early. The critical path does not.
Feeding buffers and resource buffers
Beyond the project buffer, CCPM also uses:
- Feeding Buffers: protect the critical chain from delays coming from tasks that feed into it without being part of it.
- Resource Buffers: not time, but alerts — signals that a critical resource will soon need to step in on the critical chain.
Why the critical chain changes multi-project management
In a project portfolio, resources are shared across multiple simultaneous projects. The critical path, calculated project by project, does not reveal these cross-project conflicts. The critical chain makes them explicit.
The same resource — an expert, a team, a machine — can be the constraint on several projects at once. Identifying this bottleneck enables meaningful prioritisation: which project goes first? Which task best protects the most critical delivery date?
This is precisely the level of visibility KairoProject provides: identifying the critical chain for each project, detecting resource conflicts across projects, and helping teams decide where to focus — not just where effort is being spent.
When to use one, the other, or both?
The two methods are not direct opponents — they address different needs.
The critical path remains useful for:
- Structuring the logical flow of a project in the scoping phase
- Communicating clearly about the sequence of deliverables
- Projects with dedicated, non-shared resources
The critical chain becomes essential when:
- Resources are shared across multiple tasks or projects
- Deadline adherence is critical and delays are costly
- The project portfolio requires coherent prioritisation
- The goal is to move from task tracking to genuine decision-driven management
In practice, CCPM incorporates critical path reasoning and extends it. It does not replace it — it corrects it where it is blind.
What this concretely changes for a project manager
Here are the most tangible operational differences between the two approaches:
| Situation | With critical path | With critical chain |
|---|---|---|
| A resource is shared between two tasks | Not detected | Conflict visible, sequencing adjusted |
| A task finishes early | The gain stays inside the task | The gain feeds the buffer and protects the project |
| A task falls behind | The delay propagates | The buffer absorbs it; an alert triggers if a threshold is crossed |
| Primary tracking indicator | % of tasks on time | % of buffer consumed vs % of progress |
| Priority focus for intervention | On the critical path tasks | On the constrained resource (the bottleneck) |