Retained Logic vs Progress Override in Primavera P6
Introduction
In Primavera P6, two scheduling options—retained logic and progress override—determine how the schedule calculates the remaining duration and dates for activities that are out of sequence. Choosing the wrong option can distort your project’s forecast, misrepresent the critical path, and weaken your position in delay claims. This article explains exactly what each option does, how they differ, and when to use each.
What Are These Scheduling Options?
Both options appear in the Schedule dialog under the General tab. They control how P6 treats an activity when progress is reported on a successor before its predecessor is complete—an out-of-sequence condition.
- Retained Logic: The schedule maintains the original logic. The successor’s remaining duration is constrained to start only after the predecessor is finished. If the predecessor is late, the successor’s remaining work is pushed out accordingly.
- Progress Override: The schedule ignores the logic and allows the successor to proceed as if the predecessor were complete. The remaining duration of the successor starts from the data date, regardless of the predecessor’s status.
How Each Handles Out-of-Sequence Progress
Consider a simple example: Activity A (5-day duration) has a finish-to-start relationship with Activity B (5-day duration). At the data date, A is 50% complete (2.5 days done) but B has already started and is 20% complete (1 day done).
Retained Logic
With retained logic, P6 calculates that B’s remaining work (4 days) cannot begin until A finishes. Since A still has 2.5 days of work, B’s remaining duration starts after A finishes. The forecast shows B finishing later than planned. The critical path may shift to reflect the delayed logic.
Progress Override
With progress override, P6 ignores the fact that A is not complete. It calculates B’s remaining duration (4 days) starting from the data date. B finishes earlier than under retained logic. The schedule assumes the logic is effectively broken.
Effect on the Forecast and Critical Path
| Aspect | Retained Logic | Progress Override |
|---|---|---|
| Remaining duration of successor | Starts after predecessor finishes | Starts from data date |
| Project finish date | Later (more conservative) | Earlier (may mask delays) |
| Critical path | Reflects actual logic constraints | May show false path |
| Float calculation | Accurate per logic | May show inflated float |
In practice, retained logic produces a more realistic forecast when the original logic is still valid. Progress override can be useful when you intentionally want to model workarounds, but it often hides problems.
Which to Use and Why It Matters in Claims
For most projects, especially those used in forensic delay analysis or claims, retained logic is the recommended default. Why?
- Defensibility: Retained logic respects the planned sequence. If you claim a delay, the schedule shows the impact of predecessor delays on successors. Progress override can make it appear that the project is recovering when it isn’t.
- DCMA 14-Point Checks: The DCMA (Defense Contract Management Agency) schedule assessment guide expects retained logic. Using progress override can trigger a failed check for “out-of-sequence progress” and weaken your schedule’s credibility.
- EVM Integrity: Earned value metrics like schedule variance (SV) and SPI are more meaningful when the schedule logic is enforced.
However, there are cases where progress override is appropriate: when you are updating a schedule that will not be used for claims, or when the project team has intentionally resequenced work and you want to reflect that without changing the network logic. But be aware—using progress override can mask true project performance.
To quickly verify which option your schedule uses and see the impact on critical path, you can run these checks free in the browser with Project Assure. It parses your XER locally and flags if progress override is active, along with other DCMA checks.
Best Practices
- Default to retained logic for all baseline and monthly updates.
- Document any use of progress override in the schedule narrative.
- Run a DCMA 14-point check after each update to catch unintended out-of-sequence issues.
- If you must use progress override, consider creating a separate “what-if” scenario rather than modifying the primary schedule.
Conclusion
Retained logic and progress override are powerful but often misunderstood. Retained logic preserves the integrity of your CPM schedule and is essential for credible delay analysis. Progress override can be a shortcut that leads to false conclusions. Understand the difference, choose wisely, and always verify your schedule’s health with automated checks.
Run these checks free, in your browser
Free, browser-based Primavera P6 XER schedule analyser — DCMA 14-point, GAO & NASA checks, EVM/S-curve, and forensic baseline-vs-update comparison. Nothing is uploaded; your XER is parsed locally in the browser. 3 free analyses, no card required.
Analyse your XER →Frequently asked questions
What is the difference between retained logic and progress override?
Retained logic keeps the original activity sequence, delaying successors until predecessors finish. Progress override ignores the logic and allows successors to proceed as if predecessors are complete.
Which option should I use for a construction schedule?
Use retained logic for most construction schedules, especially if the schedule will be used for claims or delay analysis. It produces a more defensible forecast.
Can progress override cause incorrect critical path?
Yes. Progress override can mask delays and create a false critical path by ignoring logical constraints. This can lead to poor decision-making.
How do I check which option my P6 schedule uses?
In Primavera P6, go to Tools > Schedule > General tab. The option is labeled 'When scheduling out-of-sequence progress'. You can also use Project Assure to detect it automatically.
Does retained logic affect float values?
Yes. Retained logic typically produces lower float values because it respects predecessor constraints. Progress override can inflate float by ignoring those constraints.