Out of sequence progress occurs when an activity reports actual progress even though the predecessor condition defined in the schedule has not been satisfied. For example, a successor may start before its finish-to-start predecessor finishes. The schedule now contains a conflict between the planned network logic and actual execution.
The actual progress may be valid. However, the original dependency may be incomplete, obsolete, or still technically necessary. Therefore, the scheduler must investigate each occurrence rather than automatically deleting logic or moving actual dates.
Out-of-sequence progress matters because unresolved conditions can distort remaining dates, total float, critical path calculations, resource forecasts, and management reports. It may also expose technical risk when a team proceeds without a required product, decision, or approval.
What Is Out of Sequence Progress?
In a Critical Path Method (CPM) schedule, relationships define the conditions that control when activities may start or finish. An out-of-sequence condition exists when reported performance contradicts one of those conditions.
Common examples include:
- A successor starts before its finish-to-start predecessor finishes.
- A successor starts before its start-to-start predecessor starts.
- A successor finishes before its finish-to-finish predecessor finishes.
The U.S. Government Accountability Office Schedule Assessment Guide describes out-of-sequence logic as progress performed in a different order from the original plan. The guide recommends reviewing each occurrence and deciding how the schedule should model the remaining work.
Deltek uses a similar definition. The Deltek Open Plan glossary defines out-of-sequence progress as reported progress when predecessor activities have not been completed.
A Simple Out-of-Sequence Example
Consider a fictional avionics development program with the following activities:
- Complete interface design
- Release interface drawings
- Build integration test harness
- Conduct subsystem integration test
The baseline schedule links “Release interface drawings” to “Build integration test harness” with a finish-to-start relationship. However, the test team begins fabricating part of the harness before the drawings receive final release.
At the next status cycle, the control account manager reports an actual start and 20 percent progress on the harness activity. Meanwhile, the drawing activity remains incomplete. The progress is now out of sequence.
That condition does not automatically prove the actual start is wrong. The team may have used mature preliminary drawings to build low-risk portions of the harness. However, the scheduler and technical lead must determine what the unfinished drawing work still controls.
If final drawing release remains necessary before fabrication can continue, the remaining harness work should wait. If only one harness component depends on final release, the original activity may be too broad. The team may need to split it into discrete activities with more accurate logic.
Why Out of Sequence Progress Matters
It can change the calculated forecast
Scheduling software must decide how to calculate the unfinished portion of an activity that started early. Depending on the software settings and network structure, the remaining work may stop until the predecessor finishes or continue without regard to the original relationship.
Those treatments can produce different completion dates. As a result, the selected approach can change the longest path, milestone forecasts, and reported schedule margin.
It can distort float and criticality
An unresolved out-of-sequence condition can produce misleading total float. It may also make an activity appear artificially critical or leave an unfinished predecessor without meaningful downstream logic.
Schedulers should understand which predecessor is actually driving the activity before changing the network. They should then review the effect on total float, near-critical paths, and contractual milestones.
It may signal technical or execution risk
Some teams can safely perform limited work early. In other cases, the successor needs information, material, approval, or test results from its predecessor.
Starting without that input can create rework or quality risk. Therefore, out-of-sequence progress requires a technical discussion, not just a software adjustment.
It can weaken management reporting
An Integrated Master Schedule (IMS) should provide a credible forecast based on current execution. If the logic no longer reflects how the team will perform the remaining work, management cannot rely on the calculated critical path.
For that reason, out-of-sequence conditions should be reviewed during the normal IMS status process. Significant cases should also appear in the schedule narrative, especially when they affect key milestones or change the critical path.
Retained Logic Versus Progress Override
GAO describes two primary treatments for calculating schedules with out-of-sequence progress: retained logic and progress override. These terms describe different assumptions about the remaining work.
Retained logic
Under retained logic, the schedule recognizes the work already completed. However, it delays the activity’s remaining work until the unmet predecessor condition has been satisfied.
In the avionics example, the test team keeps credit for the harness fabrication already performed. The unfinished harness work then resumes after the interface drawings receive final release.
This treatment preserves the original dependency as much as possible. Therefore, it is often the more conservative option when the predecessor still provides a required technical input.
Progress override
Under progress override, the remaining successor work continues despite the incomplete predecessor. Actual execution effectively overrides the original sequence when the schedule calculates future dates.
This approach may be appropriate when the team confirms that the remaining work can proceed safely. However, it can also produce an optimistic forecast if resources, approvals, or technical inputs do not support parallel execution.
GAO generally favors retained logic as the conservative approach. Still, it recommends evaluating each condition case by case. A global software setting should not replace technical judgment.
Logic revision is often the better long-term answer
Retained logic and progress override address schedule calculation behavior. They do not necessarily correct a poorly modeled network.
If execution proves that the predecessor does not control the entire successor, revise the prospective logic to model the real dependency. For example, split “Build integration test harness” into:
- Fabricate standard harness components
- Fabricate interface-specific components
- Assemble and inspect completed harness
The preliminary design may support the first activity, while released drawings drive the second. The final assembly can then depend on both. This structure provides a more defensible forecast than simply deleting the original relationship.
How a Scheduler Should Resolve the Condition
1. Validate the reported actuals
First, confirm that the successor truly started. Obtain the actual start date, completed scope, remaining duration, and basis for the progress claim.
Do not move or remove a valid actual date merely to make the schedule conform to the baseline sequence. Actual dates should represent what happened. If the entry was a status error, correct it through the program’s approved status-control process.
2. Confirm the status date
Check that actual progress falls on or before the current data date. Also confirm that unfinished work resides after that date.
The IMS status date separates recorded performance from forecast work. Incorrect placement around that boundary can create conditions that resemble out-of-sequence progress but result from poor status discipline.
3. Ask what the predecessor actually provides
Meet with the control account manager, activity owner, or technical lead. Ask what product or condition the predecessor delivers and whether the successor still needs it.
Possible answers include:
- The predecessor remains mandatory for all remaining successor work.
- The predecessor controls only part of the successor scope.
- The predecessor no longer represents the execution plan.
- The relationship never represented a real dependency.
The answer should drive the corrective action.
4. Select the treatment for remaining work
Use retained logic when the successor must stop and wait. Allow continued work only when the responsible technical and program personnel confirm that parallel execution is feasible.
If the logic no longer reflects reality, revise the prospective network. However, avoid replacing valid logic with a hard constraint merely to preserve a preferred date. Constraints can conceal the true driver and weaken critical path analysis in the IMS.
5. Recalculate and inspect the result
After correcting the condition, recalculate the schedule and review:
- The driving path to affected milestones
- Total float and negative float
- New open ends or dangling relationships
- Resource feasibility for parallel work
- Changes to forecast starts and finishes
- Potential rework or technical risk
Do not assume that a clean diagnostic report proves the forecast is realistic. The revised network must also make technical and execution sense.
6. Document the decision
Record significant out-of-sequence conditions in the update narrative or schedule change log. Explain the actual event, the treatment selected, any logic revisions, and the effect on key dates.
This documentation gives management and customer reviewers context. It also helps the scheduler distinguish routine field resequencing from a material change to the execution plan.
Software Treatment Is Not Identical Across Tools
Scheduling platforms do not all use the same terminology or calculation controls. Therefore, teams should define their approach in the schedule management plan and understand the settings used for each update.
Deltek Open Plan documentation states that the application accepts out-of-sequence progress and calculates early and late dates for the remaining portion of an activity. Schedulers should still review the resulting dates and logic rather than treating software acceptance as technical approval.
Microsoft Project allows users to enter actual starts, actual work, actual duration, and remaining duration. Its progress-updating guidance also explains that Project can adjust the placement of actual and remaining work relative to the status date. However, users should not assume that Microsoft Project settings map directly to retained-logic and progress-override terminology used in other platforms.
Regardless of the tool, preserve valid actuals, place remaining work in the future, and inspect the calculated driving path after every material correction.
Out-of-Sequence Progress and Earned Value Management
Out-of-sequence progress does not automatically mean earned value was claimed incorrectly. Actual schedule status and earned value credit answer related but different questions.
A team may have physically started a successor while earning little or no value because it has not met the work package’s objective completion criteria. Conversely, valid completed scope may support earned value even though the work occurred in a different sequence than planned.
The control account manager and program-controls team should confirm that:
- Earned value reflects objective accomplishment.
- The schedule contains accurate actual dates and remaining durations.
- The Estimate at Completion reflects any rework or inefficiency.
- The schedule and cost-system forecasts remain reconcilable.
Do not grant progress merely because an activity has an actual start. Also, do not erase valid schedule performance to avoid explaining a variance.
Contractual Requirement or Scheduling Best Practice?
Out-of-sequence progress is not automatically a universal contractual violation. The applicable contract, Contract Data Requirements List, data item description, agency tailoring, and approved program procedures determine specific delivery and reporting obligations.
GAO’s treatment of out-of-sequence progress represents authoritative schedule-assessment guidance, not a clause that independently binds every contractor. Likewise, the NASA Schedule Management Handbook presents agency schedule-management guidance and best practices. Programs must distinguish such guidance from requirements incorporated into a specific contract.
Even when no deliverable instruction explicitly mentions out-of-sequence progress, resolving it remains sound scheduling practice. An IMS cannot provide a reliable forecast when actual execution and future network logic contradict each other.
Common Mistakes to Avoid
- Deleting the predecessor immediately: Early work does not prove that the dependency is invalid.
- Changing a valid actual start: The schedule should record what occurred, not rewrite history to match the baseline.
- Using one global treatment without review: Different activities may require different technical responses.
- Ignoring partial dependencies: A broad activity may need to be split so the schedule can model what can and cannot continue.
- Adding constraints to hold dates: Constraints can hide the real driver and distort float.
- Failing to review resources: A progress-override result may assume parallel work that the program cannot staff.
- Leaving the condition undocumented: Reviewers may see changed float or milestone dates without understanding the execution decision.
Practical Interpretation
Out of sequence progress is a signal that the plan and actual execution have diverged. Sometimes the field team found a valid opportunity to start early. In other cases, the original logic was weak or the team accepted technical risk.
The scheduler’s role is not to force actual performance back into the original network. Instead, the scheduler should preserve accurate history, challenge the forecast, and model the remaining work as the team now intends to execute it.
A credible correction answers three questions: What actually happened? What dependency still controls the unfinished work? What effect does the revised execution plan have on the critical path and key milestones?