Tata Consultancy Services Limited v Disclosure and Barring Service

IntroductiON

The Disclosure and Barring Service (‘DBS’) is a non-departmental public body. It was formed in 2012 through the merger of the Criminal Records Bureau and Independent Safeguarding Authority. Its stated aim is to help employers make safer recruitment decisions each year by processing and issuing DBS checks for England, Wales, the Channel Islands and the Isle of Man. It also maintains the Adults’ and Children’s Barred Lists, making decisions as to whether an individual should be included on one or both of these lists and barred from engaging in regulated activity. Tata Consultancy Services Limited (‘TCS’) is a company supplying business process outsourcing and IT services. By an Agreement (‘the Agreement’) dated 4 December 2012, TCS was retained by DBS to take over the manually intensive business-as-usual (‘BAU’) Disclosure and Barring processes (referred to as ‘R0’ in the Agreement) from the incumbent supplier, Capita, whilst building a new system to modernise DBS’ processes and replace its previous paper-based processes with digital ones in parallel (the new ‘R1’ software). The Agreement expired through effluxion of time in 2020.

The modernisation project did not go well. There were immediate challenges with transition, leading to delay and revision of Milestones. The responsibility for delays up to November 2015 is not in dispute. By early 2016, the parties had agreed new Go-Live dates for the different parts of the R1 software: R1 Barring on 15 September 2016, R1 Disclosure (‘R1-D’) on 28 November 2016; and R1 Basics on 1 January 2017. Ultimately, R1 Barring and Basics (referred to compendiously below as ‘R1-B&B’) went live together on 7 September 2017. DBS contend that, upon going live, it suffered from serious defects.

R1-D was removed from the scope of the Agreement by what DBS contends was a lawful Partial Termination on 19 September 2018, an act TCS contends was in fact an unlawful repudiatory breach, albeit one which was not accepted. Responsibility for the delays lies at the heart of TCS’s claim and a large part of DBS’s counterclaim: TCS contends that its attempts to progress and Go-Live with the modernised systems were frustrated by DBS through mismanagement of its IT hosting provider, Hewlett Packard Enterprises (‘HPE’; later known as DXC), and later by the (strategic) decision to abandon part of the modernisation project, a decision it says was made but hidden from it for many months. By contrast, DBS contends that the availability of technical infrastructure and conduct of HPE did not cause any critical delay. Instead, it says the true cause of delay was that TCS’ software was not ready to be deployed on the infrastructure. The delivery dates were missed, DBS contends, due to problems with TCS’ own development and testing of the software.

TCS’s loss said to be caused by DBS’s breaches of the Agreement is pleaded in the sum of £110,229.124, together with a claim for £14,373,099 claimed as an underpayment of Volume Based Service Charges. DBS counterclaims for losses arising from the delays and defects in the pleaded sum of £108,705,984, although certain of these claims were abandoned prior to or at trial.

TCS called 12 witnesses of fact, 9 of whom gave live evidence. DBS called 22 witnesses of fact, 16 of whom gave live evidence. I do not set out an individual assessment of each factual witness. As would be entirely understandable in relation to events some five to seven years ago, most witnesses’ recollections were relatively vague and generalised when unprompted by contemporaneous written material. At times, of course, the answers of some witnesses were coloured by that individual’s own perception of where responsibilities lay for the problems which the project faced, and the evident lack of trust which existed between the two companies by the late stages of the relationship. Happily, however, I did not find any of the factual witnesses evasive or obtuse, and considered all were generally attempting to provide the Court with genuine assistance. Where appropriate in the context of specific issues, I identify where I have accepted, or rejected, particular aspects of a witness’s evidence. When considering the witness’s evidence I have had regard to their recollections as recorded in their witness statements and oral evidence alongside the contemporaneous correspondence and other written records, bearing in mind that whilst these are an extremely valuable source of evidence, they too can be the product of unconscious bias and unintentional fallibility and do not demand uncritical primacy (as set out in the extra-judicial speech by Popplewell LJ ‘Judging Truth from Memory: The Science’ (Footnote: ¹)).

By the conclusion of evidence, it was clear that there was less between the two IT experts than might first have appeared.

TCS relied upon the expert evidence of Mr Mark Britton, an experienced consultant specialising in the assurance of IT delivery projects BAU systems management. The evidence given by Mr Britton dealt with not just the IT-related technical evidence, such as the nature of infrastructure design, role of a systems integrator, and whether TCS complied with good industry practice, but also the detail of TCS’s delay case both in terms of the identification of what he considered to be the critical path through the project on the basis of his assessment of the Microsoft Project Plans, and the causes and extent of delays. I have no doubt as to the relevant experience of Mr Britton, and whilst it was put to him, fairly, that there is relatively limited reference to his involvement in analysing programme delays within projects, I accept that he had sufficient project experience to provide his opinion on programming matters. However, as will become clear, Mr Britton adopted what was effectively a prospective delay analysis which I do not consider to be either justified by the demands of the Agreement or was likely to prove reliable as a basis of identifying the actual causes of delay on the project. Ultimately, neither of his two delay analyses was particularly useful in discerning the actual durations and causes of critical delay on the project. As will become apparent, whilst there are a number of aspects of Mr Britton’s evidence which I accept as correct, there are some matters, in respect of which I reject his conclusions in favour of those of Dr Hunt (in relation to technical matters) and Mr Jardine (in relation to programming matters).

DBS relied upon the technical expertise of Dr Gill Hunt, whose CV, and indeed oral evidence, evidenced extensive experience in software and IT services and the delivery of major IT replacement projects such as the one this litigation relates to. I consider that Dr Hunt gave her evidence in a scrupulously fair way, and in her evidence she agreed or disagreed with the propositions put to her as she considered to be technically correct, irrespective of whether that did or did not favour the case of her client. Dr Hunt did not carry out any sort of delay analysis comparable to Mr Britton’s (that being done, for DBS, by the delay analyst, Mr Jardine). She did, however, comment upon dependencies and the technical causes of delays. Notwithstanding her obvious credibility, it will become clear that in certain respects I remained unpersuaded by her conclusions, particularly when it became apparent (and when she often fairly conceded) that the material upon which she relied for her conclusions was limited.

Given the task of detailed programme analysis undertaken by Mr Britton, TCS called Mr Anthony Morgan, a programming/delay analyst, to deal solely with the question of methodology. Notwithstanding his evident experience as an expert, Mr Morgan’s evidence was unimpressive and of little assistance to the Court. At the outset of his oral evidence, he appeared to dance around the obvious conclusion from his own report that Mr Britton had not, in his first report, carried out a recognisable as-planned v as-built analysis, which Mr Morgan had himself identified as the preferred methodology, at least in the construction and engineering industry, for analysing delays retrospectively. When questioned as to what ‘recognised practice’ he was satisfied that Mr Britton had carried out his method of analysis in accordance with, Mr Morgan asserted that it was a ‘Time Slice Analysis’. This, not mentioned anywhere in his report, was obviously wrong: a time slice analysis (as set out conveniently at paragraph 11.5 of the Second Edition of the SCL Protocol on Delay) is a method which determines the delay impact at each relevant point retrospectively – something that Mr Britton’s first report did not purport to do. This exchange led to Mr Morgan conceding that it is ‘possible’ that he had misunderstood what Mr Britton had done, which is somewhat astonishing given that the principal purpose of his report was to consider the appropriateness of Mr Britton’s methodology. I have not been able to place any weight on Mr Morgan’s evidence in my determination of the issues in this case.

DBS called Mr Scott Jardine, an experienced delay analyst who carried out an as-planned v as-built delay analysis. His conclusion supported DBS’s case that the critical path for the project ran through software development. I consider that he approached the task in his report with care and attention to detail, and also gave his answers in cross-examination with thought and, in my judgment, fairly. As will become clear, however, the cross-examination did expose areas where (to put it neutrally) a different view on where the critical path lay was both legitimate and, at some points, held contemporaneously. I have not, therefore, accepted all the conclusions Mr Jardine has reached even though I understand the reasonable justification for having advanced those conclusions in his reports.

TCS relied upon the evidence of Mrs Vikki Wall, and DBS upon the evidence of Mr Graham Hain. Both experts approached their oral evidence professionally and sought generally to assist the Court with their opinions, although both at times had seemed, at least in their reports, to have adopted a rather more critically rigorous approach to assessing the quantum of the other parties’ claims than when reviewing their own client’s. Nevertheless, their joint report and the various spreadsheets produced by them have been of considerable assistance, particularly in the context of the Volume Based Service Charges claim, for which I am grateful.

I have been assisted enormously by Counsels’ lengthy written Closing Submissions, supplementing their full written Opening Submissions. The numerous cross references to witness and documentary evidence and the relevant passages of oral evidence given under examination have been invaluable.

I have also been assisted greatly in navigating through the enormous quantity of material referred to by the schedules produced by the parties at my request upon Closing, which identified in relation to each claim and counterclaim the relevant parts of the pleadings, factual witness statements, and expert reports, and those passages of live evidence relied upon, together with a clear identification of the claimed amount, those claims no longer pursued and Written Closing Submission references. In a case like this, a single and authoritative source of the material each party, in Closing, relies upon is indispensable. In the arbitration world, such a Schedule is generally referred to as a ‘Spigelman Schedule’, named after the Honourable James Spigelman AC KC, former Chief Justice of New South Wales, and I shall do likewise in this judgment. I look forward to its broader adoption in complicated litigation as a standard tool to assist the task of judgment writing.

I therefore extend my thanks to the parties for their production of this material, and for their constructive co-operation demonstrated during the trial itself.

Issues of Construction of the Agreement

There are numerous points of construction of the Agreement which arise in relation to a variety of the issues.

There was no real debate between the parties as to the proper approach of the Court to matters of construction. I remind myself of the useful summary of the law, developed through the well known series of cases in the House of Lords and Supreme Court from Rainy Sky SA v. Kookmin Bank [2011] UKSC 50 [2011] 1 WLR 2900 to Wood v. Capita Insurance Services Limited [2017] UKSC 24 per Lord Hodge JSC at paragraph 11, set out at first instance by HHJ Pelling KC and recited as principles not disputed on appeal by the then Chancellor Sir Geoffrey Vos in Lamesa v Cynergy [2020] EWCA Civ 821:

The contract is a substantially amended version of a standard form used by the Government’s Office of Government Commerce (referred to as the Model ICT Contract). Neither party submitted that it was permissible, however, to consider the OGC Contract as part of an exercise of construction of Clauses where, as here, there is no evidence before the Court as to how (if at all) the parties put their mind to any differences from the standard form. See Seadrill Management Services Ltd v OAO Gazprom [2010] EWCA Civ 691, per Moore-Bick LJ at §17:

In the circumstances, I make clear that I have sought to determine the intention of the parties and the proper construction of the relevant clauses by consideration of the Agreement on its own terms.

The case advanced by TCS, as it had developed by Closing Submissions, relied largely, if not wholly, on failures by HPE which TCS did not say had themselves been caused by any particular failure on the part of DBS itself (in, for example, failing to co-ordinate or manage HPE), but either because (a) the infrastructure and service provided by HPE were systemically inadequate and/or (b) the way in which HPE carried out its obligations (to DBS) was inadequate. TCS argues that both types of act/omission by HPE constituted breaches of express or implied obligations upon DBS within the Agreement, or were, in any event, ‘Authority Causes’ for the purposes of Clause 7 of the Agreement. By contrast, DBS contend that failures on the part of HPE do not amount to any breach of contract by DBS and do not, moreover, amount to ‘AUTHORITY Cause’. If DBS is right about this, this is sufficient to dispose of TCS’ R1 Barring and Basics delay claim, which is based entirely on alleged failures on the part of HPE reflecting onto DBS.

Paragraphs 10-15 of the Amended Particulars of Claim summarise what TCS alleges were the services it was required to provide and, equally important in the context of this case, those services which it says it was not required to provide. It relies upon paragraphs 2.33 and 2.34 of Schedule 2-2 of the Agreement. These run to about 10 pages, and TCS contends that their obligations were limited to development and management of application software for the Solution, and did not extend to design and/or providing the technical infrastructure on which the Solution was to be deployed. DBS disputes this, and in light of the requirement upon TCS to specify within the appropriate Service Description how the Technical Infrastructure meets each of the standards and constraints set out in Schedule 2-12 to the Agreement (see Clause 2.1.2.2 of Schedule 2-12), I accept that this does appear to be at least an over simplification of TCS’s role.

TCS also contends that its obligations did not extend to providing systems integration services, ‘such as managing dependencies between the Defendant’s various suppliers, ensuring compatibility between the Solution and the technical architecture, or ensuring that suppliers and stakeholders all performed their responsibilities in accordance with a plan that permitted the project to proceed on schedule’. The nature and extent of each party’s responsibilities to act as ‘systems integrator’ features large in the pleadings, in the factual and expert evidence and indeed in the written and oral openings, but the extent that particular periods of delay as ultimately advanced at trial in fact turned on the precise definition of, or the parties’ respective responsibilities in respect of, ‘systems integration’ was in reality considerably less. Nevertheless, it is a matter I consider further below.

