Critical path vs longest path in P6: why total float lies to you

Primavera P6 offers two different definitions of "critical": Total Float at or below a threshold (the default), and the Longest Path. On a clean, unconstrained, single-calendar network they agree. On the programmes you actually work with — constrained, multi-calendar, contractually committed — they disagree, sometimes spectacularly. If you've never checked which one your reports use, this article is for you.

Here is the difference in one breath. Total Float criticality flags any activity whose total float is at or below a threshold (zero by default) — it is an arithmetic by-product of the backward pass. Longest Path traces the chain of driving relationships backwards from the activity that finishes latest — it identifies what actually determines the completion date. Float can be poisoned by constraints and distorted by calendars; the driving chain cannot. That is why they diverge, and why it matters which one your "critical path" filter is showing.

Most P6 users run the default their whole careers without knowing an alternative exists. That's survivable on a simple network. On a constrained programme it produces reports in which the highlighted "critical path" is not the path driving completion at all — and in a delay dispute, that gets expensive.

The Total Float definition, and the three ways it breaks

Total float is the amount an activity can slip without delaying the project end (or violating a constraint — remember that parenthesis, it's the villain of this article). P6's default criticality rule is simply TF ≤ 0, adjustable via the "critical activities have float less than or equal to" threshold in the schedule options. It feels rigorous because it's numeric. It breaks in three well-documented ways.

Constraints poison the float pool

Float is calculated against late dates, and late dates respect constraints. Put a Must-Finish-On milestone on a side branch — an energisation date, a handover decreed in a board paper — and if the logic can't achieve it, every activity feeding that milestone goes to negative float. They will all show as "critical", and because their float is more negative than the true driving path's, they'll sort to the top of every float-ordered layout. Meanwhile they may have no influence whatsoever on project completion. The inverse trick is just as common: a generous Must-Finish constraint or a late project "must finish by" date inflates float across the board and the genuinely critical path shows TF of +15 and looks relaxed. When a project-level deadline is missed, the entire programme can go red — and when everything is critical, nothing is: the term has stopped carrying information.

Calendars make float incomparable

P6 calculates float in the units of each activity's calendar. Five days of float on a 5-day calendar spans seven calendar days once the weekend is counted; five days on a 7-day calendar spans five. Same number, different amounts of real slack — so sorting a multi-calendar programme by total float and treating the order as a ranking of urgency is quietly wrong. Offshore/onshore, shutdown windows, lab calendars, night shifts: any programme mixing them has this problem on every float-sorted view.

Deadline constraints turn the whole programme red

The special case worth naming: a project Must Finish By date (or a late finish constraint on the completion milestone) that the current logic misses by, say, 20 days drives 20 days of negative float through every path that reaches completion. Open the float column and the entire programme is critical. The honest signal — "the plan as drawn misses its commitment" — is real, but as a tool for finding what to manage this week, the float column has just resigned.

The Longest Path definition — and where it falls short

Switch P6's schedule option to "Longest Path" and criticality is no longer about float at all. The engine finds the activity (or milestone) that finishes latest, then walks backwards through driving relationships — the predecessors that actually determine each early start — until it reaches the start of the network. That chain is the longest path: the sequence of work that genuinely sets the completion date.

Its great virtue is immunity to float distortion. Constraints can poison float values; they cannot change which predecessor was driving. Multi-calendar arithmetic doesn't enter into it. On the constrained programme above, longest path serenely ignores the −12d side branch and highlights the chain that actually ends last. For delay analysis — where the question is "what drove completion?", not "what has the scariest float number?" — this is usually the definition you want.

But it has its own blind spots, and they deserve equal honesty:

• It shows one path. A chain running one day behind the longest path is invisible — and next update, after the first rain delay, it may be the longest path. Managing only the longest path is how near-critical work ambushes projects. (The clearest way to see the longest path and the chains queued behind it is a time-scaled logic diagram, which draws the driving path and near-critical bands as continuous chains.)
• Mid-network constraints and external dates can still mislead it. An activity held by a Start-No-Earlier-Than constraint (a permit date, a client deliverable) is "driven" by the constraint, not by a predecessor — so the trace can dead-end at the constraint and present a truncated path that starts in mid-air. The path is honest about what's driving; it just may not be telling you about work.
• It says nothing about how bad things are. Longest path tells you what drives the date, not whether the date is in trouble. You still need float for the arithmetic of lateness.

Multiple float paths: the grown-up answer

Hidden in P6's advanced schedule options is Multiple Float Paths: instead of one longest path, the engine identifies the first, second, third (up to ten) most critical driving chains, tagging each activity with a Float Path number. This is the tool that answers the question longest path can't: what's coming up behind the critical path? Run it free-float-based, ask for five paths, group the layout by Float Path, and you have a ranked map of the programme's pressure points — the driving path plus the chains that will take over if it's fixed or if they slip. For schedule risk work and for sequencing recovery effort, this view earns its keep within the first hour of using it. Its only real costs are that few people know it exists, and that ten paths of output need interpreting rather than pasting straight into a report.

Which to use, when — and the rule that matters in disputes

Practical guidance, as we'd give it on a live job:

• Day-to-day management: Total Float criticality with a sensible threshold, plus a near-critical band (say TF ≤ 10d) so the understudies stay visible. Know your constraints, or the colours are lying to you.
• Claims and delay analysis: longest path — or more precisely, driving-path logic traced through each window. Tribunals want to know what drove completion, and float arithmetic corrupted by constraints will be taken apart in cross-examination.
• Risk and recovery: multiple float paths, grouped and read as a ranked list of pressure points.

And the rule that outranks all of the above: state which definition you're using. A delay submission that says "the critical path runs through the atrium roof" without defining critical hands the other side a free attack: they re-run the schedule under the other definition, get a different red line, and spend a day of the hearing arguing about vocabulary instead of delay. One sentence in the methodology section closes the door.

This is also exactly what check 12 of the DCMA 14-point assessment — the critical path test — probes from the other direction: inject a delay into a critical activity and verify the completion date moves with it. A network that fails that test has a "critical path" that doesn't actually drive anything, under either definition, usually because constraints or open ends are absorbing the delay somewhere downstream. Run that test before you believe either red line.