Critical Path vs. Critical Chain

What Critical Path Scheduling Doesn't Account For

The critical path is the longest sequence of dependent tasks in a project schedule, calculated from task durations and logical dependencies alone. The critical chain is the longest sequence of tasks once resource constraints are added to that same calculation — meaning it accounts for the fact that the same people or equipment are often needed by more than one task at the same time. Beyond resources, critical path scheduling also generally assumes that task durations are stable and predictable, that the act of measuring and reporting against the schedule doesn't change how people behave, and that delays stay contained to the task where they originate. Critical chain scheduling is built around the opposite assumptions: that durations vary, that incentives shape behavior, and that a change anywhere in the network can ripple through dependent and resource-linked tasks elsewhere. When none of these factors are in play, the critical path and critical chain are identical. In real, high-stakes projects, they usually aren't, and the critical chain is the more accurate predictor of when a project will actually finish.

Why This Distinction Exists

If you've noticed that project status can look fine for months right up until a delivery date is missed, that pattern is closely related to the distinction covered here — see Why Project Status Stays "On Track" Right Up Until It Isn't for that specific mechanism. This page assumes you're already comparing critical path and critical chain by name, and goes deeper into how and why they differ mechanically.

Critical Path Method (CPM) was developed in the 1950s to schedule projects by mapping task dependencies: which tasks must finish before others can start. CPM calculates the earliest and latest a project can finish by finding the longest chain of dependent tasks — the critical path — and treats every task not on that path as having slack, or float, meaning it can shift in time without affecting the finish date.

CPM's calculation assumes every task can get the people and equipment it needs, whenever it needs them. This assumption is explicit in how the method works, not an oversight critics have identified from outside. A 2026 CPM guide from Quickbase states the limitation plainly: "CPM doesn't actually track resource availability." When a team member is needed on two tasks at once, CPM's own schedule doesn't reflect that conflict — it has to be resolved separately, typically through a follow-on step called resource leveling, which shifts tasks in time to remove the conflict and, in doing so, often extends the schedule beyond what the original critical path showed.

Resource availability is the most commonly discussed gap in CPM, but it isn't the only one. The method also generally assumes three other things that don't hold up well in complex, high-stakes projects:

• That task durations are stable and predictable. CPM uses a single duration estimate per task. It has no built-in way to represent that a task might reasonably take anywhere from three to eight days depending on factors that won't be known until the work starts — scope ambiguity, technical uncertainty, or dependencies on inputs that haven't been finalized.
• That the scheduling mechanism itself doesn't change behavior. CPM treats the schedule as a passive description of the plan. It doesn't account for the fact that how a schedule assigns dates, tracks deadlines, and reports status changes how people actually behave around it — for example, by creating incentives to pad estimates, protect individual commitments, or delay surfacing bad news.
• That changes and delays stay self-contained. CPM calculates a single project timeline at a point in time. It doesn't inherently model how a delay or scope change on one task propagates forward through everything downstream of it, across both task dependencies and shared resources, as the project actually executes.

Critical Chain Project Management (CCPM), introduced by Eliyahu Goldratt in his 1997 book Critical Chain, builds resource constraints directly into the scheduling calculation instead of treating them as a separate correction. A critical chain schedule starts from the same dependency network a critical path schedule would use, then resolves resource conflicts as part of building the schedule itself — so the sequence of tasks that determines the project's finish date already reflects both task dependencies and actual resource availability. CCPM is also built around the opposite assumptions on the other three points above: it treats task duration as a range rather than a single number, it explicitly accounts for how the scheduling and reporting approach shapes behavior (see "Why Task-Level Time Buffers Behave Differently Than People Expect," below), and — in tools built to fully support the method — it's designed to show how a change in one part of the network affects everything connected to it, rather than treating each task's timeline as an isolated calculation.

The Core Mechanical Difference

Why Task-Level Time Buffers Behave Differently Than People Expect

Traditional scheduling pads each task's duration estimate individually to absorb uncertainty — an engineer might be asked how long a task will take and answer with a duration that already includes a safety margin, "just in case." CCPM identifies three behavioral effects that erode this safety margin before it can be used:

• Student syndrome: work on a task tends to start later than it could, because the padding creates the appearance of slack early on, so the task is deprioritized until the deadline is closer.
• Parkinson's Law: work expands to fill the time available, so a padded estimate is often fully consumed even when the task could have finished sooner.
• No handoff credit for early finishes: a task finished early often doesn't start its successor any earlier, because the next resource wasn't expecting to start yet, or because finishing early isn't tracked or rewarded the way finishing late is scrutinized.

The net effect is that padding gets consumed regardless of whether it's needed, task by task, while the project as a whole is no better protected against the delays that do occur.

CCPM's response is to strip the padding out of individual task estimates — using a more aggressive, "focus" duration for each task, representing how long the work takes with full attention and no interruption — and pool the removed time into a single project buffer placed at the end of the schedule (with additional feeding buffers where non-critical chains merge into the critical chain). This does two things at once: it removes the incentive to pad individual estimates, since the padding no longer protects any one person's individual deadline, and it concentrates the organization's real uncertainty into a single, visible, monitored pool of time rather than hundreds of small, invisible ones scattered across individual tasks.