The clauses specifically pleaded at paragraph 25 of the Amended Particulars of Claim and relied upon for establishing express breaches were Clauses 5.1, 5.2 of Schedule 2-6 of the Agreement (in relation to R1-Dand 15.4 and 15.6 of Schedule 2-6 of the Agreement (in relation R1 Barring and Basics).

The relevant parts of Clause 5 and 15 of Schedule 2-6 of the Agreement state:

Clause 15:

The general obligations at Clauses 5.1 and 5.2 do not of themselves make DBS liable, without more, for the absence of or delays in the provision of information which is required by TCS to perform their role in delivering the Solution. Indeed, the opposite is true: establishing a breach of either of these clauses entails demonstrating that the absence of or delay in information resulted from a failure on the part of DBS to co-operate or to use reasonable endeavours to ensure that the necessary information was provided within such timescales as TCS may reasonably have established. DBS does not deny the existence of such general obligations but does deny their relevance to the case advanced by TCS. Mr Croall accepted that, to the extent that any particular failure said to be the cause of Delay can specifically be attributed to a breach by DBS of one of these two clauses, that would be an Authority Cause for the purposes of Clauses 5 and 7. However, Mr Cogley also rightly accepted that in order to establish a breach of the first part of Clause 5.2, for example, it would be necessary to prove both (a) the absence of information and (b) the way in which that absence arose out of a failure by DBS to have co-operated.

As to Clauses 15.4 and 15.6, TCS was a ‘Service Line Provider’ for Application Management Services and Application Development. HPE was a separate Service Line Provider. TCS recognises that, given that HPE was not party to the Agreement, Clauses 15.4 and 15.6 did not impose any direct obligations on DBS’s other Service Line Providers. However, TCS’s case at paragraph 26.2 of the Amended Particulars of Claim, is that these clauses ‘comprised warranties given by [DBS] in respect of the conduct of its other Service Line Providers’.

I do not accept that these clauses can be construed as comprising warranties by DBS in favour of TCS in respect of the activities of other Service Line Providers for the following reasons:

In the circumstances, I do not consider that Clauses 15.4 and 15.6 of Schedule 2-6 can be read as warranties from DBS in favour of TCS. However, even if I am wrong about this, TCS’s case on breach does not (save in the most broad and unspecific way) relate back to the specific warranties provided:

At paragraph 26.3 of the Amended Particulars of Claim, in contrast to its position at paragraph 26.2 (and not pleaded as an alternative), TCS plead that Clauses 15.4 and 15.6:

These are then defined as ‘Systems Integration Activities’.

As a matter of simple language, it is plainly not possible to read these obligations into Clauses 15.4 and 15.6 of Schedule 2-6 of the Agreement. The first and most obvious reason is that there is no way in which the phrase ‘Each Service Line Provider will….’ can be read as imposing a primary obligation on DBS. DBS is not a Service Line provider. It is simply not what the words say. DBS is the beneficiary of these clauses, and not the party upon whom the obligations are placed. Second, in any event, the specific obligations relating to advice and guidance (Clause 15.4) and collaboration (Clause 15.6) come nowhere close to imposing the particular obligations specified by TCS in its pleading.

In the alternative to its case that DBS was obligated to provide or procure the provision of Systems Integration Activities as a consequence of the express Clauses 15.4 and 15.6 of Schedule 2-6, TCS plead at paragraph 27 of the Amended Particulars of Claim that it was an implied term essentially to the same effect, namely that ‘[DBS] would timeously either fulfil the function systems integrator, or appoint [TCS] as systems Integrator, or appoint a third-party systems integrator, or would otherwise take such steps as were necessary to ensure that the Systems Integration Activities would be timeously performed.’ TCS claims that such a clause was obvious and necessary for the business efficacy of the Agreement, because in the absence of the Systems Integration Activities being timeously performed, TCS would be unable to discharge its contractual responsibilities within the contractual timeframes and be unable to reduce the cost of providing Operational Services in accordance with the FM.

This is a sophisticated contract and, as DBS contends, there is no room for such an implied term in the Agreement, and the test of strict necessity cannot be met.

Moreover, there are a number of express terms imposing obligations upon TCS which make clear that at least some parts of the implied term as advanced would be in contradiction with those express terms, and thus not tenable. These include, perhaps most obviously:

Clause 9.5 which states:

“The CONTRACTOR shall ensure that the Services and the CONTRACTOR System integrate with the AUTHORITY System as set out in schedule 2-2”.

Clause 14.5 of Schedule 2-6 which states:

“The CONTRACTOR is responsible for…. all reasonable assistance to Other Service Line Providers in the management by them of their respective services (including any specific business projects or Application Development Services)….’

As a matter of contractual analysis, therefore, I reject the existence of the implied term relied upon by TCS.

Finally, it is necessary to deal with the case pleaded by TCS at paragraph 34 of the Amended Particulars of Claim, that ‘the aforesaid …failures on the part of [HPE] each amounted to an AUTHORITY Cause as that term is defined in the Agreement’. The ‘failures’ are the matters pleaded at paragraphs 30, 31, and 31A of the Amended Particulars of Claim (which are, in general terms, the matters which TCS claim were the causes of delay to its work). Paragraphs 30 and 31 relate to what are effectively both systemic and particular problems with HPE, and paragraph 31A relates to problems caused by DBS itself in relation to an issue referred to (and considered in more detail below) as ‘PSN Connectivity’ and another relating to the introduction of two-factor authentication (‘2FA’).

In relation to the failures by HPE, it is said that an act of prevention on their part is of itself an ‘Authority Cause’ for the purpose of Clause 7 (the clause pursuant to which TCS can claim relief from Delay Damages and its own losses caused by delay).

In Closing Submissions, Mr Croall indicated that DBS’s primary position that this ‘broad’ case was not open on the pleadings. However, I do not agree. I consider that the general case is one encompassed within paragraphs 34 of the Amended Particulars of Claim.

Authority Cause is defined as:

“any breach by the AUTHORITY of any of the AUTHORITY’s Responsibilities (except to the extent that it is the result of any act or omission by the AUTHORITY to which the CONTRACTOR has given its prior consent)”.

It is also relevant that Default (in the context of ‘Contractor’s Default’), is defined as follows:

Neither the words ‘AUTHORITY’s Responsibilities’ nor ‘Responsibilities’, which, as can be seen, form a central part of the definition of ‘AUTHORITY Cause’ has been contractually defined, notwithstanding the fact that ‘Responsibility’ is capitalised, as though the parties had intended the word reflect a defined term.

TCS contends that as a matter of natural and ordinary language, and as a matter of common sense given the contractual usage of the term, ‘AUTHORITY’s Responsibilities’ capture not only matters that were strict breaches of the Agreement by DBS but extended to all aspects of the project which were within what it describes as DBS’s ‘sphere of responsibility’. As such, it says that (even if DBS is not in breach of an express or implied term) critical delays caused to it by HPE’s services were nevertheless ‘AUTHORITY Responsibility’ because HPE was DBS’s contractor, and it was only DBS that had the right and power to instruct HPE and to procure its timely performance. Put shortly, as between DBS and TCS, TCS contends that DBS was ‘responsible’ for HPE and any failure by HPE to deliver something which TCS was dependent upon amounts to an ‘AUTHORITY Cause’ whether or not that failure was itself a breach by DBS of its own obligations to TCS.

By contrast, DBS contends that AUTHORITY Cause was defined as comprising only a ‘breach’ by DBS of its ‘Responsibilities’ and that the use of the word ‘breach’ is consistent with an interpretation that only a breach of a contractual obligation by DBS can amount to ‘AUTHORITY Cause’. In these circumstances, failures by third parties (even if they are sub-contractors to DBS) and/or matters not amounting to a breach by DBS of its own contractual obligations do not constitute ‘AUTHORITY Cause’. DBS relies upon what might be described as a relatively liberal use of the phrase ‘responsible/responsibility for’ within the Agreement as synonymous with the phrase ‘obliged/obligation to’.

I note at the outset that the parties have chosen to use within the delay/relief regime in Clauses 5-8 (and also the relief regime in the context of operational delays in Clause 11) two different phrases: ‘CONTRACTOR Default’ and ‘AUTHORITY Cause’.

As set out above CONTRACTOR Default means, in essence, a breach of TCS’s obligations or any default, act, omission, negligence by it, its employees, agents or sub-contractors in connection with or in relation to the subject matter of the Agreement. If the word ‘Default’ had been used to define the trigger for TCS’s entitlement within Clause 7 (i.e. ‘Authority Default’) a failure on the part of HPE, as DBS’ subcontractor, would be a failure on the part of DBS, but, and importantly, only insofar as HPE failed in providing to TCS something to which it was contractually entitled.

Instead of using the phrase Authority ‘Default’, the parties have used different language.

TCS contends that ‘Auth AUTHORITY ority Cause’ is wider than ‘Default’ in that it includes matters for which the Authority may generally be ‘Responsible’ even if that does not arise out a breach of a particular obligation. A key example of this provided in argument is an instruction: the instruction of additional work would be something covered by ‘AUTHORITY Cause’ even though DBS was entitled to give instructions. Particularly pertinent to the present dispute is that the phrase is said to cover what, TCS contends, would generally be an act of prevention by any party for whom DBS would be ‘responsible’ as between it and TCS, in the sense that the third party in question is in contract with DBS and DBS is the only party with any contractual ability to control that third party.

By contrast, DBS contends that ‘AUTHORITY Cause’ is narrower than ‘Default’. Responsibility, it is argued, is simply a synonym for ‘obligation’. DBS accepts that ‘AUTHORITY Cause’ would capture breach of an Authority obligation whether or not it was carried out by the Authority itself or a contractor or servant or agent of the Authority. However, it says, when compared with ‘Default’, breach of an obligation is a subset of the types of matters which would be included in ‘Default by the Authority’ (a phrase which is used in, for example, the limitation of liability provisions at Clause 52.3.4). It would not include, for example, a ‘statement in respect of which [DBS] is liable to [TCS]’ (unless it was also a breach of obligation).

The submission of DBS is to be preferred. This is because:

Thus, to the extent that TCS is entitled to receive something from DBS and/or its third party suppliers pursuant to the terms of the carefully drafted Agreement, a failure to provide that will be a breach of an obligation, and an ‘AUTHORITY Cause’. However, unless TCS is able to demonstrate an express or implied contractual obligation on DBS to have provided TCS with something, the absence of that thing cannot in my judgment be a ‘breach by the AUTHORITY of any of the AUTHORITY’s Responsibilities’ and therefore it cannot be an ‘AUTHORITY Cause’ for the purposes of Clause 7.

The meat of the delay and notice provisions are found in Clauses 5 to 8 of the Contract.

Delay is defined as follows:

There are particular constructional questions relating to the limiting or excluding of rights, whether through the express limitation provisions (Clause 52) or through the operation of notification requirements which, it is said by each party against the other, have the effect of excluding certain entitlements when not complied with (Clause 5.6; Clause 6.1). In this context, I also remind myself of the recent guidance of the Supreme Court in Triple Point Technology, Inc v PTT Public Company Limited [2021] UKSC 29, in which Lord Leggatt explained:

Clause 7 deals with delay to Milestones due to AUTHORITY Cause. The rights and relief are stated to be subject to Clause 5.6, accepted to be a condition precedent clause by TCS.

The rights and relief, subject to Clause 5.6 (considered further below), are also said to be available if TCS ‘would have been able to Achieve the Milestone by its Milestone Date but has failed to do so as a result of an AUTHORITY Cause’.

DBS had not focussed on the meaning or import of this element of Clause 7.1 either in its pleading or in its Written Opening Submissions. However in its Closing Submissions its case was that in order for any relief to be granted pursuant to Clause 7 (and subject to Clause 5.6), TCS had to show that it would have met the Milestone. It contends therefore where there is any critical delay, or any delay on a sub-critical path, either of which prevents TCS from establishing that it would have been able to Achieve the Milestone but has failed to do so as a result of an ‘Authority Cause’, no rights or relief under Clause 7 exist.

TCS contends that read as a whole, the regime set up by this clause is one whereby (Clause 5.6 aside) TCS is liable for failure to meet a Milestone by its Milestone Date save where and to the extent that the delay is ‘AUTHORITY Cause’. So, if there are 100 days of Delay (such that a Milestone is Achieved 100 days late), 70 of which are ‘AUTHORITY Cause’ and 30 of which are not, then TCS is liable in respect of 30 days (and potentially has liability to make Delay Payments to DBS), but in respect of the other 70 days, TCS is not in breach of the Agreement (by virtue of Clause 7.2.2), is not liable to make Delay Payments (Clause 7.2.3), and is entitled to compensation (Clause 7.2.4).

TCS expressly accepted that if TCS would not have achieved a Milestone by the Milestone Date in any event (even where its own delays were sub-critical) it would not get relief or compensation for the period during which it would have been in delay in any event. So, for example, if the Milestone is 1 February, and there are two months’ critical delay caused by ‘AUTHORITY Cause’ to achievement of the Milestone which takes place on 1 April, but in circumstances where TCS would not have been able to Achieve the Milestone because of software development delays (on a sub-critical path) until 1 March, the maximum relief/right would be for 1 month.

Mr Cogley argues that the ‘all or nothing’ construction advanced by DBS does not fit with Clause 7.2.1 and Clause7.2.3 where these clauses contain qualificatory language – ‘equal to the Delay caused by’ (Clause 7.2.1) and ‘to the extent that the Delay results directly from’ (Clause 7.2.3).

TCS’s construction is to be preferred. The product of DBS’ construction is that one day’s sub-critical delay to a Milestone not caused by ‘AUTHORITY Cause’ has the effect of depriving TCS of relief or compensation for potentially significant periods of (critical) Delay caused by ‘AUTHORITY Cause’. This is the most improbable outcome and could only be achieved by clear, consistent language. Whilst it is correct that Clause 7.1 itself has no qualifying language, the better construction reads the Clause 7.1 and 7.2 regimes as complimentary. Clause 7.1 is intended to make clear that, in considering the rights and relief under Clause 7.2, it is necessary to take into account whether TCS would have been able to Achieve the Milestone by its Milestone Date in any event. Thus, when considering the extent to which Delay was ‘caused’ by or ‘results from’ ‘AUTHORITY Cause’ within Clause 7.2, Clause 7.1 make clear that DBS’s own inability to have met the Milestone in any event is to be taken into account. This construction, in effect, gives contractual effect to the prevention principle and therefore has the benefit of coherence and compatibility with existing common law rights. (In doing so, it is potentially less favourable to TCS than some common extension of time standard form regimes in which CONTRACTOR Default on sub-critical paths – or the question of whether or to what extent the Milestone would have been achieved anyway – does not affect the extent of relief from liquidated damages).

This means that whilst the analysis of what lies on the critical path remains an important aspect of the case, the wording of the clause means that it is equally important (even if TCS establishes that it has been critically delayed by an ‘AUTHORITY Cause’) to consider whether TCS would have been able to Achieve the Milestone by its Milestone Date in any event. In other words, if TCS was delayed by matters which were not ‘AUTHORITY Cause’, albeit on a sub-critical path running in parallel to the critical path, such that TCS is unable to establish that it would have achieved the Milestone by the Milestone date irrespective of critical delay caused by the matters it complains of, TCS has no entitlement under Clause 7. Similarly, in this situation it would be unable to claim prolongation costs as damages for breach of contract because it would not be able to establish the necessary causation for the period during which it was incurring costs by reason of its own delays.

I also consider that, in relation to the debate between the parties as to the appropriate methodology for considering delay issues, the clause makes clear that the entitlement depends upon establishing whether TCS in fact failed to achieve the Milestone by the Milestone Date as a result of ‘AUTHORITY Cause’. I return to this when considering the competing methodologies of Mr Britton and Mr Jardine.

It is DBS’ case that, by reason of the wording of Clause 5.6, compliance with Clauses 5.1 to 5.3 is required in order for TCS to claim compensation (including general damages) for Delays attributable to ‘AUTHORITY Cause’. Similarly, it is TCS’s case that DBS’ entitlement to recover Delay Damages pursuant to Clause 6.2.3 is conditional upon compliance with the substance of Clause 6.1.

Before looking at the clauses themselves, I consider general principles derived from the caselaw as applicable to notice requirements said to be conditions precedent which affect entitlement. The overriding principle is that, of course, each contract is to be construed according to its own particular terms. Clauses, or parts of clauses, which look similar but which are set in different contractual matrices may have different effect. As stated by Leggatt J (as he then was), when faced with what superficially appeared to be conflicting first instance authorities in Scottish Power UK PLC v BP Exploration Operating Company Ltd [2016] All ER 536 at [204]:

Insofar as identifying a framework for consideration of the construction of such clauses, the starting point is generally seen to be Bremer Handelsgesellscheft Schaft v Vanden-Avenne Izegem PVBA [1978] 2 Lloyd’s Rep 109, in which Lord Wilberforce said:

The case itself is helpful in illuminating how these principles may be applied. The House of Lords considered clause 21 of the GAFTA Form 100, in the context of an embargo imposed by the United States government which prohibited the export of soya bean meal. The clause stated:

Having provided the three point guidance quoted above, Lord Wilberforce considered, as to (i), that the clause was not framed as a condition precedent, in that the first sentence was not expressed to be conditional upon the second sentence being complied with. Absent a link phrase such as ‘provided that’, the second sentence does not attain conditional status. Moreover, he considered that the generality of the words told against the construction as a condition precedent, which, if intended, would more likely set a definite time limit. As to (ii), the rest of the contract was considered and Lord Wilberforce concluded on the basis of the wording of other clauses that ‘if such a condition were intended, other and stricter language would have been used’. As to (iii), the Court observed that a clause such as this should an innominate term so that in many, possibly most, instances, breach could be adequately sanctioned by damages, but always so to treat it may be unfair to the seller and unnecessarily rigid.

In London Borough of Merton v Stanley Hugh Leach Ltd (1985) 32 BLR 51, Vinelott J considered Clause 24 (1) of the 1963 Edition of the JCT Standard form which stated:

This clause was described as an ‘if’ provision, which only operated in the event that the contractor invoked it by making a written application. The word ‘if’ is sufficient to create the conditionality between the required action and the entitlement. Having considered Merton in WW Gear Construction Limited v McGee Group Limited [2010] EWHC 1460 (TCC), Akenhead J considered, in the context of Clause 4.21 of the JCT Trade Contract terms (TC/C) 2002 edition that the opening sentence of the clause (‘If the Trade Contractor makes a written application to the Construction Manager stating that he has incurred or is likely to incur direct loss and/or expense’) makes it clear that the trigger for the operation of Clause 4.21 is the making of the application by the Contractor. The judge observed that the maxim is presumably that he or she who does not ask does not get. Thus, fulfilment of a contingency introduced by the word ‘if’ is likely to be a condition precedent.

A further case relied upon as demonstrating the potency of an ‘if’/provided’ is Steria Limited v Sigma Wireless Communications Limited [2007] EWHC 3454 TCC. The relevant parts of the clause read:

Notwithstanding the fact that the words ‘condition precedent’ were not used in the clause, and that the clause did not expressly state the contractual consequences of not giving a notice, HHJ Stephen Davies rejected those arguments and found that service of a notice was a condition precedent to a right to an extension, stating (at [90-91]):

One case which points in the opposite direction is Yuanda (UK) Company Limited v Multiplex Construction Europe Limited & Others [2020] EWHC 468 (TCC) in which Fraser J (as he then was) considered clause 2.21 of the JCT Design and Build Sub-Contact Conditions 2011 which states:

The Judge held, obiter, that the wording of the clause suggests that it is not a condition precedent. In the context of the issues before him, it was unnecessary for him to consider the clause in any detail. However, applying Bremer Handelsgesellscheft Schaft it seems likely that Fraser J was unpersuaded that the clause was a condition precedent, not withstanding the ‘if’ language, because of the absence of clearer language and, potentially, the absence of a specified period (as opposed to ‘a reasonable time’).

In Scottish Power, referred to above, Leggatt J (as he then was) considered a number of previous authorities relating to notice provisions in the context of force majeure clauses, which authorities were also relied upon in front of me. In Scottish Power itself, the relevant clause provided that ‘A Party, when claiming relief under Clause 15.2 shall:-…’ and then set out certain information to be provided within different time periods in the following sub-clauses. It was accepted that the party claiming force majeure relief had not complied with one of the sub-clauses. I note that whilst there was the language of obligation ‘(‘shall’) there was no express or implied language of conditionality. Leggatt J in Scottish Power concluded that, ‘I find it impossible to conclude that reasonable parties would have intended the requirements of art 15.4 to constitute conditions precedent (or subsequent) to a claim for relief without ‘thinking it necessary to say so expressly’.

Any attempt to articulate an exhaustive checklist of factors to consider when considering whether a particular clause in a particular contract is a condition precedent will inevitably be futile. However, the following can be distilled from the foregoing authorities as obviously relevant matters I should, and do, have well in mind in the present case when considering whether the relevant clauses should be construed as a condition precedent:

There can be no doubt, and it is not disputed by TCS, that the wording of Clause 5.6 is a clause which has the effect of making compliance with Clauses 5.1-5.3 a condition precedent and an entitlement to compensation under Clauses 7 or 8. It provides in plain language that DBS ‘shall not be liable to compensate [TCS] for Delays to which clauses 7 or 8 apply unless [TCS] has fulfilled its obligations set out in, and in accordance with, clauses 5.1, 5.2 and 5.3.’ This starting point was not disputed by Mr Cogley.

It is equally clear that the condition precedent regime applies only to DBS’s liability to compensate TCS for Delays, as defined. This has a number of implications. First, a failure to comply with the condition precedent does not impact upon TCS’s entitlement to what may be called generically ‘relief’ as described in Clause 7.2, namely (a) an extension of time equal to the Delay caused by that ‘AUTHORITY Cause’; (b) not being in breach of contract (or liable for resulting general damages) as a result of the failure to Achieve the relevant Milestone by its Milestone Date; and (c) having no liability for Delay Payments in respect of the relevant Milestone to the extent that the Delay results directly from the ‘AUTHORITY Cause’. In other words, non-compliance with the condition precedent does not preclude TCS from defending itself from DBS’s claims, whether for Delay Payments or for damages for breach of contract, provided it establishes that it ‘would have been able to Achieve the Milestone by its Milestone Date but has failed to do so as a result of an AUTHORITY Cause’ (as set out in Clause 7.1).

Non-compliance with the condition precedent regime may, however, preclude its own claims for compensation, subject to TCS’s point that any claim for damages, as opposed to contractual compensation, is also not caught by Clause 5.6. Whether a claim for general damages survives non-compliance with Clause 5.6 is a matter of construction. Mr Croall argues that the objective intention of the parties cannot have been that, having expressly provided for the payment of delay compensation in certain circumstances subject to certain requirements, TCS can circumvent the contractual regime simply by claiming damages for breaches of other terms of the Agreement. He relies upon Bikam OOD, Central Investment Group SA v Adria Cable S.a.r.l. [2012] EWHC 621 (Comm) at [37]-[38], in which Mr Justice Simon dealt with a counterclaim for misrepresentation which the claimant contended was an illegitimate means of getting around the parties’ agreement that claims were confined to breach of the seller’s warranties and by the terms of a clause limiting the amount of such claims. The Court rejected the defendant’s argument that the clause dealt with contractual claims and did not deal with misrepresentation. Simon J considered, in concluding that the defendant’s construction was ‘uncommercial’:

Set against this is the well known general principle that it requires clear and unequivocal words for a party to be considered to have given up a common law right which otherwise sits alongside contractual entitlements (Modern Engineering (Bristol) v Gilbert -Ash [1974] AC 689).

In the present case, I consider that TCS’s potential entitlement to claim both loss and expense pursuant to Clause 7.4 and general damages at common law for ‘Delays’ (as defined) are subject to compliance with the regime at Clauses 5.1 to 5.3. This is because:

If, therefore, TCS fails to comply with Clauses 5.1 to 5.3, and subject to the further arguments it makes as to estoppel, TCS is not entitled to claim compensation, whether under Clause 7.4 or at common law, for ‘Delays’ it considers to have been caused or contributed to by an ‘AUTHORITY Cause’.

Finally, it should be noted that ‘Delays’ is defined by reference to the period of time by which the implementation or provision of the Services by reference to the Implementation Plan is delayed arising from a failure to Achieve a Milestone. In other words, critical delay. This means that claims for financial compensation for non-critical delay or disruption are not caught by the regime at Clauses 5 to 8. However, such claims would be for breach of contract, rather than as a consequence of ‘AUTHORITY Cause’. If Mr Cogley is right that the latter is wider than the former, it is only the more narrow claims which could be relied upon for claims brought outside the Clause 5-8 regime. This is an academic distinction where no part of TCS’s claimed quantum is allocated between (for example) costs caused by critical delays and those caused by non-critical activity delays or disruption.

Clause 6.1 is first engaged if a Deliverable does not satisfy the Acceptance Test Success Criteria and/or a Milestone is not Achieved due to the Contractor’s Default.

It was not suggested by TCS, in either its pleaded case or Written Submissions, that this requires DBS to establish more than the fact of the non-achievement of a Milestone, in circumstances where TCS has, pursuant to Clause 3.1, an obligation to provide the Services in accordance with the Implementation Plan, itself incorporating the Milestones. In these circumstances, the non-achievement of a Milestone will, unless relief is obtained pursuant to Clause 7, amount to a CONTRACTOR Default. Although I explored during the course of Closing Submissions with Mr Cogley and Mr Croall whether some greater substance should be placed on the words ‘CONTRACTOR Default’ in the context of Clause 6.1, I have concluded that to do so would be wrong. This is principally because, in conjunction with Clause 7.2.2, it is plain that in the scheme of this Contract, failure to achieve the relevant Milestone by its Milestone Date is itself a breach. For what it is worth, this construction accords with the usual position in many standard form contracts where failure to meet a particular milestone of itself is justification for the imposition of liquidated damages, absent the Contractor successfully obtaining an extension of time.

As discussed further below, it does not follow from this, however, that, as Mr Croall submitted, the issue of a Non-conformance Report pursuant to Clause 6.1 is largely redundant in that it need only identify that the Milestone Date has been missed. Mr Croall’s related argument advanced in oral closing submissions, that Clause 6.1 focuses on the scenario where TCS has failed to achieve Acceptance Test Success Criteria, also paints the clause too narrowly. Although some of the language is geared towards this, the clause is plainly not directed solely towards a failure to pass the Testing.

To understand the clause it is necessary to set it in the context of TCS’s obligations and how a Milestone is achieved. TCS had certain ‘Deliverables’ These are defined as ‘an item, feature or service associated with the provision of the Services or a change in the provision of the Services which is required to be delivered by [TCS] at a Milestone Date or at any other stage during in the performance of this Agreement [sic]’ A Deliverable must be tested before an Acceptance Test Certificate can be issued. Pursuant to Clause 3.4 of Schedule 2-5 of the Agreement (‘Test and Acceptance Procedures’), TCS ‘shall use reasonable endeavours to submit a Deliverable for Testing or re-Testing by or before the date set out in the Implementation Plan for the commencement of Testing in respect of the relevant Milestone’. Pursuant to Clause 3.3 of the same Schedule, TCS ‘shall not submit any deliverables for AUTHORITY Testing’ until various criteria had been met, which interfaced with DBS. For example, pursuant to Clause 3.3.2, the parties were required to have agreed the Test Plan and the Test Specification relating to the relevant Deliverables before they could be submitted for testing.

In this context, the scope of the clause becomes clear. The first words of Clause 6.1 expressly contemplate non-satisfaction of the Acceptance Test Success Criteria. This applies therefore in circumstances where the Deliverable has been tested, but where there are Test Issues preventing some or all of the Acceptance Test Success Criteria from being Achieved. A (prompt) Non-conformance Report is required to be issued by DBS in these circumstances, whether or not the non-satisfaction has also led to the additional failure to have Achieved a Milestone. This is clear from the words ‘and/or’. The clause then expressly refers to its application where ‘a Milestone is not Achieved’. The words ‘due to the Contractor’s Default’ apply to either situation.

As becomes clear from the words which then follow, the reason why a Milestone has not been achieved may not be that the Testing has failed, but may also occur where no Testing has taken place at all as at the date of the Milestone. The wording of the clause is very clear that in each of these situations, DBS is required (‘shall’) to ‘promptly issue a Non-conformance Report’. The Non-conformance Report is to deal either/both with (a) the situation where the Deliverable has been tested, in which case the Non-conformance Report must categorise the Test Issues as described in the Testing Procedures; and/or (b), where no Testing has taken place, in which case the Non-conformance Report must set out in detail the non-conformities of the Deliverable, including any other reasons for the Milestone not-being Achieved. Whilst clearly the Non-conformance Report will be limited to such matters as are properly within DBS’s knowledge, it is improbable that a Non-conformance Report which simply says ‘TCS has not achieved the Milestone by the Milestone Date’ would comply with the requirements of the clause.

It is in this context that Clause 6.1 then concludes, ‘The AUTHORITY will then have the options set out in clause 6.2’. Clause 6.2 (at 6.2.3) includes the payment of Delay Damages. There is no other provision pursuant to which DBS become entitled to payment of Delay Damages.

The issue between the parties in respect of Clause 6.1 is whether it has the effect of making the prompt issue of a Non-conformance Report a condition precedent to recovering Delay Damages. TCS says it does, and DBS says it does not. TCS’s argument rests on a conditionality it says derives from the word ‘then’.

Bearing in mind the factors I have identified following my review of the law above, I start with the ordinary language of the clause. The word ‘then’ in the last sentence of Clause 6.1 makes clear, at the very least, that the entitlements in Clause 6.2 happen after the matters dealt with in the preceding words of Clause 6.1 have been engaged. ‘Then’ is a word which is often used in conditional sentences, but generally in sentences where the conditionality itself is derived from the words ‘If’ or ‘Unless’ or ‘Provided that…’. That conditionality is also present in Clause 6.1, which starts with ‘If’.

As a matter of normal usage of language, therefore, the entitlements in Clause 6.2 are clearly linked to Clause 6.1, through the conditional phrasing of ‘If….then….’. Construed naturally, the ‘If’ trigger in Clause 6.1 gives rise to two matters which are conditional on the ‘If…’ trigger: the first is an obligation (as set out in the remainder of Clause 6.1), and ‘then’ the second is an entitlement (in Clause 6.2). In other words, the requirement to carry out the obligation (service of a Non-conformance Report) is conditional on the ‘If…’ happening, just as the entitlement is conditional on the ‘If’ trigger happening. In my judgment, it makes no sense (either linguistically or commercially) to apply the conditional link between Clause 6.2 (the entitlement) and just the first part of Clause 6.1, effectively leapfrogging the second part of Clause 6.1 (the obligation).

It is true that the parties have chosen to express the condition precedent nature of compliance with Clause 5.1 to 5.3 in a different way, in the context of TCS’s entitlement to relief. This is potentially a factor weighing against construing Clause 6.1 as a condition precedent, when considering Lord Wilberforce’s second limb. However, it could equally be said with justification that when the delay provisions are considered as a whole, the existence of some symmetry in relation to the requirement upon both parties to provide a form of notice/information to the (other) party responsible for the delays as a condition of claiming compensation weighs in favour of TCS’s construction. This is particularly so where the rationale for the imposition of a notice regime as a condition precedent is to know where a party stands contemporaneously, and to allow the defaulting party to rectify its default. Whilst it is right that the parties will know when a Milestone has not been achieved, the Non-conformance Report must, in circumstances where the Milestone has passed but no Testing has been carried out, set out (insofar as within the knowledge of DBS) the non-conformances which have prevented Testing and any other reasons the Milestone has not been achieved (for example, the failure to have submitted a Test plan capable of agreement). In these circumstances, the conditionality created by the clear ‘If…then’ language attaching to the Non-conformance Report serves a useful purpose.

Whilst I also take account of the fact that the time period by which the Non-conformance Report has to be given is expressed by the word ‘promptly’ rather than a specified number of days, this does not in my judgment preclude the condition-precedent nature of compliance. Whether a report has been given ‘promptly’ is a question of fact and is sufficiently certain in meaning to be given effect to (as was the case in Merton, WW Gear Construction and Steria).

In the circumstances, as a matter of language, there is a clearly expressed intention to impose conditionality. ‘If’ certain CONTRACTOR Default occurs, DBS ‘shall’ comply with its obligation promptly to issue a Non-conformance Report in accordance with Clause 6.1. The last sentence of Clause 6.1 has an ordinary and natural meaning: that it is only ‘then’ that DBS have the options set out in Clause 6.2. The language should be given its ordinary and natural meaning, the effect of which is that compliance with the obligations imposed upon DBS in Clause 6.1 is necessary in order then for DBS to have the options set out in Clause 6.2.

In the present case, there is no dispute that no Non-conformance Report was provided, at any time. The pleaded averment (in DBS’s RFI Response dated 30 January 2023) that the letter of 15 June 2017 constituted a relevant Non-conformance Report and denied at paragraph 52A.2 to the Re-Amended Reply and Defence to Counterclaim was not pursed at trial or in Closing by DBS. To the extent necessary, I find for the reasons TCS aver at paragraph 52A.2.2 of the Re-Amended Reply and Defence to Counterclaim that it was not a relevant/valid Non-conformance Report in respect of the failure to achieve the relevant Milestones for the purposes of Clause 6.1. In these circumstances, DBS is precluded from recovering Delay Damages from TCS, if it would otherwise have been entitled to on account of Delay.

The story of Clause 6 does not, however, end there. As made clear by Clause 6.3, Delay Payments are provided as the primary remedy for TCS’ failure to Achieve the relevant Milestone Date and it shall be DBS’s exclusive financial remedy except where (pursuant to Clause 6.3.2) the failure to Achieve the Milestone exceeds a period of six months after the relevant Milestone Date.

The question arises: what happens if (a) the Authority fails to comply with the condition precedent in Clause 6.1 but (b) establishes that the Contractor’s failure to Achieve the Milestone exceeds a period of 6 months.

Absent the failure to have complied with the condition precedent, the parties agree that DBS would be entitled to claim its actual delay related losses over and above the sums it recovered by way of liquidated damages (i.e. giving credit for any sum recovered by way of liquidated damages). Mr Croall accepted in terms in his oral closing submissions that this meant that DBS would not be entitled to recover for the first six months of delay, because it is an exclusive remedy for that period and if the right is lost, it is not regained through the backdoor.

However, the right lost is greater than merely the payment of Delay Payment Damages for the first six months: Clause 6.2.3 provides an ongoing right to recover the relevant Delay Payments until the date the Milestone is Achieved. But for Clause 6.3.2, a failure to have complied with the condition precedent would mean that the right to recover that entire amount is lost. By reason of Clause 6.3.2, however, after six months, DBS has two potential remedies: a claim for (liquidated) Delay Payments, and a claim for unliquidated damages. As provided for explicitly in Clause 6.3, Delay Payments are provided as the ‘primary’ remedy. Moreover, DBS rightly accepted that it would not be able to recover both. Assuming compliance with Clause 6.1, after six months, DBS would be entitled to bring in addition to its primary remedy of Delay Payments, a claim for such actual losses as it could prove in addition to its claim for Delay Payments. In the period after 6 months, the logic of Mr Croall’s concession remains, and DBS’s entitlement to its primary remedy of Delay Payments, lost because of a failure to comply with Clause 6.1, cannot be regained by the backdoor. Its claim, therefore, in light of non-compliance with Clause 6.1, is limited to those actual losses incurred after 6 months of delay, to the achievement of the Milestone, over and above the Delay Payments it would have otherwise been entitled to.

Clause 8 provides a specific mechanism for the apportionment of responsibility where a Delay is attributable in part to the CONTRACTOR Default and in part to an ‘AUTHORITY Cause’.

DBS’s Written Opening submissions included Clause 8 in its extract of the relevant clauses of the Agreement, but did not otherwise refer to it. TCS’s Written Opening Submissions did not refer to Clause 8 at all, and no reference is made to Clause 8 in the pleadings. The Court queried the relevance of the Clause to either side’s case. This prompted a supplemental note from TCS in which it indicated that the clause applied to parallel delays, not merely to strictly concurrent delays, and that a delay can be ‘attributable in part’ to each party, without there being strictly concurrent causes. TCS submits that ‘first in time’ concurrency is not intended (i.e. the consequences of the events must exist simultaneously but they can start and end at different times and may have different potencies (period and potency being factors in the apportionment exercise)). It is argued that the apportionment exercise envisaged by Clause 8 is broadly similar to the apportionment of liability on account of contributory negligence or contribution among joint wrongdoers, where the focus is upon the degree of culpability involved in each of the causes of the Delay and the significance of each of the factors in causing the Delay albeit in practice culpability is likely to be the less important of these two factors. In essence, as clarified by Mr Lavy in oral Closing Submissions, TCS submits that Clause 8 is a contractual vehicle which gives a Court subject to English law the power to apportion delay, which exists under Scottish law (see City Inn Ltd v Shepherd Construction Ltd [2007] CSOH 190), but which does not otherwise exist under the English law (see Hamblen J, as he then was, in Adyard Abu Dhabi v SD Marine Services [2011] EWHC 848 (Comm)). Clause 8, therefore, is said to be there to recognise that, in a multi-faceted, multi-path project with things going on all the time, it may be necessary to have a way of being able to work out in a relatively broad brush way who is responsible for delays without having to do an impossibly fine grained analysis.

DBS argues that it is not open to TCS to raise a case based upon Clause 8. Mr Croall relies upon the fact that it has not been pleaded, no factual or expert witness has considered the question of apportionment, or advances a case based upon apportionment. Even putting this aside, Mr Croall argues that the parties have not fulfilled the pre-requisite to the clause, namely the obligation ‘to negotiate in good faith with a view to agreeing a fair and reasonable apportionment of responsibility for the Delay.’ It is said that the obligation to negotiate the issue of fair and reasonable apportionment was necessary to give rise to the entitlement to escalate the issue in accordance with Dispute Resolution which would, in turn, have given rise to an entitlement to refer the matter of apportionment to Expert Determination. None of this happened. Moreover, it is pointed out that the clause only operates to reduce sums which are otherwise recoverable by way of ‘Delay Payments’ and ‘compensation payable pursuant to clause 7.4’, and that therefore the clause would not in any event assist TCS by requiring some form of apportionment in circumstances where no sums are due to TCS because (for example) it has not established that it would have been able to Achieve the Milestone by its Milestone Date.

Finally, it is said that Clause 8 is a ‘true concurrency’ clause, which permits apportionment only where true concurrency exists. There is no claim by either party in this case that the correct delay analysis gives rise to true concurrency.

In my judgment:

Clause 52.2 deals with limits on the TCS’s aggregate liability. Clause 52.3 deals with DBS’s aggregate liability. Clause 52.4 deals with losses which neither side is liable to the other for. Clause 52.5 deals with what are considered to be direct losses recoverable by the Authority. These clauses are set out below:

The points of construction which arise are as follows:

DBS contends that the words “in respect of all other claims, losses or damages” appear at the end of a number of provisions addressing different types of liability and providing different limits for such claims; they must be read in that context. The contractual regime envisages a limit specific to each different claim. Moreover, the monetary limit is an alternative to a limit based on “the Charges paid under this Agreement during the 12 month period immediately preceding the date of the event giving rise to the claim under consideration”, which will be a different period for each claim depending upon the facts which give rise to that claim. It is said therefore that such language indicates that for each claim under consideration there is a separate limit defined by the charges over a separate period. DBS seeks to demonstrate this by an example, which it says is unanswerable and, indeed, unanswered by TCS. If TCS were right, then a claim made in 2014 would give rise to a cap based on the 12 month period preceding that claim. However, when a further claim is made the cap could no longer be based on the charges paid in the previous 12 months but by definition must relate to an earlier 12-month period when a previous claim was made. This cannot be right because it would involve an exercise which is directly contrary to the agreed regime. It also contends that the language “less the amounts previously paid” etc at the end of the sub-clause does not change the meaning of the language above.

TCS argues that the clause (and its equivalent at Clause 52.3.4) gives rise to a single cap, whose level is set by reference to the Charges due to be paid (or, for DBS’s counterclaim, paid) in the 12 months prior to the first event giving rise to the claim arising. This, it is said, is correct because: (i) both clauses define the party’s ‘total aggregate liability’ and not a per claim liability; (ii) in the case of cl. 52.2.6, the deduction of amounts previously paid strongly suggests an intent to provide for one cap rather than multiple caps; and (iii) a pair of cases (Royal Devon and Exeter NHS Foundation Trust v ATOS IT Services UK Ltd [2017] EWCA Civ 2196, and Drax Energy Solutions Ltd v Wipro Ltd [2023] EWHC 1342 (TCC)) have held a single cap to apply in relation to clauses with similar language.

Whilst, plainly, each contract will turn on its own wording, it is instructive to consider the two cases relied upon by TCS.

In Devon and Exeter, the relevant clause was as follows:

“9.2

The aggregate liability of the Contractor in accordance with sub-clause 8.1.2 paragraph (b) shall not exceed:

9.2.1

for any claim arising in the first 12 months of the term of the Contract, the Total Contract Price as set out in section 1.1; or

9.2.2

for claims arising after the first 12 months of the Contract, the total Contract Charges paid in the 12 months prior to the date of that claim.”

At first instance, O’Farrell J held that this provided for a single cap (rather than multiple caps or two caps) focussing principally upon the phrase ‘aggregate liability’, and the word ‘or’. On appeal, Jackson LJ agreed that the clause did not provide for multiple caps. O’Farrell J had rejected this (see [86]) on the basis that if there was a separate cap for each claim, the potential, very large, total cap would render the clause devoid of any real purpose. Jackson LJ disagreed, however, that the clause provided for a single cap, and found instead that it created two caps, not one. He rejected the contention that the phrase ‘aggregate liability’ was a pointer toward one cap rather than two. He said ‘It could equally well mean that the limit of liability is the aggregate of the sums set out in paragraphs 9.2.1 and 9.2.2.’ In the present case, the emphasis placed on the phrase has much more resonance because the words ‘total aggregate liability’ attached to, and are effectively repeated in relation to, each of the sub-paragraphs which follow (in contrast to the way clause 9.2 in the Devon and Exeter clause is drafted). Thus, Clause 52.2.6 should be read as: ‘the CONTRACTOR’s total aggregate liability…in respect of all other claims, losses or damages shall in no event exceed £10,000,000 ....or, if greater…etc’.

In Drax the central clause 33.2 (together with clause 33.3 which is also of some relevance) read:

Waksman J found that, despite some linguistic quirks, the correct interpretation of clause 33.2 was that there was a single cap and not separate caps for each claim. This meant that the clause was in effect construed to mean that the cap was 150% of the Charges paid or payable in the preceding twelve months from the date when ‘the first [of the various] claim[s] arose’ (see [58]). In terms of the language used, the Judge emphasised that this was supported by the phrase ‘total liability’ as well as the absence of the words like ‘for each claim’ after the word ‘liability’. It was also common ground that clause 33.3 imposed a single cap for all claims relating to a breach of clause 21, which used similar language in terms of ‘the claim first arose…’ Thus, in circumstances where there could be more than one claim, it was nevertheless accepted that there was a single cap for all claims. It can also be noted that the Judge, entirely understandably, considered that the clauses were not well drafted.

In the present case, the same is true: Clause 52.2.6 is far from a model of clarity. Nevertheless, the correct construction is that the clause gives rise to a single cap applicable to all claims, losses or damages for the following reasons:

The question arises what ‘less in all circumstances any amounts previously paid (as at the date of satisfaction of such liability) by the CONTRACTOR to the AUTHORITY in satisfaction of any liability under this Agreement’ means. These words are wide enough to include sums paid pursuant to the preceding sub-paragraphs. The effect of this is that the cap of £10m (or alternative) is the absolute cap, notwithstanding the existence of other claims. This is inconsistent with the opening words of Clause 52.2.6, which suggest that the cap relates to ‘other’ claims (i.e. other than those dealt with in the preceding sub-paragraphs). In my judgment, the words should be read to mean liability under the clause rather than the agreement. This is because the words at the start of the clause are a clear indication that Clause 52.2.6 is a cap which applies to matters other than those previously dealt with and if the intention had been that it was an over-riding cap, considerably simpler language would have been used to express that intention.

Finally, I note that in light of my findings on liability and quantum below, the question of whether one or multiple caps applies to DBS’s claims is academic.

TCS contends that the phrase ‘implementation Charges’ should be equated with the term ‘Modernization Release’. This is a reference to one of the Milestones found within the table following Clause 2.4.2. The Milestone does not describe itself as or makes no reference to ‘implementation Charges’. Whilst ‘implementation Charges’ is not a defined term, ‘Charges’ is. It is defined as ‘the rates and charges for the provision of Services ser out in, and derived in accordance with, Schedule 2-3 (The Charges and Charges Variation Procedure) including any Milestone Payment, Stage Payment, Service Charge or Non Volume Based Charges.’

I do not consider that it is possible to discern from the use of the word ‘implementation’ a clear or meaningful intention to identify a particular subset of the Charges. I reject the suggestion that, objectively, it was intended to refer solely and specifically to what TCS has identified as the Modernization Release. As such, TCS has not identified what figure should be utilised for the purposes of calculating a cap. In these circumstances, I accept DBS’s contention that no limit to Delay Payments has been identified.

In its Amended Particulars of Claim at paragraph 40, TCS sought a sum then quantified at £77,314,727 for ‘Loss of Revenue’. This was explained further at paragraphs 124 and 125 of the Further Information dated 31 March 2021:

As presented following expert evidence, TCS relies upon the FM found within the Contract to quantify TCS’s loss of anticipated savings, as a result of its claim that it was deprived of benefitting from the operational efficiencies of R1-D. TCS claims that the FM shows that the costs incurred by TCS in providing the Operational Services were projected to fall significantly over time, owing to the new processes enabled by R1 software. The claim is not articulated as one for, or is not in fact, a claim for wasted expenditure in the sense that specific costs which actually were incurred have been identified as costs which were ‘wasted’: the costs in fact incurred were required to comply with the ongoing contractual obligations. It is said, however, that but for the delays to R1-D, the predicted or anticipated efficiencies (within the FM) were not actually realised, thus creating a loss.

DBS claims that this is, in reality, a claim seeking compensation for reduced profit. It claims that, as such, the claim is (directly or indirectly) a claim for loss of profit and hence excluded by Clause 52.4.1. TCS contends that a claim for lost anticipated savings is not caught by the clause, and it is entitled to frame its claim to its advantage.

It was not disputed by TCS that the claim for loss of anticipated cost savings is a claim which could equally have been articulated as a claim for lost profits: if the savings had been made as it is alleged was anticipated, TCS’s profit would have been greater to an equivalent extent. Indeed, as DBS points out, the claim was first articulated as a claim for lost revenue. It is also not disputed that had the claim now pursued been framed in this way, it would be excluded by Clause 52.4. DBS says that the substance of the claim remains excluded by Clause 52.4, and its exclusion is not dependent upon how the claim is framed.

Both parties refer me to the recent judgment of Soteria Insurance Ltd v IBM United Kingdom Ltd [2022] EWCA Civ 440.

In that case, the exclusion clause excluded:

At first instance, O’Farrell J considered that the loss of the bargain suffered by the innocent party as a result of the repudiatory breach by the other comprised the savings, revenues and profits that would have been achieved had the intended IT solution been successfully implemented. She considered that a conventional claim for damages in this type of commercial case would usually be quantified based on those lost savings, revenues and profits, and that whilst the claiming party is entitled to frame its claim as one for wasted expenditure, that simply represents a different method of quantifying the loss of the bargain; it does not change the characteristics of the losses for which compensation is sought. As such, O’Farrell J concluded that the claim was excluded.

However, on appeal, Coulson LJ considered that a claim for wasted expenditure was not excluded. He identified at [40] that when a claimant claims damages in consequence of the other side's repudiation, there is a choice:

The Judge concluded, for a number of reasons, that wasted expenditure was not excluded by the clause. At paragraph 68 and following Coulson LJ provided the following reasons (amongst others):

The authority is not, of course, of direct application in that, first, the words of the relevant limitation of liability clause were different, and, second, in Soteria the focus was on whether the words of the clause caught a claim for expenditure actually incurred, but which was wasted, rather than lost anticipated savings.

Nevertheless, the case is an instructive reminder as to the correct starting point: the natural and ordinary meaning of the words. ‘Anticipated savings’ are not words which appear in Clause 52.4.

However, I need to construe Clause 52.4 as part of the surrounding provisions of Clause 52 and indeed the Agreement as a whole. Clause 52.4 applies to both parties. The immediately following Clause 52.5 applies only to the Authority. In this clause, the parties agree that DBS is entitled to claim ‘wasted expenditure’ and ‘anticipated savings’, expressly permitted as a direct head of loss recoverable. No equivalent clause exists for the Contractor’s benefit. This, DBS argues, supports a construction that, but for the clause, such losses would be irrecoverable pursuant to Clause 52.4. It might equally be said that the parties put their mind to the potential existence of a head of loss, namely, ‘anticipated savings’ and yet chose not to, and I do not regard this is determinative against TCS’s construction. This because it seems to me obvious that Clause 52.4 would not exclude any additional cost of procuring a replacement service, which is an ordinary head of direct loss recoverable in termination cases. In this regard, Clause 52.5.3 merely states what the legal position is, and would be with or without it, and it cannot be inferred therefore that losses included (perhaps on a belt and braces approach) would necessarily have been irrecoverable but for Clause 52.5.

However, Soteria is also instructive as to the distinction between the ‘speculative’ type losses such as a claim for loss of profits and a claim for actual costs which were expended (and which expenditure is proven by invoices, contracts and such documents) but wasted by reason of the termination. It was for this reason that Coulson LJ, at least in part, rejected O’Farrell’s construction which relied upon her conclusion that the substance of the claim made was the same as the substance of what was being excluded. In the present case, the ‘loss of anticipated savings’ is no more or less than a loss of profit claim, as Mr Cogley was more than happy to accept and, indeed, aver. He relied upon Soteria to advance the entitlement on the part of a particular claimant to articulate its claim how it saw fit, and if it was open to it to advance a claim in such a way that it was not caught by the words of a limitation clause, that was its entitlement and good fortune.

However, that was a mischaracterisation of Soteria. Coulson LJ was distinguishing between two very different substantive claims between which the innocent party to a termination must elect: it can either claim its loss of profits or, alternatively, its wasted expenditure. Then a distinction was drawn between potentially speculative and open-ended claims on the one hand (with which he associated claims for anticipated savings) and claims for actual, incurred, but wasted expenditure on the other. The former were regularly excluded by limitation clauses, and the latter were not regularly regarded as claims for consequential loss or excluded.

It is necessary to return to the words used, but against this background and in circumstances where it is, rightly, accepted that the claim for loss of anticipated savings is the same in substance to a claim for lost profits.

I consider that the correct construction is that a claim for loss of anticipated savings (which is in all but name a claim for loss of profits) is caught by the wording of Clause 52.4.

Compliance with Clause 5.3, Agreement and Estoppel

As set out above, Clause 5.1 requires TCS to notify DBS as soon as reasonably practicable of the fact of Delay or potential delay and summarise the reasons for it. TCS must then, pursuant to Clause 5.2, submit a draft Exception Report to DBS within 5 Working Days after the initial notification. Clause 5.3. sets out what the draft Exception Report must contain. Clause 5.6 makes compliance with Clauses 5.1, 5.2 and 5.3 a condition precedent to claiming compensation.

It is common ground that no draft Exception Report was served by TCS within 5 Working Days.

In its pleading, a number of arguments were raised including (a) prevention; (b) TCS did comply in that it did what was possible; (c) an implied term that compliance was not required where it was not practicable to comply and (d) an implied term that compliance was not required where DBS was aware of the matters it would address.

None of these arguments was advanced in TCS’s written or oral Closing Submissions. Insofar as necessary, had they been I would have found that these arguments were without merit. Briefly: (a) TCS was not in fact prevented from complying. Whilst TCS had limited information in respect of the consequences, it could have provided the information they had. Any difficulty in providing information may have been relevant to arguments about the adequacy of the draft Exception Report; (b) TCS did not comply with the timing obligation, as a matter of fact; (c) it was not impractical to comply (as per (a)), even if the implied term existed; and (d) the implied term alleged is neither necessary nor obvious.

In written and Closing submissions, TCS’s focus narrowed to two arguments, namely (a) there existed an express agreement to TCS’ request for an extension to the 5 day requirement (such that the condition precedent fell away); and/or (b) there was a shared and communicated common assumption on which TCS and DBS were proceeding that there was no requirement to serve an Exception Report within 5 Working Days in respect of the relevant delays, giving rise to an estoppel by convention or acquiescence or conduct.

DBS contend that there is no pleaded case based upon express agreement. DBS is correct. The only pleaded case is based upon what is alleged to be a shared and communicated common assumption arising in the circumstances at paragraph 20.5.6 of the Reply.

In any event, there is no evidence of the alleged express agreement. When asked to articulate precisely what the agreement was, Mr Cogley said it was, ‘We agree with your request’.

The request referred to was that set out in TCS’ letter of 25 July 2016, contained within its notice pursuant to Clause 5.1. This stated:

Colette Owen responded to this letter on 2 August 2016, which was beyond the 5 Working Days required by Clause 5.2. The email recited elements of TCS’s letter and then said:

TCS contends that looked at objectively, the response from Ms Owen is only consistent with her communicating DBS’s agreement to the request made by TCS. It is therefore said that this amended the 5 day period for the purposes of Clause 5.2 itself, which states:

“(or such other period as the AUTHORITY may permit and notify to the CONTRACTOR in writing)”

Ms Owen’s communication was not in my judgment a communication capable of satisfying these words of Clause 5.2 or constituting an unambiguous agreement to the request for permission to serve the exception report outside the stated 5 Working Days so as to constitute an agreement (or, indeed, an unambiguous waiver in writing for the purposes of Clause 62). Ms Owen engaged in the question of when information sought may be available, and did so in the context of the requested permission for an extension to serve the draft Exception Report, but the response was not sufficient to be a notification of some further period.

It is clear that TCS themselves did not read this communication as a formal agreement to their request for an extension. In the draft Exception Report which was eventually provided in March 2017, TCS wrote:

No other written communication is relied upon giving rise to an agreement. It may well be because of the difficulties of this argument that the point was not pleaded.

It is necessary therefore to consider TCS’s case on estoppel. To establish estoppel by convention, TCS must show the following:

The relevant common assumption is that there was no longer a requirement to serve an exception Report within 5 Working Days.

For the same reason that I reject the submission that the communication of 2 August 2016 could, of itself, objectively be construed as agreeing to TCS’ request for permission for an extension within which to serve the draft Exception Report, it is insufficient, taken alone, to be a communication of the alleged common assumption.

However, the case relating to common assumption relies upon all the conduct of the parties in the weeks and months that follow including the various negotiations between the parties in efforts to resolve their disputes commercially.

There were two relevant streams of communications between the parties following the exchange referred to above. The first was a joint exercise in replanning, which was a necessary exercise in its own right and also one which related (a) to the provision of an exception report by TCS and (b) to the second stream of communications which related to the commercial implications.

Mr Kuncheria of TCS, who was at the time Chief Accountable Officer for the DBS ‘Programme’, and whose evidence I accept in this regard as entirely credible, stated that at this time TCS’s and DBS’s focus remained on the re-planning of the Programme and that for both TCS, and to his mind DBS, the importance of this re-planning superseded the importance of the serving of the draft Exception Report when possible. This was borne out by the contemporaneous documents. By way of example, on 16 August 2016, the Commercial Forum Dashboard stated:

Re-planning related to both R1 B&B and R1-D, the former having a knock on effect to the latter. Mr Evans, of DBS, accepted in evidence that at this time once the plan was in place, everyone would be able to work out the impacts and there would be a commercial discussion. Mr Kuncheria said, which I accept:

I also accept the evidence of Mr Kuncheria that the information being provided to TCS from HPE (effectively through DBS) was a moving feast at this time. In cross-examination, he said, which I accept:

In parallel with the re-planning exercise, it is clear from the evidence that the parties were also in commercial negotiations in relation to the delays that had occurred, and that these were linked to the production of an Exception Report. On 19 September 2016, for example, Colette Owen, who was DBS’s Head of Commercial, advised the Commercial Forum (as reflected in the minutes) that exception and correction plans would be required to inform commercial negotiations. There was no suggestion that the Exception Report, if delivered, was out of time so that there was no entitlement to negotiate. Similarly, on 22 September 2016, Adele Downey of DBS, in an email to a number of senior DBS financial and commercial people involved in the project, provided a draft of her ‘script’ to be used in the negotiations with TCS. This included, ‘Delay cannot be attributable to a single party’ and ‘Reach a deal that costs no more than £11m or 5 months deferred ticket price reduction’ (i.e. financial compensation moving from DBS to TCS), and no suggestion, even as a negotiating strategy, that TCS had no entitlement because the Exception Report had not been provided within 5 Working Days in accordance with Clause 5.3 of the Agreement.

DBS argues that there was no assumption made by TCS that DBS would not rely on Clauses 5.1-5.3 as a condition precedent. I reject its submissions in this regard for the following reasons:

DBS also contends that it did not share or acquiesce in an assumption that it would not rely upon the terms of Clauses 5.1-5.3. This is not right. The following exchanges in evidence with senior DBS witnesses made clear that DBS was both prepared to extend time for the draft Exception Report (knowing that the 5 Working Days had passed) and, importantly, that DBS considered at a senior level that the 5 Working Day requirement had fallen away:

I find that DBS and TCS shared precisely the same assumption: both parties were working on the basis that the 5 day condition precedent had fallen away.

This is not a case of acquiescence by nothing more than silence. Contrary to the submissions of DBS, the evidence clearly shows that the entire landscape of discussions, which included the knock on effect to R1-D, between the parties was predicated on the basis that:

DBS had not reserved its position in any way. Moreover, through the actions of its senior commercial officers, DBS acted (entirely properly) in a manner consistent with the actual understanding of those officers that, in light of the exchange at the beginning of August 2016 and their own involvement in providing to TCS information required (from HPE), the 5 Working Day requirement had fallen by the wayside, even if there was no clear agreement replacing the period by some other defined date. In reliance on DBS’s conduct, TCS expended resources, committed to negotiating a commercial deal, and acted to its detriment further in that, as TCS submits, it was denied the opportunity to decide how it might respond faced with continuing and accruing costs that, contrary to its belief, DBS had no intention of paying because of a technical notice point.

Applying these facts to the test of estoppel, it is clear that the parties were subjectively in agreement. It is objectively obvious that TCS considered that it had had a de facto extension to provide the Exception Report, notwithstanding the absence of a formal response to their request, because of the way DBS was conducting itself in discussions and negotiations. It is also clear, on DBS’s own evidence, that it also considered that the 5 Working Day requirement had ‘fallen by the wayside’. It would have been obvious to DBS that TCS was engaging in the project in a way, to DBS’s benefit, that it may not have done faced with a denial of entitlement to compensation based on the 5 Working Day point. Insofar as it is necessary for me to do so, I also find in the specific circumstances known to the parties (and in particular as set out in (1) to (4) above), a reasonable person in TCS’s position would have expected DBS acting responsibly would have put TCS on notice that its position was that (without prejudice to the ongoing commercial negotiations) it considered that TCS had entirely forfeited its right to compensation for delay (see Ted Baker Plc v Axa Insurance UK Plc [2017] EWCA Civ 4097).

In these circumstances, DBS is now estopped from arguing that TCS has no entitlement to compensation for delay on account of its failure to comply with Clause 5.3.

The Parties’ Claims relating to Delay

The parties’ positions on delay to the R1 Project are polarised, and may broadly be summarised as follows:

Each party brings a financial claim arising out of the delays. TCS brings a claim for relief from liquidated and unliquidated damages, and its own claim for losses said to arise out of the delay, pursuant to Clause 7 of the Agreement. DBS brings its counterclaim for liquidated damages and unliquidated damages, pursuant to Clause 6 of the Agreement. TCS also contends that the Court can, should it need to, apportion responsibility for delay pursuant to Clause 8. DBS denies that Clause 8 is a pleaded issue, and (in any event) that the clause is relevant, or that any rights under the clause have been triggered in any event. I have dealt with the Clause 8 point, above.

Before considering the parties’ respective contentions as to the causes of delay, I set out the context in which the evidence sits following my determinations as to the meaning of the liability and delay related provisions I have set out above:

TCS’s claim for relief and for loss and expense is predicated on the basis that (a) the critical path ran through the infrastructure rather than software development, (b) that critical delay after Final SIT (System Integration Testing) 1 (i.e. from 6 June 2016) was all caused by infrastructure (and then in the last 3 weeks by DBS’s decision as to when it wished to go live), and that but for such delay, Go-Live could have been achieved as per the Baseline Plan subject only to 18 days of admitted delay (paragraph 30 of the Amended Particulars of Claim).

TCS contends that the planning evidence, looked at objectively, squarely points to infrastructure rather than software development being on the critical path. Mr Britton seeks to draw this conclusion from his analysis of the detailed contemporaneous programme plans in his first report and he draws the same analysis from what he calls his as-planned v as-built analysis in his second report. It is also pointed out by TCS that this conclusion is consistent with the contemporaneous view of the parties during the project, as seen through the plans which were produced at the time.

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.

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

Neither of Mr Britton’s two analyses are in my judgment reliable bases upon which the Court can conclude that the critical path ran through infrastructure throughout the majority of R1-B&B, or indeed what the particular durations and causes of critical delay were along that path (so as to assess whether they were causes which triggered an entitlement under Clause 7). Nor do they provide any basis for me to make a determination of the date by which TCS would have Achieved R1-B&B, having rejected, as I do, TCS’s pleaded case that there would have been no delay, save for 18 days.

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.

In light of the foregoing conclusion, it is not necessary to consider whether TCS has established that all of the delays to the infrastructure workstream were AUTHORITY Cause (on the assumption that it was critical throughout, which I have concluded has not been established). Nevertheless, for the sake of completeness I deal briefly with the three key elements of this part of TCS’s case.

Mr Britton identified 52 individual infrastructure delays, the majority of which are delays set out in Schedule 1 to TCS’s RFI Response dated 5 February 2021. Dr Hunt’s view as set out in her second report was that TCS bore sole responsibility for 5 of these, HPE bore sole responsibility for 10 of them, and that TCS and HPE shared responsibility for 18 of them. Of the rest, Dr Hunt’s view was that either there was no delay caused, because HPE responded within its published turnaround times, or that Dr Hunt was unable to reach a view as to responsibility. TCS submit that Dr Hunt’s view took insufficient account of the practical reality of trying to run a complex, multi-faceted IT project to a timetable.

Although in relation to some specific examples, Dr Hunt revisited her opinion and her conclusion that TCS was wholly or partly responsible, on the whole her evidence remained that to a very large degree delays, such as they were, could not be laid wholly at the door of HPE and that TCS’s own approach contributed to the lack of timely progress. I accept that evidence as a realistic technical analysis of the underlying evidence. A key element of Dr Hunt’s analysis involved consideration of the published timescales in which HPE would respond, a point which Mr Britton largely dismissed as relevant in light of his overarching point that the infrastructure development should have been based wholly on a cloud-based service with minimal turnaround times. This is an unrealistic argument, in light of TCS’s involvement in the procurement exercise which led to CCN 023 through which the move to HPE infrastructure was agreed (and in respect of which TCS were paid £8,044,788). CCN 023 stated:

“The Agreement was awarded on the basis that physical hosting of the CONTACTOR’s solution would be provided via an existing Home Office contract. Prior to contract award, the AUTHORITY was directed by Cabinet Office to market test virtual offerings from the Cloud.

This resulted in award of a contract for hosting to Skyscape. However, because of technical constraints later identified with the Skyscape solution, a further procurement was undertaken and the CONTRACTOR provided support to that procurement exercise to ensure its technical requirements were met.

Consequently, to ensure the deployment of a more resilient infrastructure in support of Release 1 (R1), the AUTHORITY awarded a contract to [HPE] on 29^th August 2014. This solution is a mix of physical and virtual, rather than pure physical, as envisaged by the Agreement.

[…]

The CONTRACTOR shall undertake its roles and responsibilities in relation to implementation and delivery of service management activities and operation of the technical interfaces required to enable hosting of the CONTRACTOR’s System on the Hosting Platform procured by the AUHTORITY from [HPE] in accordance with Application Management responsibility Matrix ver1 and Schedule 2-6 of the Agreement, as amended for the purposes of this CCN.

[…]

IT IS AGREED that with effect from the CCN Effective Date the Agreement shall be amended as set out in this CCN, and save as herein amended, all other terms and conditions of the Agreement inclusive of any previous CCNs shall remain in full force and effect.”

By this CCN, the proper construction of the Agreement is that the HPE infrastructure became part of the Authority System in respect of which TCS had obligations relating to integration under Clause 9.5 of the Agreement.

It these circumstances, Mr Britton’s generalised complaints stemming from the fact it was not a fully-cloud based infrastructure are unsustainable. This is not what TCS were entitled, contractually, to expect. I accept, in broad terms, Dr Hunt’s evidence that, in large part either ‘delays’ were caused by a combination of responsibility or were not true ‘delays’ at all, because they were a reflection of the timescales embedded within the HPE ‘system’, however cumbersome that turned out to be in practice. It is not necessary to analyse each of Mr Britton’s 52 delays item by item, in circumstances where it is clear, on the basis of Dr Hunt’s analysis, that TCS’s own contribution or responsibility for some of the delays which occurred on the infrastructure workstream is sufficient to dispose of TCS’s primary case that all delays on the infrastructure workstream were HPE’s responsibility.

Moreover, for the reasons set out within the contractual analysis above, I have rejected the contention that a delay caused by HPE is, of itself, an ‘AUTHORITY Cause’. It may well be that particular identifiable delays could qualify as ‘AUTHORITY Cause’ if they arose out of a specific failure or failures on the part of HPE to have provided something which DBS was itself contractually responsible for providing to TCS, but the complaints made do not arise out of the pleaded express breaches (Clauses 15.4 and 15.6 of Schedule 2-6). The generalised and unspecific case advanced by TCS, which does not properly tie the complaints made to an express obligation which has been breached by DBS, cannot succeed on liability.

Finally, for the reasons set out in my consideration of Clause 8, it is not open to the Court generally to ‘apportion’ responsibility for delay where, as I find, delays were caused (at least to some material degree) by a combination of TCS and HPE (and assuming that the latter amounted to ‘AUTHORITY Cause’). Even if it were permissible, it is simply not on the material provided, as a matter of fact, possible to carry out such an exercise reliably. No such analysis was pleaded, or advanced by way of expert analysis. There may be many ways of undertaking such an apportionment, and it was not open to TCS to introduce a suggested apportionment methodology in its Closing Submissions for the first time.

In the circumstances, TCS’s claim for relief and/or damages arising out of delays to R1-B&B fails. In principle, DBS would have been entitled to Delay Damages but for its failures to have complied with the provisions of Clause 6. The extent to which it is entitled to damages pursuant to Clause 6.3.2 is considered further below.

It its Closing Submissions, TCS deals first with the suggestion advanced in Oral Opening by DBS that its pleaded claim, for Delay Damages calculated from 28 November 2017 to 19 September 2018, the date of Partial Termination (295 days @ £10,000 per day giving rise to a claim for £2,950,000) was a mistake and that it should be entitled to Delay Damages from November 2016.

DBS’s pleading had expressly averred that [paragraphs 65 and 70]:

This was effectively repeated within DBS’s Written Opening. DBS’s Quantum had been calculated, and assessed by its expert, Mr Hain, in his First Report, to value the claim for general damages calculated from 28 November 2017 by reference to the pleadings.

The underlying documents do, indeed, suggest that the date required following the 2015 revision (linked to CCN041) for R1-Dwas 28 November 2016 rather than 2017 (e.g. the Board presentation referred to at F/626 referred to at footnote 16 of DBS’s Written Opening, TCS’s draft Exception Report dated 21 November 2016).

DBS did not seek to amend its pleadings, and in its Written Closing Submissions expressly maintained its claim for Delay Damages calculated as 295 days from 28 November 2017 to the date of alleged Partial Termination. It did so, curiously, on the basis that Delay Damages were claimed from one year from the ‘Revised Go-Live Date of 28 November 2016’. No explanation was given as to the basis for claiming Delay Damages from a year beyond the 2016 date – e.g. whether the date had gone back by further agreement, or that DBS were unilaterally waiving its entitlement or otherwise. One possible explanation is found, again curiously, in Mr Hain’s Second Report in which he notes the difference between November 2016 (referred to by Mrs Wall, TCS’s forensic accountant) and his use of November 2017, which traces back to the pleadings. He then comments: ‘I am instructed that between 29 June 2016 and 19 December 2016, DBS agreed that TCS would focus on Barring and Basics, with Disclosure to be delivered afterwards. DBS's claim is on the basis of an envisaged Go-Live date of 28 November 2017.’ This would suggest that DBS considered that a year’s slippage was agreed in respect of R1-D.

The case advanced by DBS in its Written Closing Submissions (but not pleaded or opened), however, still asserted that TCS were required to establish a claim for relief from 28 November 2016 to 28 November 2017 in order to obtain relief from Delay Damages, even though damages were only claimed from 28 November 2017.

This does not work. DBS’s claim (pleaded, opened and closed) is for Delay Damages calculated for a period of 295 days starting 28 November 2017. TCS does not need to seek relief in respect of a claim which has not been brought against it.

Clearly, notwithstanding the relevant period for the purposes of obtaining relief, to the extent TCS advances a claim for delay losses, it would have to establish its entitlement for the whole period.

DBS did not serve any Non-conformance Report in respect of delays to R1-D. It was not therefore entitled to exercise the options in Clause 6.2, including the levying of Delay Damages. It remains entitled to general damages pursuant to Clause 6.3 if it can establish in excess of 6 months’ delay, and, of course, relevant causation and loss.

TCS did not serve an Exception Report in respect of any delays specific to R1-D. This is a point taken against TCS by DBS on the pleadings in respect of delays caused after September 2018 by the purported Partial Termination, and TCS’s Reply refers back to the same defences in relation to the service of the Exception Report as have been considered in respect of R1-B&B above. No attention was given by the parties at trial to the question of compliance with notice provisions specific to R1-D. The notice given on 25 July 2016 and the subsequent draft Exception Report deals both with delays to the R1 programme as a whole (R1-B&B plus R1-D). DBS did not seek to develop any argument that, even if it was (as is the case) estopped from asserting that TCS was unable to claim relief because of its failure to serve an exception report within 5 days of 25 July 2016, fresh notices were required later in the project if, for example, new delays accrued due to reasons not covered in earlier correspondence. Moreover, I do not consider in circumstances where (as I find further below) TCS’s default was the wrongful removal of scope, it was necessary to serve an Exception Report relating to ‘Delay’. The contractual definition of Delay is not apposite to the non-delivery of part of the scope because of its unlawful removal. Its delivery had not been ‘delayed’ in both the normal and contractual sense of the word, it had simply been removed. For these reasons, I consider TCS is not prevented from advancing any claim for financial losses for delay and/or unlawful removal of scope by reason of a lack of notice.

TCS’s pleaded case is that, notwithstanding the delay in relation to R1-B&B, by 7 September 2017, when R1-B&B went live, TCS had designed the R1-D part of the Solution and had developed it to the extent that it was ready for Final Systems Integration Testing. It contends that, in the event, however, Final SIT could not proceed in September 2017 or at all owing to DBS’s persistent failure between September 2017 and September 2018 (the date R1-D was de-scoped) to make critical decisions and/or to complete activities that were its responsibility (the specifics of which are considered below) and without which Final SIT could not proceed.

DBS plead that as at September 2017, the R1 Disclosure part of the Solution was not ready for Final Systems Integration Testing. Further, the parties had anticipated that a period of 12 months would be required to integrate and test R1 Disclosure. ‘The November 2017 deadline for delivery of R1 Disclosure’ was therefore unachievable even if Final SIT could have been commenced in September 2017.

TCS contend that the overall period can be divided into two parts.

This is not a period for which there is any claim for Delay Damages (irrespective of issues such as notice or relief).

The first part is the period up to August 2017, during which period TCS contends that it suffered knock on effects of the delays to R1 B&B. This is not relevant to the issue of relief, as set out above, but it is relevant to TCS’s claim for financial compensation.

In terms of critical path, Mr Jardine’s evidence is that from June 2017 to June 2018, the critical path ran through the work required to start Final SIT 1. This included RFC 489, RFC 417 and 2 Code Drop Works. Mr Britton’s first report contended that the critical path during this period ran through external dependencies. Both experts’ analyses were relatively high level given the nature of the material available for R1-D. For most of the project through to Go-Live of R1-B&B, the planning focus was generally on R1-B&B, as confirmed by Mr Martin of TCS in cross examination. I also take account of Mr Britton’s evidence that the R1 Disclosure plans should be treated with caution and that a reliable delay analysis was difficult to undertake. Moreover, the systemic issues with carrying out a prospective analysis considered in the context of R1-B&B apply equally to this part of case.

I accept Mr Jardine’s view within his Window 3, which was supported by the evidence of Dr Hunt, that the critical path was effectively through the progress of the R1-B&B testing which would allow the release of the SIT Large environment.

R1-D exited SIT on 10 June 2017. There were no Sev1 (i.e. highest level of severity) defects, but there were 5 Sev2 defects. Notwithstanding these, as Dr Hunt agreed in evidence, and I find, that the SIT Large environment (the R1 test environment and stage of testing used for Component Integration testing for Interfaces, System Integration testing with Live interfaces to third parties, and Data Migration Testing, sometimes referred to as SIT-L) was being used until August 2017 for R1-B&B, and for this reason was unavailable for R1-D until then.

For the reasons set out above, TCS has not established an entitlement to either relief from Delay Damages (insofar as relevant) or from a damages claim, or its own right to claim losses, for the delays caused to R1-B&B. To the extent that the driving cause of delay at this time was these preceding delays, as TCS themselves allege, this is a period for which TCS has similarly failed to establish the relevant entitlements.

Once this dependency had been overcome, it is TCS’s case that the project could have proceeded but for two fundamental difficulties, both of which it claims are ‘Authority Cause’:

DBS’s essential point in answer to these allegations is that a failure to agree changes to the scope of work cannot amount to ‘Authority Cause’ or to a delay event. TCS is required to build in accordance with the scope set out in the Agreement unless and until it is varied by a CCN. If TCS decided not to do so in the anticipation that a change to scope of work may occur in the future, that was at TCS’s own risk.

I will first set out the relevant facts as I find them to be in relation to the period from September 2017 up to the alleged Partial Termination/de-scoping, and then turn to consider the analyses of liability and causation.

Taking stock at September 2017, as identified by Dr Hunt, the key requirements for entry into Final SIT were (1) availability of SIT-L with connectivity to support the R1 Disclosure interfaces (2) availability of all technical architecture unless otherwise agreed (3) completion of CIT/SIT on any further required software drops, including resolution of all Severity 1 & 2 defects, unless agreed with DBS and (4) availability of test plans, test data and test scripts. Dr Hunt confirmed that she had seen no evidence that TCS would have had any issue with the test plans, data and scripts, so (4) was not an issue.

As regards the availability of SIT-L with connectivity to support the R1-D interfaces, as already identified, the initial period of unavailability is linked to its being used for R1-B&B. However, thereafter, there remained third party dependencies. As set out in TCS’s email dated 5 October 2017, at this point there were 18 Disclosure Interfaces with connectivity not yet verified. Dr Hunt accepted that the third party dependencies (for which DBS was responsible) required to be resolved prior to commencing Final SIT and that there were still dependencies outstanding as at February 2018.

In terms of availability of all technical architecture unless otherwise agreed, the areas of dispute concerned RFC 489, R1 Add-Ons services Security Functions, and RFC 417, and Content Inspection. It seemed to be common ground between the IT experts that, as Dr Hunt explicitly accepted and I find, neither of these were required to start Final SIT (although they would have been required to complete it), and so these are not reasons why Final SIT could not have been commenced, if SIT-L with connectivity to support the R1 Disclosure interfaces had been available.

In relation to the Sev2 defects which existed post exit from SIT, these were not being treated with any particular urgency. This is no doubt because, as Dr Hunt also fairly accepted, the Sev2 defects were not going to be ‘showstoppers’ and could have been resolved once TCS had got into Final SIT 2. They would not therefore have prevented the commencement of Final SIT once the environment was available.

Against this background, I accept the factual evidence from Mr Padannayi that, had there not been various other issues considered in more detail below, during this time, TCS would have, as they plead, been ready to enter Final SIT in around September 2017. When cross-examined about a TCS internal email dated 4^th May 2018 that as of that date ‘The software is not ready to start Final SIT’, he explained, and I accept:

However, it follows from this that, for the purposes of the Clause 7 analysis, TCS were never going to achieve the R1-D Milestone until between July and September 2018, if one assumes a period of around 9-12 months from Final SIT to Go-Live. (9 months is not an unreasonable planned period: for example, the 4 October 2017 Microsoft update plan showed a period of 9 months from the start of Final SIT to Go-Live; the 12 December 2017; the February 2018 POAP showed a duration for this period 8.5 months; Dr Hunt’s evidence referred to further below suggests 12 months).

As at the start of September 2017, TCS sought two RBs to test the e-bulk system and the web services solution for SIT. By email dated 6 September 2017, DBS indicated that they were not in a position to provide these. Mr Brown of DBS stated that he considered it necessary to be realistic about the timelines, and that DBS was working on the assumption that e-RBs needed at least 6 months to make system changes to their front end systems. Mr Rowlands of DBS indicated, as part of the same e-mail exchange, the scale of the challenge facing DBS’ roll-out of R1 to RBs:

By mid-September, Mr Padannayi, internally, was recording the existence of a number of risks relating to the progression of R1-D SIT. In his email of 19 September 2017, risk 8 was:

As recorded in the DBS Business Change Review Board Summary, attended by a number of senior DBS witnesses who gave evidence, ‘Must Have’ was a term stemming from use of a basic MoSCoW prioritisation technique. It meant a ‘requirement is defined as making the solution unlawful, unviable or unsafe without this requirement’. Ms Owen, Head of Commercial for DBS, fairly accepted that this was so in terms, at Day 11/143.

At the same time, there were 52 outstanding issues which had not been delivered by TCS with R1-B&B and therefore were to be delivered as part of R1-D. These were referred to as ‘deferred items’.

On 22 September 2017, Mr Kuncheria of TCS sent the following message to Mr Narayanan:

Mr Narayanan responded on the same day:

TCS’s position was being communicated to DBS. On 18 October 2017, the DBS Project Board ‘PB’) minuted that, ‘TCS has advised [Mr Evans of DBS] that they need to know the totality of the build before they move to final SIT. Scope will need to include deferred items, changes as a result of GDPR and known ‘post-R1 RFCS’.

