Retained Logic vs. Progress Override

Retained logic and progress override are two ways a CPM scheduler handles one specific situation: an activity started before its predecessor finished. That's it. They don't matter for activities that progress in the planned order. But on a real job, out-of-sequence work happens every month, and the setting you pick can move the critical path and the completion date by days or weeks. This post explains what each one does, works an example both ways, and gives a recommendation.

The situation they address

Say the logic says drywall hang on level 2 can't start until MEP rough-in inspection on level 2 is finished (finish-to-start). In the field, the drywall crew started hanging the corridor while the inspector still had a few rooms left. Now drywall is in progress, but its predecessor isn't done.

The scheduling engine has to decide: does the remaining drywall work still wait for the inspection to finish, or does it carry on as if the relationship no longer applies?

• Retained logic says the relationship still holds for the remaining work. The unfinished part of drywall can't proceed until the inspection finishes.
• Progress override says the relationship has been overtaken by events. Once drywall has started, the predecessor no longer restrains it, and the remaining work continues from the data date.

Primavera P6 offers both as a project-level scheduling option, plus a third, Actual Dates, that is less commonly used on construction jobs. Microsoft Project doesn't use these labels; its handling depends on status date and task-splitting settings, so test it on a copy before assuming anything.

Worked example

Convention: 0-based working days. ES of the first activity is 0, EF = ES + duration, and a finish-to-start successor's ES equals the predecessor's EF.

Three activities in a simple chain, all finish-to-start, zero lag:

As planned: A runs 0 to 10, B runs 10 to 15, C runs 15 to 23. Project finish is day 23.

Now the status at data date = day 6:

• A started on day 0 and has 4 days remaining.
• B started on day 4, out of sequence, and has 3 days remaining.
• C has not started.

Retained logic

The A-to-B relationship still restrains B's remaining work. A finishes at data date + 4 = day 10. B's remaining 3 days can't resume until then.

A: remaining 4, from day 6  -> finish day 10
B: remaining 3, waits for A -> resumes day 10, finish day 13
C: starts after B           -> day 13 to day 21
Project finish: day 21

Progress override

The A-to-B relationship is ignored for B's remaining work, because B already started. B continues from the data date.

A: remaining 4, from day 6  -> finish day 10 (drives nothing)
B: remaining 3, from day 6  -> finish day 9
C: starts after B           -> day 9 to day 17
Project finish: day 17

Comparing the two

Same progress, same network, four days apart. Under progress override, A has effectively become an open end: nothing waits on it. If A is a real constraint on the remaining drywall (and inspection usually is), progress override is now telling you something false.

Which one is right?

Neither is universally right. They make different assumptions:

• Retained logic assumes the original relationship reflected a real dependency that still applies to the unfinished work. It's conservative. It tends to produce later finishes.
• Progress override assumes the field has shown the relationship wasn't really binding. It's optimistic. It tends to produce earlier finishes and hides the predecessor's influence.

In most construction cases, retained logic is closer to reality. The drywall crew started the corridor, but they really can't close the rooms the inspector hasn't seen. Formwork for an elevated deck started before shoring was complete in one bay, but the deck still can't be poured until it is. The relationship was partly true all along.

Retained logic is the default in P6 for a reason, and many specs and owner reviewers expect it. Some specs name the option required; if yours does, follow it.

The better answer: fix the logic

Both settings are ways of dealing with logic that no longer describes how the work is being done. The real fix is to correct the logic so it matches the field:

• If drywall can really start once rough-in is substantially done in some areas, change the FS to a start-to-start with lag, or split the activities by area. See FS, SS, FF, SF.
• If the predecessor truly no longer restrains the successor, delete or re-point the relationship and note it in the narrative.
• If the out-of-sequence start was a one-off, retained logic will handle it and the issue goes away once the predecessor finishes.

Out-of-Sequence Progress and How to Clean It Up covers the cleanup process in detail.

Practical rules

1. Pick one setting at the start of the project and keep it every month. Switching between updates changes the critical path for reasons that have nothing to do with the work, and a forensic analyst will notice.
2. State the setting in the narrative or the update submission.
3. Run an out-of-sequence report every update. In P6, the schedule log lists out-of-sequence activities after scheduling.
4. Don't use progress override to make a late schedule look better. A reviewer comparing to the prior update can see the open ends it creates.
5. When an activity shows up out of sequence two months in a row, the logic is wrong. Fix it.

How it plays out in delay analysis

In a time extension request or a forensic analysis, the scheduling option affects which path was critical in each update. If the owner's expert re-runs your updates with a different setting than the one you used, the critical paths may not match your narrative. That's one more reason to be consistent and document your choice. For more on how updates get used in analysis, see As-Planned, As-Built, and Windows. Contracts and specs vary on these requirements, so read yours, and talk to counsel if a claim is involved.

Key takeaways

• Both settings only matter when a successor starts before its predecessor is complete.
• Retained logic keeps the predecessor restraining the remaining work; progress override drops it.
• Progress override typically gives earlier finishes and can create hidden open ends.
• Retained logic is the usual default and usually closer to field reality.
• Pick one, keep it, state it, and fix logic that keeps going out of sequence.