How to Calculate the Critical Path and Total Float

Critical path analysis finds the longest sequence of dependent activities through your project network — the sequence that sets the shortest possible finish date. You run it in five steps: list activities and dependencies, draw the network, run a forward pass for early dates, run a backward pass for late dates, then calculate total float (LS − ES) to see which activities cannot slip. In practice you use the result to forecast the finish date, focus management attention on zero-float work, and judge how much delay the rest of the schedule can absorb. A calculated date is only one part of project planning, however; the plan must also establish scope, resource availability, acceptance, costs, risks and decision ownership.

Below you will run the method end to end on a six-activity network: the forward pass for early dates, the backward pass for late dates, and the float formula (LS − ES) that separates critical from non-critical work. A free calculator and a downloadable Excel workbook let you check the numbers — or your own project — as you read.

How to calculate the critical path in five steps

1. 1List activity IDs, durations and predecessors, then draw the dependency network. The example below uses finish-to-start links, no lags and a common day-0 calendar; resolve circular dependencies before calculating.
2. 2Run the forward pass: starting activities have ES = 0; otherwise ES = the maximum predecessor EF. Calculate EF = ES + duration. The latest terminal EF gives the earliest project finish.
3. 3Run the backward pass from that finish: terminal activities have LF = project finish; otherwise LF = the minimum successor LS. Calculate LS = LF − duration.
4. 4Calculate total float for each activity: LS − ES, equivalently LF − EF. Trace the connected zero-float activities from start to finish; more than one critical path is possible.
5. 5Check the result: in this unconstrained example, the critical path durations must sum to the calculated finish. Recalculate after changing a duration or dependency, because a different branch can become critical.

What does critical path analysis tell a project manager?

Critical path analysis answers three scheduling questions: what is the earliest the project can finish, which activities control that date, and how much delay can the other activities absorb? Use dependencies and durations to calculate the dates, then use total float to prioritise intervention. The longest dependent sequence matters, not the single longest task or the busiest team.

Critical path calculation: the three core formulas

1. 1Forward pass: ES = maximum predecessor EF (0 for starting activities); EF = ES + duration.
2. 2Backward pass: LF = minimum successor LS (project finish for terminal activities); LS = LF − duration.
3. 3Total float = Late Start − Early Start. Activities with zero total float form the critical path.

The float time formula, worked end to end

Total float is the amount of time an activity can slip without moving the project's end date. The formula is always the same: Total float = Late Start − Early Start (equivalently, Late Finish − Early Finish). You get the early dates from the forward pass and the late dates from the backward pass, so the formula only works once both passes are done.

Take a six-activity network, durations in days. Activity A starts the project; B and C both follow A; D follows B; E follows C; F follows both D and E.

Forward pass: early start and early finish

Start at day 0. Early Start = the latest Early Finish among the activity's predecessors; Early Finish = Early Start + duration. A runs 0→4. B and C both start at 4: B runs 4→10, C runs 4→12. D follows B, so 10→17. E follows C, so 12→15. F waits for both D (17) and E (15), so it starts at the later of the two: 17→20. The shortest possible duration is 20 days.

Backward pass: late start and late finish

Now walk backwards from day 20. Late Finish = the earliest Late Start among the activity's successors; Late Start = Late Finish − duration. F must finish at 20, so it runs 17→20. D must finish by F's late start: 10→17. E also feeds F: 14→17. B feeds D, so it must finish by 10: 4→10. C feeds E, so it must finish by 14: 6→14. A feeds both B (late start 4) and C (late start 6), so it must finish by the earlier of the two: 0→4.

Apply the formula: total float per activity

The critical path is A → B → D → F at 20 days. Procurement (C) and Configure (E) each show two days of total float, shared along their branch rather than available twice. A combined two-day delay on that branch leaves the finish at day 20 and makes both branches critical; a combined third day makes A → C → E → F the controlling path at 21 days. That is the value of the float formula: it shows where delay is survivable and where it moves the end date.

