Bristows' SnippITs - TCS v DBS: Lessons from Major IT Dispute (Part 2)

This post is part of the Bristows’ SnippITs series, which pulls together the key practical takeaways from recent court decisions for the tech sector and beyond.

Systems integrator: Who is responsible for managing third party dependencies?

On 17 May 2024, the Technology and Construction Court handed down its judgment on one of the largest IT disputes in recent years: Tata Consultancy Services Limited v Disclosure and Barring Service. The 243-page judgment (summarised here) provides a relatively rare and detailed insight into the court’s determination on a broad range of issues that often arise when a complex IT project goes wrong.

In this second post of our series considering key issues from the case for suppliers and customers of large-scale IT projects, we consider the role of a systems integrator to manage the complex web of interdependencies in an IT project and the importance of ensuring your contract reflects this.

If you haven’t read our previous post, you can find it here: Part 1: Delays, critical path and “unconscious pacing”.

Key takeaways

1. Dependencies and Risk: Suppliers in complex IT projects should ensure they fully understand interdependencies on their project, who is responsible for the performance of each party and how this risk is allocated. TCS faced difficulties because its performance had been impacted by a third party (HPE) and yet under the contract with DBS, TCS was unable to claim relief for that delay.
2. Duty to Co-operate: Suppliers should not assume they will be able to rely on general duties of cooperation under their contracts in order to keep customers on the hook for the performance of third parties. Although useful to ensure customers play their part in the delivery of the project, it can be difficult to show that a breach of these provisions caused delay.
3. Consistent Terminology: Parties should not underestimate the importance of a consistent approach to contract terminology, especially defined terms. The court in this case spent considerable time considering why the parties had used different but similar terms when defining “Authority Cause” and “Contractor Default” and what, if any, weight should be given to this.
4. Systems Integrator: TCS’s argument that without a systems integrator it was unable to fulfil its contractual responsibilities emphasises how crucial effective systems integration is on IT projects. Contracts should therefore clearly express which party has these responsibilities.

Background

The dispute centred on the modernisation of an IT system by TCS for DBS. The project suffered issues (including significant delays) and TCS brought a claim against DBS for over £110 million in damages. A large proportion of this claim related to delays that TCS said had been caused by failings of Hewlett Packard Enterprises (HPE), the IT hosting provider appointed by DBS. TCS claimed that HPE had failed to provide information on time and had provided inadequate infrastructure.

The effect of the contract was that TCS would only be able to claim for delays that were due to “Authority Cause” (defined as meaning a breach by DBS of any of its “responsibilities”). TCS therefore had to show that the HPE delays fell within this definition.

The following factors were relevant to this:

• HPE only had a contractual relationship with DBS. There were therefore no express obligations on HPE under the TCS/DBS contract.
• There were no express obligations on DBS to procure the performance of HPE.
• The contract did not set out which party was meant to fulfil the role of the systems integrator (the party usually responsible for managing integration activities and inter-dependencies over the lifespan of the project).

TCS’s arguments

TCS raised a number of ways in which it said that the HPE delays amounted to “Authority Cause”:

1. DBS was in breach of its express general duties of cooperation under the contract, including an obligation to “collaborate in an environment of mutual respect and cooperation” and “co-operate in the provision of information necessary for the successful operation and assessment of performance of the Services.”
2. Alternatively, DBS was in breach of an implied term that it would either fulfil the function of systems integrator itself or appoint TCS or a third party as systems integrator. TCS argued that without this term, and in the absence of systems integration activities being timeously performed, it was unable to discharge its responsibilities within the contractual timeframes.
3. Failing this, TCS argued that a breach by DBS of any of its “responsibilities” was not restricted to breaches of contract and extended to all aspects of the project within DBS’s “sphere of responsibility”. Because HPE was DBS’s contractor, and it was only DBS that had the right and power to procure its timely performance, DBS had breached its responsibilities by failing to ensure HPE did not hold up the project.

Decision

The court rejected each of the above arguments:

1. The general obligations on DBS including to collaborate came “nowhere close” to imposing the obligations that TCS said had been breached. For example, TCS had not shown that the delay in information from HPE had been caused by a failure by DBS to co-operate.  
2. The court declined to find an implied term in the contract regarding the systems integrator role. It rejected TCS’s argument that the term was necessary for the business efficacy of the agreement: this was a “sophisticated contract”, there was no room for such an implied term and it would have contradicted other express terms of the contract. 
3. The court considered at length the parties’ use of different language in the contract to explain similar concepts, including “Contractor Default”, “Authority Cause” as well as the undefined uses of “responsibility” and “obligation”.  It concluded that as a matter of ordinary language and unless clearly explained otherwise, “responsibility” was most likely to mean “contractual responsibility”. A fundamental difficulty with TCS’s interpretation was that if “responsibility” did not mean “contractual responsibility” it could not be defined with any certainty. TCS therefore had to show that DBS had been in breach of contract in relation to the HPE delays.

TCS had failed to show that HPE delays were an “Authority Cause”. This meant the entirely of TCS’s delay claim that relied on HPE delays failed.