Reflecting the earlier indication from DBS referred to above to Mr Padannayi recorded on 19 September 2017, there were likely to be a number of issues affecting the potential scope of R1-D that were seen as ‘Must Have’, and which needed to be resolved, in addition to the deferred items. For example, in relation to ‘eBulk’, the PB identified issues around the conclusion of the ATOS contract, which ran out in July 2018. The PB would need to decide how long eBulk was extended for. Having identified various factors, the minutes record that “all of this will need to be documented in the data migration strategy. Potential for eBulk to run from R0 and webservice from R1 but will depend on both technical limitations and stakeholder (e-RB) consultation.”

Another important issue was GDPR, which was coming into effect in May 2018, and which would affect the legality of the solution. The PB were informed that there was a DBS working group in place to look at what work was required with the product plan in place to implement this. Issues were identified around eBulk and citizen consent, and the fact that an RB would get results at the same time as the user which will not be compliant under GDPR. The minutes concluded on this topic that the full impact of GDPR was not understood as yet as it covered consent from data subject, what data was wanted, why it was wanted, realistic timescales for holding the data and communication channels that would be used.

Mr Evans of DBS, in a lengthy and slightly confused passage of cross-examination at [Day 11 /87-96] accepted, fairly, that DBS did not challenge the suggestion that the totality of scope needed to be determined before moving to Final SIT. He also accepted that there were ‘Must Have’ RFCs which formed part of what DBS considered to be the minimum viable product, and that if those Must Have RfCs were not agreed there would be no viable product.

