1. 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 4December 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.

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

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

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

The Factual Witnesses

5. 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’ [1]).

Expert Evidence

IT experts

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

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

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

Programming Experts

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

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

Forensic Accounts

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

The Parties Submissions

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

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

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

B. Issues of Construction of the Agreement

Principles Applicable to Issues of Construction

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

16. 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:

‘i) The court construes the relevant words of a contract in their documentary, factual and commercial context, assessed in the light of (i) the natural and ordinary meaning of the provision being construed, (ii) any other relevant provisions of the contract being construed, (iii) the overall purpose of the provision being construed and the contract or order in which it is contained, (iv) the facts and circumstances known or assumed by the parties at the time that the document was executed, and (v) commercial common sense, but (vi) disregarding subjective evidence of any party's intentions - see Arnold v. Britton 6 [2015] AC 1619 per Lord Neuberger PSC at paragraph 15 and the earlier cases he refers to in that paragraph;

ii) A court can only consider facts or circumstances known or reasonably available to both parties that existed at the time that the contract or order was made - see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 20;

iii) In arriving at the true meaning and effect of a contract or order, the departure point in most cases will be the language used by the parties because (a) the parties have control over the language they use in a contract or consent order and (b) the parties must have been specifically focussing on the issue covered by the disputed clause or clauses when agreeing the wording of that provision - see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 17;

iv) Where the parties have used unambiguous language, the court must apply it - see Rainy Sky SA v. Kookmin Bank [2011] UKSC 50 [2011] 1 WLR 2900 per Lord Clarke JSC at paragraph 23;

v) Where the language used by the parties is unclear the court can properly depart from its natural meaning where the context suggests that an alternative meaning more accurately reflects what a reasonable person with the parties' actual and presumed knowledge would conclude the parties had meant by the language they used but that does not justify the court searching for drafting infelicities in order to facilitate a departure from the natural meaning of the language used - see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 18;

vi) If there are two possible constructions, the court is entitled to prefer the construction which is consistent with business common sense and to reject the other - see Rainy Sky SA v. Kookmin Bank (ibid.) per Lord Clarke JSC at paragraph 2 - but commercial common sense is relevant only to the extent of how matters would have been perceived by reasonable people in the position of the parties, as at the date that the contract was made - see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 19;

vii) In striking a balance between the indications given by the language and those arising contextually, the court must consider the quality of drafting of the clause and the agreement in which it appears - see Wood v. Capita Insurance Services Limited [2017] UKSC 24 per Lord Hodge JSC at paragraph 11. Sophisticated, complex agreements drafted by skilled professionals are likely to be interpreted principally by textual analysis unless a provision lacks clarity or is apparently illogical or incoherent– see Wood v. Capita Insurance Services Limited (ibid.) per Lord Hodge JSC at paragraph 13; and

viii) A court should not reject the natural meaning of a provision as correct simply because it appears to be a very imprudent term for one of the parties to have agreed, even ignoring the benefit of wisdom of hindsight, because it is not the function of a court when interpreting an agreement to relieve a party from a bad bargain - see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 20 and Wood v. Capita Insurance Services Limited (ibid.) per Lord Hodge JSC at paragraph 11.’

17. 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:

‘The fact is that in the present case we have no evidence of why specific changes were made, nor any evidence that the parties turned their minds to the differences between the two forms and there must be a real likelihood that they simply reached for the current form without any consideration of the earlier version. … In my view the right course when seeking to ascertain the intention of the parties is to consider this contract on its own terms against the commercial background as it existed at the time it was made.’

18. 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 Defendant’s Obligations and Responsibilities

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

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

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

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

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

(1) Clause 5:

‘5.1 The parties shall collaborate in an environment of mutual respect and cooperation…

5.2 Subject to confidentiality and other similar obligations, the parties shall 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. The parties shall use all reasonable endeavours to meet the timescales as may reasonably be established for the provision of such information and to ensure the accuracy of the information provided’.

(2) Clause 15:

‘INTERACTION WITH ICT SERVICE LINES

15.1 The CONTRACTOR shall provide Services for each AMS service line for which it is the Service Line Provider.

15.2 The CONTRACTOR shall interact with the Other Service Line Providers and carry out any required obligations identified and described in Application Management Responsibility Matrix.

15.3 The CONTRACTOR shall, subject to any obligations of confidentiality and to the protection of the CONTRACTOR’s Intellectual Property Rights, share all information reasonably required by any Other Service Line Provider for that Service Line Provider to discharge their obligations. This information may include but not be limited to:

15.3.1 design specifications; and

15.3.2 Service management information (for example capacity reports and security information).

15.4 Each Service Line Provider will provide advice and guidance in accordance with the Service Model in order to facilitate the smooth integration of Services impacting other relevant Service Lines, including the integration of ICT projects (including on-board and off-board of Services) where they impact any Services delivered by the AUTHORITY, Other Service Line Providers, or third party suppliers in particular to:

15.4.1 ensure compatibility and consistency across Service

Lines and associated solutions;

15.4.2 minimise disruption to the AUTHORITY’s staff and operations;

15.4.3 in the event that the above advice and guidance for the integration of an ICT project requires a Service Line Provider to either: go beyond a reasonable level, such that their ability to provide the agreed Service is affected; or go beyond such advice and guidance, then this work shall be undertaken in accordance with the HOT Service Model Change Management process, as appropriate’

15.5 Each Service Line Provider will undertake the HOT Service Model Change Management process, as appropriate:

15.5.1 co-ordinate one or more projects with change impact analysis which will affect the AUTHORITY’s Services;

15.5.2 undertake planning and scheduling with change impact analysis due to projects being undertaken by Other Service Line Providers;

15.5.3 assist in the development of appropriate contractual terms for third parties introducing technologies into the AUTHORITY’s environment as necessary to facilitate the introduction support and maintenance of new Service Lines, Service Line Provider, Services or solutions required by the AUTHORITY.

15.6. The Service Line Provider shall (subject to any obligations of confidentiality and the protection of the Service Line Provider’s Intellectual Property Rights) work collaboratively and openly together, and with the AUTHORITY’s staff as required to support the Service Model and to deliver the Services efficiently and effectively’.

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

25. 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’.

26. 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:

(1) there is simply no natural and ordinary language which states that these clauses amount to a warranty by DBS in respect of the actions of Other Service Line Providers. The absence of such language is a powerful indicator that the parties’ intention was not that these clauses created a warranty for the benefit of TCS;

(2) this is particularly so where there is a specific part of the body of the Agreement which is dedicated to ‘Warranties’ (Clause 45), which also excludes all warranties ‘[e]xcept as expressly stated in this Agreement…’;

(3) the clause imposes obligations on ‘Each’ Service Line Provider in relation to (amongst others) ‘Other Service Line Providers’. ‘Other Service Line Providers’ is a defined term. It means, ‘any supplier other than the CONTRACTOR which delivers services equivalent to the Services to the AUTHORITY…’. If ‘Other Service Line Providers’ means every Service Line Provider other than TCS, the reference to ‘Each Service Line Provider’ in the Agreement can only be a reference to TCS;

(4) the natural meaning of Clauses 15.4 to 15.6 (and Clause 14.9 which is worded in a similar way, by reference to ‘Each Service Line Provider…’) is that the clause sets out what all Service Providers are required to do, and given that TCS is a Service Provider in respect of the specific Services forming part of the Agreement, TCS must therefore comply with these clauses for the benefit of DBS, not that DBS warrants that others will comply for the benefit of TCS;

(5) the strongest point of construction as a matter of language in favour of TCS’ position is that these clauses start with ‘Each Service Line Provider’ rather than saying more simply (for example) ‘The Contractor shall…’ (in contradistinction to Clause 15.1 to 15.3). However, this anomalous wording is not sufficient, by itself, to permit a construction that these clauses impose by way of warranty a liability upon DBS;

(6) the natural meaning of the clauses is supported by the fact that they provide for very specific and somewhat limited obligations. Even if read as TCS contends for, they do not generally warrant HPE’s performance as between TCS and DBS. In reality, the reading that TCS intends (which is complete responsibility on the part of DBS for any failure of HPE) would require (ignoring the absence of words specifically referring to a warranty) that Clause 15.1, 15.2 and 15.3 should start ‘Each Service Line Provider’;

(7) furthermore, at least some of the requirements make little or no sense if the clause is read as a warranty by DBS for TCS’ benefit: for example, why would (at Clause 15.4.2) DBS warrant to TCS that Other Service Line Providers would minimise disruption to DBS’s staff and operations (as opposed, if anything, minimising disruption to TCS’ staff and operations)?

27. 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:

(1) Clause 15.4 relates specifically to the provision of ‘advice and guidance’ in accordance with the Service Model in order to achieve certain ends. Notwithstanding the assertion at paragraph 33.2 of the Amended Particulars of Claim, TCS’ pleaded case does not identify what advice and guidance ought to have been provided, but was not, or was provided wrongly, and so does not identify by reference to this particular obligation the specific act or omission on the part of HPE that falls to be considered a breach of warranty on the part of TCS.

(2) Clause 15.6 comprises (if TCS were right) a warranty to TCS that HPE would work ‘collaboratively and openly’ with TCS, and with DBS, as required to support the Service Model and to deliver the Services efficiently and effectively. However, notwithstanding the assertion at paragraph 33.3 of the Amended Particulars of Claim, TCS’s complaints are not, in substance, about the absence of ‘collaboration’. I note in this context that the word ‘collaborate’ or ‘collaboratively’ does not appear in any of TCS’s witness statements or expert reports (save in one quotation in Mr Britton’s Third Expert Report). The word ‘collaboratively’ does appear in some of DBS’ witness statements, when addressing the approach of DBS. Whilst a number of criticisms of HPE and its systems were advanced in cross-examination, it was not put to any DBS factual witness, or to Dr Hunt, that the problems TCS faced were caused by a failure of collaboration.

28. 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:

‘included timeously fulfilling the function of systems integrator, or alternatively appointing [TCS] or a third party to act as systems integrator, and otherwise taking such steps as were necessary to ensure that the activities reasonably expected of a systems integrator were timeously performed. Such activities included:

26.3.1 Defining the high-level design approach for the project;

26.3.2 Defining the approach to integrating components and planning when each supplier needed to deliver its components;

26.3.3 Identifying dependencies between organisations and planning when each supplier needed to deliver its components;

26.3.4 Ensuring that suppliers committed to appropriate delivery dates and turnaround times;

26.3.5 Providing (or procuring) an infrastructure specification so that [TCS] was able to understand what infrastructure components were available, what capabilities they offered, and how they were to be configured;

26.3.6 Implementing reliable and consistent processes for processing infrastructure set up and configuration requests;

26.3.7 Ensuring that the technical infrastructure services that [TCS] was required to use to develop, test and deploy the Solution were fit for those purposes;

26.3.8 Ensuring that the technical infrastructure was built and supported with reasonable skill and care and in accordance with good industry practices.’

29. These are then defined as ‘Systems Integration Activities’.

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

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

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

33. 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:

(1) 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”.

(2) Clause 44.1.3 which requires TCS to:

“…provide to the AUTHORITY’s other suppliers, as are notified to the CONTRACTOR periodically, such reasonable so-operation, information (including and Documentation), advice and assistance in connection with the Services to enable any such person to create and maintain technical organisational interfaces with the Services ….”

(3) Clause 44.2 which states:

“In respect of network, communications, computer or other equipment provided by a third party contractor that do or are required to interface with the CONTRACTOR System, the CONRACTOR shall have primary responsibility for incident and problem resolution including:

44.2.1 ensuring that such requirement does not interfere with the provision of the Services in accordance with this Agreement; and

44.2.2 for taking all necessary steps within its power to ensure that the interface is successfully achieved,

provided that if it is subsequently agreed by the parties, or determined in accordance with the Dispute Resolution Procedure, that the third part supplier should have been responsible, or partly responsible, for resolving the relevant incident, the CONTRACTOR may recover its reasonable additional expenses for resolving the issue to the extent that the third party contractor is agreed or is determined to have been responsible and to the extent that the AUTHORITY is able to recovery an equivalent amount from the relevant third party contractor.”

(4) 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)….’

(5) Clauses 15.4 and 15.6 of Schedule 2-6, set out above, when construed (as they should be) as setting out the obligations of TCS in respect of their interactions with Other Service Providers.

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

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

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

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

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

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

‘any breach of the obligations of any party (including but not limited to fundamental breach or breach of a fundamental term) or any default, act, omission, negligence or statement of any party, its employees, agents or sub- contractors in connection with or in relation to the subject matter of this Agreement and in respect of which such party is liable to the other.’

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

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

42. 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’.

43. 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’.

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

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

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

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

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

(1) in the context of the present case, ‘responsibility’ simply means ‘obligation’. As DBS points out, the word is used throughout the Agreement and wherever it is used, it refers to something that one of the parties is responsible for pursuant to the terms of the contract;

(2) as a matter of ordinary language in the context of a commercial contract, the word ‘responsibility’ is, unless clearly explained otherwise, most likely to mean contractual responsibility, a term which is readily understood and, importantly, a readily ascertainable meaning in any specific scenario;

(3) this is supported by conjunction with the word ‘breach’: the phrase ‘breach of responsibility’ is likely, as a matter of language, to mean breach of an identifiable obligation which is to be found (expressly or implicitly) within the Agreement;

(4) a fundamental difficulty for TCS is that, if it does not mean contractual responsibility, how is responsibility to be defined with any certainty?;

(5) TCS sought in argument to align identification of ‘responsibility’ within the clause to the concept of an act of ‘prevention’. This does not assist it to avoid the conclusion that the word ‘responsibility’ is aligned with contractual responsibility. As made clear in North Midland Build Ltd v Cyden Homes Ltd [2018] EWCA Civ 1744, the ‘prevention principle’ is not an overriding rule of public or legal policy but is the effect of an implied term that acts of hindrance and prevention on the part an employer will be a breach of contract (London Borough of Merton v Stanley Hugh Leach Limited [1985] 32 BLR 51). It is a creature of contract. An act of prevention may be (a) a breach of an express or implied contractual obligation; and also (b) the exercise of an entitlement (such as the giving of an instruction). It will not be the happening of an event for which the parties have otherwise agreed the allocation of risk within the contract. The concept of ‘prevention’ is, therefore, itself rooted in consideration of the parties’ express or implied obligations. In the present case, the word ‘responsibility’ within the term ‘AUTHORITY Cause’ is unlikely to refer to the giving of an instruction where (a) this sits unhappily with the term ‘breach’, but more importantly (b) the parties have agreed a comprehensive scheme for the giving of and complying with instructions through a detailed Change Control Procedure;

(6) in the specific circumstances of this case, TCS’s construction is used to impose general ‘responsibility’ upon DBS for the actions of third parties with whom DBS is in contract, and who are envisaged as interacting with TCS. The parties have, however, expressly turned their mind within the Agreement to how that interaction is to be governed contractually: see, for example:

a) Clause 44.2 dealing with equipment provided by a third party contractor that is required to interface with TCS’s system: a general but otherwise undefined ‘responsibility’ on the part of DBS for the third party’s equipment is inconsistent with the ‘primary management responsibility’ placed upon TCS and/or the specific circumstances in which TCS may claim for its additional expenses (TCS do not bring a claim pursuant to Clause 44.2 in this litigation);

b) Clause 2 which relates to the inspection of the Operating Environment. The ‘Operating System’ means the ‘AUTHORITY System’, and this in turn means the ‘AUTHORITY’s computing environment (consisting of hardware, software and/or telecommunications networks or equipment) used by the AUTHORITY of the CONTRACTOR in connection with this Agreement which is owned by or licenced to the AUTHOIRTY by a third party and which interfaces with the CONTRACTOR System or which is necessary for the AUTHOIRTY to receive the Services’. This would, in general terms, relate therefore to the infrastructure provided to a supplier to DBS over whom TCS had no control, but with whose system it was required to interact. (I note that reliance on Clause 2 in the context of the question of general construction is not therefore affected by the parties’ competing arguments about the specific application of this clause in circumstances where HPE’s services were introduced by Contract Change Notice (‘CCN’)). As a matter of general construction in the context of the meaning of the word ‘Responsibility’, the specific way in which the parties have sought carefully to cater for the extent of DBS responsibility for issues in systems provided by third party suppliers to DBS with whom TCS interact points strongly towards the word ‘responsibility’ meaning contractual responsibility, rather than a nebulous concept of ‘general responsibility’ which DBS may be in breach of notwithstanding the absence of any contractual hook by which to identify with certainty the basis of TCS’s entitlement.

49. 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 Delay and Notice Provisions

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

‘5. IMPLEMENTATION DELAYS - GENERAL PROVISIONS

5.1 If, at any time, the CONTRACTOR becomes aware that it will not (or is unlikely to) Achieve any Milestone by the relevant Milestone Date it shall as soon as reasonably practicable notify the AUTHORITY of the fact of the Delay or potential Delay and summarise the reasons for it.

5.2 The CONTRACTOR shall then submit a draft Exception Report to the AUTHORITY for its approval not later than five (5) Working Days (or such other period as the AUTHORITY may permit and notify to the CONTRACTOR in writing) after the initial notification under clause 5.1.

5.3 The draft Exception Report shall give the AUTHORITY full details in writing of:

5.3.1 the reasons for the Delay;

5.3.2 the actions being taken to avoid or mitigate the Delay;
5.3.3 the consequences of the Delay;

5.3.4 if the CONTRACTOR claims that the Delay is due to an AUTHORITY Cause, the reason for making that claim.

5.4 The AUTHORITY shall not withhold its approval of a draft Exception Report unreasonably. If the AUTHORITY does not approve the draft Exception Report it shall inform the CONTRACTOR of its reasons in writing, promptly following its decision to withhold approval and the CONTRACTOR shall take those reasons into account in the preparation of a further draft Exception Report, which shall be resubmitted to the AUTHORITY within five (5) Working Days of the rejection of the first draft.

5.5 Whether the Delay is due to an AUTHORITY Cause or not, the CONTRACTOR shall make all reasonable endeavours to eliminate or mitigate the consequences of the Delay.

5.6 Where the CONTRACTOR considers that a Delay is being caused or contributed to by an AUTHORITY Cause the AUTHORITY shall not be liable to compensate the CONTRACTOR for Delays to which clauses 7 or 8 apply unless the CONTRACTOR has fulfilled its obligations set out in, and in accordance with, clauses 5.1, 5.2 and 5.3.

…

6. DELAYS DUE TO CONTRACTOR DEFAULT

6.1 If a Deliverable does not satisfy the Acceptance Test Success Criteria and/or a Milestone is not Achieved due to the CONTRACTOR’s Default, the AUTHORITY shall promptly issue a Non-conformance Report to the CONTRACTOR categorising the Test Issues as described in the Testing Procedures or setting out in detail the non-conformities of the Deliverable where no Testing has taken place, including any other reasons for the relevant Milestone not being Achieved and the consequential impact on any other Milestones. The AUTHORITY will then have the options set out in clause 6.2.

6.2 The AUTHORITY may at its discretion (without waiving any rights in relation to the other options) choose to:

…

6.2.3 require the payment of Delay Payments, which shall be payable by the CONTRACTOR on demand, where schedule 2-3 (The Charges and Charges Variation Procedure) identifies that Delay Payments are payable in respect of the relevant Milestone. The Delay Payments will accrue on a daily basis from the relevant Milestone Date and will continue to accrue until the date when the Milestone is Achieved in accordance with the Correction Plan.

6.3 Where schedule 2-3 (Charges) does not identify the payment of Delay Payments in respect of a Milestone the AUTHORITY reserves its rights. Otherwise Delay Payments are provided as the primary remedy for the CONTRACTOR’s failure to Achieve the relevant Milestone Date and it shall be the AUTHORITY’s exclusive financial remedy except where:

6.3.1 the AUTHORITY is otherwise entitled to or does terminate this Agreement for the CONTRACTOR’s Default or for Force Majeure; or

6.3.2 the failure to Achieve the Milestone exceeds a period of six months.

7. DELAYS TO MILESTONES DUE TO AUTHORITY CAUSE

7.1 Without prejudice to clause 5.3 and subject to clause 5.4, if the CONTRACTOR 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 the CONTRACTOR will have the rights and relief set out in this clause 7.

7.2 The CONTRACTOR shall:

7.2.1 subject to clause 7.3, be allowed an extension of time equal to the Delay caused by that AUTHORITY Cause;

7.2.2 not be in breach of this Agreement as a result of the failure to Achieve the relevant Milestone by its Milestone Date; and

7.2.3 have no liability for Delay Payments in respect of the relevant Milestone to the extent that the Delay results directly from the AUTHORITY Cause.

7.3 The AUTHORITY Representative, acting reasonably, shall:

7.3.1 consider the duration of the Delay, the nature of the AUTHORITY Cause and the effect of the Delay and the AUTHORITY Cause on the CONTRACTOR’s ability to comply with the Implementation Plan;

7.3.2 consult with the CONTRACTOR Representative in determining the effect of the Delay;

7.3.3 fix a Revised Milestone Date; and

7.3.4 if appropriate, make any consequential revision to subsequent Milestones in the Implementation Plan.

7.4 If the CONTRACTOR has incurred any direct loss and/or expense as a result of a Delay due to an AUTHORITY Cause, the CONTRACTOR shall be entitled to compensation to the extent that it cannot mitigate the loss or expense in accordance with the principles set out in paragraph 27 of schedule 2-3 (The Charges and Charges Variation Procedure). The CONTRACTOR shall provide the AUTHORITY with any information the AUTHORITY may require in order to assess the validity of the CONTRACTOR’s claim to compensation.

…

8. DELAYS NOT DUE TO ONE PARTY

Without prejudice to clause 5.3 and subject to clause 5.4, where a Delay is attributable in part to the CONTRACTOR’s Default and in part to an AUTHORITY Cause the parties shall negotiate in good faith with a view to agreeing a fair and reasonable apportionment of responsibility for the Delay. The parties agree that Delay Payments and compensation payable pursuant to clause 7.4 (Delays to Milestones Due to AUTHORITY Cause) shall be recoverable subject to reductions to reflect the extent to which the AUTHORITY or the CONTRACTOR respectively has contributed to the Delay…’

51. Delay is defined as follows:

Delay ‘means 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.’

52. 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:

‘108. The modern view is accordingly to recognise that commercial parties are free to make their own bargains and allocate risks as they think fit, and that the task of the court is to interpret the words used fairly applying the ordinary methods of contractual interpretation. It also remains necessary, however, to recognise that a vital part of the setting in which parties contract is a framework of rights and obligations established by the common law (and often now codified in statute). These comprise duties imposed by the law of tort and also norms of commerce which have come to be recognised as ordinary incidents of particular types of contract or relationship and which often take the form of terms implied in the contract by law. Although its strength will vary according to the circumstances of the case, the court in construing the contract starts from the assumption that in the absence of clear words the parties did not intend the contract to derogate from these normal rights and obligations.

…

111. To the extent that the process has not been completed already, old and outmoded formulas such as the three-limb test in Canada Steamship Lines Ltd v The King [1952] AC 192, 208, and the “contra proferentem” rule are steadily losing their last vestiges of independent authority and being subsumed within the wider Gilbert-Ash principle. As Andrew Burrows QC, sitting as a Deputy High Court Judge, said in Federal Republic of Nigeria v JP Morgan Chase Bank NA [2019] EWHC 347 (Comm); [2019] 1 CLC 207, para 34(iii):

‘Applying the modern approach, the force of what was the contra proferentem rule is embraced by recognising that a party is unlikely to have agreed to give up a valuable right that it would otherwise have had without clear words. And as Moore-Bick LJ put it in the Stocznia case, at para 23, ‘The more valuable the right, the clearer the language will need to be’. So, for example, clear words will generally be needed before a court will conclude that the agreement excludes a party’s liability for its own negligence.’

Clause 7

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

54. 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’.

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

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

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

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

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

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

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

Conditions Precedent: Clauses 5 and 6

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

Conditions Precedent: the authorities

63. 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]:

‘that the issue for decision in this case is one of construction of a particular clause in a particular contract, and that consideration of how courts have construed differently worded clauses in different contracts is necessarily of limited assistance. It seems to me that, while taking note of the reasoning in the authorities cited, the correct approach is to focus on the precise terms of the Agreements with which the present case is concerned and ascertain their meaning applying the ordinary principles of contract interpretation.’

64. 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:

‘Whether this clause is a condition precedent or a contractual term of some other character must depend on (i) the form of the clause itself, (ii) the relation of the clause to the contract as a whole, (iii) general considerations of law.’

65. 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:

‘21. Prohibition

In case of prohibition of export, blockade or hostilities or in case of any executive or legislative act done by or on behalf of the Government of the country of origin or of the territory where the port or ports of shipment named herein is/are situate, preventing fulfilment, this contract or any unfulfilled portion thereof so affected shall be cancelled. In the event of shipment proving impossible during the contract period by reason of any of the causes enumerated herein, sellers shall advise buyers of the reasons therefor. If required, sellers must produce proof to justify their claim for cancellation.’

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

67. 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:

‘If upon written application to him by the Contractor the Architect…is of the opinion that the Contractor has been involved in direct loss and/or expense … and if the written application is made within a reasonable time of it becoming reasonably apparent to him that the progress of the Works or any part thereof has been affected as aforesaid, then the Architect should either himself ascertain or instruct the Quantity Surveyor to ascertain the amount of such loss and/or expense…

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

69. 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:

‘‘If by reason of any circumstance which entitles the Contractor to an extension of time … the Sub-Contractor shall be delayed in the execution of the Sub-Contract Works, then in any such case provided the Sub-Contractor shall have given within a reasonable period written notice to the Contractor of the circumstances giving rise to the delay, the time for completion hereunder shall be extended ….’

70. 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]):

‘In my opinion the real issue which is raised on the wording of this clause is whether those clear words by themselves suffice, or whether the clause also needs to include some express statement to the effect that unless written notice is given within a reasonable time the sub-contractor will not be entitled to an extension of time. 

…In my judgment a further express statement of that kind is not necessary. I consider that a notification requirement may, and in this case does, operate as a condition precedent even though it does not contain an express warning as to the consequence of non-compliance. It is true that in many cases (see for example the contract in the Multiplex case itself) careful drafters will include such an express statement, in order to put the matter beyond doubt. It does not however follow, in my opinion, that a clause - such as the one used here - which makes it clear in ordinary language that the right to an extension of time is conditional on notification being given should not be treated as a condition precedent.’

71. 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:

‘If the Sub-Contractor fails to complete the Sub-Contract Works or such works in any Section within the relevant period or periods for completion, and if the Contractor gives notice to that effect to the Sub-Contractor within a reasonable time of the expiry of the period or periods, the Sub-Contractor shall pay or allow to the Contractor the amount of any direct loss and/or expense suffered of incurred by the Contractor and cased by that failure.’

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

73. 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’.

74. 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:

(1) whether it is necessary for a party to comply with one or more stated requirements in order to be entitled to make a claim for money or relief will ultimately turn on the precise words used, set within their contractual context;

(2) there is nothing as a matter of principle which prevents parties freely agreeing that the exercise of a particular right to payment or relief is dependent on compliance with a stated procedure, but parties will not be taken to have done so without having expressed that intention clearly;

(3) the language of obligation in relation to procedure to be complied with (e.g. ‘shall’) is necessary, but not sufficient;

(4) the absence of the phrase ‘condition precedent’ or an explicit warning as to the consequence of non-compliance is not determinative against construing the regime as one of condition precedent;

(5) however, the absence of any language which expresses a clear intention that the right in question is conditional upon compliance with a particular requirement is likely to be, at the very least, a powerful indicator that the parties did not intend the clause to operate as a condition precedent;

(6) the requisite ‘conditionality’ may be achieved in a number of different ways using different words and phrases when construed in their ordinary and natural meaning;

(7) the clearer the articulation, purpose and feasibility of the requirement to be complied with (in terms of substance and/or timing), the more consistent it will be with the conclusion that, depending on the rest of the language used, the requirement forms part of a condition precedent regime.

Clause 5.6

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

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

77. 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’:

‘I recognise that a claim for negligent misrepresentation involves an allegation of fault and involves a different measure of damages, but it seems to me that a court should at least have in mind the contractual allocation of risk and reward when deciding whether the parties are to be taken to have intended that claims for misrepresentation based on the same facts as give rise to the claim for breach of warranty are to fall entirely outside the confined liability prescribed by the SPA.’

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

79. 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:

(1) the ordinary meaning of the language used in Clause 5.6 (‘liable to compensate [TCS] for Delays’) is wide and apt to cover both claims brought under and for breach of contract;

(2) similarly, the broad phraseology of the words ‘…Delays to which clauses 7 and 8 apply…’ suggest that the key question in considering whether compliance with Clauses 5.1 to 5.3 is required in order to be entitled to compensation is whether (a) there has been a ‘Delay’; and (b) whether it is a ‘Delay’ to which Clauses 7 or 8 apply: namely one (put broadly) which is due to ‘AUTHORITY Cause’ (Clause 7) or due to both parties (Clause 8). This is in contrast to the sort of wording which, for example, linked in clear terms only the express right to loss and/or expense under Clause 7.4 and compliance with Clauses 5.1 and 5.3;

(3) the purpose of a notice regime is to give an employer the opportunity to engage in the mitigation of delay, particularly delay which it knows it is going to be claimed has been caused by a matter for which the employer is to blame. In this context, a construction which requires a contractor to notify the employer only for the purposes of a contractual right to compensation, but allows the same claim on the same facts to be advanced at common law without having given notice is uncommercial. It also runs contrary to the risk and reward allocation set out expressly.

80. 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’.

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

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

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

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

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

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

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

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

89. 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’.

90. 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’.

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

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

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

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

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

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

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

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

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

100. 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’.

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

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

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

104. In my judgment:

(1) if TCS were to advance a case on apportionment, that case ought to have been pleaded, giving the factual and expert witnesses the opportunity to deal with such a case. No such case was pleaded, and it is not appropriate to permit TCS to advance a case on apportionment for the first time in closings (as TCS sought to do, in effect, through Appendix A, which I consider further in the judgment below);

(2) in any event, the clause clearly requires (‘shall’) the parties to negotiate in good faith about, and about specifically, agreeing a fair and reasonable apportionment for the Delay. This gives rise to important rights, such as the ability to refer a dispute to Expert Determination, which would not otherwise exist. Although Mr Cogley referred in the most general of terms to the fact that there had been negotiations and a mediation between the parties, and that questions of delay would have been in the mix during such negotiations, there is simply no evidence that the parties have negotiated in the way required by Clause 8 or sought in any way to operate the mechanisms required. In these circumstances, even if TCS were entitled to run a Clause 8 case absent a pleaded case, which I do not accept, they do not have the substantive entitlement to do so.

(3) furthermore, it is right that the apportionment exercise does not assist 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. Clause 8 would not, in any event, have been relevant, in the circumstances which I deal with in due course when considering DBS’s and TCS’s respective rights to Delay Payments or compensation under Clause 7.4.

Limitations of Liability

105. 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:

‘52.2 Subject to clause 52.1, the CONTRACTOR's total aggregate liability:

52.2.1 in respect of the indemnity in clauses 17.2 (Tax), 29 (Employment Indemnity), and 51 (IPR Indemnity), shall be unlimited;

