Out-of-sequence progress

Last reviewed 9 September 20262,653 words12 min read

When the actual dates break the logic you built

🟩 In one line Out-of-sequence progress is an activity that has started before its predecessor finished — or more generally, actual dates that contradict a relationship. It's normal, it's not a crime, and it's not always a logic error. But every instance needs a decision, and the decision needs writing down.

👤 Who this is for Junior planners seeing "out-of-sequence" in the schedule log and not sure whether to panic. Mid-level planners doing the update and choosing between fixing the logic and leaving it. Reviewers, who need to tell the difference between a schedule that's been maintained and one that's been overridden.

e / c

First, let's be honest about why this page exists

Site does not read the schedule. Not in the way planners imagine. A foreman with a crew and a free work front will use the crew and the work front, regardless of whether the network said the previous trade should finish first. Most of the time they're right to. Idle crews cost money; a partially available floor is still a floor.

So every live schedule accumulates out-of-sequence progress. The question isn't how to prevent it. The question is what it's telling you — and there are three quite different possibilities:

The data is wrong. Someone typed the wrong actual date, or the predecessor finished and nobody statused it.
The logic was wrong. The relationship was a preference, not a physical constraint, and site has found a better sequence.
The logic was right and site has taken a risk. They've started the successor, but they genuinely can't finish it until the predecessor's done.

Each one needs a different response, and the wrong response — usually "delete the link so the warning goes away" — is how schedules stop being evidence.

🟨 The standard — what "good" looks like

An activity is out of sequence when it has an actual start (or finish) that violates one of its predecessor relationships — most commonly, it has started while an FS predecessor is still incomplete.

What the standards expect:

P6 lists out-of-sequence activities in the schedule log under Activities in progress out of sequence, every time you schedule. How it treats their remaining work depends on the Retained Logic / Progress Override setting.
DCMA 14-Point has no dedicated metric, but out-of-sequence progress feeds Metric 9 (Invalid Dates) when it produces forecast dates before the data date, and reviewers routinely report the count alongside the 14 metrics.
GAO Schedule Assessment Guide, Best Practice 8 — out-of-sequence progress should be identified at each update, and logic corrected where it no longer reflects the plan for remaining work. Leaving large volumes of out-of-sequence logic in place makes the forecast unreliable.
AACE RP 53R-06 (Schedule Update Review) — recommends each out-of-sequence instance be reviewed and either the logic revised (with the change recorded) or the reason for retaining it documented.
SCL Protocol, 2nd ed., Guidance Part B — the updated programme should reflect the contractor's actual intended sequence for remaining work. Logic that site has abandoned should be revised, and the revision recorded, so that the programme remains a fair basis for assessing delay.
Gulf client specs — many require the monthly narrative to include a table of out-of-sequence activities with the action taken, and some cap the number permitted in a submitted update.

🟢 The standard is not "zero out-of-sequence." It's "every out-of-sequence instance reviewed, decided, and the decision recorded." A schedule with twelve out-of-sequence activities and a table explaining each is healthy. A schedule with none because the links were deleted is not.

How it actually works

How P6 detects it

When you schedule, P6 checks every relationship against the actual dates. If an activity has an actual start and any FS predecessor has no actual finish, it's out of sequence. Same if an SS predecessor hasn't started, or if an FF successor has finished before its predecessor. The log lists them. The count is right there.

What P6 does with the remaining work

This is where the Retained Logic / Progress Override setting comes in (full page: retained-logic-vs-progress-override). In short:

Retained Logic — remaining work on the out-of-sequence activity is held until the incomplete predecessor finishes. The link still applies to what's left.
Progress Override — the incomplete predecessor is ignored. Remaining work carries on from the data date.

Under Retained Logic, a heavily out-of-sequence schedule can produce forecasts that are too pessimistic — activities 90% done shown waiting for predecessors they no longer need. Under Progress Override, the opposite — activities shown finishing before the things they physically depend on. Neither setting fixes out-of-sequence logic. Only revising the logic does that.

The review, instance by instance

For each activity in the out-of-sequence list, three questions in order:

1. Is the data right? Check the actual start on the successor. Check whether the predecessor has actually finished and just wasn't statused. Check whether the dates are in the right month. A surprising share of out-of-sequence entries are data errors — the predecessor finished on the 20th, the site engineer didn't report it, and the successor started on the 22nd. Status the predecessor and the warning disappears.