In light of these and other issues, under ‘Delivery Confidence’, disclosure delivery moved to ‘amber/red’, recording that comments for the (now pessimistic) Disclosure ‘rating’ as follows:

The inability to divorce delivery from commercials was inherent in the existence of ‘Must Haves’ required by DBS as part of the solution that needed to be agreed according to the Change Control Procedure in order for what DBS considered (and may objectively have been the case) a viable product to be delivered.

The logic of progression to Final SIT being necessarily linked to scope clarification was also reflected in the evidence of Dr Hunt, which I accept in this regard (Day 22/191):

The PB concluded that it was ‘not within sight of a date for disclosure delivery’. The thrust of the minutes, as I find them to be, is that this uncertainty was due principally to difficulties in identifying the ultimate scope in respect of matters which would constitute changes to the way in which TCS was then contracted to provide R1-D. In light of the fact that there were ‘Must Have’ changes, and that those changes would have to be specified through RFCs and their commercial implications negotiated and agreed, the comment that commercials and delivery could not be completely divorced was recognition of the practical reality, notwithstanding the existence of a contractual obligation upon TCS to continue to build to contractual scope unless an RFC was in place. For example, if ‘the transition for RBs cannot take a big bang approach’ was DBS’s position, there was no purpose for either party in TCS continuing to produce that solution. Similarly, continuing work on a solution which would not be complaint with GDPR would obviously be pointless and wasteful for both parties.

On 6 December 2017, DBS presented ‘DBS Challenges with respect to Disclosure R1’ and asked TCS to consider the challenges and provide solutions. Two of those challenges related to transition of RBs from R0 to R1. Mr Topham of DBS (at the time, Chief Information and Digital Officer) confirmed in cross-examination that it was this presentation that led to the issue of RFC 607. He also gave evidence that his understanding was that the genesis of RFC 607 was the lessons learned from Basics deployment, which was that a big bang deployment of all the RBs would be ‘impossible to manage and detrimental to the business’.

On 25 January 2018, DBS’s presentation to the Home Office entitled ‘DBS-TCS Extension’ by Adele Downey, the CEO, sought approval in principle to re-negotiate the contract with TCS. This was known as ‘Plan A’. In terms of Disclosure Release, the document recorded:

In seeking an extension of the TCS contract, one of the reasons given to justify why Plan A was favourable was that it “allows the time required for a phased transition in line with DBS strategy”. It also described the purpose of renegotiation was amongst other things to “support a seamless transition of services and avoidance of ‘big bang’ migrations”. The presentation continued, ‘In order to further de-risk the programme, elements of delivery will be modified from existing TCS contractual scope, including data migration and eRB transition’.

This presentation contained a number of entirely redacted slides (pages 17-23). It is not clear to me why these redactions were made (or, indeed, not challenged). Nevertheless, by reference to the Contents slide setting out the ‘aims’ of the meeting, a reasonable inference is that these slides outlined ‘Plan B’ and ‘Plan C’ contingencies. From Barry Topham’s later presentation ‘Commercial & Delivery Options’ (dated 27 April 2018), it can be seen that Plan B involved TCS Disclosure ceasing delivery, but with a one year extension to allow for transition between a change of suppliers, with Disclosure being provided by another partner. It appears from the presentation that Plans A and B were initially considered as early as October 2017. The same slide identified that the approach agreed in January 2018 had been to make a final decision at the end of February and divert all R1 resources onto plan B if necessary at that point.

With a view to advancing Plan A, RFC 607 was issued on 8 February 2018. It was marked ‘Change Priority: High’ which meant that it was “important for DBS and must be implemented soon enough to prevent a significant negative impact to our ability to conduct business”. The RFC requested TCS “to identify solutions to enable a smooth transition for RB’s moving from the R0 system to R1, for both e-bulk and web submissions”. It further stated:

Dr Hunt’s evidence in relation to RFC607 in her Reply Report stated:

However, Dr Hunt fairly conceded in cross-examination that her understanding of TCS’s intention to include a bridge was wrong and that she may have got the timeline confused. As set out below, her conclusion that the inability to agree the commercial implications of RFC607 and related ‘Must Have’ RFCs did not affect TCS’s ability to enter Final SIT, in at least practical if not purely technical terms, is not supported by the factual evidence.

Mr Padannayi’s evidence, which I accept, was that:

On the same date that RFC 607 was issued, Adele Downey wrote to Mr Shankar Narayanan (TCS’s Head of UK and Ireland) and Mr McCarthy (TCS’s then Commercial Director) stating:

This email therefore recorded an agreement that the parties would enter discussions to consider the scope related matters pertaining to R1-D, which, in particular, would include RB migration. In light of the acknowledgement that the commercials had thwarted progress to date, this email in context confirmed the ‘status quo’ understood by both parties, namely there was a pressing requirement to resolve scope as part of R1-D deployment.

Reflecting this, the following was then reported by Ms Downey to the DBS team, described as ‘an agreed statement for Shankar and I’:

“Following the productive joint meetings that have taken place between colleagues in India and in the UK, we have reached joint agreement in principle for the Disclosure re-planning exercise, subject to validation of one commercial matter to be concluded by close on Monday 12 February. Both teams are therefore commissioned to conduct a joint re-planning exercise that will result in a Disclosure delivery date and broad cost proposals for agreed changes to scope. This is to be agreed by 23rd February to form part of the formal negotiations that will take place week of 26 February.”

It is to be noted that the agreement related to the ‘re-planning exercise’, there being no suggestion that TCS was, or could be, continuing with R1-D Final SIT until the scope of R1-D was known and agreed. There was no evidence about the ‘one commercial matter to be concluded by close on Monday 12 February’, and nothing was provided to suggest that this attempt to reach commercial agreement on scope floundered within days. The evidence demonstrated that it continued at a project level (through workshops) and a commercial level for some time.

No doubt as part of the pressure to resolve scope issues, it was around this time that it appears that DBS started to engage with RBs. On 14 February 2018, a conference call took place with a number of RBs to begin ‘early engagement on the transition options’. This presented options of parallel running, big bang and ‘transition period’ (effectively what became known as Option 4). Feedback from the e-RBs was reported as being that more time would be required to assess the available options, and that a minimum of 6 months lead in time from the publication of the final version of the specifications would be required. Clearly, on this basis, in circumstances where the specification was in flux due to DBS’s concerns around the migration strategy (and the feasibility of the solution TCS had contracted to provide), delivery was still a long way off. Indeed, Mr Fritton of DBS advised the e-RBs that ‘no confirmed date for R1 (standard/enhanced) exists currently, although the aim is to delivery within 12 months’ (i.e. February 2019).

Alongside RFC 607, the Business Change Review Board on 16 February had been convened by DBS to give ‘urgent consideration of must have RfCs for R1 Disclosure go-live being given highest priority to enable planning to take place…..’. In light of the essential nature of Must Have RFCs to the viability of the R1-D solution, it is entirely unsurprising that DBS knew well that resolution of those RFCs as part of the overall scope was a necessary part of project planning (and, of course, in due course development and testing). The meeting identified 23 outstanding RFCs which were ‘Must Have’ RFCs that had to be delivered for R1-D Go-Live. Some of the ‘Must Have’s were nevertheless recorded as ‘To remain on hold’ with the BCRB deciding (for example, in relation to RFCs 567 and 576) that notwithstanding their ‘Must Have’ status, ‘the RfC is on hold and is not to be sent to TCS yet’.

On 26 February 2018, TCS presented a number of options under RFC 607, Option 4 being recorded as DBS’s preferred option, which was for a ‘bridge’ to be developed to allow RBs to make submissions using either R0 or R1 data formats before and after Go-Live of R1-D. The final slide set out assumptions about the commercial implications of the change:

