Out-of-sequence progress: the setting that quietly moves your completion date
There is a radio button in Primavera P6's scheduling options that changes the critical path, the total float and the forecast completion date of a progressed programme. It is almost never mentioned in a submission, it is rarely checked in a review, and on a real project it is worth weeks. If you receive contractor schedules, this is the first thing you should be looking for and probably the last thing anyone told you about.
What "out of sequence" actually means
A network says activity B follows activity A. The status update says B started three weeks ago and A is still running. The recorded facts and the recorded logic now contradict each other, and the software has to decide what to do about it before it can produce a forecast.
This is not an exotic condition. It is the normal state of every construction programme, because logic is written at a coarser grain than work is executed. "Blockwork" follows "slab", but in practice the slab is poured in bays and the blockwork starts on bay one while bay four is still curing. The logic was never wrong exactly — it was a summary, and the summary has been overtaken by the level of detail reality operates at.
The problem is not that out-of-sequence progress happens. The problem is that the schedule now contains a question the planner has not answered, and the software will answer it for them according to a setting most people have never opened.
Three answers, three different dates
P6 offers three ways to schedule activities that have progressed out of sequence. In the Schedule Options dialog they sit under "When scheduling progressed activities use", and the choice is stored with the project.
- Retained logic — the default. The remaining duration of the out-of-sequence activity is held until its predecessor finishes. The relationship survives the fact that it has already been violated.
- Progress override — the relationship is ignored for the remainder of that activity. Whatever duration is left is scheduled from the data date, as though the predecessor were not there.
- Actual dates — the forward and backward passes are run using the actual dates as recorded, which in practice means the analyst is taking responsibility for the sequencing by hand.
The same file, the same progress, the same data date. Three settings, three answers.
Five days on a two-activity illustration. On a real programme with two hundred out-of-sequence activities the difference is routinely measured in weeks, and it lands, more often than not, on the driving path.
Why progress override flatters
Progress override is the option that makes bad news go away, and it is worth being precise about the mechanism rather than merely disapproving of it.
When P6 encounters a progressed activity whose predecessor is incomplete, progress override does not repair the logic. It suspends it — for that activity, for the remainder of its duration. The remaining work is scheduled from the data date as if the predecessor relationship did not exist. The relationship is still in the file. It will still appear in a logic report. It simply stops constraining anything.
Two consequences follow, and the second is worse than the first.
The obvious one is that the forecast shortens. Every out-of-sequence activity is released from its predecessor, so the paths through them get shorter and the completion date pulls in. On a troubled project, where out-of-sequence working is most common precisely because the sequence has broken down, the effect is strongest exactly when the forecast most needs to be pessimistic.
The subtler one is that the released logic is invisible in every conventional review. A DCMA-style structural check will still count the relationship as present, so logic density and missing-logic percentages look healthy. The critical path will be computed through a network that is not the network you are reading. You can review the file for an hour and never see it, because the thing that changed is not in the data — it is in the setting used to interpret the data.
Retained logic is not automatically the honest answer
It is tempting to treat retained logic as correct and progress override as cheating. That is too simple, and a reviewer who says so will lose the argument to a competent planner.
Retained logic holds the remaining duration of the out-of-sequence activity until the predecessor completes. If the relationship was genuine — you truly cannot finish the blockwork until the whole slab is poured — that is exactly right. But if the relationship was a summary of a finer physical reality, retained logic manufactures a constraint that does not exist on site. The bay-one blockwork gang is working right now; the model says they must stop and wait for bay four. The result is a phantom delay: a forecast that is late for a reason no one on the project would recognise.
So the two settings fail in opposite directions. Progress override understates duration by deleting real constraints. Retained logic overstates it by preserving false ones. Neither of them is analysis. Both are the software's way of coping with a question the planner declined to answer.
What "actual dates" does, and why almost nobody uses it
The third option runs the forward and backward pass using the recorded actual dates. In effect it accepts the as-built sequence as given and calculates around it. It removes the argument between the other two settings by removing the model's opinion altogether.
It is rarely used on live programmes for a practical reason: it puts the entire burden of sequencing accuracy on manual data entry, and manual data entry on a schedule with several thousand activities is where errors live. It has a legitimate niche in forensic work, where you are reconstructing what happened rather than forecasting what will happen, and where the actuals have already been verified against records. On a monthly update cycle it is generally the wrong tool.
Progress override doesn’t repair the logic — it suspends it. The relationship stays in the file, looks healthy in every check, and constrains nothing.
The forensic problem: two revisions, two settings, no comparison
This is where the setting stops being a technical curiosity and becomes a commercial one.
A windows analysis, a time impact analysis, or any month-on-month comparison of forecast completion dates assumes the revisions are commensurable — that the difference between them reflects what happened on site. If revision 6 was scheduled under retained logic and revision 7 under progress override, part of the movement between them is a change of arithmetic, not a change of fact. Nobody looking at the two Gantt charts can see it.
AACE International's guidance on schedule update review, RP 53R-06, treats scheduling settings as part of what a reviewer must confirm has not silently changed between updates, alongside calendars, constraints and logic. The forensic recommended practice, 29R-03, is built on the same premise — that the analysis is only as reliable as the comparability of the schedules it runs on. In a dispute, "which scheduling option was each revision run under" is a fair and frequently decisive question, and it is one many contractors cannot answer after the fact.
Our own working rule: if the setting changed between two revisions, the delay between them cannot be attributed until the earlier revision is re-run under the later setting. It takes ten minutes and it removes an entire category of argument. See also the comparison of TIA and windows methods for where this bites hardest.
Fixing it properly
The right response to out-of-sequence progress is not to choose a setting. It is to find out what actually constrained the work and make the network say that. There are only four repairs, and between them they cover nearly every case.
| What really happened | The repair | Effect |
|---|---|---|
| The work is genuinely divisible — bays, floors, zones, systems | Split the predecessor and successor to match the physical increments, and relink | Removes the out-of-sequence condition entirely; the schedule now describes the work |
| The successor can start once the predecessor is partly done | Convert FS to SS with a lag, or FS with a negative lag replaced by a proper SS | Honest overlap, visible to everyone reading the logic |
| The relationship was never real — inherited from a template | Delete it, and record why in the schedule basis | Network gets simpler and more truthful; watch the float redistribute |
| The work was done in the wrong order and there will be consequences — rework, re-inspection, damage | Keep the logic, add the consequence as activities | The cost of working out of sequence appears in the forecast instead of vanishing into it |
That last row is the one that gets skipped, and it is the most valuable. Out-of-sequence working is frequently a symptom of disruption, and the disruption has a price. A schedule that quietly absorbs it with progress override has erased the evidence of its own damage.
How much out-of-sequence progress is acceptable?
There is no published threshold, and anyone quoting one is inventing it. The DCMA 14 has no out-of-sequence test — its "invalid dates" check catches actual dates in the future and forecast dates behind the data date, which is a different fault entirely. What matters is not the count but the trend and the response.
A handful of out-of-sequence activities in a monthly update on a large programme is normal and healthy — it means the team is recording what really happened rather than back-filling to match the plan. A number that grows every period, on the same paths, with no corresponding logic revisions, means the schedule and the project have separated and only one of them is being maintained. That is the signal worth reporting: not "there are 47 out-of-sequence activities" but "there were 12, then 29, then 47, and the logic has not been touched since March".
It is the same diagnostic logic as the rest of schedule quality — the trend across revisions carries more information than any single snapshot.
A note on Microsoft Project
MSP has no equivalent switch, which is not the advantage it first appears. Its scheduling engine will simply calculate around recorded actuals, splitting remaining work where necessary, which lands somewhere between P6's progress override and its actual-dates behaviour depending on task settings and whether split-in-progress tasks are enabled. The practical implication for anyone reviewing both formats: you cannot ask an MSP file "which option was this run under", so the out-of-sequence condition has to be detected from the data — actuals that precede their predecessors' finishes — rather than from a setting. Different mechanics, identical governance requirement.
Sources & further reading
- Oracle — Primavera P6 Professional User Guide, "Scheduling projects" and the Schedule Options dialog. The authoritative description of retained logic, progress override and actual dates, and of the scheduling log P6 writes on each run. docs.oracle.com — P6 Professional User Guide
- AACE International RP 53R-06, Schedule Update Review — As Applied in Engineering, Procurement and Construction. Sets out what a reviewer should confirm has not changed between updates, including scheduling settings, calendars, constraints and logic. Table of contents (AACE)
- AACE International RP 29R-03, Forensic Schedule Analysis. The method taxonomy that assumes comparable, contemporaneously maintained updates — the assumption a mid-project change of scheduling option breaks. See our summary: choosing your delay method.
- Trauner Consulting — How retained logic, actual dates and progress override deal with out-of-sequence progress. A clear practitioner walk-through of the three options on a worked network. traunerconsulting.com
- U.S. Government Accountability Office — Schedule Assessment Guide (GAO-16-89G), best practice 9. "Updating the schedule using actual progress and logic" — the clause that makes repairing the network, rather than changing the setting, the required behaviour. gao.gov/products/gao-16-89g
Key takeaways
- Out-of-sequence progress is normal. What is not normal is letting a scheduling option answer the question instead of the planner.
- Progress override suspends the violated relationship for the remainder of the activity and schedules it from the data date — shortening the forecast invisibly, because the logic is still in the file.
- Retained logic can invent a delay that nobody on site would recognise, when the relationship was a summary of divisible work.
- Two revisions run under different settings are not comparable, and any delay analysis across that boundary is unsafe until the earlier one is re-run.
- The real fix is one of four logic repairs — split, overlap, delete, or add the consequences of working out of order as activities. The last one is the one that preserves your evidence.
- Report the trend, not the count. Rising out-of-sequence numbers with untouched logic means the schedule and the project have parted company.
On your own schedule: compare two revisions and see what changed — logic, durations, constraints and dates, revision to revision, parsed in your browser with nothing uploaded.
See what moved between revisions
Load successive updates and get the full change list — added and deleted activities, re-logicked relationships, duration and constraint changes, and where the forecast moved as a result.