2026-10-15 · 5 min read

Retained Logic vs Progress Override in P6: Which to Use and When

Out-of-sequence progress is part of real construction. The logic says the slab is poured before the blockwork starts, but one area opened early and the blockwork crew got going anyway. When you update the schedule, Primavera P6 has to decide what to do with the remaining work on that blockwork activity while its predecessor is still unfinished.

That decision is controlled by one setting in the schedule options, and it can change your forecast finish and your critical path. Plenty of planners leave it on whatever the default was when the project was created. This article explains what each option does, when each makes sense, and how to stop the setting from becoming a hidden source of argument.

Where the setting lives

In P6, open the schedule options (the Schedule dialog, then Options). Under the general settings you will find "When scheduling progressed activities use" with three choices:

• Retained Logic
• Progress Override
• Actual Dates

The setting applies to the project you are scheduling, so check it on every project, including copies made from templates. It only matters for activities that have started out of sequence. If all your progress follows the logic, the three options give the same answer.

A simple example

Take two activities linked finish-to-start:

• Activity A, "Pour slab Area 2", 10 days. Started, 5 days remaining.
• Activity B, "Blockwork Area 2", 10 days. Started early despite the link, 6 days remaining.

At the data date, A is not finished, but B is already under way. The logic says B should not have started yet. What happens to B's remaining 6 days?

Retained Logic

With retained logic, P6 keeps honouring the relationship for the remaining work. B's remaining duration is scheduled to start only after A finishes. So in the example, B's remaining 6 days sit after A's remaining 5 days, and B finishes 11 days after the data date.

What this means in practice:

• The relationship still drives the remaining work, so delay on A continues to push B and anything after it.
• Dates are generally more conservative, because remaining work waits for its predecessor.
• The critical path keeps following the logic as it was written.

Retained logic suits most construction work, where the original dependency is still physically real. If the blockwork genuinely cannot be finished until the slab is complete, retained logic forecasts that honestly. It is the option many planners, reviewers and contract schedule specifications prefer, so check what your contract or client asks for before choosing anything else.

Progress Override

With progress override, P6 treats the relationship as satisfied once the successor has started. B's remaining 6 days are scheduled straight from the data date, ignoring the unfinished A. B finishes 6 days after the data date, even though A still has 5 days to go.

What this means in practice:

• The started activity is released from its predecessor, so delay on A no longer affects B.
• Forecast dates are usually earlier, sometimes optimistically so.
• The critical path can break at that point, because the chain through A to B is no longer driving.

Progress override makes sense when the dependency really has stopped mattering. If the crew can finish the blockwork in parts of the area that are ready and the remaining slab work does not affect them, then forcing B to wait for A would overstate the delay.

The risk is that progress override hides real dependencies. If the work truly does depend on the predecessor, the schedule will show a finish date the site cannot achieve, and the critical path will look shorter than it is.

Actual Dates

The third option, actual dates, is the one people use least. It leans on the actual dates recorded on progressed activities when P6 calculates the schedule, rather than treating them the way the other two options do. The result can differ from both retained logic and progress override, and it is harder to explain to a reviewer. Read the scheduling options section of the P6 help for your version before relying on it.

Unless you have a specific reason and understand the effect on your project, most schedules are better served by retained logic or progress override. If you inherit a schedule set to actual dates, test the file under each option before you change anything, so you can explain the movement in the update.

How the choice affects the critical path

Because the two main options treat the same relationship differently, switching between them can change the forecast finish and move the critical path, without anything changing on site. That is one of the reasons a critical path can jump between updates. We look at the other causes in why your critical path keeps jumping.

A quick test is worth doing on any progressed schedule:

1. Make a copy of the project.
2. Schedule the copy with retained logic and note the finish date and the critical activities.
3. Schedule it again with progress override and compare.

If the two results are close, the setting is not driving much and you can move on. If they are far apart, you have a lot of out-of-sequence progress, and that is worth looking at directly rather than leaving it to a setting.

The better fix: correct the logic

Both settings are ways of handling logic that no longer matches what is happening. Neither replaces fixing the logic itself. When you find out-of-sequence progress in an update, ask what actually changed:

• The sequence changed for good. Change the relationship. A finish-to-start link might really be a start-to-start with a lag now, or the activity might need splitting into the area that is free and the area that is not.
• The successor started early but still depends on the predecessor to finish. Retained logic will usually forecast this correctly. Consider splitting the activity so the dependent part is clear.
• The dependency no longer applies at all. Remove or re-point the relationship, and note it in the update narrative so a reviewer understands why.

P6 can list out-of-sequence activities in its schedule log, which you can view after scheduling. Review that list every update. A long and growing list is a sign the logic needs work, not just a setting change.

Keep it consistent and documented

Whichever option you choose, a few habits prevent arguments later:

• Agree it up front. Confirm the setting the contract or client expects before the baseline is accepted, and use it from the first update.
• Do not switch mid-project without a reason. Changing the setting between updates moves dates for reasons that have nothing to do with the site. If you must change it, explain the effect in the narrative.
• State it in the narrative. One line in the update report, such as "Scheduled using retained logic", saves a lot of questions.
• Check copied projects. Settings come across with templates and copies, so verify them rather than assuming.

A note on MS Project

MS Project does not have the same three-way setting. How it handles out-of-sequence work depends on its scheduling options for in-progress tasks and the status date, and the behaviour is not identical to P6. If you move schedules between the two tools, test a small sample of out-of-sequence activities in both before relying on the converted dates.

Quick summary

• Retained logic keeps the relationship in force for remaining work. It is conservative and is usually the right default for construction.
• Progress override releases a started activity from its predecessor. It suits work where the dependency has genuinely stopped mattering.
• Actual dates is rarely needed. Test it before you rely on it.
• Whatever the setting, fix the logic where the real sequence has changed, review out-of-sequence activities every update, and record the setting in the narrative.

Getting this right will not make the schedule exciting, but it does make each update more honest, and that is what clients and site teams need from it.