The recent decision in CIS v IBM is an interesting read for anyone involved in the negotiation or litigation of IT contracts. It’s not often that the parties to an IT dispute choose to take their case all the way to court – the factual complexity where an IT project has gone wrong tends to persuade both sides that settlement out of court is the best way forward – so on the rare occasion a case does make it all the way, it’s fascinating for practitioners to get some insight into how the courts will apply the law to the facts of a failed IT project.
A failed IT project
The background to this case is a fairly classic tale of an IT project gone wrong. CIS appointed IBM to design, build and implement a transformational insurance platform to support the business when it was separated from the wider Co-op Group. Almost immediately after contract signature, timescales started to slip as the build became more complex, the customer failed to fully articulate its requirements (or to stop SMEs from derailing the project by requiring their own bespoke processes be reflected in the new system), more defects than expected were found, testing ran behind and functional scope was moved to later releases to try and salvage the timetable.
Eventually, the contract was terminated over non-payment of a (relatively low value in the context of the overall project) invoice and the parties fell out over who was responsible for the failure.
Some interesting conclusions
The court’s decision in ultimately finding IBM were responsible for the failure contains some interesting, and perhaps surprising, conclusions on areas like:
- when are “wasted costs” actually “profits” ?
- when can you use a due diligence warranty offensively rather than defensively?
- to what extent do you actually need to pay attention to all the procedural requirements in the contract for things like invoicing and supplier relief?
Read more in our DigiLinks blog post.
A timely reminder
Given the increased importance of IT as a result of the Covid-19 pandemic and on companies’ improvement of their legacy IT architecture more broadly, this is a timely reminder for both customers and suppliers of what can go wrong on an IT project and of what parties should look to address in their contracts.
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.
https://www.linklaters.com/en/insights/blogs/digilinks/2021/march/uk---complex-messy-and-interesting
unknownx500
