Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 5

HANDLING OUT OF SEQUENCE PROGRESS IN AN UPDATED P6 SCHEDULE

What is Out of Sequence Progress in Primavera P6?


Out of Sequence Progress occurs from a deviation in the original planned logic that was set up in the baseline schedule. It can occur when work is executed
in the field in a different order than was planned in the schedule. The result can affect your projects logic, which dictates the order of execution of activities.
Checking for Out of Sequence progress
To check for Out of Sequence Progress in an updated schedule the following steps must be taken.
By selecting the F9 key or the Schedule hot key the Schedule dialog box will appear. There is a Log to File function that creates a summary level report from
the current project. The Log to File box must be checked and a location for the file needs to be mapped by selecting the browse button (box with four dots).
If a log file has not been run in the current database a Specify Log File dialog box will appear. To create the log select YES in the dialog box if prompted.
See graphics below.

Map and name the Log file to the desktop or a specific drive.

Dealing with Out of Sequence Progress in an updated Primavera P6 schedule
A summary report with various sections will be produced, but the focus of this discussion is the output file for Out of Sequence Activities within this report.
This portion of the report shows the number of Out of Sequence activities, Project ID, Activity ID and the Activity Descripti on for all Out of Sequence
activities in the current project. See graphic below.

NOTE: This report should be run every time an update is done (i.e. weekly or monthly).After running and printing the report each out of sequence activity
should be reviewed and corrected (if possible). Depending on the project there can be several different types of Out of Sequence Progress occurring and
each may have a specific solution.

Out of Sequence Progress : Example 1
Analysis
In the first example, activity 110ERI2131 is an activity in the report above that has out of sequence progress that needs to be addressed. See highlighted
activity above Example 1.
To see why the issue is occurring, the original logic must be understood. In the baseline schedule the original logic was set up as Install Lighting Conduit
Columns 7-15 and was to be installed before the Lighting Conduit Columns 15-21 as a Finish-to-Start relationship. See the graphic depicting this baseline
logic below.

After approval of the baseline schedule and the start of updating the project schedules, the projects logic can always change depending on what is being
installed in the field. In this instance, the logic has changed and the Lighting Conduit Col 15-21 is now actually starting first, but the existing logic (from the
baseline) remains the same and is causing Out of Sequence Progress by pushing out the Lighting Conduit Col 15-21 end date incorrectly. See the graphic
below.

Correcting the logic
To correct this type of Out of Sequence Progress, the logic must be altered to reflect the correct flow of work. In this case, the Finish-to-Start (FS) tie from
INSTALL LIGHTING CONDUIT Col 7-15 to INSTALL LIGHTING CONDUIT COL 15-21 needs to be broken and re-tied showing the Conduit Col 7-15 as
following (successor to) the Conduit Col 15-21. See graphics below.


By removing the Lighting Conduit Col 7-15 as a predecessor and making it a successor to Lighting Conduit 15-21 the Out of Sequence Progress has been
eliminated and the logic is now modeling what is taking place in the field. However, in doing this, the Lighting Conduit 15-21 no longer has a Predecessor tie
and cannot be left this way. A properly statused activity that logically precedes the Lighting Conduit Col 15-21 will need to be tied as a proper predecessor.
Open ends on installation activities are not acceptable.

Out of Sequence Progress : Example 2
Analysis
Another example from the log report would be activity 108ERI4343 (see example 2 above). The original logic (baseline) was a Finish-to-Start (FS) tie from
108ERI4343 to 108ERI4344. In the updated schedule this scenario clearly depicts two activities that are being worked concurrently while their original logic
remains tied as end-to-end (i.e. Finish-to-Start).

Correcting the logic
In this scenario the logic should be changed to reflect the concurrent work (in the field) which would result in the predecessor (to 108ERI4344) tie being
changed to a Finish-to-Finish (FF), lag 2 days. The lag shows that consideration has been taken to make sure the activities do not finish conveniently on the
same day after changing the logic. See graphic below.

With the logic changed and the Out of Sequence progress resolved, the relationship between the two activities now looks like the graphic below.


Out of Sequence Progress : Example 3
Analysis
In the last example the Out of Sequence progress cannot be resolved and must be left in place to show true representation of the
work currently happening in the field. In this example activity 106EMB1010 Mobilize WV (example 3 see above) has started but
its predecessor activity 106AMWV2000 has not which is clearly causing Out of Sequence progress. See first graphic below. In this
instance the owner directed the contractor to perform ductbank work earlier than originally scheduled stating that this work is
unrelated to the station work which is scheduled to be performed later which would be preceded by the contractual access activity.

Retaining the Original Logic
The logic should stay intact to reflect the Out of Sequence work being performed. This Out of Sequence work should be quantified
and noted in the monthly update narrative that gets transmitted to the general contractor.