In essence, this was required to enable R1 to be delivered in a staggered migration rather than a ‘big bang’, in line with DBS’s own concerns and strategy. TCS’s POAP of the same date based upon the implementation of Option 4 showed that the submission of RFCs by DBS was part of the anticipated timelines, forming part of the critical path through Code Drop 2 to Final SIT and beyond to Go-Live on 16 July 2019:

Mr Evans, of DBS, agreed in cross-examination, and I accept, that their inclusion within the POAPs indicated that the RFCs were regarded by the parties as key. In cross-examination, Mr Evans gave the following evidence (Day 11/121):

Numerous workshops were required between the parties in order to finalise the scope. In parallel with the discussions between DBS and TCS to agree the scope of R1-D, with associated commercials, DBS was, perhaps not unsurprisingly, planning for the eventuality that a commercial agreement could not be reached and as such, ‘Plan A’ would prove unachievable. DBS was reporting internally (in the presentation by Mr Topham dated 2 March 2018) that in delivering plan B with a new supplier, DBS would be effectively starting the R1-D delivery from scratch with any Design and Build work undertaken by TCS being rendered as nugatory. It indicated that there would be a substantial cost to maintain R0 until the R1-Dwas delivered by the new supplier. The procurement process/contract review period for the new supplier was anticipated to be starting in Q2 2018 (i.e. imminently).

As at 20 March 2018, TCS reported (at slide 2) to DBS on the ongoing workshop process to agree the new scope. TCS indicated that 14 High Level Scope Items needed to be clarified, which needed 35 workshops with various DBS teams and 20 workshops with various TCS teams. Approximately 400 Test Cases were estimated to be added to Final SIT scope due to RFCs. At slide 4 of TCS’s presentation, it indicated that the reasons TCS could not start Final SIT were RFCs, GDPR, External Stakeholder Readiness, SPS changes because of GDPR and RFCs (SPS was a key sub-contractor to TCS providing physical document handling services), Data Migration Strategy and External Interface Connectivity. The presentation then detailed for each of these categories a series of issues and what needed to be resolved by the DBS, third parties, or the parties together. For example, it was for DBS to confirm the number of Templates to be changed due to GDPR; and DBS needed to engage with the Friendly RBs.

There was a discussion of the programme between DBS and TCS at a Programme Board meeting on 27 March 2018. In the section of the meeting attended by DBS alone, Mr Evans gave the R1 Programme update which was reported as follows:

It is clear that both DBS and TCS were proceeding at this time on the joint understanding that without commercial agreement on the ‘Must Have’s R1-D was not viable, at least not as envisaged in the original TCS specification. I accept the evidence of Mr Padannayi, consistent with this conclusion, that RFC 607 was fundamental to the whole approach at this time, and its significant ramifications needed to be understood and agreed before TCS could proceed. This was also the effect of Mr Topham’s evidence, which I accept in this regard (Day 9/66):

By 25 April 2018, however, DBS had informed TCS that RFC 607 was not going to proceed. It indicated to TCS the reason as follows:

I accept TCS’s submission that this reason was essentially bogus. DBS clearly remained of the view that a ‘big bang’ transition was practically unworkable. There is no evidence that their engagement with RBs on the issue, which had started very late, and which by this stage was extremely limited had led them to alter their own view expressed in October 2018 that, ‘The transition for RBs cannot take a big bang approach’. This is unsurprising, in light of the technical view of Dr Hunt, which I accept, that ‘moving all 170 e-RBS from one interface to another simultaneously would always have been very challenging, if not impossible, to achieve’. Nor is there any evidence that DBS’s internal planning at this stage or in the months to come was at any stage predicated on any scenario which adopted a ‘big bang’ approach to data migration and transition. This letter was, instead, the beginning of the end of negotiations to produce a solution by which TCS would be able to deliver the R1-D which DBS knew it needed for its own reasons.

This strategy was reflected in the ‘Commercial and Delivery Options’ presentation by Mr Topham dated 2 days later. One slide set out what, ‘DBS Wants and Needs from Disaggregation’. This outlined the benefits from the DBS strategy of moving away from a single supplier like TCS. The key ‘changes in approach’ included:

It is also fair to identify that within this presentation, DBS presented considerable dissatisfaction with TCS delivery in relation to Barring and Basics, and that it may well be that that dissatisfaction fed into the decision which was effectively made around this time to bring TCS delivery of R1-D to an end. In my judgment, the degree of dissatisfaction, at least insofar as it could legitimately have been directed at TCS, is overstated. In terms of delays to R1-B&B, I have already concluded that TCS is not entitled to relief in light of its inability to have satisfied the contractual requirements of Clause 7. This does not mean that (notwithstanding the contractual risk allocation) it did not face considerable difficulties caused in reality by HPE’s infrastructure issues which were outside its direct control. In terms of the defects in R1 delivery, as set out in the relevant section below, I consider that whilst there is some justification in relation to some of the difficulties encountered, there are also a number of user-interface issues which are not the responsibility of TCS, and the significant performance and reliability related issues encountered after Go-Live (Snowbound aside) were predominantly caused, also, by infrastructure.

On 4 May 2018, TCS set out internally the reasons why at that stage TCS did not consider that it was possible to deliver R1-D by March 2019. I have already set out Mr Padannayi’s evidence in respect of the first reason, above. The other items in the email included:

It is clear from this email that, as DBS submits, it was technically possible at this stage for TCS to produce its Interface Control Document updated with matters which were within TCS’s control to update. However, it is equally clear that this would not be a final ICD until the GPDR issue was resolved. The evidence set out above demonstrated that the RBs had said clearly that a minimum of 6 months lead in time from the publication of the final version of the specifications would be required. The production of a non-final version would not have, in my judgment, advanced matters and was not causing any delay in the engagement of ‘the major dependency’. There is no contemporaneous evidence that the non-production of a non-final ICD was either causing actual delay nor delaying engagement with RBs.

On 22 May 2022, Mr Topham and Mr Whiting of DBS produced their commercial update paper recommending that the Board endorse the approach of discontinuing R1-D delivery with TCS and exit the contract as soon as reasonably practicable. This was referred to as ‘Plan D’. The paper reported that the cost of this option (Plan D) had been assessed at £231.7m versus a revised Plan A (i.e. to have continued with TCS, deliver disclosure on an extension of up to 3 years) cost of £276.5m for the period 2017-18 to 2021-22. The revised cost was broken down into BAU expenditure of £123.3m and additional expenditure of £108.4m including optimism bias of £24m.

On 31 May 2018, TCS responded to DBS’s letter of 25 April 2018, relating to RFC 607. The letter stated, having set out a short history of the matter:

Contrary to DBS’s submission that this reflected TCS (implicitly unjustifiable) ‘digging in’, in my judgment this letter reflected a generally accurate picture that the whole impetus for the move away from a (contractually specified) single migration was DBS’s initiative, with which TCS provided its co-operation. Indeed, this fact was accepted fairly by Mr Topham in evidence (Day 9, p35):

DBS’s submission, however, that this letter is a reflection of the fact that by this stage at the latest negotiation over the scope of R1-D had broken down is accurate. TCS concluded its letter by requiring that DBS ‘Finalise and communicate to TCS the final approach of data migration, including any agreement of any outstanding options’ by 6 June 2018.

This did not happen. On 13 June 2018, an instruction was given within TCS to cease work on R1-D. I accept that this was because TCS were not receiving the inputs they required from DBS, as explained by Mr Kuncheria in evidence when questioned about this evidence (Day3/106):

On the same date, the Options paper from Mr Topham and Mr Whiting was sent to the Home Office for approval. A further summary position paper was sent on 22 June 2018 which made clear that DBS's initial evaluation supported a preferred option of not building a new R1-D product; instead a new provider would take over the existing R1 system as it was (Basics and Barring) together with the current R0 (Disclosure). DBS sought official approval. The report emphasised what it saw as TCS’s failures in relation to R1-B&B delivery, and in relation to data migration stated that, ‘Levels of programme and technical complexity have increased and TCS's original proposal for data migration and registered body transition were flawed and the impact would have been catastrophic for DBS. DBS insistence following the difficulties experienced in the Basics transition led to TCS reconsidering their approach.’ This does not, in my judgment, fairly characterise the development of the change in approach to transition, with DBS (no doubt for reasons of internal pressure) seeking to place responsibility for the move away from ‘big bang’ on a flaw in the proposed technical solution, rather than its own views as to the ability of RBs to be ready for such an approach and the effect of RB unreadiness and/or lack of capability at a single unified time on the viability of continued provision of disclosure services. DBS were fully aware of the delays to the delivery of R1-D caused by the preceding period of flux in its attempts to institute Plan A and then Plan B, and noted at 3.6 that (in light of these delays) ‘Investment in the R0 legacy systems was always going to be a requirement’. It also noted a non-financial benefit to the preferred approach that it would enable greater focus on Disclosure improvements for the business as management attention was not on delivering a full new Disclosure solution. The paper also set out the perceived savings of the preferred approach against ‘the current product price’.

The Board’s conclusions were as follows:

The proposed timeline took negotiations through to the end of September 2018 at the latest whilst approval for the approach was obtained.

Positioning correspondence continued between the parties about the origins of the implementation of phased transition and TCS’s development of R1-D. On 28 June 2018, TCS recorded in correspondence, in my judgment accurately:

DBS wrote to TCS on 9 July and 17 August 2018. These were letters which were in due course relied upon by DBS in its purported Partial Termination of the contract (i.e. what was to be the descoping of R1-D).

The 9 July 2018 letter (from DBS’s solicitors) dealt the ‘data breach’ incidents, and performance and efficiency issues with R1-B&B. Paragraph 4.3 stated that the facts previously set out were ‘material Defaults’, specifically:

DBS therefore required TCS to comply with a Remedial Plan process in accordance with Clause 56.2.1 of the Agreement. The only reference to R1-D in the letter was at paragraph 5.8 which stated:

TCS’s response joined issue with the content of much of the letter. A short further letter from DBS’s solicitors dated 17 August 2018 re-iterated DBS’s position that a Remedial Plan in accordance with Clause 56.2 of the Agreement was required.

The business case proposed by the Board was considered by the PIC committee on 30 August 2018, and by email dated 13 September 2018, approval for the proposal to move services from the TCS contract to a new supplier as soon as possible after the end of the current contract was given.

Five days later, DBS’s solicitors wrote further to the letters of 9 July and 17 August 2018 stating, on 18 September 2018, in relation to R1-D:

The following day, DBS gave notice of Partial Termination. The letter stated:

Following de-scoping, the parties disagreed about the contractual validity of the Partial Termination. However, the parties treated R1-D as having been removed from the scope of work in fact. For example, in DBS’s Change Management Report dated 9 October 2018 following the above communications, DBS had reported upon its ‘Review of RFC pipeline required following DBS decision to not roll out R1 any further; not introducing R1 for Standard and Enhanced Disclosures.’ The ‘Must Have’ RFCs were generally stated to be with DBS, and were generally ‘on hold’. DBS’s Amended Defence and Counterclaim expressly admits (at paragraph 46.1), and I find, that following the notice of Partial Termination DBS did not (and indeed, to use the word asserted by DBS within its pleading ‘refused to’) engage with TCS in relation to R1-D. In its Closing Submission DBS contends that TCS did not pursue this point or put it to witnesses, but in light of DBS’s pleaded admission, this was not necessary.

R1-D could plainly not in fact be delivered without (1) resolution of the scope question in relation to those RFCs DBS regarded as ‘Must-Haves’ (which would require further co-operation from DBS) and (2) engagement from third parties and in particular RBs, for which DBS was again responsible for co-ordinating. As Dr Hunt’s evidence confirmed, and I find, TCS could not ‘strike out alone’ once DBS had indicated that, lawfully or unlawfully, it had removed R1-D from TCS’s scope and its engagement ceased.

On the basis of the foregoing chronology, distilled from the much wider body of documentation and witness evidence relied upon by the parties which I have considered, I therefore find as a matter of fact that, in summary:

The starting point is that, I find, the critical delay to the progress of R1-D throughout this period (and, in the context of the claim for relief, from at least 28 November 2017 onwards) to the point at which R1-D was de-scoped was, as a matter of fact, the stagnation caused by the continuing lack of clarity in relation to scope, the commercial negotiations aimed at resolving the lack of clarity, and the stasis which followed the break-down of those negotiations.

This broadly aligns with the general case pleaded at paragraph 36 of the Amended Particulars of Claim. However, DBS not unreasonably focussed upon the particulars then provided. I therefore address these in turn:

The only factual evidence specific to this issue within the Claimant’s witness statements appears to be set out in a lengthy footnote to Mr Padannayi’s First Witness Statement. The relevant part reads:

Whilst the contents of this footnote were unchallenged, it is not clear from the evidence what role this played in the factual matrix. It is not tied, for example, to a ‘Must Have’ RFC which was the focus of cross-examination. The issue was not referred to in Closing Submissions. Whilst I accept the factual evidence, insofar as it goes, there is no basis for me to conclude that this complaint is made out as a self-standing cause of critical delay.

The only factual evidence advance in relation to this allegation is at paragraphs 145 to 147 of the First Statement of Mr Konda. It does not refer to what particular delay was caused by this issue. In evidence, Mr Britton, TCS’s expert, accepted that this was not a delay event (Day 17/91). It is not a matter mentioned in TCS’s Closing Submissions. Whilst I accept the factual evidence, insofar as it goes, there is no basis for me to conclude that this complaint is made out as a self-standing cause of critical delay.

I take these two together as they give rise to the same contractual issues. I read the first of these two as a reference to what has been considered above to be the ‘RFC 607’ issue, namely the proposed change to stagger the data migration approach and create a new solution where an RB could exist and send applications in both legacy R0 or R1. The ‘GDPR’ RFC was an important ‘Must Have’ in the chronology set out above.

As set out in its Written Closing Submissions, DBS’s short legal answer to these claims is that the complaints are fundamentally misconceived: the contractual approach (i.e. scope) remained as per the terms of the Agreement unless and until it was changed by way of an agreed CCN.

DBS contends that a change to the contractual scope of work can only be effected by way of a CCN signed by both parties. DBS points to Clause 2 of Schedule 2-7 to the Agreement which states:

DBS therefore argues as a matter of contract: (1) the contractual scope of work can only be changed by a CCN signed by both parties; (2) until that occurs, TCS must perform in accordance with the original scope of work; and (3) if TCS decides to work on a proposed Change before a CCN has been signed, or pauses work pending a change (which is really the cause of delay here), it does so at its own risk. It is said that it follows that a failure to agree a CCN cannot amount to a delay event: the work which TCS is required to deliver by the relevant Milestone remains the same until the CCN is agreed. An RFC is insufficient to change TCS’s obligations in this regard.

In response, TCS contends that the only party that could specify the changes that were needed to be made to the R1-D specification via RFC to meet DBS’s requirements, who could engage stakeholders such as RBs and who could decide on a migration strategy for the RBs, was DBS. As a matter of natural and ordinary language (and, it argues, common sense) those matters were ‘AUTHORITY Responsibilities’, delay to which was thus ‘AUTHORITY Cause’. I have concluded above that ‘AUTHORITY Responsibilities’ must be grounded in contractual obligations.

TCS also relies on paragraphs 5.1 and 5.2 of Sch. 2-6 to the Agreement: DBS’s failure to decide upon and approve the requisite set of RFCs and its approach to RFC 607 constituted a failure to ‘co-operate in the provision of information necessary for the successful operation and assessment of performance of the Services and other obligations under this Agreement’.

TCS further submits that DBS’s contention that TCS should have no relief because it had an obligation to plough on regardless of the RFC position is commercially unrealistic because it would have led to TCS delivering a solution that it knew that DBS did not in fact want and which could not go live. Where progress, at least at some point in the future, depended upon co-operation from DBS (through the provision of RBs to assist with testing), immediate progress would be to no purpose. This submission, standing alone, does not have a legal footing, however, but it is relevant context in which to analyse the legal basis of any relief.

TCS lastly advances a case (pleaded at paragraph 31 of the Amended Reply and Defence to Counterclaim) that both parties treated the agreement of the scope of R1 Disclosure as a pre-requisite for progressing the release, that the Defendant never confirmed what, if any, functionality it actually wanted in these areas, and that in the premises, TCS could not simply proceed without confirmed functionality. To do so would breach TCS’s own cooperation obligations under paragraphs 5.1 and 5.2 of Schedule 2-6. Alternatively, TCS contends that DBS is estopped from contending that TCS should have progressed Final SIT without an agreed scope, because the parties conducted themselves on the basis that the TCS should not do so. It would be unjust and/or unconscionable for DBS to act contrary to that convention now. Paragraph 31 was not specifically pleaded to in the Amended Rejoinder, although at paragraph 5.3 of that pleading, DBS plead that TCS did not comply with the Contract Change Procedure, and was not prevented from complying by DBS.

In my judgment, DBS’s analysis of the contractual framework for CCNs is the correct starting point.

The key clause is Clause 2.3. This provides a clear obligation upon TCS to continue to provide and make available to DBS the Services (which in this context means the development of R1-D) in accordance with the existing terms of the Agreement until such time as a CCN has been signed by both parties, unless DBS expressly agrees otherwise in writing.

Clauses 2.5 and 10.1 are not duplicative of Clause 2.3 and deal with slightly different things. Clause 2.5 ensures that discussions, negotiations or other communications remain without prejudice to the parties’ rights until the CCN is signed (e.g. the parties are not bound until the CCN is signed). Clause 10.1 is directed at preventing a claim relating to the implementation of change related work prior to the CCN.

The express requirement to continue with the original scope unless and until agreement is reached by way of CCN does not prevent the parties, as part of their obligation to collaborate in an environment of co-operation, from agreeing that planning and thereafter progress was dependent upon scope clarification. The need for co-operation in circumstances where, absent co-operation, TCS would have continued to develop and test something which DBS did not want is plain. It was accepted by Dr Hunt (Day 20/194):

The fact that this may be appropriate has been expressly contemplated in Clause 2.5, by recognising that DBS may agree in writing that the obligation may be disapplied. Therefore, as a matter of contractual analysis, it is correct that TCS is generally at contractual risk if it fails to progress its scope of work whilst discussing potential changes in scope. There may be room for an argument that, if TCS asked DBS to provide an agreement in writing pursuant to Clause 2.5 that the Services or part of them do not need to proceed pending the outcome of particular discussions on scope change and DBS refused, that could be a breach of DBS’s obligation to conduct discussions relating to proposed changes in good faith, pursuant to Clause 2.2 of the Schedule and/or a breach of the obligation to collaborate in an environment of mutual respect and co-operation pursuant to Clause 5.1 of Schedule 5.6. However, there is a contractual process for being relieved from the obligation at Clause 2.5 which, unless invoked, clearly states that TCS must proceed irrespective of negotiations about change. The clause promotes certainty. It is a requirement that itself could only be waived in writing (Clause 62.1).

Therefore, prior to 6 February 2018, notwithstanding that the parties were generally aware of the others’ position, there was no agreement in writing in place to satisfy the caveat in Clause 2.5. TCS had not sought comfort in this regard. The correct analysis for this period is therefore that TCS was, pursuant to Clause 2.5 of the Agreement, at risk for the critical delays being caused by failing to proceed. For the reasons I have set out above, TCS could not have commenced SIT Final at this time, in any event, because of the absence of the availability of the SIT-L environment with connectivity. There are therefore two causes of delay in this period. Although neither expert analysed it in this way, it seems likely that this was a period of true concurrency where there were two equally potent effective causes of failing to progress to Final SIT: the absence of a software drop (due to lack of finalised scope which remained at TCS risk at this point) and lack of environment in which to test. In the context of Clause 7 relief, it does not matter whether these are truly concurrent, or whether the matter for which TCS is at contractual risk is in truth sub-critical: TCS would not be entitled to relief for this period.

However, in my judgment, the agreement reached in February 2018 which was recorded in writing by Ms Downey, properly construed in its factual context, satisfies the caveat (‘unless the AUTHORITY expressly agrees otherwise in writing’) and renders Clause 2.3 inoperative from that point onwards. It was in both parties’ interests to do so in circumstances where to do otherwise would have led to TCS delivering a solution DBS did not in fact want and which could not go live, and where the solution depended upon co-operation from DBS (through, not least, the provision of RBs to assist with testing).

It would not be correct to conclude, as TCS assert, that the approach taken by DBS in February could properly be characterised as a breach by DBS of Clauses 5.1 and/or Clause 5.2 of Schedule 2.6 to the Contract. The parties were engaged in commercial negotiations expressly on the basis that the conclusion of those negotiations was required to permit progress towards delivery a scope which required changes to the specification. That embodied, albeit strained at times, the very co-operation in the provision of information necessary for the successful operation and assessment of performance of the Services and other obligations under the Agreement envisaged by these clauses.

It is not right, therefore, to analyse this factual situation through the lens of ‘AUTHORITY Cause’ for the purposes of Clause 7 (which would give TCS the right to payment for these delays during the period of agreed re-planning, which would not in my judgment be implicit in the co-operative agreement reached at this point).

Instead, the parties’ conduct (embodied in the agreement set out by Ms Downey) upon which TCS’s argument relies and the consequent disapplication of the obligation within Clause 2.3 upon which DBS relies is given effect to merely by forbearance by each side of a claim that the other is responsible for the period of delay generated during this period of commercial negotiation. An alternative and equally valid analysis is that, as pleaded by TCS, DBS is estopped from contending that from 6 February 2018 onwards TCS should have progressed Final SIT without an agreed scope, because the parties conducted themselves on the basis that TCS should not do so. It would be unjust and/or unconscionable for DBS to act contrary to that convention now. That estoppel, in my judgment, does not arise earlier than 6 February which is the point at which the contractual answer to the estoppel falls away.

On my analysis of the facts above, there came a point where co-operation from DBS in order to provide information to allow the R1-D to be provided ceased. The most sensible date to identify this point by is 13 June 2018, when TCS downed tools and DBS resolved with certainty (albeit still subject to Home Office approval) that it did not want R1-D to be delivered by TCS and worked to execute that strategy. The correct factual analysis at this point is that an ‘AUTHORITY Cause’ pursuant to Clause 7 arose because as a matter of fact, DBS was no longer co-operating in the provision of information necessary for the successful operation and assessment of performance of the Services; rather it was executing its strategy which specifically involved TCS not delivering R1-D. As Dr Hunt agreed, TCS could not ‘strike out alone’ and DBS’s lack of constructive engagement in delivery of a minimum viable R1-D solution through TCS from June 2018 onwards breached Clauses 5.1 and 5.2 of Schedule 5-6 of the Agreement.

This ties in with the fourth pleaded allegation relied upon (at paragraph 36.4 of the Amended Particulars of Claim):

In light of the foregoing, this can be taken briefly. It is right that the principal period of engagement from RBs in the context of Final SIT could be pushed to the back end of Final SIT, and, as Mr Britton accepted, would potentially not cause a critical delay to the commencement of Final SIT. It would, in these circumstances, put an earliest date on Go-Live. It was, to this extent, a future rather than a current critical delay.

However, the availability of and engagement with external stakeholders was ultimately at the heart of the issue around data migration. As set out above, DBS’s engagement with RBs was extremely late, and it was in part its engagement with external stakeholders that led to its own determination that the ‘big bang’ solution for data migration and transition was, in its view, unworkable. The lack of clarity around scope was, at least in part, a function of DBS’s failure to have engaged sooner with external stakeholders in the solution which, inevitably, the RBs were going to have to participate in, in due course.

In summary, therefore, I find that:

Partial Termination

Clause 55.11 states:

Clause 56.2 states:

The case pleaded by DBS contends that the de-scoping of R1-D was a lawful Partial Termination justifying the Notice of Partial Termination on a number of grounds, as set out in paragraph 43 of the Amended Defence. These were, in summary, (a) missed Milestones / planning; (b) alleged R1-B&B defects; (c) R1-B&B security incidents; (d) delay to or wrongful refusal/rejection of RFCs; and (e) R1-B&B data migration issues.

TCS contends, correctly, that a material Default for the purposes of Clause 55.11 must be ‘in relation to that part’ of the Services that DBS seeks to remove, i.e. R1-D, and that only Ground (a) does so because it includes the R1-D Milestone. This does not appear to be in dispute by DBS who, in its Closing Submissions focussed solely on that part of its notice of Partial Termination on 19 September 2018 which stated that TCS had not delivered R1-D on time and could not do so within the remaining term of the Agreement. This is the relevant material Default that, it says, was not capable of remedy. As a result, almost all of DBS’s pleaded justification for the lawfulness of its Partial Termination falls away. This includes the security incidents, whose only pleaded relevance is in the context of the justification for Partial Termination.

As to whether a ‘Default’ is ‘capable of remedy’ Lord Reid said, in Schuler AG v Wickman Machine Tool Sales [1974] AC 235 at §249:

In the context of delays, HHJ Seymour QC held in Peregrine Systems Limited v Steria Limited [2004] EWHC 275 (TCC) at §172 that:

