Avoid Out-of-Sequence Progress in Microsoft Project 2010-2016

[For the corresponding video presentation, see Construction CPM Conference 2020 – Avoid Out of Sequence Progress in Microsoft Project.]

Recording Actual dates that violate existing schedule logic can cause conflicts in Microsoft Project’s internal schedule calculations. The resulting Total Slack values and Critical task flags can be incorrect and misleading.  These issues are aggravated by recent (e.g. MSP 2016) versions of the software, and users are advised to minimize out-of-sequence progress.

Recording of actual progress in a logic-driven project schedule can be problematic.  As the “Actual” dates override or otherwise constrain the computed dates, the customary definitions of Float or Slack – and their resulting impacts on the “Critical” task flag in Microsoft Project (MSP) – no longer apply.  While I hope to undertake a general review of progress updating issues in a future article, this one has a special focus on out-of-sequence progress for two primary reasons:

1. In all modern versions of Microsoft Project (e.g. ~MSP 2007+), the Total Slack values of “Critical” tasks with out-of-sequence successors can be altered unexpectedly.
2. In MSP 2016 (and possibly beginning with MSP 2013), the Total Slack values of ALL tasks (not just “Critical” tasks) with out-of-sequence progress among their successors can be altered unexpectedly. As a result, many tasks can be shown incorrectly as “Critical” in MSP 2016 when they are not “Critical” in earlier versions.

What is Out-of-Sequence Progress

Out-of-sequence progress exists when actual progress is recorded (via, e.g. Actual Start, Actual Duration, Actual Work, %Complete, etc.) at times when the logical constraints of the schedule would normally preclude it.  For example:

• An Actual Start is recorded for a task (the out-of-sequence, or OOS, task) whose Finish-to-Start predecessor has not finished. I.e. the Actual Start precedes the Early Start;
• An Actual Start is recorded for an OOS task whose Start-to-Start predecessor has not started. Again, the Actual Start precedes the Early Start;
• An Actual Finish is recorded for an OOS task whose Finish-to-Finish predecessor has not finished. Here the Actual Finish precedes the Early Finish.
• An Actual Start is recorded for an OOS task whose Finish-to-Finish predecessor subsequently delays the completion of the work (on the OOS task).  Again the Actual Start precedes the Early Start that would have existed in its absence.

In all cases there is a presumption that the recorded actual progress is more correct than the (theoretical) schedule model, so Early and Late dates are routinely overwritten by Actual dates during the schedule calculations.  When the actual progress occurs out of sequence, however, computing the Late dates (and slack values) of incomplete predecessors (during the “Backward Pass” calculations) is complicated by logical conflicts.  The software typically resolves these conflicts in a way that satisfies the needs of most users.

Completed, Out-of-Sequence Tasks

The issues discussed here are of primary concern in those cases where a task has started out of sequence and a) it remains incomplete; and b) the violated predecessor relationships remain unsatisfied (e.g. the FS predecessor remains incomplete.)  If either the OOS task or its unfinished predecessor task become complete, then they are treated like other completed tasks in Microsoft Project.  That is, they can influence the Early dates of their successors but have no impact on the Late dates of their predecessors.  As a result of this latter condition, an incomplete task whose sole successor has been completed out of sequence becomes effectively open-ended, i.e. without successors.  Under default conditions (i.e. “calculate multiple critical paths” NOT checked), the task’s Late Finish is set equal to the project’s Early Finish Date, and a high value of Total Slack is computed.

Obviously, this can have a major impact on the apparent Critical Path of a project.  In the example below (which is further described in later paragraphs), tasks CP2 and SP2 have both been completed out-of-sequence, and at a duration of only 20% of their baseline durations.  The overall project has been shortened, but the Critical Path has been truncated at CP3.  CP1 is no longer “Critical” because, in effect, it no longer has any successors.  It appears necessary to add a new FS relationship from CP1 to CP3 (and equivalently from SP1 to SP3) to re-establish the logic chain that has been broken by the completed, out-of-sequence tasks.

In Oracle Primavera P6, by contrast, the Retained Logic schedule setting automatically adjusts for activities completed out of sequence.  Thus, the need to finish CP1 before proceeding with CP3 is already included.  The result is a (presumably more realistic) 2-day delay in completion compared to the MSP result.

In-Progress, Out-of-Sequence Tasks

