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

Mr Britton (in his First Report) adopted a ‘prospective’ analysis. This method chiefly relied upon the Microsoft Project plans produced by TCS during 2016 and 2017 – beginning in 20 January 2016, up to 13 July 2017 – to identify and track changes over time to the forecast Go-Live date for R1-B&B.

The starting point for his analysis was the existence, therefore, of a move to the Go-Live date in a particular contemporaneous plan. That move would generally be backward (i.e. later), but sometimes forward. Mr Britton then sought to examine the detail of the plans to determine what he considered had changed since the earlier plan to cause movement to the projected Go-Live date. An extract from his analysis, as summarized and commented upon in the Joint Report with Dr Hunt is set out below to illustrate the basis of the analysis:

Mr Britton regarded these resets to the projected Go-Live date from time to time as being a ‘proxy’ for actual critical delay (including ‘negative’ critical delay, if the date came forward) to the R1 Project.

The effect of the analysis is that Mr Britton did not consider whether a forecast event which pushed the forecast delay back in one plan in fact became an event which caused actual critical delay to completion in due course. Mr Britton accepted this in terms (Day 16/74):

Whilst Mr Britton also accepted that he did not, having identified what prospective delay was perceived to be likely to occur in the future, carry out any cross-check against what actually happened, he thought this was a theoretical problem in this case (Day 16/123):

Mr Britton explained this further in re-examination, where he said that (Day 19/128):

The difficulty of this approach as a matter of objective delay analysis is that its efficacy as an approach itself depends on the very conclusion Mr Britton arrives at, namely that infrastructure delays are constantly on the critical path. Mr Britton does not therefore regard it as particularly important (in the context of his report which allocates all infrastructure delay to HPE (and/or DBS)) to distinguish with precision what the period or cause of critical delay actually was.

Mr Britton accepted, in the passage above, that earlier delays identified as the cause of (forecast) critical delay may not ultimately have transpired to be either on the critical path or, indeed, to have caused delay at all. A good example of this was where a particular part of the planned solution was de-scoped from the project altogether so that the forecast delay attributable to the development of that part of the solution never became a reality. Moreover, he accepted that his analysis does not allow actual delay to be apportioned between particular infrastructure related activities on his critical path (Day 16/117):

It is true that in a universe where (a) all delays are infrastructure delays, and (b) all infrastructure delays are Authority Cause, this would not necessarily be a problem. It was, it seems, for this reason that Mr Britton did not perceive his approach as problematical (Day 16/129):

Where, however, the universe is one in which the very purpose of the exercise, without starting with the answer, is to determine what activities were the real cause of actual delay, rather than potential causes of forecast delay, and what the actual delay period attributable to a particular activity was as things transpired, this is in my judgment a significant problem with Mr Britton’s analysis.

A large part of the rationale advanced by Mr Britton for this approach depended upon his assumption that once a forecast delay was embedded into the programme, it effectively became a cause of delay because other work was undertaken in the context of the new timeline. Thus, in his Third Report, Mr Britton expressed the view that:

Whilst the logic of Mr Britton’s evidence is comprehensible in general terms (although it must be said that the distinction with the construction industry he observes is not necessarily correct given that, depending on the labour market, very similar resourcing issues may also, in construction projects, give rise to a reluctance to let workers go), it is ultimately a question of fact as to whether this happened. In essence, the conduct described is a type of ‘pacing’, in which the duration of the non-critical activity is prolonged deliberately in the face of delays caused to a critical activity. It is likely to be the product of a conscious management decision to achieve a particular advantage.

Dr Hunt’s evidence on the topic, in her second report, was as follows:

In response to this, Mr Britton identified (at paragraph 40h of the Joint Statement dated 25 August) generic behaviour (such as the agreement to RFCs (Requests for Change) or the spreading of UAT2 (User Acceptance Testing) over three cycles, without requesting extensions, and the absence of pressure on the BPO (Business Process Outsourcing) UAT team to speed up despite overrunning by months). However, it remains the case that none of the TCS witnesses gave any direct evidence to support the existence of a decision to slow activities down to pace against infrastructure delays. There were no documents in which such a strategy was either discussed at management level, or through which instructions to ‘pace’ were given to the teams. In cross-examination, Mr Britton also accepted that these were not really examples of ‘pacing’, more ‘keeping the team busy’.

It might be said that the examples provided by Dr Hunt were all dated from a period where little critical delay since the November 2015 reset had occurred (assuming the extent of accrual of delay within Mr Britton’s first analysis, Mr Jardine’s analysis, and the contemporaneous programmes is correct), and therefore they do not relate to the period in which infrastructure delay was undoubtedly occurring (irrespective of the question of criticality). However, her observation about the absence of evidence suggesting any conscious decision to pace activities is, in my judgment, a fair and justified one.

