Schedule Compression: How to Detect It Before It Becomes a Problem

Schedule compression rarely announces itself. It does not show up as a single dramatic event. It accumulates quietly — a few days of float consumed each update cycle, durations that shrink just enough to keep the completion date from moving, logic that gets tightened in ways that mask the real state of the project.

By the time compression is obvious, it is usually already a problem. The goal of good schedule monitoring is to catch it early — when you still have options — rather than after the fact.

This post explains what schedule compression looks like in a P6 schedule, how to detect it using float analysis and comparison reports, and what early warning signs to act on.

What Schedule Compression Is

Schedule compression is the process by which a schedule loses its buffer — the float, the realistic durations, and the logical sequencing that originally made it a credible plan.

It happens in several ways:

Float erosion. Activities consume their total float as delays accumulate. Each update cycle a few more days disappear. After six months of a few days per cycle, a 45-day buffer has become a 5-day buffer — and the project is now highly sensitive to any further delay.

Duration compression. Remaining durations get shortened to keep the schedule looking on track even when actual progress does not support the revision. A 20-day remaining duration becomes 14 days without a legitimate basis for the change.

Logic manipulation. Predecessor relationships get removed or modified to float activities off the critical path. The schedule looks healthier than it is because the constraints that were driving criticality have been eliminated rather than addressed.

Constraint additions. As float erodes, schedulers sometimes add constraints to hold dates rather than letting the network calculate them honestly. This hides the compression rather than resolving it.

The Float Erosion Pattern

The most reliable early indicator of schedule compression is consistent float erosion across multiple update cycles. A single update where float drops 5 days may be unremarkable. The same drop in each of six consecutive updates represents 30 days of consumed buffer — a significant and potentially critical trend.

This is why running schedule comparisons at every update and tracking float across time matters. A single snapshot tells you the current state. The trend across updates tells you the trajectory.

In Change Inspector's Float Consumption analysis, you can compare any two schedule files and see the top activities by float consumed — with before-and-after values. Running this at each update and noting the pattern across the project history gives you an early warning system for compression.

The DCMA High Float check (Check 6) approaches this from the other direction: it flags activities with too much float, which can indicate missing logic. But it is the combination of tracking high float activities over time and watching for rapid float decline on near-critical activities that gives you the full picture.

Duration Compression Red Flags

When reviewing schedule updates, watch specifically for remaining duration changes on in-progress or not-started activities. Duration reductions on incomplete activities should always have a legitimate basis — a productivity improvement, a scope reduction, additional resources being applied.

Duration reductions that coincidentally keep the completion date from moving, without any corresponding field event or resource change, are a red flag. They may indicate that the scheduler is managing the completion date rather than honestly reporting the forecast.

In Change Inspector's Activities tab, filter for Changed activities and look specifically for the Remaining Duration field. Sort by the magnitude of duration changes to prioritize your review.

Logic Changes That Indicate Compression

When a schedule is under pressure, logic changes that are not driven by legitimate construction sequencing reasons are worth scrutinizing. Specific patterns to look for:

Removed predecessors on critical activities. A predecessor removed from a critical activity may be legitimate — the field team confirmed the sequence can change. Or it may be removing a constraint that was accurately modeling a real dependency, with the result that the activity gains float it should not have.

New start-to-start or finish-to-finish relationships. SS and FF relationships with lags are sometimes added to compress activity sequences in ways that would not be possible with Finish-to-Start logic. Adding these relationships late in a project, where they were not in the baseline, deserves scrutiny.

Lag reductions. Lags that shrink between updates — a 10-day cure time that becomes 5 days, a 15-day review period that becomes 7 — may be legitimate in some cases and schedule compression in others.

What to Do When You Detect Compression

When the pattern of float erosion, duration reduction, or logic manipulation suggests compression, the appropriate response depends on the situation:

If you are the GC reviewing a subcontractor schedule: raise the specific findings in writing. Request justification for duration changes and logic modifications. Do not accept the schedule until the changes are explained and, where appropriate, supported by field documentation.

If you are the owner's representative: flag the pattern in your schedule review report. Request a schedule recovery analysis showing how the contractor plans to complete within the contract dates given the current state of float.

If you are the contractor: the compression is a signal that the schedule needs attention. Options include adding resources, revising sequences with legitimate field-driven logic changes, or formally notifying the owner that the schedule is at risk and requesting a time extension if the compression is caused by owner-directed changes.

In all cases, the documentation of when compression began and what caused it is essential. Change Inspector's comparison reports, run consistently at every update cycle, provide that documentation automatically.