Key issues arise when the out-of-sequence task and its predecessor are both incomplete.  Because this behavior is sometimes different for MSP 2016 than it is for MSP 2010, we’ll look at both versions for the remaining examples.

For exploring the behavior of in-progress, out-of-sequence tasks, we examine the simple project schedule below.  The schedule is comprised of a single start milestone, a single finish milestone, a “Critical Path” string of four tasks, and a “Slack Path” string of four tasks.  The “Slack Path” is two days shorter than the “Critical Path,” with the last two tasks each having a shorter duration.  There is an unachievable Deadline applied to the finish milestone, and this creates negative Total Slack on the Critical Path.  Thus, the Critical Path tasks all have TS=-1d, and the Slack Path tasks have TS=1d.

With no progress, the project is scheduled identically in both versions of MSP.  Notably, P6 also starts with the same schedule dates.

Now let’s examine what happens when we record an out-of-sequence Actual Start on some future task.  In the example, the last task in each string (CP4 and SP4) is given an Actual Start that is one day earlier than its predecessors allow.  To keep things simple, no progress beyond the actual starts are recorded (i.e. %Complete = 0%.)  I’ve kept the “Split in-progress tasks” scheduling option checked (per default), so re-scheduling the project creates an initial split in tasks CP4 and SP4 and delays their remaining parts to satisfy the predecessor relationships.  As a result, all the tasks keep the same finish dates as before, and the project finishes on the same date as before, one day after the Deadline.

Although their start and finish dates have not changed, the logic-related information of the predecessors of the OOS tasks have been altered substantially.

1. In both MSP 2010 and MSP 2016:

• The Total Slack values of the Critical Path tasks that precede the OOS task (i.e. tasks CP1, CP2, and CP3) are all changed from TS=-1d to TS=0d.
• This behavior is not justified: if the tasks are all executed according to the scheduled dates, the project will still finish one day late. The tasks should still have TS=-1d.
• This is in fact a general result (see also Comment 1): (Presumably for MSP 2007 through MSP 365), any super-critical (TS < 0) task with an out-of-sequence, in-progress task in its successor chain will automatically have its Total Slack re-set to zero. Thus, out-of-sequence progress can cause a task with 60 days of negative Total Slack to appear much less Critical than it is.
• This behavior can present a problem for project managers operating in a negative-slack (i.e. behind-schedule) regime, where schedule-recovery efforts are typically prioritized based on Total Slack values. Entering a single OOS Actual Start value (whether correct or not), can substantially alter the overall schedule recovery picture.
• It seems most MSP users pay no attention to Total Slack values beyond the application of the “Critical” flag, and the observed behavior doesn’t change that. Consequently, for most users up through MSP 2010, out-of-sequence progress appears to have no substantial impact on the “Critical Path.”

2. In MSP 2016, in addition to the prior behavior:
   • In the example, the Total Slack values of the Slack Path tasks that precede the OOS task (i.e. tasks SP1, SP2, and SP3) are all changed from TS=1d to TS=0d.
   • This behavior is also not justified. The tasks could all be delayed one day from their scheduled dates without compromising the project’s completion Deadline.  The tasks should still have TS=1d.
   • This is also a general result (see also Comment 1): (presumably for MSP 365 and maybe MSP 2013), ANY task (Critical or non-Critical) with an out-of-sequence, in-progress task in its successor chain will automatically have its Total Slack re-set to zero. Consequently, it will automatically and unavoidably be flagged as a Critical task.
   • For general MSP users after MSP 2010, therefore, out-of-sequence progress can have a substantial, even major, impact. In particular, tasks that are actually far from the Critical Path may be incorrectly flagged as Critical.
3. The results in Oracle P6, however, appear more realistic.  The Late dates and corresponding Float values are unchanged from the initial schedule.

Below I’ve shown another perhaps more realistic example of the same simple project.  There has been a simple progress update on the Status Date of 1Oct’18, four working days into the project.  As of that date (the first Monday in the project), tasks CP1 and SP1 are still in-progress and have fallen one day behind the original plan.  Their successors (CP2 and SP2) have been allowed to start early, however, with each recording one day of actual progress.

Similar logical results are observed.  Task CP1 – the Critical predecessor of the Critical OOS task CP2 – now has TS=0d instead of TS=-1d in both software versions, and its Critical flag remains unchanged.

In MSP 2016 only, task SP1 – the non-critical predecessor of the non-critical OOS task SP2 – now also has TS=0d and is flagged as Critical.  This is incorrect.

As before, however, the late dates and Float values in the P6 version of the schedule are aligned with expectations.

Out-of-Sequence Progress and Task Path Driving Predecessors in MSP 2016

The “Task Path” bar styles provide useful methods for identifying related tasks, including the Driving Predecessors path, for any selected task in MSP 2013+.  The Driving Predecessors Task Path is particularly useful for confirming the Critical Path of a project when Total Slack is complicated by other factors.  Unfortunately, the method is not successful when out-of-sequence progress is encountered.  As shown in the figure below – repeating the two previous examples in MSP 2016 – the Driving Predecessors Task Path (orange-colored bars) is terminated when an Actual Start is reached on the backward (right-to-left) pass.  Thus, driving Task Path functionality is not compatible with out-of-sequence progress.

[The Task Path functionality is equally incompatible with in-progress schedules that involve Finish-to-Finish relationships among overlapping tasks, even if none of the progress occurs out of sequence.  Any Actual Start value terminates the progression of the associated bar formatting flag.]

Out-of-Sequence Progress and BPC Logic Filter

The impacts of out-of-sequence progress on the Total Slack of some tasks are the result of specific decisions in MSP’s backward-pass algorithms for computing Late dates and Total Slack.  Obviously, the algorithm has been tweaked between MSP 2010 and MSP 2016 leading to the even more undesired results.

BPC Logic Filter – my company’s MSP add-in for logic analysis – generally ignores MSP’s Deadlines, Late dates, Actual dates, and Total Slack values.  Instead, it performs separate backward and forward traces to determine driving logic paths and relative float values.  The latter, like Free Float, can never be negative.  Thus, when BPC Logic Filter encounters out-of-sequence progress during a trace, zero relative float is applied, and a driving relationship is inferred.  As shown in the examples below, this approach results in the correct identification of driving and near-driving paths to project completion, even when out-of-sequence progress is encountered.  [In the bar charts, the path relative float is listed to the right of each bar.  A zero-value represents the driving path with the bar characteristically colored (maroon), positive values and associated bar colors indicate the number of days away from driving the project completion.  

BPC Logic Filter also includes a Project Logic Checker to identify logic issues in Microsoft Project tasks.  Like many such tools, it automatically flags OOS tasks, along with their immediate predecessors, for correction. (Beginning with release, 1.5.5.5, the tool also differentiates the important categories of OOS tasks.  The “-I” suffix in the bar chart below identifies out-of-sequence conditions where both predecessor and successor of the violated relationship remain Incomplete; total slack in such cases cannot be trusted.)

In addition, the Logic Inspector in BPC Logic Filter automatically flags tasks with out-of-sequence progress as well as all the relationships that are violated by such progress.  Here it is shown that the out-of-sequence progress on task SP2 violates its predecessor relationship with SP1.  The late dates and total slack of the predecessor (SP1) are incorrect.

Out-of-Sequence Progress in the Real World

This examination was prompted by an associate who, after a recent “upgrade” from MSP 2007 to MSP 2016, encountered numerous unexplained changes in the “Critical Path” during project updating.  As it turned out, the updated schedule contained extensive out-of-sequence progress that explained the observed behavior.  The out-of-sequence progress was the result of a schedule model that was ultimately invalid – a poor representation of the work, either as planned or as actually executed.  As is often the case in construction, this was aggravated by the persistent executive schedule pressure that converts some technological restraints (e.g. don’t start interior finishes until the building roof and skin are closed up) from mandatory requirements into mere preferences.

A typical invalid schedule model involves the representation of multiple overlapping activities as an over-simplified Finish-to-Start string.  For example, the schedule below shows five sequentially-related, non-critical tasks, of roughly equivalent work content, that are scheduled to occur over a five-week period.  Although they are shown sequentially, it is in fact customary to execute these five tasks nearly concurrently, with each task commencing as soon as its predecessor’s progress allows – and thereafter suspending or pacing progress to match that of its predecessors.

[Some schedule purists would suggest that these tasks should be broken down into many small, repetitive work packages, all arranged with pure Finish-to-Start logic relationships.  The resulting schedule is extremely detailed and reflects a true logical plan for executing the work.  In my experience, however, such a detailed plan can often be riddled with preferential logic that is ultimately over-ruled by field decisions.  Out-of-sequence progress – in spades – is the inevitable result; the scheduling workload multiplies with no added value.

Another approach might involve five parallel tasks, each of five weeks duration, modeled with continuous relationships or at the very least with compound (joint SS + FF) relationships.  Unfortunately, neither relationship is supported by MSP.  The dummy-milestone approach that I use to mimic compound relationships in MSP seems fairly esoteric, and the common alternative – using solely SS or FF relationships – can be problematic.]

The scheduler here has chosen the most expedient route, a simplified Finish-to-Start string of five activities.  Four weekly updates of actual progress then lead to the progressed schedule shown at the bottom of the figure.  While its appearance is substantially changed compared to the original plan, the progressed schedule – in MSP 2010 – seems to correctly depict the status and slack of the multiple in-progress, out-of-sequence tasks.  Thus MSP 2010 seems largely indifferent to the consequences of invalid logic combined with out-of-sequence progress, as long as the affected tasks are non-critical.

As my associate discovered, however, MSP 2016 is far less tolerant of such practices.  When the progressed schedule is recalculated in MSP 2016, the in-progress predecessors of the in-progress, out-of-sequence tasks are shown as Critical (with TS=0).  This is incorrect, as the tasks could all slip by 15 days without delaying the project.

For comparison, here are the corresponding updates for the identical project schedule in Oracle P6 (R18.8.10).  The dates and Float values are identical to those for MSP 2010; they are correct for these non-critical tasks.  (Original and Actual Durations in P6 are handled differently than in MSP, so those are not comparable.)

Review and Recommendations

Out-of-sequence progress is an unwelcome but often unavoidable occurrence in projects with logic-driven schedules.  It happens when the actual project execution is allowed to deviate from the plan in a way that creates logical conflict in the automatic scheduling calculations.  It typically results from a combination of the following circumstances:

1. The schedule plan includes logic relationships that are not technologically mandatory. I.e. there are a number of alternative methods available for sequencing a group of related activities, and only one (preferred) method is incorporated into the schedule.  In addition:
   • Procedural controls are inadequate to ensure that project execution conforms to the preferred logic sequence; or
   • Subsequent to initial schedule development, the preferred logic sequence is altered due to field conditions, resource limitations, or other factors.
2. Subsequent to initial schedule development, technologically-mandatory logical constraints are allowed to be violated – typically under schedule performance pressure – and the resulting technical risks are accepted.
3. The schedule is based on scope and logic definitions that are overly simplified compared to the actual or achievable plan of execution. E.g. simple Finish-to-Start relationships are used to represent overlapping, partly-concurrent activities.
4. Subsequent to occurrence of any of the prior circumstances, the schedule logic is not revised appropriately.
5. Schedule updates do not include regular review and correction of invalid logic in light of out-of-sequence progress.

In MSP, a task that is both started and completed out-of-sequence may cause the incomplete tasks in its predecessor and/or successor chains to become effectively open-ended, with impacts on Early and Late dates, Total Slack, and Critical task definition.  Consequently, the updated schedule may be invalid.

A task that is started out-of-sequence but remains in progress may cause substantial alterations to the Late dates, Total Slack, and Critical definitions of the incomplete tasks in its predecessor chains.  In particular:

1. (In all modern MSP versions) Total Slack of behind-schedule tasks will change from negative to zero and in some cases turn positive. [See also comment 1.] Although the Critical flag won’t always change, any identification of driving and driven logic paths that is based on negative Total Slack will be incorrect.
2. (In recent versions – e.g. MSP 2016) Total Slack of non-Critical tasks will change from positive to zero (with some exceptions), and each task will be incorrectly marked as Critical. [See also comment 1.]  Thus, the “Critical Path” and any other Slack-based identification of driving or driven logic paths will be incorrect.

These are pretty major consequences, yet their persistence suggests that they reflect as-designed behavior, not bugs.  It might even be suggested that the most recent “improvements” are intended to highlight the out-of-sequence progress – for correction of the associated logic.

In MSP, the only reliable way to avoid the negative consequences of out-of-sequence progress, in my opinion, is to avoid and/or minimize its occurrence.  Fundamentally, this means:

1. Ensure that project schedules are based on sound consideration of the scope and logic of project execution.
2. Ensure that procedural controls are put into place to a) validate, b) revise where necessary, and c) enforce the preferred sequence of activities.
3. Where necessary, revise the schedule logic to reflect the actual/required sequence of execution.
4. During regular progress updates, identify all out of sequence progress, and revise associated logic as appropriate to avoid the consequences noted above.