UK: Complex, messy and interesting – Lessons from the Co-op v IBM dispute

Failed IT projects are not uncommon but parties who are willing to take their dispute all the way to court are. This is largely because unpicking what happened is a messy and painstaking process – the costs can be substantial and the outcome uncertain.

This makes the dispute over the failed implementation of a new IT system in CIS General Insurance v IBM [2021] EWHC 347 something of a rarity. The 175-page judgment rewards the reader with a forensic analysis of what went wrong, the details of some novel contractual claims and a number of interesting points of law. The key points are summarised below.

Covid-19 has brought a renewed focus on companies’ IT systems, with a number of companies having to expedite updates to their existing technology to facilitate the new remote way of working. This case is, therefore, a timely reminder of the potential pitfalls with IT transformation projects and the issues which both customers and suppliers should have at the forefront of their minds when embarking on a new project.

The background to a failed IT project

The origin of the dispute was Co-op’s plan to move to a new IT solution to handle its insurance business. In June 2015, it entered into a contract with IBM to deliver that system by December 2017 (the “Agreement”). This was a substantial project – the cost of delivering the new system was £50.2 million with a further £125.6 million for managing the system over the next 10 years.

The solution was based on a third-party insurance platform known as “Insurer Suite” created by the Innovation Group. IBM engaged the Innovation Group as a subcontractor to modify the “Insurer Suite” to be suitable for Co-op’s requirements.

The project used an Agile methodology based on a series of short sprints. O’Farrell J dryly notes these “were not a success” and “were slow and chaotic, rather than agile”. Use of Agile methodology should be considered carefully by customers; it can seem a good idea on paper but require a certain level of IT expertise and control of SMEs on the customer side in order to be successful.

As a measure of how far off beam the project went, from the start of the second phase of user acceptance testing in October 2016 until termination, 1,784 defects were recorded, of which 116 were severity one, 432 severity two, 1,052 were severity three and 184 were severity four. A single defect in either category one or two being sufficient to fail user acceptance testing.

IBM attempted to terminate the agreement in July 2017 after Co-op refused to pay one of its invoices. Co-op claimed the attempted termination was a repudiatory breach by IBM and brought a series of claims against IBM. Co-op’s primary claim was for £128 million in wasted costs.

IBM caught between a rock and a hard place

A key problem when litigating many IT projects is establishing who is at fault. While the contract will normally fix the supplier with a range of obligations to deliver the new system; success is also dependent on the customer’s participation and co-operation. The complexity and dependencies in the relationship between the customer and supplier means that when things go wrong, both will likely try and pin the blame on the other and the facts will rarely give a clear picture of who was responsible.

However, in this case IBM found itself caught between the failures of its subcontractor and its own failure to use the relief mechanism in the Agreement.

On the first flank, IBM themselves identified numerous problems with their subcontractor, the Innovation Group. IBM served two breach notices on the Innovation Group in September 2016 and February 2017 describing the code they developed as “very poor”, that the use of FOSS in the product created “legal and security risks” and the system testing was also “very poor [and] significantly below industry standard [as] demonstrated by the high number of defects”. IBM might not be morally responsible for those failings, but the Innovation Group was IBM’s subcontractor and under the Agreement, IBM was contractually liable for their performance.

On the other flank, the Agreement contained a provision allowing IBM to obtain relief where the underlying problem was the fault of the Co-op. However, to obtain relief IBM had to promptly serve a relief notice on Co-op identifying that failure. No relief notices were sent.

As a result, even if Co-op’s failure had contributed to IBM’s failure to complete the project milestones, IBM could not obtain any relief. O’Farrell J concluded it was not possible to imply a term to that effect as it would contradict the express relief clause. The Agreement contained a “complete code” for supplier relief.

Rejected invoices, missing PO numbers and a disputed termination