2. Was the relationship hard or soft? Hard logic is physics — you can't pour before you've fixed rebar, you can't close the ceiling before the duct test. Soft logic is preference — crew sequencing, "we'd normally do this room first." If the relationship was soft and site has found a workable alternative, the logic is now wrong for the remaining work. Fix it. If the relationship was hard, site has started something they can't finish, and the logic should stay.

3. If the logic stays, is Retained Logic producing a sensible forecast? Sometimes it is — the successor genuinely can't finish till the predecessor's done, and P6 has it right. Sometimes the relationship type needs adjusting rather than deleting: an FS that should now be an FF, because the finish is what's constrained, not the start. Change the type, keep the link, log it.

Whatever you decide, write it down. Activity ID, the relationship, what changed (or didn't), why, who confirmed it. This is the change log the statusing-a-schedule page keeps coming back to. Out-of-sequence decisions are its most important entries.

🟥 Where people go wrong

1. Deleting the relationship to clear the warning. The out-of-sequence list has 30 entries. Someone removes the 30 offending links. List is empty. Thirty activities now have no controlling predecessor for their remaining work. Half of them probably still needed one. And in a delay analysis later, 30 deleted relationships in one update looks exactly like what it is.

2. Ignoring it entirely. The log says 45 out-of-sequence activities. Nobody looks. Retained Logic holds their remaining work behind predecessors site has long since worked around. The forecast is three weeks pessimistic and the PM decides the schedule is useless. He's not wrong, but the fix was an afternoon's work.

3. Switching to Progress Override instead of reviewing. Covered at length elsewhere. It makes the pessimism go away without touching the logic, and it applies to every out-of-sequence activity equally — including the ones where the logic was hard and still binding.

4. Not checking the data first. Twenty minutes of logic surgery on a relationship that was fine — the predecessor had simply finished and nobody entered the date. Always status the predecessor first, reschedule, and see what's left.

5. Deciding without site. Whether the relationship was hard or soft, and whether site has genuinely found an alternative sequence, is a question for the people doing the work. A planner guessing from the office gets it wrong often enough to matter. Take the list to the site engineer. Ten minutes per week.

6. Letting it accumulate. Five out-of-sequence activities in month three, fifteen in month four, forty by month six. Each month it's "we'll sort it in the revised baseline." By the time the revised baseline comes, the network no longer describes the job and it's a rebuild. Deal with them monthly.

7. Changing logic without logging. The fix is right — FS to FF, sensible reason. But it's not written down. Next month's comparison report shows a logic change nobody can account for. In a claim, the other side's expert lists it under "unexplained changes to the contractor's programme." Every one. Log it.

⚖️ When you're challenged

"The log says 28 out-of-sequence activities. That sounds like a lot." "It's a fit-out floor where site has opened three rooms at once instead of finishing them in order. Eight were data — predecessors finished and not statused, fixed. Fourteen were soft logic I've revised to SS/FF pairs so the remaining work models what they're actually doing; all logged. Six are hard — the ceiling closures — and they stay, because site has started them but genuinely can't finish till the duct tests. Table's in the narrative."

"Just delete the links. Site's already done it their way." "Some of them, yes — where the logic was only ever a preference. But six of these are physical. If I delete the ceiling-to-duct-test link, the forecast shows ceilings closing before the test that has to happen first. When the test slips, the ceiling date won't move and we'll find out on site. I'd rather keep those links and change the type so they hold the finish, not the start."

"Why has the forecast got worse? Site is ahead on Level 3." "Site's ahead on the starts. Retained Logic is holding the finishes behind first-fix, which is still open in the last two rooms. If I change those links from FS to FF+2 — which is what's physically true now — the forecast comes in by about a week. I'll do it and log it."

"The client has asked why we changed 14 relationships this month." "Because site re-sequenced Level 3 and the logic needed to follow. Each one's in the change log with the reason, and they're listed in the narrative under out-of-sequence review. Retained Logic throughout, no constraints added. Happy to walk them through it."

📄 Related pages

Retained logic vs progress override — the setting that decides how P6 treats remaining work on these
Hard Logic vs Soft Logic — the question at the centre of every out-of-sequence review
Relationship types explained — why FS→FF is often the right fix
Statusing a schedule — step 7, where this review sits in the update
Monthly update checklist — the Phase 2 line for this
Schedule Narrative — where the out-of-sequence table goes
P6 Schedule Comparison — how the client sees your logic changes
Time Impact Analysis — why unexplained logic changes are a problem later

✏️ Worked example

A single floor of a residential tower. 6-day calendar. Data date 25 May. Three activities in the original logic:

ID	Activity	Dur	Logic
B100	Blockwork — Level 6	12 days	—
M100	MEP first-fix — Level 6	10 days	B100 FS
P100	Plaster — Level 6	8 days	M100 FS

What happened by 25 May:

B100 started on time, but the block crew moved to Level 7 for three days to keep the structure moving. Site says B100 has 3 days remaining.
M100 started on 19 May — the MEP crew arrived as planned and started in the four apartments where blockwork was complete. Site says 7 days remaining.
P100 not started.

After F9 with Retained Logic, the schedule log lists M100 as out of sequence: it has an actual start, and its FS predecessor B100 is incomplete.

Retained Logic result before any review:

Activity	Remaining	Forecast finish
B100 Blockwork	3	28 May
M100 MEP first-fix	7	5 June — held until B100 finishes, then 7 days
P100 Plaster	8	15 June

The MEP crew's early start has bought nothing. M100's remaining 7 days sit after B100. The forecast is pessimistic — the MEP crew is genuinely working now, in the four finished apartments.

The review:

Is the data right? Yes — B100 really is unfinished (two apartments to go), M100 really did start on 19 May.

Was the link hard or soft? Soft at the start, hard at the finish. MEP can start in any apartment that's blocked. But the last apartment's MEP can't finish until the last apartment's blockwork is done — and it needs a day or two after.

Decision: change B100→M100 from FS to FF+2. The start is no longer constrained (it's already happened). The finish is held to 2 days after blockwork finishes. Logged: "B100–M100 changed FS to FF+2. MEP first-fix commenced 19 May in completed apartments; remaining constrained by final two apartments only. Confirmed with site engineer 25 May."

Retained Logic result after the change:

Activity	Remaining	Forecast finish
B100 Blockwork	3	28 May
M100 MEP first-fix	7	1 June — the later of (data date + 7) and (B100 finish + 2)
P100 Plaster	8	10 June

Five days recovered, not by trimming anything, but by making the logic describe what's true now. The link is still there. If B100 slips another week, M100's finish slips with it — because it should.

For comparison — what Progress Override would have done without any review:

Activity	Forecast finish
M100 MEP first-fix	1 June (data date + 7, link ignored)
P100 Plaster	10 June

Same date today, by coincidence. But if B100 then slips to 5 June, Progress Override still shows M100 finishing 1 June — four days before the blockwork it's going into. The FF+2 model would correctly move M100 to 7 June. Same answer this month; only one of them is right next month.

The out-of-sequence table in the narrative for this floor reads:

Activity	Predecessor	Finding	Action
M100 MEP first-fix L6	B100 Blockwork L6	Started 19 May in completed apartments; finish constrained by last two apartments	FS changed to FF+2; logged

One line. That's what a maintained schedule looks like.

📖 References

AACE International, RP 53R-06, Schedule Update Review — As Applied in Engineering, Procurement and Construction
US GAO, Schedule Assessment Guide (GAO-16-89G) — Best Practice 8
SCL, Delay and Disruption Protocol, 2nd ed. (2017) — Guidance Part B §§ 1, 4
DCMA, 14-Point Schedule Assessment — Metric 8; general guidance on out-of-sequence review
NEC4 ECC — Cl. 32.1 (revised programme to show changes to previous programme)
Oracle, P6 Professional User's Guide — Schedule Log, "Activities in progress out of sequence"

One housekeeping note first: in Batches 2–4 I referred to "Invalid Dates" as DCMA Metric 8. It's Metric 9; Metric 8 is High Duration. The DCMA page below uses the correct numbering throughout — please correct those earlier references when you publish (data-date, statusing, monthly-update-checklist, retained-logic, out-of-sequence). Everything else was right.

From the field

Experience from working planners. Unreviewed — read it as experience, not guidance.

Add what you know about out-of-sequence progress. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.

Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.

Add your experience