When monitoring and responding to the Contractor’s schedule performance on the project, how do you know if the schedule update is even valid for use?
When we review a schedule progress update, we need to first determine if the schedule update is a valid update. By that, I mean is the logic still complete? Have there been any revisions with this update that result in the schedule not meeting the contract requirements or best practices? It doesn’t take much to render a schedule useless….
There are most likely logic revisions, changes to lag values, or possible changes to calendars or assignments. There are also deletions and additions of activities and/or Activity Relationships. Then there are changes to quantities or Resources which may impact Activity Durations or Resource Calendars.
For this post, we will address the lack of correcting Out-of-Sequence, OOS Logic.
Personally, the first schedule “quality check” I make is for complete logic. Please see the previous post, Schedule Performance Measurement, Part 2. (For Owners).
Next, I check for changes to Relationships and Relationship Lags. Please see the previous post, Schedule Performance Measurement, Part 3. (For Owners).
I then check for changes to Activity and Relationship Calendars and Calendar assignments.
But, my personal pet peeve is OOS Logic which has not been addressed.
When the Contractor is assigning actual and expected dates to the schedule update, while assigning the current progress for work in progress, it is common and acceptable for actual work in the field to have been executed differently than planned. This results in Out-of-Sequence, OOS Logic.
Primavera P6 provides a Schedule Log with lots of information. One of the things this log provides is a list of activities with OOS Logic. This is simply a list of activities with assigned Actual Dates which are not progressed the same as the Schedule Network Logic.
For example, if activity A drives activity B with an FS Relationship and Activity A is assigned an Actual Start Date with a projected scheduled Finish Date and activity B is assigned an Actual Start Date, activity A will show up on the Schedule Log as having OOS Logic because activity A does not have an Actual Finish Date prior to activity B actually starting. This condition is simple to correct. We simply change the logic to an SS relationship. This allows the as-built relationship to match the revised logic. If activity A has not actually started and activity B is assigned an Actual Start Date, then more work must be done to correct the OOS logic. Activity A is obviously either not progressed and missing the Actual Start and Finish dates or the actual sequencing of the work is being executed differently than planned and activity A should no longer be the predecessor to activity B.
If the issue is OOS logic, it should be addressed. Leaving OOS logic in the schedule allows the now incorrect logic to drive the successor activity dates, which is incorrect. This happens when we use Retained Logic, which most schedule specifications require. It is also best to use Retained Logic to allow the planned logic to drive the schedule. We just have to correct the OOS logic with each update.
Not correcting OOS logic with each update can produce erroneous specific Network Path scheduled activity dates. This can create a Critical Path based on the original logic which is no longer valid due to the actual OOS work in the field. We want the Critical Path, and Near Critical Path(s) to be based on the most accurate progress input and plan to execute the remaining work.
Typically, correcting OOS logic for driving activities on the Critical Path will shorten the Remaining Duration of the Project Schedule. I prefer to correct the OOS Logic immediately after I assign the actual dates, expected dates, and actual progress. This way, when we need to determine the best method of recovering any lost time, we are working with a valid Schedule Network.
The same applies to Near Critical Path(s).
That said, understanding the impact of the uncorrected OOS Logic, and reporting those findings is important to the Owner. Personally, I do not consider the Schedule Update valid if the OOS Logic is not corrected. But many schedule specifications do not address this issue.
As Planning and Schedule Professionals, we need to provide the Project Team with the “tools” they need to manage the project. The owner needs to know what the performance of the actual work in the field is, compared to the planned performance. Unless we have a valid schedule update to measure with, and against, and understand the impact of acceptable schedule revisions, we cannot provide an accurate measurement.
I’m sure many of you have comments or additional insight into this subject. Please share!
I’d love to hear what you think!
Please visit https://conschmanservices.com to learn more about Construction and Schedule Management Services, LLC
Please visit my LinkedIn account to learn more about me.
Please visit my “The Blue Book” ProView.
Paul Epperson CCM, PMP, PSP, PMI-SP