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.

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

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

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

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

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

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

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

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;

windows_analysis.jpg