i wanted to know that how primavera identify the oos?
how can we categorized the oos?
how can we filter the oos activities (not from the log)?

thanks mr. jerome ijachi odeh,

azeemus

greetings to all

i really do not realize how consultant asks for such logs to be kept and recorded, it is either they are super-powerful planners and above the nature or they are really do not know the volume of work required to log such changes.
to be more specific when working in a none typical project that consist of multiple buildings in different locations and multi disciple activities of epc nature with restrictions on 世界杯时间比赛时间 such as offshore projects, and a list of activities that exceed 10k, the sequence of work is something that cannot be controlled during the execution specially when the work open front is not released for contractor as planned, if we need to keep logging such stoppage and resubmit the schedule with all backups to get client approval we will end up doing the planning package on every weekly report and never have a constant plan / target.

as a contractor i would agree the schedule with client approval and keep the logic unchanged whatsoever this will serve the project forecast and eot.

however at a certain stage, the schedule forecast completion date will absolutely become unacceptable, this is when a real change is required by re-visiting the critical path and the remaining works status with respect to uncompleted activities that are driving the critical path, a revised schedule then can be submitted to get the necessary approval but again this is to be done when it is really required.

thanks nelson,

=jerome

riyad,

appreciate your comment about contractual implication of changing logic but the tutorial is about a quick way to trace out of sequence activities when retained logic setting in p6 is in place. instead of spending minutes trying to find where the problem lies, it is hoped that this method will save time.

i also added a caveat in my conclusion that logic should only be changed if permitted on the project.

kind regards,
=jerome

progressing situations with out-of-sequence issues are sticky indeed. if the schedule was progressed in an order that is not represented in the schedule, and a contract or schedule spec states that p6 must stick to retained logic, then the recommendation is to adjust the logic of the progressed activities to represent the order that activities were in fact executed. the most important aspect about this is communication about out-of-sequence with the team – a discussion that focuses on how to handle these situations and how to reflect them in the schedule. so discuss first so everyone understands what you’re doing to the schedule. utimately, the progress schedule should reflect how the work was executed in the field, and a log should be kept with the changes made to the logic. of course, every project and contract will be different (and likely frustrating).

in the absence of any mention in the contract i have followed the task of identifying and correcting the out-of-sequence relationships in already progressed activities in few of my contracts with strict coordination and agreement with the contractor. i have seen in such cases that the forecast dates are very reliable. the major disadvantage is that such transparency needs to be ensured throughout especially considering the fact that the contractors mostly fail to maintain a log leading to the control over the updated schedule practically spoiled. it can lead to further unnecessary complications when dealing with the extension of time claims especially when there are disagreements on the implemented changes to logic.

i suggest to adopt this step if we can maintain logs and the contractor and consultant agrees on the changes as a log each time before such changes actually takes place and the log is communicated, verified and agreed upon – otherwise the normal constraints like ‘baseline programme to be maintained as a bible’ applies. practically i have noticed that it is not a good decision considering the several instances where the contractor’s planning person makes several changes without logging them.

the practical way of getting out is to estimate precisely when to raise the flag regarding revised baseline programme which is implemented in most projects due to the resistance of the contractor and the existence of claim events. the revised programme should be submitted and approved at a fast pace before these out-of-sequence activities exceed an acceptable level and the updated baseline programme becomes a useless entity which misleads the whole project and it’s stakeholders.

in projects where the logs were maintained and the contractor was transparent and honest, the results were outstanding and the programme gave realistic dates. the idea is to first verify the programme without the required changes in logic and then do the changes in coordination and agreement after updating the necessary logs. each time you have to observe the status of the yet to start activities and note that the dates are realistic – if they are not an expert decision has to made on when to raise the flag to go for a revised and updated baseline programme.

the above is not applicable in projects where the contract allows for a ‘progress override’ method while observing out-of-sequence activities. this also has its merits and demerits when it comes to extension of time claims which itself is a wider topic to cover here.

thanks joe

=jerome

usually i just deleted the predecessor when this happen, there 100% anyway it’s a shortcut solution if your are not constrained by the client scheduling requirements.

but this is the way we should fix the error, and i salute you for giving us this tips.

thank you.

tijo,

unfortunately, i’m not in a position to produce a video tutorial.

jerome

can you please prepare the video for this

thanks derek,

glad you found this quick tip useful.

kind regards,
jerome