Your Schedule Says This Can't Start Yet. The Field Already Did It Anyway.

Out-of-sequence progress is what happens when an activity gets marked started or complete before its predecessor's logic says it's allowed to — a concrete pour reported "in progress" while the excavation it depends on hasn't finished, a wall going up before the inspection that's supposed to gate it. The schedule's network logic says one thing has to happen before another; the field update says it didn't work out that way. In Primavera P6 (Oracle's project-scheduling software, the standard on most capital construction and DCMA-compliant programs) and the DCMA 14-point assessment (a set of schedule-health checks originally built by the Defense Contract Management Agency, now used broadly across construction and project controls), this gets treated as a real defect, not a rounding error. I'm Taj, building Ordo7 — here's what causes it, why it quietly wrecks your float and critical path, and what to do about it.

What out-of-sequence progress actually means

Every activity in a well-built schedule sits inside a chain of logic: a predecessor that has to happen first, a successor that depends on it finishing. Out-of-sequence progress shows up specifically on Finish-to-Start (FS) relationships — the most common link type in a P6 schedule, where Activity B isn't supposed to start until Activity A finishes. When B gets an actual start date while A is still open, the two disagree with each other. That specific mismatch — a predecessor with no actual finish date, paired with a successor that already has an actual start date — is the textbook definition, and it's exactly what the DCMA's Relationship Types check (Check 4 of the 14-point assessment) is watching for when it evaluates how much of your logic is genuinely FS-driven.

Takeaway: if an activity has an actual start date but its FS predecessor doesn't have an actual finish date yet, that's out-of-sequence progress — regardless of how healthy the rest of the schedule looks.

Why it happens: the field doesn't wait for the network diagram

Out-of-sequence progress usually isn't a data-entry mistake. It's what happens when field reality moves faster, or in a different order, than the logic anticipated. A sub gets ahead on rough-in because access opened up early. A punch item nobody planned around gets waived so the finish crew can keep moving. The plan assumed a strict order; the job site found a faster or just different one.

P6 gives you two settings — retained logic and progress override — that decide what happens to the remaining schedule once that gap shows up. Retained logic keeps the predecessor relationship in force for whatever duration is left, even though the successor already started; it's conservative but can produce dates that don't match the field. Progress override lets the successor's actual progress stand and effectively ignores the unfinished predecessor going forward. Neither setting fixes the underlying problem — they just decide how the schedule copes with it.

Takeaway: don't just toggle retained logic vs. progress override to make the dates look better — go find out why the field got out of sequence in the first place.

Why it distorts your critical path and float

This is the part that actually costs you. Total float and the critical path are both calculated from the network logic — what's actually driving what. When an activity's real-world progress no longer matches its logic, the float and critical-path math downstream of it is being computed against a network that no longer reflects what's true. An activity can show float it doesn't really have, because the calculation still assumes a predecessor relationship the field has already broken. Or the reported critical path quietly shifts to a chain of activities that isn't actually what's driving the finish date anymore.

Left uncorrected, it compounds. Every recalculation after the first out-of-sequence update inherits the same distortion, and a scheduler trusting the critical path at face value ends up managing the wrong activities.

Takeaway: treat every out-of-sequence flag as a signal to re-verify float and critical path on everything downstream of it, not just the one flagged activity.

How to find it in P6 — and where Ordo7 fits in today

In P6, run the schedule log or a filter for activities with an actual start date whose FS predecessor has no actual finish date — that combination is out-of-sequence progress, activity by activity. Most schedulers catch it during the routine update review, which is exactly the kind of check that's easy to skip when there are 2,000 activities and a status meeting in twenty minutes.

This is where Ordo7 fits in today, and I'd rather be precise about the boundary than let you assume more than what's actually built: Ordo7's out-of-sequence check currently runs on Primavera P6 .xer files only (P6's native export format). It looks for exactly the pattern above — an FS predecessor relationship where the predecessor has no actual finish date but the successor already has an actual start date — and flags it as a critical issue. That check isn't yet implemented for the CSV or Microsoft Project XML import paths Ordo7 also accepts, so if you're working from one of those formats, this specific check won't run on your file yet.

Takeaway: if you're scheduling in P6 and exporting .xer, this is a check you can automate instead of eyeballing row by row. If you're on CSV or MS Project XML today, keep doing this one manually until that coverage lands.

How to fix it

Fixing out-of-sequence progress means going back to the logic, not just the dates. Talk to the field about why the sequence didn't hold — was the original logic wrong, was there a real acceleration, was a step skipped that shouldn't have been? Then either correct the relationship (add a lag, change the relationship type, or split the activity to reflect what actually happens in what order) or correct the field process so the real sequence matches the plan going forward. A schedule "fixed" by just picking retained logic or progress override without addressing the why will keep generating the same distortion on the next update.

For the rest of the DCMA-style checks Ordo7 runs today — missing logic, negative float, hard constraints, high duration, invalid dates, and this one — see the full walkthrough in The DCMA 14-Point Check, Explained Without the Jargon.

If you're carrying a P6 schedule right now and want to see where your own out-of-sequence flags are, upload the .xer file to Ordo7 and get a plain-language read on it in a few minutes.