To register your interest and find out more about our Procurement Bill webinar series, please click here.

What can the public sector learn from CISGIL v IBM? Part Two – The Practical Lessons

Share this

In our first article we considered the legal lessons to be learned by the public sector from the failed transformational IT project considered by the High Court in the CISGIL v IBM case.  The focus of our analysis was on the terms of the agreement between CISGIL and IBM signed in May 2015 and the legal consequences of IBM’s ultimate decision to terminate that agreement in July 2017.

In this second article we look at why the project might have failed.  Although we can only form a view based on the Court’s judgment (as is to be expected in a case like this, the parties and their expert have highly conflicting views as to the reasons for its failure), there are nonetheless important lessons to be learned by public sector customers (and suppliers) about how they award and manage transformational projects.

How and when the project failed

To understand why the project failed let’s first look briefly at what happened.   If readers want a longer account they should look to the judgment itself here.

The path to contract

  • Early 2014  CISGIL Board decides to re-platform its entire business onto a new technology platform
  • June 2014   CISGIL commences an RFP process
  • July – August 2014  IBM and Insurer Group respond together to the RFP process. IBM is the lead bidder/prime contractor
  • September 2014  IBM proposal is ranked first out of four bidders and the CEO’s recommendation to proceed with IBM is accepted by the Board
  • October – December 2014  Due diligence by both parties to ensure IBM and IG understood CISGIL’s requirements. Although CISGIL had low confidence in IBM’s leadership, it had confidence in IG’s strong insurance and systems knowledge
  • January – May 2015   CISGIL and IBM sign an Interim Services Agreement. They jointly produce a fit-gap analysis mapping CISGIL’s 551 requirements onto the base product.  Where requirements could be met OOTB (out of the box) the spreadsheet identified whether the base software required configuration or customisation of existing source code or base development (which would entail changing the base product to meet CISGIL’s needs but also the needs of all IG’s clients)
  • June 2015   CISGIL and IBM enter into a Master Services Agreement, and, under it, an Implementation Statement of Work (taking the project up to completion of the Implementation phase) and a Managed Services SOW. The overall value of the project was approx. £180m, split as to one third on implementation and the balance on support over a ten year period.  The MSA incorporated the fit-gap analysis (which played an important role in the subsequent litigation).

The path to failure

What followed is a sorry tale which will be familiar to many who have worked on public sector projects.

The contract envisaged broadly that the requirements would be delivered in two main releases.  Release 1 comprised delivery of the sales and service system for home insurance products by the end of April 2016.  Release 2 comprised delivery of sales and service system for motor insurance products by 15 August 2016.  Historic customer data held on the existing system (COM) would be migrated to the new system (NOM) after each release.  Home data would be transferred under Release 1.5 by the end of July 2016.  Motor data would be transferred under Release 2.5 by the end of October 2016.

Both Releases were to be based on the Insurer Suite product of IG.  However, as the fit-gap analysis referred to above made clear there was still a fair amount of code build and customisation to be done, which certainly had not been the original intention and imported significant risk, which was eventually to materialise.

Ironically, and as an aside, a project with a significant degree of code build and customisation would be unlikely to get the go-ahead now in the public sector, given the strong policy drive from Government Digital Service to use configurable off the shelf products even for sophisticated technology needs.

The project was to be delivered through agile.  There were six sprints in Release 1 and soon it was going badly, the sprint workshops having started in September 2015 (3 months after contract signature).  By December 2015 the parties had agreed a revised plan to split up Release 1 and milestones with the possible contingency of another month for delivery of the whole of Release 1.

IBM then delayed on submission of the revised drops and by March 2016 it was clear that even the May 2016 contingency date for full Release 1 would be missed.  The Release was to be further split up.  Even though system integration testing by IBM was proceeding badly, CISGIL decided to proceed with User Acceptance Testing – this went even more badly and was halted in April 2016.

Thereafter things went downhill.  Relationships deteriorated, key figures left, breach notices were issued (including by IBM on IG, as to which more will follow) all whilst the parties tried to negotiate a commercial deal.

In the background, work continued on Release 1 which re-entered SIT in October 2016.  Once again CISGIL decided to commence UAT (even though its own entry criteria had not been met), but did not proceed beyond the first cycle of UAT.  Negotiations to re-set Releases 1 and 2 and the contract failed.

By March 2017 IBM was predicting a go live for Release 1 of April 2017 (i.e. a year late) and for Release 2 of April 2018 (i.e. 20 months late).  By termination this date for Release 2 had slipped back even further to September 2018.  At CISGIL the project was posing risks to the business and CISGIL was questioning the value now of the ten year deal with IBM.

In March 2017, IBM submitted its invoice for Application Gateway 5 (see our first article).  In April 2017, while there was some suggestion that the parties might enter into the dispute resolution procedure, though they did not in fact do so and in July 2017 IBM gave notice to terminate the MSA on the grounds of non-payment of the invoice.  The CISGIL CEO and the IBM account lead spoke, but the sense of resignation of both parties is apparent from the Court account.