DBS did not, in its Closing Submissions, dispute that the fact of failure to have met the R1-D Milestone (whether that is taken to by 28 November 2016 or 2017) would not necessarily of itself be a material breach incapable of remedy. DBS does not suggest that it sought to engage in the Remedial Plan Process required of it in relation to R1-D if it was capable of remedy, by which it means capable of delivery prior to the end of the (unextended) Agreement period. It plainly did not: the letter of 18 September 2018 simply asserted that ‘there is not sufficient time within the remaining Term of the Agreement for R1 Disclosure to be delivered, even if TCS had a credible plan for delivery’. Instead, it contends that as at the date of its notice, 19 September 2018, there was a ‘material Default’, that the contractual expiry date was 31 March 2019, and that TCS could not deliver R1-D by this date.

DBS is correct that, as a matter of principle, it does not follow that because something could physically be done late it can never amount to an irremediable breach of an obligation to do something by a certain time; it will depend upon the circumstances of the case. However, in the present circumstances, it is right to focus on the question of whether R1-D could have been delivered within the relevant contractual timeframe. If it could, DBS would (together with any compensation payable for delays to which a party may be entitled) be put in the position it would have been but for the breach.

TCS contends that the effect of the contractual regime is that DBS could not conclude that R1-D Milestone delays were incapable of remedy prior to engaging the Remedial Plan Process, and that the failure to engage the Remedial Plan Process of itself therefore meant that the Notice of Partial Termination was unlawful. There will, of course, be situations where it is possible for the Authority to determine that, objectively, a breach is incapable of remedy. However, in circumstances where, objectively, a breach may be capable of remedy, I consider that the contract, properly construed, requires the Authority to engage Clause 56, to which its right under Clause 55 is expressly subject. If the Authority chooses, as it did here, not to engage Clause 56 in respect of the relevant alleged material Default, but, objectively, it may have been capable of remedy, it will not have exercised its right to Partial Termination lawfully.

As a matter of fact, I accept that, as at 18 September 2018 (when DBS asserted that the material breach relating to delivery of R1-D could not be remedied), it would definitely not have been possible for TCS to achieve Go-Live by 31 March 2019. However, in my judgment, the analysis does not end there.

First, it is obviously correct that TCS had not delivered R1-D by the Milestone Date, and that breach took place on 28 November 2016 (or 28 November 2017, to the extent that the date for delivery had consensually moved back – which is not relevant for this analysis). If a Notice had been served at or shortly after either of those points, it would not have been possible to assert that the breach was incapable of remedy and engagement Clause 56 would have been required.

I have found above that, on the basis of the programmes, it would have taken up to 12 months from commencing Final SIT to achieve Go-Live. The breach would therefore have been capable of remedy, had a notice been served at any time up to 31 March 2018. Indeed, because of the possibility of accelerative measures, it would not, at any stage up to around 9 months prior to the expiry date (i.e. the end of June 2017), have been possible to assert justifiably that the breach was inevitably incapable of remedy without invoking the necessary Clause 56 Remedial Plan Process in order to provide the defaulting party with, as required by the Contract, a reasonable opportunity to demonstrate that the breach was capable of remedy. This is consistent with Dr Hunt’s evidence that, as at June 2018, it was still ‘possible’ to suppose Go-Live could have been achieved by the end of March 2019 ‘but you have to sit down and look at every single plan in the context it is in at that point in time’.

I have also found that from 6 February 2018 onwards, TCS was not contractually responsible for the ongoing critical delays, and that from 13 June 2018, the cause of continuing critical delay was an ‘AUTHORITY Cause’.

TCS contends, and DBS disputes, that on proper construction or by necessary or obvious implication, DBS could only exercise a right of Partial Termination within a reasonable time of the operation of the Remedial Plan Process or the alleged material Default. Neither party developed their submissions in this regard. DBS merely contended that ‘there is no basis for this argument.’ This is not right. The construction/implication sought relates to how this Agreement, if at all, regulates the principles of election, affirmation, and waiver, which apply equally in the case of a contractual right to (partially) terminate a contract as they do in the case of a common law right to terminate upon acceptance of a repudiatory breach. However, in the context of contractual rights the operation of the principles depends upon the construction of the particular contractual right (see DD Classics Limited v Kent Chen [2022] EWHC 1404 (Comm)).

In the present case, I accept that the proper construction of the contract is that the Authority could only exercise a right of Partial Termination within a reasonable time of the operation of the Remedial Plan Process or the alleged material Default. This construction is both obvious and necessary. The whole purpose of the Remedial Plan Process is to give the Contractor, within defined timescales, the opportunity to remedy a material Default which otherwise gives the Authority the right to remove that part of the work. The purpose of the regime would be defeated if, in relation to a material Default of which it is aware, the Authority could simply wait until, by reason of the effluxion of time, it is no longer capable of remedy, and then invoke Clause 55.11 and, by so doing, sidestep the obligations in Clause 56 to which Clause 55.11 is expressly subject.

In the present circumstances, the reason why the R1-D default was not capable of remedy as at the date of the Notice was the preceding critical delays which were, from 6 February 2018 onwards, not the responsibility of TCS and, from 13 June 2018, an ‘AUTHORITY Cause’ arising out of DBS’s failures to comply with Clauses 5.1 and 5.2 of Schedule 5-6 of the Agreement. It was not open to DBS, on a proper construction of the contract, to wait until the default was irremediable to exercise its right under Clause 55.11 without operating Clause 56. An alternative way of analysing these facts is that, by delaying the operation of Clause 55.11 from the end of June to September 2018 (in circumstances where, had it done so in June, it would have been required to invoke Clause 56) DBS benefited from its own breach and a limit on the time by which DBS was required to invoke Clause 55.11 in relation to the material default relating to R1-D will be implied so as to prevent DBS from benefiting from its own breach.

Even if I am wrong about this, I accept TCS’s submission that it is necessary to consider that, as at the date of the Notice of Partial Termination, it was inevitable that the Agreement was to be extended by at least 6 months. This had already been communicated by DBS to TCS prior to the Notice of Partial Termination. At the Commercial Forum on 13 September 2018, the following was minuted:

The ‘preference’ was not a preference between an extension of 6 months and no extension; it was a preference between an extension of 6 months and a longer period. This much is clear from the strategy paper seeking approval from PIC referred to in the chronology above. It was reiterated in the presentation by Ms Downey to PIC on 30 August 2018, two weeks before the Commercial Forum. In this Ms Downey made clear that:

DBS argues that it is legally irrelevant that it ‘may have been anticipated’ that the Agreement would be extended, and that the parties’ legal rights and obligations must be assessed based upon the contractual position as it existed at the time the contractual right was due to expire.

I remind myself that the relevant question is whether DBS was entitled to assert as at 18 September 2018 that R1-D was incapable of being delivered in the contractual timeframe. It is right that the then contractual expiry was 31 March 2019, but a minimum extension was not just ‘anticipated’; it was, I find, inevitable. Not only was it part of DBS’s own strategy, it was essential because there was simply no way DBS could continue to meet its statutory obligations until it had secured an alternative supplier (lawfully), and it would not have been able to do this without an extension. It would not be appropriate for the Court to shut its eyes to the factual reality when considering, objectively, whether the (future looking) conclusion that TCS was incapable of delivering R1-D prior to the termination of the Agreement was justified as a matter of fact. The fact that the inevitable extension had not been formalised – an obviously necessary step as Mr Kuncheria of TCS unsurprisingly agreed – does not change the reality that the Agreement was not in fact going to expire until the end of September 2019 at the earliest.

Indeed, the formalisation of the extension took place 8 days after the Notice of Partial Termination. If, on 18 September 2018, DBS had sought to invoke the Remedial Plan Process (as, on this analysis, it should have done), by the time the plan was required to be submitted (20 days later), the date by which the Remedial Plan would have had to demonstrate delivery of R1-D would (even ‘formally’) have been 30 September 2019.

Taking into account the (minimum) inevitable extension to the Agreement of 6 months, even on Dr Hunt’s evidence, a reasonable Remedial Plan would have demonstrated that R1-D could have been delivered in time (absent unagreed RFCs). In light of the imminence and inevitability of extending the Agreement expiry date to at least 30 September 2019, DBS were wrong not to comply with Clause 56, and invoke the Remedial Plan Process.

For all these reasons, the Notice of Partial Termination was invalid, and DBS was not entitled to remove R1-D from TCS’s scope at the time and in the manner it did. The non-delivery of R1-D following the wrongful Partial Termination was caused by the effective de-scoping and the admitted non-engagement by DBS thereafter in the delivery of R1-D.

DBS contends that if, as TCS contend, TCS did not accept its repudiatory conduct in wrongly removing part of the scope, the correct analysis is that TCS remained contractually obliged to deliver R1-D. It contends that in these circumstances, absent ‘AUTHORITY Cause’, TCS is liable for the continuing non-delivery of R1-D. This is not correct. TCS did not accept the repudiatory conduct (which would have entitled them to bring the whole contract to an end) because it continued to comply with its other obligations (e.g. providing the R1 B&B services). By electing not to bring the (whole) contract to an end on account of the repudiation means only that the repudiatory element of the breach is writ in water. The breach in de-scoping the R1-D when it was not entitled to is not. TCS was entitled to accept that (in breach of contract) DBS had unilaterally decided to remove part of the scope of works, treating it, in effect, as an instruction with which it would comply, without prejudice to any damages it may have on account of the breach. Another valid analysis is that, in light of the breach by DBS, TCS acted reasonably in not continuing to expend its money delivering a product DBS had indicated in the clearest of terms and by subsequent conduct (albeit not in a contractually compliant way) that it no longer wished to take delivery of in order to mitigate its own losses. Finally, and to the extent necessary, the removal and subsequent admitted refusal to engage with the delivery of R1-D would, in any event, be ‘AUTHORITY Cause’ arising from DBS’s breach of contract, but this alternative analysis is, in my judgment, artificial because it does not meet the factual reality that scope was simply, and wrongly, removed (and was not, in any real sense from then on, in ‘Delay’).

Delay/Partial termination Related Quantum

TCS claims for “Manpower Costs”, being the difference between: (i) the costs that it incurred in providing both Operational Services and in relation to the development and testing of the Solution; and (ii) the costs that it would have incurred in so doing but for the delays it says were caused by DBS. In the period following the removal of R1-D, these losses are properly related to the removal of that scope. TCS claims the following manpower costs per period and workstream, as summarised by TCS’s forensic account expert, Mrs Wall.

Period 1 (GBP 11.9 million) is an approximately 12-month period from September 2016 to August 2017, covering the delay of the R1-B&BGo-Live from 15 September 2016 to 7 September 2017. Mr Padannayi explained that this period roughly covers the period from the planned R1 Barring and Basics Go-Live (15 September 2016) to the month ending before Go-Live was actually achieved (7 September 2017). His evidence was that TCS incurred manpower costs to maintain the R1-B&B team, which would not have been required had Go-Live taken place as planned. There was intended to be a "big bang" release of R1 Disclosure on 28 November 2016. If that had happened, the R0 support team would have been disbanded and TCS would not have incurred further costs on the R1 Disclosure delivery team. Costs for that R0 support and R1 Disclosure delivery teams were therefore included from December 2016 onwards. However, R1 BAU IT support team would still have been required throughout.

Period 2 (GBP 8.8 million) is an approximately 13-month period from September 2017 to September 2018, being the continued delay of the R1 Disclosure go live until the day before notification from DBS of its intention to terminate R1 Disclosure on 19 September 2018. Mr Padannayi’s evidence was that after R1 Barring and Basics Go-Live, TCS incurred manpower costs to maintain their delivery team to work on the delayed R1 Disclosure which would not have happened had R1 Disclosure Go-Live been achieved as planned in November 2016. TCS would also not have continued to incur R0 support costs.

Period 3 (GBP 3.0 million) is an approximately 18-month period from September 2018 to March 2020, being the absence of the R1 Disclosure Go-Live between the notification from DBS and the actual termination of the Project on 27 March 2020. Mr Padannayi gave evidence that during that time TCS continued to incur costs for R0 support which would not have been necessary if R1 Disclosure Go-Live had happened. He explained that for a couple of months, a small number of R1 Disclosure staff were retained on the DBS account (five in October 2018 and two in November 2018), because TCS wanted to progress R1 Disclosure and did not accept the partial termination. He said, ‘These were key people and we did not want to lose them — we wanted to make sure DBS weren't going to change their position.’

On the basis of my findings on liability, Period 1 relates to a period of critical delay during which TCS has no entitlement to claim losses pursuant to Clause 7. The claim for this period fails in its entirety.

In relation to Period 2, I have found that there was critical delay from 13 June 2018 to 19 September 2018 which was an ‘AUTHORITY Cause’, entitling TCS to claim pursuant to Clause 7.4 for loss and expense. From Appendix VW3-A, it can be seen that the claimed costs for June to September 2018 are as follows:

The top line is what Mrs Wall refers to as ‘verified’ costs. The bottom line is ‘Unverified as to amount’. The aggregate of both lines together forms part of the £23.6m sum claimed, as set out in the table above. The aggregate of the bottom line only forms part of the sum of £9,740,335 agreed between the experts as the total payroll costs for the relevant period for the relevantly allocated personnel included within the TCS claim.

Doing the best I can by a pro-rata of the days, the claimed sum for the period 13 June 2018 to 19 September 2018 would be a total of £1,640,562 (constituting £666,735 (Footnote: ²) verified costs and £973,827 (Footnote: ³) unverified as to amount).

As to ‘verified’ and ‘unverified’, the experts agreed that following the submission of Mr Hain’s Second Report and Mrs Wall’s Second Report, additional payroll information had been disclosed for the period September 2016 to November 2018. The total of the monthly payroll costs for the relevant employees identified by Mr Padannayi indicated by this information is GBP 8,346,640. On Mr Padannayi’s assumption that the actual costs in December 2018 of GBP 92,913 reflect the monthly costs for January 2019 to March 2020, results in total payroll costs of approximately GBP 9,740,335 for the entire claim period to March 2020.

The difference between £9.7m and the claimed amount is due to the fact that Mr Padannayi’s, and therefore Mrs Wall’s calculations use 2012/13 rate cards for the ‘unit cost’ (as distinct from ‘time’) element of the Manpower costs claim.

Based on BCLP’s letter to Bristows of 5 July 2023, Mrs Wall gave evidence that her understanding was that the costs included in the ‘fully loaded cost cards’ account for, amongst other things, the running cost of facilities, employee travel, hotel and visa costs. Mrs Wall recognised that some of these types of costs are included in TCS’s Non-Manpower Costs claim, but is unable to identify what duplication may exist. She also recognised that some of the costs which contribute to the fully loaded card cost may not be incremental to the Project, but considered that some, unidentified, proportion of the difference would represent incremental expenditure not included elsewhere in TCS’s claim. Whilst Mrs Wall expressed the view that any valid Manpower Costs claim would be in excess of its payroll costs of approximately GBP 9.7 million (assuming entitlement for the whole period), Mrs Wall was not able to identify how much in excess of this sum the claim would be for or on what basis. This position is not, in principle, any different to Mr Hain’s evidence that that in circumstances where rate cards incorporate allocations of general overheads (including those identified generically by Mrs Wall, as well as HR, legal, finance, leadership etc,), such allocations rely on assumptions as to the amount of work that will be done in order to recover the anticipated level of overheads.

TCS’s claim cannot succeed on the basis of its rate cards, which include a substantial element of overheads. Although TCS may have incurred additional costs which fall outside of payroll costs and Non-Manpower Costs, TCS has not provided any evidence in relation to the overhead element of the claim or its recovery as a matter of fact (or causation), and TCS has provided no calculation for them. TCS’s claim must be based upon the sums referred to by Mrs Wall as ‘verified’. TCS conceded this in its Closing Submissions (paragraph 183).

The second issue of principle between the parties related to the allocation exercise undertaken by Mr Padannayi. Mr Padannayi took the ‘Monthly Allocation Report’ from TCS’s internal system, Ultimatix, and added two columns, both relating to RFCs. The content of these columns was derived from work he had done speaking to peers and, as a cross-check, his knowledge about RFC timings. It was not suggested to Mr Padannayi that his approach was somehow inappropriate in cross-examination. And, seen in the context of Mr Padannayi’s wider exercise, it is clear he tried to adopt a ‘very conservative approach’ to personnel identification.

In his reports, and as summarised in the Joint Report, Mr Hain had identified that there were ‘Work Order Numbers’ set up by TCS and used by TCS in the management of its business, as evidenced by the fact that costs (including charges of time on timesheets) were allocated to different Work Order Numbers. Mr Hain considered that contemporaneous allocations of cost and charges of time to WON codes was likely to provide more reliable information than making enquiries of colleagues about what particular members of staff were doing many years ago without reference to WON codes.

Mr Hain used the same data source as Mr Padannayi (Exhibits VW1-5.1-28) to determine that £1,496,344 of the actual payroll cost to December 2018 (£8.3m, see 3.1.1 above) was recorded against RFC WON codes and that approximately £3,280,646 of the actual payroll cost to December 2018 was recorded against BAU WON codes. Taking the RFC and BAU costs from the actual payroll costs of £8.3m, leaves an amount of £3.6m (analysis by way of WON codes produced approximately 43% of Mr Padannayi’s analysis).

TCS relies upon the fact that, during cross-examination, Mr Hain confirmed that he did not consider a manpower analysis based on WON codes should be preferred over Mr Padannayi’s approach and that he was not in a position to challenge what Mr Padannayi had done, and he confirmed that he supported a figure at the top of his range, rather than the product of his WON code exercise:

The £1.5m adjustment relates to an adjustment relating to the final months which is relevant to Period 3. In my judgment, particularly in light of Mr Hain’s rowing back from an allocation/adjustment exercise based upon WON codes, I accept that the exercise undertaken by Mr Padannayi was thorough, appropriate and materially reliable.

In the circumstances, the claim for Period 2 succeeds in the sum of £666,735. To the extent that (contrary to my findings above), TCS were entitled to recover its losses in any other period, they would be calculable on the same basis (i.e. payroll data applied to Mr Padannayi’s allocation exercise).

In relation to Period 3, but for the wrongful Partial Termination, but accounting for the preceding delays, I assume that TCS would have delivered R1-D by 19 September 2019, one year from the date of Partial Termination. The costs of maintaining its R0 and R1 delivery costs from September 2018 through to the delivery of R1-D on 19 December 2019 are not recoverable as they are costs associated with carrying out its base scope (albeit late, by reason of the preceding delays for which compensation has been assessed, to the extent relevant). In other words, the analysis assumes that no critical delay is caused to the progress of the works from 19 September 2018 onwards, and that therefore there would be no Clause 7.4 entitlement.

The only Manpower costs in Period 3, which are, in reality, costs caused by the wrongful de-scoping of R1-D, will relate to the period from 20 September 2019 to March 2020.

TCS’s figures for manpower costs are based on the assumption that they remain the same after November 2018, and no actual salary costs have been provided for the period from December 2018 to March 2020, as agreed by the experts at paragraph 3.1.1 of the Joint Report. Mrs Wall requested the actual salary data from her client for this period, but was not given it, and agreed that such data must exist (Day 24/123). DBS contend that in circumstances where TCS gave no explanation for not providing the data, the Court should draw the natural inference that if it had been provided it would not support the sums claimed, and would show TCS’s manpower costs decreased rather than (as assumed within the TCS claim) they remained the same. I agree. There can be no proper basis for failing (essentially refusing, in light of Mrs Wall’s request) to provide actual cost data for the entire period of the claim. There is no evidence, therefore, of what TCS’s actual costs were in respect of manpower during the only relevant period under consideration in Period 3, and in these circumstances, the claim fails.

I therefore conclude that TCS are entitled to £666,735 in respect of its Manpower Costs claim.

The factual evidence underlying the claim for non-manpower costs was given by Mr Banerjee and Ms Lalitha, neither of whom were called for cross-examination. The quantum experts agree that of the non-manpower costs claimed by TCS, £8,661,931 has been incurred and paid. The majority of these costs are costs which are said to have been incurred because R0 was not decommissioned on time, which could only occur once the entirety of R1 was delivered.

The balance of the claimed amount is £62,862. £58,500 of this relates to staff expenses (travel/visa costs) which is calculated on an average cost of £1,500 per person, supported by the unchallenged evidence of Ms Lalitha. I accept her evidence, and that of Mrs Wall who concludes based on her review of the evidence that these costs are likely to have been incurred and the amount is estimated on a reasonable basis. Whilst ‘unverified’ in the sense that the sums have not been tracked back to specific supporting invoices, I consider these sums should be included within the claim (particularly in circumstances where I have rejected the use of all in ‘rates’ for staff that would have included such additional costs). The remaining £4,362 relates to a small portion of the hardware and software renewal sums which both experts include in the estimates of sums reasonably incurred. I consider that the sum ought to be included in the overall assessment of non-manpower costs (which therefore totals £8,724,712), which claim spans the same 3 periods as considered in relation to the manpower costs claim, dealt with in the previous section.

The vast majority of the costs claimed (£7,137,646) relate to Vodafone costs. Vodafone provided network and connectivity services to TCS. Mr Banerjee explained, and I accept, that Vodafone hosted and managed the data centre, which hosted all of the servers operating for the Project to run the legacy R0 applications, and delivered network and connectivity for the legacy R0 system between the data centres and (i) the local network connection from two floors of TCS’s office premises; and (ii) public service networks where the data was consumed (e.g. the Police National Network). The claimed Vodafone services were specific to the legacy R0 estate which would have been replaced by the R1 Disclosure system – the same connections were not required once R1 Disclosure was live. Vodafone provided services to TCS for R0 support and R1 support but the services I refer to only relate to R0 support; in the absence of a delay to R1 Disclosure Go-Live these services would not have been needed. After Service Transfer on 27 March 2020, DBS took over the premises and the Vodafone contract was novated to them, so they continued to use the Vodafone services but TCS were invoiced for the full month until 31 March 2020.

There were, in addition, numerous other hardware and software renewal costs of much lower sums, aggregating to approximately £800,000 which represented extensions of fixed termed contracts which had to be renewed because R0 was not decommissioned. DBS correctly point out that, if the first extension date would have been reached without R0 being decommissioned due to delay for which DBS is not liable, the extension would have been required in any event (and the same applies to any further extensions).

On the basis of my analysis of delays as set out above, (a) TCS has established an entitlement to loss and expense for 98 days, and (b) but for the wrongful de-scoping, TCS would have delivered R1-D by 19 September 2019. It is usual that claims for prolongation costs are calculated by references to the expenses incurred during the period of relevant critical delay. However, in the circumstances of the present case, I consider that the fairest method of analysis which gives effect to the factual findings above, and takes DBS’s point about the timing of renewals into account, is that I should assess TCS’s entitlement by allowing all non-manpower costs incurred after 98 days prior to 19 September 2018, i.e. after 13 June 2018. I therefore allow all of the sums claimed for the months of July 2019 to the end, together with 17/30 of the sum claimed for June 2019 (£206,733). That comes to £1,615,841 plus £117,148.70 (Footnote: ⁴), making £1,732,989.70.

For the reasons set earlier in this judgment, I consider that recovery of these costs is excluded by Clause 52.3.

I nevertheless address therefore what TCS’s recovery would have been but for the existence of the exclusion clause. TCS’s pleaded claim is for £77,314,727 and, as clarified in its response to a Request for Further Information dated 5 February 2021, is advanced on the basis that (i) the per transaction cost to TCS of processing each of Basic Disclosure, Standard Disclosure, Enhanced Disclosure and Update transactions was anticipated to fall substantially on Go-Live of R1 owing to the efficiencies of operating the Solution compared with the legacy R0 process; (ii) the contractual charging scheme reflected that anticipated lower cost to TCS, principally by means of a substantial drop in the Transaction Charges after Service Year 3; (iii) by reason of the delay to Go-Live of R1-B&Band the lack of Go-Live of R1-D, TCS was not able to achieve the contractually anticipated savings but was still subject to the reduced Transaction Charges; (iv) the result was that the Claimant’s net revenues from Transaction Charges were substantially lower than they would have been but for the delay in relation to R1-B&Band non-implementation of R1-D.

As set out in her First Report, Mrs Wall performs three different calculations of TCS’ lost anticipated costs savings, all of which are based on the Financial Model (‘FM’). The first is based on the use of the Transaction Charges as a proxy for calculating TCS’s loss of anticipated savings. This yields a sum of £54,056,959. As pointed out in her first report, her view was that ‘it is not clear that the reduction in Transaction Charges following the planned go live date for R1, as used in TCS’s calculations, would be an appropriate proxy for calculating loss of anticipated cost savings.’ Mrs Wall accepted in the Joint Report that, whilst the loss of anticipated cost savings ‘could possibly’ be as high as £54m, they were more likely to be within the £8-13 million range calculated by her second and third approaches.

Mrs Wall’s second approach was to consider the anticipated cost savings in the FM (calculated at £13,138,959), and the third was to consider the anticipated cost savings in the FM expressed as a percentage reduction in operating costs incurred prior to the R1 Go-Live date, applied to TCS’s actual costs from January 2017 to March 2020 (calculated as a range from £8,166,753 to £12,731,575, depending on whether the percentage reduction is calculated on aggregate average operational costs (the lower figure) or average operational cost per transaction).

Mrs Wall confirmed in cross-examination that her third approach was her most preferred approach in terms of accuracy and reliability (Day24/155). In light of this, I do not consider Mrs Wall’s first two suggested approaches further (save that some of the criticisms of the third approach were explored in evidence in the context of the second approach and are equally applicable) insofar as they relate to issues around use of the FM.

