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 - Delay longer than window

20 replies [Last post]
C S
User offline. Last seen 3 years 48 weeks ago. Offline
Joined: 19 Feb 2015
Posts: 5
Groups: None

Does anyone have any advice on what I should in a situation where I am undertaking a windows analysis and the resulting delay is longer than the duraiton of the window itself? It seems a bit counterintuitive that for example I am showing a 60 day delay in a 30 day window.

What is considered "best practice" in these situations?  

Replies

Baris Hazar
User offline. Last seen 3 years 1 day ago. Offline
Joined: 4 Dec 2009
Posts: 39
Hi Mike, I totally agree with your advices. No objection at all. But please note that the discussion itself started by CS is purely related to specific detail and what you write now has limited relevance to the topic. Regards Baris
Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi Baris

I am leaving this disussion now with the following advice.

You will never be a delay analyst by reading books and protocols.

It is not a science it is an art - even a dark art - based on years of experience and intuition.

After 53 years as a Builder I started delay analysis 23 years ago and I am still learning and what I have learned in the last few years is when the "Book" has to be side stepped in favour of a common sense approach.

My best advantage is that I am NOT a planner - I am a builder who can work the software.

You have to know the law in your jurisdiction in respect of the signed contract.

Discover the quality of the records available and make a judgement.

1. Is it good enough.

2. Is it true.

Get to the nub of the delay problem in the first week - and then tell your client how strong a case he has - walk away if it is too weak - your reputation is only as good as your last case.

The 1st rule is "Never Believe a Word that your Client Tells You" - until he can show you the piece of paper.

If you go ahead then work out how to tell the story to the tribunal - keep it:

a. Simple

b. true

c. accurate

Finally - If you do not know then ask someone who does - there is no such thing a stupid question. But you have to know if you have got a stupid answer.

Good luck and good bye.

Mike Testro.

Baris Hazar
User offline. Last seen 3 years 1 day ago. Offline
Joined: 4 Dec 2009
Posts: 39

Thanks for sharing Rafael. I will have a look. 

Baris Hazar
User offline. Last seen 3 years 1 day ago. Offline
Joined: 4 Dec 2009
Posts: 39

Hi Kannan,

Thanks for joining the discussion. Although I have a similar opinion, let me clarify my stance in order not to leave any gaps in our understanding. Because, in the trailing comments, I got a little confusion.

SCL Protocol clearly defines the methodology to determine the EoT entitlement with TIA. In accordance with the methodology:

Let's assume that the delay is caused solely by Employer in order not to bother ourselves with concurrency issue, 

Then:

1- Identify and quantify the delay event: Delay Event X having ST Date: Y, FN Date: Z, Duration: D

2- Update the schedule just before the start date of delay event. If delay event start date is say 01 January 2016, then the updated schedule data date should also be 01 January 2016 which means that the schedule contains the actual progress as of 31 December 2015. (This might not always be possible, but consideration must be given to the fact that the schedule data date should be as close as possible to the start date of Delay Event)

3-Make a copy of the updated programme and call it un-impacted version which will be used as a reference baseline afterwards 

4- Insert the delay event into the updated schedule with the given dates and duration.

5- Link the delay event with logical successor activities

6- Run the schedule which will give you impacted schedule.

7- Assign the un-impacted copy of the original programme as a baseline to the impacted programme, and measure the slippage as compared to the original un-impacted programme.

8- If the impacted schedule shows a completion date later than the un-impacted version, then the difference in calendar days will be the EoT entitlement of Contractor (Excusable and compensable)

Important Remark for Item 8: If the completion date reached by the impacted programme shows a date later than un-impacted programme but still before the contractual completion date in the original project baseline, then there is no EoT entitlement. In this case, just the TF is consumed due to the default of Employer. (This is another grey area- Ownership of Float)

9- If not, then no EoT entitlement. Delay event consumed some of the TF but it wasn't big enough to shift the completion date.

 

AACE 29R-03 advises to use 3 schedules to analyse the situation: Un-impacted schedule, Impacted Schedule and Progressed Schedule. Out of these 3 schedules:

Un-impacted Schedule is the one which is free off delay event.

Impacted Schedule is the one incorporating the delay event.

Progressed Schedule is the one having a data date coincides with the end date of the delay event.

 