52.2.2 for all loss of or damage to the AUTHORITY Premises, property or assets (including technical infrastructure, assets or equipment but excluding any loss or damage to the AUTHORITY's Data or any other data) of the AUTHORITY caused by the CONTRACTOR's Default shall in no event exceed £5,000,000 (subject to indexation);

52.2.3 for all loss, destruction, corruption, degradation, inaccuracy or damage to the AUTHORITY Data caused by the CONTRACTOR's Default shall be £5,000,000 (subject to indexation);

52.2.4 in respect of Services Credits shall be limited in each Service Year to 10% of the Charges in that year;

52.2.5 in respect of Delay Payments shall be limited to 10% of the implementation Charges.

52.2.6 in respect of all other claims, losses or damages, shall in no event exceed £10,000,000 (subject to indexation) or, if greater, an amount equivalent to 100% of 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 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.

52.3. Subject to clause 52.1, the AUTHORITY's total aggregate liability, (in addition to its obligation to pay the Charges as and when they fall due for payment):

52.3.1 for all Defaults by the AUTHORITY resulting in loss of or damage to the property or assets (including technical infrastructure, assets or equipment) of the CONTRACTOR shall in no event exceed £5,000,0000 (subject to indexation);

52.3.2 for the Termination Payment, shall not exceed:

52.3.2.1 in first Contract Year, £35,000,000 (subject to indexation);

52.3.2.2 in the Contract Years two and three and four and five, £25,000,000 (subject to indexation) for that respective year

52.3.2.3 in the final Contract year, £15,000,000 (subject to indexation);and

52.3.3 for the Compensation Payment, shall not exceed £10,000,000 (subject to indexation);

52.3.4 in respect of all other Defaults by the AUTHORITY shall in no event exceed the greater of:

52.3.4.1 an amount equivalent to the total Charges paid or properly invoiced and due to be paid under this Agreement in the 12 month period immediately preceding the event giving rise to the liability; or

52.3.4.2 £25,000,000.

52.4 Subject to clauses 52.1 and 52.5, neither party will be liable to the other party for:

52.4.1 any indirect, special or consequential loss or damage; or

52.4.2 any loss of profits, turnover, business opportunities or damage to goodwill (whether direct or indirect).

52.5 Subject to clause 52.2, the AUTHORITY may, amongst other things, recover as a direct loss:

52.5.1 any additional operational and/or administrative costs and expenses arising from the CONTRACTOR's Default;

52.5.2 any wasted expenditure or charges rendered unnecessary and/or incurred by the AUTHORITY arising from the CONTRACTOR's Default; and

52.5.3 the additional cost of procuring Replacement Services for the remainder of the Term; and

52.5.4 any anticipated savings.’

106. The points of construction which arise are as follows:

(1) DBS contends that the cap of £10,000,000 (subject to indexation) referred to in Clause 52.2.6 applies separately to each of its counterclaims brought against TCS. TCS contends that the clause provides a single, aggregate cap of £10,000,000 which applies to all claims, save for those dealt with in the preceding sub-paragraphs of the Clause. The only relevant one of these to provide a separate limit of liability is Clause 52.2.5 in respect of Delay Payments;

(2) in relation to Clause 52.2.5, TCS contends that the Delay Payments are to be limited to 10% of the ‘implementation Charges’. These are not specifically defined. TCS argues that, by reference to Schedule 2-3, the implementation Charges should be regarded as a reference to the Charges associated with the successful Delivery of the Modernisation Release, which are £2,898,420.23. The limit would therefore be £289,842. DBS denies that any meaning can be given to the cap, or, alternatively, identifies other materials which may bear on what ‘implementation Charges’ mean, and which would give rise to a substantially higher cap;

(3) DBS contends that TCS’s claim for wasted expenditure is in fact a claim for loss of profits, and as such is excluded by Clause 52.4.2. TCS contends that, whilst accepting that its loss could be characterised as either wasted expenditure or loss of profit, having characterised it as wasted expenditure, it is not caught by the exclusion at Clause 52.4.2.

A single or multiple caps?

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

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

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

110. 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.”

111. 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’.

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

‘33.2 Subject to clauses 33.1, 33.3, 33.5 and 33.6, the Supplier's total liability to the Customer, whether in contract, tort (including negligence), for breach of statutory duty or otherwise, arising out of or in connection with this Agreement (including all Statements of Work) shall be limited to an amount equivalent to 150% of the Charges paid or payable in the preceding twelve months from the date the claim first arose. If the claim arises in the first Contract Year then the amount shall be calculated as 150% of an estimate of the Charges paid and payable for a full twelve months.

33.3 The Supplier's total aggregate liability arising out of or in relation to this Agreement for any and all claims related to breach of any provision of clause 21 whether arising in contract (including under an indemnity), tort (including negligence), breach of statutory duty, laws or otherwise, shall in no event exceed 200% of the Charges paid or payable in the preceding twelve months from the date the claim first arose or £20m (whichever is greater).’

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

114. 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:

(1) as set out above, the words ‘the aggregate liability … in respect of all other claims, losses or damages, shall in no event exceed’ are a clear indicator that the clause is setting out the total liability notwithstanding however many claims, losses or damages might exist;

(2) the simple language of ‘per claim’ is absent;

(3) whilst the ‘claim under consideration’ within the alternative (if greater) to the figure of £10,000,000 suggests that more than one claim may be under consideration, the clause then seeks to net off sums previously paid. This demonstrates that, on any view, the capped sums calculated in accordance with the clause are not intended to be additive (although it may be that a later claim considered gives rise to a larger overall cap being applied than had previously been calculated by reference to an earlier claim).

(4) even without the express ‘netting off’ process, I would consider a construction equivalent to that found by Waksman J to exist, which implies a reference to the first claim, would be appropriate given the clear intention that the clause is intended to provide an aggregate liability figure for all other claims. However, I do not consider this is necessary, and as set out in (3), it may be that a later claim than the first sets the cap. The effect of this is that the alternative cap is, in effect, the Charges in 12 months prior to any claim brought giving rise to the greatest cap. Determining the precise mechanics of this is, however, unnecessary in the present case as no claim is brought by DBS by reference to a cap calculated in accordance with the alternative possibility. (I note that, on the basis of the figures provided by the Forensic Accounting experts in the context of the Charges Variation Dispute, the Charges in each year in fact exceeded £10,000,000, so the alternative, greater cap(s) ought in fact to be applicable: yet DBS has not presented a workable analysis of how such greater cap(s) should be calculated).

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

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

The Delay Damages cap under Clause 52.2.5

117. 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.’

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

Is TCS’s claim for loss of anticipated costs savings excluded by Clause 52?

119. 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:

‘The loss of revenue claim is advanced on the basis that (i) the per transaction cost to the Claimant 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 processes; (ii) the contractual charging scheme reflected that anticipated lower cost to the Claimant, 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 Barring & Basics and the lack of Go-Live of R1 Disclosure, the Claimant 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 Barring & Basics and non-implementation of R1 Disclosure.

Pending expert evidence, the Claimant has calculated its losses only for the period April 2017 to March 2020, and has done so by reference to the difference between the Transaction Charges applicable during that period as set out in paragraph 2.3.1 of Schedule 2-3 and the Transaction Charge that would have been paid had the Service Year 3 Transaction Charges continued to apply in Service Year 4 onwards, such difference in charges being a proxy for and reasonable estimate of the lost anticipated cost savings.’

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

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

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

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

124. In that case, the exclusion clause excluded:

‘Losses arising under and/or in connection with this Agreement (whether in contract, tort (including negligence), breach of statutory or otherwise) which are indirect or consequential Losses, or for loss of profit, revenue, savings (including anticipated savings), data …, goodwill , reputation (in all cases whether direct or indirect)’. ‘Losses’ were defined as ‘All losses, liabilities, damages, costs and expenses including reasonable legal fees on a solicitors/client basis and disbursements and reasonable costs of investigation, litigation settlement, judgment, interest.’

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

126. 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 claimant can either claim its loss of profits or, alternatively, its wasted expenditure. If the claim is for wasted expenditure, it is not limited to the expenditure incurred after the contract was made but can also include the expenditure before the contract, provided it was reasonably in the contemplation of the parties as likely to be wasted if the contract were broken: see Anglia Television Limited v Reed [1972] 1 QB 60. In that case, Lord Denning MR said:

‘It seems to me that a plaintiff in such a case as this has an election: he can either claim for loss of profits; or for his wasted expenditure. But he must elect between them. He cannot claim both. If he has not suffered any loss of profits- or if he cannot prove what his profits would have been- he can claim in the alternative the expenditure which has been thrown away, that is, wasted, by reason of the breach.’

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

‘68. All loss of profit/revenue/savings claims are difficult for the potential contract-breaker to estimate in advance. They can be notoriously open-ended. Claims for loss of profit, revenue and savings are therefore types of potential loss which, because of those problems of speculation and ascertainment, are routinely excluded by clauses like clause 23.3.

69. Claims for wasted expenditure are an entirely different animal. To be able to claim such wasted expenditure is a valuable right: see Anglia v Reed and Yam Seng. Moreover, if the victim of a breach of contract has spent money in anticipation that the contract would be performed, then his or her loss is easy to ascertain: there will be invoices, contracts, receipts and the like. This type of loss is the opposite of speculative: it is precisely ascertainable. It is a pure accounting exercise. Perhaps for that reason, such claims are not usually regarded as claims for consequential loss.

….

70. This distinction is also in accordance with the law. That these are different types of loss as a matter of law is underlined by the decision in Anglia Television (paragraph 40 above). When a contract is repudiated, the victim can claim loss of profits or the expenditure which has been thrown away as a result of the repudiation. He or she cannot claim both and, to address a point touched on in Treitel's The Law of Contract, 15^th Edition at 20-036, also edited by Professor Peel, there are "formidable objections to running the two claims in the alternative": see Filoblake Ltd v Rondo Ltd at [64]. On its face, therefore, clause 23.3 expressly excluded the former type of loss, but did not exclude the latter.’

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

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

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

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

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

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

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

C. Compliance with Clause 5.3, Agreement and Estoppel

Introduction

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

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

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

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

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

Express Agreement

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

141. 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’.

142. 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:

In accordance with clause 5.1 of the Agreement, which requires TCS to provide DBS with notice where it will not, or is unlikely to, Achieve any Milestone by the relevant Milestone Date, please accept this letter as confirmation of a Delay. This means that the contractual Milestones for Release 1, as presented at Project Board on 25th November 2015, which we have been jointly delivering to, will not be Achieved on time.

The most significant reasons for this Delay are:

Delay in delivery of internet connectivity

Delay in delivery of content inspection

Delay in on-boarding to Verify

TCS will provide DBS with a draft Exception Report, which will contain additional information pertaining to the Delay, in accordance with clause 5.2 of the Agreement. However, as we are still in the process of re-planning, and still awaiting additional information from DBS to allow this to complete, TCS is currently unable to determine the detailed consequences of the Delay. Accordingly, TCS is unable to provide a draft Exception Report within the stated 5 Working Days from the date of this letter and requests DBS’ permission for an extension.

As discussed at R1 Project Board on 21st July 2016, please can you confirm by when DBS will be in a position to provide the information required by TCS to allow it to complete the re-planning, which includes the baselined HPE plan, confirmation of Verify stage completion dates, and the dates by which all other external dependencies will be met (e.g. those we have for Vodafone and HOT).

TCS will, in due course, and following receipt of the additional information that is required from DBS, confirm to DBS when it is possible to provide a draft Exception Report.

143. 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:

‘Current situation is:

1. Updated HPE Delivery Plan I believe TCS received this yesterday and Paul Martin is working on plugging it in to the TCS plan.

2. Decision on Verify / Post Office Contingency TCS has been informed that Verify is the solution.

3. Confirmation of Verify stage completion dates Planning session this week.

4. Dates by which all other external dependencies will be met. We will need to plan on the basis of assumptions (e.g. those we have for Vodafone and HOT)’

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

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

146. 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:

‘I note that you never formally responded to our request in that letter for an extension within which to submit an Exception Report.’

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

Estoppel

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

(1) A common assumption shared by both parties or an assumption made by TCS and acquiesced in by DBS: see Tinkler v Revenue and Customs Commissioners [2021] UKSC 39; [2021] 3 WLR 697 per Lord Burrows JSC at [39].

(2) If there is said to have been a common assumption, TCS must show that it was communicated between the parties, i.e. it must have crossed the line. A common subjective assumption is insufficient. See Tinkler at [34]-[38].

(3) The person raising the estoppel (here, TCS) must know that the person against whom the estoppel is raised (here, DBS) shares the common assumption and must be strengthened, or influenced, in its reliance on that common assumption by that knowledge; and DBS must (objectively) intend, or expect, that that will be the effect on TCS of its conduct crossing the line so that one can say that DBS has assumed some element of responsibility for TCS’ reliance on the common assumption. See Tinkler at [51].

(4) Alternatively, an estoppel by convention based on acquiescence can only exist where the parties are subjectively in agreement; i.e. the party making the representation knows that the other party has a different understanding: ABN Amro Bank NV v Royal and Sun Alliance Insurance Plc & Ors [2021] EWCA Civ 1789; [2022] 1 WLR 1773 per Sir Geoffrey Vos MR at [87].

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

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

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

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

153. 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:

‘A joint re-planning exercise is underway. It is anticipated that the revised plan will be agreed by R1 Project Board on 25th August 2016. This will then inform discussions around the commercial impacts’.

154. 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:

‘We all focussed on regulating the position by re-planning and then we would know that the consequences of the delays were - and would in fact have already sorted them out. We could then serve the Exception Report. ….There is no doubt that [DBS] knew we needed specific information to complete the draft Exception Report that DBS could not readily provide, and the process we were all embarked upon was a collaborative one to ascertain and understand when all parties could complete the relevant tasks so that an effective-plan for delivery could be prepared. I also do not recall any occasion on which DBS asserted, prior to the service of the draft Exception Report, that TCS would not be entitled to compensation for the delays described in the Notice of Delay because it had not served the draft Exception Report within five working days.’

155. 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:

‘So I think even when we were trying to do the replanning, you will find that in a period of three to four or five months, each of the elements of delivery from the delivery partners, like HPE, were shifting 12, 15, 16 times. So we could not - it’s a moving feast. We just couldn’t pinpoint in terms of any of those details that is required, because for an Exception Report in our mind to be complete, we need to give some kind of a realistic assumption in terms of when these partners can deliver, based on which, when we can deliver the final outcome. And every time we prepare one, we find that they come back in the next week or session and give us a delay which is again further on. So we find multiple iterations coming from all the time. So we couldn’t collate it in any sensible shape or form, because from one reporting period to the other, so many delays are happening, so we couldn’t have a feel. Even though, again, that’s a frustration I would have in my witness statement is that we want to do it and we have expressed with DBS that we would like these teams to come together to help us prepare to do it, but it - it just doesn’t happen.’

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

157. 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:

(1) DBS claims that there are no contemporaneous documents before the Court which record TCS making such an assumption and nothing in the internal TCS correspondence on the topic of Exception Reporting to suggest that DBS believed that DBS would not rely upon the clauses. However, the whole tenor of the communications, in circumstances where DBS themselves did not articulate any reliance upon the provisions at the time, is that the condition precedent was simply not a live point. It is unsurprising that it was not the subject of discussion internally within TCS. It is objectively obvious that TCS considered that it had had a de facto extension to provide its Exception Report, notwithstanding the absence of a formal response to their request, because of the way DBS was conducting itself in discussions and negotiations;

(2) DBS placed weight, in cross-examination and in submissions, on the internal emails from Mr Murphy (of TCS) drawing the relevant contractual terms to the attention of his colleagues which may be said to have emphasised the potential importance of the clauses in late July 2016. There is no suggestion that TCS were unaware of the clauses: these emails make clear that they were aware of the wording of Clause 5.3. The emails also make clear, for what it is worth, that TCS genuinely considered that the production of an Exception Report that detailed the consequences of the delay was not possible in light of their dependency upon information from others (and in particular HPE, through DBS). The very fact that TCS were acutely aware of the possible point that DBS might take against them supports their belief that the point had fallen away in circumstances where substantive negotiations and planning was taking place absent any suggestion by DBS that they had forfeited their entitlement to compensation. The internal emails from Mr Murphy do not, therefore, negate in any way the existence of the assumption relied upon;

(3) Mr Kuncheria was right to concede that no formal extension was ever granted. It is obvious that it was not, as I have found above. Indeed, had it been, the issue of estoppel would not arise. The concession was not of itself inconsistent with an estoppel existing;

(4) I do not accept that Mr Kuncheria’s evidence (or that of other more junior TCS employees) does not support the assumption asserted. Whilst he does not use the phrase, ‘I assumed…’, his evidence (in the passages quoted above) and the correspondence surrounding the substance of the discussions and negotiations clearly demonstrate an assumption on TCS’ part that, whilst it was still necessary to produce an Exception Report, no technical point on 5 Working Days was being taken against it and that any entitlement would be determined in light of the substantive merits.

158. 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:

(1) Ms Owen’s oral evidence, which I accept in this regard, was that her response of 2 August 2016 did not agree an alternative period in which the draft Exception Report could be provided. This is consistent with the conclusion I have come to above. However, her evidence was also, in summary, that (a) she understood TCS were saying that they did not have sufficient information to do so; (b) at least one of her colleagues considered this to be reasonable; (c) she had not refused the request and would have said so if she had; and (d) DBS was prepared to grant TCS more than 5 days even though the parties never came to any agreement on what the period was (Day 9/130):

Q. You were asked in writing by TCS for an extension of time. You -- and they said that, "We need an extension of time because we need information to prepare our exception report", okay? David Charles says to you, after looking at what you had cut and pasted and sent on to him, that this seems reasonable.

A. Yeah.

Q. Okay? You then adopt his answer to your email and you go back and you provide some of the information, but not all of it.

A. Yes.

Q. So you knew that they still required information in order to prepare an exception report?

A. Yes.

Q. And you hoped that what had been provided would at least help in some way toward preparing the exception report?

A. Yes.

Q. And that the information that would be imparted or whatever, or gleaned by TCS at the R1 PB meeting the following day would also help to supplement and provide information for them to prepare the exception report?

A. Yes.

Q. So it follows, doesn't it, that you didn't go back to them and say, "No, you're not getting an extension of time"?

A. No, I never -- I never said that, no.

Q. But you see, if you weren't prepared to grant an extension of time and that's one of the things that was being sought, then you would have said that, wouldn't you, in your response?

A. Yes.

Q. Yes. And you didn't?

A. No, I didn't.

Q. So it follows that you were prepared to allow them to have more than five days?

A. Yes, which we can do.

…

Q…So the issue was not: are we going to prepare an exception report? It's, and it remained: when will we have sufficient information to be able to do so? Is that fair?

A. That was TCS's position, yeah.

Q. Yes, that's right. Okay. But whether or not DBS agreed with it, DBS had in fact granted the five-day exception -- extension. I appreciate you didn't write a letter saying, "Yes, you can have an extension", because the conduct of the parties after that date was all on the basis of well, you still wanted an exception report, they, TCS, were going to provide you with one, but they were still asking for information. That's a fair summary of the position, isn't it?

A. They kept asking for information, we kept reminding them that the exception report was still outstanding, but we didn't -- we didn't agree a final date that they -- they should have as an extension, that's correct.

(2) Mr Whiting was, at the relevant time, Director for Finance, with additional responsibility for DBS’s Commercial operations. Mr Whiting was taken through a number of documents which dealt with commercial negotiations in the autumn of 2016, and he generally agreed that DBS did not take any point that no Exception Report had been served with 5 Working Days and/or that as a result TCS were not entitled to bring a claim. He gave evidence that the first time he could remember seeing the 5 Working Days point being taken by DBS was in the pleadings. In this context, the following exchange then took place (Day 8/20):

Q. Yes. Well, I suggest it's obvious and the fact is this, that nowhere in [Colette Owen’s 2 August 2016 email], which of course, as you say, you saw, nowhere in the document does it say you are not having an extension of time, does it?

A. Not from what I've seen today, no.

Q. No. So, you see, one explanation for your conduct in never mentioning the five days point, as I will call it, and deploying that in your commercial negotiations that you were having with Mr Kuncheria in these many meetings that you had is because in fact the five business days aspect had just fallen by the wayside, hadn't it? Not the provision of an exception report, but the five business days?

A. Yes

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

160. 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:

(1) there was a continuing requirement on the part of DBS and acceptance on the part of TCS that an Exception Report setting out the consequences of the claimed delays was required;

(2) TCS was bringing a claim for financial compensation for delays caused by HPE (and, in TCS’s eyes, therefore, DBS);

(3) information for the process was required from HPE, through DBS, and the provision of that information was ongoing both for the purposes of re-planning the project and (therefore) to articulate the consequences of the delays within an Exception Report;

(4) it was worthwhile for both parties to engage at length in discussion and negotiation of the merits of the parties’ positions in circumstances where DBS was not asserting that TCS’s right to compensation had fallen away because of a failure to have served a draft Exception Report within 5 Working Days.

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

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

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

D. The Parties’ Claims relating to Delay

Introduction

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

(1) TCS contends the predominant cause of delay to R1-B&B was inadequacy of the technical infrastructure services that DBS procured from HPE: they were immature, unstable and poorly documented; that provisioning, configuring and troubleshooting on infrastructure consistently proceeded at an unpredictable (and thus unplannable) but generally glacial pace. Although its pleaded case maintained that DBS failed to manage HPE adequately so as to resolve these issues, this case was not advanced with any enthusiasm either in examination of witnesses or in submissions. The case essentially rested upon HPE’s failures (either systemic or in execution).

(2) DBS rejects that difficulties with the technical infrastructure were responsible for any of the critical delay to the R1 Project; rather, it contends the delay was caused by problems with the development and testing by TCS of the application software.

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

166. 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:

(1) DBS’s claim for liquidated damages is excluded by reason of its failure to have served a Non-conformance Report at all;

(2) DBS nevertheless has a claim for unliquidated damages (in excess of Delay Damages it would have been entitled to but for its failure to serve a Non-conformance Report) it may prove were caused by Delay as a result of Contractor Default in excess of 6 months;

(3) Delay is caused by CONTRACTOR Default unless TCS establishes that it is entitled to relief pursuant to Clause 7. TCS is entitled to relief irrespective of compliance with any condition precedent;

(4) TCS is entitled to relief from Delay Damages and to recover loss and expense to the extent that it can establish 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;

(5) it is therefore necessary for TCS to establish the date by which it would have been able to Achieve the Milestone but for AUTHORITY Cause;

(6) an AUTHORITY Cause requires establishing a breach by DBS of an express or implied obligation (whether by itself, one of its other contractors, or servants or agents) under the Agreement.

R1 B&B Delays

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

168. 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’s First Analysis

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

170. 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:

A close-up of a chart

Description automatically generated

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

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

Q. You're really asking -- seeking to ask and answer

the question, from the plan: what appears to have caused

1 the planner to change the Go-Live date?

A. Yes.

Q. We go on, we can see a bit further down, you say:

"I have then reported that as the reason for

the date slipping or (in several instances) moving

forward."

A. Yes.

Q. So that's what you do and you say: this is the -- this

is the reason for the change -- the date change?

A. Yes.

Q. And, at least in this analysis, you don't at any stage

seek to consider whether the forecast events actually

occurred as planned?

A. No.

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

Q. Yes. So you could test - you could cross-check the information in the Microsoft Project plan by reference to, for example, and as-built analysis, which would tell you whether what was projected comes to pass, if you’re doing it retrospectively?

A. Yes.

Q. But that’s not what you do in your first report, is it?

A. No, I don’t do that exhaustively. I won’t say I won’t do it. I’d have to have a look.

Q. Well, you don’t do it at all in your first report, do you? It’s not exhaustively; you don’t do it at all?

A. I would -- I don’t know. I can’t say I never do it, but I -- you know, as a general rule, no, I don’t.

Q. What, in your first report?

A. In my first report.

Q. No.

And would you accept that if one was interested in

finding out to what extent a project was actually

delayed and the things that actually caused delay to

the project, it would be appropriate to look back to see

what actually happened and not simply confine yourself

to that which was projected to happen?

A. But at the end, I am looking at what actually happened.

And also I think this is a very theoretical objection,

because if you look at the events which cause delay,

many of them are in the past and -- with respect to

the plans, and when you follow up what did actually

happen, they did happen and delayed even further.

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

…The -- what I'm really

trying to say in that answer is that I think Mr Croall's

objection was that, you know, if you're looking forward,

it might never have happened, but if you go through

the sequence of plans, you can see that all of

the delays that affect the timeline, that cause

the Go-Live date to be pushed out, you can see, in

retrospect, that they did happen and they were actually

worse than that. So it's not a fair criticism to say,

"Well, it might not have been -- it might not have

happened that way"; it did happen that way, ultimately.

They didn't appear as the critical path later on because

other things had delayed even further, but, you know,

those delays did happen.

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

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

Q. But let us be clear. If the court wanted to know how much any given event caused by way of delay, they couldn’t derive any assistance from your report because you don’t seek to apportion delay to any given feature or any given event; that’s right, isn’t it?

A. Between infrastructure features, no, that’s right.

MR JUSTICE CONSTABLE: But because all of your analysis is through infrastructure, that means there isn’t really a caveat, in fact, to your answer?

A. I think if you were to want to -- to want to come to a conclusion that said X days were delayed -- there was X days delay due to CJX/PSN and there was Y days due to content inspection, then it would be quite challenging to do that. You could maybe do it by looking further into and looking at the different delays, but there would be no easy - there’s no easy off-the-shelf answer.

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

MR JUSTICE CONSTABLE: And how much does your view on the absence of a problem in this project relate to your view that, from your analysis, the critical path runs through effectively the same thing, as far as you’re concerned, ie the fault of one party, and distinguishing with greater precision within that isn’t necessary for you to draw a particular conclusion? Are those two linked?

A. I -- I think, I’m not sure whether this would have been sufficient if we’d had to, as I say -- if the responsibility passed from one party to another. I think you would need to refine it in some way. But I think it’s still important to take account of how the projected delays influenced the decisions made at the time. So I don’t know if I have an answer as to how you would do it if -- if it was more complex.

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

179. 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:

‘On an IT project, activities that are not on the critical path will tend to extend to fill the time available and activities that are one the critical path will tend to be compressed and overlapped or a completely new strategy will be devised if the project is late. Dependencies are fluid and can often be waived or postponed…Teams can be asked to work additional hours over limited numbers of weeks to speed up delivery if required. Unlike a construction project, resources cannot simply be brought on and laid off a project as and when required…..If software is not on the critical path, then ways need to be found to keep these team members productive, by slimming the team down (a route that cannot easily be retraced) or by finding additional work for them to do, such as implementing change requests or non-essential improvements and defect fixes. Changes may be agreed without requesting an extension when one would have been insisted on if the software was critical.’….Once a delay to a milestone has been forecast on an IT project, the software-delivery workstream will work to the new forecast date.’

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

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

‘While I have not been able to assess TCS’s progress in development and testing in detail, because of the lack of a development tracking tool, I have seen no evidence to suggest that TCS’s development and testing team were in effect ‘pacing’ their activity while waiting for other critical activities to complete. On the contrary there is evidence that TCS did not have sufficient resource to carry out the necessary work in 2016, for example:

• DBS expressed concerns at the lack of test resource, completeness of test plans and a lack of a release manager in March 2016

• TCS’s proposal to re-sequence test phases in May 2016 was accompanied by a proposal to significantly increase on-shore testing resource

• TCS did not have sufficient resource to test and support both Barring & Basics and Disclosure in June 2016

• Suggestions that TCS should implement changes to the portals for usability reasons caused concern about build impact in TCS’s build team’

182. 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’.

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

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

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

Q. But essentially, as I understand it, you're choosing BPO UAT largely because it wasn't forecast to last as long as it did?

A. I -- by observation, I look at that and I think that's -- that's the problem. It's back to my core -- my - my core work thought. It was on the original critical path and I would find it strange if the baseline critical path wasn't true what people thought were the core pieces of work at the time. And then it was -- it looks to have been, for whatever reason, only ever forecast to be done it within a week or two, but when it came to it, suddenly it's caught you up and perhaps caught you by surprise, but that has caused it to become critical at the end here.

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

Q. And obviously the single longest item which is much longer than planned is the slip to BPO UAT?

A. Yes.

Q. As a consequence, in your report at page 40 {C1/4/40} onwards, you spend some time explaining why it is that that workstream need not have taken the amount of time it in fact took?

A. Yes.

Q. Is that a fair way of characterising how you address it?

A. Yes.

Q. And it’s because you conclude that it need not have taken that time that you conclude that you can - unlike the delays that we see to systems monitoring and load balancing, it doesn’t need to be fed into the –

A. The original plan.

Q. -- the original November 2015 plan. Have I understood that right?

A. Yes.

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

A. We wanted to finish this test phase, definitely. But what I was referring to earlier was that if you look at holistic view of programme and if you see where this PMS testing -- or BPO UAT was taking longer indeed, but there wasn't -- there was nothing hanging off of it, so to speak, before what is stopping it from going live basically.

Q. That was -

A. There's no -- this is not a predecessor for any other critical activity in the sense this taking longer was delaying the programme day by day. No, that was not.

188. 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:

(1) As of 15 November 2016, the plan for BPO UAT envisaged the testing of 363 test scenarios at an average rate of 19 scenarios per day, leading to a finish date in December 2016;

(2) By 22 November 2016, TCS had attempted 124 scenarios of which 54 passed, 38 failed and 32 were blocked. Support was sought from the build team to address the issues as of 23 November 2016, but slow progress was being made in addressing the issues. As set out in the email from Amit Kumar Tyagi:

‘As per the update shared yesterday, today We have taken support from build team to analyse all the failed and blocked scenarios in PMS area and identified the one's which needed further clarification, testing, test data creation, or if it is a new requirement.

There was slow progress in execution today due to teams involved in these discussions on previous failed, blocked scenarios and unavailability of test data in the SIT-L environment (since regression and BPO UAT testing is going in parallel and test data creation needs support from testing team).’

(3) Similar problems continued to occur. Some days (e.g. 29 November 2016) no official testing took place because of lack of availability of the Finance team. There was still a large number of blocked and failed scenarios as at 2 December 2016. From Amit Kumar Tyagi:

‘There are total 142 blocked scenarios, the reasons for the blockage of these scenarios is summarised as follows -

1) Blocked in PMS - 112

a) Finance unable to close period - 73

b) Reporting logic incorrect - 15 (5 scenarios have failed which were attempted full test of similar scenarios but the logic seems to be incorrect due to which these have been put as blocked)

c) Test data creation in progress to retest and confirm - 8

d) User Training under progress to carry on testing - 2

e) The remaining 14 include Test Scenarios dependent on other Failed/Blocked Scenarios

2) Blocked in non-PMS i.e. Contact Centre, BPO, MIS etc - 30

a) Blocked by RBAC's - 27

b) Blocked due to other Failed Scenarios - 3

In addition to the blocked scenarios, there are total 87 failed scenarios (29 non-PMS and 58 PMS). The defects have been raised for these and are being discussed/reviewed during daily triage call. The defect summary has been skipped from this status update and will be continued from 05-Dec-16 daily status report.’

[PMS is Payment Management System; MIS is Management Information System; RBAC is Role Based Access Control]

(4) On 9 December 2016, Ms Wagner rejected as unrealistic a plan to complete BPO UAT by the end of December. She asked for a realistic plan that could be delivered. The report also referred to the fact that ‘BPO have struggled… due to lack of resource on our part” and that the “test team have committed to providing us with two additional resource to aid the progress of retesting.’

(5) On 9 January 2017, Mr Bhatia reported internally that BPO UAT had “not gone well and the statistics [had] not been very encouraging so far…”

(6) A status update on 20 February 2017 reported that there were still 87 defects in re-testing which it was hoped would be completed by 6 March 2017, following which there would be a round of regression testing

(7) An internal TCS message on 1 March 2017 referred to the fact that BPO UAT had not been run as efficiently due to inexperience of the TCS BPO UAT team in running tests.

(8) By the end of March (27 March 2017), Mr Foster reported the status as follows

‘Please find below. We have had no update from testing today due to the system being unavailable for nearly all of the day. With regards to Barring testing we are still waiting for the resolution of the outstanding cases from last week. The build team have made a number of updates to this but over the last week everytime an issue is fixed it causes a problem in another area.’

A screenshot of a graph

Description automatically generated

(9) Mr Swain of TCS disagreed with this characterisation of the problem, hinting it seems that it was the approach of the BPO team which was causing the problems:

‘I would disagree with the statement that everytime an issue is fixed it creates more problems. We meet several times a day on various issues, we can discuss and try resolve in an efficient manner if it's such a problem. I have given below an extract of fixes released/tested in last 2-3 weeks…

We understand the criticality of this phase and try to ensure that you get the fixes as soon as possible.’

This exchange does not appear consistent with an activity which is merely being allowed to drift in the knowledge of parallel critical delay on a different workstream. TCS was therefore aware of the problems with BPO UAT and the importance of resolving them.

(10) On 28 March 2017, Ms Mather asked Mr Foster what was needed to meet the exit criteria. In a separate message, she also asked why an unrealistic date of 3 April had been set when it was known that the test team would not be available due to their involvement in month end activities. Mr Foster responded that this was due to ‘various reasons including lack of system availability and resource not being available for unexpected reasons’.

(11) As at mid-June, the following data was presented:

A screenshot of a table

Description automatically generated

A screenshot of a number

Description automatically generated

(12) This shows the progression of defect identification and resolution through the first half of 2016.

(13) In the same email chain, Mr Swain stated that there were expected to be no remaining critical defects at the end of that day, implying there were still critical defects as of that date. He said:

‘Our BPO team has made it clear that only critical defects are must-have from business point of view. However in today's checkpoint DBS has said they will review the high defects to ensure that service is not impacted due to these.

We will be left with around 25 high defects as of EOD today. All of these in rejected/retest status.

Currently Safuvan's team is retesting and closing these defects.

In parallel, Debra has asked BPO team to revisit these defects and reduce the severity, as appropriate.’

(14) Notwithstanding the obvious focus and effort, as of 22 June 2017, the position was:

A table with numbers and letters

Description automatically generated

(15) There therefore remained severity 1 and severity 2 defects. Defects overall were still less than 90% fixed: there were 806 defects in total with 89 outstanding.

(16) Exit from BPO UAT in the event only occurred on 9 August 2017.

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

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

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

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

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

And so one can't just say, well, this is how long

the test phase was, one needs more metrics to understand

what was primarily driving the ongoing SIT?

A. Yes, I was answering you in the abstract, and I think in

this case, for this window, it's more complicated than

that. We've got a mixture of DBS RFCs, we've got defect

fixes going on, we've got the PMS enhancements, we've

got in the early stages some portal work still going on

and we've also got issues that TCS decided to move from

drop 8 into drop 6 to support OPA, for example. So

there's a whole mixture of different things happening.

So I think to say it's primarily defect fixes is an

overstatement on my case -- on my part.

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

A. What we've got here is very much a mish mash of

different things.

Q. So if you wanted to understand -- if it was important to

understand the difference between the, what I'm going to

call, pre-existing defects, so from the original

contractual scope, and RFC-based defects, one would have

to do rather more analysis than you've done; is that

fair?

A. Yes, that's fair.

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

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

MR JUSTICE CONSTABLE: And would you -- I mean, this sounds slightly counterintuitive to me, although I don’t run IT projects. To not exit, when it’s something on a plan, you’ve got your client there, why wouldn’t you exit? And then obviously you may -- you may want something for your testers to do so they carry on fixing defects, but if they’ve got to the point at which they’re allowed to exit, given the remaining number of defects, why on earth wouldn’t you do that so you’ve just ticked that box and the client can’t complain?

A. Yeah. No, you could do that and I think that would be a sensible thing to do. But -- so you might exit and then just carry on fixing defects. So, yes, perhaps it’s not the best example in the world.

197. 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:

Q. So, if they were doing so, they would appreciate they were doing it on risk, so to speak?

A. I think so. They would take a -- they would take a balanced judgment based on risk, if there’s that much logic to it.

Q. And one of those risks is that they will end up being the cause of a delay to the project, isn’t it?

A. Yes, there is -- there is that risk.

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

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

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

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

202. 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:

A white and blue calendar with black text

Description automatically generated

203. 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:

A graph with blue and orange lines

Description automatically generated

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

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

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

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

Q. Do you know what the impact would be if you had fed the delays in software into your original Excel spreadsheet?

A. I don’t know the precise effect, but, yes, if you -- if you actually fix is (sic) so that all the delays in the software are in there at the beginning, of course it’s going to be the -- the critical path and it’s going to be accounting for all the delay.

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

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

Q. So on this analysis, one sees the latest date in terms of the impact of delays relating to load balancers which takes you to 22 June?

A. Yes.

Q. But one can see the software delays would have taken you to only one day shorter than that.

A. Yes.

Q. So the delays related to infrastructure features that you identify here have only caused one more day delay in the software?

A. Yes.

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

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

Conclusion on Mr Britton’s Analyses

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

TCS’s submission based upon Mr Jardine’s analysis

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

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

215. 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] BLR 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.

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

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

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

A screenshot of a computer screen

Description automatically generated

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

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

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

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

Responsibilities for Delay on the ‘Infrastructure’ Critical Path

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

(1) All infrastructure delays were attributable to HPE;

(2) All delays attributable to HPE were ‘Authority Cause’;

(3) Even if it is not possible to conclude that all infrastructure delays were attributable to HPE, it is possible for the Court to undertake an exercise of apportionment.

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

225. 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.”

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

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

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

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

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

R1-D

The Relevant Period for Consideration

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

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

‘In or around January 2016, the parties agreed that the Claimant would pay the Defendant the sum of £4,559,439 to compensate it for the delay up to 31 March 2016. The parties also agreed that the Go-Live date for R1 Barring would be revised to 15 September 2016, the Go-Live date for R1 Basics would be revised to 1 January 2017 and the Go-Live date for R1 Disclosure would be 28 November 2017….