Both parties made submissions as to BPO UAT in the particular context of pacing, or ‘unintentional pacing’ as it was described at one point by Mr Britton.

Mr Jardine explained the importance of BPO UAT to his analysis in cross-examination (Day 24/61):

Mr Britton explained how the same issue affected his decision making in relation to his second analysis (Day17/172):

By ‘unintentional pacing’, Mr Britton explained that he meant that the activity did not appear to have been resourced adequately to perform it within the planned timeframe. It was not necessarily an act of deliberately going slowly, rather it was just not picking up speed when it fell behind, because of the existence of critical delays on the infrastructure path(s). Mr Britton characterised BPO UAT as an activity which was allowed to drift because it was not critical, and TCS submit that there was no reason in principle why the initially planned timescales for BPO UAT (being 18-20 working days) could not have been achieved had that been necessary. TCS points out that BPO UAT was never marked as critical on contemporaneous ‘POAP’s (Plans on a Page – effectively summary programmes), consistent with (amongst other things) the evidence of Mr Padannayi’s explanation in cross examination as to why there was no sense of urgency even though the TCS build team (as opposed perhaps to the BPO team) wanted to close BPO UAT (Day4/160):

I accept that Mr Padannayi’s recollection to the effect that BPO UAT was not perceived as being on the critical path at the time is most probably accurate. However, the chronology produced by DBS at paragraph 185 of its Closing Submissions which is the basis for the following factual findings is also a fair and correct one. It is one which demonstrates in my judgment that TCS’s submission that BPO UAT could have been carried out in the as-planned duration of 18-20 days if necessary is completely without foundation:

This chronology suggests, as I find, that the extended duration of BPO UAT was caused in very large part by TCS’s own problems which were being encountered and an absence of resource which would not have been immediately remediable had TCS considered it necessary. It may be that some element of the overall duration was caused by a lack of prioritisation given the other, critical delays at the time. Ultimately, however, I do not consider that the duration of this activity was principally caused by ‘unintentional pacing’. It was caused mainly by the technical issues TCS was grappling with, the (possibly changing) requirements of the BPO commercial team and the unreliability of their availability for testing given the other demands on their time. This is so even though I accept it was probably sub-critical, although only marginally so in the latter months of the R1 B&B project.

It is convenient at this point to consider that one of the principal explanations that Dr Hunt gave for the length of time taken by TCS for development and testing was the need for defect-fixing. In its written Closing, TCS identifies, by reference to aspects of cross-examination, a number of reasons why Dr Hunt has overstated the extent or difficulty of defect fixing.

The starting point is that, on the basis of the contractual analysis, it is necessary for TCS to prove the date by which they would have Achieved the Milestone as a key element of obtaining relief: it is not for DBS to explain the reasons why TCS took the time they did by reference to identifiable problems that TCS faced of its own making.

In relation to Mr Jardine’s Window 3 (from 15 June (when DBS suspended UAT 1) to 10 November 2016 (when DBS recommenced UAT by starting UAT 2)), for example, Mr Jardine’s view was that the critical path remained through the development and testing of the additional software Drops and thereafter into Final SIT 2 and UAT 2, since these were the “core” stages of R1-B&B that the successive POAPs show were being progressed (and were increasingly in delay). Dr Hunt (upon whose analysis Mr Jardine relied) considered that the principal reason for these additional code Drops, and consequential critical delay to the start and progress of Final SIT 2, was the need for TCS to fix and re-test software defects found in earlier SIT and UAT1 prior to its suspension.

Dr Hunt relied on ‘ALM’ (Application Lifecycle Management) data from TCS showing the number and severity of the defects recorded for SIT during 2016. The view expressed in Dr Hunt’s report was that the main driver of continuing SIT during this period was the need for TCS to deliver and test additional drops which were primarily driven by the need for defect fixes. In cross-examination, Dr Hunt fairly conceded that this was an overstatement of the position (Day 21/109):

Whilst Dr Hunt fairly conceded the point was more nuanced than her initial report had indicated, the tenor of her evidence in cross-examination, which I accept, is that there remained, nevertheless, a considerable amount of defect-fixing work ongoing. A large part of the cross-examination focussed on the potential contribution to the workload caused by the impact of RFC related work. Even if, as Dr Hunt conceded, a greater element of the extended duration of testing related to RFC work than fixing defects in the originally planned workscope, there are two fundamental difficulties facing TCS. The first is that, having agreed to carry out RFC work with no adjustment to the Milestone Date pursuant to the Change Control procedure, to the extent that the work did in fact cause delay, it is TCS’s risk, which passed at the point of agreeing the RFC. The second, more important, issue is that even if this were not the case, there is no evidential basis, either in the factual witness evidence or the expert evidence, upon which the Court could possibly come to a reliable conclusion about the appropriate amount of time which reflected RFC defect-fixing work as opposed to original-scope defect-fixing work. Indeed, the absence of such an analysis formed part of one of Mr Lavy’s questions (Day 21/123):

