Critical Path Analysis: What Changes Between Updates and Why It Matters
The critical path shifts between schedule updates in ways that carry real consequences. Here is how to track those changes and understand what is driving them.
Some project teams check the critical path once — when the baseline is approved — and then largely ignore it until something goes wrong. That is a mistake. The critical path is not a fixed feature of a schedule. It shifts between updates in response to progress, delays, logic changes, and constraint additions, and those shifts carry real consequences for project risk and delay attribution.
This post explains what drives critical path changes between updates, how to detect them, and why tracking those changes matters both for project management and for claims documentation.
What the Critical Path Actually Is
In Primavera P6, the critical path consists of activities where total float is less than or equal to the critical float threshold — by default, zero. Any activity with total float of zero or below is critical: a delay to that activity, without mitigation, delays the project completion date.
A few things worth clarifying:
The critical path is calculated, not assigned. It is the output of the CPM network calculation based on the activity durations, logic relationships, and constraints in the schedule. You cannot simply declare an activity critical — it becomes critical because of the network.
There can be multiple near-critical paths. Activities with small positive float (say, 5-10 days) are near-critical. A modest delay to any of them can make them critical. Managing only the zero-float path without watching near-critical activities is a common source of surprises.
The critical path length index (CPLI) measures the efficiency of schedule execution on the critical path. Change Inspector's Health Check module calculates CPLI as (Critical Path Duration + Average Float of Critical Activities) ÷ Critical Path Duration. A CPLI below 1.0 indicates the project is behind on its critical path.
What Causes the Critical Path to Shift
Progress and Delay
The most common cause of critical path movement is simply progress — or the lack of it. When a critical activity finishes on time, the next activity in the chain becomes critical. When a critical activity is delayed, the delay propagates forward through the network.
Activities that were not critical can become critical when near-critical activities accumulate enough delay to consume their float. This is called a near-critical path becoming critical, and it is often a surprise to project teams who were focused only on the previously identified critical path.
Logic Changes
Logic changes are the most consequential and least visible driver of critical path shifts. When a predecessor relationship is removed from a critical activity, that activity may float off the critical path — not because the work is ahead of schedule, but because the constraint was eliminated. Conversely, adding a new predecessor to a previously non-critical activity can make it critical overnight.
This is why the Relationships tab of a schedule comparison deserves careful attention. A logic change that shifts the critical path is a material schedule event, even if no dates visibly moved.
Constraint Changes
Hard constraints — Must Start On, Must Finish On — can force activities onto or off the critical path regardless of what the network logic would otherwise calculate. A Must Start On constraint set to a future date can give an activity negative float even if there is no real delay to its predecessors. Tracking constraint changes between updates is therefore part of understanding critical path movement.
Duration Changes
If an activity's remaining duration is revised upward — reflecting that the work will take longer than originally planned — the activity and all its successors move later. If those activities were on the critical path or near it, the project completion date moves accordingly.
How to Track Critical Path Changes in Change Inspector
Change Inspector surfaces critical path changes across several modules:
Activities tab — Critical activities filter. The Activities tab in the Compare module shows total float values before and after for every changed activity. Activities with TF ≤ 0 in the current schedule are critical. Comparing TF values between the two updates tells you which activities gained or lost criticality.
Relationships tab. Review all logic changes, paying particular attention to relationship additions and removals on activities that are currently critical or that were critical in the previous update.
Health Check — Critical Path Length (Check 12). This check reports the percentage of non-complete activities on the critical path. A sudden significant increase in critical activity percentage between two updates signals that the critical path expanded — often indicating a schedule problem.
Health Check — CPLI (Check 13). CPLI below 1.0 on the current schedule but at or above 1.0 in a previous update indicates that critical path performance has deteriorated.
Float Consumption analysis. The Float Consumption section in the Health Check module shows the top activities by float consumed between two files. Activities that have gone from positive float to critical (TF ≤ 0) are flagged with a warning. These are the activities to focus on immediately.
Critical Path Changes in a Claims Context
In a delay claim, the critical path at the time of the delay event is central to the analysis. A delay only extends the project completion date if it affects an activity that was on the critical path at the time the delay occurred. An owner-caused delay to a non-critical activity with 30 days of float does not, by itself, entitle the contractor to time relief — even if the activity eventually became critical later.
This is why contemporaneous critical path documentation matters. If you tracked the critical path at each update cycle and have the comparison reports to prove it, you can demonstrate exactly which activities were critical when a delay event occurred. Without that documentation, the critical path at any given point in the past is a matter of reconstruction and argument.
Monthly schedule comparison reports that include critical path data — saved and archived at each update — are the best contemporaneous record available.