Systems Integration Contracts: Co-op v IBM

Systems integration contracts govern the relationship between the parties involved in an IT implementation project. Such a contract can make for a complicated relationship and a messy dispute, as seen in CIS General Insurance v IBM [2021] EWHC 347. Few of these kinds of projects ever see their day in court, arguably due to inherent complexities and the expense of their unpicking. This case concerned the implementation by IBM of a new IT solution for Co-op’s insurance business. The agreement was supposed to deliver the system by December 2017 and used an Agile methodology (read our blog).

Success with system integration contracts often relies upon customer co-operation and participation as much as the supplier’s delivery. The simple question of defining what a customer wants from the outset can be a challenge when creating bespoke software. A number of alternative contractual and management solutions (Agile for example) have developed in an attempt to match this complexity. In short, systems integration contracts need to be meticulously thought through and understood. IBM’s failure to use relief mechanisms under its agreement with Co-op left them with few legs to stand on when their subcontractor failed to deliver, leading to an award of £15.8 million in damages to Co-op.

Customer’s requirements

In systems integration contracts, the purpose of a customer’s requirements section is to set out clearly and comprehensively all the functionality that the customer requires from the system. This is about letting the supplier know exactly what the project needs to achieve – which can be difficult and so customers often seek help from third parties. Consultants can be used to investigate the various interest groups within the customer’s company to discern exactly what is needed and then to write up the requirement’s document for the customer. Consultants can then also be instructed to undertake market research with a view to suggesting potential suppliers.

Specification

Once a customer’s requirements are known, it is then the supplier’s job to specify exactly how those requirement’s will be achieved. This means a more technical outlining often called a ‘specification’. The customer’s requirements therefore represent the customer’s interests and the specification represents the supplier’s abilities. This opens up a spectrum of ways for the two parties to contract. Firstly, a customer could agree that it doesn’t care how their requirements are achieved so long as they are achieved. Secondly, a customer could agree to accept a product that fulfils all the obligations a supplier sets for itself in a specification. And thirdly some kind of balance between the two which gives the supplier an assurance that certain specifications will be accepted by a customer, but also the customer confidence that their requirements will be met. The third option is likely to be the most desired, but also the more difficult to communicate in a contract. This is why various alternative approaches have emerged, such as Agile, with a view to making software development more co-operative. However, as seen in CIS v IBM, the Agile Alliance’s manifesto principle ‘customer cooperation over contract negotiation’ proved ineffective when IBM was held to be responsible for critical delays to this very large ‘Agile at scale’ project.

Timetables

Timetables give suppliers the opportunity to outbid other potential suppliers at the tender stage – pushing down their delivery time to the greatest possible extent. It is no wonder, therefore, that IT projects are notorious for exceeding their original contractual timetables. This can be the result of a number of factors. And not just the result of overly aggressive bidding. It could be due to customer changes or faults made by the supplier. This is all tied together by the fact that timetables are usually unrealistic at the outset.

It should therefore be in both parties’ interests to try and be as realistic as possible when it comes to timetabling in systems integration contracts. It can also be useful to introduce phase-level assessments which mean that customers have to accept early stages of development before moving on to later ones. This is where a third party consultant or project manager can come in handy – someone who can introduce a stronger notion of objectivity.

Intellectual property rights

Ownership in or licensing of intellectual property rights in the software being supplied are a fundamental consideration in software projects and must be addressed in systems integration contracts. It may seem logical that the creation of software for a customer should lead to the intellectual property rights of that software being transferred to the customer, when such projects are finalised. However, the current trend is towards the granting of licences to customers. This is because the bespoke software developed on the project will often include modules which the supplier has already created and may even be licencing to other customers. If the licence rights are wide enough and the customer’s use of the software is for its own internal operations then in practice it shouldn’t matter whether the software is owned or licensed by the customer as far as the customer’s use of the software is concerned. However, what if the customer is undertaking the project in order to give it some competitive advantage? This advantage  would be undermined if a supplier was able to licence the new software to competitors.

Another consideration is that, given the extensive involvement of customers in such projects, it can often be the case that key ideas underpinning the development of the software have the potential to come from the customer – what rights should the customer receive (if any) as a result of its input into the development of the software?

Acceptance

It is common practice to include acceptance testing clauses in systems integration contracts. Without such provisions there is greater scope for debate between the parties around whether the supplier has created software that does what it is supposed to. A failure of acceptance tests usually gives rise to an obligation for the supplier to fix the software and re-submit it for testing. If the product continues to fail, this usually gives customers the option to:

• Ask for the product to be fixed and tested again.
• Accept the system with its faults, but with a reduction in price.
• Introduce a third party to carry out the work.
• Terminate the contract.

CIS General Insurance v IBM

This recent case is a compelling warning of how systems integration contracts can go awry. 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 level one, 432 severity level two, 1,052 severity level three and 184 severity level four. With a defect in severity level one or two constituting a failed acceptance test. This put IBM in a sticky situation. Not helped by their failure to obtain relief for certain problems when they were attributable, in part, to the customer (Co-op). This was because IBM needed to promptly serve notice of such customer caused problems, which it failed to do.

The case ended up taking nearly three years to get to court with the parties then spending two months in court and a judgement taking a year to be finally produced. IBM were deemed to have successfully excluded liability for “indirect or consequential losses, or for loss of profit, revenue, savings (including anticipated savings), data, goodwill, reputation (in all cases whether direct or indirect” and so Co-op’s primary claim for £128 million of wasted costs on the abandoned project was dismissed. Co-op was successful in its secondary claim for additional costs incurred in supporting the project as a result of IBM’s breaches and was awarded £15.9 million in damages set off by a £2.9 million counterclaim against Co-op resulting from an unpaid invoice.

Final observations

It can easily be argued that the failings of IBM to ensure its subcontractor delivered was the main cause of their downfall. But that doesn’t make this case a simple question of a supplier failing to supply. The nature of the agreement, being a systems integration contract, meant that Co-op (the customer), had obligations to ensure the system delivered all it needed. When Co-op failed to correctly co-operate, IBM (the supplier) failed to serve notice to claim against such customer failings, leaving them with nothing more than a defect ridden piece of software and a set of customer caused problems which they had failed to properly address. Systems integration contracts needs to be thoroughly understood before such projects go ahead. Otherwise you could find yourself in a similarly sticky situation.

EM law specialises in technology law. Get in touch if you need advice on systems integration contracts or other technology law matters.