…

The Claimant could not have delivered R1 Disclosure prior to the expiry of the Agreement or by the deadline of 28 November 2017, nor can it establish an entitlement to an extension of time for the reasons given in paragraphs 39-42 above.’

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

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

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

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

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

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

Compliance with Notice Provisions

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

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

Analysis of Delays

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

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

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

Up to August 2017

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

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

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

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

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

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

From August 2017 to 19 September 2018

250. 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’:

(1) TCS claims that there was a dawning realisation on the part of DBS that the solution for which it had contracted would not serve its purposes without modification and that numerous RFCs were therefore needed - designated by DBS as ‘Must Have’ RFCs. As at the time of ‘Partial Termination’, it is said that DBS still had not approved or provided commercial cover for those RFCs.

(2) Then (and related to the first in that an RFC was required) there was delay and indecision on the part of DBS in relation to the question of how its 170 RBs (Registered Bodies who would need to adapt their IT systems and business processes so that they could integrate with R1-D) would be on-boarded to the new platform. DBS came to appreciate that “big bang” migration was not going to be operationally viable, and that a means needed to be found to stagger migration of the RBs. While TCS planned to design a “bridge” that would allow phased migration over an extended period, TCS says that DBS dragged its feet and ultimately rejected the RFC pursuant to which TCS proposed to build it (RFC 607), instead choosing to de-scope R1-D.

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

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

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

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

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

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

257. 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:

‘I think that's very important, for the court to really understand the difference between where we were in September 2017 versus where we were in May of 2018. So what I mention in my evidence, in my witness statement, was that before September 2017 we had finished CIT and SIT of Disclosure, and at that point in time the software was ready to enter Final SIT, and I stand by that. If the Disclosure environment was available, had it been available at that time, had the third parties been ready at that time, including registered bodies, we would have been ready to enter Final SIT back in September 2017. That's still a valid statement. Now, if you see -- if you see, if you fast-forward to what happened in the six or seven months between then -- that time frame and May 2018, a lot of things have changed, a number of RFCs, requests for change, landed in our bucket and many of them were stated as must have for R1 Disclosure, including the RFC 417 content inspection for Helion-G. You may remember, we said Helion-C was mandatory for Barring release and the back-end of that was mandatory for Disclosure release. So amongst many things, there were several new things that we introduced between Barring Go-Live and this time frame we are looking at, the email. So it is true that I said we finished CIT and SIT in 2017 and we would have wanted to -- we wanted to enter Final SIT at that stage, but because the other thing happened, other changes being introduced, we were not ready to jump into Final SIT in May 2018. So I say both are valid statements.’

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

259. 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:

‘A significant amount of work is still required to understand the solution for Standard and Enhanced Disclosures, and also the implementation and migration approach for the Registered Bodies (RBs), before we consider involving them in System Integration Testing.

DBS currently have over 160 organisations that submit nearly 4million Standard and Enhanced Disclosure Applications. Some of these Disclosure Applications exist within the RB systems or the DBS systems for up-to 6 months. So far, within the R1 solution for Standard and Enhanced Disclosures there is no consideration for a phased migration of the RBs to migrate from R0 to R1, or how the solution implementation will provide business continuity for all the RBs during the R1 Disclosure Release.

Experience (from the Digital Connect Hub project) and feedback from the RBs has already informed DBS that the solution cannot be implemented in a “Big Bang” approach for all RBs, and in fact the migration will take a number of months.’

260. 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:

‘DBS has indicated that there may be RfCs that are required (Must Have) for Disclosure. However the list is neither firmed-up nor agreed. Hence there is a risk that code changes to accommodate the Must-have RfCs may be deployed to Test Environment, while Final SIT is underway.’

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

262. 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’.

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

‘My thoughts are that we should completely shut down R1 transformation, have a lean team to debate on finalising the list of 52, and purpose re start, only on the finalisation of the list and the scope. Our argument would have to be that the list of 52, along with the decisions that DBS has to make on strategy of disclosure release, makes it impossible to finalise the scope and strategy of our delivery.

I feel we will continue to burn heavily in any pursuit to deliver Disclosure, without containing its scope or re work.’

264. Mr Narayanan responded on the same day:

‘This is in line with what we discussed. Let’s scale down our R1 team drastically and not entertain any planning discussions until we resolve the 52 (or 38 as I understand) outstanding issues.’

265. 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’.

266. 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.”

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

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

269. 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:

’- Cannot completely divorce commercials and delivery

- There is no plan as yet for disclosure

- The data migration and cleansing challenge should not be under-estimated

- The transition for RBs cannot take a big bang approach.’

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

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

Q. And would you really expect a supplier like TCS to

continue ploughing on testing software that it knows

that its client doesn't want because it needs at least

some changes?

A. I don't think I should answer that question.

Q. It requires, of course, continuing DBS's cooperation,

doesn't it?

A. Well, yes, because you've got to impact assess, solution

assess and agree the RFCs in order to agree the scope,

that's correct.

Q. So -- and in fact, even to progress Final SIT, as

matters stood for R1 Disclosure, TCS couldn't strike out

alone, it needed DBS cooperation?

A. Yes.

Q. And actually, it needed the third party cooperation, at

least at some stage down that track, from RBs and from

Disclosure Scotland?

A. Yes.

Q. And on any view, an implication of the RFCs was the need

to replan Disclosure?

A. Potentially.

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

273. 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’.

274. 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:

‘Deployment scope and date is still under discussion with TCS

Lessons learned from Barring and Basics deployment will inform strategy e.g. data migration eRB transition

Protection of DBS live service remains the priority.’

275. 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’.

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

277. 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:

‘All RBs must be able to submit applications into R1. This will require RB’s to be transitioned off R0 and onto R1 over an agreed period of time….

The solution must ensure that at least 6 months’ notice of the change is communicated to RB’s.

…

If the change is not implemented, there is a risk that RBs will not successfully transition onto the R1 service, leaving them without an electronic channel to submit applications. DBS will not be able to cope with the volume of paper applications if RBs cannot submit applications electronically and, as a result, revert to a contingency process…’

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

‘As discussed in my first report the challenges of migrating a large number of RBs from R0 to R1 was not a new issue as moving all 170 e-RBS from one interface to another simultaneously would always have been very challenging, if not impossible, to achieve.

TCS’s Data Migration Strategy does not consider this issue, it focuses on identifying data that needs to be migrated from R0 to R1 in a ‘big bang’ approach. I have not been able in the time available to identify what approach TCS intended to take to RB’s prior to RFC 607 but note that they appear to have included an R0-R1 bridge which would be tested as part of SIT 253.

This would presumably have allowed data to flow between the systems during parallel operations.

I agree with Mr Britton that the parties’ apparent inability to agree an approach to data migration introduced significant uncertainty and made it difficult to produce a complete plan.

However, it does not appear to have affected TCS’s ability to enter Final SIT.’

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

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

‘Indeed, any plans for R1 Disclosure were disrupted because we always thought we had an agreed plan for data migration, but DBS said that they wanted to change the approach. Standard and Enhanced Disclosure checks were already taking place and so there was a lot of existing data to migrate. The planned approach was a "big bang", meaning we'd shut down the legacy system and start with R1 Disclosure at once. This was a complex data migration project with a huge data volume. In early 2018, DBS said that there was a huge risk that the RBs would not be ready and therefore the "big bang" data migration approach would not work. DBS no longer had the appetite to take that risk. I first heard about this from Amit, who had received the message from Peter Evans.

An RFC was raised (RFC 607) to stagger the data migration and create a new solution where an RB could exist and send applications in both legacy R0 or R1. I felt this was a very significant change.’

281. 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:

‘Both,

Thank you for meeting Paul [Whiting] and I today. I found the meeting very helpful in outlining our positions and agreeing how we will take forward the forthcoming commercial discussions.

Commercial issues

At our meeting today we agreed the scope of the commercials that have thwarted progress with the remaining disclosure deployment. We agreed that the discussions should consider all matters as a package with a view to reaching agreement on a safe delivery of R1 disclosure as part of an agreed extension period. The individual elements to be discussed being:

Disclosure scope; to include phased RB migration

Ticket price and volumes; this can include proposals for a revised payment mechanism for the extension period and a review of basic volume forecasts for 17-18, and other forecasts for the final year of the contract

R0 extension costs; taking into account risk and additional cost to run the service

Cause for delay

In order to maintain progress with the disclosure planning, in principle DBS agreed to consider the actual additional third party costs accruing to TCS above the 110% threshold for 2017/18, subject to these being appropriately evidenced.’

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

283. 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.”

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

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

286. 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’.

287. 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:

A screenshot of a computer

Description automatically generated

288. 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:

A screenshot of a project management diagram

Description automatically generated

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

Q. Absent their agreement, R1 Disclosure could not go

ahead; do you agree with that?

A. I can't -- I can't say for certain. All I'm looking at

is the list of RFCs that say they are must haves. That

-- on the basis of that evidence, I can't disagree with

that.

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

291. As at 20March 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.

292. 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:

‘…Plan indicates a Disclosure Go-Live of July 2019 which is driven by TCS assumptions. [Mr Evans] agrees that the plan is viable/achievable but contains no contingency although may contain some optimism bias. Large part of plan is taken up by eRB transition with an overall total Programme cost of approximately £19.5m to reach Disclosure Go-Live.’

In the section of the meeting attended by TCS, Mr Shah of TCS reported:

‘11. Disclosure plan

‘[Amit Shah of TCS] advised that the plan as presented has already moved by four weeks and that R1 PB should not look at dates but what needs to be done. This plan is more activity driven with the first item on the critical path being RfCs, then when these are finalised will move onto GDPR and then stakeholder readiness.

…His biggest worry on the plan is RfCs, data migration and scoring on Update Service profiles as this will also generate lots of work for DBS. AS feels that these items are captured in the plan.’

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

Q. And if they [the RFCs] couldn't be agreed with TCS, R1 Disclosure

was not going to go ahead, was it?

A. No.

Q. They were never agreed, were they?

A. No.

Q. So there came a point in time at which it was clear that

R1 Disclosure was not going to be provided?

A. Yes.

294. 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:

‘DBS have taken the decision to not proceed with this RFC. DBS position is that the parallel running of R0 and R1 was discussed between the technical teams in order to prevent TCS to have to write complex migration rules for in-flight applications.

However as was discussed and agreed in the forum, data migration is a TCS responsibility and as such, if this is the approach that TCS wants to take the decision rests with TCS. Any period of time during which both applications need to be up to enable DBS to complete the in-flight applications in R0 because TCS have elected not to migrate the in-flight applications is at TCS own cost. The transformation tool will allow all applications to be submitted into R1 from the point at which it goes live so the only reason for R0 to not be decommissioned is to allow DBS to complete the in-flight applications which TCS have chosen not to migrate until they are complete in R0.

So, currently DBS do not view this as requiring an RFC.’

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

296. 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:

‘Development of new Disclosure product and a big-bang delivery approach with any supplier is deemed [ ]”. The word following ‘deemed’ is missing (it is not clear if it has been redacted) but from the context it is clearly a pessimistic or negative word (which would also accord with Dr Hunt’s evidence about the inherent difficulty or impossibility of such an approach in principle).

“Seek a 1 year contract extension to allow for transition to new suppliers”. In other words (although this was called a ‘revised Plan A’) effectively this was the cessation with TCS in which TCS would not deliver R1-D. The “Preferred Programme Approach” indicated that it assumed “TCS Disclosure delivery ceased immediately’.

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

298. 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:

‘3. The major dependency is on eRBs; with DBS holding the line that the eRBs need 6 months notice before implementing any changes. DBS will not engage with the eRBs, because the ICD has not been approved. We are waiting for the GDPR change to be raised and approved before updating and issuing the ICD. I think we should make any corrections to the ICD, resulting from the Barring / Basic release, and issue the ICD as it is. When the GDPR RFC is approved we can commence work on the changes.

4. Although the availability of eRBs appears to be on the critical path, the introduction of the bridge means that R1 Disclosure can go live without eRBs converting to the new R1 solution.

5. The availability of MET to engage with us to progress Final SIT. MET are likely to be available by the end of May. However, MET do not have to make changes to consume the Web Service.

6. ANI being ready to participate in Final SIT. ANI / DBS are disputing who should pay for changes to the ANI systems. This probably won't be resolved until the end of May and then ANI's suppliers will have to make the software changes; which would take approximately 4-8 weeks to develop and test.

7. Disclosure Scotland's availability to participate in Final SIT. They are unlikely to be available until the end of May or later.’

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

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

301. 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:

‘The concept of parallel running was accordingly proposed by DBS in its first problem statement and then planned by TCS in order to assist DBS. For DBS to now assert that RO/R1 Disclosure parallel running is a TCS requirement so as to avoid migration of in-flight applications is very disappointing and disingenuous. It appears that this is another case of DBS again trying to unjustifiably shift blame to TCS for changes to implementation of R1, when the primary driver for RU/R1 parallel running was a change in DBS' risk appetite concerning the approach towards service cutover.

If, as your emails dated 25th April 2018 (previously referenced), and also the updated Rfc 607 (v1.4) seem to suggest, DBS does not require this change then TCS will revert back to its original solution, i.e. TCS will plan to migrate all in-flight RU applications to R1 in a single migration, with no requirement for parallel running. We will now re-engage with DBS to agree how we move forward with in-flight application migration and we will move ahead on the basis that DBS have now accepted the risk that comes with this approach.’

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

‘…So, again, I know this is not your letter, of

course, it's a TCS letter, but if you agree with

the first sentence, as I have just asked you about and

as you've indicated that you do, then it does follow,

doesn't it, that in fact R0/R1 Disclosure parallel

running was not in fact the idea of or a request of or

arose from something on the TCS side, it arose from

something on the DBS side?

A. Yes, that -- that's my understanding.’

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

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

Q. … And we can see that the actions that are included is that:

‘The team will cease to work on any disclosure activities. This will include ... releases in drop 8, drop 8 review items, drop 8 defect fix, PMS development, drop 8 ... including PMS testing.’

Then I don't need to read on. What's clear from this message is that there is an instruction coming from somebody that further work on R1 Disclosure should stop; that's right, isn't it?

A. Yeah.

Q. And I assume, given that you were in charge of the project, you must have been -- must have (a) known about this, and (b) must have given the instruction?

A. So, I think there is a mail that I have also sent at that point in time to Shankar right there, another the time frame -- similar time frame, but I mention we should stand down the team because we are not having the inputs needed for us to go forward. So it is better to stand down and have a lean team and wait for, rather than having the whole team wasting their time. So it is probably in that context when you are saying that we should cease to work on disclosure activities until we get those conclusions done. What I am not able to mention -- see from this letter is what is that he's waiting for which -- which is making him feel that it is better that we get those results out before we start engaging the teams further.

So, yes, there is a call at that point in time to step down the team, because we had a whole bunch of people waiting and not able to execute work because of some impediment. I'm not able to fix my mind on what that single element is.

305. 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’.

A white grid with numbers and numbers

Description automatically generated

306. The Board’s conclusions were as follows:

‘• That their priority is to protect the live service;

• No option is without risk and on balance Board agreed that the revised plan provides the best approach to manage the risk and protect delivery of the service.

• That R1 performance is not acceptable and therefore too risky for disclosure;

• It is more complicated to build a new R1 platform with another provider for disclosure to then disaggregate from it;

• That should we not pursue R1 Disclosure and therefore DBS doesn't need to continue with TCS

This recommendation is to continue with the preferred course of action to negotiate with TCS in order to securely exit the current contract.’

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

308. 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:

‘As you are aware, a detailed plan must still be agreed between the parties before we can continue with delivery of R1 Disclosure and it is incorrect and wholly impracticable for you to maintain that TCS should have continued to plan implementation whilst DBS had, at the same time, engaged TCS' migration resources (via RFC 607 and various workshops) to consider a different approach to migration, including parallel running of RO and R1 Disclosure. DBS made clear this was to assist with the staggered onboarding of Registered Bodies to R1.’

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

310. 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:

(1) Barred List - Deletion of Records;

(2) Basics Certificates Data Breach;

(3) Forward Button, Barring Portal;

(4) Data integrity - victim’s records;

(5) Problems with Barred List Upload; and

(6) Performance and efficiency of Barring and Basics.

311. 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:

‘One of the issues in the dispute resolution procedure was the treatment of the so- called “Deferred items” and the timetable for delivery of Disclosure. It was clear, even in September 2017, that the parties would need to agree a timeframe for the delivery of Disclosure, which was (at that point) promised for November 2017. Since then, the parties have been unable to agree how to proceed with the project. In the circumstances, as a result of the Delay, our client sees no way that Disclosure can be delivered before expiry of the Term. In any event, the serious issues with Barring and Basics require urgent resolution before any further work is done.’

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

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

314. 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 project continues to be affected by poor planning. For example, TCS’ specification for the mapping and migration of disclosure data lacks detail and there remains a considerable amount of effort to complete the mapping specifications to the standard required. The strategy for migration of profiles and the update service subscriptions is reliant on manual input and support from DBS. No data cleansing strategy or rules have been published and therefore DBS cannot make an assessment of the extent of the necessary data cleansing tasks. DBS has no confidence that the data migration activities, a prerequisite for the delivery of Disclosure, can be performed before expiry of the Term. DBS has also repeatedly expressed concern about the fact that TCS wishes to migrate the data over nine days (one “big bang” cut-over event), rather than finding ways to make the task more manageable, less disruptive and risky. In short, TCS’ plan takes no account of the very serious issues experienced with data migration to date and it does not address the fact that DBS would not be able to operate its services during the nine-day cut-over period.

Further, TCS expects to migrate all the Registered Bodies at once. There are around 2,000 Registered Bodies which are all independent of DBS. They do not all have the capability to develop and test a new interface to DBS without assistance. It is not sensible to assume that they could do this work within the 9 day cut-over window and, in any event, TCS has made no plan for this. The migration of 45 Registered Organisations to the new Basics platform required extensive planning and took 6 months.

…

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. TCS has missed the contractual Milestones already and it has also failed to meet its own subsequent deadlines. There is no realistic prospect of TCS delivering R1 Disclosure in accordance with the Agreement, whether within the remaining Term or at all.

The breaches of clauses 3-6, the failure to produce Remedial Plans, the breakdown in the Contract Change Procedure (Schedule 2-7) are a result of TCS’ defaults.

…

DBS is entitled to rely on clauses 55.11-55.15 (the Partial Termination provisions) and thereby to invoke the Contract Change Procedure so as to remove R1 Disclosure from the scope of the Services.

…DBS is actively contemplating exercising its right to rely on clauses 55.11-55.15 to remove R1 Disclosure from the scope of Services as identified … above.’

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

‘This letter is one month’s Notice, issued pursuant to clause 55.11. As set out in the letter from the Authority’s lawyers, Bristows LLP, dated 18 September 2018, TCS:

1. is in material default of the Agreement and such default or defaults are not capable of remedy; and/or

2. is responsible for material default(s) that have not been remedied in accordance with the Remedial Plan Process.

These Defaults have already prevented the delivery of the new, modernised functionality known as “R1 Disclosure” (defined in Annex 1) on time or within the current Term of the Agreement. The Authority is therefore exercising its rights to vary the Agreement using the Contract Change Procedure, to remove R1 Disclosure from the scope of the Services, in reliance on and in accordance with the procedure set out in clauses 55.11 and 55.14.’

The parts of the Agreement that shall be varied are set out in Annex 1 to this Notice. However, this Notice shall not affect or vary TCS’ obligation to provide the current “live” Disclosure services using the legacy systems that are now in use, known as “R0 Disclosure” as well as the R1 Basic and Barring Services (together, these services are defined as the “Live Services”).’

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

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

318. 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:

(1) at September 2017, TCS could have commenced Final SIT but for the absence of the availability of SIT-L with connectivity to support the R1-Dinterfaces;

(2) from around this time, both parties became increasingly aware, and proceeded on the basis that, in order to provide a viable R1-D solution, there were a number of changes to the specification which were required (‘Must Haves’) and others which were, if not technically required in order for a legally compliant solution to be delivered, practically necessary given the limitations by then understood on the capabilities of the RBs to be ready for transition (i.e what became RFC 607);

(3) in light of this, TCS was not in fact progressing at full steam towards R1-D Final SIT, principally pending clarification and finalisation of DBS’s required scope, in addition to work required in respect of its own deferred items;

(4) this position was well understood by DBS from at least October 2017 onwards. It was agreed in writing on 6 February 2018 that there would be a joint replanning exercise and proposals for agreed changes in scope to deliver (at least) a minimum viable product;

(5) in parallel with this, DBS’s internal strategy developed from late 2017 into one in which, by the spring of 2018, DBS did not want TCS to deliver R1-D at all. In April 2018 DBS sought to blame TCS for its determination that the transition could not be managed by way of a ‘big bang’, but irrespective of RFC 607 there remained other key ‘Must Have’ RFCs the resolution of which were essential for delivery of a minimum viable product;

(6) by June 2018, negotiations had effectively broken down. TCS stopped work on R1 Delivery;

(7) DBS also resolved by June 2018 to seek approval for its preferred option of not building a new R1-D product, with a new provider taking over the existing R1 system as it was (B&B) and the current R0 (Disclosure), and bringing TCS involvement with DBS to an end as soon as practicable;

(8) in September 2018, immediately after approval by the relevant part of the Home Office of its strategy to end the contract with TCS, it sought to de-scope R1-D by way of a purported Partial Termination;

(9) following de-scoping, there was in fact no further material progress on R1-D. This is because DBS regarded it as having been lawfully removed as scope and whilst TCS disputed the lawfulness of the removal, progress could not in fact sensibly be made without DBS co-operation to resolve ‘Must Have’ RFCs (including GDPR) and/or for testing and delivery at that point and in the future.

Analysis

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

320. 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:

Failed to confirm its desired functional scope of R1 Disclosure in relation to the Customer-to-Business portal and Accountable Officer’s Update Service functionality. Such confirmation was a prerequisite to any necessary changes to the code base being implemented and tested.

321. 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:

‘What was not clear at that time was if the functionality of citizens submitting the Basics Disclosure applications and the associated system-driven checks for the Accountable Officer ("AO") would work fine in the R1 Disclosure code base in spite of all the RFCs on the related functionalities. There were also some very key open questions about the AO verification process which needed to be clarified by DBS. (For example, under the original scope, the AO themselves needed to first submit a Basic Disclosure application in the R1 system so that they could be vetted; also the AO needed to have an active subscription for a recurring check called "The Update Service". With the original RFC all these functionalities were suppressed in the R1 B&B codebase and we were unclear whether DBS were looking for bringing back all these features when R1 Disclosure goes live.) So overall, while we had already completed the CIT and SIT on the R1 Disclosure, we were unclear on how much rework will be required based on what DBS may decide on the inclusion or exclusion of this citizen-facing functionality in the R1 Disclosure code base. I recall estimating approximately 100 person days' worth of effort for removing this functionality from the R1 Disclosure code base and testing it. This work had to complete before we could formally commence Final SIT.’

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

Failed to make available an end-to-end test environment for the Interactive Voice Response system.

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

Failed to agree upon a data migration approach, without which the Claimant could not complete the build of a data migration environment so that anonymised data could be made available for testing.

Failed to agree an RFC in relation to changes required to ensure that the Solution would be compliant with the requirements of GDPR.

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

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

326. 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:

‘2.1 Under this Contract Change Procedure:

…

2.1.5 no proposed Change shall be implemented by the CONTRACTOR until such time as a Contract Change Note (CCN) has been signed by both parties and issued by the AUTHORITY in accordance with paragraph 6.4.

…

2.3 Until such time as a CCN has been signed by both parties, then, unless the AUTHORITY expressly agrees otherwise in writing, the CONTRACTOR shall continue to provide and make available to the AUTHORITY the Services in accordance with the existing terms of the Agreement.

2.4 Any work undertaken in connection with any Changes by the CONTRACTOR, its Sub-Contractors or agents (other than that which has previously been agreed in accordance with the provisions of paragraph 2.3 of this schedule 2-7) shall be undertaken entirely at the expense and liability of the CONTRACTOR unless otherwise agreed between the AUTHORITY and the CONTRACTOR in advance.

2.5 Any discussions, negotiations or other communications which may take place between the parties in connection with any proposed Changes, including the submission of any written communications, prior to the signing by both parties of the relevant CCN shall be without prejudice to the rights of either party…’

DBS also relies upon, to the same effect, Clause 10 which provides:

‘10.1 Any proposed Change processed in accordance with this schedule 2-7 shall not be authorised and the CONTRACTOR shall not implement any proposed Change until the CCN is signed and executed by the persons identified in the table below’.

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

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

329. 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’.

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

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

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

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

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

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

MR JUSTICE CONSTABLE: And ultimately, if continuing means

that there's not going to be something that the client

thinks is viable, then maybe there needs to be

cooperation to fix that outcome.

A. Yes.

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

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

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

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

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

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

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

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

Failed to ensure that relevant external stakeholders were available to participate in Final Systems Integration Testing.

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

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

346. In summary, therefore, I find that:

(1) As at 7 September 2017, but for the following delays, TCS would have, with no other interference, achieved the Go-Live Milestone for R1-D within about 1 year (I will assume a Go-Live Date of 7 September 2018, insofar as it may be relevant). The delays accrued to R1-D at this point were driven by preceding R1-B&B delays and were not matters for which TCS is entitled to relief or damages for the reasons set out in relation to R1-B&B;

(2) For the period from 7 September 2017 to 5 February 2018, TCS is not entitled to relief, or damages, pursuant to Clause 7 for the delays accrued caused by the lack of scope clarity/agreed ‘Must-Have’ RFCs.

(3) For the period from 6 February 2018 to 13 June 2018, neither party is entitled to claim that the other party is in breach for the further delays accrued;

(4) For the period from 14 June 2018 to 19 September 2018, TCS has established that the further accrued critical delays (day for day) were caused by ‘AUTHORITYCause’. This is a period of 3 months and 5 days (98 days).

E. Partial Termination

347. Clause 55.11 states:

‘Subject to the provisions of clause 56 (Remedial Plan Process), the AUTHORITY may, by one (1) month's prior written notice, require the Partial Termination of any part of the Services on the occurrence in relation to that part of a material Default by the CONTRACTOR, where the Default is not capable of remedy or, if the Default is capable of remedy, the Default has not been remedied in accordance with the Remedial Plan Process.’

348. Clause 56.2 states:

‘56.2.1 The AUTHORITY notifies the CONTRACTOR that it considers that the CONTRACTOR is in material Default and that it requires a Remedial Plan. The notice may specify the matters complained of in outline but must contain sufficient detail so that it is reasonably clear what the CONTRACTOR has to remedy.

56.2.2 The CONTRACTOR shall serve a draft Remedial Plan within 20 Working Days (or any other period agreed by the parties) even if the CONTRACTOR disputes that it is responsible for the matters complained of.

56.2.3 If the AUTHORITY considers that the draft Remedial Plan is insufficiently detailed to be properly evaluated, or will take too long to complete or will not remedy the matters complained of then it may either agree a further time period for the development and agreement of the Remedial Plan or escalate any issues with the draft Remedial Plan using the Escalation Process.

56.2.4 If despite the measures taken under clause 56.2.3 a Remedial Plan cannot be agreed within 10 Working Days of the date of its submission then the AUTHORITY may elect to end the Remedial Plan Process at the end of the escalation period set out in the Dispute Resolution Procedure and serve a Termination Notice which will take effect unless the CONTRACTOR remedies the Default within a period specified in the Termination Notice which shall not be less than 30 days from the date on which the Termination Notice is sent to the CONTRACTOR … .’

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

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

351. 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:

‘The question then is what is meant by the word ‘remedy’. It could mean obviate or nullify the effect of a breach so that any damage already done is in some way made good. Or it could mean cure so that matters are put right for the future. I think that the latter is the more natural meaning.’

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

‘It seems to me that the whole purpose of a provision in a contract by which a party contemplating the determination of the contract for breach on the part of the other party has to give a notice, if a breach is capable of remedy, is to give the party in default the chance to avoid the consequence of termination of the contract if, in substance, the other party can, at the point at which notice is given, be put in the position in which he would have been but for the breach. It is difficult to see how such a provision could be of any practical utility if the fact that the date for performance of a positive obligation had passed meant that the breach of that obligation was to be taken to be irremediable, even if it could be performed late. Until the last date for performance had passed there was no breach. It would be strange if in those circumstances, the moment there was a breach that breach was irremediable, however quickly thereafter the obligation could be performed. …’

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

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

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

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

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

358. 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’.

359. 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’.

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

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

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

363. 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:

‘[Janette Cowburn, DBS Associate Director for Commercial] advised she assumed TCS representatives were aware of the conversation between Adele Downey and Shankar Narayanan during which Adele had informed Shankar that DBS would not be continuing with R1 Disclosure and that its preference was for a 6-month extension only. This was due to be communicated formally shortly. CO suggested, and it was agreed, that the SLA action discussions be recommenced once this formal notice had been provided.’

364. 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:

‘Establishment of a Service Transition programme to exit from TCS as soon as operationally feasible, and no later than March 2021 … The business case proposes a contract extension to be applied flexibly — we currently plan to extend for six months to allow for transition to the new arrangements by September 2019.’

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

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

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

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

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

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

F. Delay/Partial termination Related Quantum

TCS’s Claims

Manpower Costs

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

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

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

374. 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.’

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

376. 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:

June	July	Aug	Sep
297,512	212,942	193,864	125,699
456,294	330,421	252,846	172,754

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

378. 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 [2] verified costs and £973,827 [3] unverified as to amount).

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

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

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

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

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

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

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

386. 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:

‘… I'll get you the range -- so the 3.6 is at the bottom of the range, the 9.7, the overlap with Mrs Wall, is at the top of the range, and then I think the figure that I promote is 1.5 million less than that, depending on whether you accept Mr Padannayi's evidence that the payroll costs in the final month for which we have data available carries on through to the end of the contract.’

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

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

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

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

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

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

Non-Manpower Costs

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

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

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

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

397. 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 [4], making £1,732,989.70.

Anticipated Cost Savings

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

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

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

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

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

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

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

405. 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%.

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

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

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

(1) adjusting the figures in row 23 to reflect an 18% saving rather than 22.9%;

(2) calculating the total of the as adjusted figures for all of the months from July 2019 to the end, plus 17/30 of the amount for June.

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

Summary of TCS’s Delay Claim Recovery

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

(1) Manpower costs: £666,735

(2) Non-Manpower costs: £ 1,732,989.70

Total: £2,399,724.70

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

DBS’s Claims

CCN 041

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

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

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

