Out-of-Sequence Progress and How to Clean It Up

Out-of-sequence progress is any work that started (or finished) before the logic says it could. Drywall started before the rough-in inspection was done. Rooftop unit setting started before the roof curbs were complete. It happens on every job, every month. A few instances are normal. Dozens, carried from update to update, mean the schedule no longer describes how the building is being built. This post covers how to find out-of-sequence progress, what it does to your dates, and how to fix it.

What counts as out of sequence

The logic says one thing; the field did another. Common forms:

The first one is by far the most common. The second often signals that a predecessor wasn't statused: the work was done, nobody marked it.

Why it happens

• The logic was too coarse. "MEP rough-in, Level 2" finish-to-start to "Hang drywall, Level 2." In reality, drywall starts in the east wing while the west wing is still being roughed. The logic didn't model that.
• The field found a better sequence. The super moved a crew to an area that was ready. Good for the job, bad for the logic.
• Predecessors weren't statused. The activity is physically done but nobody entered an actual finish.
• Workarounds. Temporary power used so terminations could start before permanent power. The relationship was real; the field worked around it.
• The relationship was never real. It was added to "connect things" during baseline development.

What it does to the schedule

How your software handles the remaining work depends on the scheduling option. Under retained logic, the remaining work on the out-of-sequence successor still waits for the predecessor to finish. Under progress override, the relationship is ignored and the successor continues from the data date. The difference can be significant. See Retained Logic vs. Progress Override for a worked example.

Either way, out-of-sequence progress causes problems:

• Under retained logic, successors can show a long gap or a stretched remaining duration that doesn't match reality.
• Under progress override, the predecessor can become a hidden open end with inflated float.
• In both cases, the critical path may run through activities that aren't really driving anything.
• Reviewers flag it, and a schedule with lots of it is harder to defend in a delay analysis.

Finding it

Most tools report it after scheduling. In Primavera P6, the schedule log lists activities with out-of-sequence progress. Other tools have filters or quality checks for it. If yours doesn't, filter for in-progress or complete activities that have at least one finish-to-start predecessor without an actual finish.

Run this check every update, right after entering progress and before making revisions. Track the count. If it goes up month after month, the logic is drifting away from the field.

Four ways to fix it

For each out-of-sequence activity, ask: what's the real relationship between these two pieces of work? Then pick one of these.

1. Status the predecessor

If the predecessor is actually done, or further along than shown, update it. This is the most common fix and the easiest. Talk to the super; the work is often 100% done and nobody updated it.

2. Change the relationship type

If the work really overlaps, model the overlap. A finish-to-start between rough-in and drywall becomes a start-to-start with a lag (drywall can start 5 days after rough-in starts) plus a finish-to-finish (drywall can't finish until 3 days after rough-in finishes). That pair describes trades following each other through a floor. See FS, SS, FF, SF and Lags and Leads.

3. Split the activities

If the work moves by area, break it up. "MEP rough-in, Level 2" becomes "MEP rough-in, Level 2 East" and "MEP rough-in, Level 2 West," each with its own drywall successor. More activities, but each relationship is now true. It also makes the update easier, since each area gets its own status.

4. Delete or re-point the relationship

If the relationship was never real, delete it. Before you do, make sure the successor still has a real predecessor; otherwise you've traded an out-of-sequence problem for an open end. If the successor actually depends on something else, link it to that instead.

A worked example

Convention: 0-based working days. Original logic, all FS:

Planned: A 0–15, B 15–17, C 17–25.

At data date day 12, A has 3 days remaining, B not started, and C started on day 10 with 6 days remaining. C is out of sequence: it started before both A and B finished.

Under retained logic, C's remaining 6 days wait for B. A finishes day 15, B runs 15 to 17, C runs 17 to 23. The schedule says ceiling grid will take from day 10 to day 23 for 8 days of work.

Talking to the super: the grid crew is working the corridor and the east half, which was inspected early in a partial inspection. The west half is still being roughed.

Fix by splitting:

Recalculate from the data date, day 12:

C1: remaining 2, from day 12        -> finish day 14
A2: remaining 3, from day 12        -> finish day 15
B2: ES = 15, EF = 16
C2: ES = max(B2 EF 16, C1 EF 14) = 16, EF = 20

Ceiling grid on Level 3 now finishes on day 20, not day 23, and nothing is out of sequence. Neither date is "right" by default; the split version is right because it matches what's happening on the floor. A2 following A1 with FS models one rough-in crew moving east to west; if separate crews work both halves at once, the logic would be different.

Preventing it

• Build the baseline at the level of detail the field works at: by floor and area, not by building. See How Many Activities Should a Schedule Have?
• Use SS/FF pairs where trades follow each other through an area.
• Review the logic with the superintendent before the baseline goes out.
• Update predecessors thoroughly. Many "out-of-sequence" flags are just unstatused work.
• When something goes out of sequence twice in a row, fix the logic instead of waiting for it to resolve.

Documenting the cleanup

Logic changes are revisions, and they belong in the narrative. A short table works:

Owners generally accept logic cleanup that's explained. What draws scrutiny is logic changing quietly, especially when it helps the completion date.

Key takeaways

• Out-of-sequence progress means the logic doesn't match the field; a few is normal, a lot is a logic problem.
• Check for it every update before revisions and track the count over time.
• Fix it by statusing predecessors, changing relationship types, splitting activities, or removing false relationships.
• Never delete a relationship without making sure the successor still has a real predecessor.
• Document every logic change in the narrative.