What Is the Critical Path in Project Management?

Every project schedule answers one question that everyone actually cares about: when will this be done? And the honest answer comes from a single concept — the critical path. It is the longest chain of dependent tasks in your schedule, and its total duration is the earliest your project can possibly finish.

Most teams ignore the critical path until the project is late, then discover that a task they never watched was quietly controlling everything. That is the wrong order. The critical path is not a report you generate after things go wrong; it is the calculation that tells you which tasks deserve your attention this week and which ones can wait. This guide explains what the critical path is, how to calculate it by hand, what float means, how it relates to PERT and critical chain, and how to use it — with a fully worked example you can reproduce.

Quick Answer: What Is the Critical Path in Project Management?

The critical path is the longest sequence of dependent tasks in a project schedule, from the project’s start to its finish. Because these tasks are linked, the total duration of that chain is the earliest date the project can complete, and every task on it has zero float — meaning any delay to a critical task delays the entire project by exactly that amount.

The critical path method (CPM), the technique used to find it, works by computing the earliest and latest dates each task can start and finish, then identifying the tasks whose earliest and latest dates allow no slack. It was developed in the late 1950s by Morgan R. Walker of DuPont and James E. Kelley Jr. of Remington Rand, and it is now calculated automatically by virtually every serious project scheduling tool.

Why Does the Critical Path Matter?

The critical path matters because it converts a schedule from a collection of tasks into a focused management plan. Without it, every task looks equally urgent and your attention is spread evenly across everything, which in practice means protecting nothing.

With a critical path, three things become clear. First, you know the true project duration, which is the number your stakeholders signed up for. Second, you know which tasks must not slip — the critical ones — and you can protect them with extra attention, resources, and buffer. Third, you know which tasks can slip without hurting the date, because their float tells you exactly how much delay they can absorb.

The consequences of ignoring it are concrete. A task off the critical path with 12 days of float that slips by 3 days is a non-event. The same task on the critical path slipping by 3 days moves the delivery date by 3 days, and every downstream commitment — the launch, the invoice, the customer promise — moves with it. Teams that do not know their critical path discover these relationships at the exact moment they can no longer fix them.

How Do You Calculate the Critical Path?

You calculate the critical path in four steps: list the tasks and their durations, define the dependencies, run a forward pass to find the earliest dates, then run a backward pass to find the latest dates. Tasks whose earliest and latest dates are identical — zero float — form the critical path.

Step 1: List tasks and durations

Start from your work breakdown structure and list every task with a realistic duration estimate. Use historical data, team input, and subject-matter expertise. The durations are assumptions, so the whole analysis is only as good as they are — a bad estimate produces a confident-looking wrong answer.

Step 2: Define the dependencies

Record which tasks depend on which. In the critical path calculation, the dependency type used is almost always finish-to-start: a task’s earliest start is driven by its predecessor’s earliest finish. Missing or wrong dependencies are the most common cause of incorrect critical paths, which is why this step deserves a validation pass with the people doing the work.

Step 3: Forward pass (earliest dates)

The forward pass runs from start to finish. The earliest start (ES) of the first task is zero; its earliest finish (EF) is ES plus duration. For every following task, ES is the largest EF of its predecessors, and EF is ES plus duration. When you finish, the largest EF in the network is the project’s estimated duration.

Step 4: Backward pass (latest dates)

The backward pass runs from finish to start. The latest finish (LF) of the final tasks is the project duration found in the forward pass; their latest start (LS) is LF minus duration. Moving backward, each task’s LF is the smallest LS of its successors, and its LS is LF minus duration. Finally, float equals LF minus EF (equivalently LS minus ES). Tasks with float equal to zero are critical.

Critical Path Calculation: A Worked Example

To make the method concrete, here is a small project with six tasks and two parallel paths. Task A (12 days) feeds C (15 days), which feeds E (10 days). Task B (4 days) feeds D (12 days), which feeds F (7 days). A and B start together; E and F finish the project.

Forward pass. A and B start at zero. A finishes at 12, so C starts at 12 and finishes at 27; E starts at 27 and finishes at 37. B finishes at 4, so D starts at 4 and finishes at 16; F starts at 16 and finishes at 23. The largest EF is 37 (task E), so the project takes 37 days.

Backward pass. The final tasks E and F get LF of 37. E’s LS is 27, so C’s LF is 27 and its LS is 12; A’s LF is 12 and its LS is 0. F’s LS is 30, so D’s LF is 30 and its LS is 18; B’s LF is 18 and its LS is 14.