‘The AUTHORITY has undertaken an assessment of the delay and has claimed cost impacts from the CONTRACTOR. Pursuant to clause 6.3.2 of the Agreement, since the CONTRACTOR’s delay will be more than six (6) months, the AUTHORITY calculated its actual additional costs incurred as a result of the CONTRACTOR’s failure to Achieve Milestone GL R001(a) (Go Live of Phase 1 Barring - 17/12.2015) and GL R001(b) (Go Live of Phase 2 Disclosure - 31/03/2015, rather than relying solely on the Delay Payments provisions in the Agreement. While the AUTHORITY’s calculation indicated that it has incurred costs of more than £6.2m (inc. VAT), this figure was not agreed by the Parties and following further discussions the AUTHORITY has agreed to accept CONTRACTOR’s offer to pay damages in relation to the failure to Achieve Milestone GL R001(a) (Go Live of Phase 1 Barring - 17/12/2015); and failure to Achieve Milestone GL R001(b) (Go Live of Phase 2 Disclosure - 31/03/16) (together the “Breaches”), for the sum of £4.56m (inc. VAT) (the “Settlement Sum”).

The CONTRACTOR shall, within seven (7) days of the date of each monthly Service Charge invoice provide a credit note to the AUTHORITY for the monthly sum of £316,666.66 (exclusive of VAT) to reimburse the Authority in respect of additional costs it will incur during the period of twelve (12) months from the CCN Effective Date.

In the event that the entire Settlement Sum cannot be applied against future invoices within the period of twelve (12) months, the remainder of the Settlement Sum shall be paid immediately to the AUTHORITY upon written notice of the same, and such sums shall become a debt, together with any interest accrued in accordance with the Late Payment of Commercial Debts (Interest) Act 1998

…

7. CCN Effective Date

(The date upon which changes to the Agreement are to take place).

[INSERT].

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

‘There was a delay at the end of 2015 which is recorded in the unsigned copies of CCN 041. I remember this document because CCN041 was never signed off and therefore it was something that always appeared in our logs and meeting minutes. Also CCN041 was the first time TCS “held their hands up” and volunteered that they were responsible for delay. The sum recorded in CCN 041 was agreed (£4.56 million) and was never changed or disputed by TCS. In return for the delay payment, DBS also agreed to new dates for delivery of the Milestones at the end of 2016. However, whilst TCS and I were in the process of negotiating and writing up the wording CCN 041, there were more problems with the project which made DBS conclude that the new Milestones (at the end of 2016) were at risk of being missed as well.’

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

‘I remember participating in the discussions about the delays in 2015 which were caused by TCS (CCN041). I worked up the figures to calculate DBS losses in order to put them to the R1PB. Afterwards, I recall that negotiations with Mike McCarthy of TCS began. It was agreed that TCS had caused the delay and the sum itself was agreed and never in doubt. However, from my recollection, the change request itself was never finally agreed because it included additional points which TCS would not agree. Colette Owen was heavily involved with this.’

417. 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:

‘CCN 041 for the R1 Delay (September 2015) is yet to be signed. This now forms part of the commercial negotiations for the R1 Delay (July 2016).’

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

Q. Yes. And your position was that if the CCN was entered

into -- and can I just add this, it was anticipated by

everybody, wasn't it, for it to be effective, that it

would be signed?

A. Yes.

Q. Yes.

And when it was -- and then it would have an

effective date as well, wouldn't it?

A. Yes.

Q. Yes. I mean, we can see that ourselves from looking at

the document.

A. Yeah.

Q. And as we know, it was never signed by either DBS or in

fact TCS, was it?

A. That's correct, yes.

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

420. 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’.

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

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

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

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

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

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

Delay Payments

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

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

R1-B&B Delay

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

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

431. The sums claimed by DBS are:

(1) Disclosure Scotland Extension Costs: £1,036,830 (Item 1)

(2) R1 Barring Loss of Anticipated Savings: £2,424,934 (Item 3)

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

Disclosure Scotland Extension Costs - Item 1 of the Updated Schedule of Loss

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

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

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

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

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

‘BH explained that the new letter of direction from the Minister was slightly different to previous letters of direction as it extended direction up until end June 2[0]18, if required. DBS has agreed a transition plan with Disclosure Scotland between 1 September and 31 December. These dates have been communicated to staff and Responsible Organisations (ROs). The transition plan is a phased approach over four months and will leave Disclosure Scotland with 10% of volumes. PCS welcomed the new letter of direction but was concerned because the transition was taking place during a time of peak volumes for DBS and Disclosure Scotland. BH advised the dates had been carefully considered but due to Disclosure Scotland’s contract with BT ending in March 2018 and FTE contracts ending, transition by December was most viable. BH confirmed the phasing approach was designed to deal with peak volumes and DBS was working with ROs to identify the most appropriate time for them to onboard. DBS had proposed to second staff to Disclosure Scotland to support the transition period. Due to other matters formal consultation on the secondment proposal had not yet commenced….’

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

Q. Right, okay. So that's clearly telling us, isn't it,

that over this phased period DBS is proposing to send

staff to Disclosure Scotland to help, ie support,

the transition period? I mean, surely you accept that,

because that's what it says?

A. Yes, but it was also result of the delay in bringing

the services across, because the system wasn't ready to

do it at an earlier period.

Q. Well, there are two things here, aren't there? We know

that the ROs weren't ready, were they, because that's

what is being referred to when it says -- and this is

one of the two reasons for the phasing -- one was:

"... to deal with peak volumes ..."

And the other was:

"... DBS was working with ROs to identify the most

appropriate time for them to onboard."

You see that?

A. I can see that, yeah.

Q. Okay.

Now, it would follow, wouldn't it, surely, then that

if in fact DBS had -- let's pretend it was entirely

within DBS's gift -- opted for a shorter transition

period, then it may well have been that no secondment

was necessary at all?

A. It's my understanding the secondment was necessary

because of the -- the delay and the plans that

Disclosure Scotland already had in place that couldn't

be easily undone that meant they were winding down their

operations. That's my understanding. I wasn't close

enough to -- I wasn't close enough to

the responsible organisations myself, so I wasn't part

of those discussions, and as I said, it was Gareth that

was liaising directly with -- with Disclosure Scotland.

So, yes, whilst I was part of the -- the finance team

and we would be reporting on the numbers --

Q. But nobody is suggesting here, are they, that in fact

this four-month phased transition is because there's

been a failure by Ms Downey, or the Home Secretary, or

anybody within DBS to give proper notice to

Disclosure Scotland, are they?

A. My -- as I said, my understanding -- I can't --

you know, I can't talk to a failure, or

the communications there were between DBS,

the Home Secretary or Disclosure Scotland. As I said,

I'm not privy to those personally, other than what

you've shown me on the screen today.

Q. So --

A. It's my understanding that Disclosure Scotland had

already put plans in place to wind down those

operations, and the fact that the delegation, or the --

is the "delegation" the right word? The fact that it

was extended by the Home Secretary didn't necessarily

mean that they were able to undo the already-planned

winding down of the facilities and the staff that they

had in place. The --

Q. My question to you was a far simpler question and it was

this. We don't see anything in this document, do we,

that indicates that the reason for staff having to be

seconded up to Disclosure Scotland was because of

the lack of notice being given by DBS?

A. Not -- I can't see that the -- in this document, no,

that it was a lack of notice given by DBS.

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

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

Loss of Anticipated Savings - Item 3 of the Updated Schedule of Loss

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

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

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

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

(1) presented the anticipated removed and decreased FTE savings from the WFPM v15.6;

(2) calculated the total FTEs employed in each year by grade (for 2016/17 this represents the FTEs for the period from October 2016 to March 2017 only);

(3) calculated the proportion of the FTEs employed in each year, by grade, which were expected to be removed (“FTE % Removed”) or decreased (“FTE % Decreased”), e.g. the anticipated removal of 37.9 FTEs at the AO grade represents an anticipated FTE % Removed of 40% when compared to the 96.0 FTEs actually employed in 2017/18;

(4) calculated the total cost incurred in each year by grade (for 2016/17 this represents the costs from October 2016 to March 2017 only);

(5) applied the FTE % Removed to the total costs incurred in each year by grade to calculate the “Removed Cost”; and

(6) applied the FTE % Decreased to the total costs incurred in each year by grade to calculate the “Decreased Cost”.

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

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

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

‘In around May 2016, some work was started by Dawn Wayman, Head of Service for R1 Transformation in Barring, to try to forecast savings that would be achieved from delivery of R1 in Barring. To do this, the WFPM was looked at with a view to stripping out the functions that would be replaced by the R1 Solution (or transferred to TCS’ back-office processing) and to calculate the anticipated savings. I knew this wouldn’t give us an exact answer as to savings, because the WFPM was not a perfect reflection of existing workloads and the lack of visibility of the R1 solution meant that we did not yet fully understand the additional work that would be created by the changes to our processes. However, I accepted, based upon what I was told by Dawn Wayman, that such an approach would provide us with a usable estimate.’

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

449. 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,

‘Both Mrs Wall and Mr Hain use the WFPM as a sufficiently reliable source for the basis of 64.7 FTE [Full Time Equivalents] on which to estimate the number of staff roles expected to be removed and reduced as a result of R1 going live….’

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

451. 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:

(1) The changes ‘marked against activities’ were ‘based on limited information’;

(2) ‘all changes marked against activities in the 'R1 view' WFPM file (or: DLOD tab) refer to the expected situation ~6m after go-live.’

(3) ‘activities marked as ‘removed’ need to be confirmed with the business via validation of relevant R1 processes/ procedures’.

(4) ‘activities marked as ‘decrease’ … are known to have a similar activity in R1 with an expected decrease in effort which needs to be confirmed with the business owners and cannot be quantified at this point’.

(5) ‘where activities are marked as red the current view is they may require more effort than today however this cannot be confirmed at this point.’

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

A close-up of a white paper

Description automatically generated

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

A black text on a white background

Description automatically generated

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

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

456. 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.’

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

Now, that must tell us, mustn't it: well, you can't

necessarily take the 52 FTEs as being pretty much

the likely position, because in fact what that 52 does

not take into account is what we see at 5.1.7, in other

words, the additional workaround -- the additional

processes or temporary workarounds. Do you see that?

A. I think in terms of what I've said about the 52

previously was that was what we expected to realise by a

task removal in a steady state position. 5.1.7 is

reflecting on the fact that, well, we won't get to that

point until all operational areas have gone live, and at

that point in time also we didn't know whether or not

there was other things that we would need to add. There

was the unknowns in terms of how R1 operated that might

potentially ask us or require us to do additional tasks.

That's what the caveat is being reflected there. That's

my understanding.

458. 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:

A white background with black text

Description automatically generated

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

So, one thing that we can see from this is that, if

we wanted to work out, or the business, so DBS'

commercial side wanted to work out what the anticipated

savings might be, it would need for these tasks to have

been carried out and reported on in order to do that,

wouldn't it?

A. Yes.

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

Q. So, it's quite clear, isn't it, that you had real

concerns at this time in anybody placing reliance on

version 15.6?

A. Yeah, I think it wasn't just at this time, I think,

prior to Go-Live, I think there was concerns that had

been expressed, as we reflected on before the break. We

were saying that a lot of it was estimate and

assumption, and until we got exposure to the solution,

we wouldn't be able to accurately estimate what our

resource requirement was.

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

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

Q. So on any basis, as we know, this is telling us that it

would be wholly inappropriate to use version 15.6 as

a basis of trying to calculate what your anticipated

cost savings would be because of the very things that we

see here that tell us how unreliable 15.6 actually was;

would that be fair?

A. No, I wouldn't agree with that.

Q. Why not?

A. Because we had to make an estimate based on what we

knew. We knew that the requirements that had been

supplied meant that certain tasks should be removed via

automation, via BP -- back office processing being

outsourced. So based on that, what we knew was going to

be removed, that was our estimate. All along in those

documents that were produced prior to Go-Live, we put

those caveats on it to say, "We do not know, because

we've got a lack of visibility of the solution, what new

things R1 might require from us."

MR JUSTICE CONSTABLE: Sorry, I'm not quite -- I understand

your evidence that is you had to do something and things

were uncertain, but in terms of the baseline, do you

think 15.6 is reliable or it needs to be adjusted in

some way given a greater level of knowledge that you

might have now, or something else? What's your ...?

A. If we knew what R1 was going to require of us at

the point in time that we generated those originally

estimates, we would have been able to have a clearer

understanding of what we needed to do in terms of using

15.6. 15.6 was the previous state. If we'd had that

greater knowledge, we would have been able to modify it

to go beyond just the removed tasks. As part of that

exercise, we did highlight the ones which we thought

would be impacted, but from a potential future --

additional saving as opposed to an additional cost or

effort, and we couldn't -- we couldn't assess those

additional costs or efforts at that point in time.

MR JUSTICE CONSTABLE: Yes, but I think the question that's

being asked of you is: we are where we are now.

A. Yes.

MR JUSTICE CONSTABLE: And knowing what you know now, do you

think it's a reliable document to use? And that doesn't

necessarily imply any criticism of it at the time at

which it was produced, it's just with the benefit of

hindsight.

A. Yes, with the benefit of hindsight, and I think

potentially that's what I was pointing out in

October 2017.’

MR JUSTICE CONSTABLE: When you say, "Yes, with the benefit

of hindsight", what are you saying "yes" to?

A. I'm saying: yes, it wasn't a -- it didn't produce

a figure that we could rely upon.

463. 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:

‘Following that work I have written separately to Jenny on the R1 impact (current and future). I think it is wrong to focus on the removed tasks and a more holistic approach is required. Persisting in discussion with PCS around FTE reductions based on removed tasks, when their members are experiencing greatly extended timescales and increased effort in key processes is possibly not the best approach. Experience now shows that the previous analysis that informed the DLOD was very much guess work with no timings produced for existing or new processes in R1.

There is therefore an urgent need for the completion of a WFPM for Barring for R1 based on timings / effort in R1 to produce an accurate picture re: any savings / required staffing.

Jenny will obviously have a view on how to approach the meeting on the 20th however I have no longer have any confidence in the DLOD figures and would not want to persist in offering them as an accurate assessment of R1 impact.’

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

…this is you

saying, "Well, look, hang on a minute, the approach that

was taken before in relation to DLOD is not really

the approach that we ought to be taking for the reasons

that you identify in this document." That's what you

were conveying, wasn't it, to Mr Cookson?

A. Yes, we -- we have a -- at this point, we've got a live

system, we can accurately -- or more accurately assess

the effort required to -- to produce Barring case work.

Q. And that's why you say, isn't it, in the next paragraph:

"There is therefore an urgent need for

the completion of a WFPM for Barring for R1 based on

timings/effort in R1 to produce an accurate picture

re: any savings/required staffing."

A. Yes.

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

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

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

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

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

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

Updated Schedule of Loss Item 2

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

R1-D Delay

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

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

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

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

R0 Licence Costs - Item 4 of the Updated Schedule of Loss

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

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

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

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

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

481. In the circumstances, the claim fails.

R0 Hosting and Infrastructure Costs - Item 5 of the Updated Schedule of Loss

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

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

484. The claim fails.

R0 Technology Refresh - Item 6 of the Updated Schedule of Loss

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

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

487. This claim fails.

R0 N-1 Sustainment Costs - Item 7 of the Updated Schedule of Loss

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

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

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

491. This claim fails.

R0 Maintenance Costs - Item 8 of the Updated Schedule of Loss

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

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

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

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

496. This claim fails.

Savings

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

G. DBS’s Defects Counterclaims

Introduction

498. 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:

Items 9-11 R1 Barring Portal Quality Issues £7,646,596

Items 12-14 R1 Basics Portal Quality Issues £11,944,475

Items 15 Technical Infrastructure & Architecture Costs £1,053,759

[Items 16 - 18 were not pursued by DBS: see DBS Responsive Schedule dated 28/07/23, #20-21 in respect of items 17 and 18, and DBS Oral Opening D2/16 in relation to item 16]

Items 19-21, 24 R1 Barring Standards/Quality Costs £6,956,753

[Items 22 and 23 were not pursued by DBS, as set out in DBS Written Opening Submissions fn58]

Items 25-31 Exist/Service Transfer Costs £9,784,410

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

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

9. Basics Portal Quality (Useability Issues)

£10m (cap applied to a claim of £10,807,874)

10. Barring Portal Quality (Useability Issues)

£6,091,027 (no cap applicable)

11. LPF Portal Quality (Attaching and viewing documents)

£15,213 in respect of RFC 591. No cap applied.

12. Barring Standards/Quality: Seiebel Useability - Useability Issues

£3,876,923 (made up of different heads of loss) (no cap applied)

13-21 . Barring Standards/Quality: Various Issues

No loss pursued/Included in item 12 (no cap applied).

22. The Security Incidents

Nominal Damages

23. N-1 Sustainment [R1]

£1,025.458 (no cap applied)

24. Exit Service Transfer

£10m (cap applied to a claim of ‘at least’ £12,301,123)

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

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

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

Quality-related Obligations

504. 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:

(1) Clause 1.1.1 of Schedule 3 which states:

;a) In today’s world, customers expect Government services to be aligned with private sector standards in terms of accessibility, interaction and overall level of service. Specifically, the proposed services shall be available online, through multiple devices (e.g. laptop or tablet) and with a high level of customer service. To meet those standards and operate the transition to the online world, the Contractor will:

i. Implement a Solution that gives priority to the online channel for all interactions with third parties (customers or partners), encouraging self-service over traditional channels (that will still remain available). For instance, the Solution will allow an Applicant to request and receive a Disclosure Certificate via a straight through, 100% online journey; …

…

iii. Set up and orchestrate a strategy to promote the move to the online channel, combining incentives and marketing and communication campaigns.’

(2) Clause 1.1.4(c) which states:

‘The Solution will deliver capability and systems to support the Authority’s following strategic principles:

[at least 50% of barring referrals online by Year 2 and 90% by Year 5 and 95% of applications made online by Year 5].’

(3) Clause 1.2.1.1 which states:

‘The portal will be designed to accommodate different types of usages, ranging from very occasional (e.g. an Applicant requesting a Disclosure) to very frequent users (e.g. a Registered Body checking applications every day). To that effect, the user interface will be clear, intuitive and optimised for efficient use, as well as customised for each type of user (e.g. an Applicant will have a dedicated, simple user interface; whereas a registered body will have access to more functions).’

(4) Clause 1.2.1.2 which states:

‘The portal will be designed to facilitate self-service:

i. Easy navigation throughout the website, via navigation toolbars, breadcrumb and easily accessible shortcuts;

ii. Powerful search engine that will allow a user to find information anywhere on the site;

iii. Guidance through contextual help, regularly updated FAQs, etc.

iv. User profile management for users to manage their credentials, preferences and personal details;

v. Access to information such as previous applications, Case-related material, etc. stored in the document repository;

vi. Access to business services & products such as Disclosure applications (basic, standard or enhanced), status checking, referrals, etc. The user journeys will be facilitated by wizard-type interfaces and online form validation; the Solution will also allow the users to save drafts and resume interrupted processes (draft applications will be stored in the secure database.’

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

Good Industry Practice and Defects

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

‘the exercise of that degree of skill, care, prudence, efficiency, foresight and timeliness as would be expected from a leading company within the relevant industry or business sector’.

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

MR JUSTICE CONSTABLE: Can I just ask a question therefore which has a slightly broader application. When you answer questions about Good Industry Practice, and you answered the question then using the word "typical" --

A. Mm.

MR JUSTICE CONSTABLE: -- when looking at what you mean by "Good Industry Practice", do you mean as in fact is generally or typically done by the industry, or do you imbue with the word "good" any objective nature to mean something that, even if, in fact, quite a lot of people don't in fact do it, it would nevertheless be something good for them to do?

A. No --

MR JUSTICE CONSTABLE: I think that's a bit of a lawyers' question.

A. I think that latter interpretation implies that you're expecting people to go further, and I'm not -- that's not how I'm using the term. I'm using the term in terms of what can be expected if you employ a large systems integrator or a large development house to develop software.

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

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

Q. … Software almost invariably has defects?

A. Yes.

Q. Ideally, you try and minimise the number of defects in a system by testing them?

A. Well, you try and design them out as well. So you ideally try to drive them out throughout the whole software development life-cycle, and testing is the final chance to get rid of them.

Q. Yes, and the various stages of testing?

A. Yes.

Q. In the real world, you're unlikely to catch all defects that way?

A. Yes, that's correct.

Q. And there are a number of reasons for that, but one is that there are some defects that only arise in pretty obscure circumstances that you might not think to test?

A. Yes, that's true.

Q. And that can include some serious defects, by which I mean defects with serious consequences?

A. Yes, there's a difference between -- yeah, serious consequences may arise from things that you couldn't possibly have foreseen, that's absolutely true.

…

Q. Now, you agree, I think -- well, in fact, I know, because you've said so, the presence of defects in a live environment is not in itself evidence of a failure by a contractor to develop using Good Industry Practice?

A. That's correct.

Q. And neither is it in itself evidence of a failure by either party to test properly?

A. No, it's -- it's -- defects will always get through.

510. 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’.

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

Digital by Default Standards

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

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

A blue and white poster with text

Description automatically generated

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

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

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

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

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

‘The Contractor will conduct a requirements elaboration stage and the subsequent iterative development of the solution design and its build as described in the modified waterfall method.’

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

‘The Contractor will use a modified waterfall approach (with Waterfall as its main philosophy but with characteristics of the Agile integrated within it) in the development of the modernised Solution for the Authority.”

And

“The Contractor will use a modified waterfall approach (with Waterfall as its main philosophy but with characteristics of the Agile integrated within it) in the development of the modernised Solution for the Authority.’

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

‘Mr Britton and I agree that TCS adopted a primarily waterfall based approach to the project, although as discussed in my first report their ‘modified waterfall’ approach explicitly included the use of prototypes. I agree with Mr Britton that it is difficult to switch to a fully Agile approach mid-project and this would have required a change in the contractual framework to align milestones and so on to the new approach. However, TCS did move to an iterative delivery and test approach, which they described as Agile, and incorporated some Agile-like techniques in their initial design approach.. …’

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

A red and black text

Description automatically generated

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

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

524. Relevant provisions of the Agreement are as follows:

(1) Clause 1.1.4(b) to Schedule 3 stated that

‘The Solution will deliver –

…

v. Effective web-based, self-service for all - HMG ‘digital by default’

(2) By Clause 12.1, the Agreement required TCS to comply with ‘the Standards’:

‘Standards’ is a defined term:

‘means the British or international standards, AUTHORITY’s internal policies and procedures, Government codes of practice and guidance referred to in schedule 2-12 (Standards) together with any other specified policies or procedures identified in schedule 2-012 (Standards)’

(3) By Clause 2.1 to Schedule 2-12 - Standards and Regulations (v2.0), TCS were to:

‘ensure that they deliver the Service to meet [DBS’] ICT Strategy whilst also following standards and regulations, and adhering to the following measurement techniques, or their replacements in the event of their being superseded, for the term of this Agreement:

2.1.1 Standards Catalogue

2.1.1.1 The parties shall agree, within 30 days of the Effective Date, a Standards Catalogue. The Standards Catalogue shall be a fully managed list of standards and policies, each of which may be, for example mandatory, default, desirable or a future target….’

(4) Schedule 2-12 itself (or no other Section of the Agreement, other that as mentioned in Clause 1.1.4 quoted above) refers to a Design-by-Default.

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

‘1.1 Purpose

The purpose of this document is to serve as an authoritative and practical compendium of standards agreed for the DBS Programme. This document is an initial Standards Catalogue that includes a list of Standards agreed on during a series of dialogues with DBS….

…

1.6 Constraints

Demonstrable compliance with current Government and HO ICT related policies and strategies are mandatory.

In particular:

…

The GDS “Digital by default” service standard (https://www.gov.uk/service-

manual/digital-by-default)

...

While there may be contractual implications in conforming to the standards included within this document, which need to be addressed. This compliance is non-negotiable and assumed in this document.’

7. DBS Standards Catalogue

A close-up of a document

Description automatically generated

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

‘The enclosed spread sheet lists all the standards and legislation that have been referenced from Schedule 2-2, 2-12 and 2-16 (Reference 3, 1, and 2 in 1.5 Document References) and identified based on discussions with the Authority during the Standards Non Functional Workshops.’

527. The spreadsheet contained the following row:

A screenshot of a computer

Description automatically generated

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

529. 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:

A close-up of a grid of words

Description automatically generated

So, the reference for BS 7925-2 (Standard for Software Component Testing) cross-references to Schedule 2-5. This relates to Testing and Acceptance Procedures and Clause 8.1 has an explicit obligation to comply with BS7925-2. The ‘Requirement’ column for line 23 is a quote from Schedule 12-2.

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

A screenshot of a computer screen

Description automatically generated

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

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

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

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

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

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

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

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

539. 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:

‘DBS need to resolve the GDS issue with TCS in the PM [Project Management] & commercial world but meantime I wanted to see if we could get the technical documents moving forwards. My suggestion is:

We make an assumption that a CCN will [formally] bring into scope GDS for TCS. We document that assumption [formally] in the Standards Catalogue and then include the appropriate GDS standards in the catalogue. …

I’ve discussed this with Fran [Sands] & Guru [Dsor] and I have sat down with Guru and put together some proposed changes to further this suggestion. …’

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

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

The Basics Portal

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

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

544. 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:

A screenshot of a payment form

Description automatically generated

545. 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:

A close up of a computer screen

Description automatically generated

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

547. The high level finding also concluded:

• Contract too restrictive to work in a digital way

• Supplier won’t work to GDS standards, bc it’s not in contract

• Not responsive, not mobile-friendly

• Not agile

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

549. 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’:

‘Following today’s call please find attached the report produced by the Home Office User Researcher who visited last Friday

I would like to add some context before you read....

You may aware that the logistics of the day did not work very well in terms of access to the necessary environments

As a consequence the assessment reinforces some of the initial feedback received regarding the GDS/HO view on the ‘user journey’

- The 1st pass Service Assessment (last 2 slides) is overly harsh in my view & separately I will address points such as Iterate/Open Source/ Test end to end/Offline/succeed first time/performance data etc... which DBS would have a different view’

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

551. 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:

;I attended a meeting earlier today with Sharron, Sushant and DBS reps to discuss the feedback we have received from the user testing of the Basic prototype. Sharron asked that I send it to you.

We received 205 comments, a lot of them were repeated comments and many related to the prototype itself. As we know the prototype didn’t not have any context help, error validation or all of the drop down menu information so therefore this makes it difficult to give a true usability results as if they had been included the number of comments would have been reduced. I have therefore not included the prototype comments in the list for you.

I have broken the comments down by severity rating and by area such as guidance/navigation etc. I have filtered what I think is relevant for TCS and by ‘High’ severity rating for you to look at to see if any of the comments can be taken on board. Most of them are wording/label feedback.’

552. 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.’

553. 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:

‘User Research and Test Phases

User research will provide suggestions to improve the user experience. They would be prioritised for the first 1 January launch and expected to be largely cosmetic and contain nothing to derail the build. It is vital that the new system is something that customers want to use otherwise there will be potential for reputation damage and complaints. PB believes that September is the best time to decide as there will be significant progress made over the coming weeks. Resources need to be focussed on this delivery. TCS confirmed they have a ring fenced team in place to make this happen.’

554. Ms Keenaghan also accepted in evidence that she understood that resource had been committed to make user research cosmetic changes and other changes (Day 12/129).

555. The PB continued:

‘Customer Experience

User research was a requirement for TCS to carry out which has not been undertaken. Chair visited India in April 2016 during which she received assurances from TCS [Aarthi Subramanian] that any changes to the Basics solution as a result of user research would be delivered. PB requires TCS to honour the commitment. Home Office Digital (HOD) is sending a User Researcher to DBS on Monday [8 August] to commence work on this.’

556. The reference to the HOD User Researcher is a reference to Ms Bartlett’s user review considered above, which led to the identification of the usability issues, and functionality concerns, relied upon by DBS. The agreement to deal with any usability issues arising out of UAT was also recorded in Mr Sands’ June assessment of compliance with DbD (in the context of principle 12).

557. In any event, both IT experts agree that the useability issues that IBM, GDS and DBS identified could have been resolved ‘relatively easily’. Dr Hunt’s evidence in cross-examination about the fixing the issues she identified in her report was as follows (Day 20/124):

Now, I'd like you to assume for me that TCS was

willing to address the issues you identify in your

reports in relation to the Basics Portal and that it had

allocated resources specifically to that task. With

those two assumptions, from a technical perspective,

the sensible thing to do in order to remedy the problems

that had been identified would be to allow TCS to fix

them rather than starting again from scratch; do you

agree?

A. Yes.

Q. And you would expect that, wouldn't you, to take far

less time, apart from anything else, than starting

again?

A. Yes.

Q. And you would also expect it to be significantly

cheaper?

A. Who knows? But in theory it should be, yes.

558. The assumptions Dr Hunt was asked to assume reflected the facts as I have found them to be. As to the likely cost of fixing the useability issues, Mr Murphy of TCS gave the following evidence (Day 5/105):

… And I recall, although I can't give specifics, that there was a number of between 50 and 100K given to me as a finger in the air, this is the sort of ballpark we're talking about.

Q. Yes, and that's the finger in the air figure you put in your statement?

A. Yes.

Q. Yes. But it's not a figure one sees in any specific proposal that's made to DBS, is it?

A. We were never asked for one, so we never provided one.’

559. That TCS was not asked for a costed proposal to fix these issues was consistent with the absence of evidence that TCS planned to charge DBS for this work. Whilst changes to functionality would potentially be matters for commercial resolution (and, if not a DBS requirement within the Agreement, that would be correct), the evidence as I find it to be is that TCS was prepared and preparing to address useability issues such as those identified in the DBS assessment referred to above. This is a different issue to whether TCS wanted the changes to be made documented through the RFC process, because it is necessary to agree how a particular issue is to be corrected/resolved (and thus that the solution is acceptable). TCS was always clear that it would want the changes it implemented to be documented through an RFC process. There was a debate in cross-examination of Dr Hunt about whether making changes in this way would be quicker through an agile working method; Dr Hunt did not agree that it necessarily would, and I accept that evidence. However, importantly, the discussion highlighted that whichever method of delivery is adopted, the documentation of changes to accommodate user feedback is part of the process whether or not the change is one which TCS is required to carry out as part of its scope, or whether it is a zero cost RFC (Day 20/121):

A. Well, I mean, all -- virtually every contract I've ever

looked at has an RFC process of some description. If

you don't have a process for implementing changes and

improvements, you don't get them. So I'm not sure that

it's fundamentally something that prevents you from

iterating and improving the service. It's a question of

whether the contract says it has to be -- whether

improvements are made free of charge or need to be

charged for and how much you wish to spend on iterating

it.

560. Indeed: this appeared to be agreed. As recorded at least internally within TCS, Ms Keenaghan agreed that no action on changes arising out of the useability testing was to be taken until an RFC was raised, impacted and approved. Requiring changes arising out of the user testing to be documented through the RFC process, TCS was in my judgment not acting unreasonably.

561. Dr Hunt nevertheless formed the view, in her report, that the decision by DBS to develop the customer facing Basics Portal itself was reasonable given the extent of work still to be done and the ‘risk’ that a further GDS review would identify more issues.

562. Mr Britton’s view was that DBS’s decision to start afresh was not justified on the basis of quality of the portal produces by TCS. This broadly accords with Dr Hunt’s view about the relative ease with which the issues she had identified could be resolved. Mr Britton’s view that the quality issues could not themselves have justified removing the scope and starting afresh was not directly challenged in cross-examination. Instead, the justification for starting afresh was put on the basis that if complying with the DbD principles is what TCS was meant to be doing, it would not be a question of simply fixing particular issues (Day 18/184):

Q. But the point is, in order to comply with

the Digital-by-Default terms, if that's -- if that's

what you're meant to do, it wouldn't simply be

a question of fixing this issue here or fixing that

issue there, you'd need to go and -- go back through

the process, wouldn't you?

A. Yes, it -- I don't -- there would be no benefit really

in going back through the process and redeveloping from

scratch. What you would probably do is to adopt it from

there going forward.

…

Q. But if you need to start methodologically in a different

way, you need to approach things differently, you need

to go through the exercise of understanding user needs

and all of the things we've seen in the standards, well,

then, if you stick with what you've got, you're really

-- you're tying yourself down, and you're not really

abiding by the process, you're adopting a process which

everyone acknowledged -- adopting an outcome which

everyone acknowledged did not use this process and then

being somewhat stuck with that, aren't you? And is that

-- I'm going to suggest to you --

A. No.

Q. -- that's not really what the standard requires?

A. I don't think the standard addresses this situation.

But I -- I think, from a practical point of view,

you know, provided the technical foundation of what's

been built is good, there's no reason why you shan't --

you shouldn't change the methodology and incrementally

improve what you've got.

563. In terms of the factual chronology, by the end of August, DBS had started to explore, internally, the formulation of an in-house digital team to look to develop a minimum viable product for the Basic product. It is clear on the evidence that DBS’s concern was the incompatibility of the solution with the broader DbD requirements (and in particular principles 4 and 5) which went - as did Mr Croall’s questions - to the fundamental methodology by which the solution had been developed and manner in which it could therefore be iterated in the future. Mr Sands’s evidence within his witness statement was that:

‘I remember that TCS’ lack of user testing and agile development in response to user feedback was a significant issue…I also recall that TCS originally had no plans to implement web analytics into the Basics Portal to obtain performance metrics on their usage which I found surprising, and demonstrated to me TCS lack of experience in delivering web solutions to UK government.’

564. The first concern of Mr Sands relates to DbD standards 4 and 5; the second relates to DbD standards 15-17. None of these were TCS obligations, and, indeed, DBS does not rely upon breach of these DbD standards. Yet it is clear that these type of concerns were driving DBS to start again, from a different place.

565. At a meeting on 28 September 2016, TCS was informed that :

‘DBS, HO and GDS are developing a “minimum viable product’ which is undergoing user research and usability testing. These are planned up until 28 Nov. LK said that a meeting was being scheduled for 7 Oct, to discuss the potential impact on the DBS Release 1 portal.’

566. The parties eventually agreed that the removal of the portal was dealt with by an RFC. Internally, DBS recorded in October 2016 the driving rationale:

‘Adele is v clear that DBS owning the customer portal (‘front end’) is a strategic objective for her. She sees this as enabling DBS to rapidly iterate existing services and build new customer services. So, although we have arrived here somewhat tactically because of TCS failure to deliver adequate customer interface, we have ended up with an approach that entirely suits DBS strategic intent’.

567. The RFC was 558. This was a consolidated RFC dealing with a number of matters, but which included RFC 552:

‘RFC 522 relieves TCS from its obligation to deliver the Basic TCS web portal for citizens, as well as removing the need for TCS to manage payment collection and identity verification. This entails in suppression of Basic online Application services for the citizen. The Update Service for Basic product is to be rolled out at the time Standard and Enhanced Disclosure go live.’

568. DBS contends, with some justification, that the issue of breach went essentially unchallenged with Dr Hunt. On breach, Dr Hunt concluded in respect of both portals:

‘In my view changes for usability were to be expected given the approach that TCS had taken to portal design and they should have planned to do user testing and incorporate the resulting changes into the portal. TCS’s failure to do so means that they did not comply with GDS or the standards of Good Industry Practice and failed to design the portals using the principles and benefits of early engagement and feedback as intended in their own modified waterfall methodology.’

569. On the evidence before the Court, this view is justified. It is clear that earlier user engagement should have been undertaken even using TCS’s modified Waterfall approach. I find that, in not doing so, TCS failed to comply with GIP. However, I do not regard that the complaints reviewed by Dr Hunt which consisted of missing functionality requirements not derived from Schedule 2-12 or Schedule 3 are made out.

570. Having established that at least some part of TCS’s development of the Basics Portal constituted a breached by TCS of GIP, it is for DBS to establish a causal connection with the loss claimed. In relation to a loss shown to be caused by its breaches in relation to the Basics Portal, the burden shifts to TCS to demonstrate that the loss ought not be recoverable if DBS acted unreasonably. I accept DBS’s submissions that, as a matter of law, that:

(1) demonstrating that another reasonable option was available is insufficient: see Wilding v British Telecommunications Plc [2002] EWCA Civ 349; [2002] ICR 1079 per Sedley LJ at [55] (restating Lord Macmillan in Banco de Portugal v Waterlow and Sons Ltd [1932] AC 452 at p. 506 {K1/1/55});

(2) the standard DBS is to be held to is not a high one: see Chitty on Contracts, (35^th Edn., 2023), para. 30-101; and that

(3) it is no bar to recovery that costs turn out higher than anticipated. A claimant is permitted to recover loss and expense incurred following reasonable acts of mitigation: Thai Airways International Public Company Limited v KI Holdings Co Limited [2015] EWHC 1250 (Comm); [2016] 1 All ER (Comm) 675 per Leggatt J at [33].

571. It is absolutely clear on the evidence, however, that the cause of the decision to implement a new solution was not the useability issues identified in August 2016, which were relatively easy to fix and in respect of which, I find, TCS was willing to fix without cost, and had the resources to do so. There is no evidence before me that doing so would not have been possible prior to Go-Live on 1 January 2017, and indeed at a project level the parties were working on this basis prior to the commencement of DBS’s parallel strategy. The evidence is also clear that in developing its own portal from scratch, DBS was seeking to obtain a fundamentally different product which was fully compliant with DbD, as it is clear GDS/Home Office was keen to happen. It was a product which TCS had not been contracted to supply.

572. Indeed, DBS’s case (paragraph 409.1 of Closing Submissions) is that it acted reasonably because TCS was not prepared to deliver a DbD-compliant Basics Portal. That reflects Mr Sands’s evidence. It is also entirely correct that TCS was not prepared to do so: but they had no obligation to do so. It is significant that within DBS’s Written Closing Submissions as to the reasonableness of its decision, an inability or unwillingness to fix the relatively easy to resolve useability issues (as opposed to the broader DbD compliance issues) are not referred to directly at all. These limited matters would certainly not have reasonably justified starting from scratch with a new solution.

573. DBS’s claim in respect of the Basics Portal therefore fails for the following reasons:

(1) the breaches established did not cause the loss claimed, and/or that even if there is some causal connection, the decision to remove the scope and design a new portal was a failure to mitigate. DBS need merely have ensured TCS fixed the useability issues, which was relatively easy, and which, I find, TCS was willing to do;

(2) there is, in any event, no suggestion in DBS’s Written Closing Submission that the pleaded justification for the removal of scope (‘A prototype was built by DBS with the assistance of GDS and presented to TCS, but TCS declined to change the work it had done on the Basics Portal’) has been made out on the evidence. No such case was put to TCS witnesses. The case is not made out;

(3) TCS’s argument that the matter was resolved by RFC 558 is correct. The scope was removed by agreed contractual variation. No reservation of rights was expressed within the RFC. Removing the scope clearly had cost implications for both parties: there was work to ‘suppress’ the Basics Portal to be carried out by TCS which was not insignificant, and there was obviously the cost of developing the new (and different) portal. Having reached this agreement through the contractual mechanism, it is for DBS to explain how they are entitled, nevertheless, to revisit what was agreed and now claim an entitlement to the costs it has incurred. Having made no reservation in respect of re-opening the agreement, I find DBS are not entitled to do so;

(4) further and in any event, the portal developed was developed to different standards. The costs claimed are not ‘like for like’ with the product required to have been produced by TCS. It is not possible on the evidence to identify what quantum would be associated with replacing the TCS Basics Portal with something consistent with the Agreement even if, contrary to my findings, the breaches established caused the decision to replace the portal, and/or that decision was reasonable in the context of curing the breaches found.

574. DBS’s Counterclaims in respect of items 12, 13 and 14 within the Updated Schedule of Loss fail.

The Barring Portal

575. It is Dr Hunt’s view that the Barring Portal (which, subject to changes that have been made since Go-Live, is still available to access) provides a very poor experience for organisational and individual users. It is her view that the portal is not ‘clear, intuitive and optimised for efficient use’ nor ‘customised for each type of user’.

576. Dr Hunt presents the basis for these conclusions in her Appendix E. This identified 6 complaints, of which 6 were designated ‘High’ impact, 3 were ‘Medium’ impact and 5 were ‘low’ impact. Of the ‘low’ impact items, DBS indicated that it does not maintain its complaint in relation to two of them (items 9 and 12).

577. TCS’s denial of breach in its Closing Submissions related solely, and in reality with limited vigour, to its reliance upon the fact that DBS had been involved in a collaborative manner in relation to the development of the screens. Similarly, Mr Britton referred often in his cross-examination to the fact of UAT, and that the complaints made by DBS had not been picked up by DBS testers during that phase of testing.

578. I accept DBS’s case, supported by Dr Hunt, that in reality the sort of problems complained of by DBS would probably have been picked up in effective usaebility testing, which should have been conducted but which, as accepted by Mr Argawal of TCS, was not. Mr Britton also accepted that useability testing to enhance the design should have taken place during the design phase.

579. In the circumstances, I find that the matters of which Dr Hunt makes complaint are instances in which, by reason of a failure to have complied with GIP, the Barring Portal did not comply with the specification, in that it was not clear, intuitive and/or optimised for efficient use’ nor ‘customised for each type of user’.

580. DBS also relies upon the Barring Portal failure to have delivered a system which would support DBS’s strategic goal of having at least 50% of barring referrals being only by Year 2 and 90% by Year 5: as identified by Dr Hunt, take up was around 25% after 2 years (there is no comparator for Year 5). The difficulty of making a finding in this regard is that, for obvious reasons, take up of the website relates to a whole range of factors, of which the useability of the site is just one, including the extent to which the site was promoted by DBS. In this regard, DBS’s internal assessment in October 2020 identified that 100% of those referral organisations who continued to make referrals using the paper service would move to an online system to make barring referrals, and of that cohort, 49.1% said they ‘would unequivocally use the online service if they were aware that it existed’ (emphasis in the original). The remaining percentage said they would use the online service if the current offering had been improved, because they had tried but essentially given up. Thus, the reason for lack of usage was pretty evenly split between lack of profile (DBS responsibility) and quality of the site (TCS responsibility). In circumstances where the requirement upon TCS was to provide a product that ‘supported’ the target take up, and a product which was clearly putting people off would comply with the obligation relied upon given that the useability issues were at least a material contributory factor failure to meet the take up targets. TCS were therefore also in breach of this part of Schedule 3.

581. Perhaps for these reasons, TCS focussed principally on causation. The first point made is that the complaints made by Dr Hunt, and adopted as breaches by DBS, did not align wholly with the issues identified by DBS itself and which, logically, can have been the extent of the matters in mind when DBS decided to re-design the portal. The difference is in part, also, explained (as Dr Hunt accepted) by the fact that useability complaints will always have a degree of subjectivity to them (Day 20/174).

582. The DBS assessments of the Portal were dated April 2019 and October 2020. For the April assessment, 4 participants took part in Testing Sessions to determine if the portal itself contained reasons for the low usage, and 3 key issues were found that had a 4 or 5 severity rating, and further issues with lower severity were found.

583. The first key issue was the requirement to enter an authorisation code to allow end users/applicants to use any services linked to their certificates. This was Dr Hunt’s complaint at item 2. Complaints were being made about this by users as early as December 2017, as set out in DBS’s ‘R1 Basic Portal Complaints - TCS analysis’ presentation. DBS recorded:

A close-up of a white background

Description automatically generated

584. However, it is also clear that the fix was not difficult and, as Dr Hunt said, could and should have been done (Day 20/151):

Q. But that doesn't strike one as being a particularly

difficult thing to fix to make the link more prominent

or make it more self-explanatory, if it needs to be?

A. Yeah, certainly it's something that could and should

have been done.

…

Q. If what we're talking about here is taking a link which

is currently not very clear and maybe making it bigger,

maybe changing what the text says, maybe doing both,

that's not exactly a huge change, is it?

A. That's not. It needs a bit more than that. It needs

to -- what it should have done is detect whether this

particular account was linked to anything or not and

then say, if you're trying to link -- if you've just got

a certificate, this is where you need to click to link

it to this portal account. So it needs a bit more than

just putting the link somewhere.

Q. Well, I mean, you could put it in clear text, couldn't

you, with an "if" in front of it: "If you're trying to

do X ..." --

A. Yes, of course.

585. The second key issue was the users’ ability to find the correct link within the navigation bar for view a certificate, which was one of the two main reasons for applicants accessing the portal. Again, subject to Dr Hunt’s view that every change required a cycle of work and could not necessarily be described as trivial, Dr Hunt agreed that this was not a difficult thing to fix (Day 20/152).

586. The third key issue was twofold, first the ability of the user to find the correct link within the navigation bar to be able to share the certificate, and then confusion about the need to use the dropdown menus to proceed to granting consent, which was not in fact required. In terms of the ease of fixing both issues, again Dr Hunt was clear (Day 20/155):

…The one on

page 12 {F/3321/12} is another one where the answer

is: make the link clearer; do you agree?

A. Can we go back to page 12 again --

Q. We may.

A. -- please?

Yes.

…

Q. Yes, so if you wanted to take a simple approach, put

grant consent at the top -- I appreciate there are

a number of ways of designing things, but to take your

example, take "Grant Consent", put it at the top, then

you could have a rule and have the consent history

below?

A. You could do that, yes.

Q. And that would be a very easy way of solving this

problem?

A. It would certainly make it better.

Q. And it would be a very cheap and quick way of making it

better?

A. Cheap and quick as any software changes.

Q. Yes. But a bit like the links, my point is this is not

sophisticated development needed --

A. No.

Q. -- to move a button from the bottom of the screen to

the top and put a line underneath it?

A. No.

587. Dr Hunt then accepted in terms, and I find, that in respect of each of the key issues, it was perfectly possible to fix them from a technical point of view without too much difficulty.

588. The second DBS analysis took pace in October 2020. In relation to aspects of the ‘user journey’ with which the portal users expressed unhappiness were set out in Slide 36:

A map of a user journey

Description automatically generated

589. It can be seen that users were in fact either satisfied or very happy with most of the portal,but were unhappy with three areas. These were registration, upload/file type restrictions and the third was submit form.

590. As to the first, ‘user registration’ was not a matter criticised by Dr Hunt. Moreover, the need for any registration as part of the overall business solution required of TCS has now been scrapped by DBS. Dr Hunt also did not criticise the upload limits. In her first report Dr Hunt stated merely that it is common for there to be limits on the size of files to be uploaded to a website (the second reason for user unhappiness), and a reasonable approach would have been for TCS to provide a 10MB limit to start with but to consider extending that if it proved problematic. Dr Hunt also stated, and I accept, that making a change to the website to allow a different limit would have been a relatively small change.

591. In relation to ‘Review and Submit Form’ (the third red dot), the first issue (in the ‘Experience’ box) was ‘Timeout issues while submitting’, and this aligned with item 10 of Dr Hunt’s Appendix E, regarded as ‘low’ impact. Dr Hunt accepted that there was a ‘very simple fix’ (Day 20/173). The second issue related to saving referrals, which is not a problem that Dr Hunt had encountered or was included in her list of problems. In cross-examination, Dr Hunt said that she was not entirely sure what the complaint was.

592. Against the background where the actual issues identified by DBS, whether in 2019 and 2020, were in theory capable of easy technical solutions, the issue of a causal link between the breaches established and the decision to ditch the solution altogether and build a new one again arises, as it did for the Basics Portal.

593. There are, in my judgment, a number of clear indicators within DBS’s 2020 presentation. The first is that in considering the potential for a new solution the ‘Principles’ included, ‘Agile’ and ‘Aligned with the GDS Standard’. Neither of these were requirements imposed on TCS, as found in relation to Basics. Similarly, Slide 21 made clear that ‘as dictated by the DBS Technology Roadmap, the Barring Portal is to be hosted on UK Cloud based infrastructure’: again, this a fundamentally different from the product required from TCS. When considering options, option 1 was ‘Do nothing and fix current incidents’, and option 2 was, ‘review existing offering’, which identified that it would need ‘reverse engineering …due to inaccessibility of current code’.

594. Whilst it is correct that DBS considered replacing the Barring Portal sooner than 2020, ultimately it is simply not possible to link the easily resolvable and specific useability issues that were in fact the source of contemporaneous complaint (or, indeed, the further items of complaint identified by Dr Hunt) with the decision a number of years later to replace the Barring referral part of the portal (other parts of it are still in place). The principal justification given, fairly, by DBS in its Written Closing Submissions relates back to the same reasons the Basics Portal was replaced, which it is said apply with equal force. ‘In other words,’ DBS contends, ‘it was a significant task to bring the Portal into compliance with DbD Standards and there was no reason to consider that an incremental approach would be cheaper or more efficient’. The claim in respect of the costs to replace the Barring Portal fails for same reasons that the Basics Portal failed: compliance with DbD Standards was not part of TCS’s scope of work. The only loss caused by the specific breaches established in terms of discrete useability problems would be the cost (if any, to DBS) of rectifying those specific issues, which would have been relatively technically straight forward. In addition, as with Basics, whilst the solution in fact built may have covered the same scope as the Barring Portal, it was fundamentally a different solution, in line with DBS’s own broader strategy.

595. DBS’s Counterclaims in respect of items 9 and 10 in the Updated Schedule of Loss therefore fail.

Barring Portal: Loss of productivity - Item 11 of the Updated Schedule of Loss

596. For the reasons set out in in respect of Updated Schedule of Loss item 3, I have concluded that the quantification of DBS’s loss of productivity claim is flawed and the claimed losses irrecoverable. In the circumstances, item 11 also fails.

597. However, even if the WFPM was a reliable basis for starting to assess a loss of productivity in general terms, there is absolutely no proper attempt by DBS to provide a sound evidential link between the specific useability breaches established in respect of the Barring Portal and loss of productivity caused to DBS staff. DBS merely takes an overall sum as the aggregated effect of all Barring related complaints, and suggest in it Written Closing Submissions that it be reduced it by 50% to account for inefficiencies ‘caused by performance issues and other matters which do not form part of DBS’s claim’. DBS allocate 40% to the portal issues and 60% to other barring claims on the basis of the evidence of Ms Clare Graves, who whilst accepting that ‘I am not in a position to comment directly (from any personal knowledge) about the impact’ states ‘following consultation with my colleagues, I believe it is fair to estimate that about 40% of the 78.75 excess staff are needed because of Barring Portal Problems’.

598. There is no credible evidential basis for the suggested percentage reduction of 50% at all: DBS’s own witness evidence does not engage with the question of assessing the performance issues for which DBS itself was responsible or other matters which do not form part of DBS’s claim. Other than Ms Graves’s belief that it is a ‘fair estimate’ on the basis of her discussion with others, there is no explanation as to how the 40/60 percentage has been arrived at so as to allow even the most superficial interrogation. I also note that whilst Ms Graves said (in February 2023) that ‘when the Barring Portal is replaced (in the coming months), it will be easier for us to form a more certain view about this and look at the impact on the workforce by reference to current statistics and models’, DBS did not in fact seek to update its evidence for trial on the basis of the efficiencies in fact gained by the introduction of their new portal.

599. DBS’s approach cannot be equated with the Court ‘making the best estimate possible’ urged upon the Court by DBS, who relies upon the judgment of Toulson LJ (as he then was) in Parabola Investments Ltd v Browallia Cal Ltd [2010] EWCA Civ 486, [2011] QB 477 per Toulson LJ (as he then was) at [22] - [23]:

‘22. There is a central flaw in the appellants' submissions. Some claims for consequential loss are capable of being established with precision (for example, expenses incurred prior to the date of trial). Other forms of consequential loss are not capable of similarly precise calculation because they involve the attempted measurement of things which would or might have happened (or might not have happened) but for the defendant's wrongful conduct, as distinct from things which have happened. In such a situation the law does not require a claimant to perform the impossible, nor does it apply the balance of probability test to the measurement of the loss.

23. The claimant has first to establish an actionable head of loss. This may in some circumstances consist of the loss of a chance, for example, Chaplin v Hicks [1911] 2 KB 786 and Allied Maples Group Limited v Simmons and Simmons [1995] 1 WLR 1602, but we are not concerned with that situation in the present case, because the judge found that, but for Mr Bomford's fraud, on a balance of probability Tangent would have traded profitably at stage 1, and would have traded more profitably with a larger fund at stage 2. The next task is to quantify the loss. Where that involves a hypothetical exercise, the court does not apply the same balance of probability approach as it would to the proof of past facts. Rather, it estimates the loss by making the best attempt it can to evaluate the chances, great or small (unless those chances amount to no more than remote speculation), taking all significant factors into account. (See Davis v Taylor [1974] AC 207, 212 (Lord Reid) and Gregg v Scott [2005] 2 AC 176, para 17 (Lord Nicholls) and paras 67-69 (Lord Hoffmann)).’

600. DBS is correct that the loss of anticipated savings claim is by definition a hypothetical exercise, and this places the claim in a different category to global delay or disruption claims which are claims which seek to measure the effect of something which in fact happened in the past, and to which a standard balance of probabilities causation test applies. However, the ability for the Court, once an actionable head of loss is established which head involves a hypothetical exercise, to disapply the usual balance of probabilities approach to evaluate chances is not to be equated with asking the Court effectively to guess or make arbitrary and unsubstantiated percentage adjustments to claimed amounts in order to take account of matters which need to be excluded from a globally calculated sum. There must be an evidential basis justifying the figures used and the Court must be astute to considering critically whether the method of assessment advanced really is the ‘best’ estimate available. If there are different and more obviously evidentially rigorous approaches to assessing of loss which the claiming party has not advanced, the Court may simply conclude that it is not in a position to assess the ‘best’ estimate.

601. In the present case, the causal link between the breaches established and lost inefficiencies was, in relation to this part of the DBS’s case, principally the lack of take up of the digital system by applicant. It would have been entirely possible to present an evidence-based quantum analysis that (for example) identified the number of applications which would have been handled digitally, had the take-up target been met, and the number of digital applications in fact made, both based upon the actual numbers of applications made. The delta is the number (on DBS’s case) which would have caused, in each case, additional work for DBS which would not otherwise have been required (the multiplier). Analysis would have been able to establish, on the basis of factual evidence of what actually happened, an approximate difference in the amount of time, and therefore cost, between handling an application on paper versus digitally (the multiplicand). The multiplier applied to the multiplicand would have been a rational and reasonably robust approximation of the hypothetical loss. In circumstances where, as I have found, there were other reasons not due to TCS which caused the take up to be lower than targeted, it may be that the multiplier would be adjusted downwards on the basis of a percentage adjustment to estimate the effect of the difference causes, but this sort of adjustment would be applied to a significantly more evidentially rigorous starting point. It is this type of ‘best estimate’ which Toulson LJ was observing is permissible in assessments of the hypothetical.

602. I do not consider that, even if the WFPM was itself a reliable document, and allowing for the type of approach permitted in the context of a claim which is assessing a hypothetical situation, the Court is able to conclude that the anticipated loss of savings claim advanced by DBS represents the best estimate of the losses which would actually have been caused to it by the established breaches.

LPF Portal

Item 19 of the Updated Schedule of Loss

603. DBS claims £15,213 which it paid TCS in order to change the functionality of the LPF Portal in order to attach documents.

604. The functionality requirement was stated broadly:

(1) At paragraph 2.23.6 of Schedule 2-2 to the Agreement:

‘The Solution shall enable the AUTHORITY to issue a request to obtain local police information from its sources where there are indications that further information exists.’

(2) At Schedule 3 to the Agreement:

‘Local Police Forces interface, which will allow to capture Police intelligence in a standardised way for both Disclosure and Barring purposes through the web portal (see section 1.2.1). Police Forces and the Authority will be able to interact in order to share and discuss information through a dedicated space on the web portal. The routing of information will be governed by Business Rules.’

605. Mr Britton’s evidence was that both parties accepted RFC 591 as a change, and DBS had not picked this issue up in UAT. Dr Hunt agreed that RFC was accepted as a change, and that this was because DBS did not request a change to the text field size but the ability to attach a document, which was an approach that was documented as not required. Dr Hunt considered that there appeared to have been no opportunity for DBS to comment on the screen layout during the design process, and that if the design process had made use of prototypes prior to development as it should have done then the need either for a larger text field or for attachments could have been identified much earlier. Dr Hunt agreed with Mr Britton that DBS could also have raised this during UAT and did not.

606. It is clear from an email exchange in August 2017, that DBS initially wanted an enlargement to the text box, but also indicated that it wanted the text within the box to be formatted so that it could be cut and pasted out of the box by the DBS users. Mr Kaushik of TCS then advised:

‘After looking into the examples and the requirement from Barbara i.e. to show the text formatted on the Portal Notification, I would suggest this to be an attachment solution as compared to enlarging the existing “Requested Information” box. As just enlarging the box might give us more space to write the information, but it will not keep the format when presented back on Portal.’

607. It is clear that the origin of this RFC lay in the fact that the text box had a character limit which proved inadequate to deal with some sorts of information exchange. The basic functionality existed, and no specified requirement (e.g. minimum size or the ability to attach documents) was breached. Whilst it may well be that the involvement of DBS review at the design stage, as promoted by Dr Hunt, may have identified this issue, it may well not have done: in the same way that the issue was not picked up by DBS at UAT, it may not have been picked up at any earlier stage. Moreover, the ability to cut and paste out of the text box appeared (which was not a specified requirement, and the absence of which has not been alleged by DBS to be a design failure) appears to have been the real driver to add the ability to attach documents as a functionality change.

608. DBS did not see this functionality change as consequent upon a design failure by TCS at the time, given that DBS (after what is clear from the RFC tracker was a lengthy commercial verification process) agreed that the new functionality should be paid for pursuant to the RFC process. I form the same view. Moreover, having agreed to pay for the new functionality (which may have had very different cost implications to merely increasing the character limit within the text box) without reservation, DBS do not identify the basis upon which it is entitled to the return of the sums DBS agreed to pay at the time.

609. The Counterclaim at item 19 in the Updated Schedule of Loss in respect of RFC 591 fails.

610. The other RFC claims (514, 640, 673, and 682) were not pursued by DBS in its Closing Submissions (or cross-referenced within its Spigelman Schedule).

Siebel Useability Issues

611. Siebel is an Out of the Box (‘OOTB’) product developed by Oracle which is the basis for the R1 Barring user interface.

612. Appendix G to Dr Hunt’s first report contains a table containing 18 useability issues which DBS relies upon to support its pleaded case that the User Interface is poorly designed and provides little support to the user (paragraph 99.16.3 of the Amended Defence and Counterclaim).

613. The IT experts agreed that improvements could be made to the useability of the R1 Barring user interface, and agreed that the design of the user interface is to some extent constrained by the use of Siebel. As DBS expressly accept, the Agreement required TCS to maximise the use of off-the-shelf products and minimise the amount of bespoke development which designing and implementing the Solution. The IT experts also agreed that systems should be designed with useability in mind but that there are trade-offs and compromises required between useability and other aspects of the system, such as the extent of customisation. This was also emphasised in the evidence of Mr Agarwal, which I accept (Day 6/165):

However, just -- we need to understand that this is a product. Product has its features, right? So, a product, at one hand, there was a very strong emphasis from DBS that we should not customise the project beyond a certain level. So we were trying to keep a balance between the features, out-of-the-box features of the product and the DBS functional requirements that were there.

614. The IT experts also agreed that useability problems are often identified in UAT, but resolving such issues at such a late stage is more difficult and costly than identifying them during design, and the disagreement at the heart of their positions was whether the useability issues identified by Dr Hunt (to the extent their existence was accepted as ‘issues’ at all by Mr Britton) resulted from TCS’s failure to following GIP in its approach to designing the user interface.

615. As to the specific issues themselves:

(1) Item 1: Unusable screens. Sometimes the user would be presented with screens which were not in fact usable. Mr Britton accepted this in principle. Both experts agreed this to be ‘low’ impact.

(2) Items 2 and 3: Not relied upon by DBS, given that the IT experts agreed that this was standard functionality that they would not expect to be customised.

(3) Item.4: Inconsistent back navigation. The back button was necessary to step back on step for some tasks, but for other tasks would return an error message. Mr Britton accepted this in principle. Both experts agreed this to be ‘low’ impact.

(4) Item 5: No personalisation: Users are not able to personalise the way in which information is presented to them so that, for example, they could always see the newest Barring Cases first. Instead, a re-sort would need to be performed each time. Mr Britton agreed, but, in his opinion, Siebel does not offer that kind of functionality. I accept, however, Dr Hunt’s evidence that this functionality was standard, but was not available because of TCS’s customisation of the setting icon. Mr Britton considered that it could potentially be improved but was not “necessarily” an issue but would depend upon whether it was a problem for users in real life. Dr Hunt regarded this as a ‘medium’ impact on the basis that it required additional steps to be taken. DBS submitted there was no real dispute that this could amount to a useability issue: Mr Britton’s reticence relates only to whether it did. DBS is correct that this would depend upon the evidence of the users. The only evidence about whether this was a ‘real’ issue is the inclusion within a spreadsheet of Barring suggested updates of (atline 18) ‘Home Screen sorting’, asking whether ‘My cases/My Activities/Service Requests be sorted by New at the top’. This was ‘Low’ priority. If an issue at all, it is likely, in my view, that this was ‘low’ impact.

(5) Item 6: Too many irrelevant data fields displayed. Dr Hunt considered that, on the “Case Screen”, the user is presented with a large number of irrelevant fields which clutter the screen and force the user to scroll down to see what activity has occurred or is required. Mr Britton considered the issue unclear as he doesn’t know whether there are irrelevant fields or not. DBS submit that barring users are concerned with whether an individual should be considered for barring / entered on to the barred lists, and that the Court can safely conclude that this does not involve the following fields which relate to basic or enhanced checks: update service; purpose of check; references to “applicant”; application type. Dr Hunt’s opinion was, however, essentially based on informal feedback during demonstrations of the system. There is no witness evidence addressing this particular issue, and whilst the inclusion of an option which is irrelevant to a particular user, it is difficult to see how the impact is anything other than, if anything, low.

(6) Item 7. Address field truncated: On the case list screen, the applicant’s address field is truncated to 8 characters and can only be viewed in full using a pop-up. That this is so is not in dispute. Mr Britton made the point that he thought this was OOTB functionality, and that whilst it might be ‘marginally, maybe’ better to see the whole field, it was unclear whether a user was ever likely to need to see the whole address in order to process an application. Mr Britton accepted that whether customisation was appropriate depended upon ‘to what extent this is a real issue’ (Day 19/5). There is no factual evidence that this particular issue was a ‘real issue’ to anyone in particular within DBS: it is not a complaint specifically documented by DBS as a problem at any time. Dr Hunt agreed with Mr Britton that it was ‘low’ impact.

(7) Item 8. Too many irrelevant data fields displayed: This issue is similar to Item 6 but relates to the ;Barring Case Screen;. That screen has multiple irrelevant fields which TCS was specifically informed were for test purposes only including MinScoreAdult, MinScoreAdultID, MinScoreChild, and MinScoreChildID. Mr Britton confirmed in cross-examination that in his opinion this would be an error (Day19/8). Dr Hunt categorises this as ‘medium’ impact, Although no DBS factual witness gives evidence specific to this issue, the Barring suggested updates spreadsheet identifies at row 50 ‘There are too many tabs, many of which never need to be access by teams’. The impact is said to be ‘Accessing required info is difficult and time consuming. System impact of accessing incorrect tabs’. I accept that this would be ‘medium’ impact.

(8) Item 9: Once a barring user scrolls down to view the referral form it is not possible to see details such as the person’s name. That this is so was not in dispute. Mr Britton’s view is that it is unclear if or why it is necessary when completing the information entry it is necessary to continue to see the name at all times. It is not obvious why this should be the case and there is no evidence from any DBS witness explaining why this is a problem. To the extent it is an issue, Dr Hunt regards the impact as low, and I agree.

(9) Item 10. No delete on list data entry. A row can be added quickly by clicking on the “+” icon, but can only be deleted through a keyboard shortcut or the settings icon. Dr Britton accepted a delete button would probably be an improvement but described the impact as ‘negligible’; Dr Hunt accepted that it was ‘low’.

(10) Item11: List data entry fields too small. Both experts agree this was high impact and a significant problem for users. In contrast to other issues, this is one that a DBS witness specifically addressed. Ms Martin, whose evidence was not challenged and which I accept, said:

“18. In the R1 Barring system we input information into text boxes in the system. There are text boxes for, by way of example, background information and PNC summaries. Often those text boxes are not big enough to contain all of the information which we need to input. For example, the background information section has three separate text boxes for background information in case one is insufficient.

19. In addition the text boxes are very small perhaps an inch and a half in height and so, even in cases where the boxes are large enough to contain the information you need to input, after inputting more than a few lines of text the preceding text is no longer visible within the box and it is necessary to scroll within the box to check what you have previously drafted. This is particularly an issue within the evidence evaluation tab. The evidence evaluation text boxes are even smaller than those in the background information tab, because the screen appears in a table form and so the boxes are much narrower in length.

20. In carrying out an assessment it is often necessary to move between tabs to review information to draft our summaries. We might need to go back and amend what we have inputted within text boxes as a result of further reviews and in that case we have to scroll within the box to check and amend what we have previously drafted.

21. As a result I draft information for data input in a separate Microsoft Word document and then cut and paste that over to the text box. It is simply not possible to efficiently and accurately use the text boxes solely due to the amount of information I need to input and the manner in which it is presented within the system. So far as I am aware, all other Caseworkers also use the same workaround. This workaround would have been unnecessary if, for example, the text boxes had a button which “popped” the box into a bigger screen for data input or review.”

This workaround is recorded on Row 13 of the ‘Workaround’ worksheet under the DMU tab, referred to further below. Both experts accepted this was ‘high’ impact.

(11) Item 12: List management not appropriate for checklist. The barring information gathering checklists contain reminders, for example to gather relevant previous work history, or disciplinary correspondence. The IG Checklist shows two lists, one with 4 and one with 7 items, although there are in fact 14 items on the second list and there is no indication of this unless the user clicks at the bottom of the screen at which point items 8-14 appear. Dr Britton says, and Dr Hunt did not disagree, that this is part of the OOTB functionality. Dr Hunt considers that this confusion means that it does not provide the checklist functionality, and that the impact is ‘medium’. I accept, however, the evidence of Mr Britton that, given that the users will have quickly learned how many items are on the checklist from their repeated use of the screens, the impact is low. In this regard, I note that there is no evidence from any DBS witness that this issue has, in fact, caused any issues at any time. In the Barring suggested update document referred to above, the only comment relating to ‘IG Checklist’ (row 21) stated, ‘Excess information in this screen. Not very user friendly. Could it be expanded into one long list? Could it be prepopulated with N/A as this is the majority of responses made’. The impact stated ‘*Lots of clicking’ ‘*Takes a long time to complete’. The thrust of the complaint (a) does not relate to not showing all 14 items in the second list, rather that the content of the list contained things that required checking which were in fact ‘N/A’. There is no suggestion, however, that including the content (presumably provided by DBS and/or existing DBS process) was a breach.

(12) Item 13: Poorly designed popup forms. Both experts agree that the one of the two issues relating to forms, where there are irrelevant entries on drop-down boxes, is of medium impact (because users encounter the issue in more than one drop-down box) and the other is low. No DBS factual witness gives evidence specific to this issue, or whether or how the inclusion of unnecessary/irrelevant choices within the drop down box adds to the time it takes to carry out their work.

(13) Item 14: Invalid drop down values. Both experts agree this issue was a defect of ‘medium’ impact individually, but again there is no evidence of whether or how this has caused any problems in reality.

(14) Item 15: Drop down values change. The experts could not replicate this, but Mr Britton describes it as a common issue. They agree the impact as low.

(15) Items 16 and 17: Not relied upon by DBS.

(16) Item 18: Error messages are not helpful in that they do not explain the error, which does not assist the user to remedy the problem. The experts agree that this is a ‘low impact’ issue.

616. The main useability issue giving rise to any specific impact and explained within the factual evidence relied upon by DBS is the size of the text boxes. I accept that, to the extent that TCS was unsure of the size necessary to meet DBS’s needs, they should at the design stage have sought sufficient information to get this functionality right. The failure to have done so was, consistent with the opinion of Dr Hunt in this regard, a failure on the part of TCS to design the solution in accordance with GIP, in my view. The creation of a workaround to meet this issue would undoubtedly have made the process less efficient.

617. I also accept that a system should not, in accordance with GIP, be designed so as to include irrelevant fields, tabs or entries within drop-down boxes which were unnecessary. Again, the fact that these remained at Go-Live results from a failure on the part of TCS to have designed the system properly. However, in the absence of witness evidence or contemporaneous documents explaining how or why the inclusion of an irrelevant field or tab has in fact materially influenced the efficiency of the process, I conclude that the impact of such issues taken together was, at most, low.

618. Whilst in general terms it is right that DBS was ‘heavily’ involved in various ways in the design, review and feedback during the design process, as accepted by Mr Sheahan of DBS (Day13/120), there is no evidence to link the particular complaints made by Dr Hunt back to a particular demand made by DBS. I also accept that whilst some of these issues might have been picked up at UAT, the purpose of UAT was more directed to functionality. The failure of DBS to have identified a particular issue does not mean - if objectively it is a defect - that TCS is not responsible for it.

619. DBS has, to the limited extent identified above, therefore made out its case that there were some Siebel useability issues which constituted a breach of the Agreement. Save for the size of text box issue, however, I am not persuaded on the evidence that the issues have had more than a ‘low’ impact upon efficiency.

Snowbound

620. Snowbound is the third party tool for handling, displaying and manipulating documents, including the application of redactions, which TCS incorporated into its Solution.

Redaction

621. TCS had a number of contractual obligations relating to redaction:

‘Schedule 2-2, 2.21.8.18

The Solution shall enable the AUTHORITY to redact Case information on the DBS Technical Infrastructure that must not be disclosed in accordance with Business Rules

[ … ]

Schedule 3, 1.2.4.2(a)(viii) Bundle Creation

[ … ] the Solution allows for the production of Case Bundles (e.g. at the ‘minded-to-bar’ stage). The bundle module provides two main functions: firstly to organise the information so that it can be distributed as a bundle, and secondly to support the redaction of information as a part of the bundle creation process

[…]

Schedule 3, 1.2.4.2(a)(ix)

For the redaction support process, rules will be established to allow for certain data fields to be removed or obfuscation rather than used in their actual data form. Also some documents in a Case will need to be duplicated and then some information redacted so that the redacted version is the version brought forward for the purposes of generating a bundle.’

622. It is common ground that the Snowbound redaction pen did not work properly: TCS put positively to Dr Hunt that “the redaction pen wasn’t working properly” (Day19/178). As explained by Dr Hunt, this issue appears to have occurred because of a defect in Snowbound which meant that if certain characters, such as ‘£’, appeared in a document the document would not be properly saved after redaction. After various problems had emerged during SIT and UAT, which had seemingly been solved, they re-emerged after Go-Live. In July 2018, TCS indicated that the pen should no longer be used. Mr Kumar of TCS informed DBS:

;Redaction pen was disabled in 4.7 earlier for around 2 months when there was a similar issue in this option. Later before the upgrade, we got a fix for that issue from Snowbound and it was enabled in 4.7 for end user. Now after we get fix from Snowbound we will enable this option inn 4.10 as well, meanwhile case workers can use "filled rectangle" option to redact in place of redaction pen.;

623. This refers to TCS’s solution, which was to use a filled rectangle to cover text that needed to be redacted. Dr Hunt noted in her First Report, ‘Mr Britton and I observed that it is not possible to set the default colour to black so way and then rotated, for example because it is a landscape oriented page, the rectangle does not rotate leaving the redacted text exposed.’ Further, I accept Mr Sheahan’s evidence that a user could copy and paste the obscured text into a different programme which would expose it.

624. During cross-examination of Dr Hunt, TCS implied that the Snowbound manual made clear that ‘Redaction annotations are only considered redactions when they are burned in and saved as an image format file such as TIFF format’. In its Written Closing Submissions, TCS advanced the case the workaround which required the user to annotate a document with a blacked out rectangle and then ‘burn in’ the annotation by saving the document as a TIFF meant that TCS complied with its contractual obligation to product redaction functionality. I do not agree. I accept DBS’s submission, instead, that it is unreal to suggest that a method of redaction which would require each user to change the colour of default rectangle, place a rectangle over each intended redaction, save each document as a tiff image, and then convert each tiff image back to a pdf document could be a method of ‘redaction’ as envisaged by paragraph 2.21.8.18 to Schedule 2-2. The failure of the redaction pen and clunky workaround therefore amounted to breaches of the Agreement by TCS. Contrary to Clause 2.21.8.18 to Schedule 2-2, the Solution did not enable DBS to redact information, and contrary to Clauses1.2.4.2(a)(viii) and 1.2.4.2(a)(ix) to Schedule 3, DBS was not able to create bundles using redacted documents. As a matter of contractual analysis, it is irrelevant whether the root problem lay with Snowbound or the way it interacted with the rest of the system or whether TCS took reasonable care to test Snowbound properly when proposing it.

625. I also accept as obvious that the inability to use the as-intended redaction functionality made the process of redacting and bundling less efficient, to some extent, than it would have been had the redaction pen worked properly.

Document naming, bundle creation and performance

626. There is no dispute between the IT experts that documents were named with lengthy alphanumeric reference numbers when loaded automatically from SPS. I find, as Mr Britton accepted in his second report that ‘it would have been a great improvement in the User Interface to have provided meaningful names’: The other naming issue, not raised in cross-examination or disputed by Mr Britton, was, as Dr Hunt identified in her first report, that even if the user changed the document names manually, this name would not be displayed when trying to select documents to insert into a bundle. Instead, only the internal content identifier was visible.

627. I accept Dr Hunt’s conclusion, unchallenged in cross-examination, that TCS’s ‘design of the integration between Siebel, document generation and bundling appears to have taken no account of how users would work with the system’, and that as such it would not have been carried out in accordance with GIP. I also accept Dr Hunt’s evidence that TCS’s design of the integration between Snowbound and Siebel made the bundling functionality ‘effectively unusable’. Mr Britton’s evidence was not materially different. He accepted in cross-examination (Day19/30):

Q. all the things that Snowbound was introduced to do in terms of the things we looked at earlier, saving documents, editing documents, redacting documents, creating bundles, well, then, the R1 solution, as delivered, effectively didn't give you usable functionality of that kind?

A. As delivered, yes. But of course they did make performance improvements.

628. Part of the DBS process related to the creation of a minded to bar (‘MTB’) bundle. This included identifying the correct documents, redacting them, creating an appendix of the documents, and drafting an accompanying letter. As such, it was a task impacted by the Snowbound issues discussed above and I accept that, as a result of the issues they encountered with snowbound, DBS implemented a workaround to create bundles in excess of 200 pages manually.

629. As to wider performance issues generally, DBS plead that ‘the system is slow, in that every action a user attempts to perform on the system suffers from a time lag of several seconds’ (paragraph 99.3 of the Amended Defence and Counterclaim). DBS also made complaints about reliability and log in times (paragraphs 99.2.1 and 99.2.2 of the Amended Defence and Counterclaim).

630. There was a performance test in the SIT-L environment, which was explored in cross-examination. The Non Functional Requirement for retrieval of a .pdf document from the database was to test a 10-page document, and the test was passed in relation to load times for retrieval of documents. I accept Dr Hunt’s opinion that the testing ought, in compliance with GIP, to have included a test under the load likely to be expected in use, and that, having reviewed the Test Completion report for Performance Testing that it did not. Moreover, other response times applicable to caseworkers’ use of the Snowbound tool were exceeded. The Agreement specified Application Response Times of 99% within 2 seconds and 1% within 3 seconds for a user executing any transaction within the application: Schedule 2-2. I accept TCS’s submission that the results show each response time was in excess of this requirement, and that similar response times were encountered even after Snowbound had been upgraded by TCS to version 4.13.

631. However, Dr Hunt, in her Appendix K, analysed the Post Go-Live Defects in relation to the reliability, login failures and time lag pleaded at paragraph 99.2 of the Amended Particulars of Claim, and in relation to each one concluded that responsibility was ‘primarily’ HPE, because of bandwidth limits imposed. Dr Hunt also concluded that these issues should have been rectified by BCR1642 but implementation of this was delayed by issues which were the responsibility of HPE and DBS. Dr Hunt’s conclusion on performance in cross-examination was as follows (Day 19/176):

Q. Now, a large part -- after the initial HPE fixes,

a large part of fixing the Snowbound issues, including

the performance issues I'm talking about here

specifically, was upgrading the Snowbound software,

wasn't it?

A. It was certainly a significant part, yes.

Q. And that suggests, doesn't it, that at least those --

that significant part of the problem wasn't in fact

caused by the TCS built DMS system and its inability to

cope with load, it was a Snowbound software issue?

A. Well, we don't really know, I think is the -- is

the real answer to that question. Snowbound was

something that could be upgraded, so it was, and it gets

better when they improve Snowbound. So the general

feeling is that that was probably the culprit, but I'm

not sure that anybody has investigated DMS performance

in any real sense.

Q. But in a sense, absent any other intervention, if you

make intervention A, upgrading the Snowbound software,

and the result is everything goes faster, then it's --

A. Yeah.

Q. -- a fair --

A. A fair cop.

Q. -- deduction, isn't it --

A. Yes --

Q. -- that that was the issue, or at least that was a major

issue?

A. Yes.

Q. And that means that -- if that is right, it means that

it's not anything that TCS did wrong with its

design-and-build of DMS, the contention is in

the client, the Snowbound client?

A. Most likely, yes.

Q. And certainly you haven't identified, I think, correct

me if I'm wrong, but in either of your reports anything

that TCS could and should have done to improve

performance but they didn't do?

A. Apart from the upgrading Snowbound, which --

Q. Yes.

A. Yeah.

Q. Yes, apart from upgrading Snowbound?

A. Yes.

632. Snowbound updates were carried out in July 2018 from v4.7.2 to v4.10: the v4.8 and v4.9 updates had stability problems and were not implemented) and to v4.13 in June 2019. In the circumstances, it is not possible to conclude that there existed general performance related issues which were the responsibility of TCS, other than those associated with Snowbound integration, even though it is likely that the problems encountered post-Go Live would probably have been identified sooner if the testing had taken place at appropriate load. The system performance problems themselves were, as Dr Hunt concluded and I accept, primarily the responsibility of HPE and bandwidth related issues.

633. I accept that the Snowbound issues which have been established were a material contribution to the decision by DBS to implement a workaround to create MTB bundles in excess of 200 pages. DBS submits that it continued to experience issues with creating MTB bundles, even after the bandwidth issue had been resolved. That this was so was supported by Dr Hunt’s analysis (see first report paragraph 495). Contemporaneous support is also found in some of the documents: see for example the email exchange dated 19 February 2018, in which it was recorded that, ‘we have not found that lift of the cap on bandwidth by one of our suppliers, has seen a decent improvement on the DMT specifically. It didn’t demonstrate any improvement in the speed of Siebel generally however…’ Having sought feedback from caseworkers dealing with MTB bundles in excess of 50 pages, one caseworker stated: ‘I don’t have a case with over 50 pages but I have done a bundle this morning with 42 pages and it was horrendously slow. I could have gone to make a cup of tea each time I tried to move down a page.’

634. In terms of specific cost claims arising out of Snowbound (as opposed to DBS’s loss of anticipated efficiency claim, of which the Snowbound complaints play a part), DBS claims Snowbound Tool remediation costs in the sum of £293,069 (item 21 of the Updated Schedule of Loss), and Adobe licence costs, in the sum of £8,270 (item 20 of the Updated Schedule of Loss).

Adobe Licence (Item 20)

635. I have found above that the failure of redaction functionality constituted a breach of contract. I accept that the provision of a third party product which fails is not, of itself, a failure to have adopted GIP. Nevertheless, DBS adopted a reasonable solution in introducing a solution from Adobe and purchasing the necessary licences. I accept the factual evidence of Ms Graves (at paragraph 34(d) of her Third Witness Statement. Mrs Wall’s main challenge from a quantum perspective on the basis of certain names appearing more than one fell away once it was explained that some individuals were requesting more than one licence for their team members.

636. The Counterclaim at item 20 of the Updated Schedule of Loss in the sum of £8,270 succeeds.

Document Storage (Item 21)

637. TCS’s claim for Snowbound remediation costs relates to TCS adopting a document storage configuration using a file system and not in a database. The Updated Schedule of Loss states, ‘The Defendant is upgrading the Unified Content Manager and datacore components as part of a project to address the poor performance and unreliability of Snowbound on the users of R1 Barring.’ Other than reference back in general terms to ‘poor performance and unreliability’, there is no specific pleaded allegation: taking a broad view of the pleading, the allegation rests on the general case about the failure to have designed the solution in accordance with GIP, resulting in poor performance and unreliability.

638. There is no independent evidence supporting the claim. Dr Hunt accepts that she has not assessed the configuration independently, and whilst she gave evidence that the CGI proposal (the supplier recommending the proposed change) was ‘a sensible proposal’, Dr Hunt’s evidence falls short of asserting that the configuration adopted by TCS was not in accordance with Good Industry Practice. Moreover, as set out in the passage above, Dr Hunt agreed that there was nothing, in respect of performance and reliability which was ‘primarily’ the fault of HPE, which TCS should have done to improve performance other than upgrade Snowbound.

639. Furthermore, Mr Konda of TCS explained that it was not possible to use a database storage model given the lack of shared storage in the DXC solution. There is no dispute that TCS agreed to supply the Datacore solution in 2015 pursuant to RFC 423 because of the limitations in HPE’s provision of shared storage. DBS relies upon the fact that under “key features” of RFC 423, TCS was to describe how it had assured itself that “the SCC can deliver the R1 non-functional requirements, in particular the performance levels”. This ignores the fact, however, that the RFC also identifies that a number of alternative options were considered, and then stated:

‘However all options have similar issues related to delivery timeframe, cost and technical risk. The option described in the RFC (2, above) is considered the best compromise of deliverability, cost and technical risk. The only option without technical risk is (3), but that would be very expensive and likely to have a major impact upon the dates.’

640. Option 3 was stated to be replacing virtual servers, many of which were already built, with 62 servers as these could have shared storage presented to them. Thus, the RFC was clear on its face that the solution being adopted was not as technically optimal as shared storage. There is no evidence that, presented with requirement for a technical solution at the particular time it was required in the project, the recommendation for the solution was wrong or represented a failure of Good Industry Practice (and no such case is pleaded).

641. I accept, therefore, the evidence of Mr Britton that the upgrades to the UCM or datacore components do not imply any failure on behalf of TCS.

642. The Counterclaim at item 21 of the Updated Schedule of Loss for £293,069 fails.

Other B1 Barring Quality Issues

643. As confirmed in the Spigelman Schedule submitted by DBS, no loss was pursued in relation to its pleaded claims in respect of:

(1) data mapping in the Disclosure Information Workstream;

(2) migration of PNC Alias material;

(3) Autobar catch up (RFC 514);

(4) multiple contact records;

(5) GDPR.

644. The other complaints maintained do not give rise to separate losses, but form part of the loss grouped within row 12 of the Spigelman schedule. Setting aside items 20 and 21 dealt with above, this leaves the general lost efficiency claims pleaded at item 24 of the Updated Schedule of Loss.

645. Notwithstanding my conclusion that, along with item 3 and 11, the basis of the lost efficiency case is flawed (and see further below), I deal with those complaints DBS maintain in their Written Closing Submissions/Spigelman Schedule.

Scan on Demand

646. TCS was required to provide facilities (via SPS) for archived paper files to be automatically retrieved when needed and scanned into the R1 system to become an electronic record. See:

(1) Clause 2.25.6.3 of Schedule 2-2:

‘the Solution shall enable the AUTHORITY to identify and request a Case file that is archived off-site’,

(2) Clause 2.25.6.7 of Schedule 2-2:

‘the Solution shall enable the AUTHORITY to record the returning of case files where appropriate to an off-site location following the conclusion of case’.

(3) Section 1.1.2 of Schedule 3:

‘The Contractor will also provide a scanning facility to digitise any historic document that is required as part of an operational business process’;

(4) Section 8.3.7(e)(ii) of Schedule 3:

‘The Contractor will scan paper files on a ‘as and when needed’ basis as new documentation for a Case enters the system workflow via the scanning process…’

647. TCS was therefore required to provide facilities for SPS to scan documents. As the IT experts agreed, this on demand service was to use Siebel as the conduit for requests. The IT experts agreed that the solution contained defects and that DBS and SPS were unable to use Siebel for this purpose. The issues were described by Dr Hunt:

(1) The case number on the manifest did not match the one on the physical file which meant SPS could not identify the correct file;

(2) Certain boxes were not migrated to the R1 system;

(3) If paper files were spread across more than one box, Siebel could not recognise them.

648. TCS admits that the delivered solution was contractually deficient. In light of this admission, consideration of whether the failure also amounted to a failure in GIP is not necessary.

649. DBS submits on the basis of the factual evidence of Mr Sheahan that, as a result of these issues, DBS had to continue using a manual process of requesting archived material which meant that anticipated efficiency savings were not made until DBS bulk scanned old files. However, on the basis of the contractual requirement, and the contents of RFC 307, this appears to overstate the position. Undoubtedly, the inability to use Siebel properly in order to request files etc made the system less efficient than it should have been. However, RFC 307 made clear that the ‘bulk scan’ of old files was being contemplated as advantageous to DBS to obviate the inefficiencies in the solution contracted for (even if the requesting process had been operating properly through Siebel). The RFC stated:

‘Under the current process, whenever a case with a paper file is reopened, TCS will request the box containing the file be sent from TNT to SPS. SPS will open the box, remove the file in question and scan it. SPS will then reseal the box and return it to TNT. This is the process based on Schedule 3, Section 1.1.2 which reads “The Contractor will also provide a scanning facility to digitise any historic document that is required as part of an operational business process’.

650. The ‘impact’ section of the RFC then identified the inefficiencies inherent in the contractual solution itself, rather than as a result of the fact that the requesting process was not automated as it should have been:

‘The process currently referenced in Schedule 3 for ah-hoc scanning of paper files would commence from R1 go live. There is no discernible end date to this process. The impact of this is that there will be ongoing delivery and return of boxes between TNT and SPS. Boxes may be opened on numerous occasions and it will be necessary to keep a record of which files have been removed and which remain.

The DBS will also not achieve its goal of a fully digitised solution. This will impact on the DBS’s ability to answer any questions and requests for information that come out of the Independent Enquiry into Child Sexual Abuse (IICSA). It will also slow down our ability to work on reactivated cases and new referrals for existing profiles. The affects our efficiency in dealing with appeal, reviews and referrals. It also affects our efficiency in dealing with Appeals, Reviews, SARs, FOIs and Parliamentary Questions.’

651. I reject the suggestion that the bulk scanning of historical files was caused by the defects within the scan on demand service. The bulk scan was agreed (and ultimately taken forward with SPS) to meet DBS’s understanding of the inefficiencies caused by the contracted for process, rather than the specific defects in respect of which TCS was in breach. Because of the way the claim has been presented, it is not clear what part of the ‘loss of anticipated savings’ claim also wrongly elides these issues, although in light of Mr Sheahan’s evidence the implication is that the claim will have done so. No specific loss is identified or claimed (e.g. the cost of bulk scanning), and it merely forms part of the overall loss of efficiency claim.

Special Characters

652. DBS plead that ‘The system suffered from problems with special characters, in that a field containing specific characters would cause the system to crash. This included the names of individuals containing apostrophes or hyphens. Around 10,000 records could not be migrated into the R1 Barring system because they contained special characters’ (paragraph 83.4 of the Amended Defence and Counterclaim). TCS’s Reply admitted that there was a problem with migrating around 8,500 documents with special characters (including apostrophes and hyphens) in their file names, but averred that the issue was relatively easy to resolve - special characters in the file name needed to be replaced before the file was uploaded. TCS denied that this caused the system to crash or that the documents could not be migrated at all.

653. The following list of ‘special character’ related defects is taken from the report of Dr Hunt:

A screenshot of a computer error

Description automatically generated

654. Dr Hunt’s view was that it is normal practice to test systems of this type with a variety of names that are expected to be encountered and that hyphenated first names and surnames are very common, as are names including apostrophes and other characters. Moreover, she concluded that the prevalence of these issues suggests that TCS’s testing did not, contrary to GIP, take into account the variation in input data that would be expected.

655. Mr Britton accepted that the email validation issue (ref PRB0042198) was a defect in the system and evidence of a minor failure to meet GIP. He also accepted the LPF Portal issue (PRB0043875) was a minor failure to meet GIP. He accepted that INC0416930 was a defect, but not one which would generally be picked up in testing and therefore not a breach of GIP.

656. To the extent there is a difference, I prefer the evidence of Dr Hunt that the prevalence of these issues indicate a failure to have tested properly in accordance with GIP, even if the existence of defects in the design itself is not a failure to comply with GIP.

657. I accept the generality of the point put to Mr Britton, in cross-examination, and with which Mr Britton agreed (up to the point that the issues were fixed), defects such as this will make the system less effective as an automated service, and to that extent, would involve some loss of efficiency.

658. As noted above, no claim in relation to the data migration consequences of the defects is pursued by DBS.

Letters

659. The RFC and CGI letter-related claims are no longer pursued. The only relevant claim relates to the provision of header/footer information on a single HTML letter. Letters sent to Police Forces needed to have “Official Sensitive” in the header and footer of each page. DBS rely upon the requirement that TCS was (by Clause 2.17.1.16 of Schedule 2-2) to ensure the Solution would ‘enable the AUTHORITY to create letters using standard letter templates and/or electronic documents’.

660. The document provided for the original upload to Siebel did show the header and footer security marking on each page, and when the system generated letters in PDF form, the headers and footers were shown. However, in relation to letters rendered using HTML (which does not paginate) the header and footer would only be displayed at the very top and bottom of the letter if it were to be printed out at the ‘client’ (i.e. police) side.

661. Both IT Experts agree that if a header and footer was required on each page, then this was a defect providing that there was a requirement with which this did not comply: (Dr Hunt at Day 20/16, Mr Britton at Day 19/42). Dr Hunt agreed that she did not consider the existence of this issue was caused by any failure to have complied with GIP.

662. In my judgment, if the system permitted the generation of the police information letter in HTML, it was also necessary that the relevant coding was included to comply with the appropriate template. It was, presumably, not necessary for the functionality for the system to generate this particular letter in HTML: the letter generation could, presumably, remain limited to PDFs for printing or downloading, which would have avoided the problem. I therefore find that the fact that HTML letters were generated was strictly a defect, even if not one caused by a failure to comply with GIP.

663. I accept that this issue would have caused some loss of efficiency. The contemporaneous evidence suggested in August 2019 (at which point a new workaround letter template had been produced) that about 100-110 of these letters per week were being produced - see the exchange between Mr Sheahan and Mr Blanchard of 2 August 2019.

664. The second issue concerns letter address fields. Automatically generated letters intended to be sent out under the autobar process would sometimes pull through inappropriate data because, in some cases, the PNC had included information in the address field such as “sex offender”. DBS suggests that dealing with low quality input data, including from the PNC, was an expected aspect of TCS’s obligations, relying in Closing Submission upon :

(1) section 1.2.2.1 (b) of Schedule 3 which highlights, in the context of identity matching, that “the Solution is designed to provide effective matching capabilities in a low quality data environment”;

(2) section 2.25.8.80 of Schedule 2-2 to ensure the Solution could cope with partial address: “the Solution shall provide an address search tool to be used by the AUTHORITY to identify full addresses from part address details”.

665. It is plain that these clauses do not impose on TCS an obligation to have anticipated that users of the PNC would have used the address field to include wholly inappropriate information like ‘sex offender’. As Dr Hunt wryly observed, ‘my impression is that it’s not that the PNC is routinely using it for that, it’s just that occasionally those words happen to get put in, presumably by a policeman who feels like it would be quite a sneaky thing to pop it into the address field’.. (Day 20/22). The unreliability of PNC data in this particular way was plainly not a TCS responsibility, as Dr Hunt accepted (Day 20/17). I accept her evidence, as set out in row 10 of Appendix 12 (‘Workarounds’) that this was ‘not a defect’, and I reject the submissions, insofar as it is pursued, that the failure to have foreseen this issue and dealt with it was a failure of GIP.

666. DBS also rely upon the fact that on 4 November 2015 DBS had highlighted to TCS that:

‘in some cases, the address data in the Autobar extract contains non-address data, for example it could contain phrases or abbreviations like “Register Sex Offender” or “RSO”. Clearly, we cannot accept this data being accepted as port of the address held on Siebel and the system absolutely cannot issue out an automatic notification with any such entry … can you explore the possibility of the system “sense checking” address details.’

667. TCS accepted this was technically feasible, but, as Mr Agarwal indicated in his email to Mr Prabhakaran 2 days later, it was complex to implement and would need to be developed from scratch. Mr Prabhakaran told Mr Agarwal ‘we do not want to accept this requirement’.

668. However, I reject DBS’s submission that TCS chose ‘to ignore it’ and deliver a Solution in which this problem eventuated as a complete mischaracterisation of the facts. Instead, an RFC was raised - entirely appropriately. The ‘History’ section of the RFC tracker shows that this was under various stages of consideration through 2016 and 2017 until it was withdrawn by DBS. I note that on 6 September 2016, for example, the history states, ‘Barring confirmed content to wait for this RfC until post R1 release strategy is confirmed. In addition, no changes to requirements are needed at this time’.

669. It was for DBS to weigh up the cost implications of paying for a complex technical solution by way of an RFC against the implications of a manual workaround, e.g. by physically checking addresses before letters go out. It has plainly chosen to go with the manual workaround as more cost effective, as this is the solution still in place many years later (see exchange with Dr Hunt on Day 20/22-3).

670. It is this problem which DBS contend, in its Written Closing Submissions, meant that the automation promised for the Autobar team was not delivered, and that DBS suffered a loss efficiency caused in that it was necessary to switch off the automatic dispatch of Autobar letters from the point of Go-live. This is not, however, the responsibility of TCS. [Row 17 of the Spegilman Schedule confirms the remaining Autobar case as limited to the ‘Letter Address Field’ issue].

Item 24 : Loss of Efficiency Claims arising out of R1 Barring Quality/Useability Issues

671. I have found, in relation to equivalent items from the Updated Schedule of Loss items 3 and 11, that the presentation of DBS’s loss of anticipated savings claim is flawed and cannot be relied upon as a ‘best estimate’ of the losses sustained by those breaches which led to efficiency savings not having been realised.

672. This remains the case in respect of the aggregated claim presented under Updated Schedule of Loss. The WFPM is not a reliable basis for a claim. Moreover, having accepted that there are performance and other issues which would be wrapped up in DBS’s starting point calculation, there remains no evidential basis upon which the Court could rationally and reliably identify an appropriate adjustment to the claim to reflect this. Whilst a court will seek to arrive at the ‘best estimate’ it can when dealing with a head of loss which necessarily includes hypotheticals, for the reasons I have identified, this is not to be equated with guessing. Some rational and evidence based estimate could have been presented in order to gauge what part of the overall loss of efficiency identified could fairly be attributed to the different breaches identified, and which to the matters which even on DBS’s case do not give rise to a claim. This problem is obviously exacerbated where, as here, some breaches claimed against TCS which are said to have given rise to claimed inefficiencies have not succeeded.

673. Perhaps in partial recognition of the difficulties DBS’s aggregated claim faced, DBS presented in its Written Closing Submissions, for the first time, a calculation of loss which it said could be attributed to workarounds caused by specific breaches. DBS contends that of the aggregate claim pleaded and supported by Mr Hain on the basis of the cost of FTEs, it is possible to attribute some identifiable part to the staff time lost in operating ‘workarounds’. It calculates this sum as £498,092.17.

674. In its oral Closing submissions, Mr Lavy submitted that it was far too late for DBS to try and calculate a loss on this basis, pointing out that DBS had never previously sought to rely on its workaround spreadsheet as a basis for quantifying loss. Mr Lavy pointed out that workarounds were specifically addressed on the pleadings, and DBS effectively disavowed the need to provide the particularity sought.

675. At paragraph 115.12 and the Amended Schedule of Loss item 24 (the item with which I am presently concerned), TCS pleaded in its Reply:

‘The Defendant must plead and prove how specifically alleged breaches caused each of the said workarounds, and the cost and effort associated with each breach.

In circumstances where the Defendant maintains that workarounds have persisted for years, including with a new supplier, the Claimant infers: either the issues complained of are insignificant; or the Defendant has failed to mitigate its loss through proper documented workarounds at an early stage and by taking appropriate steps to address issues.’

676. There was a related Request for Further Information, in respect of which TCS complained about the adequacy of response, and generated a second Request. This asked at Request 33:

‘For each of 27 workarounds relied upon, please identify:

(a) The relevant cells in the spreadsheet for the workaround;

(b) How the workaround arises from the eight respects in which the Solution is said to have provided a poor and outdated user experience at paragraph 99.16 (and which - by the Response to Request 51 - the Defendant limits its claim);

(c) Over what period the Defendant alleges the workaround was employed (noting the Response to Request 51, which states some lasted only a few months).

(d) How the alleged workaround is quantified as a specific financial claim.’

677. The Response indicated that the pleading was adequate and the request sought a level of detail which was not necessary to enable TCS to prepare its case or understand the case it had to meet.

678. Request 37 is also relevant, in that it asked in relation to the aggregated losses claimed at Item 24 what proportion was attributed to the matters set out in paragraph 115.11 of the Amended Defence and Counterclaim i.e. the 27 workarounds, and how that was calculated. DBS responded:

‘The losses claimed at Item #24 are the losses flowing from the impact of the cumulative effect of the breaches which impacted on the efficiency of the operation of Barring. The claim does not seek to attribute any part of those losses to specific breaches including those identified at paragraph 115.11 and/or 115.12.’

679. The case TCS had to meet, therefore, was one in which, notwithstanding having been given the opportunity properly to particularise a case linking breach to workaround to loss, DBS averred was based solely on the aggregated loss.

680. I accept Mr Lavy’s submission that to advance a calculation attempting to link losses to the workaround schedule for the first time in Closing Submissions is plainly too late. TCS was entitled to understand in advance of trial (at the latest) any claim by which DBS sought to link a particular loss to a particular breach. TCS would be prejudiced if this claim were allowed to be advanced after the evidence closed. As Mr Lavy observed correctly, TCS's factual cross-examination on the workarounds spreadsheet was aimed at showing that DBS could and should have done a proper analysis rather than advance its global claim for efficiencies. There was no cross-examination to test, for example, the FTE assessments in the workarounds, how they were arrived at and how reliable they were (or were not). I accept that this is because there did not need to be in circumstances where there was no quantified claim. Similarly, it seems to me that there would likely be exploration of precise durations of instituted workarounds, and the reasons why certain workarounds have stayed in place. In fairness to Mr Croall, his oral reply closing submissions addressing this complaint acknowledged Mr Lavy’s point about what may have been cross-examined on and did not seek to suggest Mr Lavy’s submission was misplaced.

681. In the circumstances, TCS would suffer obvious prejudice if DBS were entitled to advance the particularised workaround claim in its Closing Submissions.

682. Finally, I note, however, that the (late) quantification of the claim throws the broader claim into even sharper relief. First, it shows that there had been ways of working from specific breaches rationally to quantify losses attributable to those breaches. In these circumstances, an aggregated approach is not the ‘best estimate’ of loss in these circumstances. Second, (and taking DBS’s workaround spreadsheet at face value) it highlights that of all the workarounds being put in place just 14.5% of time attributable to workarounds was attributed by Dr Hunt in her Appendix 12 to an identifiable breach relevant to item 24.

683. For all these reasons, DBS’s Counterclaim for lost inefficiencies at item 24 of the Updated Schedule of Loss fails.

N-1 Sustainment Costs

Item 15 of the Updated Schedule of Loss

Liability

684. DBS relies on Clause 2.36.7 of Schedule 2-2 to the Agreement, which provides that:

‘2.36.7.1. The CONTRACTOR shall ensure that, except with the prior written consent of the AUTHORITY (such approval not to be unreasonably withheld) all software (meaning, for the avoidance of doubt, all software that is used directly by the Users and all software that is used by the CONTRACTOR to provide, support and manage the Services) is maintained at the most recent (n) or immediately previous (n-1) general, stable version. …

2.36.7.3. For the purposes of this paragraph, "(n)" means the major version of the software, and for the purposes of this schedule, the "major version" shall be what a relevant governance and/or review board determines is a major version, based on information from the vendor of the software in question.’

685. It is common ground that some software was not at N-1 level at the expiry of the Agreement. A TCS spreadsheet dated 12 September 2019 records nearly 60 separate items of software and their status as at 1 September 2019 (col F) and as at 31 March 2020 (col G). (The latter is misdated 31 March 2019 but must relate to a point later in time than Column G because in a number of incidents the version has been upgraded in the interim). In cross-examination, Mr Konda accepted this spreadsheet was accurate (Day 4/62). The spreadsheet identifies that at least 17 software products were outside of N-1 as at that date, including software such as ‘SBB04 - IBM Infosphere MBM”, “SBB05 - Oracle Enterprise Service Bus’, ‘SBB13 - Oracle Policy Automation” and “Oracle Enterprise Manager’.

686. It is clear, therefore, that TCS was in breach of Clause 2.36.7 of the Agreement. In its written Closing Submissions, TCS does not, at least explicitly, challenge this, but instead argues that ‘there was good reason for this, and it did not cause DBS loss’.

687. As for the good reason, TCS identifies that R0 was a complex web of hardware and software. It points to TCS’s successor, CGI, and its assessment that ‘The DBS estate is complex with many inherent interdependencies. Currently the Estate is aging with many products end of life and out of mainstream support’.

688. When considering the prospect of a plan to upgrade all remaining components of the R1 system, TCS internally saw the project as extremely significant, as set out in the email from Mr Padannayi dated 30 September 2019:

‘You may recall, from our last meeting, Phil Jelley had asked the teams to come up with a 'Big Bang' plan to upgrade all the remaining components of R1 system. While we cannot have a detailed plan at this time until we carry out POCs, our teams have come up with a high level plan with proposed elapsed durations as below:

Offshore delivery (including Testing): 88 days (4.5 months)

Onsite delivery (Infrastructure): 50 days (2.5 months)

Onsite testing: 21 weeks (5.25 months)

Based on this, it looks like over 12 months of continuous work, even in a good scenario!! Offshore CRM team is speaking with TCS CRM COE to get more inputs and best-practices.

Now that we have commenced the Service Transition activities, the real question is: are we going to go back to DBS with such a big bang plan?’

689. In cross-examination, in reference to his 12 months’ estimate, Mr Padannayi explained why updating the software would be a significant undertaking and that it would first be necessary to identify the technology compatibility and formulate a proof of concept (Day 5/22). Mr Konda also accepted bringing the software up to N-1 would be a very significant task (Day 4/66). The 12 month estimate was, however, for carrying out the work itself (rather than for merely an analysis of how it was to be carried out).

690. TCS point out that it was contracted to provide involved the upgrade from R0 to R1 and that when (as I have found) R1-D was wrongly removed from TCS’s scope by DBS, the difficulties of carrying out upgrade (or dealing with end-of-life) became particularly acute.

691. Ultimately, whilst there were plainly significant difficulties in complying with the contractual requirement in practical terms, the fact that there may have been a ‘good reason’ for TCS’s breach in a qualitative sense, it remains the case that TCS was in breach of the obligation. It could have, but had not, sought to obtain prior written consent of DBS to a strategy which would not have sustained all software to N-1 in light of the practical issues, and DBS were not entitled to withhold its consent unreasonably. TCS’s failure either to carry out the necessary upgrades or to regularise the position contractually placed it in breach of contract.

Causation and Loss

692. DBS claims the cost of £2,050,916, apportioned on a 50/50 split between R0 and R1. The cost relates to a ‘Tiger Team’ provided by CGI.

693. In Closing, DBS contended that this cost related to the task of ‘carefully determining the current state of the software across the estate and identifying the best strategy for updating across the Solution as a whole’. In the Updated Schedule of Loss, DBS referred to this as ‘a preliminary analysis of the work required to update the software’. In other words, the costs claimed are not actually the costs of upgrading the particular items of software which were, in accordance with the spreadsheet, not at N-1 level.

694. The costs of the preliminary analysis are identified by Mr Hain as comprised within a Purchase Order dated 30 June 2021, which shows that the work paid for related an initial period of 6 weeks and then a further 8.5 months (total 10 months) of the ‘Tiger Team’. The date of Purchase Order coincides with the preceding Proposal presented by CGI dated 3 June 2021 (which contains tables of costs relating to the initial 6 week and overall 10 month periods referred to in the Purchase Order).

695. The ‘preliminary analysis’ which forms the basis of the claim was identified by DBS within its response to TCS’s RFI dated 16 December 202 as a particular spreadsheet, dated 11 October 2021. TCS takes the not unreasonable point that, on its face, the generation of the spreadsheet said to be the preliminary analysis which is the subject matter of the claim was produced at a point about 36% of the way into the overall 10 month period claimed on the face of the PO. On any view, the claim for remainder (74%) of the 10 month period is entirely unexplained by reference to the claimed ‘preliminary analysis’.

696. The further, significant, difficulty with DBS’s claim is that it is obvious from a review of the Proposal that the scope of the review undertaken by CGI was significantly broader than dealing simply with upgrading software which was, as at September 2020, not at N-1, i.e. the specific breach established. This can be seen, for example, in the following graphic:

A red and white box with black text

Description automatically generated

697. The breach of which complaint is made falls within just the first of the 5 ‘challenges’ which the Tiger Team were, according to the Proposal, tackling. This is also clear from the ‘Key Question’/’Further Steps and ‘Activities’ tables:

A screenshot of a chart

Description automatically generated

A white and blue box with black text

Description automatically generated

698. None of these questions were necessitated by, or even related to, the breach relating to N-1.

699. It is also clear from the ‘preliminary analysis’ spreadsheet itself that, even in relation to the more limited question of upgrading the software, DBS was concerned with the broader question of what upgrades were required to the software in order to achieve ‘cloud readiness’. This is not the same as considering what is required to upgrade to N-1. So, the summary table for R1 within the preliminary analysis showed:

A screenshot of a computer

Description automatically generated

700. That the focus of just part of the overall workscope was related to broader issue of cloud readiness, rather than the fact of N-1 itself, was also reflected in CGI’s paper dated March 2022 entitled ‘R1 Data Integration (Informatica)’ which stated:

‘Under N-1 Sustainment, the Data Integration epic was designed to propose solution(s) to replace the existing R1 data integration processes and functionality with a supportable strategic platform, ideally being on cloud or a cloud native environment. The proposed solution was to be sustainable to at least a level of N-1’.

701. I consider that the costs claimed by reference to the 10 month consultancy project undertaken by CGI bear no direct relation to the costs that would have been incurred by reference to the actual breach which has been established. DBS incurred these costs as part of its wider business strategy and would have done so whether or not the software was maintained at N-1. Whilst I can see that conceptually, some part of the cost of this project may have been increased by the N-1 sustainment issue, no attempt whatsoever has been made by DBS to carve out from these costs those which relate to that part of the workstream which might properly be linked (or equivalent) to more limited analysis the breach would have given rise to, or the truly additional costs caused by the complaint. There is, for example, no evidence from anyone from CGI who might have been able to provide some evidence enabling an assessment along these lines.

702. Even if this were not of itself fatal to DBS’s claim, I also note that the preliminary analysis itself demonstrates that which might be common sense, namely that (albeit through the lens of cloud readiness), significantly more of the legacy R0 software required removal or upgrade than R1 (i.e. 41 v 71) :

A screenshot of a computer

Description automatically generated

703. DBS have simply split the costs claimed between R1 and R0 on the basis of Ms Graves’ evidence that this split was an assumption considered to be ‘fair’ which came from the finance and business teams. This was not checked with CGI (Day 15/35). I have already found that such part of the costs which related to R0 are not recoverable following the wrongful removal of R1-D. There is no basis to think that simple 50/50 split is right in circumstances where the evidence seems to show (albeit against DBS/CGI’s different criteria relating to cloud readiness) significantly more for R0 software required upgrade than R1.

704. In the circumstances, DBS has failed to establish that the costs claimed have any or any sufficient causal connection with the breach established in respect of R-1 Sustainment.

705. The Counterclaim at item 15 of the Updated Schedule of Loss fails.

Exit/Service Transfer

Liability

706. DBS’s pleaded case on breach relies on Clauses 3.1-3.3 and 4.1-4.3 of Schedule 2-11. The particulars of breach at paragraph 112 of the Amended Defence and Counterclaim contain 3 allegations relating to planning (pursuant to Clauses 3.1-3.3): the provision of non-compliant STPs, the failure to discuss and resolve STP issues or provide revised versions twice a year (paragraphs 112.1-112.3). Paragraphs 112.4 to 112.6 relate to what might be called ‘execution’ (pursuant to Clauses 4.1-4.3): failure to provide assistances to migrate the Services to a Replacement Contractor, failure to act reasonably during the Exit and Transfer Arrangements, and failing to co-operate with DBS upon exit and transition.

707. No case was advanced by DBS in its Written Closing Submissions relating to the execution allegations. The focus of DBS’s case had narrowed to deficiencies in the STP planning document, and, in particular, Version 0.9 of the STP which existed as at July 2018. An STP was not in fact agreed between the parties until December 2019, which was v0.18.

708. Clause 3 of Schedule 2-11 sets out what the STP had to contain.

‘3. SERVICE TRANSFER PLAN

3.1 Where required by the AUTHORITY, no later than three (3) months after the Effective Date, and thereafter as specified in paragraph 3.3 of this schedule, the CONTRACTOR shall prepare a Service Transfer Plan (STP) for review by the AUTHORITY. The AUTHORITY shall review the STP within twenty (20) Working days of receipt from the CONTRACTOR and shall notify the CONTRACTOR of any suggested revisions to the STP. In this respect, the AUTHORITY shall act neither unreasonably, capriciously nor vexatiously. Such suggested revisions shall be discussed and resolved within ten (10) Working Days. The agreed STP shall be signed as approved by each party.

3.2 The STP shall provide comprehensive proposals for the activities and the associated liaison and assistance that shall be required for the successful transfer of the Services, including the following details:

3.2.1 proposals for the identification and transfer of documentation providing details of the Services, including the format and structure in which it is to be provided;

3.2.2 proposals for the identification of all Services;

3.2.3 proposals for the identification of all leases, maintenance agreements and support agreements utilised by the CONTRACTOR in connection with the provision of the Services, together with details of the relevant lessors and contractors, the payment terms, expiry dates and any relevant novation and/or early termination provisions;

3.2.4 proposals for the identification and return of all AUTHORITY Furnished Items in the possession of the CONTRACTOR;

3.2.5 a detailed summary identifying the owners of title and risk in all the Services and AUTHORITY Furnished Items following transfer of the Services;

3.2.6 proposals to enable the AUTHORITY or the Replacement Contractor to recruit suitably skilled personnel;

3.2.7 proposals for the training of key members of the Replacement Contractor’s personnel in connection with the continuation of the provision of the Services following the expiry or termination (howsoever arising) of this Agreement charged at rates agreed between the parties at that time;

3.2.8 proposals for the granting of licences to use all software (including the Software) necessary for the AUTHORITY’s receipt of the Services and the provision of copies of all related documentation;

3.2.9 proposals for the transfer of all AUTHORITY Data then in the CONTRACTOR’s possession to either the AUTHORITY or a Replacement Contractor, including:

3.2.9.1 an inventory of all AUTHORITY Data;

3.2.9.2 details of the data structures in which the AUTHORITY Data is stored, in the form of an agreed data model together with information on other data structures in which the AUTHORITY Data could be stored;

3.2.9.3 proposed transfer methods, both physical and electronic; and

3.2.9.4 proposed methods for ensuring the confidentiality, integrity and availability of the AUTHORITY Data on transfer,

3.2.10 proposals for providing the AUTHORITY or a Replacement Contractor copies of all documentation:

3.2.10.1 used in the provision of the Services and necessarily required for the continued use thereof, in which the Intellectual Property Rights are owned by the CONTRACTOR; and

3.2.10.2 relating to the use and operation of the Services;

3.2.11 proposals for the methods of transfer of the Services to the AUTHORITY or a Replacement Contractor;

3.2.12 proposals for the assignment or novation of all Services, leases, maintenance agreements and support agreements utilised by the CONTRACTOR in connection with the performance of the Services;

3.2.13 proposals for the secure disposal as appropriate to the security classification of any redundant Services and materials;

3.2.14 proposals for the supply of any other information or assistance reasonably required by the AUTHORITY or a Replacement Contractor in order to effect an orderly hand over of the provision of the Services; and

3.2.15 proposals for the transfer of all CONTRACTOR Equipment to either the AUTHORITY or a Replacement Contractor, including:

3.2.15.1 a register of all CONTRACTOR Equipment;

3.2.15.2 proposed identification and transfer methods, including the point at which risk and title in all CONTRACTOR Equipment shall transfer;

3.2.15.3 a detailed summary identifying the owners of title and risk in all the CONTRACTOR Equipment on transfer of the Services.

3.3 The STP shall be reviewed and updated by the CONTRACTOR. In this regard, the CONTRACTOR shall provide a revised version of the STP to the AUTHORITY on or before 31 July and 31st January each year (or more frequently as may be agreed between the parties). The revised STP shall be reviewed and agreed in accordance with the provisions of paragraph 3.1 of this schedule.’

709. It is relevant that the extent of TCS’s obligation to carry out the obligations pursuant to Schedule 2-11 and the STP were not unlimited, as set out in Clause 10.1:

‘The CONTRACTOR shall provide resources of sufficient skills and experience to carry out the activities required to fulfil the CONTRACTOR's obligations under this schedule 2-11 and the Service Transfer Plan. In order to fulfil such obligations the CONTRACTOR shall make full use of staff allocated to the provision of the Services (at no additional cost) and, further, shall provide at no additional cost to the AUTHORITY up to 60 man days of additional resources to carry out any activities which the CONTRACTOR is not ordinarily obliged to provide in the course of the day-to-day provision of the Services. Any additional resources required by the AUTHORITY from the CONTRACTOR in order for the CONTRACTOR to fulfil its obligations under this schedule 2-11 and the Service Transfer Plan shall be provided by the CONTRACTOR upon the request of the AUTHORITY and may be charged in accordance with the charges set out in schedule 2-3 (The Charges and Charges Variation Procedure).’

710. The analysis from the IT experts in relation to this issue is limited. Dr Hunt, in support of the claim, identifies in general terms that none of the versions prior to v0.18 provided the comprehensive proposals required by the Agreement, but there is no analysis of the individual elements which formed the central complains DBS identify in its pleadings or sought to elicit from the evidence at trial.

711. Ms Wooller, the consultant employed by DBS from August 2018 onwards as Programme Director (on the basis of a specification produced at v1.5 on 11 January 2018) gave evidence for DBS and was generally critical of the service plans and what she saw as a lack of engagement on the part of DBS. Some part of the costs of retaining Ms Wooller are included in DBS’s financial claim as referred to further below. Her criticism of STP v0.9 is, however, largely at a general level and to the extent it provides any detail on the particular breaches amounts (in paragraph 13) to an endorsement of the comments which had been submitted to TCS by DBS at the time (‘the v0.9 comment spreadsheet’). These comments are the same comments as were then included in the spreadsheet which passed between the parties and to which DBS responded. I consider those comments specific to the breaches alleged below.

712. In Closing, DBS assert that TCS failed to include in STP v0.9 (or any earlier version) comprehensive proposals for:

(1) The identification of all Services (3.2.2);

(2) Enabling the recruitment of suitably skilled personnel and/or training members of the replacement personnel in connection with the continuation of the provision of the services (3.2.6 and 3.2.7) i.e. knowledge transfer;

(3) Providing all documentation to a replacement contractor (3.2.1 and 3.2.10);

(4) The identification of all leases, maintenance agreement and support agreements in connection with the provision of the services (3.2.3)

(5) Providing any other information or assistance reasonably required by a replacement contractor (3.2.14)

713. Its pleaded allegations specific to paragraphs 3.2.9 and 3.2.12 were not pursued.

Identification of all services (3.2.2)

714. The obligation within Clause 3.2.2 of Schedule 11.1 required proposals for the identification of all services; it did not require within the STP the identification of services.

715. The STP v0.9 stated, in respect of this obligation:

‘3.2.2. Identification of all Services;

The Services are identified in the contractual Documentation, specifically Schedule 2-2 (The Services, Service Levels, Service Credits and Implementation Plan) and Schedule 3 (Contractor's Solution), as well as any additional RFC's/CCN's. In accordance with paragraph 3.2.1 of this Appendix B, the PMO will hold copies of all assured and shared Documentation (including such Documentation relating to design, build, test, training etc.) and this will collectively allow the Authority to identify all Services.’

716. In considering this complaint, it is necessary to review the comments made by DBS at the time and TCS’s response (in red), as contained in the v0.9 comment spreadsheet:

A white background with red text

Description automatically generated

717. In its Written Closing Submissions, DBS submits that the proposals under paragraph 3.2.2 relating to services provide no detail whatsoever and simply refer to the Agreement, and suggest that if that was satisfactory it would render the paragraph obsolete. However, DBS’s point at the time, which made sense, was not that it was inappropriate to refer to the Agreement in this context but that some of the services required by Schedules 2-2 and 3 had not been provided. As such, they pointed out that it was necessary to provide details of what - as against the Agreement - had not been provided. That was a fair point; and it was accepted in principle by TCS who agreed that it would highlight any aspects of the service that had not been delivered. The second point raised by DBS sought clarification that it was to be TCS who were to provide the identification of Services, and TCS agreed to make the necessary change to reflect this.

718. As an indication of the information about Services proposed to be identified on service transfer, this exchange, together with the response to the comment was perfectly adequate. I do not know whether in any versions before v0.9 these changes were formally reflected, but there was nothing to suggest that TCS’s identification of services during transfer would be insufficient. Moreover, DBS effectively changed, or added to, its requirement in September 2019, requiring TCS to identify all of the services currently supplied or supported in an IT infrastructure library style services catalogue, which requirement was then included in v0.18. There is no evidence that this was requested sooner, and it went beyond the comment made on v0.9.

719. I reject the submission that the STP v0.9 (read in conjunction with the comments and responses) fell short of the requirement at paragraph 3.2.2 of Schedule 2-11.

Knowledge Transfer (3.2.6 and 3.2.7)

720. Whilst paragraphs 3.2.6 and 3.2.7 plainly fall within the general pleading allegation relating to the whole of Section 3.2, it is of note that the absence of adequate proposals for knowledge transfer pursuant to these sub-clauses were not specifically identified as breaches at paragraph 106.1 or 112 of the Amended Defence and Counterclaim.

721. In respect of knowledge transfer, the information contained within v0.9 was clearly generic. The criticism advanced by DBS was that v0.9 did not include the level of specific planning which was ultimately included in v0.18, based upon the ‘comprehensive proposals’ for knowledge transfer that Mr Padannayi put together in October 2019.

722. In relation to the obligation at Clause 3.2.6, the v0.9 comment spreadsheet included the following concern and response (in red):

A white background with black text

Description automatically generated

A close up of text

Description automatically generated

723. There is no specific complaint by DBS in respect of this response, and as indicated above, Dr Hunt does not descend into sufficient detail to form a view as to why further specific details pursuant to this obligation were required. On the face of it, the types of information TCS indicated it would provide in order to permit the replacement contractor to recruit its resources seem reasonable.

724. In relation to Clause 3.2.7, knowledge transfer, the v0.9 comment spreadsheet included the following relevant exchange:

A white text on a black background

Description automatically generated

A red text on a white background

Description automatically generated

725. In addition, Clause 3.2.7 was addressed specifically as follows:

A white text on a white background

Description automatically generated

A red text on a white background

Description automatically generated

726. It is clear that in neither of its responses was TCS suggesting that knowledge transfer would not take place, but rather that planning in detail at that point would be subject to charges, on the basis that Clause 3.2.7 expressly entitled TCS to charge at rates agreed between the parties in respect of the provision of planning. At that time, on any view, the comment made placed the ball firmly in DBS’s court and, pursuant to Clause 3.1 of Schedule 2-11, it was for the parties together to resolve the comment.

727. Mr Padannayi’s evidence in cross-examination was consistent with this. He accepted that the sort of knowledge transfer plan ultimately produced in October 2019, after the notice of intended transfer had been given and when DBS had provided their document ‘TCS Exit Services Requirements’ had been issued, could have been produced earlier, but that DBS did not request this. Indeed, it is clear from the comments DBS themselves advanced that they were not at this point seeking the sort of comprehensive training programme ultimately included in v0.18. The comments at 3.2.7 suggested that DBS was anticipating that (for example) the STP record that TCS would in the future undertake an analysis of training needs with DBS and/or replacement contractor i.e. during the transition stage when the replacement contractor had been identified. When questioned about the ability to have produced his comprehensive plan sooner, he accepted that this was technically feasible, but he gave the following evidence, which I accept (Day 5/9):

So I think you told us this is a document you

produced without any input from DBS. So would it be

right to understand that if you'd been asked to produce

this much earlier in the project, you would have been

able to do so?

A. I mean, I wasn't asked to produce it, definitely, and

I wasn't even in that role of doing this. Yeah, if

there was an ask from DBS to produce this specifically

-- I mean, I don't think there was anything technically

preventing us from doing this.

Q. So something like this, this kind of information and

detail could have been provided much earlier in

the project if there had been an ask for it?

A. Specific to the knowledge transfer, could have been.

Could have been provided, yeah.

Q. So it would have been possible to break down each one of

the workstreams and identify the kind of information you

need to know about those workstreams and the kind of

information that a new supplier would need to be fed in

terms of information at a much earlier stage than end of

2019. Have I understood that right?

A. Can I just clarify something on that? You have to also

understand, as you showed in the previous statement,

the process it took me, the time it took me and

the people it took me to do this.

Q. Yes.

A. So here, we were officially into the transition stage

and I had access to those dedicated people, the process

I explained where I went to Mr Kuncheria and he

supported me. So, I don't know -- I don't want to

speculate now would it have been possible in the absence

of that official service transition window, because

I don't know if I would have got dedicated time from so

many experts to put this together. So -- so purely at

that technical level -- sorry, purely at the technical

level, it would have been feasible, but provided all

these people could have been dedicated for this activity

at that stage.

Q. So, if it had been appropriate to put something like

this kind of detail, or at least some parts of this

detail into a Service Transfer Plan at an earlier stage,

your evidence is that would have been possible so long

as enough people were available to engage with providing

the information; is that right?

A. That is correct, yeah.

728. The reality lies somewhere in the middle of both parties’ positions. The sort of details of how knowledge transfer would take place identifying a minimum level of provision, as suggested in the type of relatively high level comments on v0.9, would be required if the STP was to be regarded as compliant with Schedule 2-11. As accepted by Mr Britton in cross-examination, most of the additional detail in v0.18 in respect of knowledge transfer (and other matters) was not reliant on selection of a replacement contractor. To this extent, I regard the STP as having fallen short of contractual requirements. I reject the submission, however, that the detailed planning undertaken by Mr Padannayi (and alluded to in the first general comment within the v0.9 comment spreadsheet), which was a very significant piece of work detailing 253 sessions and delivery metrics, was something which ought to have been provided as part of the STP, unless DBS were prepared to pay for it pursuant to Clause 3.2.7 at that point. There is no suggestion that DBS responded to TCS in this regard. I also accept Mr Britton’s evidence that it is difficult to see how this level of detailed planning in respect of knowledge transfer (rather than in general principles) would be important to know in advance of the identification of the replacement contractor(s) and nature of the transfer. Finally, it does not follow that TCS should simply have adopted all the suggestions of DBS in respect of Clause 3.2.7 identified in the extract above, even though it gives an indication of the relatively high level information to be provided. I can understand, for example, the reticence of providing an STP which said barely, ‘Delivery of training to suit the needs of DBS’, even if that training was to be on a paid basis.

729. I conclude, therefore, that v0.9 did not comply with Clause 3.2.7 of Schedule 2-11, although TCS would not have had to produce something significantly different to the high level ‘outline’ identified by DBS’s own comments in relation to 3.2.7 in order for the document to be contractually compliant. That would be significantly less detail that that which TCS was ultimately able to include in v0.18 which followed Mr Padannayi’s comprehensive planning exercise once notice of transfer had been given.

Providing all documentation to a replacement contractor (3.2.1 and 3.2.10)

730. STP v0.9 identified TCS’s proposed approach:

‘TCS will produce a Documentation master list. Such Documentation master list will be provided to the Authority via the PMO during the planning phase of the Service Transfer process.

The Documentation Master List will be transferred to the Replacement Contractor after validation of the list between TCS and the Authority, followed by the Documentation itself. TCS' PMO already maintains a list of up to date assured and shared Documentation and this will form the basis of the Documentation Master List.’

731. It then included information about Document Types, TCS’s ‘Document Strategy’ (essentially where and how documents were stored), the information which would be captured on the Master Document List, how documentation would be transferred (if it was not already in the possession of the Authority) and how, if relevant, documents would be destroyed.

732. There were a number of comments on the Clause 3.2.1 provision. I do not reproduce them all here. DBS’s central criticism advanced in its Written Closing Submissions was that the STP did not contain proposals, but rather statements of future intent. On the basis that TCS indicated that ‘TCS’s PMO already maintains a list of up to date assured and shared Documentation’, it contended that a comprehensive proposal should have included TCS identifying this documentation specifically.

733. This criticism is not justified on the basis of TCS’s contractual requirements. The STP was to provide ‘proposals for the identification and transfer of documentation…’. The very reference to identification makes clear that the proposal itself was not required to identify the documentation which would be transferred. Moreover, it is plain that DBS itself did not at the time think that the STP was deficient because it did not contain the document master list. The comment and response within the v0.9 spreadsheet relevant to this particular complaint is set out below:

A black text on a white background

Description automatically generated

A white background with red text

Description automatically generated

734. The suggestion that the list would be subject to due diligence and updating as part of the service transfer itself was entirely reasonable, and in accordance with TCS’s obligations. The substance of this was agreed, to the extent relevant, by Ms Wooller in cross-examination (Day 14/81):

Q. And so, the response that we see here, surely that's

a response that you would regard as appropriate? What

they're saying is: well, yes, we do keep a list and all

we're required to do is to provide you with proposals?

A. Yes, so I -- I would then have expected, in the service

transfer plan, the TCS proposal would be that -- that

that list exists and at the point at which they went

into exit they would do their due diligence. So,

basically, what they say in that statement is the sort

of thing I would have thought that they would put in

the service transfer plan. That's their proposal of how

they would deal with -- deal with this list.

735. The consequence of this is that DBS’s complaint is really limited to the fact that the TCS response was not, potentially, brought forward to a further version of the STP, as fairly accepted by Ms Wooller in the following exchange (Day 14/82):

MR JUSTICE CONSTABLE: Can I just ask, did the fact that

that comment was made in the spreadsheet rather than in

the service transfer plan itself make any practical

difference in that you knew what the position was

through the way it is in the spreadsheet, or does it

have some impact I don't understand?

A. No, I think it would simply be, if -- if that was TCS's

position and it didn't have it in the transfer plan --

as I say, I don't know if that particular comment was in

the plan -- then it would be odd that they didn't just

include it in the plan so we -- we wouldn't then have

any further comments on that part of the plan. If

they'd stated in the plan that this is what they were

going to do in respect of that list, then DBS wouldn't

need to comment, they would just agree that the plan

covered sufficiently what they were doing with that

master list, so it -- it would have removed the need for

the comments backwards and forwards.

736. I reject the submission that a failure to have provided the actual list of documents to DBS prior to the initiation of service transfer and the necessary due diligence to be undertaken at that time constitutes a breach of Clause 3.2.1 of Schedule 2-11. Although it may have been better for the clarifications provided within the TCS responses to have made their way into the next revision, I consider that, in the particular respect complained of, v0.9 STP taken with the comments and responses was sufficient to comply substantively with Clause 3.2.1 of Schedule 2-11. No loss is claimed, in any event, on the basis that a (valid) clarification was included only in the spreadsheet and not in the STP itself.

737. It is not clear (whether from the pleadings, factual or expert evidence) what particular complaint arising from Clause 3.10 is advanced. The only comment within the v0.9 comment spreadsheet relates to how workarounds in place at the point of transfer will be identified, documented and provided. TCS indicated that this would be covered as part of the work under 3.2.2 (considered above). I do not consider that DBS have established any breach by TCS in respect of 3.10 of Schedule 2-11.

The identification of all leases, maintenance agreement and support agreements in connection with the provision of the services (3.2.3)

738. This was not a specific complaint made in paragraph 106 of the Amended Defence and Counterclaim, and neither the experts nor the factual witnesses give any description of how DBS failed to comply with this obligation. In principle, this appears to be a similar complaint to the Master Document List. In the v09 spreadsheet DBS raised two comments. The first related to clarification that the transfer of documents was not to be held up if they did not happen all to be ready at the same time, which TCS accommodated. The second comment sought clarification within the STP about what information had already been identified. As TCS rightly responded, the obligation was for TCS to provide proposals as to how this information will be identified, not to identify it as part of the STP. TCS’s STP included the proposal for how it would be gathered and presented to DBS.

739. I find that STP v0.9 was not in breach of Clause 3.2.3 of Schedule 2-11.

Providing any other information or assistance reasonably required by a replacement contractor (3.2.14)

740. This was not a specific complaint made in paragraph 106 of the Amended Defence and Counterclaim, and neither the experts nor the factual witnesses give any description of how DBS failed to comply with this obligation.

741. This Clause clearly related to specific requirements made by a replacement contractor during the process. Nothing specific was required in the STP produced in advance of the identification of particular information or assistance required by a replacement contractor.

742. I find that STP v0.9 was not in breach of Clause 3.2.14 of Schedule 2-11.

743. In the circumstances DBS has established that v0.9 was deficient in breach of Clause 3.2.7 of Schedule 2-11, in that the sort of details of how knowledge transfer would take place identifying a minimum level of provision were absent. However, DBS has failed to establish that the v0.9 was deficient such that TCS was in breach of Clause 3.2 of Schedule 2-11 in the other respects alleged.

Causation and Loss

744. DBS contends that there were two broad categories of loss caused by the alleged breaches. The first is the need for consultancy support, and the second is incoming supply cost.

745. In relation to the first category, it is said that because of the deficiencies in the STP up to and including STP v.09 and the lack of co-operation that betrayed, the programme to procure a replacement supplier and transition the services was significantly more complicated than it would otherwise have been.

746. Ms Graves explained in her third witness statement that DBS’ plans for transition and exit accelerated in around August 2018, when she says it retained Ms Wooller to assist with this project. The transition and exit had to be planned alongside the procurement of a new supplier to take over the services. DBS did not have the internal capacity to take on the exit and transition project, alongside all the work that was being undertaken at the time for R1 Barring and Basics. Ms Graves considered that some consultants would always have been needed by DBS, even if the transition away from TCS had been smoother, ‘without the disputes between the parties’. Therefore, when considering DBS’ costs of exit, Ms Graves gave credit for the “normal” costs of exit, assuming that DBS would have retained an additional project manager (a senior “Grade 6” project manager), plus advisers to assist with TUPE and employment issues. Ms Graves also said that DBS was not claiming for the costs of work done by consultants who were analysing “future” options (such as disaggregation) since she considered that similar advice would have been sought in any event and was not due to TCS. Ms Graves then tabulated the claims made excluding the CGI costs as follows:

A list of tasks with text

Description automatically generated

747. The starting point for the connecting the claimed losses to the established breach is not promising for DBS: the pleaded case from which the losses were claimed to flow included allegations of a failure to have acted reasonably during the Exit and Service Transfer arrangements, and to have co-operated with DBS (i.e. the execution allegations). However, as explained above, these claims were not pursued. The remaining narrow claim focussed on certain aspects of the STP document, and of the 5 complaints made, only one has partially succeeded.

748. In respect of knowledge transfer, there is no dispute that the exercise undertaken by Mr Padannayi in October 2019 was ‘comprehensive’ and has not been criticised, and there is no case that the v0.18 STP plan was materially deficient. It is also not said that TCS in any way failed to execute the plan agreed, and Ms Wooller stated in terms (at paragraph 21 of her statement) that from December 2019 onwards, TCS delivered pretty much as per the requirements agreed in the plan.

749. In this regard, I also view the factual evidence against the background of the opinion of evidence of the IT experts, neither of which provided any support for the proposition that any deficiency in the STP in fact caused any problems.

750. Dr Hunt’s evidence (Day 20/184) was :

Q. But you don't, in any of your reports, I don't think, identify any problems that actually occurred as a result of deficiencies in any of those earlier versions of the plans?

A. No, I haven't investigated what happened during service transfer.’

751. Mr Britton’s evidence, in his Second Report, was:

There are good reasons for wanting a supplier to maintain an up-to-date Service Transfer Plan throughout the duration of a contract, but once the service transfer has occurred, it is the quality of that transfer itself that matters and potentially leads to additional costs.

752. The costs claimed, save for the CGI costs, relate to the costs of additional external and internal resources. The only evidence in relation to additional personnel required came from Ms Wooller, who at paragraphs 36 and 37 of her Witness Statement said:

‘36. Because there was little co-operation from TCS and because we had no insight into what TCS would and would not do when it came to service transfer, we were forced to put projects in place to manage service transfer almost as though all the services were already with DBS or transferring to DBS rather than with a supplier. Although the DBS teams for the R0 premises and Payment Processing insourcing would have needed to exist in any event, I suspect there were at least 14 people (covering 12 different roles) we would not have needed in normal circumstances, as the work would have been handled by the incoming and outgoing suppliers. For example, in relation to the Contact Centre workstream additional staff that would not have normally been required included Laura Lord, two project support team members who worked with her, Neil Donlan, Paul Kerr, and Andy Copas. Additionally, Gary Salisbury and Karen Dooley were with the programme for a short period prior to Andy Copas and Paul Kerr joining. In relation to the Technology Services, additional staff who would not have been necessary included Neil Bhatta, Ian Woodley, Jordan Vaughan, Dave Norden and Steve Bowering. Harveen Kaur also joined the programme later on to lead the server room migration and over the transition period itself. Many of these people were engaged as consultants through CACI Limited, although Jordan Vaughan was from BJSS and Paul Kerr was from Accomplish Management Consulting. Other roles would have been needed anyway, but ended up being needed for more work than should have been necessary. This included Dave Sheppard who was brought in to help with the pricing model for tenders, but stayed longer than would have been necessary to support more broadly on the Contact Centre piece. Jacqui Gerrard (engaged via Certus Advisory) was involved with TUPE for the Payment Processing workstream, but probably spent about twice the amount of time as should have been necessary to also support on Contact Centre and the Technology Services. There were also several DBS subject matter experts who were called on more than should have been necessary throughout the tender and service transfer process, due to the absence of constructive engagement from TCS.

37. Furthermore, we realised that the issues around replacing R0 with R1 and service transition were both significant and that we would need to protect service transition from being affected by the work required to replace R0 by separating them into 2 programmes. As such, DBS had to double up on programme resources in order to be able to focus on both programmes with separate teams. R0 was becoming more pressing and an increasing risk to DBS because of the legacy systems involved. The discussions on whether or not to continue with plans to replace R0 and the commercial conversations about whether TCS met their contractual requirements in replacing R0, all played into the relationship with service transition.’

753. Even taken at its highest, it is not possible to link the additional personnel to the established breach by reference to this evidence. In any event, I do not accept Ms Wooller’s evidence more broadly in relation to causation. It is clear that by reference to DBS’s own draft exit plan in August 2018, a large team was planned, as demonstrated by the following organisational chart:

A diagram of a project management

Description automatically generated

754. It is obvious that no part of DBS’s decision to include the various personnel within its own transition organisation was a result of inadequacies in v0.9 (or, indeed, any preceding draft) of the STP. The draft exit plan does not refer to any TCS failure in this regard, and indeed specifically states at paragraph 1.5.3 that one of the ‘exclusions and constraints’ to which the plan was subject was that. ‘responsibility for the development of an exit transition plan will rest with TCS’. In other words, the plan itself rested on the assumption that TCS would comply with its contractual obligations with regard to transfer and exit, not that it was required, or had been expanded in any way, because of any actual failure on TCS’s part, or a perceived risk of future failure.

755. Moreover, in relation to the causal link between her own employment and DBS’s claim, it is plain from the specification (dated January 2018, many months before v0.9 STP) attached to her contract that her very broad brief related to the overall DBS strategy at the time, and was not caused by TCS’s failure in respect of knowledge transfer (or, indeed, the state of any part of the STP). Even though the breaches were not pursued, it seems obvious that the breadth of her role was also completely unrelated to the alleged lack of co-operation which lay months in the future (on DBS’s pleaded case). The background to the requirement/overview of requirement within the specification set out as follows:

‘1.1 The Authority is on a journey to transform the way in which it delivers its core services to the public. This began with the R1 digital Modernisation Programme, and will further evolve over the coming years with the potential expiry of the existing R1 Support contract in March 2019.

1.2 The Authority is currently working through its options to transition the existing Application Technology & Infrastructure delivery model, but will require expert external support in all aspects of the exit & transition programme.

1.3 The timeframe is likely to be challenging and continuity of services is paramount for a safe transition. The future model is likely to be a partly disaggregated model rather than a "big bang" single supplier shift.

1.4 A small programme has been established and the Programme Team have created a roadmap with timelines, activities and dependencies, it is anticipated that the Authority will appoint a Transition and SIAM partner/s to deliver the transition and manage suppliers post transition.

1.5 DBS do have some technical, commercial, administrative and management resources already allocated to the programme team and if required more can be drawn upon to support delivery.’

756. Furthermore, it is clear that the reason for additional personnel related in Ms Wooller’s eyes to general lack of co-operation from TCS (which allegation was not pursued) and the difficulties of transitioning whilst also dealing with R0 legacy issues (resulting from DBS’s own strategy to remove R1-D and for which TCS is not responsible). In evidence, Ms Wooller repeated her understanding that DBS needed external support during exit and transition because there was not the capacity within DBS to carry out transition work together with the ongoing day-to-day work on R0 ‘and the relationship with TCS’. Moreover even if general ‘lack of co-operation’ was a pursued and established breach, which it is not, Ms Wooller made clear that after September 2019, once DBS had presented what it felt should be in the service transfer plan, TCS cooperated.

757. In my judgment, DBS have failed entirely to establish on the evidence any proper causal link between the costs claimed and the only breach established, which was a failure on the part of the STP to have included more detailed (but nevertheless remaining relatively general) descriptions of the knowledge transfer process. Indeed, even if the STP related allegations under Clause 3 of Schedule 2-11 had all been made out, DBS’s claim would still have failed. There is simply no link between the additional personnel costs incurred by DBS in transitioning to the new supplier and the STP deficiencies alleged (and which were resolved, even on DBS’s case) for the execution of service transfer itself.

758. I find that none of the specific individuals in respect of which claims are made (Kim Wooller, Paul Kerr, Jordan Vaughan and Sunaina Shori (items 26, 27, 28 and 29 of the Updated Schedule of Loss) were employed as a result of the established breach (or, indeed, the alleged STP related breaches). The same applies to the miscellaneous personnel employed through the CACI agency (item 30). There is no evidence - either documentary or by way of narrative from a factual witness - that sheds any light on the link between the IBM costs claimed (item 25) and any part of DBS’s case in relation to STP deficiencies, or even the transition (relating as they do to a period after transition).

759. In the circumstances, the claims for additional external, agency and IBM personnel (items 25 to 30 of the Updated Schedule of Loss) fail.

760. The remaining claim, which at £3,526,593 is not insignificant, is pleaded on the basis that DBS engaged CGI to perform service transition work and to create contingencies, such as alternative accommodation, including the assessment and documentation of the design of the inherited systems. The costs were part of Lots 1 and 2 ‘were caused by the lack of documentation and the Claimant’s refusal to co-operate’. No claim for lack of documentation or refusal to co-operate, save in the limited sense relating to the STP specific alleged breaches, was advanced at trial let alone established. Ms Wooller confirmed in evidence that none of Lots 1, 2 or 3 related to complaints concerning TCS in relating to the STP. Ms Wooller also confirmed that if CGI had increased the cost of its bid as a result of not knowing more about knowledge transfer, that would have been set out within their risks and assumptions and their risk premiums. There is no evidence that this happened. Moreover, the suggestion that they may have done would be inconsistent with the evidence of Ms Mather of DBS, who said CGI provided lots of evidence of its experience with dealing with similar transitions and said that it was not unduly concerned about the fact that this would be a difficult transition, which they had plans to manage without seeking to rely on DBS to help support them. There is no link whatsoever between the sum claimed and the breach established (or, indeed, the breaches alleged).

761. In the circumstances, item 31 of the Updated Schedule of Loss fails.

H. The Security Incidents

762. It is common ground that there were three data breaches:

(1) the “Basics Certificates Data Breach” when on 2 February 2018, more than 1000 Basic Certificates were delivered to an individual’s address, each of which contained sensitive personal information relating to other individuals;

(2) the “Barred List Deletion of Records Incident”, when on 12 April 2018, a member of the public using the Barring Portal inadvertently managed to delete 294 cases and 95 individuals from the Barring List; and

(3) the “Victim Records Breach”, when on 19 June 2018 it was discovered that the records of individual victims were being inadvertently attached to the wrong cases, affecting 114 allocated, 552 unallocated, and 6020 closed cases.

763. In its Spigelman Schedule, DBS indicated for the first time that it sought ‘nominal damages’. No claim for damages, even nominal, is pleaded in respect of the security incidents. It is not suggested that the incidents caused any financial loss to DBS.

764. DBS, in its Written Closing Submissions, contended that the significance of the security incidents is that they (1) illustrate the existence of defects in the Solution at the time of Go-Live and the potentially serious consequences of such defects for DBS and its users; (2) demonstrate TCS’s unsatisfactory attitude and actions in relation to remedying defects which existed at Go-Live; and (3) contributed to DBS’ loss of confidence in TCS and its ability to deliver, an important factor relevant to DBS’ decision to partially terminate the Agreement and de-scope R1 Disclosure.

765. The only pleaded reference is to part of the justification for the validity of the Partial Termination. Whilst the security incidents may have, as a matter of fact, informed part of DBS’s strategy to remove R1-D, I have already found that the security incidents could not have been relevant to the contractual entitlement to remove R1-D by way of Partial Termination in accordance with Clause 55.11.

766. The security incidents are, as a result, irrelevant to the issues which I have had to decide. Were it relevant to have done so, I would have preferred the evidence of Dr Hunt that each of the incidents arose out of a breach on the part of TCS to have designed and coded the system in accordance with Good Industry Practice. That said, I also conclude that for each of these incidents, the immediate issue was resolved quickly, preventative steps were taken, and there were no other similar incidents. They did not demonstrate systematic problems with the solutions or a generally unsatisfactory attitude, as suggested.

767. Given that it should have been clear to DBS that these incidents were analytically irrelevant to any remedy sought, and that they were (at most) capable of providing some colour in the context of the overall relationship, it was unnecessary for quite so much time to have been spent in witness evidence (both factual and expert) and at trial on these matters.

I. The Charges Variation Dispute

Introduction

768. TCS’s fees for providing the operational services under the Agreement were principally in the form of Volume Based Service Charges. These were per-transaction charges payable in respect of each disclosure application processed by TCS during each Service Year. The scheme of charges, which is set out in paragraph 2.3 of Schedule 2-3 to the Agreement, specified a unit charge for each type of disclosure application (Basics, Standard, Enhanced and Update) for each Service Year as follows:

A table with numbers and a few words

Description automatically generated with medium confidence

769. The parties also agreed a mechanism to vary those charges for the following service year based on the number of transactions in the prior service year (‘the Charges Variation Clause’): Section 2.8 Schedule 2-3. The relevant provisions are:

‘2.8.4 If the Actual Transaction Percentage exceeds 110% (one hundred and ten percent) then the Transaction Charges for the subsequent Service Year may, at the Authority’s option, be reduced such that in the subsequent Service Year, the reduced Transaction Charges multiplied by the Predicted Transaction Volumes would give an under-recovery of Forecast Revenue in that Service Year equivalent (within 2%) to the over-recovery of the Forecast Revenue in excess of the 110% cap in the prior Service Year. The revised Transaction Charges shall apply from 1st April of the relevant year.

2.8.5 If the Actual Transaction Percentage is lower than 85% eighty five percent) but greater than 75% (seventy five percent) then the Transaction Charges for the subsequent Service Year shall be increased such that in the subsequent Service Year, the increased Transaction Charges multiplied by the Predicted Transaction Volumes would give an over-recovery of Forecast Revenue in that Service Year equivalent (within 2%) to the under-recovery of the Forecast Revenue in excess of the 85% cap in the prior Service Year. The revised Transaction Charges shall apply from 1st April of the relevant year. For illustration purposes only if the Actual Transaction Percentage equals 82% then the increase in Transaction Charges for the subsequent Service Year shall be such that the over recovery in the subsequent Service Year is equivalent to 3%, the difference between 82% and 85%.’

770. There was a slightly different procedure relating to the final service year: Sub-Section 2.8.8:

‘2.8.8 At the end of the Service Year 4 a minimum Transaction Volume shall be agreed for Service Year 5, on which the Volume Based Service Charge shall be calculated. This minimum Transaction Volume shall be 85% of the current Predicted Transaction Volume prevailing after any variation to the Predicted Transaction Volume made at the end of Service Year 4.’

771. Relevant terms within these clauses are defined as follows:

(1) ‘Forecast Revenue” is defined as “the revenue earned by the CONTRACTOR as stated in the Financial Model, cell Y21 in the summary worksheet”

(2) “Predicted Transaction Volume” is defined as “the entries within the Financial Model for each of the Basic Disclosure, Standard Disclosure, Enhanced Disclosure, Updated Service Applications and Update Service Renewals’.

772. The FM is referenced at Clause 20 of the Agreement, headed ‘Financial Model’. It states simply:

‘The provisions of schedule 2.3 (The Charges and Charges Variation Procedure) shall apply in relation to the Financial Model and the parties shall comply with their respective obligations under schedule 2-3 (The Charges and Charges Variation Procedure) in this regard.’

773. It is also relevant that Clause 2.3.3 of Schedule 2-3 states;

‘2.3.3 The Volume Based Service Charges shall be calculated each Month as follows:

2.3.3.1 for each type of Transaction, the actual volume of transactions in the Month shall be multiplied by the Transaction Charges in Table 1 or Table 2 above (as applicable), subject to any variation to the Transaction Charges arising from the provisions in paragraph 2.8, Charges Variation, of this Schedule 2-3.

2.3.3.2 the total Transaction Charges for each type of Transaction are then summed to give the monthly Transaction Charge.’

774. The parties disagree in two respects about the proper construction of these provisions, and, as the case was closed, one remaining factual dispute. These issues are relevant to the proper calculations to be carried out pursuant to the Charges Variation Clause. The three remaining issues are (numbered as per the parties’ submissions prior to Issue 3 falling away):

Issue 1: How the amount of an ‘over-recovery of the Forecast Revenue’ (Clause 2.8.4) or ‘under-recovery of the Forecast Revenue’ (Clause 2.8.5) is to be measured. This is an issue of construction.

Issue 2: Whether the Predicted Volumes for Basics in Service Year 4 were 1,000,000 (TCS’s case) or 320,374 (DBS’s case). This is an issue of fact.

Issue 4: How Clause 2.8.8 of Schedule 2-3 applied to Volume Based Service Charges in Service Year 5. This is an issue of construction.

775. The forensic accountant experts have agreed the results, depending upon the resolution of the points of contractual and factual difference, as set out in the following table:

Issue 1	Issue 2	Issue 4	Under/(Over) Payment
SY4&5 ATC	1m v 320k	85% floor v fixed	Under/(Over) Payment
TCS	TCS	TCS	15,164,816
	TCS	DBS	4,467,391
	DBS	TCS	14,373,890
	DBS	DBS	4,711,157
DBS	TCS	TCS	6,976,737
	TCS	DBS	(2,024,573)
	DBS	TCS	5,132,634
	DBS	DBS	(2,329,641)

776. Thus it can be seen that the result of the Court deciding each sub-issue in accordance with TCS’s case is that TCS would have been underpaid by £15,164,816. If each issue were determined in accordance with DBS’s case, DBS has overpaid TCS by £2,329,641.

777. I will deal with Issues 1 and 4 (the issues of construction) first.

Issue 1: How the amount of an ‘over-recovery of the Forecast Revenue’ (Clause 2.8.4) or ‘under-recovery of the Forecast Revenue’ (Clause 2.8.5) is to be measured.

778. I do not repeat the principles of contractual construction set out earlier in this judgment.

779. As provided within the definition, Cell Y21 of the ‘Summary’ Tab within the FM provides the ‘Forecast Revenue’, as referenced within the key provisions. Cell Y21 is described as the “Total Contract Value” and the sum of cells AA21:EP21. Those cells sum the revenue for each month, including the contribution from Volume Based Service Charges. The Volume Based Service Charge is in turn calculated by reference to the ‘Charges Summary’ sheet. This sheet contains the sum of the basic, standard, enhanced, and subscription charges for each month and obtain data from the Calculations sheet which in turn are based on the contractual transaction charges.

780. The transaction charges were set such that if DBS’s predictions as to volumes (the contractual ‘Predicted Volumes’) proved precisely accurate, the total sum payable by way of transaction charges would match the ‘Volume Based Service Charge’ element of ‘Forecast Revenue’ set out in the FMIt is common ground that whilst the Agreement provided for charges to be levied on a per transaction basis, the focus of the commercials was on the total revenue that would flow from DBS to TCS each year in relation to transactions, the unit charges effectively being “reverse engineered” to achieve the commercially agreed Forecast Revenue. That reverse engineering meant that provided volume predictions were accurate, the expectations of the FM would be met.

781. The agreed purpose of the Charges Variation Clause was, as pleaded by TCS and admitted by DBS:

‘to ensure that the Claimant’s revenues from the Transaction Charges remained broadly as envisaged by the Financial Model even if actual transaction volumes diverged significantly from the Predicted Volumes on which the Financial Model was predicated.’

782. Both parties aver that the mechanism should be construed in light of this.

783. Where actual volumes fall within the range 85% to 110% of predicted volumes in a given year, no adjustment is to be made. Where divergence is greater than that in any given year, Clause 2.8.4 allowed for downward adjustment of the unit charges for the following year to compensate for the revenue surplus caused by actual volumes exceeding 110% of predicted; and Clause 2.8.5 required upward adjustment of the unit charges for the following year to compensate for the revenue deficit caused by actual volumes falling below 85% of predicted. If the volume of charges fell below 75% a separate regime applied, but that is not applicable in the circumstances of this case.

784. It is to be noted that the trigger for adjustment is whether the number of transactions within a particular year exceeds or falls below the predicted number of transactions for that year by an amount outside the stated range i.e. the volume. In the language of the Clause, this is when the “Actual Transaction Percentage” is above 110% (Sub-Section 2.8.4) or between 75-85% (Sub-Section 2.8.5). The Actual Transaction Percentage is the percentage by which the actual transactions differed from the predicted transactions, and is calculated as a percentage: (actual transaction volume)/(predicted transaction volume) *100 as stated in Clause 2.8.2.

785. It is, therefore, not the revenue exceeding or falling below the predicted forecast that triggers the relevant adjustment, but a comparison between predicted and actual volume of transactions in a given year. It is also to be noted that TCS always takes the risk that transactions may be up to 15% lower than predicted in the FM, and takes the benefit (without risk of any clawback) of a potential 10% increase in volume. As such, the adjustment to the year following one in which the adjustment mechanism is triggered is by reference to the delta from the outer edges of the tolerance range, not from 100%. As per the example in Clause 2.8.5, if the actual transaction volume is 82%, then the upward adjustment to the rates is the equivalent of 3% (not 18%) to reflect the fact the TCS bears risk of the ‘first’ 15% of the transaction volume falling below 100%.

786. Whilst therefore the parties have agreed that the purpose of the clause is to ensure that the Claimant’s revenues from the Transaction Charges remained broadly as envisaged by the FM even if actual transaction volumes diverged significantly from the Predicted Volumes on which the FM was predicated, real emphasis should be placed on the word ‘broadly’, because the mechanism will likely end up with a divergence between predicted revenue and actual revenue because of 85%-110% risk/benefit range.

787. There is no difference between the parties as to how the clause operates to adjust the charges for SYX+1, assuming Actual Transaction Percentage is above or below the 85%-110% range in SYX.

788. If the higher trigger occurs, the Transaction Charges are decreased so that the (adjusted) Transaction Charge for year SYX+1 multiplied by the Predicted Transaction Values would give an under-recovery of Forecast Revenue equivalent to the over-recovery for the Forecast Revenue in excess of the 110% cap in SYX. So (in an example I explored with the experts, who both agreed with the following), if the Actual Percentage Volume is 113% in SYX:

(1) The excess Actual Percentage Volume (beyond 110%) is 3%.

(2) the Forecast Revenue for SYX+1 is reduced by a figure equivalent to 3% of Forecast Revenue for SYX (‘the Adjusted Forecast Revenue’);

(3) the Adjusted Forecast Revenue for SYX+1 is divided by the Predicted Volume for SYX+1, to give the new Transaction Charge;

(4) this has the effect that, if the predicted volume for SYX+1 comes precisely to pass, the aggregate recovery over years SYX and SYX+1 is the Forecast Revenue for those two years, plus 10% of SYX Forecast Revenue.

789. The mechanism also has the effect that if the predicted volume for SYX+1 falls within the 85%-110%, there is no triggering mechanism to permit adjustment of the Transaction Charge in SYX+2 in order to compensate for any over or underpayment within the range. However, given that payment in SYX+1 is also intended to compensate TCS or DBS for any over/underpayment in year SYX, this means that TCS may or may not be fully compensated for any under-recovery and/or DBS does not clawback in full any over-recovery in the previous year. This works in either parties’ favour depending on the happenstance of the Transaction Volume in SYX+1. So, if the rate was reduced in SYX+1 because of an excess volume in SYX, the mechanism operates so that any increased volume in SYX is also paid at the reduced rate. Similarly, if the rate was increased in SYX+1 because of reduced volume in SYX, any increase in volume above 100% of predicted volume in SYX+1 is also paid at the higher rate. This is illuminating as it demonstrates the very real limitations of the mechanism in maintaining Forecast Revenue, even broadly.

790. It is now necessary to consider the different approaches of the parties to the proper calculation in year SYX+2 in circumstances where there was an adjustment in SYX+1 to Transaction Charges because of an excess or shortfall in volume in SYX.

791. On TCS’s case, the over- or under- recovery is calculated by comparing Forecast Revenue for SYX+1 (i.e. predicted transaction volumes for SYX+1 multiplied by the contractual unit transaction charge for SYX+1) with actual revenue (i.e. the actual transaction volumes for SYX+1 multiplied by the actual unit transaction charge for SYX+1, reduced or increased as it was from the contractual unit transaction charge for SYX+1 by any adjustment which took place at the end of SYX). DBS’s case is that the comparison is between forecast revenue for SYX+1 (i.e. predicted transaction volumes for SYX+1 multiplied by the contractual unit transaction charge for SYX+1) with a ‘deemed’ actual revenue (i.e. the actual transaction volumes for SYX+1 multiplied by the contractual transaction charge for SYX+1). It therefore ignores the fact that the contractual transaction charges for SYX+1 had been varied by operation of paragraph 2.8 of Schedule 2-3.

792. TCS contends that as a matter of language, the amount of an ‘over-recovery’ or ‘under-recovery’ must be measured by reference to the amount of actual recovery and not the amount of the recovery that would have arisen had the unit transaction charges been different but that did not in fact arise because the charges were not in fact set at a level that led to such recovery.

793. It also contends that its calculation is more consistent with what the parties accept was the commercial purpose of the provisions. It uses an example of 150 actual transactions for each of Service Years 1-3, against a prediction of 100 each year (which would have generated an overall Forecast Revenue at £10 per transaction of £4,000 over 4 years). On that example, the model agreed by the experts demonstrates that TCS’s construction of paragraph 2.8.4 leads to total actual revenues of £4,500 and DBS’s calculation leads to total revenues of £3,900. It contends that although the DBS figure happens to be closer to the FM than the TCS figure, the outcome on DBS’ construction is commercially perverse: the example demonstrates that the revenues that TCS receives for processing a total of 550 transactions over the term (i.e. 150 more transactions than forecast by the financial model) is less than the revenue it would have received had it processed only 400 transactions; and even less still than the £4,300 that TCS would have been entitled to receive (on both parties’ cases) had it processed a total of 430 transactions over four years (precisely 110% of predicted volumes). TCS submits that the greater the divergence of actual Transaction Volumes from Predicted Volumes, the more extreme this commercial perversity becomes. If volumes are increased to 300 for each of Service Years 1 to 3 (i.e. a total of 1000 transactions for the term), it contends that DBS’s construction leads to TCS not being paid at all, and instead having to pay DBS £3,300. It therefore submits that a construction that leads so readily to such outcomes is unlikely to be correct.

794. Notwithstanding this example, I do not consider that TCS’s construction is correct. As a matter of language, the focus of the clause is upon (a) Actual Transaction Percentage in terms of triggering the adjustment, but also upon (b) Forecast Revenue when considering over or under-recovery and adjustment of the Transaction Charge. Forecast Revenue is defined by reference to the FM, and is the predicted volume multiplied by the contractual rate. At the end of year SYX, both parties’ construction accepts that ‘over’ or ‘under’ recovery is a matter being driven by excess or insufficient volume alone, and the extent of adjustment to the Transaction Charge is also therefore driven by excess or insufficient volume. TCS’s construction, however, then means that ‘over’ or ‘under’ recovery in year SYX+2 means the aggregate effect on Forecast Revenue of both excess or reduced volume plus the change in the Transaction Rate as a result of a previous adjustment.

795. I consider that TCS’s construction is not supported by the illustration given at the end of Clause 2.8.5. This states that ‘if the Actual Transaction Percentage equals 82% then the increase in Transaction Charges for the subsequent Service Year shall be such that the over recovery in the subsequent Service Year is equivalent to 3%, the difference between 82% and 85%.’ It is the change in volume alone which dictates the adjustment to the Transaction Charges. The effect of taking the actual over recovery in the subsequent Service Year rather than what has been called the deemed over recovery (using the appropriate contractual rate for the relevant Service Year, rather than the actual, adjusted rate) means that the consequent adjustment will not be made solely by reference to the change in volume, as the illustration makes clear is the intention of the parties. DBS’s construction is true to the illustration, in that, by using the contract rates for the relevant year in both sides of the comparison, it is only the extent of volume change (outside the range) from predicted to actual which drives the adjustment for the following year.

796. Similarly, by permitting the effect of the adjustment to the rates in SYX+1 to play a part in identifying whether or to what extent there has been an over or an under recovery, the situation can arise, on TCS’s construction, whereby the mechanism would produce, in SYX+2, an increase in Transaction Charge notwithstanding the fact that the transaction volume exceeding the predicted volume. The same is true in reverse. This is clearly not an intended outcome. It is clear that the language implies that any relevant excess volume must lead to the Transaction Charges being ‘reduced’; any relevant fall in volume must lead to the Transactions Charges being ‘increased’. A construction whereby this may not be the outcome is not the correct construction. Such an outcome is not possible where adjustment is driven by excess or reduced volume alone, as DBS’ construction requires.

797. This potential effect was accepted by Mrs Wall, TCS’s forensic account, as a potential effect of TCS’s construction. In her calculations she noted that such an effect would be an unlikely intention, and sets her formula to avoid it. She states (at Note 10 to calculation sheet H5 at Appendix VW1-H to her First Report):

‘Paragraphs 2.8.4 and 2.8.5 of Schedule 2-3 state that the Charges Variation Procedure operates such that the Transaction Charges for the subsequent Service Year “…may, at the Authority’s option, be reduced" or “…shall be increased" if the Actual Transaction Percentage is higher than 110% or lower than 85% respectively. I would expect that if the Actual Transaction Percentage were higher than 110%, the adjusted Transaction Charge for the subsequent Service Year to be lower than or equal to the contractual Transaction Charge set for the subsequent Service Year. I have therefore set a minimum value of either (i) the adjusted Transaction Charge calculated from the formula or (ii) the contractual Transaction Charge for the subsequent Service Year. Equally I would expect that if the Actual Transaction Percentage were lower than 85%, the adjusted Transaction Charge for the subsequent Service Year to be higher than or equal to the contractual Transaction Charge set for the subsequent Service Year. I have therefore set a maximum value of either (i) the adjusted Transaction Charge calculated from the formula or (ii) the contractual Transaction Charge for the subsequent Service Year.’

798. By introducing the maximum and minimum adjustments into the formula when modelling TCS’s construction to avoid this improbable outcome, Mrs Wall is in effect introducing words into the clause in order to make sense of it, which words (a) do not exist and (b) are not necessary to make sense of the DBS construction. This points against TCS’s construction as being correct.

799. It may be noted, further, that in fact it is only Clause 2.8.4 which states that the adjustment is at the Authority’s option. Clause 2.8.5 (when there has been insufficient volume) requires that the rate shall be increased. Thus, the mechanism introduced into Mrs Wall’s model is not in fact permitted by the clause. A construction which requires the rates to be reduced in SYX+2 in circumstances where there the Actual Transaction Percentage is lower than 85% is plainly not contemplated by the language of paragraph 2.8.5.

800. As to the example raised by TCS in Closing, of 300 transactions for each of years 1 to 3, the model shows the following:

801. First, it can be the seen that the ‘negative’ transaction sum is a feature of both the TCS and the DBS construction in year 2, the calculation of which is common to both sides’ approach. The production of a negative sum is, therefore, of itself not a feature which should be considered particularly remarkable or a basis upon which to judge one construction as correct or not. It is the arithmetic function of an extremely high number of transactions, very significantly above the predicted volume. Second, as DBS submitted, whilst the model produces a negative number, there is no contractual mechanism for payment from TCS to DBS and so in reality, a negative number is equivalent to zero. If the negative numbers are substituted for zero, then over the 4 years, the DBS calculation provides for £3,000 aggregate income (against £4,000 Forecast Revenue) and TCS’s calculation produces £2,400. The overall effect is, therefore, that the DBS model produces an aggregate recovery that is more ‘broadly’ in line with the aggregate Forecast Recovery than TCS’s calculation. The conclusion that the example demonstrates the uncommercial outcome generated by DBS’s construction does not follow.

802. In coming to this conclusion, I make clear that I do not place any weight on DBS’s argument that the clause should be construed in the context of the International Financial Report Standards in IFRS.

Issue 4: How Clause 2.8.5 of Schedule 2-3 applied to Volume Based Service Charges in Service Year 5

803. TCS contends that the meaning and effect of Clause 2.8.8 was to ensure a minimum Volume Based Service Charge for TCS in Service Year 5, to be calculated by multiplying the applicable transaction charge by 85% of Predicted Volumes. It contends that Clause 2.8.8 was not engaged unless actual volumes in Service Year 5 fell below 85% of Predicted Volumes (just as, TCS says, Clauses 2.8.4 and 2.8.5 were not engaged unless actual volumes in Services Years 1 to 4 fell outside the range 85% to 110% of Predicted Volumes). Thus if (as was in fact the case for Basics, Standard Disclosure and Enhanced Disclosure transactions) actual volumes exceeded 85% of Predicted Volumes, TCS was entitled to Volume Based Service Charges calculated by multiplying actual volumes by the applicable transaction charge. It is argued by TCS that:

(1) As a matter of language, ‘minimum’ means minimum. On a natural and ordinary reading, the clause provided that regardless of how few transactions were actually affected in Service Year 5, TCS would be entitled, at a minimum, to Volume Based Service Charges calculated by multiplying the contractual unit charge by 85% of Predicted Volumes for that Service Year.

(2) Moreover, paragraph 2.3.3 of Schedule2-3 provided that the Volume Based Service Charges were to be calculated by multiplying ‘the actual volume of transactions’ by the applicable Transaction Charges (i.e. the unit charges). Whilst that was said to be ‘subject to any variation to the Transaction Charges arising from the provisions in paragraph 2.8 …’ (emphasis added), it was not subject to any variation to volumes. Nothing in paragraph §2.3.3 or §2.8.8 suggests that the former ceased to apply in relation to Service Year 5.

804. DBS argues that in Service Year (‘SY’) 5, TCS was to be paid the applicable transaction charge (whether adjusted or not) multiplied by 85% of the Predicted Transaction Volume. It is argued by DBS that:

(1) The wording of sub-section 2.8.8 is clear and unambiguous. The Volume Based Service Charge was to be calculated on the minimum transaction charge (85% of the predicted transactions) agreed “at the end of Service Year 4”.

(2) Accordingly, the charge was fixed for SY5. That is consistent not just with the plain meaning of the words used, but also the fact that a reasonable observer would have understood the purpose was to provide clarity over the sums DBS would pay. The objective reason for the fix is that there was no future year in which an over or under-recovery could be clawed back.

(3) TCS’s contention there was to be a calculation at the end of SY5 at which time the Volume Based Charge would be the higher of 85% of the predicted revenue or the actual volume times by the applicable transaction charge is wrong. Firstly, DBS point to the fact that there is no language which supports that interpretation,and say that it is contradicted by the clear language focussing on the calculation occurring at the end of SY4, at which time the actual volume for SY5 was unknown. Secondly, this would expose DBS to paying an unlimited amount of money with no possibility of recovery by adjustment in the following year. That would contradict the carefully construed Charges Variation Clause as a whole and the agreed purpose of the clause. Thirdly, TCS’s interpretation benefits only TCS, whereas the true construction is balanced and may favour TCS (if actual volume < 85%) or DBS (if actual volume > 85%).

805. Clause 2.1 of Schedule 2-3 requires that ‘the Authority shall pay the Service Charges to the Contractor for all operations services in each Month from the Service Commencement Date to the end of Term’. The Term (subject to any extension) was 5 years. The Service Charges shall be made up of various Charges, include ‘Volume Based Service Charges in accordance with paragraph 2.3 below’. Clause 2.3.1 sets out the table quoted above, and as also set out above, Clause 2.3.3 then requires that the Volume Based Service Charges shall be calculated each Month. For each type of transaction, the actual volume of transactions in the Month shall be multiplied by the Transaction Charges in Table 1 (during the initial 5 year Term), subject to any variation to the Transaction Charges arising from the provisions in paragraph 2.8.

806. Whilst cross reference to Clause 2.8 of Schedule 2-3 is made within Clause 2.3.3 of Schedule 2-3, this cross reference is made with respect to any variation to the Transaction Charges. It does not identify that Clause 2.3.3 is more widely subject to variation as a result of Clause 2.8.

807. Applying Clause 2.3.3 to Year 5, it would suggest that the Volume Based Service Charges shall be calculated each Month by multiplying the actual volume of transactions by the Transaction Charges (as varied by the provisions in paragraph 2.8). This would suggest that the amount of the Volume Based Service Charges will vary with actual various in volume of transactions in Year 5, as with previous years.

808. Notwithstanding any broader cross-reference between Clauses 2.3.3 and 2.8.8 of Schedule 2-3, it is clear that both sides contended for constructions in fact impose a further change in the manner in which the Volume Based Service Charge is calculated.

809. On TCS’s case, a minimum Volume Based Service Charge is calculated (by reference to 85% of the predicted volume of transactions for Year 5 multiplied by the applicable Transaction Charge). If the actual volume falls below 85% of the predicted volume, TCS is to be paid the minimum Volume Based Service Charge rather than the actual. Clause 2.8.8 is silent as to how this mechanism works on a monthly basis, or how the adjustment process works at the end of Year 5. As DBS points out, the clause does not suggest that there is some adjustment/accounting process at the end of Year 5. This is a factor which weighs against TCS’s construction.

810. On DBS’s case, there is, in effect, a fixed Volume Based Service Charge (again, calculated by reference to 85% of the predicted volume of transactions for Year 5 multiplied by the applicable Transaction Charge). However, this construction suffers a similar problem in that there are no express words which explain precisely how, in practice, the mechanics of the change to the ‘vanilla’ Clause 2.3.3 process actually works. Does TCS get paid accordingly to actual volumes, in accordance with Clause 2.3.3, on a monthly basis until the minimum volume is met, at which point no further payments are due? Or are the payments made in accordance with Clause 2.3.3 with an adjustment process at the end of the year to repay any sums required to be paid by 2.3.3 but which overtop the minimum Volume Based Service Charge calculated pursuant to Clause 2.8.8?

811. It can be seen that the interrelationship between Clause 2.3.3 and Clause 2.8.8. is poorly drafted and neither sides’ construction properly reflects a fully described and satisfactory mechanism.

812. However, in my judgment giving proper meaning to the word ‘minimum’ is likely to be the key to construing the intention of the parties. On DBS’s case, it is a word which is, at best, otiose and, more problematically for DBS, positively misleading in some circumstances. In circumstances where actual volumes exceed 85% of the predicted volume, the clause does not operate to provide a ‘minimum’ Volume Based Service Charge at all: indeed, it operates as a cap. It was suggested by Mr Croall in argument that the word refers to the fact that 85% is the acceptable ‘minimum’ Actual Percentage Transaction in Clause 2.8.3, but that is not what Clause 2.8.3 either expresses or implies. 85% is the bottom of the range within which there is no adjustment of the Transaction Charge. I do not regard Clause 2.8.3 as giving the word ‘minimum’ a sensible meaning within Clause 2.8.8. TCS’s submission that if the parties had intended the clause to mean what DBS contends it means, it would have most accurately used the word ‘fixed’, or no further descriptor at all, is right. In circumstances where I consider there is, in the language used, a plain indicator that TCS’s construction is preferable - in that it imbues the word ‘minimum’ with proper meaning - the fact that DBS’ construction is ‘balanced’ and might operate in either parties’ favour is not persuasive. That the adjustment is upwards only is, in fact, precisely what one would expect the implication of use of the word ‘minimum’ to be. It does not create a commercially odd outcome, insofar as relevant. Where TCS earns more, it is because it has carried out more work (and DBS has received more income).

813. In the circumstances, in relation to Issue 4, TCS’s construction is preferable.

Issue 2: Whether the Predicted Volumes for Basics in Service Year 4 were 1,000,000 (TCS’s case) or 320,374 (DBS’s case)

814. The contractually agreed Predicted Volumes figure for Basics in Service Year 4 was originally 1,000,000, but DBS’s case is that figure was subject to later contractual amendment whereby it was revised to 320,374. In response to an RFI raised by TCS as to how and when such amendment was alleged to have been made, DBS responded as follows:

[DBS] is continuing to investigate the precise circumstances in which the amendment was made. This issue will be addressed in [DBS’s] witness evidence and/or by way of further particulars in due course.

815. TCS contends that the issue was not the subject of any further particulars and was not addressed at all in DBS’s witness evidence. It says that it is for DBS to establish that the contractually agreed Predicted Volumes were amended as alleged and that, in the absence of evidence on the point, it cannot do so.

816. DBS contends the change to the predicted transaction volume for Basic Disclosure in SY4 (1 April 2017 – 31 March 2017) can be seen from : ‘Sheet H.2 Cell [D9] in VW1- H {C3/9/1}, Cell E21 of the Method Tab {F/3286/1}; {B2/7/14}’.

817. I cannot from these documents find the agreement DBS alleges. The first document referred to is a non-contemporaneous document created by DBS’ expert. The second document [F/3286] is a spreadsheet created in 2018. It is correct that at Cell E21 in the two tabs marked ‘TCS Method’ and ‘DBS Method’ there can be seen the number 320,374. There is a comment for each cell which states: ‘Reset as per Clause 2.8.6’. This could suggest that at this time the parties were aligned. Interestingly, this number appears to have been ‘hard’ inserted into the spreadsheet rather than the result of cross-reference to other parts of the spreadsheet (like other predicted documents). The spreadsheet appears to be a TCS document. It was provided to Ms Graves of DBS. Ms Graves was called to give evidence by DBS, but gave no evidence about any such agreement even though her evidence did touch on matters relating to the methodology of varying the transaction charges. The third document referred to by DBS [B2/7/14] is an exhibit to the second witness statement of Ms Graves. Page 14 of this document is referenced at paragraph 7 of her evidence which states that ‘The enclosure to that email (at pages 9-14) explains DBS's interpretation in more detail, and also includes details of the amounts which DBS considered would be due to TCS, including in respect of the Update Service for Service Year 5.’ It does not provide any evidence relating to an agreement (or absence of agreement) related to predicted volumes. In fact page 14 contains an extract from what appears to be a document stating that it is without prejudice and subject to contract.

818. Mr Croall had no instructions on why Ms Graves gave no relevant evidence. There is therefore no factual evidence at all called by DBS explaining the meaning of the document, or the fact of any agreement it is said to represent. Equally importantly, the individuals named in the document as the author (Subramanian Sankaranarayanan) and the person who last modified the document in 2019 (Kamala C L) both gave witness statements for TCS and were available for questioning on this matter: neither was questioned and the substance of DBS’ case - that this document evidences an underlying agreement - was not put to them.

819. Whilst it might be that the documents referenced in submissions by DBS were capable of substantiating its case about an amendment, they are not so clear on their face that the fact of such an agreement is inescapable (or even prima facie). Factual evidence from a relevant witness is needed to explain the content of the two contemporaneous documents relied upon; alternatively, DBS could have put its case as to the import of the documents to the relevant TCS witnesses and it did not do so. In these circumstances I do not find, on balance of convenience, that the agreement alleged has been established.

Conclusion on Volume Based Service Charge

820. Therefore, DBS succeeds on Issue 1, and TCS succeeds on Issues 2 and 4. The agreed financial result from this is that TCS have been underpaid by £6,976,737. Whether this sum is subject to VAT is a matter to be dealt with following further argument from the parties at the hearing dealing with consequential matters, unless agreed.

J. Summary of Conclusions

821. I therefore conclude as follows in respect of the parties’ Claims and Counterclaims (subject to the remaining issue of applicable VAT):

(1) TCS is entitled to:

(a) Manpower costs (R1-D): £666,735.00

(b) Non-Manpower costs (R1-D): £1,732,989.70

(2) DBS is entitled to:

(a) CCN041 £4,559,439.00

(b) Barring Portal Defects (Snowbound) £8,270.00

822. All other claims by TCS and DBS are dismissed.

823. The net sum payable by DBS to TCS is therefore £4,808,752.70 (subject to the remaining issue of applicable VAT).

824. Neither side have provided detailed submissions on interest (save relating to the Late Payments point dealt with in the context of CCN 041). The parties are invited to agree interest calculations. In the absence of agreement, I shall determine interest related issues along with the usual consequential orders.

[1] https://www.judiciary.uk/speech-by-lord-justice-popplewell-judging-truth-from-memory/

[2] The total of the top line (£830,017) multiplied by 98/122 (number of days 13 June-19 Sept/total number of days June-Sept)

[3] The equivalent calculation for the bottom line.

	TATA CONSULTANCY SERVICES LIMITED	Claimants
	- and -
	DISCLOSURE AND BARRING SERVICE	Defendants

	[Home] [Databases] [World Law] [Multidatabase Search] [Help] [Feedback]
	England and Wales High Court (Technology and Construction Court) Decisions
You are here: BAILII >> Databases >> England and Wales High Court (Technology and Construction Court) Decisions >> Tata Consultancy Services Ltd v Disclosure and Barring Service [2024] EWHC 1185 (TCC) (17 May 2024) URL: http://www.bailii.org/ew/cases/EWHC/TCC/2024/1185.html Cite as: [2024] EWHC 1185 (TCC)

England and Wales High Court (Technology and Construction Court) Decisions

JUDGMENT

A. IntroductiON

B. Issues of Construction of the Agreement

Limitations of Liability

The Barring Portal

Barring Portal: Loss of productivity - Item 11 of the Updated Schedule of Loss

Siebel Useability Issues

Introduction

Issue 1: How the amount of an ‘over-recovery of the Forecast Revenue’ (Clause 2.8.4) or ‘under-recovery of the Forecast Revenue’ (Clause 2.8.5) is to be measured.