Claim analysis

Member for

19 years 7 months

Since the engineer has reviewed (and at later stage approved) the baseline schedule and it is meant to be that he has modified the durations, lags & relationships of the activiites, then he can’t modify the approved baseline (rev. o).



If a revised schedule was made, then the engineer can review this modified schedule and accordingly modify the durations, lags & relationships of the activities.



HTH

Member for

21 years 10 months

Is it apprpriate for the Engineer to modify any relationship or lag (which is meant as a resource linking) in the approved baseline programme?



What if some durations in baseline was meant as a summary and not detailed enough, can the Engineer re-assess this?



Regards

Shaju Varkey

Member for

20 years 10 months

Charleston



Couple of comments,



The jist of your post is correct and unfortunately politics awill lways play a role in projects.



But -



The level of proof for a claim is "on the balance of probabilities" which means if its 51% /49% for the claim, the claim succeeds. Beyond all reasonable doubt is a much higher threshold applied to criminal cases, not civil proceedings which is where construction claims end up if they go to court or arbitration.



Also, depending on the contract it may not be up to the Contractor to prove an EoT claim at all. It may be purely up to the CA to assess it when notified. This was the case with some of the more older versions of standard forms but some still retain this stance today.



In assessing a claim (whether from the Contractor or by him/herself) the CA should act impartially and the assessment should be:



In accordance with the contract

Methodical

Calculated

Use periods that reasonably reflect the actual delay caused



The 4 general principles of delay analysis - and they come from a case where the CA didn’t assess an EoT properly and it all later ended up in Court. (John Barker v London Portman Hotel 1996)

Member for

20 years 3 months

Dear Shaju,



In reply to your PM,



First I advised you to follow Mr. Andrew Flowerdew ideas and Mr Stuart Ness ideas relating to claims, time impact analysis.



On a personal level my philosophy is that "He who claim must prove beyond reasonable doubts". I worked on the contractor side for most of my 23 years of construction experience and claims was really a pain in the ass for me. But I did was successful because I worked hard to "prove beyond reasonable doubt".



So, in your case since you are on the consultant side, all you have to do is prove that the claim from the contractor did not met the criteria of "prove beyond reasonable doubt". In this case you dont have to "bang your head, burning the midnight candle (oil), etc, etc. Plain and simple.



But, But, But be careful with politics specific in your project. In the event that the politics is very strong in your project, you have two choices: 1.) you maintained your professionalism and expect to be kick out someday or 2.) you play politics with the gods in your project, make them happy, forget professionalism, think like a you are just a labourer given a chance to do planning and claims



The choice is yours. If you are young, you will prefer 1.) but if you have family, better choice 2.



A practical advice my friend in PP.



Cheers,



Charlie

Member for

20 years 10 months

Shaju,



If you’ve got a delay spanning 18 mnths then trying to ascertain it’s impact in one simple operation is pushing the boundaries of analysis past it’s credible limits.



If the records are available a Time Impact Analysis should be carried out on a monthly basis to ascertain it’s effect.



As you say there were considerable Contractor delays within this time period it is probable that the delay to the issue of the Firefighting information will have only been critical (and hence affected the completion date) for part of the 18 months. I’ve known delays of a year or more to cause delay to completion of only 2 or 3 months. TIA is time consuming and takes alot of work but given the timescale involved and associated concurrent delays, it would be worth doing.