The third approach uses a comparison of the forecast operational costs in the FM before and after (anticipated) Go-Live. That generates a percentage (22.9% or 35.7%) and that is then applied to actual cost data.

DBS advance a number of criticisms. The obvious point is made that the claim is based upon the forecasts with the FM, which were made a number of years prior to the relevant events, and some of the assumptions, unsurprisingly transpired not to be correct. For example, TCS ended up processing more transactions than forecast within the FM. TCS did not use contemporaneous budgets or forecasts of future costs, which Mrs Wall fairly accepted it would have expected an organisation like TCS to have, and which Mr Hain also considered would ordinarily be readily available. The use of the FM therefore invites the inevitable question: why not use a more up to date forecast of likely costs post Go-Live? DBS does not, in its Closing Submissions, say that this point is fatal to the claim as a whole, but argues that in light of it, the Court should err on the side of caution and the claim should be ‘reduced further’. There is force in the point made by DBS.

DBS raises two further points which, in my judgment, are valid. The first is that the percentage calculation deriving from a cost-per-transaction approach assumes that all costs were variable, when only some would be. This would tend to overestimate the saving. The second is that Mrs Wall’s calculation includes the effect of an efficiency benefit derived from the introduction of R2, which it would be appropriate to strip out. This would reduce Mrs Wall’s 22.9% to 18%.

There is inevitable uncertainty given the factors set out above. Indeed, this is precisely the sort of uncertainty of which Coulson LJ observed when comparing a loss of profits claim to a true wasted expenditure claim (based on actual invoiced costs incurred but to no end, in light of a termination). In my judgment, it is appropriate in all the circumstances to use the lower bound percentage of 18% to reflect the likely saving that TCS would have made.

This saving then needs to be applied in the same way as the analysis for non-manpower costs, to those actual costs which were incurred after the date that, but for the matters of which TCS complain, it would have achieved Go-Live of R1-D.

This can be calculated from Mrs Wall’s appendix VW-3A, by:

This amounts to (£2,653,289/22.9)*18 = £2,085,555.

TCS are entitled, pursuant to Clause 7.4 of the Agreement, to:

If, contrary to my conclusion on the correct construction of the contract, TCS is entitled to loss of anticipated savings in respect of the removal of R1-D, I have calculated the amount that would be recoverable given my findings relating to liability and quantum in the sum of £2,085,555.

The parties are agreed that, pursuant to discussions in 2015 leading to a draft CCN 041, the parties agreed to settle liability at £4,559,439 for the delays up to September 2015 in exchange for revised Go-Live dates, the Milestones were adjusted and the parties in fact worked to the new Milestones. There is no dispute between the parties that that sum is payable by TCS to DBS as part of the overall accounting which will be determined by this litigation.

There are two issues relating to CCN 041, however, arising out of its proper characterisation. DBS contends that it is a debt, with the consequence (a) that the sum is not to be taken account of as part of the single £10 million cap applicable under Clause 52.3 (as I have found it to be) and (b) interest on the sum should be paid under the Late Payment of Commercial Debts (Interest) Act 1998 from the date of the original Defence and Counterclaim, which is claimed is the written notice given by the wording of CCN 041. TCS denies this characterisation. TCS contends that there was no binding agreement in the full terms of CCN 041, but instead the proper analysis is that by their conduct, the parties (and TCS in particular) are estopped from arguing that the value of the delay claims against it for the period up to September 2015 is other than £4,559,439. The claim for this sum is, however, a claim which contributes towards the liability cap. It also contends that DBS’s claim for interest pursuant to Late Payment of Commercial Debts (Interest) Act 1998 is not pleaded, and wrong.

Draft v.0.1 (and later drafts) of CCN 041 stated:

Collette Owen (Head of Commercial for DBS) gave evidence that:

Mr Whiting (Deputy CEO of DBS) also gave evidence in relation to CCN041, as follows:

DBS, in its Written Closing Submissions, points out by reference to an email exchange dated 23 June 2016 that, by v.0.5 (which contained the wording above), the parties were agreed on the content save that some references to test documents needed to be added. The document supports this submission, but it was around this time that negotiations in relation CCN 041 then got wrapped into negotiations covering all delays, as set out in the Commercial Forum Dashboard in July 2016, which recorded:

Mr Whiting also confirmed in evidence his understanding that for the CCN to be effective, the CCN would need to be signed (Day 7/97):

DBS’s primary analysis depends upon the obligation to have commenced providing credit notes being effective. However, it was not. The agreement was never signed off, as DBS’s witnesses accept. This is consistent with the fact that at no point did DBS complain that credit notes were not being provided, or indeed simply deduct the sums that would have started to become due from the payments otherwise being made to TCS, as it would have been entitled to do if its analysis that the obligation to give credit had in fact arisen.

The wording of the draft CCN 041 in respect of the ‘Settlement Sum’ becoming a debt is clearly in contemplation of the future invoices from TCS being insufficient to permit the entire Settlement Sum to be deducted over the period of 12 months, with a notice being required to be made in respect of the ‘remainder of the Settlement Sum’. The agreement then provided that in circumstances where TCS fully pays the Settlement Sum, the Authority was precluded from claiming additional damages, losses, expenses or costs. However, where TCS did not comply with the CCN (as DBS alleges in effect the position to be), the Authority was not so precluded, and would merely need to set off against any claim the Authority may bring in respect of the (pre-September 2015) ‘Breaches’.

DBS contends that, if the parties are estopped from denying the amount owed to DBS and the revised Go-Live dates, they are equally estopped from denying the applicability of other terms set out in CCN 041. By the other terms, DBS’s first argument focussed upon the part of the CCN by which the sum payable turned into a debt upon notice, which notice it said was given by paragraph 66-67 of its Amended Defence. It then said that a debt was not caught by Clause 52.2.6.

The difficulty with this argument is that in general terms, an estoppel (noting that neither parties’ submissions detail what type of estoppel has arisen or how of its constituent elements have been satisfied) requires a representation or common assumption from which it would be unjust/unconscionable to resile. Neither party, however, was proceeding on the assumption that the CCN was effective such that the obligation to commence giving credit against the monthly invoices had yet arisen. DBS’s conduct (in not seeking such credits or making deductions) is entirely inconsistent with the suggestion that it was proceeding on the basis that such credits were yet due prior to formally signing off the CCN, as indeed is its failure to give a notice after 12 months (indeed: ‘12 months from when?’ one might ask…). There was therefore no common assumption that the obligation to give any credit had yet arisen. Indeed, put another way, there was no common assumption that the credits envisaged were ‘due’ until the CCN was effective. This can be contrasted with the conduct of the parties in clearly working towards new Milestones upon the shared understanding that the Milestones had actually moved backwards, and that they had been moved in exchange for an agreed valuation of DBS’s claims under Clauses 6.2 and 6.3 in respect of preceding delays.

I do not consider, therefore, that by virtue of an alleged failure to make payments pursuant to the draft CCN and the service of ‘notice’ by reference to paragraph 66 of the Amended Defence (which I note does not expressly state that it constituted notice for the purposes of the draft CCN), the agreement that the value of the claim against TCS for the pre-September 2015 became a ‘debt’. The value of the claims agreed would not become ‘due’, other than by operation of the CCN terms once it became effective, which never happened. It would be wrong, therefore, to say that there was a ‘failure’ to pay the sum as at the date of the Amended Defence.

Mr Croall’s better argument, however, was that the agreement reached in the (draft) CCN encompassed the nature of the manner of payment, by way of credit against sums otherwise payable to DBS. He argued, in the context of the applicability of caps, it was hard to see how a sum that is to be credited against charges as its principal mechanism for payment could be intended to be subject to a cap: one way of looking at it was that it was a consensual agreement to change the payment regime.

This argument has force. In my judgment, it has particular force in circumstances where the agreement reached was for a composite sum to be payable by TCS in respect of both Delay Payments pursuant to Clause 6.2 and additional delay damages pursuant to Clause 6.3. That this is so is plain from the wording of the draft CCN. The two different types of claim are subject to separate liability cap regimes: Clauses 52.2.5 and 52.2.6, yet the parties did not agree any particular split of the sum of £4,559,439 to the different clauses. This makes it impossible to determine what part of the sum is caught, in principle, by the different regimes. I consider this to be consistent with the common assumption advanced by DBS that the payment agreed was to be way of credit against payments (whenever it became effective) and was not subject to any cap. Even if I am wrong about this, TCS has not provided any evidence or submission which would allow the Court to determine what part of the composite value of £4,559,439 should be set against the Clause 52.2.6 cap. In these circumstances, I conclude that no part of £4,559,439 should be included within the £10,000,000 Clause 52.2.6 cap.

It also follows from my conclusions above, however, that I do not consider that the sum is owing by way of debt such that it would be right to apply the Late Payment of Commercial Debts (Interest) Act 1998. No such claim has, in any event, been pleaded by DBS, whose claim is limited to interest pursuant to section 35A of the Senior Courts Act 1981.

I have found that it was a condition precedent that DBS promptly issue a Non-Conformance Report in accordance with Clause 6.1 if DBS is then to have the options set out in Clause 6.2, which includes Delay Payments. It did not do so. Its claim for Delay Payments fails.

If I am wrong about that, its claim in respect of R1-B&B in the sum of £892,500 would have succeeded in full, and its claim in respect of R1-D would have succeeded for the period from 28 November 2017 to 6 February 2018, a period of 70 days (in the sum of £700,000).

DBS claims the sum of £3,461,764, although it accepts that it must give credit against this for the £892,500 which would have been recoverable by way of Delay Payments (even though, for the reasons set out above, these are in fact irrecoverable).

Although TCS appeared to suggest that there was no Milestone for Basics against which delay could be alleged, this was not pursued in Closing which adopted the R1 Barring and R1 Basics Go-Live dates of 15 September 2016 and 1 January 2017 respectively.

The sums claimed by DBS are:

On the face of it, the delay to the R1-B&B Milestone exceeded 6 months so, pursuant to Clause 6.3 of the Agreement, the primary remedy of Delay Payments is not DBS’s exclusive financial remedy. It would be entitled to claim damages demonstrated to be in excess of the Delay Payments otherwise recoverable.

The claim comprises £427,130 paid to Disclosure Scotland and £609,700 DBS internal staff costs.

The claim is supported by the factual evidence of Ms Graves, who explained in her Third Witness Statement that the R1 project was meant to have been delivered at the end of 2016 and that the issuing of Basics certificates would be performed by DBS for the first time, replacing a service that was performed for the whole of the UK by Disclosure Scotland under delegated powers. Ms Graves said that when it became clear that DBS’s Basics service would not be ready on time, DBS had to ask for an extension of the delegated powers. This meant DBS had to commit to a longstop date of January 2018, when DBS would take over the Basics Services from Disclosure Scotland. Ms Graves candidly accepted that she only had indirect knowledge of what was happening with Disclosure Scotland as a result of her conversations with Gareth Gregory who was dealing directly with the situation. Gareth Gregory did not give evidence. Nevertheless, Ms Graves recalled that Disclosure Scotland was not aware of the proposed extension to the delegated powers before it had already taken steps to reduce its own workforce and changed its facilities. This meant that between August 2017 and January 2018, DBS had to send a number of staff up to Disclosure Scotland to assist them to maintain the same volume of Basics checks. As part of this, DBS had to pay for desks/office space, communication costs at the Blantyre site (a Disclosure Scotland site) (which were recharged by Disclosure Scotland) and to rent flats to accommodate the DBS team, with travel, overtime and other expenses.

TCS advance a number of arguments. The first is that the claim relates predominantly to the post-Go-Live period, from August 2017 to January 2018, when R1-B&B went live on 7 September 2017. As a stand alone point of principle, this is not a good one. A delay in period X can plainly cause a loss in period Y. The fact that the loss is incurred in a later period does not mean it cannot be recovered as damages caused by a preceding delay.

The second argument is, however, that the reason the DBS costs were incurred was not because of the delay per se, but because Disclosure Scotland reduced its staff and facilities not knowing that DBS intended to extend the delegated powers under which Disclosure Scotland was carrying out its work. As Ms Graves accepted fairly in evidence, it was not TCS’s responsibility to liaise with DBS Scotland. Ms Graves was taken to a number of documents which dealt with discussions between DBS and Disclosure Scotland about extensions, but was unable given her lack of direct knowledge to shed light on their context.

One such document was R1 and Basic Consultation Meeting Minutes dated 14 June 2017. These stated:

Ms Graves’s evidence in relation to this was as follows (Day 14/193):

There is very little transparency within either the brief, largely second hand evidence from Ms Graves, or from the disclosed documents, to establish a proper causal link between the costs incurred in sending staff to Scotland in the latter months of 2017 and early 2018 and the delay. At best it seems clear that staff were sent to Disclosure Scotland for a number of reasons, including the need to assist with transition which is entirely unrelated to the complaints about delays. There is also no proper evidence to link the fact that DBS failed to communicate with Disclosure Scotland about the period of delegation extension in a timely way to a failure on the part of TCS (e.g. in failing properly to inform DBS of anticipated delays) as opposed to the mere fact of the delay itself. These are not matters of failure to mitigate: they are matters of basic causation. In my judgment, DBS has failed to prove a causal link between the breaches relied upon (the delay to achieve the Basics R1 Milestone) and the losses claimed, which the evidence suggests would have been incurred wholly or materially in any event.

In the circumstances, DBS’s claim in relation to Disclosure Scotland fails.

DBS claims that it had to retain a number of temporary staff members to perform Barring work between October 2016 and September 2017 due to the delayed delivery of R1 Barring. This is Schedule of Loss item 3. There are also loss of anticipated savings claims relating to R1 Barring Portal Quality Issues (Schedule of Loss item 11) and to R1 Barring Standards/Quality Costs (item 24).

The claimed sum is £1,971,434. Mr Hain’s assessment is £2,424,934.

As explained by Mr Hain in his First Report, DBS’s claims for loss of anticipated savings in respect of R1 Barring rely on two documents: the Workforce Planning Model (or ‘WFPM’) v15.6 and an analysis of staff costs incurred (‘Barring Payroll Analysis’). DBS contends that these two documents provide the Court with (1) DBS’s best estimate of the efficiency savings expected had a compliant Barring Portal and Solution been delivered (the WFPM) and (2) the difference between workload prior to and after delivery of the Barring Portal and Solution.

Mr Hain also explained that DBS had estimated the lost efficiency by carrying out the following assessment:

As such, the FTE %Removed and FTE %Decreased calculated by reference to the WFPM is a fundamental part of the assessment.

In relation to the delay period, the loss is explained as having been calculated as the anticipated savings for the six month period from October 2016 to March 2017, plus 50% of the anticipated savings for April 2017 to March 2018, approximating to the period from April 2017 to September 2017.

In his witness evidence, Mr Gergely, who was a central witness in relation to the WFPM, said as follows (para 34):

Whilst accepting it was not ‘a perfect reflection’, Mr Gergely considered that it was nevertheless usable, in his view, for the purposes of the loss of anticipated savings assessment.

No doubt at least in part on the basis of this evidence, there was, as DBS points out in its Written Closing Submissions a measure of agreement prior to Mr Gergely giving evidence at trial as to the expected efficiency savings on the basis of the WFPM. As recorded at Section 6.3.1 of the Joint Statement, Mrs Wall recorded that,

Mr Gergely was however crossed-examined at some length on the chronological development of the WFPM. The starting point is that in around August 2015 (i.e. before any UAT), DBS performed an initial assessment of the changes which would occur in ways of working within DBS following R1. This was known as the ‘Detailed Level Organisation Design’ (or ‘DLOD’). In around early January 2017, DBS used the WPFM to update the DLOD following R1 Barring Go-Live. A column was added to identify whether a task was expected to be removed, be retained, decrease in effort or increase.

As TCS submits, and I find as a fact, it was known at the time that this was an inadequate exercise. The WPFM included important caveats, all of which were agreed by Mr Gergely:

In April 2017, someone called Marta Bergonzini from DBS produced a presentation which stated:

It repeated on slide 5 a number of the caveats and on slide 7 set out planned improvements to the ‘rough view’:

Slide 8 indicated that there had been little validation of duration of activities and ‘the level of confidence is low’. It is particularly relevant that DBS were themselves indicating that using actual data collected from the first few months of operations would improve future headcount estimates. Mr Gergely agreed in cross-examination that it was clear, at this point in time, that a new version of the WFPM needed to be created.

DBS’s Operational Organisation Design Document v0.2 dated 14 June 2017 indicated that it had not been possible to assess the full end to end functionality of R1 for the purposes of workforce modelling, and that DBS anticipated that as it moved into the next phase of R1 delivery (training for staff), it would be possible to better assess the impact on workforce and the ability to realise the theoretical business benefit. It was recorded at this time that this would form the basis of the next review of this document for Operations (Barring).

The DLOD dated 13 July 2017, indicated that, ‘a number of additional processes (or temporary workarounds) will need to be added post R1, until all operational areas have gone live. The exact impact of the decreases (in terms of potential FTE reduction) require further investigation by Business Analysts with the required level of R1 knowledge to determine any time savings. As yet it has not been possible to make any accurate assessments within the testing environment.’

There remained, therefore, a significant amount of uncertainty about the estimates, as explained during cross-examination by Mr Gergely (Day 13/49):

In October 2017, an internal DBS presentation indicated the work that it was then anticipated was required in order to revise and correct the DLOD assumptions, as reflected in the following slide:

Mr Gergely accepted that these tasks would need to be carried out in order to work out what the anticipated savings might be (Day 13/64):

In relation to a review Mr Gergely undertook in October 2017, he also gave the following evidence about the (un)reliability of the document as then perceived contemporaneously (Day 13/55):

Mr Gergely undertook a review of the WFPM following Go-Live. He was cross-examined in relation to a document produced after Go-Live in which an number of the assumptions in the 19/01/17 WFPM had not been borne out. One of these related to the Disclosure Information Team (or ‘DIT’) in respect of which the document showed an anticipated removal which had yet to occur or, indeed, in respect of which activity effort had increased.

This line of cross-examination led to the following exchange in which Mr Gergely explained that, with the benefit of hindsight, the document did not produce a figure which DBS could rely upon (Day 13/60):

This fair evidence merely reflects, in my judgment, the view expressed by Mr Gergely’s email of 15 November 2017, following his contemporaneous review, when he wrote:

Equally important was Mr Gergely’s evidence confirmed that it was after DBS had a live system that they could properly assess the work required to produce Barring Case work (Day 13/65):

I accept the submission of TCS that, on the basis of this factual evidence, Mr Gergely effectively disavowed the evidence in his witness statement that the WFPM was a ‘usable estimate’, at least in the context of the claim DBS is advancing. On any view, in my judgment, it is clear that, even as a working or rough estimate at the time, it suffered from considerable uncertainties and was shown, shortly after Go-Live, to have contained flaws, none of which have been addressed or corrected by DBS in its use of the document to underpin its claim. It is right that Mr Gergely had already accepted at paragraph 36 of his witness evidence that post Go-Live, he was concerned that the WFPM was not a suitable baseline to calculate the R1 impact because the processes were so different: however, this does not mean that the Court should conclude, as DBS contend, that the WFPM nevertheless is an appropriate basis upon which to calculate a delta which reliably represents a loss of anticipated savings. In my view, it plainly is not.

Whilst the foregoing conclusions apply to all the loss of anticipated savings claims, the particular context of Updated Schedule of Loss item 3 is the delay claim. In the context of a delay claim, the use of an estimate of savings is particularly problematic, even if it were reliable (which in this case, it was not). This is because, as Mr Gergely accepted, there would exist better evidence as to the actual time taken by tasks post-Go Live which can be compared with actual data about the amount of time taken in relation to the R0 system. The starting point for the quantification of the actual loss caused by the delayed introduction of savings can (and should) be calculated by reference to the actual savings that were, because of the delay, not (actually) generated as soon as they would have been. Taking a simple example, if post Go-Live the evidence demonstrated the efficiencies from the introduction of R1 actually generated an ability to reduce the workforce by 10 FTEs, then this is the lost actual saving caused by the delay for the relevant period of delay (no doubt taking into account the fact that the actual savings may not have been immediate). Even if the WFPM was not of itself unreliable as an estimate (as it plainly was), a claim for actual losses caused by a delay should be assessed by reference to actual, not estimated, losses when the evidence plainly exists to have permitted such an assessment.

Moreover, it is plain that even if (contrary to my conclusion) it would have generally been appropriate to advance an analysis based upon the (unreliable) WFPM in order to generate a percentage expectation of reduction which is then applied to actual costs, the evidence of what actually happened during the period of the claimed delay demonstrates that it is clearly the wrong approach on the facts.

Mr Gergely confirmed in his witness evidence (at paragraph 35) that DBS had already allowed staff numbers to drop by around 48 people in anticipation of making savings, as shown in the WFPM v15.6 as at 31 October 2016 (i.e. the commencement of the period of delay). Mr Gergely also confirmed in cross-examination that the figures of actuals within the WFPM were accurate. Although, as he continued to explain in his statement, DBS considered taking on short term agency staff in the lead up to Go-Live in order to make up for the reduced headcount, DBS decided to stick with the numbers they had, and to rely upon DBS’s fixed-term appointments and staff overtime in order to meet the workload. There is no evidence, therefore, that any people were hired due to the delays, in circumstances where DBS had already put into effect what it anticipated to be the staff savings. Mr Gergely’s factual evidence was that 12 people were then added after Go-Live rather than before.

There is no basis, given these facts, to attempt to assess delay prior to Go-Live by anticipated savings by reference to the theoretical percentages applied to actual costs derived from the WFPM. The evidence is that anticipated staff savings had already been made. One basis of claim could have been, on the basis of this factual evidence, based upon the overtime paid to the (reduced) workforce because efficiencies did not commence as soon as anticipated. That was, after all, the manner in which DBS actually sought to address the problem caused by delayed introduction of the new systems. But no such claim has been advanced and the Court has no proper basis upon which it could carry such an exercise out.

In the circumstances, because of, but also irrespective of, the unreliability of the WFPM in terms of its forecasts, I conclude that the claim for anticipated savings as a result of R1-B&B as advanced by DBS is fundamentally flawed and fails.

DBS’s claim for Loss of Basics Contribution has not been pursued.

DBS claim sums capped at £10m for delays between 28 November 2017 and 19 September 2018 which the Schedule of Loss describes as costs relating to ‘non-delivery’ of R1-D.

On the basis of my findings, TCS were not responsible for Delay in excess of 6 months from the date of the commencement of TCS’s claim (28 November 2017), for the purposes of Clause 6.3. This means that DBS is not entitled to a general damages claim.

Even if DBS is correct in its (unexplained and unpleaded) case that the Milestone should be treated as having remained as 28 November 2016 as opposed to 28 November 2017, which is the date from which its claim for delay commences, and a claim for general damages for delay to R1-D is permissible in principle, it is permissible only for the period from 28 November 2017 to 5 February 2018, from which point on DBS is estopped from claiming that TCS is in culpable delay and (from 13 June 2018) there is ‘AUTHORITYCause’ which precludes any claim for breach by DBS. I have also found that TCS is not responsible for non-delivery of R1-D after it had been unlawfully removed from its scope of work and/or that (contrary to my primary analysis) this period would in any event amount to ‘AUTHORITYCause’. The costs of maintaining or refreshing its existing R0 platform were caused by DBS’s wrongful removal of R1-D from 19 September 2019 and are not recoverable. If DBS had not removed R1-D, TCS would have taken (as I have found) around a year to complete R1-D. During this period, TCS may (but for DBS’s failure to have complied with Clause 6), have been liable for Delay Payments. However, as at the date of the wrongful removal of R1-D, that entitlement lay in the future, in respect of delay beyond the Milestone Date which had not yet accrued.

Against this, I consider the heads of loss pleaded as Schedule of Loss items 4 to 8.

This is pleaded in the sum of £9,653,107. The sum supported by Mr Hain is £8,509,192 in his First Report. The Joint Report (Appendix G, Row 12) states that the experts agree that £8,77,866 has been incurred and paid in relation to this item, and this is the amount claimed.

As made clear by Mr Hain in his First Report at paragraph 6.2.15, the claimed sums relate to the period 6 April 2020 to 5 April 2023 (although I note that Ms Graves suggests at paragraph 41 of her Third Witness Statement that the costs claimed are ‘from 2018’).

Whilst Mr Hain’s assessed sum, upon which DBS now rely, is arithmetically close to the sum claimed and supported by Ms Graves, Mr Hain has adjusted the claim significantly by (a) increasing the claim by c£3m to reflect costs from 6 April 2023 to 2024; (b) increasing the sum claimed by c£6m to account for costs between 6 April 2018 to 2020; (c) decreasing the claim by c.£10.3m to account for ongoing R1 Oracle Processor based costs, ongoing R1 annual End User based costs, costs for unsampled charges and a particular issue with a particular invoice.

Therefore, it is clear that the claim is fundamentally different to that pleaded, and supported by factual evidence. This is not mere adjustment by an expert assessing the claim made – it is the expert advancing a new case (one which runs for a period of some 6 years rather than a pleaded case relating to a period of 3 years). This is not the role of an expert.

In any event, the only relevant claim would, in light of my findings above, be for a short period within the 2017-18 financial year in respect of which there is (a) no pleaded case and (b) no factual evidence and (c) no expert evidence (even on the basis of the broader analysis undertaken by Mr Hain).

