HT-2020-000448 - [2024] EWHC 1185 (TCC)

In oral Closing Submissions, Mr Lavy urged upon the Court a conclusion that even if I reject, as I do, Mr Britton’s two analyses, I may still arrive at a conclusion in support of TCS’s case by taking Mr Jardine’s analysis, and correcting it, so as to arrive at a conclusion on the extent and cause of critical delay.

Mr Jardine’s as-built plan starts with common ground between the experts: the critical path runs through Drop 1 to 4 barring development, Barring & Basics CIT (Component Integration Testing), SIT and then Final SIT 1 (i.e. through the software/testing workstream). Thereafter, however, in contrast to Mr Britton’s view that infrastructure became critical, Mr Jardine has the critical path continuing to run through the software workstream (i.e. development and functional testing) through to 22 June 2017, after which multiple workstreams are all shown as critical in the run-up to Go-Live.

I accept Mr Jardine’s fundamental premise which is that the correct analysis will focus upon the periods when, if at all, the progress of the software development and testing workstream was actually impacted by the absence of the dependency provided by infrastructure (in line with the logic of the example of the painted wall given by Hamblen J as he then was in Abu Dhabi v SD Marine Services [2011] B.L.R. 384 (Comm Ct) at [262] and of the approach of Ramsey J in Bluewater Energy Services BV v Mercon Steel Structures [2014] EWHC 2132 (TCC); 155 ConLR 85 at [308]–[312]). Although an over-simplification to some degree, ultimately the provision of the infrastructure by HPE was a dependency which (even if it is delayed) does not cause a critical delay to TCS’s work unless and until the progress of TCS’s work is in fact slowed due to its non-availability. The ability to mitigate issues with infrastructure delay by reworking the manner in which the software development testing and fixing takes place will, insofar as it means that TCS work is not in fact delayed, keep infrastructure off the critical path.

The principal criticism of TCS of Mr Jardine’s analysis is that the depiction within the as-built of OAT (Operational Acceptance Test) is unrealistic and wrong. Mr Jardine depicted OAT as a pair of mini bars situated in September 2016 and February 2017. The Baseline plan did not include OAT 1 and OAT 2 but rather envisaged a single OAT running from 03/03/16 to 07/06/16, and OAT was first shown as split up in the 06/06/16 POAP when OAT progress had stalled awaiting infrastructure dependencies and thus needed to be replanned. TCS submitted that the realistic and fair way to represent OAT was as a single bar running from May 2016 at the latest all the way through to September 2017, (where Mr Jardine already showed OAT as being critical). Although Mr Jardine did not go so far as to accept that he had drawn the OAT bars incorrectly, he did accept that OAT could fairly be depicted as a single bar running from May 2016 to September 2017 if, as a matter of fact, OAT 1 had started from May 2016 and OAT 2 had commenced by September 2016.

TCS then contend that if this revised timeline for OAT is superimposed on Mr Jardine’s as-built plan, OAT becomes a clear contender for being critical on the basis of that definition: it is an activity that from (at latest May 2016) has no float and, given its as-built length, cannot be delayed. With OAT critical, it is evident that the true as-built critical path likely went through the software drops, then CIT/SIT (as the experts agree) and then into OAT which – owing to the missing infrastructure dependencies which meant that it could not finish until shortly before Go-Live (where Mr Jardine has it as critical) – remained critical throughout.

This analysis is illustrated in a version of Mr Jardine’s analysis of the critical path adjusted by TCS for its Closing Submissions:

The difficulty with this analysis is that, in reality, OAT overall was ‘stop/start’ but there is insufficient evidence and analysis to conclude that there was no float in the ‘single activity bar’ advanced by TCS in Closing. That is because the single bar in fact contains significant periods where no work was being carried out. A proper and robust as-built analysis should be capable of substantiating the (implicit) assumption in TCS’s case that the commencement of each ‘start’ of part of the overall OAT process was properly and immediately dependent upon a preceding ‘finish’ of relevant infrastructure. No such analysis exists. It is not therefore possible to conclude that the single OAT activity bar TCS posits in its written Closing Submissions is indeed properly to be regarded as a single, critical activity during which the periods of inactivity are constraints dictated solely by the absence of infrastructure. It would not be a reliable basis upon which to draw safe conclusions to adjust Mr Jardine’s analysis in the manner suggested.

That said, the careful and detailed cross-examination of Mr Jardine did expose other potential difficulties with parts of his analysis. It is likely, for example, that Mr Jardine was wrong when he identified the first set of drop releases (Drops 4.1 and 6.1) as being critical when they were not, and that as such there may have been float on the functional testing workstream so as to call into question its criticality within Mr Jardine’s analysis. However, it does not follow from this that it is possible simply to remove from the software development and testing stream the two months marked ‘FLOAT’ in the visualisation above. This was not a point put in these terms to Mr Jardine, and it was not a point put to any factual witness. Whilst, therefore, the identification of the non-criticality of Drops 4.1 and 6.1 may be relevant to whether Mr Jardine is correct as to the location of his critical path, it does not give rise to a reliable basis upon which the Court could effectively carry out its own as-planned v as-built exercise, or to answer the critical question of when, but for the infrastructure delays of which complaint is made, would TCS have Achieved the Milestone.

With this in mind, it is clear that neither expert’s analysis identified the true critical path, and it seems likely that the software development and testing workstream and the infrastructure workstream ran in parallel through large portions of the project sufficiently closely that both workstreams were likely contenders for true ‘criticality’ during each of the Windows from Window 3 onwards. In addition, it is clear that at the very end of the project there was a day-for-day delay of approximately 3 weeks arising out of DBS’s request (which TCS acceded to) to delay Go-Live for particular reasons of concern to DBS. This three week period does not feature in any pleaded claim or proper legal analysis: it is not obvious that TCS acquiescence in this request is an ‘AUTHORITY Cause’ pursuant to Clause 7 of the Agreement: it does not arise out a breach of DBS’s responsibilities, and it seems improbable that the parties (in reaching the accommodation they evidently reached) would have anticipated that the ‘delay’ would entitle either party to make a claim against the other for Delay Damages (on the part of DBS) or loss and/or expense (on the part of TCS).

I have rejected, as a matter of fact, TCS’s contention that the BPO UAT activity could have been materially shortened, and have also rejected the contention that the OAT activity can reliably be seen as an unbroken single-bar of activity, these being the two main adjustments Mr Lavy submitted the Court might make to Mr Jardine’ analysis. Nevertheless, in a case in which the contractor’s entitlement did not depend upon it establishing the date by which it would have Achieved a Milestone, the Court might have been tempted on the evidence available to carry out the type of adjustments suggested by Mr Lavy in order to arrive at a middle ground answer to the extent and cause of critical delay. However, in the present case, for the reasons set out above, TCS has simply not discharged the burden upon them to demonstrate the date by which it would have Achieved the Milestone irrespective of whether the critical path was running through the software development and testing stream or the infrastructure stream or (as is likely) moved between the two at various stages through the project. In these circumstances, it is not possible to conclude that, even if the matters complained about constituted AUTHORITY Cause, TCS is entitled to relief and/or payment pursuant to Clause 7 of the Agreement in relation to R1-B&B.