Conclusion
As shown in the examples above, most out of sequence progress can be resolved, but where it cannot, or more importantly, where it should be retained, it
should be communicated to all parties involved in the schedule clearly.
Out of sequence progress can be inevitable due to changing conditions on the project site, but how it is handled during the life cycle of the CPM schedule is
the more important aspect.
Reviewing the accuracy of the schedule logic against the sequence of the installation work in the field is the key and the logic should be analyzed during
every update period. Whenever logic has been revised from the baseline plan it should be noted in a monthly schedule narrative or a letter to the
owner/general contractor specifying all logic changes. If schedule logic is continuously revised each update period to reflect the sequence of work in the field
a full schedule review might be warranted to determine if a re-baseline plan is needed.
Comments
1. Mahmoud says
June 29, 2013 at 6:16 am
good lesson Sean, but the third example in not clear..
Reply
2. Larry Erbe says
June 30, 2013 at 3:50 pm
Couple of questions, when out of sequence work occures and the work being done out of sequence is 100% complete, therefore no longer affecting its
successor, is it still necessary to redo the logic? (In answering this question assume the remaining activity will start on the current data date therefore a
logical predecessor is not needed to push the activity out to a specific start date.) Also, more importantly, will not corrected logic for completed activities
have any effect the remaining critical path activities? (I cant imaging it does but need to be sure.)
Reply
3. Larry Erbe says
June 30, 2013 at 5:31 pm
Follow up question, if the baseline showed an activity(s) as NOT critical how are you to determine (at the time of schedulimg) if, now that it was done out of
sequence, whether or not is became critical and therefore any delay to the out of sequence work is subject to compensatory time? This is especially difficult
for me if the out of sequence work is 100% completed between schedule updates.
Reply
4. Sean Cain says
July 1, 2013 at 7:28 am
Mahmoud,
Thanks for your comments. Maybe I should have used a different example. Typically, as a contractor, we do not get schedules from the General Contractor
and we need to track the key predecessors to our work (work by others that drives our work) in our schedule. In doing that we do not put the complete
activity in but, just the predecessor. So in a case where the work by others is not complete and ultimately holds up our work, we leave the out-of-sequence
work in place to show that we still need that predecessor to finish before our work can complete. I hope that is clearer.
Larry,
To your first question, yes, the out-of-sequence work should be corrected even if one of the activities in question is complete. It is good practice to review all
out-of-sequence work each update period to make sure you do not have a very long list (of OOS) as well as not to have any remaining duration pushing
through complete activity logic. The effect on the critical path will be that you have good forecasted end dates and not any issues of out-of-sequence
working inadvertently pushing out any work that is not complete. In regards to the second question, you cannot ask for compensation until you have used up
all available float (youve gone negative) and this can be quantified by comparing your current update to the baseline schedule to see if there has been a
delay issue. Out-of-sequence logic does not necessarily cause negative float but, it can use up available float very easily and the more out-of-sequence
logic you have the more issues you will have with incorrect forecast dates and less available float for all the activities tied to the out-of-sequence (in
question).
Reply
5. GfreddieK says
July 7, 2013 at 8:19 am
In correcting the logic of the Out of Sequence activities, do you change the scheduling option from Retained Logic to Progress Overide? or you just keep it
Retained Logic until the project is done.
Reply
6. Sean Cain says
July 8, 2013 at 7:38 am
Freddie,
I would not advise switching between the Retained Logic or Progress Override setting on any project regardless of the out-of-sequence activities. You need
to check what the contract specifies for which option is to be used and that setting should be used for the duration of the project. Most projects will specify
the use of Retained Logic.
Reply
7. tajamal says
September 10, 2013 at 9:45 am
while updating the schedule the predecessor completed before its planned finish date , n this completion have no effect on successor whose start data is
behind the data date .as in my opinion successor should take the data date as the start date bcz the predecessor is completed before the its planned finish
date.
plz reply Mr. Sean Cain
Reply
8. Sean Cain says
September 12, 2013 at 11:12 am
Tajamal,
That would be assuming the logic tie is a SS relationship. With the predecessor activity NOT complete, it will still drive the successor properly which is
shown above in the example.
Reply
9. Sean Cain says
September 16, 2013 at 3:10 pm
Another thing to remember is that even though a predecessor is complete, ITS predecessor may not and can continue to push through to follow-on
successors.
Reply
10. Kishore A Nair says
June 22, 2014 at 1:16 am
** In this case that is, while fixing out of sequence activities, I think we are loosing a baseline to compare. Because if we change the link in the update then
the sequence in the baseline and the update will have a different flow . So we cannot compare the baseline dates and logic with the updates thereafter.
So on which program we will prepare the EOT.Based on which program dates we can send delay notices?
Reply
11. Sean Cain says
June 23, 2014 at 10:20 am
Kishore,
The Update tracks the progress of a project and is supposed to adapt and change to what is going on with said project, whereas the baseline stays
untouched. You must certainly fix any out-of-sequence progress encountered with the project because the update is not always going to track what the
baseline laid out. This is very common in most forms of construction and is expected to be implemented where necessary. Remember, the baseline is the
original plan for the project and it is a best case scenario for the buildout of the the project. The update is as built status, current forecast and future forecast
that changes with the project.
Any delay notices should be based off the update, although you can also show delays in a copy of the baseline for some forms of delay analysis.
Reply
o Kishore A Nair says
June 28, 2014 at 4:10 am
Thanks Sean,
What you said is correct and logical. But generally I think we required prior consent from client for this kind of scheduling.
Also could you please suggest me some references about this practice. So that I could convince my people over here about this practice.
Thank you so much and Will be watching the blog closely for these kind of informative tips.
Reply

You might also like