Not good setup of schedule how to use in delay analysis

Hello Efren,

I am not an expert or master delay analyst, but to my novice experience in making the delay analysis presentation, you need to gather the information on those delayed IFC drawings issuance and foregoing. I guess it is documented with correspondences, minutes of meetings, and other pertinent papers about the subject. When was it really issued and what is its time impact on the project completion? Those are the vital question. Floats in your approved or accepted master program has to be given consideration as well in your claims as the client will make use of it to win the argument.

For the program presentation, you may add it in the schedule as a milestone or much more so if you can create a series of activities with actual durations leading to its issuance would be a great presentation. You may have it in one band of WBS for clarity or may show it next to the predecessor activities. Of course, you have to make a unique and noticeable ID numbering for additional activities in your program. Furthermore, you still need to link the predecessors and successors activities of those delayed drawing activities in anticipation to the in-depth reviewing of your EOT claim.

You need not to worry about float calcualtion at this stage as you are now dealing with the project actuals. On the first place, it must have been taken care of before the program presentation and acceptance by the client. No matter how you change at this point in time to show that there is not much float in your master program, it is maybe too late as the client may already have a copy of the orignally submitted program of work. What matters most now in your analysis is on how to convincingly demonstrate its delay impact to the overall project completion in the most comprehensive way of presentation. What I have done in our EOT claim at our recently completed project is that I utilized excel spreadsheets and dealt with program summaries in relation to the subject EOT claim with narrative support of explanation at the end column. As I was using a P5 program in that project, I also added Remarks/Notes column in the program with text input for justification and impact of the delay. Of course, you need to make compilations of your supporting documents such as correspondences and the like.

Primavera printout presentation alone may not be enough to explain or justify the delay. Also use other means like the excel spreadsheets with summaries as the board of your program reviewers may not be too interested in going through the lenghty program details.

Hoping to have shared a lot with you.

In Service,
Ferdinand

Plese note that I had been referring to "client" in my narrative below as I am on the contractor side. I guess you may understand then wht I am trying to stress therein.

Hoping for your comments and additional input.

Thanks.

Thanks Mr. Ferdinand for your very good and well experience suggestions

You’re welcome Efren. Walang anuman.

I will be tempted to correct the base line (the not good setup of schedule) before using the programme in the delay analysis. This is acceptable if justified.

Granting that the Baseline was already approved, then it is good as good. You can make it as basis for comparison with your Updated schedule.

I totally agree with you Anoon, however am not sure if Efren is able to do that. If efren is, that means the not so good schedule is not really that bad. Just an opinion.

I have to agree with Nestor, I think the logical thing to do is to correct the baseline first and delete all activities which are not part of your original scope and add activities which are in your original scope, this way you are comparing apples against apples.

You also need to do this in your current updated programme and add all the events which have impacted your programme (based on actual dates), i.e. late issuance of IFC drawings, change orders, late access, typhoons, etc.

On the other hand, the contractor has an obligation to mitigate delays without incurring additional cost and the contractor needs to prove that they have taken such measures like work around and this should be demostrated in your programme.

Cheers,
Daniel

Hi All,

Going back to post no. 1, Efren mentioned that the Baseline was approved and i supposed the works were almost complete (98% as mentioned). Nestor was right, not bad at all.

May I suggest that you leave the Baseline as it is, never do anything or never change it, (anyway you can never change actuals, or time in the past). I also assumed that no re-baselining was done, thus, you only got one original baseline, which makes the work much easier.

Work on your current updated schedule, and make a comparison (Original Target vs. Current/Updated Schedule). The comparison might be apples to bananas, but it will make you aware that from the original plan to produce apples, it came out to be bananas (that’s the difference between Plan and reality).

cheers!

Hi Effren

I have come in a bit late on this thread.

My advice is save your approved baseline into a new file and call it something like EOT Presentation.

Then take out all the unused activities by changing them into ZERO duarion milestones.

Then add in the missing activities - using a different colour code.

Reschedule and see what differences there are in float and / or critical path to the original baseline.

If youe EOT presentaion is generally shorter than the original baseline then you will be giving away some float.

If it is longer then you will be starting with a period of culpable delay - this cannot be helped.

I do not advise "fiddling" the changes to make things fit - you will lose all credibility.

Then add the delay itmes as big bright red bars and link up to the delayed activities and see what happens to your critical path.

Then check back to your as built situation. You may have to re-run your original progress reports on the new EOT presention.

You will then have the makings of a reasonable delay analysis presentation.

Best regards

Mike Testro