TCS v DBS – Quickfire contracting tips for commercial lawyers

Digital transformation projects often carry a high level of risk, with much scope to go wrong. Several high-profile issues organisations have faced with key digital suppliers in recent months (such as the AT&T v Broadcom dispute – blog available here - and the CrowdStrike global outage) act as useful reminders of the importance of getting tech procurements right. 

It is still relatively unusual for these issues to make it to the courts – but when they do, there are some useful lessons we can all learn. Earlier this year, the case of Tata Consultancy Services Ltd v Disclosure and Barring Service [2024] EWHC 1185 (TCC) - a mammoth 242-page judgment covering a wide range of issues in a digital transformation contract – was heard in the UK courts. 

In this blog we focus on the lessons we can take from it in relation to: (1) notice provisions and conditions precedent; (2) estoppel; (3) responsibility for third parties; (4) responsibility for delays,  (5) partial termination; and (6) incorporating documentation into the contract. The case also provides useful guidance on liability caps, although we have produced a separate blog post on this – available here.

Background:

In 2012, DBS retained TCS to assume control of its manually intensive Disclosure and Barring processes from its incumbent provider and to build a new IT system to modernise and digitise this paper-based process. This digital transformation did not go to plan, and suffered significant delays. 

When the contract expired in 2020, TCS claimed damages of around £110m, with DBS counterclaiming for losses of a similar amount. TCS cited DBS’s mismanagement of its IT hosting provider Hewlett Packard Enterprises (HPE) and DBS’s strategic decision to abandon part of the project as reasons for the delays. DBS counterclaimed, attributing the delays to TCS's software development and testing failures. 

After the claims and counterclaims, the court held that DBS must pay TCS £4.8 million in damages (albeit that both parties were awarded some damages and much of TCS’s award relates to the underpayment of volume-based service charges, that are not relevant to the issues discussed here). 

Issues from the case:

(1) - Notice Provisions and Conditions Precedent 

• Issue: The contract required TCS to notify DBS of delays to milestones (and submit an Exception Report within 5 working days of that initial notice) to claim compensation for delays. TCS did not serve the Exception Report on time. The question arose as to whether this was a condition precedent. 
• Findings: The conditions precedent in the contract were clearly defined and enforceable. This was a condition precedent and TCS had not satisfied the conditions, thereby affecting its entitlement to claim for certain performance obligations. However, this was affected by “estoppel by convention” – see issue 2. 
• Lessons
  • Provisions requiring notice can be conditions precedent.
  • The absence of the phrase “condition precedent” or an explicit warning as to the consequences of “non-compliance” is not determinative when construing a condition precedent.  

(2) - Estoppel by Convention 

• Issue: TCS argued that DBS was estopped from enforcing its condition precedent requiring TCS to file an Exception Report because there was a “common assumption” that this requirement no longer applied (and if both parties act on a shared assumption, neither can later deny that assumption).
• Findings: The court agreed that DBS was estopped finding in favour of TCS. The parties' conduct in the negotiations showed they jointly assumed this requirement had “fallen by the wayside” and that TCS had a “de facto” extension to file the Exception Report.
• Lessons: 
  • If a contractual counterparty misses an important deadline or contractual requirement, and there is a risk you may wish to claim in the future, always reserve your position to prevent estoppel by convention and consider expressly enforcing your rights under the contract. 
  • Explicitly refer to contractual provisions (such as the need for notice, escalation, or remediation) when communicating with a counterparty to reduce the risk those communications are insufficiently clear.  

(3) - Responsibility for third parties

• Issue: TCS argued that failures by DBS’s IT hosting provider (HPE) caused problems/delays with the project and that: 
  • DBS had provided general assurances of cooperation in systems integration services, which were to be performed by HPE. This amounted to a warranty of HPE’s performance of those services for TCS’s benefit; 
  • There was an implied term that DBS agreed to provide system integration activities (which it had breached when HPE failed to deliver); and 
  • the failures of HPE were essentially failures of DBS (within the meaning of “Authority Causes” in the contract). 
• Findings: The court rejected the existence of a warranty or implied term and rejected that DBS was generally responsible for HPE’s failures under the contract unless a problem/delay arose from a specific failure of HPE to provide something that DBS was contractually responsible for providing to TCS.  
• Lessons: 
  • As a customer, carefully consider providing dependencies in a contract where you rely on a third party for the success of a project, and it is not in your gift to ensure the third party delivers.
  • The responsibilities of a systems integrator will not necessarily be added to those of a service integrator, prime contractor or employer as a matter of implication. Clear wording is needed to incorporate these responsibilities if that is what has been agreed.

(4) - Delays 

• Issue: The contract included various milestones and deadlines to complete steps for the digital transformation, but each party argued the other was responsible for the delays.  
• Findings: The court held that the delays were primarily attributable to TCS’s performance issues. TCS failed to provide adequate resources and management, leading to significant project delays. This restricted TCS entitlement to relief for most of the project. 
• Lesson: During a contract's life, suppliers should ensure that they clearly communicate with their customers when delivery is going to be delayed, and why and how the issue is being resolved. Customers should also require this in the contract. 

(5) - Partial Termination 

• Issue: DBS had sought to partially terminate the contract, and the court examined the validity/implications of this partial termination. 
• Findings: The court held that DBS’s notice of partial termination was invalid due to the failure to follow the proper procedure and engage with the “remedial plan process”. As a result, TCS was awarded damages of £1.3 million for the de-scoped work due to wrongful termination.
• Lesson: Termination can be very difficult to get right. When a material breach clause references a “breach incapable of remedy” or a “remedial plan process” for the parties to follow when terminating for material breach, such processes must be closely followed to demonstrate to the court that termination was valid/lawful. 

(6) - Incorporating documentation into the contract 

• Issue: The contract required TCS to comply with agreed standards, which were incorporated via a clause in the contract and referred to a “standards catalogue”, which needed to be agreed between the parties. These standards included the Government’s Digital Service Standard, which emphasised the use of ‘agile’ methods. However, the rest of the contract envisaged a “modified waterfall” approach to development, integrating some agile development features, but predominantly following a waterfall development methodology. 
• Findings: The court found that the “standards catalogue” did not make clear that TCS was obliged to follow the Digital Service Standard, as it was not stated as a “requirement” and including it would have cut across the whole modified waterfall approach that the parties had agreed in the contract.
• Lesson: If you are a customer that wants to incorporate internal principles, policies, rules of engagement, codes of conduct, ethics/sustainability rules, risk management policies and procurement terms into the contract, ensure they are relevant to the contract and work with its other terms, are clearly defined and explicitly incorporated, and that there is a clear mechanism to update them.