What to report from the critical path result

Report the controlling sequence and forecast finish together: in this network, A → B → D → F and day 20. Explain that C and E share a two-day allowance, and identify any duration or dependency changes before promising the finish date. If Procurement slips by three days, the recalculated forecast is day 21 and the controlling sequence changes to A → C → E → F. Reporting only the original path would hide the new schedule risk.

Critical path analysis, pass by pass

Here is the same six-activity network traced one step at a time. Read the forward pass top to bottom, then the backward pass bottom to top — the rows where the two passes give the same start are the critical path.

Using critical path analysis on a live project

• Weekly: re-run the passes with actual dates and remaining durations — the critical path moves as work finishes early or late.
• When a delay is reported: check the task's float first. Inside float, note it; beyond float, the end date moves and the sponsor needs to know.
• When asked to bring the date in: only shorten critical activities (crash or fast-track B or D here). Speeding up C or E saves nothing.
• Before approving a change: add the new activity to the network and see whether it creates a longer path than A → B → D → F.

Common critical path calculation mistakes

1. 1Taking the earliest predecessor finish in the forward pass. Early Start is the latest Early Finish of all predecessors — F above cannot start at day 15 just because E finishes then.
2. 2Taking the latest successor start in the backward pass. Late Finish is the earliest Late Start of all successors, otherwise float is overstated.
3. 3Mixing day-0 and day-1 conventions. Pick one (this guide starts at day 0) and use it on both passes, or every float value will be off by one.
4. 4Leaving open ends. Every activity except the first needs a predecessor and every activity except the last needs a successor, or float on the dangling task is meaningless.
5. 5Treating float as spare time for the team. Total float is shared along a path; if C uses its two days, E has none left.

Check your answer with the calculator and Excel example

Enter the six activities above into the free critical path calculator — IDs, durations and predecessors — and it runs both passes for you, showing ES, EF, LS, LF and total float for every task and highlighting A → B → D → F as the 20-day critical path. To practise on a bigger network, download the Excel example from this guide: change any duration and the forward pass, backward pass and float columns recalculate, so you can see exactly when a near-critical path takes over.

Project planning: connect the schedule to the delivery commitments

A network can be mathematically correct and still be impossible to deliver. The six-task calculation above assumes that people, equipment, inputs and approvals are available when needed. Integrated project planning tests those assumptions against the actual delivery environment. Use the calculated finish as a starting point for discussion, not a promise made before checking capacity and acceptance. The broader project-plan guide covers how to assemble the plan; this section explains how to make its schedule credible and keep it useful.

Turn deliverables into schedulable work

A work breakdown structure organises the scope by deliverable; the schedule organises the activities needed to produce those deliverables. Do not treat them as identical. A deliverable such as an accepted supplier configuration may need requirements review, access provision, configuration, testing, defect correction and sign-off. Give each activity a completion condition, an owner, a duration estimate and predecessor logic. This exposes the work hidden behind labels such as implementation or launch.

• Define done before estimating: acceptance testing ends when agreed tests pass and the authorised reviewer accepts the evidence, not merely when someone has spent three days testing.
• Include non-build work: purchasing, environment preparation, data access, training, release approval, handover and support readiness can control the finish just as much as development.
• Represent a decision gate as a zero-duration milestone, but schedule the review preparation and any approval turnaround that must happen before it.
• Document estimate uncertainty and assumptions. A supplier lead-time estimate without confirmation is a risk to investigate, not a contractual commitment.

Dependency types and external handoffs

Separate mandatory logic from preferred working order. A required inspection before release is different from a team's preference to finish all documentation before testing. Record external dependencies with an owner on each side, a needed-by date, the input or decision expected and an escalation route. Avoid hiding substantive work inside a lag: if a review requires effort and an accountable owner, model it as an activity. The simple calculator cannot model SS, FF, SF, lags or different calendars; do not enter them as though they were FS links.

Effort, duration and realistic capacity

