Agile implementations and legacy systems – A pyrrhic victory for the Co-op?

The recent CIS v IBM decision touches on two topical issues in IT disputes: maintenance and replacement of legacy systems, and  use of agile implementation methodologies.  It is also a useful reminder of some important basics regarding the management of troubled IT projects.

The case and the issues

The claimant (Co-op) was the insurance business of the Co-op group. In order to substantially reduce the costs of running its legacy systems, Co-op contracted IBM to design and manage the implementation of a completely new IT infrastructure. The implementation was not a success and, in July 2017, IBM purported to terminate the contract on the basis that it had some £2.9 million of unpaid fees.

The following points are of particular note:

• Co-op alleged that the core software used for the project was held out as being a proven “off the shelf” product that could be used with minimum configuration and development work. Co-op alleged that the system was in fact unsuitable for the UK market without extensive development. IBM alleged that the scoping work it had carried out was appropriate and any suitability issues were unknown to it after proper due diligence.
• The parties selected an agile implementation methodology (i.e. an iterative development methodology where the software is developed, tested and accepted in short development cycles, as opposed to traditional linear or “waterfall” methodologies).
• The project was delayed and Co-op alleged that the work that was performed by IBM’s subcontractor was of poor quality. IBM’s case was that much of the delay was due to Co-op’s failure to properly engage with the agile methodology (for example, its alleged failure to specify its requirements and delays in testing), and that the work performed was adequate.
• Co-op withheld milestone payments on the basis that it was entitled to set-off damages arising from IBM’s earlier breaches of contract against fees due. IBM denied that it was in breach of contract and terminated the contract on the basis of the outstanding invoices. In response, Co-op argued that IBM had terminated wrongfully, putting it in repudiatory breach of contract.

Co-op claimed damages of c. £128 million in respect of its wasted costs of the project including interest payments and expenses surrounding a £70 million bond issue to fund the project. IBM counterclaimed for £2,889,600 in respect of its unpaid invoices.

The judgment

O’Farrell J found that:

Termination

• Co-op had validly challenged IBM’s invoice for the disputed milestone. As such, IBM was not entitled to unilaterally terminate the contract for non-payment of the invoice without following the contract’s escalation process. IBM’s purported termination of the contract was therefore wrongful and constituted a repudiatory breach of contract.
• If Co-op had not correctly challenged the invoice, it would not have been allowed to withhold the sums in issue due to the “pay now, argue later” provisions in the contract, despite its set-off.
• Co-op argued that IBM was in wilful default because it terminated the agreement for commercial reasons, knowing that it was not entitled to do so. However, the court concluded that the breach of contract was not intentional or reckless because IBM honestly (albeit wrongly) believed it was entitled to terminate.

Suitability of the software, delay and fitness for purpose

• The court found that the scoping work undertaken by IBM was broadly appropriate. While there were issues around the suitability of the core software for the UK insurance market, this was now known to IBM and that knowledge could not be imputed to IBM from its subcontractor. However, IBM was responsible for the project delay and shortfalls in the quality of the development and configuration work undertaken.
• A peculiarity of the contractual structure adopted was that IBM’s liability arose from its failure to report any issues regarding the suitability of the software or delay to Co-op. IBM was found not to have breached these obligations, including because it was not aware of the true position (which was only known to IBM’s subcontractor) and/or Co-op would not have acted any differently if it had known the true position as it was committed to the project and would not have terminated it at the material times.

Quantum 

Co-op’s costs of raising a bond to fund the acquisition were, in principle, properly recoverable. However, those costs, together with the remainder of Co-op’s £128 million wasted costs claim, fell within the contractual exclusion for “loss of profit, revenue, savings (including anticipated savings) ... (in all cases whether direct or indirect)”. Despite this, the court allowed the Co-op’s alternative claim for the costs of the implementation of £12,998,390 (after deductions and set-off of IBM’s unpaid fees).

Comment

The case reminds us of some themes that are common to software implementation disputes and raises some interesting new points. In particular:

• Agile implementation methodology: relatively few cases involving agile implementation methodologies have come before the courts thus far. It has been suggested that implementations using agile methodologies are less likely to fail and end up in dispute. For example, the FCA’s recent Multi-Firm Review, Implementing Technology Change, noted:

“Firms that made effective use of agile delivery methodologies were also less likely to experience a change incident.”

However, the authors’ experience is that dysfunctional implementations fail whatever methodology is adopted. In particular, agile implementations require a high degree of user engagement and resourcing and can quickly come unstuck if there is not an appropriate level of engagement and careful control of the customer requirements, or if there are tensions between the customer and supplier teams.

The authors’ view is that the correlation observed by the FCA is more likely to arise because: (1) the participants in the study were inherently more likely to be larger, sophisticated businesses more comfortable with iterative methodologies and better able to deliver successful projects; and (2) the FCA respondents recommended using agile methodologies as part of a programme of incremental changes. This is significant because large enterprise implementations (like the one in this case) will always be more difficult and are arguably less suitable for an agile approach.

• Termination conduct: contract termination is a minefield, not least because the law on termination is complex and highly technical. Further, getting it wrong opens the terminating party up to a claim for wrongful repudiation which can often be much larger than the sums originally in issue. While a case like this shows that even the largest and most sophisticated organisations advised by experienced lawyers can get it wrong, it is essential that parties considering whether to terminate an ongoing implementation take legal advice before doing so (and, indeed, before engaging in any conduct that might be deemed a repudiatory breach, such as refusing further performance).

• Wilful default: many IT contracts contain provisions imposing different limits of liability etc. where the other party is in wilful default. While IBM was not found to be in wilful default, the case is a reminder that a further risk of seeking to terminate an ongoing contract for cause is the argument that the termination was in fact for commercial reasons and so constituted wilful default. It is therefore important that the terminating party genuinely believes that it is entitled to terminate and can demonstrate that (for example, by referring to legal advice).

• Set-off: the case provides helpful confirmation that it is possible to set-off sums due to the customer against payment due to a supplier provided the contract does not include “pay now, argue later” language (or other language preventing set-off).

• Exclusions and limitations of liability: the fact that the customer’s claim was defeated by a well-drafted exclusion clause is a reminder of the importance of getting basics like loss of profits exclusions right. However, it is also worth noting that this was a case where the project was simply abandoned and the Co-op group disposed of its insurance business. Had Co-op elected to replace the system instead, IBM could have been faced with a much more substantial bill.

If you have any comments on this article or would like to discuss any of the issues raised, please do not hesitate to contact Philip Tansley or Matthew MacLachlan.