Open your project in P6. Go to Activities. Apply the critical path filter. You get a set of activities highlighted in red. That is the critical path, right?

Maybe. Often not.

P6's default critical path filter shows activities with total float less than or equal to zero. That is not the same as the longest path through the network. It is not the same as the path driving the completion date. It is a float-based filter that can be misleading in at least five common ways.

1. Date constraints create false critical paths

If an activity has a "Finish On" or "Finish On or Before" constraint, P6 calculates its float relative to that constraint, not relative to the project completion. The activity shows zero float because its late finish equals its constraint date, not because it is on the path that determines when the project ends.

On a large EPC project, there are typically dozens of date constraints. Contractual milestones, interface handover dates, permit deadlines, weather windows. Each one creates a cluster of activities that show as critical in the float filter but may have nothing to do with the project completion date.

The result: the critical path filter returns 400 activities when the real longest path has 120. The signal is buried in noise.

The fix: Use the longest path method instead of (or in addition to) the float filter. P6 has a built-in longest path calculation. It traces the chain of activities from the project start to the project finish by following the path with the least total float, ignoring intermediate constraints. This gives you the path that actually determines the completion date.

2. Open ends break the CPM calculation

An activity with no successor has nowhere for its float to propagate. P6 calculates its late finish as its own early finish (or the project data date, depending on settings), which often produces zero or negative float. The activity appears critical even if it finished three months ago and has no bearing on the completion date.

On a schedule with 30,000 activities, there are usually 50-200 activities with missing successors. Most are complete. Some are administrative. A few are genuine planning omissions. All of them contaminate the critical path filter.

The fix: Fix the open ends first. Every activity should have at least one successor (except the project completion milestone). Run the open-end check before you run the critical path analysis. P6 has a schedule check that flags this. So do most schedule health check tools.

3. Calendar differences distort float

If two sequential activities use different calendars, the float calculation can produce unexpected results. Activity A finishes on a Friday using a 5-day calendar. Activity B starts on Monday using a 7-day calendar. P6 calculates two days of weekend float that do not actually exist as usable schedule margin.

On projects with multiple work calendars (day shift, night shift, 6-day week, 7-day week, weather-restricted), the float values become increasingly unreliable as indicators of schedule criticality. An activity can show 10 days of float that are entirely composed of non-working days on its successor's calendar.

The fix: Be aware that float is calendar-dependent. When you identify the critical path, check that the activities on it use compatible calendars. If they do not, the float values are technically correct but practically misleading. The longest path method is less susceptible to this because it follows the chain of dependencies rather than relying on absolute float values.

4. Progress override settings mask the real path

P6 has a setting called "Define Critical Activities as" in the project scheduling options. The default is "Total Float less than or equal to 0." But many planners change this to "Longest Path" or set a different float threshold.

The problem arises when progress override is enabled. If P6 is set to "Retained Logic" or "Progress Override," the way it handles out-of-sequence progress changes the float calculation. An activity that should be critical may show positive float because P6 allowed it to start out of sequence and recomputed its dates accordingly.

Two planners looking at the same schedule with different scheduling options will see different critical paths. Neither is wrong. They are computing different things. But if you do not know which option is set, you cannot interpret the result.

The fix: Standardise the scheduling options and document them. Check what "Define Critical Activities as" is set to. Check whether retained logic or progress override is in use. Include these settings in your schedule analysis as a footnote. The critical path is only meaningful in the context of the assumptions used to calculate it.

5. The critical path shifted and nobody noticed

This is the most common and most dangerous failure. The critical path three months ago ran through structural steel. This month it runs through instrument cable pulling. The float filter still shows activities in red. But the red activities are different activities, and the PM is still talking about steel.

Critical path shifts happen when one area recovers and another area slips, when logic ties change, when constraints are added or removed, or when resources are re-levelled. They are normal. They are also invisible unless you are specifically comparing this period's longest path to last period's longest path.

The PM who reports "critical path through steel erection" for three consecutive months because they saw it in January and did not re-check in February and March is reporting stale information. The committee is making decisions based on a path that is no longer driving the completion date.

The rule: Re-identify the critical path every period. Do not carry it forward from last month. The longest path analysis takes five minutes. The cost of reporting a stale critical path is a steering committee making decisions about the wrong problem.

What to do about it

Three actions.

  1. Use the longest path, not just the float filter. The longest path traces the chain of activities from start to finish. It is less susceptible to constraint noise, open ends, and calendar distortion. P6 has this built in. Use it.
  2. Clean the schedule before you analyse it. Fix open ends, review constraints, standardise calendars. A schedule health check is not optional housekeeping. It is a prerequisite for a meaningful critical path analysis. If the schedule is broken, the critical path is broken.
  3. Compare period to period. The critical path this month is only meaningful in comparison to the critical path last month. Did it shift? Did float change? Did the driving activity change? The comparison is the analysis. The single-period snapshot is just data.

The critical path is the single most important piece of information in your schedule. It determines the forecast completion, it drives the recovery strategy, and it is the first thing a delay expert looks at when a dispute begins. Getting it right is not a technical nicety. It is the foundation of every schedule conversation.

If you are not sure whether your critical path is right, upload your XER to Allsignal's free schedule check. It runs a longest path analysis, flags open ends, identifies constraint conflicts, and shows you the path that is actually driving your completion date. No account. No trial. Just the answer.