Corrected baseline programme for delay analysis

Hey Mike



well didn’t mean any harm. I didn’t even pay attention to the date.

:)

Regards

Hi Roland



A little word of advice to a new PP member.



To resurrect a 4 year old thread may be considered bad manners by the originator and contributors.



Please respond where a live debate is in progress - go and have a look at Lets Challenge Spider and see if you can add anything to that forum - and retain your sanity.



Best regards



Mike Testro

I find the "But For" principle to be highly subjective, and a method that should be approached with caution.

It has been used a lot of times from both parties to a claim to state that "but for" my delay on X activity the other party would have delayed the project anyway because he didn’t mobilize his subcontractor for activity Y on time.By stating that the first party is really violating the concepts of CPM by forgetting that in a lot of cases it could be that the delay on activity X gave activity Y more float and therefore the late mobilization of the subcontractor on that activity didn’t cause any critical delays to the project and could amount to the contractor just pacing the delay on activity X.

Of course everything said above wouldn’t be a problem if both experts really know what they’re doing and if you end up in court , for the judge to really be in tune with the subject because in this part of the world most judges don’t.

Regards

Adrian



Your graciousness is now making me feel guilty for bringing your slip to your attention.



I think His Honour Judge Humphrey LLoyd QC made a similar slip in Balfour Beatty Construction Ltd v London Borough of Lambeth [2002] so we are in good company – but again that all depends on the definition, Judge LLoyd’s definitions may have been different to ours!



We can get very pedantic if we are not careful and talk about a time impact analysis or Time Impact Analysis for instance. Literally, I think lowercase signifies any method that analyses time and impact where as uppercase is a specific method. Similarly, a timeslice/windows analysis and Timeslice/Windows Analysis.



Again, these are only my interpretations of the methods but I think your description is of a windows/timeslice analysis. My view is that the techniques are broadly similar but TIA leads to a more refined analysis as it deals with individual events whereas Timeslice Analysis potentially deals with whatever number of events happen within the selected time period. I tend to think there is a specific way of analysing the delays using Timeslice Analysis but until we get a revision of the Protocol maybe we are all still a little in the dark.



Regards



David

Dear David,



Fair call, you’re quite right. Too many commentators use "Time Slice" and "Time Impact" interchangeably and I fell victim to it too - I was reviewing a judgement that did exactly that when I drafted my suggestions for Neil.



Agreed that "Time Slice" is another term for "Windows." I know it as marking two dates on a programme that bound an event and any suitable method of analysis may be applied within that theatre. Same for you?





Much obliged and many thanks,



Adrian Archer.

Pickavance Consulting Limited

Dear all



Apologies for this non-constructive posting but I’d like to get back on my ‘hobby horse’ of nomenclature and definitions of methods.



With respect, I am surprised at Adrian’s misappropriation in an otherwise excellent response. In my extremely humble opinion (!) what Adrian refers to as ‘Time Slice’ is in fact ‘Time Impact’ analysis and is that method which is ‘recommended’ by the SCL and to some extent by his organisation’s chairman, Keith Pickavance, in his book ‘Delay and Disruption in Construction Contracts’.



‘Time Slice’ analysis (or ‘Windows’ analysis) is something different and is not mentioned in the SCL Protocol. An unexpected omission considering, in my experience, it is a frequently used method of analysis, at least in the UK.



Regards



David

Guys,



In most cases I would have a strong preference to leave the baseline programme (Contract programme) unaltered, especially if it was ’agreed’ or ’approved’ or ’accepted’ or ’acknowledeged’ by the Principal. There should be a very strong case for tempering with such programme.



Extending the duration of the project due to, say, omission in the Programme is particularly problematic, as the Principal, had the problem being known at the time prior to signing the Contract, could have signed with a different Contractor.

I am acuallv playing a game clled cossacks 2 which is bmind bloring

I could even quote Khalil gibran

Therb id some space for Napoleon here, as well as Einstein qnd rsun tsu

hi

Andrew, the fun has begunmlet them prove there is no room for pragmatibm on the site

regards

Small clarification on last post



If the assumptions were reasonable and apparently possible, given what was known at the time........

Hi all,



Without knowing the detail it is hard to judge or advise but if the original logic assuptions made were reasonable and possible AT THE TIME THEY WERE MADE then the contractor probably has a strong case. If so, follow Philips advice, sit everyone round a table and do a deal.



It’s often difficult with hindsight, now knowing all the facts, to take yourself back in time to when the contract began and think of what was or what was not known at the time, but that is your starting point.

hi,



From the OP and clarification it seems that the critical issue is the unforeseen delay/sequencing error and how does one assess that with the benefit of hindsight?



All parties viewed the programme and didn’t spot the problem, therefore it is reasonable to believe that the contractual view mentioned below is well supported.



Assumimg the worst, i.e. going to court, one could begin the assessment from the "oversight point", however as you pointed out it would most likely benefit the contractor, and in my view rightly so.



Assuming a baseline before the oversight would not be advised in my view, from the contractor’s view one could easily re-state that the sequence problem (including CP activities) were only uncovered at a ’late’ stage, and unforeseen by all parties. I guess that nobody stood up at that point and discussed with the contractor for the cost implication to accelerate the works to meet the deadline.



.......just my 2 cents



cheers,

Hi Andrew, good to see you are still around.



Hi Neil,



Something I missed, in your fitst post the first sentence, there was a thread, "As built critical path", I thought you were aware of. Obviously not, as ypu have not referred to it. There is some interesting reading, probably the longest thread to have run on the PP site, maybe somebody can comment?



The point is let’s be practical/pragmatic, and go a different route, which the "legal eagle planners" seem to avoid, as their income derives from there, and talk to each other ie client/contractor/middleiman, and resolve the issues in a civilised manner. Admit our shortcoming whichever side of the fence we sit. If you make a mistake admit to it, and fix it.



I have over thirty years experience, and I still have not learnt everything. You probably need thirty people with thirty years, and you might get to have a basic understanding of everything. For every activity we do there might be 10+ methods, so who are we to criticise somebody else’s logic, unless we have twenty experienced people, and then the joke is somebody can think up a better method.



Regards



Philip

Niel,



Both Philip and Adrians suggestions have many valid points. Although you obviously wish to minimise your work content but we do not know the value of the claim and hence how much effort the contractor may think it’s worth spending on the claim in order to persue it. It may be substantial and hence he may wish to spend considerable time (and money) on it if he believes it will help his case.



One of the questions that needs to be asked is why the contractor (and possibly others) thought the original logic was correct and why subsequently it was found to be wrong. The legal phrase "what was or ought to have been in the contemplation of both parties at the time of making the contract" is fundamental to contract law and probably has a direct bearing to all or part of what you are considering.



I know this doesn’t help you pick an analysis method but don’t shoot yourself in the foot by choosing a method based on what will save yourself work. It might cost you (or more likely your client) alot in the long run.

Jonker



If the said changes corporate in the baseline schedule with mutual understanding as Tait explained then where jeopardise go?

Hi Neil,



I have been on both sides of the fence in claims, and even as a contractor, I would say that making changes to an approved programme would jeopardise your own case.



Regards



Philip

Dear Neil,



From what you describe, I see a number of possible ways for you to proceed. Forgive me if I’m too long-winded in describing the different techniques but I don’t know at exactly what level to pitch my suggestions.



It isn’t uncommon for either party to a dispute to introduce a "corrected" baseline by one party to a dispute. The outcomes you describe sound terribly familiar - the "corrected" baseline never existed during the currency of the works and was hence never followed; the "corrected" critical paths could be prejudicial to one side or the other; arguments over reprogramming to overcome the impractical as well as the impossible.



You’ll note that I keep putting "corrected" in inverted commas. That’s because one must be mindful that no programme can ever forecast the works with complete accuracy and, as such, it can never be "correct." Best treat any claim of possessing a "correct" or "corrected baseline" with outright cynicism.



I wouldn’t worry about the programme being "approved." From what you’ve described, the contract encourages updates and revisions and even now your Contractor wants to "correct" it. There are almost no contract forms that treat the programme as an immutable, contract document. If both parties now agree to change the programme, so be it.



I understand you’re adopting the "as-planned impacted" technique. This technique however assumes that that original baseline is relevant and a fair representation of the works for their entire duration. This is fine for simple programmes of a dozen activities or so but your 2,000-activity programme has grown well beyond the limits of this technique.



You fear the risk that concurrent activities will be resequenced under a "corrected" baseline. This is inevitable on a large programme - any corrections will shift whole trains of activities past eachother. I’m reminded of a mediation in which the other side’s expert, insisting on the "as-planned impacted" model, had to try to explain to the mediator why a single adverse weather event was impacted on a dozen different activity paths and on a dozen different days, not one of which matched the actual date of the event!



It is possible to study the works with an "as-planned impacted" model but you would need to treat every single deviation from the original baseline as an event for impacting. That is the only way to ensure that a single baseline programme can represent the works for the entire duration of the works but I wouldn’t wish that on anyone. I’m thinking your programme simply sounds too big to handle an "as-planned impacted" analysis.



You can however avoid the problems of forcing one baseline programme, original or "corrected," to represent the works for all of the works - and that’s to try a different technique.



The most interesting - and frustrating - thing about retrospective delay analysis is the explosion in the number of techniques that become available upon completion of the works. Now that your project is near completion, you have the original baseline programme and the as-built programme, which I think gives you all the reasons you need why the original baseline can’t be made to apply to all the works for all their duration, "corrected" or otherwise.



There are two techniques that can help avoid arguments over the baseline - "as-built but for" and "time slice." Both however open up different grounds for disagreement between the parties in dispute - it seems it’s up to you to decide which arguments are worth having!



"As-built but for"



This technique has solid support from the courts. A "live" as-built programme is constructed that, with verifiable logic, holds all the activities on the dates that they occurred. Activities that represent the events are excised from the programme to see where the completion dates would fall were it not for the event in question - i.e., the works would have finished x days earlier but for such-and-such event.



Your as-built records need to be more than the activities’ as-built start and finish dates. You’ll also need records that can convey how the activities were linked. For example, did "FRP Mezzanine" drive "FRP 1/F" with a start-to-start link plus a lag or a finish-to-finish link plus a lag? If there is an event between these activities then the choice of links may influence the event’s impact on the works.



You said you have an as-built critical path so you might already be halfway there. Be careful though - some software produces as-built critical paths only because they can’t handle as-built dates properly and keep them "live." Finished activities can then affect future activities from "beyond the grave."



It also helps if your contract terms are sympathetic to assessment of actual delays to completion. Most standard forms say something like, "is likely to cause or has caused delay to completion," which is consistent with the "as-built but for" technique, so you’re probably OK there.



You haven’t mentioned any disputes over acceleration but the "as-built but for" technique can calculate this as well. The effects of claimed acceleration can be tested by adding in activities that extend the programme: i.e., "we would have finished much later but for all this wonderful acceleration."



Disputes over this technique usually arise from the choice of logic to drive the as-built programme. It’s a popular technique for many reasons but principally it’s grounded in fact. Events can be impacted on the actual days they occurred and the programme is verifiable from the site records. You generally don’t need the original, dysfunctional baseline and therefore you certainly don’t need to try to "correct" it.



"Time slice"



This technique is the darling of the SCL protocol and de rigueur for the US courts. It’s the most time consuming technique but gives the most faithful rendition of the works as they progressed, without the benefit of the parties’ sometimes prejudiced hindsight.



And the Contractor gets to "correct" the baseline - sort of.



In short, each event is impacted onto a programme that represents the status of the works when that event became apparent. Each update should include all the as-built data prior to the event and any documented programme revisions known to the parties prior to the event.



You said that the original baseline was shown up to be unworkable and this is why the Contractor wants to correct it. If you adopt the "time slice" method then the original baseline can be revised - or "corrected" - progressively, as each programming problem became apparent.



I understand your contract supports updating and revising the programme. Also, your Contractor wants to rework the baseline and they can - just as long as they correct it progressively as each programming problem became apparent and not in one almighty hit, like their "corrected" baseline seeks to do.



Disputes over this technique usually arise from when to impact events and when to revise the ever-developing baseline programme. For example, if the Contractor claims a delay in receiving a subcontractor nomination from the Employer, should the event be impacted on the original programmed date; impacted successively until the nomination is received; or on the actual nomination date? Some jurors also get shirty about calculating EOTs on a likely delay to progress instead of an actual delay to completion, sometimes asking whether a Contractor actually needed the EOT in hindsight.



I’m thinking you might need to open both sides up to the possibility of adopting a different technique and then perhaps weighing up which arguments are worth having with your Contractor: debate over a "corrected" baseline that never actually existed during the works; debate over the "as-built" logic that actually drove completion; or debating whether you can bar hindsight from the analysis entirely and "correct" the programme progressively instead.



Sorry for being so prolix but good luck!





Kind regards,



Adrian Archer.

Pickavance Consulting Limited

Hi Neil,



I do not believe in the so-called as built critical path, nor in claiming with a programme that is fixed in the as built stage. The errors should have been corrected pro-actively, ie before the activities took place, as a revision. As I understand it the programme was approved, and as such should form the basis for a claim, without any alterations, despite the fact it was suspect to begin with. I think the point here is that it should never have been ’Approved’



Regards