← All academy guides
Intermediate

Critical Path vs Longest Path: The Difference Most Planners Don't Know

P6 offers two different definitions of "critical," controlled by the project setting PROJECT.critical_path_type. They usually agree. They don't always — and when they don't, it matters for delay analysis and claims.

Same network, two definitions of critical
Start A (8) TF 0 B (5) TF 0 C (3) TF 0 End
Both A and B→C have zero total float (they tie at 8 days), so under CT_TotFloat both chains are marked critical.

The P6 setting

PROJECT.critical_path_type controls which definition P6 uses when it colours activities as critical in a layout or report. It's a project-level setting, so two schedules — or two updates of the same schedule opened with different settings — can show a different critical path even with identical logic and dates underneath.

CT_TotFloat: float ≤ threshold

Under this method, any activity whose total float is at or below the defined threshold (usually zero, sometimes a small positive number) is marked critical — full stop. If two independent chains both happen to tie at zero float, as A and B→C do above, both are shown as critical, even though only one of them can actually be driving the End milestone's date at any given moment.

CT_DrivPath: the driving path flag

P6 also tracks, for every activity, which single predecessor relationship actually determined its Early Start — the "driving" relationship. Following driving relationships back from the project finish traces exactly one path: the longest path. Where two chains tie on float, only the one P6 identifies as driving (based on evaluation order, not float value) is marked, and the other — despite also having zero float — is not.

When they agree, and when they don't

Most of the time, on a well-structured network, there's only one path with the minimum float value, so both methods produce the same picture. They diverge specifically in tied-float scenarios like this one, or in networks with unusual constraint dates that create float without a genuine driving relationship behind it.

Which one DCMA uses

The DCMA 14-point assessment's critical path test is built on CT_TotFloat — it works from float values, not driving-path flags, which is also why FloatCheck's own critical path check recomputes float directly rather than trying to reconstruct P6's internal driving-path logic from the XER.

In a delay analysis or an EOT claim, arguing from "the critical path" without specifying which of these two definitions you mean is a common way disputes stall — state the method up front, and check which one the contract or the other party's schedule actually assumes.

See this in your file → validate.html