Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Windows analysis

1 reply [Last post]
John Kelly
User offline. Last seen 10 years 27 weeks ago. Offline
Joined: 18 Jul 2011
Posts: 25
Groups: None

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

 

 

 

 

 

Replies

Mike Testro
User offline. Last seen 6 weeks 6 days ago. Offline
Joined: 14 Dec 2005
Posts: 4418

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