Out-of-sequence progress: retained logic, progress override, and what your dates are really telling you

What counts as out of sequence

Out-of-sequence (OOS) progress is progress recorded on a successor before its predecessor reached the state the relationship requires. The definition is per-relationship, and the relationship type matters:

• Finish-to-start. The successor has an actual start while the predecessor has no actual finish. This is the classic case and the bulk of what any OOS report will contain.
• Start-to-start. The successor has started while the predecessor has not started at all. Rarer, and usually a stronger signal that the modelled sequence and the site sequence have parted company, because SS links tend to encode a genuine enabling condition.
• Finish-to-finish. The subtle one. A started successor is fine under FF; the violation is the successor finishing while the predecessor is still open. FF pairs also produce the awkward half-state where the successor is nearly complete and the link's remaining pull applies only to its last day of work, which is why FF-heavy networks generate OOS noise that looks worse than it is.

Lags complicate each case in the obvious way: an FS plus 10-day lag is violated by a successor that starts nine days after the predecessor finishes, even though the bar chart looks sequential.

Why it happens on real projects

The network was a plan. The site is a set of crews moving to wherever work is available. When the predecessor stalls on a delivery or an approval, a competent superintendent does not stand the crew down to preserve the schedule logic, they open up the next available front. The schedule then records the truth, an actual start against a successor whose predecessor is still open, and the file is out of sequence. That is the statusing process working correctly. The alternative, fudging actual dates so the file stays "clean", is far worse, because it corrupts the as-built record to protect a diagram.

So one or two OOS activities in an update are ordinary life. The question is never whether they occur. It is what the scheduling tool does with the remaining work once they have.

P6: three treatments, three sets of dates

P6's schedule options offer three ways to calculate an in-progress activity whose logic has been violated, and they are worth stating exactly because the labels are widely repeated and less widely understood.

Retained logic keeps the relationship in force for the remaining work. The successor's actual progress stays where it happened, but its remaining duration is scheduled after the predecessor finishes, as the link always demanded. Dates come out conservative. The failure mode is a schedule that shows a half-built successor stopping dead to wait for a predecessor that, on site, it plainly no longer depends on: a forecast nobody on the project believes.

Progress override lets the remaining work proceed from the data date as if the violated relationship were not there. Dates come out aggressive. Be clear about what this really is: for that activity, the relationship's remaining force has been deleted. The link still appears in the relationships tab, which is precisely the trap, the network looks intact while parts of it no longer restrain anything. On a file with dozens of OOS activities, progress override quietly severs dozens of links and the completion date floats free of the logic that was meant to defend it.

Actual dates, the third option, changes how actuals that sit on the wrong side of the data date influence successors, and it can pull or push remaining work in ways that surprise even experienced P6 users. Most organisations avoid it for exactly that reason; if you inherit a file with it switched on, find out why before you re-schedule anything.

None of these is "the correct setting". Each is a different answer to a question the schedule cannot answer for itself: does the remaining work still depend on that predecessor or not?

Microsoft Project has no such switch

Schedulers who move between tools should know that MSP does not expose a retained logic versus progress override choice. It honours actuals where they were recorded, and it repositions incomplete remaining work according to its own calculation options, the status-date settings that move completed parts before the status date and remaining parts after it, and its willingness to split an in-progress task so the unfinished portion resumes later. The practical effect on an OOS pair usually resembles retained-style behaviour for the remaining split portion, but the mechanics differ enough that an MSP programme and a P6 programme statused from the same site data can legitimately disagree on the forecast. A reviewer comparing the two should establish the calculation settings on both sides before attributing the difference to anything real.

The review implication: settle it in the standard

Because the switch changes published dates, it cannot be a personal preference. Two P6 users opening the same file and reporting different completion dates by this setting alone is not a hypothetical, it is a routine month-end event on any project where the contractor schedules with override and the client's reviewer opens the file with retained logic. Each side accuses the other of manipulating the forecast, and both are simply running their own defaults.

The fix is procedural. The scheduling basis or the contract's programme requirements should state which treatment applies to submitted updates, and the reviewer's first act on any received file should be to read the schedule options, not the Gantt chart. Many public-sector and major-project specifications mandate retained logic for exactly this reason: it is the conservative default and it keeps the logic honest until someone deliberately changes it. If a contractor argues for override on a particular update, that is a conversation worth having, in writing, with the OOS list on the table.

The fix is neither setting

Arguing retained versus override is arguing about which wrong answer to publish. An OOS activity is the network telling you a relationship no longer describes the work. The durable response is to change the logic to match reality: sever the link that no longer applies, or convert the FS to an SS with an appropriate lag if the work is genuinely now running in parallel, or re-tie the remaining scope to whatever it actually waits on now. Do it as a deliberate, logged re-plan edit in the update narrative, with a reason against each change. Then the setting barely matters, because the file contains almost nothing for it to act on.

The counterargument arrives immediately on any contract-administered job: logic edits in a monthly update attract scrutiny, and some reviewers treat every severed link as an attempted manipulation. Fair. The answer is transparency rather than avoidance. A documented change with a stated reason survives that scrutiny; a file that carries fifty OOS activities month after month, with its forecast silently shaped by a scheduling option, does not survive a delay analyst later.

And watch the trend. A handful of OOS pairs each month, in different areas, reflecting ordinary opportunism on site, is fine to correct as you go. The same areas going out of sequence every single update means the network's sequencing assumptions are wrong at a structural level, and the job is a re-sequencing exercise on the remaining scope, not another month of tolerated exceptions. A schedule that must be overridden to produce a believable date has stopped being a model of the work.