Why Multitasking Specifically Breaks the Critical Path Model

CPM doesn't model what happens when the same person is expected to make progress on two critical tasks at once. In practice, this is resolved by the person splitting attention between them — which introduces a cost the schedule never accounted for. Cognitive psychology research on task-switching, going back to studies by Rogers and Monsell in the 1990s and later work by Rubinstein, Meyer, and Evans, has found that switching between tasks carries a measurable performance cost even when the switch is fully predictable and rehearsed: people are consistently slower on a task immediately after switching to it than when repeating the same task. More recent estimates place the productivity loss from frequent task-switching at 20 to 40 percent, depending on task complexity. With CPM, many task duration estimates implicitly build in the assumption of multitasking, masking the true amount of work and obscuring opportunities for acceleration.

CCPM treats this as a scheduling input, not an unfortunate side effect to manage separately. A resource assigned to a critical chain task is expected to work that task until it's finished or handed off, rather than splitting time across several assignments at once — the method describes this as running a relay race, where the goal is to finish and hand off one baton at a time, not carry several simultaneously.

How Progress Is Monitored Differently

Because CPM tracks progress against planned dates for individual tasks, a project can show every individual task as "on schedule" or "percent complete as expected" right up until a resource conflict or delay surfaces — often close to a deadline, when there's little time left to respond.

CCPM tracks progress by monitoring how much of the project buffer has been consumed relative to how much of the critical chain has been completed. This relationship is typically visualized as a fever chart: a plot comparing percent of buffer used against percent of the critical chain complete, divided into zones (commonly green, yellow, and red) indicating whether the rate of buffer consumption is sustainable. A project can be consuming buffer faster than its progress would justify — a warning sign — well before any individual task is reported "late," because the signal comes from the rate of consumption across the whole chain, not from any single task's status. Fusion Online generates a fever chart automatically at each schedule update, and goes one step further, projecting a "landing zone" that shows the range of likely completion dates given current buffer consumption.

Why Behavior and Change Propagation Matter as Much as Resources

Resource availability gets most of the attention in comparisons between critical path and critical chain, but two other differences matter just as much in practice, particularly in high-stakes projects where scope can shift and task durations genuinely vary.

Incentive alignment. A schedule isn't neutral once people are being measured against it. When individual tasks each carry their own deadline, the natural incentive is to protect that specific deadline — which, as covered above, tends to produce padded estimates, quiet local recoveries, and status reporting that reflects whether a date was hit rather than the underlying health of the work. CCPM's shift to a shared project buffer, monitored collectively, is partly a scheduling mechanism and partly a deliberate change in what behavior gets rewarded: the goal becomes finishing the actual critical work as fast as possible and handing it off, rather than defending an individual task's date. This is why CCPM literature frames execution around a small number of clear priorities rather than a long list of individually-owned deadlines — it's addressing behavior, not just arithmetic.

Change propagation. Critical path scheduling, as a calculation, produces a timeline as of the moment it's run. It doesn't inherently track how a delay or scope change on one task cascades through everything downstream of it — both the tasks that directly depend on it, and other tasks competing for the same resource. In a stable, low-uncertainty project, this rarely matters, because little changes after the plan is set. In a high-stakes project where scope shifts and durations vary — which describes most complex engineering, R&D, and new product development project work — a change on one task can quietly threaten a completion date several steps removed from where the change occurred, in a part of the project nobody is currently watching.

Tools built specifically to support CCPM address this by treating the schedule as something to be actively recalculated as conditions change, not a static plan set once at the start. Fusion Online, for example, includes an Impact Chain view for any task, showing the chain of predecessor or successor tasks — considering both task dependencies and resource contention — that are within a meaningful distance of affecting or being affected by that task, including a "Duration Until Impact" showing how much runway exists before a nearby risk actually becomes a problem for the task in question. Combined with a recurring schedule update cycle (typically weekly, as tasks are updated and the schedule is recalculated), this is intended to surface ripple effects while there's still time to respond to them, rather than discovering the consequence only once it directly delays something visible.

It's worth being precise about scope here: resource-constrained scheduling and buffer management are core to the CCPM methodology itself, as defined by Goldratt. The kind of change-propagation visibility described above — actively showing how a delay ripples through the network — is a property of how a specific tool is engineered, not something guaranteed by critical chain scheduling as a concept alone. A scheduling tool can technically calculate a critical chain without offering this kind of forward-looking visibility into cascading risk.

When Each Method Applies

Critical path scheduling is a reasonable choice when a project is relatively stable and predictable: task durations are well understood, resource availability genuinely isn't a constraint, and the work isn't sensitive to how individual task deadlines shape behavior. In these conditions, the critical path and critical chain calculations tend to produce similar results, and CPM's simpler, more widely-supported tooling is a reasonable default.