Float. A, C, and E have zero float — they are the critical path (A → C → E, 37 days). Tasks B, D, and F each have 14 days of float: they can be delayed by up to 14 days before they threaten the finish date.

The practical meaning is striking. The two parallel paths look equal in size, but only one controls the project. If task F slips by 10 days, nobody cares — the date still holds at 37 days. If task C slips by 2 days, the whole project moves to day 39, and every commitment downstream shifts with it. That asymmetry is the entire value of the critical path: it tells you where delay is expensive and where it is free.

What Is Float and Why Does It Matter?

Float (also called slack) is the amount of time a task can be delayed without delaying the project. It is computed as LF minus EF, and it is the number that separates critical tasks from everyone else.

Critical tasks have zero float — there is no give in the chain. Tasks off the critical path have positive float, which is your safety margin and your source of flexibility. When a task slips but stays inside its float, the project date is safe; when a task burns through its float, it joins the critical path and suddenly every day of delay matters.

Float is also the resource reservoir of the schedule. The classic move under deadline pressure is to pull people off a task with large float and put them onto a critical task, because the float task can absorb the delay. That is exactly the leverage the critical path provides: you are always trading float you have for delay you cannot afford.

There is an important subtlety: a project can have total float on the critical path itself. If a task on the critical path must wait for a fixed external event — say, testing cannot start until sunrise on a scheduled date — the waiting time is real but it is not recoverable float. That delay is called critical path drag, the amount by which each critical activity extends the project, and it is why you attack the critical path by shortening its activities, not by waiting.

Can a Project Have More Than One Critical Path?

Yes. A project can have several critical paths, and it can also have near-critical paths that become critical as float burns. Multiple critical paths happen when two parallel chains have exactly the same total duration; both must then be managed with equal urgency, because delaying either delays the project.

Near-critical paths are the subtler danger. A path with 3 days of float is not critical today, but a single slip can make it critical tomorrow, at which point you suddenly have two chains demanding attention. Mature teams track “near-critical” tasks — those with float below a defined threshold, such as 10% of project duration — and treat them as almost critical. This is why the critical path is not a static line you find once: it is a live calculation you refresh every week as actual progress replaces estimates.

How Does the Critical Path Differ From PERT and Critical Chain?

The critical path method is often confused with two related techniques, and the differences matter for how you use them.

PERT (Program Evaluation and Review Technique) was developed around the same time as CPM for the U.S. Navy’s Polaris program. Where CPM assumes each task has one duration, PERT models uncertainty by using three estimates — optimistic, most likely, and pessimistic — to compute a weighted expected duration. Use PERT when durations are genuinely uncertain; use CPM-style fixed estimates when the work is familiar. Most modern tools blend the two.

Critical chain project management (CCPM) starts from the critical path and adds the resource dimension. It accounts for resource dependencies — the fact that two logical tasks may compete for the same person — and inserts buffers at strategic points instead of padding each task. CCPM is the right tool when shared resources, not logic, are the real constraint on your schedule.

The practical distinction: CPM asks “what is the longest chain of logical dependencies?”, PERT asks “how uncertain are my durations?”, and critical chain asks “what happens when my people are the bottleneck?” You can start with CPM, add PERT-style estimates where uncertain, and adopt buffers where resources bind.

When Should You Use Critical Path Analysis — and When Not?

Use critical path analysis when the project has meaningful dependencies, a fixed or important finish date, and work that can be modeled as a network — which is most projects worth managing. It is standard in construction, engineering, software delivery, product development, event planning, and any environment where “this must finish before that” is the daily reality.

Use it with caution, and know its limits, in three situations. First, small parallel projects where everything has float and nothing is truly critical — the overhead may not pay for itself. Second, highly uncertain work where durations are guesses: the method will produce a precise-looking date built on fiction, so pair it with PERT-style ranges. Third, projects where resource constraints, not logic, dominate — in that case critical chain thinking is a better lens.

CPM also has honest weaknesses. It can be complex and time-consuming on large networks, it tends to produce rigid schedules that resist change, and it can lead teams to overfocus on critical tasks while neglecting non-critical work that later becomes critical. None of these are reasons to avoid it — they are reasons to recalculate regularly and keep the schedule alive.

Which Tools Find the Critical Path Automatically?

Nearly every serious scheduling tool computes the critical path for you, but the depth of the implementation varies. Here is an honest comparison.

Microsoft Project is the reference for CPM on complex projects — it handles dependencies, float, baselines, and critical path natively, and it is the tool most PMO environments expect. The trade-off is the steep learning curve and the cost, which is hard to justify for a lightweight team.