Why the project failed and lessons to be learned

Doomed to fail?

Public sector projects often fail because of the choices that are made before or during procurement.  Packaging decisions (aggregation vs disaggregation), routes to market and award criteria (price vs quality) are classic constraints that often mean that an awarded contract or set of contracts may be doomed to fail even before the first work has started.

On the face of it that would not seem to the be the case here.  IBM was apparently the clear winner in the RFP process run by CISGIL.  What is more, CISGIL, obviously unconstrained by PCR, was afforded the luxury of an extensive pre-award due diligence phase during which both parties satisfied themselves as to the extent of work required to modify IG’s Insurer Suite base product to the UK market and to meet CISGIL’s requirements.

In the proceedings the Court rejected CISGIL’s case that the base product was developed for the US market and that the level of development required to localise it for the UK market/CISGIL was significantly greater than expected.  This was an important part of CISGIL’s case as it asserted that IBM had not done sufficient due diligence on the IG base product.  Instead, the Court found that the level of development required broadly corresponded to the fit-gap analysis agreed by all three parties.

So the problem was not so much the base product as such and, according to the Court, the size and nature of the task had been well understood by both parties at the outset.

If that was not the problem, what was it?

One problem may have been that of ‘mission’ for IG.  The model for many software vendors is that they provide a customisable modular software solution and develop a product roadmap to meet the needs of their (often) global customer base.  At all times the vendor is in charge of the product development.

In this case IG undertook the challenge of adapting and developing its own base code to meet the needs of the UK market and CISGIL.  This may have led to confusion of mission and contention of resource.  Certainly it seems to be what broke IBM and IG; the scenario smacks of the problems faced by the NHS Connecting for Health Programme which tried unsuccessfully to harness the talent of global system integrators with US and UK EPR software vendors.

Another possibility is that the problem was more about the relationship between the parties.  It is not clear if IBM had a track record of working with IG and it would seem that the IBM-IG subcontract was only put in place once the contract was awarded by CISGIL to IBM.

To be fair this is not of itself unusual, but the outcome of the case illustrates some of the strengths and weaknesses of the prime contractor model.

From a purely legal point of view this might be said to have worked out well for CISGIL.  The Court attributed the delays to Release 1 to lack of resource on the part of IG and to its poor working practices; despite this, IBM was clearly accountable for the performance if its subcontractor.

From a delivery standpoint, though, CISGIL’s (and IBM’s) lack of visibility of the underlying issues with the development of the IG product for CISGIL meant it was poorly placed to manage the problem.  This was an evident frustration to CISGIL which felt it was being cut out of a tripartite dialogue with IG.

Our experience on public sector projects is that structural supply chain weaknesses are a recurring source of project failure.

What can be done? There is no easy answer.  A contracting authority will always look to a system integrator – even if it has a direct relationship with a software vendor.   It will also be wary of intervening in its contractor’s supply chain, and this will equally be anathema to the contractor.

However, the first thing a contracting authority should do is recognise the risk.  Too often a PQQ process and a prime contract are deemed to be enough, yet this case illustrates this is not so and that the project risk register should have supply chain risk in its top 5 issues.  With this in mind, public sector customers should consider supply chain due diligence prior to contract award and should look at enhanced governance and reporting involving key subcontractors.  They should look at strengthening the oversight obligations of the SI, in this case the Court surprisingly found that IBM was not deemed to have the knowledge of IG.  It is clear that IG was taking decision as to the development of the base product (for example copying the base code as opposed to creating customer specific extensions) of which IBM was unaware and which made its technical challenge of turning the project around, once it was failing, that much greater.

Finally a contracting authority should understand the commercial terms of the subcontract.  If things go wrong, will the subcontractor be motivated to fix them? In this case a cause of the problem was lack of resource from IG; it is simply not clear whether there was a commercial imperative or constraint getting in the way of throwing resource at the problem.

In this case (and again redolent of the NHS case) a core problem was apparently the quality of offshored development and system testing by IG.  For a collaborative project like this, there is much to be said for co-located working and/or on the ground oversight of development effort.

Avoiding project failure and successful turnarounds

The reasons given by the Court for the delay to Release 1 were:

  • The project did not fail because the base product required redevelopment and re-configuration beyond that envisaged in the contract. In other words everyone went in with their eyes open.
  • Rather the cause of delay and failure was IG’s failure properly to resource the effort required for Release 1 and the poor quality of the programming work done by IG.

As is common in such situations delay in Release 1 had a knock-on/domino effect on the work on Release 2.  IG had insufficient resource to manage and perform Release 2 in parallel with Release 1.  To make matters worse (and a good example of the bind IG found itself in of trying to manage its core product and create a custom product for CISGIL), IG implemented Release 2 on a different version of Insurer Suite (Release 7.6) to Release 1 which meant that substantial extra work was required to retro-fit fixes from Release 1 into Release 2.