In the circumstances, the claim fails.

This sum is pleaded and supported by Ms Graves of DBS in the sum of £5,340,938. This is stated to relate to the period from April 2020 to April 2022. The invoices relied upon form the basis of the assessment by Mr Hain and the agreement by the experts that £5,073,793 has been incurred and paid.

These costs do not relate to the only period for which a claim would be valid.

The claim fails.

The Updated Schedule of Loss states that these sums are ‘to be assessed, estimated at £15,517,357’. The costs relate to the work undertaken at DBS’s cost to refresh the legacy R0 systems, including making changes to the WAN, switches, virtualisation, internal networks and internet gateway. None of the costs, either external or internal, relate to the only period for which a claim would be valid.

I add that this element of the claim also demonstrates the difficulty with DBS’s approach at trial to paint these costs as ‘delay’ costs rather than costs attributable (as indeed its pleading describes) to non-delivery of R1-D. This is because, as a matter of causation, these costs were in fact incurred in an environment where DBS’s business strategy was to ensure the R0 infrastructure was maintained for a considerable period into the future, allowing it breathing space to find a new supplier and develop its bigger project of ‘disaggregation’ (i.e. to reduce dependence upon a single supplier). Implicit in the claim that these are costs caused by delayed delivery includes the necessary assumption that the same decisions in terms of what technology refresh to implement would have been made in circumstances where R1-D was going to be delivered, but merely delivered late, rather than not delivered at all. It is an entirely false assumption. Completely different decisions may have been made about what ‘investment’ was required in R0 if the only issue was ongoing delay to the delivery, rather than in the situation driven by DBS’s own strategy where R1-D was not to be delivered at all by TCS, and not delivered by anyone else to any foreseeable timetable. The pleading’s description of these costs – as relating to the non-delivery of R1-D – is therefore correct, and the characterisation in submission of these costs as caused by ‘delay’ is wrong. Even if, therefore, DBS is correct that (contrary to the factual reality) one should characterise the period beyond 19 September 2019 as ongoing delay to the delivery of R1-D (because its Partial Termination was legally ineffective), it would not follow that these costs could be characterised as ‘delay’ costs. Such a conclusion would involve a leap of both fact and logic.

This claim fails.

DBS pleads that at service transfer, many of the software products within R0 needed to be updated due to TCS’s failure to maintain the currency of the software deployed. DBS contends that it has been forced to engage a third party, CGI, to undertake work to update the system, and that this work is ongoing.

The claimed sum of £1,053,759 relates, as Mr Hain explains in his First Report, to 50% of the cost of one CGI purchase order (the other 50% is claimed within the R1 N-1 Sustainment Costs). There is no explanation or evidence which supports a conclusion that any part of these costs relates to the only period for which a claim would be valid. This claim is also a claim properly characterised (as pleaded) as caused by non-delivery, rather than ‘delay’, as explained above in respect of Item 6.

There are, in any event, other fundamental difficulties with the claims, as discussed in relation to Updated Schedule of Loss item 15, further below.

This claim fails.

DBS pleads that it has been required to engage in a number of changes and updates to R0 to improve the security and reliability of data exchanged with R1. The Updated Schedule of Loss identifies a number of projects, and adds that, due to the age of the system, all necessary changes to R0 have been costly to implement. The pleaded sum is ‘estimated’ at £2,843,990.

Mr Hain explains that the costs include (a) CGI claimed costs in the sum of £1,829,974 (b) the replacement of MS Access and Deployed of F5 costs in the sum of £193,000 (c) internal resources in the sum of £230,938 and (d) internal resources relating to security in the sum of £590,078.81. Mr Hain makes various adjustments to the sums claimed.

There is no basis to link, causally, the CGI costs or the replacement of MS Access and Deployed of F5 costs to the period of delay for which a claim is valid.

Mr Hain notes that claimed sums at (c) and (d) relate to a period from April 2017 to March 2022. The claim at (c) is based upon the assumption that the work required equated to 1 FTE SEO and 0.4 FTE EO. The claim at (d) relates, in the majority, to ‘Digital (1 x Contract resource 1 day per week)’ and ‘DSARs (1 x 0.5 AO per week)’. He calculates an adjustment for the 2017-2018 year to excise the costs up to 28 November 2018 which is the date (no doubt on instructions) he said was the date R1 Disclosure was due to go live on. The remaining elements for (c) and (d) for that year are £39,481 and £56,855. A proportion of these sums, therefore, relate to the period from 28 November 2017 to 5 February 2018. The sums are far below the sums that would have been recovered by way of Delay Payments (had DBS complied with Clause 6), and so (even if appliable) no claim for proven additional damages exists.

This claim fails.

In light of my findings above, it is not necessary for me to address the parties’ procedural submissions about whether TCS was entitled to advance a case based on purported savings made or anticipated to be made by de-scoping R1-D (whether an amendment to the pleadings was required and if so whether it should be permitted). In circumstances where it is not necessary for me to do so, I will resist the temptation to.

DBS’s Defects Counterclaims

The remainder of DBS’s Counterclaim relates to alleged quality or contractual non-compliance issues by TCS. The categorisation within the Updated Schedule of Loss is as follows:

None of the individual item claimed amounts exceeded £10m. It can be seen that, as grouped within the pleading, however, R1 Basics Portal Quality Issues together exceeded £10m. The DBS Re-Amended Rejoinder did not engage with how (on DBS’s case) the multiple £10m caps applied, other than to plead generically to the construction point, asserting that it limited the liability for each and every claim ‘i.e. cause of action’. It might be implied (given its denial that, on its construction, the cap applied) that DBS was contending that none of its claims were capped and that, notwithstanding its grouping, each item (or, effectively, head of loss) was treated as recoverable individually and below the cap.

The categorisation summarised in the Spigelman Schedule provided by DBS in Closing adopted the following categorisation and quantum (and numbering by reference to row):

I make no criticism whatsoever about a recategorization of the claims within the structure of the Spigelman Schedule. I also emphasise that this comparison of presentations formed no part of my consideration of the proper construction of Clause 52.26, dealt with above. However, the different groupings and application (/non-application) of the cap does neatly demonstrate how DBS’s construction seems unworkable. DBS’s own application of caps is in no way tied to ‘causes of action’. The losses claimed derive from numerous separate alleged breaches, some one off, and some continuing, each of which (when sounding in damages) would give rise to separate causes of action. The workability of the clause, as advanced by DBS, depends upon undefined and somewhat arbitrary grouping of breaches into themes – which could be done in a myriad of different ways, as demonstrated by DBS’s own differing approaches. It gives comfort to my conclusion that, whilst the language of Clause 52.2.6 was generally infelicitous, TCS’s construction is preferable. DBS’s construction leads to the question: how does the cap apply in practice? DBS’s own application(s) of the cap does not appear to present a robust answer to that question.

The ‘Basics Portal’ refers to the functionality that would allow a citizen to apply for a Basics disclosure certificate This was a limited set of screens that was to be provided by TCS as part of the overall Web Portal, which would also include the ‘Barring Portal’. The Barring Portal was intended to support organisations who needed to refer individuals to DBS.

The IT experts agreed that there were improvements that could have been made to the useability of the initial release of the portals. They disagree on whether the need for such improvements represented a failure by TCS.

DBS relies upon a series of specific express obligations with regard to the Portals, as set out in the Contractor Solution at Schedule 3. By Clause 9.1.12 of the Agreement TCS was obliged to ensure the Services provided were in accordance with the Solution. The terms relied upon in Closing by DBS are:

In its Closing Submissions, DBS placed particular emphasis upon the requirements that the portals are clear, intuitive and optimised for efficient use, and customised for each type of user, as required by Clause 1.2.1.1.

DBS also rely upon Clause 9.3 by which TCS was required to perform the Services in accordance with, amongst other things, Good Industry Practice (Clause 9.3.1). “Good Industry Practice” (‘GIP’) was defined in Schedule 2-1 as

DBS sought to draw a distinction between the requirement of GIP which is, contractually, pegged to that which would be expected from a ‘leading’ company within the sector and the test applied by Mr Britton on the basis of the following exchange (Day 19/94):

The distinction between what a ‘large systems integrator or large development house’ and a ‘leading company’ was not explored further, and it is not obvious whether the distinction, in the present case, means much. Notwithstanding, when considering Mr Britton’s evidence in context, I have been acute to the possible application of a slightly less demanding obligation when he has considered the question of his views on compliance with GIP.

By way of generality, TCS is correct that, to the extent that DBS’s case equates the existence of defects in the software without more to a failure to adhere to GIP, either in design or testing, this would not be correct. This was confirmed by Dr Hunt, in cross-examination, whose evidence I accept in this regard (Day 19/138 -140):

This broadly accorded with the evidence given by the experts jointly in their statement that ‘the simple existence of defects or problems in a design is not in itself evidence of a failure to meet Good Industry Practice, but that poor practice makes it likely there will be more such problems in more areas of the system’.

This was also accepted, specifically in relation to the delivery of the portals, by Ms Keenaghan (a DBS Project Manager at the time) in cross examination (Day 12/103).

There was an issue of principle between the parties as to whether TCS was required to comply with the Government’s Design by Default (or ‘DbD’) Standards.

A ‘poster’ format of the 18 principles applicable as of 19 March 2016 was included in the supplemental report of Mr Britton:

As will become clear, DBS’s case on breach of DbD was limited to 5 of the DbD principles: 1, 2, 7, 9 and 12 (as explained by Mr Croall in oral Opening Submissions).

The IT experts agree that the DbD standard describes sensible principles and processes that if applied appropriately should help achieve a high-quality result, and that many of these, including for example researching user needs, building a working prototype and testing the end-to-end service, can be used regardless of the software development methodology that is adopted. At paragraph 40 of the Joint Statement, Dr Hunt’s view was stated to be that many of principles set out in the GDS Digital By Default standard should be used as part of Good Industry Practice (my emphasis: DBS overstated the position in its Written Closing Submissions by suggesting in this paragraph Dr Hunt’s position was simply that ‘the DbD standards reflect Good Industry Standards’).

It is of note that of the principles which DBS does not rely, it is principles 4 and 5 which would have required the Solution to be build in an ‘Agile’ methodology, so as to provide a service that can be iterated and improved on a frequent basis. As Mr Sands, a technical architect employed by DBS agreed, the DbD standard is very much focused on ‘Agile’ as a methodology.

‘Waterfall’ and ‘Agile’ refer to two different development approaches: adopting, as I do, TCS’s summary within their Closing Submissions of the explanation given in Mr Britton’s report of the two approaches: ‘Waterfall’ is characterised by successive lifecycle phases for each release (i.e. requirements, design, build, test, deploy); ‘Agile’ involves short sprints during which parts of the system (usually discrete pieces of functionality) are taken from being a requirement to being ‘Done’ (i.e. built, tested and accepted).

TCS’s contracted approach as set out in Schedule 3 (Contractor’s Solution) to the Agreement was as follows:

This was further described in TCS’s Solution Support Document, which stated:

As confirmed by Dr Hunt, the experts broadly agreed that TCS was contracted to use a ‘modified’ Waterfall approach rather than an ‘Agile’ approach:

This is consistent with the contemporaneous analysis of Mr Sands, of DBS, when assessing the Solution against DbD requirements in June 2016:

Whilst DBS does not advance a case that TCS breached the Agreement by failing to adopt an ‘Agile’ methodology, the distinction between the two approaches gains some significance in the context of this case when assessing whether, in due course, DBS’s decision to remove the Basics Portal from the scope of TCS’s service and replace it themselves was caused by/reasonable in light of useability issues (so as to support its counterclaim for the costs of doing so from TCS) or whether they did so in pursuance of their broader strategic aim to comply with GDS’s broader ‘DbD’ objectives.

In light of the reliance placed on some of the failures to comply with DbD in its case on breach, it is necessary to resolve the anterior issue of whether compliance with DbD formed part of TCS’s contractual obligations.

Relevant provisions of the Agreement are as follows:

Clause 1.1.4(b) to Schedule 3 stated that

The Standards Catalogue was approved as v1.0 on 21 August 2014. It stated:

As part of the Catalogue, there was an embedded spreadsheet (‘Appendix A’) referenced in Section 9, which stated:

The spreadsheet contained the following row:

The text in the fourth column from the left (column D) replicated the first two lines of Section 7.1.1 above under the heading ‘Description’. This is a short description of the standard referred to. Column I was headed ‘Requirements’. This was blank. Column J was headed ‘Requirement reference’. This contained ‘CCN TBA’ (i.e. Contract Change Notice To Be Approved).

The ‘Requirements’ column (column I) generally described the nature of TCS’s requirement to comply with the standard described in column 4, and ‘Requirements Reference’ column (column J) indicated the source of the requirement. Take the following extract by way of example:

There are also various rows in which there is a description of a standard, but the ‘Requirements’ section is ‘NA’ and the ‘Requirement Reference’ is ‘None’. There are also line items which are ‘greyed out’ with a comment ‘Removed following DBS (LB) review comments’ e.g.

The other category of row items was where there was a clear identification and description of a standard, together with a Requirement, but there was not a cross-reference to the Agreement as the source of the ‘Requirement’: rather, it was the ‘Standards Workshop R1’ e.g.

The issue is a short point of construction involving the identification of the objective meaning of the above contractual terms. As set out in slightly greater detail earlier in this judgment, it is well established in this context that the Court’s task is to ascertain the objective meaning of the language which the parties have chosen to express their agreement (Wood v Capita Insurance Services Ltd [2017] UKSC 24; [2017] AC 1173) and that where parties have used unambiguous language the court must apply it (Rainy Sky SA v Kookmin Bank [2011] UKSC 50; [2011] 1 WLR 2900). DBS also draws to the Court’s attention, in terms of principles to be applied, the requirement that the Court should strive to read provisions together and not find inconsistencies. DBS, further, states that where a document incorporates the terms of another (which DBS says must be TCS’s case) the terms of the main/host document i.e. the Catalogue will prevail (see e.g. Modern Building (Wales) Ltd v Limmer & Trinidad Co Ltd [1975] 1 WLR 1281).

DBS contends that the language used is unambiguous, relying on the words ‘non-negotiable’ and ‘mandatory’. It is argued that the language at Clause 1.6 (Constraints) contains no language contradicting or in any way qualifying the express requirements they rely upon. In relation to Appendix A, DBS contends that the spreadsheet itself cannot bear the weight TCS place on it, and in particular Cell D in the relevant row pertaining to DbD (i.e. the description column above) provides ‘more support’ for the obligation to comply with DbD, leaving only the column setting out the reference to the requirement – Cell J. ‘CCN TBA’ is not the kind of language required, it is said, to change the requirements set out clearly in the Catalogue. It is argued that the column ‘merely purports to identify (whenever the spreadsheet was produced) the provenance of the requirement.

In my judgment, the Agreement can be read together without inconsistency. It is plain from the face of the Agreement that, as at the Effective Date, the parties were required to agree the final Standards Catalogue which was to apply. By reference to Clause 12.1 and the definition of ‘Standards’, a standard only applied if it was referred to in Schedule 2-12, or, by reference to Clause 2.1 of Schedule 2-12, the Standards Catalogue. The ‘Standards Catalogue’ would be a single (and, subject to change control, live) ‘authoritative’ document which set out the applicable standards. Appendix A was an integral part of the Standards Catalogue, and it is clear on its face (and by Clause 9 of the Standards Catalogue) that it was derived from discussions with the Authority during the Standards Non Functional Workshop.

DBS’s analysis is limited to a focus on cells D and J of the relevant row of spreadsheet, and draw their conclusion that little weight can be attached to the document accordingly. However, this is a blinkered analysis. It is tolerably clear from the document looked at as a whole that it represents the product of the procedure laid down in Clause 2.1.1.1 of Schedule 2-12. A critical column – entirely ignored by DBS – is in fact column ‘I’ which sets out the ‘Requirements’. Column D merely sets out a description of the standard and, of itself, is unimportant. In relation to DbD, the ‘Requirements’ column is blank, and together with ‘CCN TBA’ the intention of the parties is absolutely clear: there was no present requirement upon TCS, pending a CCN. This is supported by looking at the rest of the document: the parties clearly (a) confirmed applicability of certain standards already referred to in schedules to the Agreement, and listed these out (b) agreed to ‘remove’ requirements which were found in the schedules and (c) introduced, via the workshops, new requirements which are not found elsewhere. In my judgment, the ‘authoritative’ Appendix A was (on the basis of my construction of the words used within the relevant contractual document) the checklist produced by the parties intended to reflect which, of all the requirements which may have been referenced in disparate parts of the Agreement and/or otherwise agreed during the process envisaged by Clause 2.1.1.1 of Schedule 12, TCS was contractually required to comply with.

The fact that a small number of the line items were marked ‘CCN TBA’ (i.e. the parties were recording their agreement that there were commercial ramifications which required resolution before being able to fill in the ‘Requirements’ column for those items) is consistent with the Standards Catalogue itself, important elements of which DBS again essentially overlook, when read as a whole. So, whilst Design-by-Default is described ‘mandatory’ and ‘non-negotiable’ in Section 1.6 of the Standards Catalogue, the very same section said, ‘there may be contractual implications in conforming to the standards included within this document, which need to be addressed…’. Whilst ‘mandatory’ and ‘non-negotiable’ are emphasised by DBS, they do not in fact mean anything more or less than ‘required’. It is clear that the parties intended for Appendix A to specify which ‘requirements’ stated elsewhere within the Agreement (including Schedule 3) applied, and where that requirement was to be found in the Agreement (or, if it was not in the Agreement, where the requirement came from). The objective intention of the parties in leaving the ‘Requirements’ column blank, coupled with ‘CCN TBA’, when construed as part of the Agreement, Schedule 12-2, the Standards Catalogue and indeed Appendix A, read as a whole is entirely unambiguous. They were recording their agreement that Design-by-Default was not a requirement pending commercial resolution.

This analysis is supported, in my judgment, by the agreed position that (a) by Schedule 3 to the Agreement, TCS was going to deliver the Solution using a modified waterfall approach and (b) the DbD Standards are very much focused on ‘Agile’ as a methodology, with principle 4 requiring the adoption of an Agile approach expressly. Introducing DbD as a contractual obligation would have, without more, cut across the whole approach to design TCS had proposed, and DBS agreed, to adopt. A modified waterfall process plainly did not comply with principle 4 (as Mr Sands identified). It is unsurprising that it would need to be the subject of commercial negotiations, and its introduction as a contractual requirement through the Catalogues Standard would have created a clear inconsistency with the express obligation to adopt the ‘modified Waterfall’ approach to development.

I should add that I found no assistance in the case of Modern Building (Wales) Ltd v Limmer & Trinidad Co Ltd referred to by DBS. Although not identified by DBS, I assume that reliance is placed upon the passage at 1289F which states: ‘Where parties by an agreement import the terms of some other document as part of their agreement F those terms must be imported in their entirety, in my judgment, but subject to this: that if any of the imported terms in any way conflict with the expressly agreed terms, the latter must prevail over what would otherwise be imported.’ The case involved the question of whether an arbitration agreement was incorporated by sub-contract order which stated merely: ‘To supply adequate labour plant and machinery to carry out, complete, the ventilated and non- ventilated ceilings at the contract site within the period stipulated in the programme of work and in full accordance with the appropriate form for nominated sub-contractors (R.I.B.A. 1965 edition)... ’ on the basis that the standard for to which the words were held to refer (there being some confusion) contained an arbitration agreement. The present case is plainly not one where the parties have imported the terms of some other document into their agreement. The Standards Catalogue is fully integrated part of the Agreement (indeed: it is a defined term), and Appendix A is a fully integrated part of the Standards Catalogue. The analogy with Modern Building (Wales) Ltd does not begin to apply. In any event, as I have found, there are no inconsistencies when proper meaning and effect are given to the Agreement, read as a whole.

Finally, on this issue, I note that TCS rely, in the context of this dispute, upon the fact that their construction reflected views expressed by the parties in their discussions. In exchanges copied to the TCS owner of the Standards Catalogue (Gurupratap “Guru” Dsor), DBS’s Giles Gamon (a participant in workshops) said that:

They also rely upon the cross-examination of Mr Sands who confirmed his understanding of the discussions, and that DbD was subject to commercial agreement between the organisations (Day 13/75).

Whilst this material reflects that there were communications which ‘crossed the line’ between the parties in advance of the agreed Appendix A which is entirely consistent with what, in due course, that Appendix showed, in circumstances where it is unclear if these views were also reflected in the ‘Slides presented and notes gathered during the standards workshops conducted with DBS’ expressly referenced with the Standards Catalogue at item 5, it would not be appropriate for me to take the discussions into account when construing the Agreement, and I do not do so.

DBS’s pleaded case is that the Basics Portal designed by TCS was rejected by DBS because of its inadequate quality, and because it did not comply with GDS standards, including DbD. Following the rejection of the Basics Portal, DBS aver that Mr Charles of IBM suggested that DBS would be able to develop GDS-compliant screens itself. A prototype was built by DBS with the assistance of GDS and presented to TCS, but DBS allege that TCS declined to change the work it had done on the Basics Portal. It is then pleaded that as a result of these issues, DBS decided to remove the Basics Portal from TCS’s scope of work and to design the Basics Portal itself. The Basics Portal designed by TCS has never been used.

Neither expert was in a position to evaluate the Basics Portal itself because neither had seen it. All Dr Hunt saw and evaluated was the list of useability issues that were identified by DBS, by IBM and by GDS at the time.

The issues identified by IBM related to a review carried out seemingly informally in August 2016. Mr Craven of IBM emailed Ms Keenaghan of DBS stating, ‘I went through the prototype pages earlier this week and noted a few bits down. Not sure if they will be useful for the heuristic review or not’. The attached PDF attached 7 pages of screenshots with around 12 comments in red, such as the following:

Louise Bartlett, a User Researcher for the Home Office also carried out a ‘Assessment of DBS Basic Application’ and provided a presentation on 15 August 2016. This stated that the digital team had been asked to provide advice and support to the DBS project, prioritising the work on the ‘basic’ service at that point which had a go-live date of 1 January 2017. There were a number of ‘detailed findings’ which identified useability issues. For example:

The review also identified 12 additional ‘user journeys’. These were essentially functionalities that were not available. By way of example, 2 of the 12 related to the user being able to grant consent to a third party/employer so the other party could view the certificate; and 3 related to third parties being able to log in and view an applicant’s certificate. The absence of these appears to have fed into Ms Bartlett’s ‘high level’ criticism that the project was ‘seen as ‘digitalising’ a paper process, not improving it’. However, I note that, as explained by Lisa Keenaghan, who was a DBS project manager at the time, when DBS’s replacement served was launched following the removal from TCS, the solution did not even provide for a user (let alone a third party) to go online and access and view their certificate: they had to await a paper certificate. This was on the basis that it had been determined by DBS during their ‘discovery phase’ that these aspects of the service, whilst providing a better service, were not critical to the disclosure check taking place. These were regarded as ‘new features’ with prioritised development for the future.

The high level finding also concluded:

The Home Office review then tabulated their perception of TCS’s compliance with the 18 DbD principles, and concluded that apart from ‘some’ compliance with principles 6 and 7, none of the criteria were met. I have found that there was no obligation to comply with DbD. However, as identified above, there is cross-over between some of the DbD principles and GIP. In my view, a failure by TCS to have understood user needs (principle 1) would generally be a failure to comply with GIP. That said, it is also the case that the particular elements of missing functionality identified by Ms Bartlett (and reviewed by Dr Hunt) were not tied back – either at the time, or as part of DBS’s case - to any prescriptive requirements identifiable within the Agreement, and there is necessarily a degree of subjectivity around what ‘user needs’ may be. As Mr Britton points out, it is not clear on what basis Ms Bartlett (who did not give evidence) concluded that this functionality was contractually required. The presentation itself provided very limited substantiation to enable anyone to understand Ms Bartlett’s justification for her view on DbD compliance. As Mr Croall put in his questions to Mr Britton at one point, there is a difference between functionality and useability. It seems to me that these criticisms really went to functionality (which TCS was reasonable to assume should have been specified) rather than useability.

Although Ms Bartlett’s review is relied upon by DBS against TCS now, the view of David Charles of DBS at the time was that the conclusions were ‘overly harsh’:

DBS was well aware of the gap between the methodological requirements for development to a specification imposed by the Agreement on TCS and the GDS expectations of a solution fully compliant with all principles of DbD.

DBS carried out its own assessment at the time, and provided a useability test report. The output of this was summarised by Angela Maxwell of DBS in an email to Mr Malik of TCS at the time (4 August 2016) as follows:

The presentation produced broke the results down into a number of pie charts, splitting the issues into categories: the ‘High severity’ chart identified 3 aesthetic issues, 5 navigation issues and 4 (testing) guidance issues. It also identified 4 prototype specific issues. Under ‘cosmetic useability’ issues, there were 54 syntax issues (such as an ‘s’ missing off a word) and 11 aesthetic issues. The next step was stated as being: ‘DBS to workshop with TCS around usability issues and timescales for fixes.’

It is, of course, important context that at this point, in around August 2016, TCS was still in the middle of the testing phases. It was clear that changes would be required coming out of the test phases, and TCS had indicated that it was prepared to ensure the necessary changes could be implemented prior to Go-Live on 1 January 2017. As reported in the R1 Project Board minutes of 3 August 2016: