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

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 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

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

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

Small clarification on last post

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

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,

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.

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