Retained logic vs progress override
Last reviewed 9 September 20262,359 words11 min read
The setting that decides your forecast finish
🟩 In one line This one radio button tells P6 what to do when site has started something before the logic said they could. Retained Logic makes the remaining work wait for its predecessor. Progress Override lets it carry on regardless. On a messy project the difference can be weeks — and the button is buried three dialogs deep.
👤 Who this is for Mid-level planners whose forecast changed by a month and nobody touched the logic. Junior planners who've been told "just switch it to Progress Override" and want to know what they're agreeing to. Senior planners and reviewers, because this setting is one of the first things a forensic analyst checks.
First, let's be honest about why this page exists
At baseline, this setting does nothing. Both options produce identical dates, because there's no progress for them to disagree about. So nobody thinks about it. The project gets approved, the update cycle starts, and three or four months in — once the site has started working in whatever order suits them — the forecast finish quietly becomes dependent on which option is selected.
And it's an easy switch to make. Tools → Schedule → Options → General, one click, F9, and the finish date comes forward three weeks. No logic changed. No durations changed. Nothing in the comparison report. Just a better date.
That's why this page exists. The setting is legitimate and both options have a place. But one of them is a lot easier to abuse than the other, and if you're going to use it, you should be able to say exactly what it's doing to your forecast and why that's right.
🟨 The standard — what "good" looks like
The setting only matters for out-of-sequence progress — an activity that has started (has an actual start) while at least one of its predecessors is still unfinished. For every other activity, the two options behave identically.
| Option | What P6 does with the out-of-sequence activity's remaining work |
|---|---|
| Retained Logic | Holds it until the unfinished predecessor completes. The logic you built still applies to what's left. |
| Progress Override | Ignores the unfinished predecessor. Remaining work continues from the data date as if the link weren't there. |
| Actual Dates | A third option, rarely used and rarely permitted by client specs. Treats the activity's actual dates as governing. If you're not sure you need it, you don't. |
Where the standards land:
- P6's default is Retained Logic.
- DCMA 14-Point doesn't name the setting, but Metric 9 (Invalid Dates) and the general expectation of out-of-sequence activities being investigated and corrected both assume the logic is being respected, not overridden.
- AACE RP 29R-03 (Forensic Schedule Analysis) discusses the two settings at length in the context of update analysis, and cautions that Progress Override can mask the effect of logic that's still valid. Most forensic analysts treat a switch to Progress Override during a project as a red flag requiring explanation.
- Gulf client specifications — the majority now state Retained Logic explicitly, and some require the scheduling options to be listed in the monthly narrative. The setting is stored inside the XER (the SCHEDOPTIONS table), so the reviewer can see it without asking.
- SCL Protocol doesn't address it directly, but its emphasis on the programme reflecting the intended sequence of work points the same way.
🟢 The default position is Retained Logic. If you're going to use Progress Override, the burden is on you to explain why the retained logic is wrong — and if the logic is wrong, the better answer is usually to fix the logic, log the change, and stay on Retained.
How it actually works
Picture a two-activity sequence. Plaster the wall, then Paint the wall, finish-to-start. That's the plan.
Site gets ahead of themselves. The plasterers are slow, so the painters start on the sections that are done. Now Paint has an actual start, but Plaster isn't finished. Out of sequence.
Retained Logic asks: what does the remaining painting depend on? It says: the plaster still has to finish before the painting can finish. So it takes the plaster's forecast finish, and schedules the painter's remaining days after that. The painter may have started early, but they can't finish until the plasterer is out of the way — which, on a real wall, is true.
Progress Override asks: has painting started? Yes. Then it assumes the link has done its job and no longer matters. The painter's remaining days are scheduled straight from the data date, in parallel with whatever plaster is left. Painting finishes earlier. Whether that's physically possible isn't something P6 is thinking about.
Which is right? It depends entirely on why the logic was there.
- If the relationship was hard — the paint physically cannot go on before the plaster — then Retained Logic is right. The painter will run out of wall.
- If the relationship was soft — a preference, a crew sequence, a "we'd rather do it this way" — and site has found a workable alternative, then the logic is wrong for the situation, and the honest fix is to change the relationship (say, to a start-to-start with a lag, or a finish-to-finish) and log it. Progress Override would give you a similar date, but it does it by ignoring the problem rather than resolving it.
That's the distinction. Retained Logic respects what you built. Progress Override assumes you built it wrong wherever site disagreed with it. Sometimes site is right. But the schedule should say so explicitly, not by a global setting that applies to every out-of-sequence activity at once — including the ones where site is not right.
How big can the difference get?
On a well-sequenced job with a handful of out-of-sequence activities, a few days. On a fit-out or an MEP-heavy job where site is working every available front, dozens of activities can be out of sequence at once, and the two settings can produce forecast finishes six or eight weeks apart. Same file. Same progress. One radio button.
🟥 Where people go wrong
1. Switching to Progress Override to improve the date. The most common misuse. The forecast is bad, someone tries the other option, it's better, it stays. No logic was fixed. The out-of-sequence activities that genuinely can't finish early are now forecast to finish early. Next month, reality catches up and the forecast slips back — and now there's no honest explanation for either movement.
2. Not noticing it changed. Someone else opened the file, changed the setting for a what-if, and didn't change it back. It's not in the comparison report; scheduling options aren't tracked as changes. Check the setting every single update, before F9. It takes ten seconds.
3. Not telling the client. The setting is visible in the XER. If the client's reviewer opens the file and finds Progress Override when the spec says Retained Logic, the update is rejected and the conversation about why it was switched is not one you want to have after the fact. If there's a reason to use it, put it in the narrative before they find it.
4. Using it instead of fixing the logic. Fifty out-of-sequence activities means fifty relationships that don't describe how the work is actually being done. Progress Override makes them stop hurting the forecast. It does nothing about the fact that the schedule no longer represents the plan. Fix the ones that are wrong. Leave Retained Logic on for the ones that are right.
5. Using it mid-way through a claim window. A time impact analysis compares the schedule before and after a delay event. If the scheduling option changed between the two, the comparison is meaningless — and the other side's expert will demonstrate that in about two slides. Whatever the setting is at the start of a delay analysis, it stays until the end.
6. Assuming Retained Logic is always conservative. Usually it is. But with start-to-start or finish-to-finish relationships and lags, Retained Logic can occasionally schedule remaining work later than makes any physical sense — the successor is 90% done and P6 has it waiting for a predecessor that's no longer relevant to the remaining 10%. That's not a reason to switch to Progress Override globally; it's a reason to look at that relationship and change it.
⚖️ When you're challenged
"Switch it to Progress Override. The dates are better." "They're better because P6 stops making the out-of-sequence work wait for its predecessors. On some of those that's fine. On the ceiling closures it isn't — they genuinely can't close before the duct test. If I override globally, the forecast says ceilings finish three weeks before the test they depend on. I'd rather fix the twelve relationships that are actually wrong and stay on Retained."
"What's the difference? Show me." Run it both ways. Write down the forecast finish under each. Then list the out-of-sequence activities and split them into "logic still applies" and "logic is stale." "Retained gives 14 August. Override gives 22 July. Of the 30 out-of-sequence activities, 18 are genuinely constrained — the override date isn't achievable for those. If I fix the other 12 properly, Retained comes to about 5 August, and that's a date I'll stand behind."
"The client's found Progress Override in the XER. What do I tell them?" The truth, quickly. "It was set during a what-if last month and not returned to Retained before submission. Corrected file attached; the forecast finish under Retained Logic is X. No other changes." Then make sure it never happens again — add it to the checklist.
"Why does the spec care? It's just a setting." "Because it can move the forecast by weeks without any change to logic or durations, and it's invisible in a comparison report. The spec fixes it so both sides are looking at the same calculation. Same reason they fix the calendar and the float definition."
📄 Related pages
- Out-of-sequence progress — what causes it and how to review it before you schedule
- Scheduling options — the rest of the dialog, including the calendar-for-lag setting
- Hard Logic vs Soft Logic — the distinction that tells you whether the retained logic is right
- Statusing a schedule — step 8, where you check this before F9
- Data date — the other thing in the F9 dialog
- Time Impact Analysis — why the setting must not change during an analysis
- P6 Settings That Change Your Dates — this setting and the others like it, on one page
✏️ Worked example
Three activities from a villa finishing sequence. 6-day calendar. Data date 25 March.
| ID | Activity | Original duration | Planned logic |
|---|---|---|---|
| F100 | Plaster — ground floor | 12 days | — |
| F110 | Paint — ground floor | 10 days | F100 finish-to-start |
| F120 | Floor tiles — ground floor | 8 days | F110 finish-to-start |
What happened by 25 March:
- F100 Plaster started on time, but the crew was pulled to another block. Site says 6 working days remaining. Forecast finish under any setting: 1 April.
- F110 Paint started early — 18 March — on the rooms that were plastered. Site says 7 working days of painting remaining.
- F120 Tiles not started.
F110 is out of sequence: it has an actual start, and its predecessor F100 isn't finished.
Under Retained Logic:
| Activity | Remaining | Scheduled from | Forecast finish |
|---|---|---|---|
| F100 Plaster | 6 days | Data date 25 Mar | 1 Apr |
| F110 Paint | 7 days | After F100 finishes — 2 Apr | 9 Apr |
| F120 Tiles | 8 days | After F110 — 10 Apr | 18 Apr |
P6 holds the remaining 7 days of painting until plaster is done. The painter's early start bought nothing in the forecast. Tiles finish 18 April.
Under Progress Override:
| Activity | Remaining | Scheduled from | Forecast finish |
|---|---|---|---|
| F100 Plaster | 6 days | Data date 25 Mar | 1 Apr |
| F110 Paint | 7 days | Data date 25 Mar — link ignored | 2 Apr |
| F120 Tiles | 8 days | After F110 — 3 Apr | 11 Apr |
Painting carries on in parallel with plastering. Tiles finish 11 April. One week better.
Which is true?
Neither, exactly. The painter can genuinely keep going on the plastered rooms, so Retained Logic is too pessimistic. But the last two rooms can't be painted until they're plastered, so Progress Override — which has painting finishing the day after plastering — is too optimistic. The plaster finishes 1 April; the paint in those last rooms needs a couple of days after that at least.
The right answer is to fix the logic. Change F100→F110 from finish-to-start to finish-to-finish with a 2-day lag (paint can't finish until 2 days after plaster finishes), log the change with the reason, and stay on Retained Logic:
| Activity | Forecast finish |
|---|---|
| F100 Plaster | 1 Apr |
| F110 Paint | 3 Apr |
| F120 Tiles | 12 Apr |
12 April. Defensible, physically sensible, and the change log says: "F100–F110 changed FS to FF+2d; site painting completed rooms ahead of plaster completion; remaining paint constrained by final two rooms only. Requested by site engineer, 24 Mar."
That's a forecast you can put in front of a client. The Progress Override date, one day different, is one you'd have to hope they didn't ask about.
📖 References
- Oracle, P6 Professional User's Guide — Schedule Options, "When scheduling progressed activities use"
- AACE International, RP 29R-03, Forensic Schedule Analysis — §2.3 (schedule settings and their effect on analysis)
- AACE International, RP 53R-06, Schedule Update Review
- DCMA, 14-Point Schedule Assessment — Metric 8; commentary on out-of-sequence progress
- SCL, Delay and Disruption Protocol, 2nd ed. — Guidance Part B §1
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about retained logic vs progress override. 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