Things came to a head when IBM issued an invoice for milestone AG5 (IMP-30). While described as a milestone payment, in reality it was a delayed invoice for software licensed under the Agreement, the cost of which had been spread across the term rather than being paid up front, and therefore not tied to wider progress with the project.

Despite this, Co-op refused to provide a purchase order number and disputed the invoice when it was submitted. In response, IBM purported to exercise its rights under the Agreement to terminate for non-payment. Co-op retaliated by claiming IBM’s termination notice was a repudiatory breach, which it accepted. In other words, the Agreement had come to an end but the question was who was at fault. This turned first on whether the invoice submitted by IBM was valid. O’Farrell J concluded the invoice was valid:

• While the Agreement stated the invoice must contain a purchase order number (which it did not) Co-op had wrongfully withheld the purchase order number and could not rely on its own breach to escape their obligations (Alghussein v Eton College [1988] 1 WLR 587).
• The invoice incorrectly referred to “IMP-20 Application Gate 5” (not IMP-30). However, this was a “minor clerical error” and it was clear the invoice related to AG5 (not least because Co-op had already paid for the “IMP-20” work). Accordingly, this did not affect the validity of the invoice.
• Co-op raised various arguments that the invoice was sent without supporting documents and should have also been sent in hard copy as required by the Agreement. These contentions were rejected by the judge as no supporting documentation was needed and the parties had agreed hard copies would not be necessary.

However, Co-op had the right to dispute an invoice in good faith. It rejected the invoice three days after delivery because it didn’t contain a purchase order number. Despite this being due to Co-op wrongfully withholding that number, the court concluded Co-op had believed it was entitled to withhold the purchase order number and so had validly disputed the invoice in accordance with its obligation to act in good faith: “it was a position that was not so unreasonable that it amounted to bad faith”. This suggests a pretty low bar for good faith, though given the complex background and ongoing problems with the project, the court concluded Co-op disputed the invoice because it genuinely considered that IBM was not entitled to payment.

As Co-op had successful disputed the invoice for milestone AG5, IBM’s attempt to terminate for non-payment was a repudiatory breach of contract.

As a side note, O’Farrell J noted that the use of non-payment of the AG5 invoice to terminate the full contract was a “high-risk strategy” given it was for “a modest sum in relation to the high value of the overall project”. This is likely indicative of how difficult it can be to establish a termination right for either party in a factually complex IT dispute, even one as far off track as this, especially if the only termination right is for material breach. Parties to IT contracts would do well to give serious thought to the circumstances in which they would want to be able to walk away from the contract, to try and avoid the significant risks which can be associated with asserting material breach.

Weaponising due diligence and warning clauses

Alongside the claim for repudiatory breach of contract, Co-op advanced a number of interesting contractual claims against IBM.

These included a claim that IBM was in breach of its obligation to use “all reasonable steps… that it has satisfied itself as to all risk, contingencies and circumstances to do with its performance of the Agreement”. In particular, Co-op alleged that IBM had not identified that the base product, Insurer Suite, would require significant base code development to be suitable for Co-op’s needs.

While this claim failed on the facts – because IBM had taken reasonable steps to ascertain the risks of the project and had not mispresented the scope of development required – it is interesting to see this type of clause being used for offensive purposes and not simply as a means to stop IBM claiming the work was more complex than expected or to defend a claim by IBM that it has been misled as to the scope of the project. The case brings into stark focus the need to be clear about the parties’ expectations regarding the amount of development necessary to deliver the customer’s requirements, as well as the importance of ensuring SMEs are bought into the business changes which the project will entail, to avoid the project being “de-railed by SMEs seeking to include bespoke changes to the… product to meet their preferred method of operation”.

Similarly, Co-op claimed that IBM was in breach of its obligations to notify Co-op “when it becomes aware of any development which may have a material impact on [IBM’s] ability to provide the services effectively”. Co-op claimed that had IBM informed it of the significant base code amendment needed to Insurer Suite, it would have terminated the Agreement.

