2026-10-15 · 6 min read

Why Your Critical Path Keeps Jumping (and How to Stop It)

Few things damage trust in a programme faster than a critical path that changes every week. One update the critical path runs through the steel frame. The next it runs through the switchgear delivery. The update after that it runs through a fit-out activity nobody was watching. The client starts asking which version is true, and the site team stops paying attention to any of them.

Sometimes the critical path moves because the project genuinely changed. A delivery slipped, a design package arrived late, or a sequence was re-planned. That is the schedule doing its job. But a lot of the time the jump is caused by the way the schedule is built or updated, not by anything that happened on site. This article covers the usual causes and how to deal with each one.

First, decide what "critical" means in your file

Before chasing anything else, check how your tool is defining critical activities. Two schedules with identical logic can show different critical paths simply because of this setting.

In Primavera P6 there are two common definitions, set in the schedule options:

• Total float less than or equal to a value, usually zero.
• Longest path, which traces the chain of activities that drives the project finish.

In MS Project, the equivalent is the "tasks are critical if slack is less than or equal to" setting in the advanced options, which defaults to zero days.

The total float definition is sensitive to anything that distorts float: constraints, calendars, open ends and out-of-sequence progress. The longest path definition is usually more stable because it follows the driving logic to the finish. If your critical path keeps jumping and you are using a total float threshold, switch to longest path for a look and compare. If the two give very different answers, that difference is itself a clue that something in the file is distorting float.

Cause 1: Several paths with almost the same float

This is the most common cause on large jobs and it is not really an error. When two or three chains of work all finish within a few days of each other, a small change on any of them can swap which one is longest. One week the structure is a day longer than the MEP path; the next week MEP picks up three days and becomes critical.

The fix is not to pretend there is only one critical path. Instead:

• Report the critical path and the near-critical paths together, for example everything within ten working days of critical.
• In P6, use the multiple float path option in the advanced schedule options to see the first, second and third paths that drive a chosen activity or the finish milestone.
• Track the float of each near-critical path over time. A path that loses float every update is the one to worry about, whether or not it is currently labelled critical.

Once people see the near-critical paths, a "jump" stops being a surprise. It becomes a path they already knew was close.

Cause 2: Open ends and weak logic

If activities are missing predecessors or successors, their float is not calculated against anything meaningful. An activity with no successor can show very large float, or it can be forced critical, depending on how the tool treats open ends. P6 has a setting to make open-ended activities critical, which can drag unrelated activities into the critical path report.

Weak logic causes a quieter version of the same problem. Activities that are linked only start-to-start, or linked to a summary milestone instead of the work that really follows them, do not pass delay through the network properly. The critical path then shifts depending on which loosely tied activity happens to finish last.

Run a logic check before every update. Every activity apart from the start and finish milestones should have at least one predecessor and one successor, and the links should describe how the work actually depends on each other. Our article on fixing open ends and dangling logic in P6 walks through this step by step.

Cause 3: Constraints overriding the logic

Hard constraints are a classic source of an unstable critical path. A "must finish on" or "finish on or before" constraint creates negative float when the logic cannot meet the date. A "start on or after" constraint can hold an activity back so that it looks critical even though nothing is pushing it. In P6, a mandatory constraint can break the logic altogether.

Each update, as progress moves dates around, those constraints interact with the network in different ways, and the activities showing the lowest float change with them.

Keep constraints to a minimum and give each one a reason you could explain to a reviewer: a contractual milestone, an access date from the client, or a fixed delivery. Where you need to show a target date, consider a milestone with a deadline or a comparison against the baseline instead of a hard constraint. Review the full constraint list as part of every update, because constraints that made sense at baseline often outlive their purpose.

Cause 4: Mixed calendars

Different calendars are normal. Concrete pours, shutdowns, commissioning and office work rarely share a working week. But float is calculated in working time on each activity's own calendar, so two activities on the same chain can show different float values even though they drive the same finish.

The typical symptom is a critical path that seems to skip activities, or a chain where float jumps up and down along the path for no obvious reason. In P6, the setting for how total float is computed (start float, finish float, or the smaller of the two) also affects what you see.

If the critical path behaves strangely, filter the driving activities and check their calendars. Use as few calendars as the job genuinely needs, and make sure holidays and shutdowns are entered consistently. Longest path reporting helps here too, because it is less affected by calendar differences than a float threshold.

Cause 5: Out-of-sequence progress

On a real project, work rarely happens exactly in the order the logic says. A successor starts before its predecessor has finished, because the crew was available or the area opened up early. How the tool handles that out-of-sequence progress changes the remaining dates, and therefore the critical path.

In P6 this is controlled by the retained logic and progress override settings. Retained logic keeps the remaining work of the out-of-sequence activity waiting for its predecessor to finish. Progress override lets the remaining work carry on from the data date, ignoring the unfinished predecessor. The same update can produce a different critical path under each option. We cover that choice in detail in retained logic vs progress override in P6.

Whichever setting you use, keep it consistent between updates, and correct the logic where the sequence has clearly changed. If the site is going to keep working out of sequence, the links should say so.

Cause 6: Sloppy updating

A large share of critical path jumps come straight from the update process:

• The data date was not moved forward, or was moved inconsistently.
• Actual start and finish dates were not entered, so finished work still appears to have remaining duration.
• Remaining durations were not reviewed, so activities that are clearly behind still show their original time to go.
• Percent complete was updated but not linked to remaining duration, so the forward pass is working from stale numbers.

Each of these moves dates for reasons that have nothing to do with the site. A consistent update routine fixes most of it: set the data date, enter actuals, review remaining durations with the people doing the work, then schedule and compare against last period before anything is issued.

Cause 7: Lags, levelling and level-of-effort activities

A few smaller things can also shift the critical path:

• Long lags hide work and do not respond to progress the way an activity does. Replace large lags with real activities, such as curing, approval or delivery, where you can.
• Resource levelling can move activities and change which chain is longest. If levelling is part of your process, run it the same way each update and report the result with and without it when the path changes.
• Level-of-effort and summary activities can appear on the critical path when they are not driving anything. Exclude them from critical path reports, or make sure your tool's settings treat them correctly.

A simple routine to keep the path stable

1. Choose one critical path definition, preferably longest path, and state it in the narrative.
2. Run a logic and constraint check before every update.
3. Update consistently: data date, actuals, remaining durations, then schedule.
4. Compare the new critical path against last period's and explain any change in plain language.
5. Report near-critical paths alongside the critical path so changes are expected, not surprising.

When the critical path changes after that routine, people can trust that something real happened. That is the point of having a schedule in the first place.

If you have a programme whose critical path will not settle down, a logic and settings review is usually where the answer is, and it is the kind of work I take on as a freelancer.