RP states that the completion date reached by the impacted schedule should be compared against the one in the Progressed Schedule to analyse if the results are hypothetical or not. 

I find this comparison very useful to measure if the results of delay analysis are really reasonable.

Regards,

Baris

Kannan CP
User offline. Last seen 5 weeks 4 days ago. Offline
Joined: 12 Jun 2008
Posts: 280
Groups: None

Hi Baris,

In my understanding of SCL, you have to update the program just before the start of the delay event. This is to understand the delays by the contractor in other paths(as of that period), which may affect the contract completion date.

So in the succeeding month updates (just before the closing of the event) you can analyse the delay by the contractor on the other paths.

Just after the closing of the delay event, update the program and see the impact on the completion date.

You have to analyze the concurrent delay by the contractor to evaluate the prolongation cost, excusable/non excusable delays.

Best Regards

Kannan

Rafael Davila
User offline. Last seen 9 hours 58 min ago. Offline
Joined: 1 Mar 2004
Posts: 4852

The best of all is "voodoo analysis", as per following reference.

http://barbaconsulting.com/wp-content/uploads/2011/12/fall-2009-const-la...

Best Regards,

Papa Doc

Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi Baris

Both statements are correct - they mean the same thing.

I read the AACE document and could not understand a word of it.

Best regards

Mike T.

Baris Hazar
User offline. Last seen 3 years 1 day ago. Offline
Joined: 4 Dec 2009
Posts: 39

Hi Mike,

In this case, SCL says 'use the schedule update just before the delay event or risk event' and you say 'use the schdule update which is closest to the end of delay event'. I am confused. Which statement is correct?

Regarding Windows analysis:

SCL stresses on the good merits of TIA and maybe doesn't recognize Windows method as an alternative. However, AACE 29R-03 provides a better framework on the delay analysis methods and Windows analysis is one of them.

Regards,

Baris

Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi Baris

Employer risk event and employer delay event are the same thing.

The SCL protocol did not foresee a rolling event and in any case it does not recognise Windows as a delay analysis method.

Best regards

Mike Testro

Baris Hazar
User offline. Last seen 3 years 1 day ago. Offline
Joined: 4 Dec 2009
Posts: 39

Hello Mike,

I do appreciate your detailed explanations. Thanks a lot.

I will slightly modify my scenario as follows:

Lets imagine that the delay event A ends on 1st of June instead of 15th of May. In this case, we wouldn't need to spend effort to interpolate the progress to update the schedule by 15th of May for our case.

In this case, as you stressed, we have a schedule update which even coincides with the end date of the delay event.

So, now let's come to the 'impact delay event' stage:

As far as I understand from your statements, I am supposed to use the Jun 2015 update having a data date of 1st of Jun 2016 in order to calculate the delay impact. Also, I have a delay event having a start and finish dates which is earlier than my data date (1st June).

In this case, how am I supposed to model the delay event within Jun 2015 update if its finish date is before my data date?

You might say that "Just insert the delay event, link with the logical successors, give a remaining duration of 90 days, and press F9.". Because this would be the only answer in order to see an impact from the delay event on the project completion date.

BUT:

This delay event occured between Mar and Jun 2015. So weren't I supposed to use Mar 2015 schedule having a data date of 1st of Mar 2015 and closest to the beginning of delay event.

My basis is SCL Guidance Section 3.2.7.1 which says "the Programme should be brought fully up to date to the point immediately before the occurrence of the Employer Risk Event"

In our case, we don't have an Employer Risk event but an Employer Delay event which can retrospectively be considered as Employer Risk Event if we go back to Mar 2015 and use blindsight method.

 

Thanks,

Regards,

Baris

 

Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi CS

You are confusing TIA and Windows.

If you insist on using Windows and you have an event that straddles more than one window then you have to impact the event at the end of each window.

If it is a TIA then you enter progress just before the event ends.

Best regards

Mike T.

C S
User offline. Last seen 3 years 48 weeks ago. Offline
Joined: 19 Feb 2015
Posts: 5
Groups: None

Thanks for all the informative responses. Am I right in summarising that a delay longer that an individual wondow period should be spread over multiple windows and that the overall delay arising should only be calculated at the end of the final window?

 

If using a TIA do I update the progress at the end of each window or at the end of the delay event in whichever window that happens to be? 

Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi Baris

You have focused on one of the dificulties with TIA when the updates are so far apart.