This claim also failed on the facts. Not only did the Court find that Insurer Suite did not need substantial rewriting but even if IBM had notified Co-op of that fact, Co-op would not have terminated during the relevant period. Interestingly, IBM were not deemed to have all the knowledge of their subcontractor and would only have been required to notify Co-op of facts actually within IBM’s, not IG’s, knowledge. Customers should keep this in mind on projects where a significant portion of the work is subcontracted.

A side note on “all reasonable endeavours”

The judgment also weighs in on the chimera “all reasonable endeavours” – a term that has attracted controversy over the years, particularly on the question of whether it means the same as best endeavours.

O’Farrell J concluded “I do not accept that an obligation to use ‘all reasonable endeavours’ is necessarily the same as an obligation to use ‘best endeavours’, although in many cases there may be no discernible difference in practice”. In other words, while is some cases the terms may be factually the same, legally they are not.

While “an obligation to use best endeavours is likely to encompass all reasonable steps that could be taken, it might extend to more than an accumulation of moderate or sensible steps. It is conceivable that the circumstances of a particular case could require the party with such an obligation to go further, such as taking steps that were against his own financial interests, or steps that required extraordinary efforts”.

Exclusions of economic losses and wasted costs claims

While not all of Co-op’s claims against IBM succeeded, it had shown IBM repudiated the contract by wrongfully attempting to terminate for Co-op’s non-payment of milestone invoice AG5.

The primary claim for that repudiation was for £128 million of Co-op’s wasted costs on the abandoned project. The question for the court was whether this was subject to the following exclusion of:

“indirect or consequential Losses, or for loss of profit, revenue, savings (including anticipated savings), data …, goodwill, reputation (in all cases whether direct or indirect)”

O’Farrell J decided this claim was excluded. The “conventional claim for damages in this type of commercial case would usually be quantified based on those lost savings, revenues and profits. [Coop] is entitled to frame its claim as one for wasted expenditure but 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”.

This is a somewhat surprising conclusion as previous judgments have tended to limit this type of exclusion clause to loss of future profits and business, and not the immediate costs of clearing up the mess. For example, similar claims were not excluded by the type of clause set out above in Royal Devon and Exeter NHS Trust v ATOS [2017] EWHC 2197, though O’Farrell J distinguished that case on the basis that NHS Trusts do not conduct profit making activities. It is also surprising given O’Farrell J’s later conclusion that certain costs incurred by Co-op as a result of IBM’s delay were recoverable, without explaining why these costs (which appear, on the face of it, to form part of the overall £128m) were not to be considered “profit” and therefore excluded with the rest of the wasted costs. In practice, her conclusion appears to be that Co-op could not recover by way of wasted costs more profit than they would have had the contract been properly performed, but given the exclusion clause prevented recovery of any profit then it is difficult to see how she reached this conclusion.

It is also worth noting that as a result of the failure of this project, Co-op abandoned the attempt to develop a new IT system altogether and sold off its insurance business. Had Co-op instead tried to build a replacement system, the cost of that replacement system might well not be excluded. Co-op’s secondary claim for additional costs incurred in supporting the project as a result of IBM’s breaches did succeed and it was awarded £15.9 million in damages, set off against the £2.9 million Co-op owed IBM for the unpaid invoice for milestone AG5.

Conclusions

This case took nearly three years to get to court, the parties spent two months in court and the judgment took around a year to hand down. It is not clear what each parties’ costs are, but they may well be much greater than the amounts recovered. At the same time, it is not an unusual set of facts where IT projects fail and highlights how messy and complicated they can become. The judgment gives those involved in IT projects some useful reminders of the areas they should ensure their contract addresses, but will also likely result in negotiation of supplier relief and deemed direct loss clauses becoming more contentious. Failed IT projects are still likely to result in unhappy customers and suppliers playing ‘litigation chicken’, but there is little in this judgment to discourage them from a sensible and early settlement.

By Lindsey Brown