Where it is for TCS to demonstrate the date by which it would otherwise have Achieved the Milestone as part of its case for relief and/or payment, the absence of this analysis is, fundamentally, an obstacle for TCS. This is particularly so in circumstances where the evidence suggests that – even if there are a number of non-TCS related issues causing problems for exiting a particular test phase – there were also TCS-related issues preventing exit caused by TCS or sub-contractors for whom TCS was responsible. In these circumstances, it is not possible for TCS to establish that – even ignoring the non-TCS issues – they would have exited the particular test phase sooner. Take, for example, the exit to Final SIT 2, where the evidence is clear that the Welsh Template Testing issue (a TCS issue) remained a difficulty to TCS alongside other issues through to the end of 2016. There is no evidence (witness or documentary) which suggests that delays in this regard were attributable to any party other than TCS or its sub-contractor, or that the issues would have been resolved sooner than they were in fact but for other problems.

I conclude on the evidence that it is not likely that TCS could in fact have exited testing phases earlier than they did. Mr Britton accepted that if the criteria to exit a test phase were met, it would be sensible for the contractor to exit and then carry on fixing defects, rather than elongating the test phase to fix more defects even though the exit criteria were already met (Day16/148):

This is particularly so, in my judgment, in the context of an Agreement where the right to relief was dependent upon establishing when TCS would otherwise have Achieved the Milestone. It is not obvious why going slower than planned and/or than the pace at which TCS would otherwise have been able to proceed along the software-development workstream and/or not exiting test phases as soon as possible would be, in any way, a sensible strategy. It certainly cannot be assumed that this is what TCS would have done, given that it seems entirely counterproductive to its interests knowing that it would be necessary to seek relief when the Milestone was not Achieved. Mr Britton fairly accepted in evidence that any conscious decision to work in this way would be reported up the line or down the line (Day 16/157); and that if it chose to do so, it would be at risk:

Another risk, of course, is that it may make it difficult for TCS to establish when it would (on its sub-critical path, assuming this is where its activities lay) have Achieved the Milestone but for AUTHORITY Cause. This difficulty is highlighted by consideration of BPO UAT above. I have accepted that it was probably not on the critical path (although it probably would only have been marginally sub-critical), but I have also rejected TCS’s ‘all or nothing’ case that BPO UAT would have been carried out in the planned duration if TCS had wanted as completely unrealistic. This presents an insuperable difficulty for TCS’s pleaded case that, but for the infrastructure delays, it would have Achieved the Milestone as planned (subject to 18 days delay).

Returning to Mr Britton’s analysis, I consider that insofar as his conclusions regarding criticality are driven, as they seem to be, by his assumption that the software development and testing workstream was being intentionally or unintentionally paced to any material degree, these conclusions are unreliable. Moreover, even in circumstances where the Agreement was silent as to the type of delay analysis required, it is improbable that the sort of prospective analysis undertaken by Mr Britton would be of much assistance to any tribunal wishing to understand what the actual periods and causes of critical delay on a project were, after the event. As set out above, Clause 7 requires a backward-looking analysis which identifies the actual reasons TCS failed to Achieve the Milestone in question. It is clear that Mr Britton’s first, prospective, analysis does not adopt a recognisable and logical method by which this could be established with any reliability. The mere fact that, as is undoubtedly true, infrastructure delays were within contemporaneous documents perceived at various times by various parties including DBS to be causes of critical delay does not detract from this conclusion as to the appropriateness of Mr Britton’s approach to delay analysis.

A further difficulty with Mr Britton’s analysis in the specific context of this case is that he only considered matters which were shown to be on the critical path on any given plan, and did not analyse delays to activities on the sub-critical path. Mr Britton accepted this (Day 16/75 line 15). In circumstances where TCS is also required pursuant to Clause 7 to demonstrate the date by which it would have Achieved the relevant Milestone but for AUTHORITY Cause, this is a fundamental problem. That Mr Britton presented no analysis which sought to establish this (in circumstances where by definition software development was, on his evidence, always on a sub-critical path) was demonstrated by the fact that the answer to this key question was advanced in Closing by TCS by reference to, in effect, an analysis presented by Mr Lavy through a ‘correction’ of Mr Jardine’s evidence rather than by reference to any evidence from Mr Britton.