Windows analysis

J
John Kelly 👤 Member for 14 years 10 months

Hi there. (apologies in advance for the long winded article)

I am currently working on rebutting a Contractors claim. 

The Contractor has presented the delay analysis using a Time impact analysis to demonstrate the effect of the Employers delaying events.  I am pretty certain that in a lot of the cases the Contractor was concurrently in delay but need to prove it.

I am looking to adopt a Windows as planned Versus As built analysis to assess what the Critical path was on a monthly basis, i plan to do this as follows;

1. Identify the Baseline programme

2. Correct any anomalies in the programme, unnecessary constraints, missing logic etc with contractors approval.

3.Import the progress for month 1 into the baseline programme and asess any movement to key milestones and identify the Critical path for that month, lack of progress or activites late starting etc will be identified as the critical delay for that month.

4. Then import progress for month 2 into the updated programme from step 3 above, and again asess any movement to key milestones and identify critical path, this procedure will be repeated to the Project completion/last available update.

 

This method retains the Contractors baseline logic (in front of the data date) and this is where i believe i may be going wrong. 

Having read an article By David Barry on delay analysis he recommends that the future intention of the Contractor must be taken into consideration at each window, so for example say in Window 3 the Contractor was planing to try and carry out some works concurrently during the latter stages of the project in an attempt to mitigate delay then this must be accounted for, ie change the logic to reflect the planned mitigation.

By making the said changes to logic it will undoubtedly lessen the entitlement to Contractors EOT for that month where as leaving the logic as per the baseline logic will give the Contractor a greater entitlement for that month.

I believe that by leaving the logic as per the baseline the mitigation of delay will be accounted for when the progress is assesed for the period in question, ie the work that was planned to be carried out sequentailly and is then carried out concurrently will result in an earlier forecast for the milestone and go down as mitigation for the contractor. 

By changing the future logic and say for example the planned mitigation never materialises for whatever reason i believe will then go down as delay against the contractor for the period in question even though he thought he could mitigate some delay but then never materialises.

So my question is should the logic in front of the data be as per the monthly updates or should the Basleine logic be retained, i understand that if there is a new revision to the Baseline then obviously that then becomes the planned intent of the Contractor.

 

Apologies for the long winded article and thanks in advance for any thoughts/advice

 

 

 

 

 

M
Mike Testro 👤 Member for 20 years 5 months

Hi John

You have described the inherent problem of using windows analysis and why I would never use it.

Let us start with the three "Building Blocks" required for a Time Impact Analysis (UK Terminology)

1. If the project is nearing completion then you have the full as built record and can reconstruct an as built programme in as much detail as possible.

2. You are in the process of setting up a viable baseline programme.

3. You have not mentioned an Events Schedule but this needs to be developed - including both Employer and Contractor delays.

Now when you have all three in place you can start the Time Impact Analysis by setting up the event schedule in Chronological Order of Delay Impact.

Then Impact the events one by one starting with the earliest.

There will be four possible results in respect of the Baseline compared to the As Built.

1. The Baseline Start is later than the impact date so no effect at all.

2. The Impacted Task falls short of the As Built in which case something else caused a further delay.

3. The Impacted Task lays over the the As Built in which case the cause and effect can be said to be proven within the "Bounds of Probability"

4. The Impacted Task overshoots the As Built in which case some sort of Mitigation must have taken place to adjust the baseline programme.

If you know what adjustments were made to the logic or resource levels then apply them at this stage - if not you will have to make your own adjustments based on experience of what a contractor would have done in the circumstances.

Always keep in mind that the results are entirely theoretical and do not necessarily reflect what actually happened.

All of the above is described - with working examples - in my book "Basic Priciples of Delay Analysis" now available for download from my website:

www.expertdelayanalysis.com

£25.00 for the first 100 downloads.

Best regards

Mike Testro

Forum Sponsor

Top Posters

Julian Pegg
1 posts
Peter Nagy
2 posts
Raymund de Laza
17 posts
Syed_Asad
0 posts
Tony Greyvenstein
0 posts
Ahmed Al-Jubouri
13 posts
Umar Alvi
3 posts
Sibusiso Mahlalela
0 posts
Michael Samanyayi
3 posts
Simon Gumede
0 posts