![HT-2020-000448 - [2024] EWHC 1185 (TCC)](https://backend.juristeca.com/files/emisores/logo_yJUntHA.png){kind=logo}
N-1 Sustainment Costs
N-1 Sustainment Costs
Item 15 of the Updated Schedule of Loss
Liability
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.’
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’.
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’.
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’.
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?’
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).
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.
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.
- Heading
- CONTENTS
- IntroductiON
- The Factual Witnesses
- Expert Evidence
- Programming Experts
- Forensic Accounts
- The Parties Submissions
- Principles Applicable to Issues of Construction
- The Defendant’s Obligations and Responsibilities
- Clause 15
- Clause 9.5 which states
- Clause 14.5 of Schedule 2-6 which states
- The Delay and Notice Provisions
- Clause 7
- Conditions Precedent: Clauses 5 and 6
- Conditions Precedent: the authorities
- Clause 5.6
- Clause 6
- Clause 8
- Limitations of Liability
- A single or multiple caps?
- The Delay Damages cap under Clause 52.2.5
- Is TCS’s claim for loss of anticipated costs savings excluded by Clause 52?
- Compliance with Clause 5.3, Agreement and Estoppel Introduction
- Express Agreement
- Estoppel
- Introduction
- R1 B&B Delays
- Mr Britton’s First Analysis
- Mr Britton’s Second Analysis
- Conclusion on Mr Britton’s Analyses
- TCS’s submission based upon Mr Jardine’s analysis
- Responsibilities for Delay on the ‘Infrastructure’ Critical Path
- R1-D
- Compliance with Notice Provisions
- Analysis of Delays
- Up to August 2017
- From August 2017 to 19 September 2018
- Analysis
- 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 prerequis
- Failed to make available an end-to-end test environment for the Interactive Voice Response system
- 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 ensure that relevant external stakeholders were available to participate in Final Systems Integration Testing
- Partial Termination
- TCS’s Claims
- Non-Manpower Costs
- Anticipated Cost Savings
- Summary of TCS’s Delay Claim Recovery
- DBS’s Claims
- Delay Payments
- R1-B&B Delay
- Disclosure Scotland Extension Costs – Item 1 of the Updated Schedule of Loss
- Loss of Anticipated Savings – Item 3 of the Updated Schedule of Loss
- R1-D Delay
- R0 Licence Costs – Item 4 of the Updated Schedule of Loss
- R0 Hosting and Infrastructure Costs - Item 5 of the Updated Schedule of Loss
- R0 Technology Refresh – Item 6 of the Updated Schedule of Loss
- R0 N-1 Sustainment Costs – Item 7 of the Updated Schedule of Loss
- R0 Maintenance Costs – Item 8 of the Updated Schedule of Loss
- Savings
- Introduction
- Quality-related Obligations
- Good Industry Practice and Defects
- Digital by Default Standards
- Section 71
- The Basics Portal
- Section 73
- The Barring Portal
- Section 75
- Section 76
- Barring Portal: Loss of productivity - Item 11 of the Updated Schedule of Loss
- LPF Portal
- Siebel Useability Issues
- Redaction
- Document naming, bundle creation and performance
- Adobe Licence (Item 20)
- Document Storage (Item 21)
- Other B1 Barring Quality Issues
- Scan on Demand
- Special Characters
- Letters
- Item 24 : Loss of Efficiency Claims arising out of R1 Barring Quality/Useability Issues
- N-1 Sustainment Costs
- Causation and Loss
- Exit/Service Transfer
- Identification of all services (3.2.2)
- Knowledge Transfer (3.2.6 and 3.2.7)
- Section 95
- Providing all documentation to a replacement contractor (3.2.1 and 3.2.10)
- The identification of all leases, maintenance agreement and support agreements in connection with the provision of the services (3.2.3)
- Providing any other information or assistance reasonably required by a replacement contractor (3.2.14)
- Causation and Loss
- The Security Incidents
- The Charges Variation Dispute 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
- Section 104
- Issue 4: How Clause 2.8.5 of Schedule 2-3 applied to Volume Based Service Charges in Service Year 5
- 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)
- Conclusion on Volume Based Service Charge
- Conclusions