How to Calculate the Critical Path (Step-by-Step)

how to calculate the critical path is a key topic in modern project management and teamwork. Every project manager has sat in a status meeting and watched a delivery date slip for reasons nobody saw coming. Usually the trigger was a task that looked ordinary — a content draft, a vendor approval, a test run — and yet it pushed everything else down the line. The critical path is the calculation that makes those surprises predictable. It tells you exactly which tasks control your finish date and which ones can slip without hurting it.

The method itself is old, reliable, and completely doable by hand on a whiteboard. You list the work, define what depends on what, then run two simple passes over the schedule to find the longest chain of dependent tasks. This guide walks through every step with a fully worked example you can reproduce, includes the exact spreadsheet formulas, and shows you how the calculation behaves in real tools. By the end, you will be able to compute the critical path for your own project in under an hour.

Quick Answer: How Do You Calculate the Critical Path?

You calculate the critical path in six steps: list every task with a duration, define the dependencies between them, run a forward pass to find each task’s earliest start (ES) and finish (EF), run a backward pass to find the latest start (LS) and finish (LF), compute float as LS minus ES, and mark every task with zero float as critical. The chain of zero-float tasks from start to finish is your critical path, and its total duration is the shortest possible project duration.

The formulas are simple: EF = ES + duration, LS = LF − duration, and float = LS − ES. The skill is not in the arithmetic — it is in getting the durations and dependencies right, and in keeping the calculation current as the project changes.

What Do You Need Before You Can Calculate the Critical Path?

Before the arithmetic starts, you need three inputs, and the whole calculation is only as good as they are.

A complete task list. Work from your work breakdown structure (WBS) and list every task that must happen to finish the project. Miss a task and the schedule quietly ignores it — which is how teams deliver a “complete” project that is missing the very work that controlled the date. This is the most common reason a calculated critical path disagrees with reality.

Realistic durations. Each task needs a duration estimate in a common unit (days, hours). Use historical data, team input, and subject-matter expertise. The critical path is arithmetic performed on these numbers, so a padded or optimistic estimate produces a confident-looking but wrong answer.

Correct dependencies. Record which tasks must finish before others start. In the vast majority of cases you use finish-to-start: task B cannot start until task A is done. Missing dependencies are the second most common source of error, which is why you should validate the dependency list with the people doing the work before you trust the output.

If any of these three is missing, stop and fill the gap. The calculation rewards preparation and punishes shortcuts.

The Critical Path Formulas: ES, EF, LS, LF, and Float

There are five numbers to know, and each has a one-line definition.

Tasks with float equal to zero are on the critical path. Tasks with positive float are not — they can absorb delay up to their float before they threaten the finish date.

The forward pass (ES and EF) moves left to right and computes the earliest dates. The backward pass (LS and LF) moves right to left and computes the latest dates. Float falls out of the difference between them. That is the entire method.

Step-by-Step: How to Find the Critical Path in Your Schedule

Here is the full workflow, ready to apply to any project.

Step 1: Build the activity list and durations

Take your WBS and write down each task with a single duration estimate. Keep the unit consistent. If a task genuinely varies in length, record the expected value and plan to revisit it — you can refine uncertainty later with three-point (PERT) estimates, covered below.

Step 2: Define the dependencies

For each task, list which tasks must finish before it can start. Keep to real logic, not habit: “design review must be done before development” is a real dependency; “we usually do it this way” is not. When in doubt, ask the person who will actually do the task.

Step 3: Run the forward pass

Start at the first tasks (no predecessors). Their ES is 0 and their EF is duration. For every later task, ES equals the largest EF among its predecessors, and EF equals ES plus its duration. When you reach the end, the largest EF in the network is the estimated project duration.

Step 4: Run the backward pass

Start at the final tasks (no successors). Their LF is the project duration from Step 3, and LS is LF minus duration. Moving backward, each task’s LF equals the smallest LS among its successors, and its LS is LF minus duration.

Step 5: Compute float and identify the critical path

Float = LS − ES for each task. The tasks with float zero form the critical path, which runs from start to finish. Mark them in a different color on your schedule.

Step 6: Validate and document

Walk the critical chain end to end and ask: does this sequence match what the team expects? Share it in your next planning meeting. Then set a reminder to refresh it — this is a living number, not a planning artifact.

Worked Example: Calculating the Critical Path on a Website Launch

To make the method concrete, here is a small website launch with six tasks and one parallel path. The tasks: requirements (T1, 5 days), design (T2, 7 days, after T1), content writing (T3, 6 days, after T1), development (T4, 12 days, after T2), QA testing (T5, 5 days, after T3 and T4), and deployment (T6, 2 days, after T5).

Forward pass. T1 starts at day 0 and finishes at day 5. T2 starts at day 5 and finishes at day 12; T3 also starts at day 5 and finishes at day 11. T4 starts at day 12 and finishes at day 24. T5 depends on both T3 and T4, so its earliest start is the larger of their finishes — day 24 — and it finishes at day 29. T6 starts at day 29 and finishes at day 31. The largest EF is 31, so the project takes 31 days.

Backward pass. T6 gets LF 31 and LS 29. T5 gets LF 29 and LS 24. T4 gets LF 24 and LS 12. T3 gets LF 24 (the LS of its successor T5) and LS 18. T2 gets LF 12 and LS 5. T1 gets LF 5 (the smaller of T2’s LS at 5 and T3’s LS at 18) and LS 0.

Float and critical path. T1, T2, T4, T5, and T6 all have float 0 — they form the critical path (T1 → T2 → T4 → T5 → T6), totalling 31 days. T3 has 13 days of float: content writing can slip up to 13 days without moving the launch.

The practical meaning is striking. If content writing slips by 10 days, the launch still happens on day 31. If design slips by just 2 days, the launch moves to day 33, and every downstream commitment moves with it. That asymmetry — where delay is expensive and where it is free — is the whole value of the calculation.

How to Calculate the Critical Path in Excel or Google Sheets

You can reproduce the entire calculation in a spreadsheet with four formulas, which also makes it easy to re-run when estimates change.

Set up columns for Task, Duration, Predecessor, ES, EF, LS, LF, and Float. Then:

• ES: enter 0 for the first tasks. For a task with one predecessor, reference that predecessor’s EF. For a task with several predecessors, use MAX over their EF cells.
• EF: = ES + Duration.
• Project duration: = MAX of the EF column.
• LF: for final tasks, enter the project duration. For other tasks, use MIN over the LS cells of their successors (or reference the single successor’s LS).
• LS: = LF − Duration.
• Float: = LS − ES.
• Critical flag: a formula like =IF(Float=0,”Yes”,”No”) — or use conditional formatting to highlight zero-float rows.

The main trap is circular references when a chain loops back, which in a well-built project schedule never happens. If your network is large, consider a layout where each row references only rows above it. A spreadsheet gives you full control and full visibility, but it asks you to maintain the logic yourself — which brings us to the tools that do it for you.

Which Tools Calculate the Critical Path Automatically?

Nearly every serious scheduling tool computes the critical path for you, but the depth and behavior differ. Here is an honest comparison of the main options.

Microsoft Project remains the reference for CPM on complex projects — it handles dependencies, float, baselines, and critical path natively, and it is what most PMO environments expect. The trade-off is the learning curve and the per-user cost, which is hard to justify for a small team running a handful of simple projects.

Smartsheet brings the same logic into a spreadsheet-shaped tool that many 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, so one careless edit can silently change your critical path.

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

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.

OpenProject gives teams a free, self-hostable alternative with Gantt scheduling and dependency support. The trade-off is that you take on hosting and maintenance, and the polish of commercial tools is absent.

The selection rule mirrors the method: pick the tool whose CPM depth matches your project’s complexity, and make sure you can actually see float and critical path in the view you use every week — not only in a special report you generate once.

How Do You Handle Uncertain Durations (PERT)?

When durations are genuinely uncertain, add three-point estimation instead of guessing one number. For each task, estimate the optimistic (O), most likely (M), and pessimistic (P) durations, then compute the expected duration as (O + 4M + P) / 6. Use these expected values in your forward and backward passes.

This matters because the critical path calculation is arithmetic on estimates, and a single-duration model treats every number as fact. On familiar, repeatable work, single-point estimates are fine. On research, design, and integration work — where surprises are the norm — PERT-style ranges give you a duration that reflects reality without pretending precision.

A practical middle ground: use the expected value for the calculation, but track the range for critical tasks. If the pessimistic estimate for a critical task would break your delivery date, that is a risk to manage now, not a fact to discover later.

When Should You Recalculate the Critical Path?

Recalculate at least weekly on any project with real dependencies, and immediately after any significant change: a task slips past its float, scope changes, a resource leaves, or a dependency is added. The critical path is not a static line you draw once in planning.

The reason is that the critical path moves. As actual progress replaces estimates, a path that had comfortable float can burn through it and become critical, and a task you were watching can quietly stop controlling the date. Teams that refresh weekly catch these flips while they still have options. Teams that do not rediscover them at the moment the delay is final.

Three Scenarios: The Critical Path in Real Projects

Scenario 1 — Using float to protect the date. A marketing campaign has two parallel workstreams. The creative production stream is critical at 20 days; the vendor bookings stream has 12 days of float. Ten days in, the photographer on the critical path needs an extra assistant, while vendor bookings is running 3 days behind but still inside its float. The manager moves one person from vendor bookings to the photo shoot. The campaign date holds, and the cost was a 3-day delay on a path that could absorb 12.

Scenario 2 — A near-critical path flips. A product release has a 45-day critical path through requirements, design, build, QA, and release. A second integration path has 4 days of float. Two weeks in, the integration vendor misses a delivery, burning the float. The path becomes critical — now two chains control the date. Because the team recalculates weekly, they spot the flip on day 18 and fast-track the integration by running two tasks in parallel, recovering the slip before the release is threatened.

Scenario 3 — Estimating honestly. A construction team plans a 60-day structural phase. The durations are entered from a previous similar building, but the new site has foundation unknowns. Using three-point estimates, the expected foundation duration comes out 8 days above the single-point guess. The team adjusts the plan and communicates a 68-day structural phase. They finish in 66. The team that trusted the optimistic single number would have committed to 60 and missed it by a week with no plan to absorb it.

Common Mistakes When Calculating the Critical Path

• Missing dependencies in the model. A critical path computed from an incomplete dependency list is not your critical path; it is a schedule that ignores real constraints.
• Trusting durations nobody validated. The method produces precise-looking answers from whatever numbers you feed it. Bad estimates in, bad dates out.
• Calculating once and forgetting it. The path changes every week. A stale critical path is a false sense of control.
• Confusing “busiest” with “critical.” The task that looks most urgent is often the one with the most float, while a quiet critical task actually controls the date.
• Ignoring near-critical paths. A path with a few days of float becomes critical the day it slips. Track it before it surprises you.
• Using total float when you need free float. Total float is relative to the project; free float is relative to the next task. For resource decisions, know which one you are working with.
• Forgetting resources entirely. The logical critical path assumes unlimited resources. When your bottleneck is a person, not a dependency, critical chain thinking (covered in our comparison of critical path vs critical chain) is the better lens.

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 defensible durations you can stand behind in a review?
• Are your dependencies complete enough that the computed critical path would survive scrutiny from the people doing the work?
• Will you actually refresh the calculation 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 only 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 the options — fast track, crash, re-sequence — to act, or will you only be able to report the news?

Conclusion

The critical path is the single most useful number in your schedule because it answers two questions you cannot afford to guess: when the project can realistically finish, and which tasks control that date. The calculation itself is simple arithmetic — a forward pass, a backward pass, and a float column. The discipline is in the inputs and the cadence: honest durations, complete dependencies, and a weekly refresh.

Start by building a dependency-correct network with defensible estimates, calculate the critical path, and then manage it as a living number. Protect the critical tasks, spend float deliberately, and compress the path when the date matters more than the plan.

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.