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

Mr Britton’s second analysis, which was not his ‘preferred’ analysis, identified as critical a series of different events and different durations to his first analysis. It was Mr Britton’s attempt to carry out what he called a retrospective as-planned v as-built analysis (akin, in principle, to that carried out by Mr Jardine). There is some force in DBS’s submission that this supports the inadequacy of his first analysis as an attempt to identify the actual causes of delay.

Mr Britton carried out a workstream by workstream analysis in respect of each workstream affected by allegations of delay, including software development. In order to carry out a calculation of delay, however, Mr Britton adjusted the plan where he considered it to be incomplete and corrected dependencies which he said had been omitted. His conclusion on the occurrence of delay was set out in the following table at paragraph 103 of his Third Report:

As can be seen, the majority of delay was caused, he concluded, in windows 2 and 3, and was attributable to the Systems Monitoring workstream. The progressive occurrence of actual accrued critical delay as the project progressed on this analysis was illustrated in the following table, plotting Mr Britton’s two different analyses against Mr Jardine’s analysis:

It can be seen, for example, that as at June 2016 (the end of Window 2) there is a very significant discrepancy between on one hand the accrued critical delay calculated by Mr Britton’s first analysis (essentially reflecting the then projected Go-Live date) and Mr Jardine’s analysis (essentially reflecting the delta between as-planned and as built dates, without the same adjustments to the plans) – both negligible accrued delay – and on the other hand Mr Britton’s second analysis, showing significant accrued critical delay.

This discrepancy is a feature of Mr Britton’s approach to the analysis of system monitoring. Mr Britton’s view was that systems monitoring was a feature that was needed for Go-Live, so that in determining the critical path it should be included from the outset, albeit he considered that it was not necessarily TCS’s responsibility to plan for or provide the feature until the RFC had been agreed (this was RFC 458). ‘Commercial cover’ for this RFC was not provided until 13 June 2016, and Mr Britton noted that it was not until the programme dated 27 July 2016 that a more detailed plan for the delivery of RRF 458 was included. Notwithstanding this Mr Britton effectively backdated the eventual delay in relation to systems monitoring into the original baseline plan of 25 November 2015, which made it the critical activity at a point prior to TCS being instructed to carry out the work. This put systems monitoring on the critical path for R1 B&B from very early in the project, even though TCS did not show this in its plan in detail until mid-2016.

There are a number of problems with this approach. First of all, it has the effect of attributing delay to something which was not, by its absence, in fact causing any actual delay to the progress of the work at the time. Its absence was not stopping any other work from proceeding. Even if the parties knew its introduction in due course was capable of causing delay in the future, there is no suggestion in this case that it was actually causing delay. There may be cases where knowledge of a future delay might cause actual present critical delay if that knowledge actually affected the manner in which the present activities were being carried out. But there is no evidence adduced to suggest that that was the factual scenario here, and in the absence of such features, it is not right to show critical delay accruing early in the project attributable to activities which were introduced later in the project.

Second, Mr Britton only applied this logic to infrastructure delays (such as systems monitoring). As he accepted in cross-examination, he did not ‘backdate’ the actual delays which occurred within the software development workstream (Day 17/146). Mr Britton also accepted that had he fed the time which was actually taken for software development into the baseline plan, it would have meant that software development was on the critical path (Day 17/180):

I do not accept, therefore, that Mr Britton’s second analysis was either what might be described as an orthodox as-planned v as-built analysis, or that it produced reliable results which could be cross-checked against common sense. No factual witness and no contemporaneous document identified the existence of a very significant accrued critical delay on the project by the middle of 2016, and that his analysis produced such an apparent delay reflects its unreliability.

It is also of note that Mr Britton’s second analysis, even if it were reliable, leads to the conclusion that delays to the software delivery workstream were such that, absent infrastructure delays, Go-Live would only have occurred just one day earlier (Day 17/144):

It is right, as submitted by Mr Lavy in oral Closing Submissions, that simply taking the overall as-built software development and testing stream is not necessarily a true counter-factual for what would have happened but for delays on the infrastructure workstream. As he submitted, unless the analysis is designed specifically to allow one to do that, it is going to be based upon the wrong assumptions. It is also absolutely right that, on the evidence before me, there were almost certainly some delays to the software development and testing workstream that were themselves caused by infrastructure related issues.

However, it is equally clear to me on the evidence (for example, in the context of BPO UAT and defect-fixing discussed above) that TCS have not come close to demonstrating that in large part, the time taken in relation to software development and testing was not simply the time it took, on account of matters for which TCS were themselves responsible – whether because of the number of defects and/or the availability of resources, or simply that they worked more slowly than planned. I am also not satisfied, for the reasons set out above, that the overall duration of the software development workstream was driven wholly or even largely by either conscious or unconscious pacing and could have been carried out materially quicker had it not been for infrastructure delays on the critical path (if that is, indeed, where those delays were).