Out-of-sequence progress is a schedule condition that project controls professionals encounter regularly and address inconsistently. It occurs when a successor activity is reported as having started or progressed before its predecessors are complete. It seems, at first glance, like a minor data quality issue — a status entry that does not match the network logic. In practice, it is one of the most consequential integrity problems in schedule analysis, because it corrupts the earned value calculations, float computations, and critical path determinations that depend on the schedule as their source data.
A schedule with significant out-of-sequence activity is not a reliable source of performance data. It is a schedule that has partially detached from reality.
Why Out-of-Sequence Progress Happens
On active construction and capital projects, work does not always proceed in the order the network assumed. Field crews start work when materials arrive, when access becomes available, or when labor is mobilized — not necessarily when the network predecessor logic would dictate. A concrete pour might begin before the preceding rebar installation has been formally completed and statused. Mechanical installation might start in a completed zone while adjacent areas are still under prior-phase work.
Some out-of-sequence progress reflects genuine, legitimate overlap. Construction practices often allow parallel or overlapping operations that a finish-to-start relationship in the schedule does not fully capture. When this is the case, the appropriate response is to update the schedule logic to reflect the actual execution strategy — modifying the relationship type, adjusting the lag, or splitting the work packages to reflect the actual sequencing.
What actually happens on most programs is different. The out-of-sequence condition is noted, sometimes flagged in a scheduler's comments, and then left unresolved. The schedule is statused with the out-of-sequence progress intact, and the downstream calculations proceed as if the logical inconsistency is not there.
What the Scheduling Engines Do With It
P6 and MS Project handle out-of-sequence progress differently, and both approaches have significant consequences.
P6 uses a "retained logic" setting by default. Under retained logic, when a successor activity has been started before its predecessor is complete, P6 does not allow the successor to be scheduled ahead of the predecessor's projected completion. The result is that the successor activity's remaining work is held until the predecessor finishes — even though work on the successor has already started. This produces a gap in the schedule: the activity shows actual start dates in the past but projected completion dates pushed into the future, held by logic that the actual field conditions have already violated.
Under the "progress override" setting, P6 ignores the predecessor constraint for activities that have already started. The successor is scheduled based on its own remaining duration, unconstrained by the incomplete predecessor. This produces dates that may be more realistic for the activity itself but creates a logical inconsistency — a network that claims the work can complete without its defined preconditions being met.
Neither setting resolves the underlying problem. Retained logic produces artificially delayed dates for activities already in progress. Progress override produces logically inconsistent networks. Both distort the critical path and float calculations that depend on network integrity.
The EVMS Consequence
In an EVMS context, out-of-sequence progress contaminates earned value calculations in a specific way. When a successor activity earns value before its predecessor is complete, the earned value credit is booked against a scope that the network says cannot yet have been accomplished. The PV corresponding to the predecessor work is also still running. The result is a combination of premature EV credit on the successor and continuing planned value burn on the predecessor — a double-count effect that makes performance appear better than it is.
On programs with significant out-of-sequence activity, this effect is not trivial. A control account with 15% of its activities in out-of-sequence status can show SPI values that are substantially inflated relative to true physical progress. The management team is reading performance metrics derived from a schedule that does not accurately reflect what work has and has not been completed.
DCMA's 14-Point Assessment does not have a specific metric for out-of-sequence progress as a percentage of the schedule. It is addressed indirectly through the schedule logic completeness checks, but a schedule can pass all 14-point thresholds while carrying a significant out-of-sequence problem.
Detection and Resolution
Detecting out-of-sequence progress requires a comparison of actual start dates against the completion status of predecessor activities. In P6, activities with actual start dates and incomplete predecessors are identifiable through schedule analysis filters. The volume of out-of-sequence activities, expressed as a percentage of all in-progress activities, is a meaningful schedule health indicator.
Resolution requires a judgment: is the out-of-sequence progress reflecting a legitimate change in execution strategy, or is it a statusing error? If the former, the schedule logic should be updated. If the latter, the status should be corrected. What should not happen — but frequently does — is carrying unresolved out-of-sequence conditions through successive reporting periods without addressing the underlying network integrity problem.
Programs with persistent out-of-sequence activity are programs whose schedule cannot be trusted to produce reliable critical path, float, or earned value data. The schedule is statused. It is reported. It passes routine reviews. And the data it produces is wrong.
The Forensic Intelligence Engine identifies out-of-sequence activity concentration, quantifies the earned value impact of premature successor progress, and flags unresolved logic conflicts between actual dates and predecessor status — before those conflicts corrupt the program's performance metrics.