The rules say that you must update the programme immediately before the end date of the event.

Your event ends on 15th May which is exaclty halfway between update 1st May and 1st June.

Therefore you interpolate the progress as 50% between 1st May and 1st June so that you get the % complete at the 15th May.

If the event ended on 10th May then use 33% and 20th may 66% etc.

This is not an exact "fact" but it is a reasonable assumption to make in the circumstances.

So update the progress calculated at 15th May and then impact your event.

If it is a forensic analysis then I have developed a pice of software that will show the % complete to 2 decimal places for all tasks for any date during the construction process - based on QA-QC inspection records - but that is my copyright.

Best regards

Mike Testro

Baris Hazar
User offline. Last seen 3 years 1 day ago. Offline
Joined: 4 Dec 2009
Posts: 39

Hi Mike,

Thanks for the reply!

Just to clarify the issue, appreciate if you could take a look at the scenario below.

Project X has a baseline schedule having a data date of say 01 Jan 2015. 

  • 1st update: 01 Feb 2015
  • 2nd update: 01 Mar 2015
  • 3rd update: 01 Apr 2015
  • 4th update: 01 May 2015
  • 5th update: 01 Jun 2015
  • 6th update: 01 Jul 2015

....

  • Delay analysis is to be made within August 2015 period and project is ongoing.
  • The delay event A has a start date of 01 Mar 2015 and finish date is 15 May 2015. (75 calendar days)

Question 1:

So if to use TIA, which schedule update would you use for the analysis?

Question 2:

What would be the start and end dates of the delay event A inserted into the program?

Cheers,

 

Baris

Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi Rafael

That is exactly what happened to me in a recent arbitration.

An Italian cladding contractor working for a French main contractor for an American oil company in Sakhalin Island was in arbitration in London.

I was appointed as expert for the Italian cladding contractor.

One short Main Contractor's delay took the installation of the cladding into the winter period and added 6 months to the completion date.

My client asked for a negotiating programme which I produced - two weeks later they settled with the main contractor.

One other - point the applicable law was of the State of New York.

Thats how it works.

Best regards

Mike testro.

Rafael Davila
User offline. Last seen 9 hours 58 min ago. Offline
Joined: 1 Mar 2004
Posts: 4852

What if you are in Siberia and a 4 week delay gets you into 6 months winter?

Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi Baris

The rule book says that you update the programme to a point just before the impact of the event.

In your case that would mean skipping the first two updates.

So much simpler than doing it three times for the one event.

Best regards

Mike Testro

Baris Hazar
User offline. Last seen 3 years 1 day ago. Offline
Joined: 4 Dec 2009
Posts: 39

Hi CS,

You cannot insert a delay event having 60 days duration into a 30 days window. I recommend you to divide the delay event into 2 windows. Impact of the first part of the delay event will be analyzed in the first window, and second part will be analyzed in the second window. 

 

Hi Mike,

Would you be so kind to explain how TIA would help for the question addressed by CS? What if we are talking about a delay event, say 90 days, covering a period of 3 consecutive schedule updates. How correct or reasonable would it be to project the completion date by inserting a 90 days delay event into a single schedule update rather than analysing it within 3? 

Thanks in advance.

Regards,

 

Baris

Mike Testro
User offline. Last seen 1 week 22 hours ago. Offline
Joined: 14 Dec 2005
Posts: 4399

Hi CS

This is one of the fundamental flaws in a retrospective windows analysis.

Windows was designed for delays as the work proceeds and should not be used for retrospective delays.

When reviewing each window you have to pretend that you do not know what is happening in the next windows.

So you have to fill the first window with part of the event (mark it as 1st section) and project the completion date for that bit then put the rest of the delay in the next window.

It is all nonsense of course and is one of the reasons that I never use the system for forensic delay - another reason is that it is very difficult to show concurrency.

My advice is to switch to a time impact analysis and solve all your problems.

Best regards

Mike Testro

Sadeeq Khan
User offline. Last seen 2 weeks 3 days ago. Offline
Joined: 21 May 2009
Posts: 18

Hi CS,

The delay for a particular delay event cannot be more than the duration of the window itself. You might be confused in total cumulative delay that is achieved at the end of a window for a delay event. In this case you should deduct all delays that happens in previous windows. Check the photo below;

3642
windows_analysis.jpg