REPORTED PROGRESS OR LOGICALLY VALID PROGRESS?
The Out-of-Sequence (OOS) Problem in Primavera P6
There is something both fascinating and deeply misleading about how Primavera P6 handles Out-of-Sequence (OOS) activities. The software is perfectly capable of detecting them, listing them in the Schedule Log, counting how many there are, and flagging them as anomalies in the update. Up to that point, everything seems reasonable: the system recognizes that the actual reported progress has violated the planned logical sequence of the schedule. However, immediately afterward, Primavera offers what appears to be a neat technical response: Retained Logic. And this is precisely where the real problem begins.
Because Retained Logic does not actually solve the underlying issue. It merely tells the scheduling engine how to recalculate the network after the inconsistency has already occurred. In other words, Primavera does not correct the broken logic — it simply manages it computationally.
The issue becomes far more serious when the anomaly is not just a successor that started early, but a much more severe condition: a successor activity that is already completed while its mandatory predecessors have not even started. At that point, the conventional explanation of Retained Logic becomes insufficient. If the successor is shown as Completed, with an Actual Finish, contributing to % Complete, feeding the S-Curve, and possibly even influencing executive reports or earned value calculations, then the schedule is accepting as “progress” something that, according to its own logic, should not have been possible yet.
At that moment, this is no longer just a scheduling irregularity. It becomes a problem of internal model consistency.
The activity exists as a reported fact, but not necessarily as a logically valid event within the schedule network. This is where the discussion must move beyond software behavior and into something far more important: the logical validity of reported progress.
The Practice Standard for Scheduling published by the Project Management Institute provides an important foundation for understanding why this matters. The standard correctly emphasizes that a project schedule should be built on a coherent logic network, where relationships represent a technically and operationally defensible sequence of work. It also stresses that updates should reflect the real status of the project, and that the network should maintain enough integrity to function as a reliable control model. However, when applied to severe OOS conditions, the standard does not go far enough. It explains the importance of logical consistency, but it does not explicitly conclude that a completed successor — especially one completed while its predecessors remain not started — may invalidate the meaning of the reported progress itself.
In other words, the standard protects the structure of the schedule, but it does not fully judge the epistemic reliability of the data flowing through it.
This gap becomes even more evident when viewed through the work of several authors in project controls and schedule analysis. Walt Lipke and Mario Vanhoucke help us understand that not all reported progress should be treated as temporally meaningful progress. Lipke’s work on Earned Schedule challenges the assumption that reported completion automatically reflects valid time performance. Vanhoucke’s research on schedule adherence, performance control, and predictive validity reinforces the idea that progress must be evaluated not only by quantity, but also by whether it respects the structure of execution that gives it meaning. From that perspective, a severe OOS condition is not just a broken relationship — it is a distortion of schedule performance interpretation.
Similarly, David Hulett provides a crucial insight: a schedule may continue to run, calculate dates, and produce outputs, while simultaneously losing much of its ability to represent actual project behavior. That distinction — between a model that runs and a model that explains — is fundamental here. Saleh A. Mubarak, from the perspective of construction scheduling and delay analysis, reinforces the idea that logic is not a decorative mathematical layer; it is the minimum causal structure that makes a construction sequence defensible. Once that structure is violated, the resulting progress data can no longer be interpreted with the same innocence.
From a more realism-driven scheduling philosophy, Vladimir Liberzon helps push the critique even further. A schedule is valuable not because its network looks elegant, but because it reflects real constraints, real sequencing, real resource interactions, and real execution conditions. If reported progress contradicts the necessary logic of the work, then the schedule has ceased to be a trustworthy representation of the project — even if the software still accepts it. In a very compatible way, J. Chris White also contributes to this discussion by challenging the adequacy of static activity status as a sufficient basis for understanding project progress. His perspective strongly supports the idea that progress must be interpreted dynamically, not merely administratively.
Institutional frameworks such as the DCMA, the NDIA — especially through the PASEG — and the recommended practices of AACE International also reinforce an important principle: a schedule should not be considered healthy simply because it produces dates. It must also maintain defensible logic, interpretable structure, and analytical credibility. None of these frameworks fully solve the completed-successor OOS problem on their own, but together they support a powerful conclusion: when the schedule accepts status conditions that contradict its own causal structure, it is no longer enough to say that “the software handled it.” The real question becomes whether the model remains valid for control, forecasting, critical path interpretation, or forensic use.
Recommended by LinkedIn
For this reason, OOS conditions should not be reduced to a mere operational choice between Retained Logic and Progress Override. That debate is necessary, yes — but it is nowhere near sufficient. The deeper issue is that an activity may have real field effort, real hours, real cost, and even real physical work behind it, and still not qualify as logically valid progress within the schedule model.
That leads to a much more powerful distinction:
Executed Progress vs. Valid Progress
Executed Progress may exist physically in the field. But Valid Progress requires that the reported activity status be consistent with the dependencies that give that activity meaning inside the network.
If a successor is shown as completed while its mandatory predecessors remain not started, then the schedule is producing a data point that the software can process — but that the scheduler should not accept uncritically.
That is the real doctrinal crack in the traditional treatment of OOS conditions.
So the conclusion should not simply be that Primavera “handles” OOS through Retained Logic. A more serious conclusion is this:
A schedule should not be considered reliable merely because the calculation engine is capable of absorbing its inconsistencies.
When an update allows reported progress to contradict the minimum causal logic of the network, the model ceases to be merely imperfect and begins to become potentially misleading. That is why there is a strong need for additional criteria — beyond software settings and beyond standard scheduling practice — to distinguish between reported progress and logically valid progress.
References
We had issues in MS Project where too many OOS issues would cause corruption of the file itself. I can't say if going to the 64bit Operating system and software helped because we have not had OOS in a schedule I worked on since 2012. Back to present, we have a status tool that asks for Actual Dates, Reforecasted Dates and BCWP, amongst other info, for the work packages. It doesn't take into account logic. So after status is imported into the IMS, we run analysis, and send out a report and ask what happened with these OOS, and other issues, what now depends on the finish of this task? Most of the time I know the answer, but I want to get concurrence from the CAM. Most of the time it is resource driven and we can do these high slack work packages at different times. It would be more efficient to do these tasks in a certain order, but if someone more important needs the big machine, we can shoehorn this other job into the pecking order and get some work done.
Jair, very well said. Reported progress can be current and still be misleading. That is the trap. Once work is entered out of sequence, the plan may continue to calculate, but it no longer reflects how execution is unfolding. After more than 100 PPM implementations, this is exactly the kind of problem that led us to build aangine. Too many organizations had status updates, dashboards, and reporting discipline, but not enough protection for the plan's actual logic. That is why your distinction matters. A plan is only useful if reported progress still respects dependency, sequence, and what is truly possible next. www.aangine.com And one with the spreadsheet angle: Jair, this hits a nerve for a reason. Many organizations do not even reach the point of logical validity in a formal PPM tool. They are trying to hold planning together in spreadsheets because the need is so urgent and the structure is so fragile. That is part of why this topic matters so much to me and part of why aangine caught my attention. The problem is not simply whether progress is reported. It is whether the plan still has enough integrity to support judgment once reality starts pushing work out of sequence. www.aangine.com
As usual, excellent article, Jair Aguado Quintero. OOS work often messes everything up--including EVM metrics. (Goosing SPI is often THE motive for OOS work!). Worse, OOS work may often have to be UNdone to let necessary predecessors be done, then REdone! That new fragnet can cause REAL sched & budget overruns! On page 169 of my book "Managing Projects as Investments: Earned Value to Business Value", I wrote: "Every project manager should, at the start of any project, make it clear that no one is allowed to do out-of-sequence work without first clearing it with the project manager. If an engineer hits upon an idea that may shorten the schedule by not waiting for a predecessor to finish, that’s great! We want that engineer to step forward and, if the change is practical, to take credit for “thinking outside the box.” But first, it must be approved and the schedule must be changed to reflect the new reality. Anyone who does work out of sequence without first getting the change approved should be quartered, drawn, and then hanged, and then told never to do it again." My editor at CRC Press called to point out that the term is usually: "hanged, drawn and quartered". I explained I'd do it to them out-of-sequence. Bajan the Steve
Good read. But let me push the diagnosis one step further. The root cause here is not technical. P6 detects the anomaly, logs it, and flags it. Retained Logic is just the engine doing its job with a broken input. That's not a bug — that's a design boundary. The real failure happens upstream, in three places. 1. Someone reported a completed successor while mandatory predecessors hadn't started. Human decision. 2. A scheduler accepted the update without questioning its logical validity. Human posture. 3. An organization measured schedule health by date output, not by network coherence. Human standard. P6 doesn't hide that. It actually surfaces it. The problem is what happens next: practitioners use the software's ability to absorb the inconsistency as a reason to stop asking the harder question. A schedule that runs is not the same as a schedule that explains.