First, you need to establish the actual as-built programme based on your records. Base on your simple baseline programme, update as built floor by floor, When Floor started and when it was completed.
Second, You also need to establish what cause the delay, when it started and when the issue was resolved. You can only establish this if you have good records, i.e. correspondence, meeting minutes, etc. Try to identify these issues one by one and call them Events 1, Events 2 and so forth and include them as activities, if possible mark them with a different colour so you can easily identify them. Back-up your events with records (correspondence, minutes of meeting, site instructions, etc.)
I am sure they have done some measures to mitigate the delay, for example if there is a design issue on one floor or part of a floor, I am sure they jump to the next floor to work around the issue and then just come back later. If this was not the case then your construction team did not do a very good job and your EOT claim is weak.
Note that non bearing walls are not critical activities and can always lag behind the structural works, so I think the logic on the baseline programme is not quite sound.
Best regards,
Daniel
Member for
17 years 8 months
Member for17 years8 months
Submitted by Ronn Chester Baluyot on Thu, 2011-02-24 09:48
I don't know if the progress record we have is good enought. Let us say for a particular floor/level (which is quite a big area to be represented in one activity/bar), we have a diagram showing how it was divided into portions and when each portion was casted. For the start date of each portion maybe the site photographs might be useful.
The problem is like this, lets us say Level 1 split into Portions A, B, C and D. We started in A with the falseworks/formworks and then continue as usual, a week later we started B the same sequence as A, then next is C. Then in Portion B we encountered a prolem, like there was no sufficient information to continue. But in A and C we can still proceed the works. And all of these works are represented in the baseline programme as a single activity. What in the world. I'm not the one responsible for the baseline programme and all of its monthly updates.
Member for
16 years 7 months
Member for16 years7 months
Submitted by Gary Whitehead on Thu, 2011-02-24 09:21
Do you have good site records of progress? Because in order to demonstrate the impact of delay, you have to be able to demonstrate the progress achieved at the point the delay event impacted.
If so then yes, I would develop a programme in sufficient detail and with correct logical linkage that fits to the dates in the original accepted baseline. Note any assumptions you make wrt productivity rates / resources etc when doing this, and any data used to inform those assumptions.
Then update with progress to the first delay event, impact the event, note the impact on float / end date, rinse and repeat.
NB: If when creating the detailed baseline programme you discover the dates given in the original approved baseline were wildy out, you may have to justify ignoring the original baseline for EOT purposes which will be a harder sell.
I'm sure Mike T will be along soon to give you his expert opinion.
EOT claim 3 years too late with no bottom-up baseline and SS_lag links? He'll be in his element ;o)
Member for
19 years 10 monthsHi Ron First check that your
Hi Ron
First check that your claim is not time barred by default after 3 years.
In your current situation I would consider a collapsed as built method because you do not have to develop a detailed baseline programme.
As in the previous threads everything depends on the As Built records - they must be really detailed to make it work.
Do you still have the concrete test cube results? They will tell you the day that each pour was made and you can extraplotate other data from there.
Good luck and best regards
Mike Testro
Member for
24 yearsRonn, First, you need to
Ronn,
First, you need to establish the actual as-built programme based on your records. Base on your simple baseline programme, update as built floor by floor, When Floor started and when it was completed.
Second, You also need to establish what cause the delay, when it started and when the issue was resolved. You can only establish this if you have good records, i.e. correspondence, meeting minutes, etc. Try to identify these issues one by one and call them Events 1, Events 2 and so forth and include them as activities, if possible mark them with a different colour so you can easily identify them. Back-up your events with records (correspondence, minutes of meeting, site instructions, etc.)
I am sure they have done some measures to mitigate the delay, for example if there is a design issue on one floor or part of a floor, I am sure they jump to the next floor to work around the issue and then just come back later. If this was not the case then your construction team did not do a very good job and your EOT claim is weak.
Note that non bearing walls are not critical activities and can always lag behind the structural works, so I think the logic on the baseline programme is not quite sound.
Best regards,
Daniel
Member for
17 years 8 monthsHi Gary, I don't know if the
Hi Gary,
I don't know if the progress record we have is good enought. Let us say for a particular floor/level (which is quite a big area to be represented in one activity/bar), we have a diagram showing how it was divided into portions and when each portion was casted. For the start date of each portion maybe the site photographs might be useful.
The problem is like this, lets us say Level 1 split into Portions A, B, C and D. We started in A with the falseworks/formworks and then continue as usual, a week later we started B the same sequence as A, then next is C. Then in Portion B we encountered a prolem, like there was no sufficient information to continue. But in A and C we can still proceed the works. And all of these works are represented in the baseline programme as a single activity. What in the world. I'm not the one responsible for the baseline programme and all of its monthly updates.
Member for
16 years 7 monthsOuch. Do you have good site
Ouch.
Do you have good site records of progress? Because in order to demonstrate the impact of delay, you have to be able to demonstrate the progress achieved at the point the delay event impacted.
If so then yes, I would develop a programme in sufficient detail and with correct logical linkage that fits to the dates in the original accepted baseline. Note any assumptions you make wrt productivity rates / resources etc when doing this, and any data used to inform those assumptions.
Then update with progress to the first delay event, impact the event, note the impact on float / end date, rinse and repeat.
NB: If when creating the detailed baseline programme you discover the dates given in the original approved baseline were wildy out, you may have to justify ignoring the original baseline for EOT purposes which will be a harder sell.
I'm sure Mike T will be along soon to give you his expert opinion.
EOT claim 3 years too late with no bottom-up baseline and SS_lag links? He'll be in his element ;o)