Smartsheet brings the same logic into a spreadsheet-shaped tool that mid-size teams already understand, including predecessor columns and critical path calculation. The trade-off is that grid-based logic is easy to overwrite and harder to audit visually.

ProjectManager offers a cloud Gantt that highlights the critical path with a filter, plus dashboards and reports — a good middle ground for teams that want visual scheduling without desktop software. Its trade-off is that advanced features vary by plan.

Oracle Primavera P6 is the enterprise standard for construction and engineering, handling enormous networks, calendars, and resource constraints. It is also the most expensive and specialist-heavy option, and it is overkill outside those industries.

ClickUp fits small teams that want the schedule and the work in one affordable tool, including a Gantt view with critical path. The trade-off is that its scheduling engine is lighter than the dedicated products, which is fine until your project outgrows it.

The selection rule mirrors everything above: choose the tool whose CPM depth matches your project’s complexity, and — above all — make sure you can actually see float and critical path in the view you will use every week.

Three Scenarios: The Critical Path in Real Projects

Scenario 1 — Protecting the critical chain under pressure. A software release has a 45-day critical path: Requirements (6d) → Design (8d) → Build (20d) → QA (7d) → Release (4d). Design slips by 3 days. Because the team watches the critical path, they pull a tester into early QA planning, fast-track the build setup, and recover 3 days — the release date holds. The same situation in a team that only tracks “percent complete” would have absorbed the slip silently and discovered a 48-day release on day 44.

Scenario 2 — Exploiting float to save budget. A campaign has two parallel paths: creative production (critical, 20 days) and vendor bookings (10 days of float). Two weeks in, the vendor bookings path is slipping toward its float limit while a photographer on the critical path needs an extra assistant. The manager reassigns one person from vendor bookings to the critical photo shoot, accepting a 3-day hit on a path with 10 days of float. The campaign date is unchanged, and the critical path — not the busiest-looking path — got the resource.

Scenario 3 — Two critical paths, one surprise. A construction project has two equal-duration paths: the structure chain and the MEP (mechanical, electrical, plumbing) chain, each 60 days. Both are critical. The team manages the structure chain closely but treats MEP as “secondary” because it runs in parallel. When MEP slips by 5 days, the whole project slips by 5 days — and the delay review shows the second critical path was visible in the network all along. The lesson: when you see multiple critical paths, every one of them controls the date.

Common Mistakes With the Critical Path

• Finding the critical path once and forgetting it. The path changes every week as actuals replace estimates; a stale critical path is a false sense of control.
• Trusting durations that no one validated. CPM is arithmetic on estimates; bad durations produce a precise-looking date that is fiction.
• Missing dependencies in the model. A critical path computed from incomplete dependencies is not your critical path.
• Managing by “busiest task” instead of criticality. The task that looks most urgent is often the one with the most float.
• Ignoring near-critical paths. A path with a few days of float becomes critical the day it slips; track it before it surprises you.
• Overfocusing on critical tasks and starving non-critical work. Non-critical tasks can burn their float and quietly join the critical path.
• Believing the schedule can’t be compressed. Fast tracking and crashing exist precisely to shorten the critical path; not knowing them is a management gap.

Know This Before You Choose

Before you commit to critical path analysis as your scheduling approach — and pick the tool that runs it — answer these questions.

• Do you have a work breakdown structure and realistic durations you can defend in a review?
• Are your dependencies complete enough that the computed critical path would survive scrutiny by the people doing the work?
• Will you actually refresh the critical path weekly, or will it become a static artifact of the planning phase?
• Can your tool show float and critical path in the view you use daily, not just in a special report?
• Do your deadlines live in fixed dates (contracts, launches, external commitments) where the critical path genuinely protects value?
• When the critical path slips, do you have the authority and options — fast track, crash, re-sequence — to act, or will you only be able to report the news?

Conclusion

The critical path is the most useful single number in project management because it tells you two things you cannot afford to guess: the earliest date you can deliver, and which tasks control that date. Everything else in the schedule — float, near-critical paths, resource trades — is a refinement of those two facts.

Start by building a dependency-correct network with defensible durations, calculate the critical path, and then manage it as a living number: refresh it weekly, protect critical tasks, spend float deliberately, and compress the path when the date matters more than the plan. The method is over sixty years old and it is still the backbone of scheduling software because it answers the question every stakeholder asks.

To be transparent: Doitify is our product, which is why we know its capabilities from the inside. For teams that want scheduling logic — dependencies, Gantt charts, and milestone tracking — to sit beside execution, collaboration, and reporting in one workspace, Doitify’s project management workspace is built for that workflow, and it is the scenario where we recommend it.