Effort is the amount of labour required; duration is elapsed working time on the schedule. Sixteen person-hours of work may occupy two eight-hour working days for one fully available person, but four days if that person can allocate only four productive hours a day. More people do not automatically divide duration: handoffs, specialist skills, equipment constraints and work that cannot be parallelised limit that relationship. Waiting for a supplier or an approval adds duration even when your team spends little effort during the wait.

Check for double-booking across parallel branches. Resource levelling resolves overload by moving work or changing allocations, which may extend the finish and change the critical path. Resource smoothing aims to adjust work within available float without changing the finish; it may not eliminate every overload. Recalculate the schedule after these adjustments. A logic-only critical-path result does not prove that the necessary people are available.

Worked business case: the plan fails a resource check

Use the same illustrative six-activity network. The unconstrained forecast is day 20. Now assume Design (B) and Configure (E) require the same specialist, who cannot do both at once. This adds a resource constraint without changing the approved deliverables. Compare the scenarios below using working-day offsets, finish-to-start links, no lags and no holidays. The additional test-approval scenario is separate from the resource scenarios, not cumulative.

A second specialist is an option to assess, not an assumed fix. Confirm skill suitability, onboarding time, access, cost and whether the work genuinely can be separated. Present the sponsor with the revised forecast and the consequences of each option. The useful planning outcome is an explicit decision with evidence, not a date achieved by removing inconvenient dependencies.

Plan uncertainty without hiding it in every task

Record the basis of each estimate: comparable work, expert judgement, supplier quotation or a range of plausible durations. Identify the assumptions most likely to change the finish, especially on critical and near-critical branches. Where uncertainty warrants it, use three-point estimates or schedule-risk analysis rather than interpreting a single deterministic CPM date as a confidence level. An expected duration is not a guaranteed finish date.

• Separate known work from risk response: access verification is planned work; a fallback environment for a possible supplier outage is a response to an identified risk.
• Make contingency visible and explain its basis and owner. Float arises from dependency logic; contingency is a deliberate allowance for uncertainty. They are not interchangeable.
• Connect risks to affected activities and milestones, with a trigger, response owner and action date. Review the cost and time required for the response.
• Challenge deadlines imposed before the estimate. Show the gap between the requested date and the credible forecast, then assess scope, sequencing, capacity and risk choices.

Rolling-wave planning and hybrid delivery

Detail near-term work when there is enough information to estimate and assign it. Keep later work at an appropriate planning-package level, with outcomes, indicative windows, dependencies and ownership still visible. Before a package approaches execution, decompose it, confirm capacity and update the forecast. Agree when this refinement happens and which changes need approval; rolling-wave planning is not permission to omit distant scope or pretend uncertain dates are firm.

Baseline, forecast and change control

The baseline is the approved reference used to assess performance. The current forecast is the best estimate of what will now happen, based on actual progress and remaining work. Keep both: overwriting the baseline with a later finish conceals variance. Record the baseline version, approval, calendars, scope assumptions and milestone dates. A forecast update does not by itself authorise changed scope, extra spending or a revised contractual commitment.

1. 1Capture the proposed change and the business reason, including the deliverables and acceptance criteria affected.
2. 2Model its impact on dependencies, remaining durations, resources, costs, risks and release readiness. Recalculate the controlling and near-critical paths.
3. 3Present options with consequences: accept a later date, fund a credible recovery, phase delivery or remove agreed scope. Identify who has authority to decide.
4. 4Record approval or rejection and communicate it to affected owners, suppliers and stakeholders. Update the controlled baseline only when the governance process authorises it; retain the previous version and decision history.

The weekly planning review: evidence before percent complete

Planning tools: choose the model, not just the presentation

Templates to use with the critical path method

1. 1Project plan template (/templates/project-plan) — record the activity list, durations and dependencies before you run the passes.
2. 2RAID log template (/templates/raid-log) — log a risk against every critical and near-critical activity so slippage is spotted early.
3. 3Status report template (/templates/status-report) — report critical path movement and remaining float each week, not just percent complete.