Veterans of Government projects will recognise all the symptoms of a failing project, yet often in a failing Government project, the parties agree to swallow pride and cost and re-set the project rather than cancel it.  Terminating a business-critical project is always a last resort and, in a Government context, the combination of (re)procurement timescales and the reputational and scrutiny issues often drive projects to limp on, even if the business case is impaired.

So, if the CISGIL project was not doomed to fail (see above – on the evidence IBM did not think the project was bound to fail until very late in the day) why did it? Why did IBM and CISGIL not turn it around?  What lessons can be learned for similar public sector projects?

Some clues are given by the case.

The first and probably critical factor is that of trust.  The case recounts a senior meeting in April 2016[1] (only 10 months after signature of the MSA) which led to a complete breakdown of trust and was, in the Court’s words, a turning point in the relationship between the two parties.  Unhelpfully there were no contemporaneous notes of the meeting, which of itself is a significant learning point.  Importantly CISGIL came away from the meeting with a belief as to the release path for Release 2 which was contradicted the following day.  Whilst that is not IBM’s recollection of events, the impact on trust and confidence was accepted by the Court.

In our experience of Government projects, when there is delay or project failure, trust evaporates quite fast and both parties see the worst in each other, regardless of reality.  If a project is to be turned around each party must have a conscious strategy of re-building trust at every level, from CEO peer-to-peer downwards.  This may involve swapping out personnel on both sides, either for competence reasons or because the teams on the ground have lost objectivity.

A second factor in the CISGIL case may have been time.  Too many public sector projects set overambitious deadlines for delivery, perhaps driven by Ministerial targets, with little contingency.  After an exhausting award process, momentum is lost and the euphoria of contract award evaporates in the harsh reality of mobilisation, design, build and transition.  If the parties are fortunate, there is at some stage, and usually after a significant dip in trust, a re-set of contract and relations (see above).

CISGIL was not blessed with a soft deadline.  It had a business and regulatory imperative to move onto the IG platform that left it increasingly less wriggle room to accommodate IBM and IG as the project slipped and slipped.

Those of us who have worked on Government projects will recognise the sense of slow car crash that emanates from the account of the CISGIL case.  Government projects take too long to turnaround – but they will be allowed to take as long as it takes in some, but not all, cases.

For Government projects the (perhaps unwelcome) lesson is to build in a contingency, and to encourage this during the tendering process, and also to recognise that the 100/365 day period following contract award is most likely the highest risk period for the project.  Rather than throwing the problem over the wall to the (un)lucky supplier, contracting authorities need to prime their PMOs, design authorities and intelligent customer functions for activity from Day 1.

A third factor in the CISGIL case may have been space.  As 2016 proceeded CISGIL, IBM and IG all sought to protect their positions under their respective contracts.  Notably, the dispute resolution procedure under the IBM CISGIL contract was not engaged until just before the contract was terminated in the following year.  This is entirely understandable, but the question is whether such an approach can ever solve the problem or whether it simply preserves a legal position.  It is not clear from the account at least that they ever created an environment where there was space to get to the bottom of the problem and find a solution.

In our experience of Government projects, it is sometimes useful to call a halt and to introduce a ‘standstill period’ when all parties agree to a ceasefire, so that, building on trust, they can concentrate on problem solving and find a safe space for commercial negotiations.

If there is trust, appetite and space there is always hope.  To make the most of that hope, a number of things need to come into play.  First, there must be a collective reset of expectations for the project outcome.  Secondly, both customer and supplier must have confidence that the other is committed to that outcome, and capable of delivering it.

The most important element may also be the most elusive – and that is there has to be an acceptable commercial outcome for all parties.

Where a project is failing each party will have unbudgeted accrued costs and will likely be forecasting further unbudgeted costs to achieve the project outcome.  The supplier may be facing a double whammy of reduced revenue (as a result of delay) and increased cost.  Descoping, contract extension and cost sharing with the authority will all be ways for the supplier to hang onto the deal it has booked and announced to shareholders.  Each of these will be unappealing to the authority and carry legal (unauthorised variation or extension of a publicly procured contract) or scrutiny risk.

The contracting authority will equally have its own unbudgeted costs, although these are likely to be less extensive than for the supplier.  Put another way, the pecuniary costs of project failure will often be greater for the supplier – but the reputational and policy ‘costs’ of project failure will often be greater for the authority.

The objective for each party will be to devise a deal which is at least better than the alternative of cancelling the project and one that can be sold to internal and external stakeholders.  On the NHS Connecting for Health Programme one of the contractors, Accenture, was able to divest itself of its obligations to one of the other contractors, CSC.  But, as the CISGIL/ IBM case illustrates, walking away for a contractor is never an easy course.  For the public sector the walkaway option can be equally unpalatable, particularly if the project is there to deliver essential public services.


The CISGIL IBM case is a good illustration of the continuing high risk of transformational IT projects.

Hopefully this commentary gives some pointers on how the public sector can avoid any pitfalls.

For more information please contact Richard Bonnar or Simon Kenyon.

[1] CISGIL vs IBM UK Limited  [2021] EWHC 347, paragraph 132 onwards

Share this