Critical chain scheduling is the more accurate model for high-stakes projects where one or more of the opposite conditions hold: task durations carry real variance because scope or technical approach isn't fully settled, key people or equipment are shared across multiple projects or tasks, individual incentives could plausibly work against the project's actual completion goal, or a change in one part of the project could reasonably be expected to affect other parts through dependencies or shared resources. This describes most complex engineering, R&D, pharmaceutical, aerospace, and medical device environments, especially those with multi-project portfolios. Critical chain scheduling doesn't require modeling every resource or every possible dependency to provide benefit — even limiting resource modeling to the small number of genuine organizational bottlenecks can surface conflicts a critical-path-only schedule would miss entirely. See Resource Contention Across Multiple Projects for more on why this specific situation is difficult to manage with visibility tools alone, and The Multitasking Penalty for the underlying cost of splitting people across simultaneous work.

Adopting Fusion Online doesn't require adopting every part of the critical chain methodology at once — this staged path is a specific capability ProChain built, not something the methodology itself defines. See Do You Have to Fully Adopt Critical Chain to Get Value From Fusion Online? for how the scheduling engine and the behavioral methodology can be adopted separately.

Frequently Confused Terms, Defined Precisely

Float (or slack): in CPM, the amount of time a task can be delayed without delaying the project finish date. A task with zero float is on the critical path.

Buffer: in CCPM, a block of time inserted into the schedule — not assigned to any specific task — that exists specifically to absorb variation and protect a completion commitment. Buffers are described in CCPM literature as fundamentally different from slack: slack is unused time within the existing schedule structure, while a buffer is a deliberately created and monitored allowance.

Resource leveling: a scheduling technique used in traditional project management to resolve resource overallocation after an initial schedule is built, typically by shifting non-critical tasks in time. Critical chain scheduling resolves the same kind of resource conflict during the initial schedule calculation, rather than as a separate step afterward.

Focus duration: in CCPM, an aggressive estimate of how long a task takes with full attention and no interruption — deliberately shorter than a traditional padded estimate, because the removed safety margin is relocated to the shared project buffer instead.

Critical chain tasks: the specific tasks that make up the critical chain — analogous to critical path tasks, but determined by both logical dependencies and resource constraints together.

Common Questions

What is the difference between critical path and critical chain?

Critical path scheduling determines a project's timeline using task dependencies only, assuming any needed person or resource will be available exactly when planned. Critical chain scheduling determines the timeline using both task dependencies and actual resource availability, so it accounts for cases where the same person or equipment is needed by more than one task at the same time.

Is critical chain better than critical path?

Critical chain produces a more accurate schedule specifically in environments where people or equipment are shared across multiple tasks or projects — which describes most organizations with specialized skills in limited supply. When resources aren't a real constraint and uncertainty is minimal, the two methods produce similar results.

What is a buffer in project management, and how is it different from slack?

Slack (or float) is unused time that already exists within a critical-path schedule's structure — time a non-critical task could be delayed without affecting the finish date. A buffer is a block of time deliberately added to a critical-chain schedule, separate from any individual task, specifically to absorb variation and protect a completion date. Buffers are monitored directly; slack is simply a byproduct of the schedule's dependency structure.

Does critical chain project management eliminate multitasking entirely?

Critical chain scheduling discourages multitasking specifically on critical chain tasks — a resource assigned to a critical chain task is expected to work it until it's finished or handed off, rather than splitting attention across several assignments. This is a deliberate scheduling rule, based on research showing that task-switching carries a measurable performance cost, not a claim that multitasking never happens anywhere in an organization.

What is a fever chart?

A fever chart is a graph used in critical chain project management that compares how much of a project's buffer has been consumed against how much of the critical chain has been completed. It's typically divided into green, yellow, and red zones indicating whether the current rate of buffer consumption is sustainable, and it can show a schedule risk well before any individual task is reported late.

Does critical path scheduling assume behavior stays constant regardless of how the schedule is used?

Yes, effectively. Critical path scheduling treats the schedule as a neutral output of a calculation, without accounting for how tracking individual task deadlines might shape behavior — for example, encouraging padded estimates or discouraging early disclosure of problems. Critical chain scheduling explicitly addresses this by shifting the unit of accountability from individual task dates to a shared project buffer.

Can a schedule show how a delay in one task affects other, unrelated-looking tasks?

Only if the tool is built to calculate and display that connection. Critical path scheduling generally treats each task's timeline as its own calculation and doesn't automatically surface how a change ripples through dependent and resource-linked tasks elsewhere. This kind of visibility depends on the specific tool, not on critical chain scheduling as a concept alone — Fusion Online's Impact Chain view, for example, shows how much runway exists before a nearby delay would affect a given task, as part of its broader approach to dynamic planning and execution.

The Short Answer

If your project's schedule was built by mapping task dependencies alone, assumes task durations are fixed and known, assumes the schedule itself doesn't influence behavior, and treats each task's timeline as its own isolated calculation, you have a critical path schedule. If your schedule additionally accounts for shared resource constraints, treats task duration as a range rather than a fixed number, is designed around aligning individual behavior with the project's actual completion goal, and can show how a change in one part of the project affects connected work elsewhere, you have a critical chain schedule. The critical chain will usually be the more honest estimate — and in complex, high-stakes environments where scope shifts and people are shared across competing priorities, it's the one more likely to match what actually happens. In execution, critical chain is also more likely to yield better outcomes.