Main issue in systems integration contracts - Click to read more
The traditional method of software development is the Waterfall model (also known as the Linear Sequential Life Cycle Model) and is used to describe the steps to develop software in the most logical and sequential manner, performed throughout the software development life cycle (SDLC). In the waterfall model, which was introduced in the 1970s:
- the business requirements are prepared and finalised before the project starts;
- the development process is divided into distinct, straightforward phases (conception, initiation, analysis, design, construction, testing, deployment);
- the methodology is a structured, sequential design process, where the output of the previous phase will become the input of the next phase and so on; and
- a project mind-set is adopted, with complete focus on accomplishing the project in line with specific dates or milestones for each phase.
In recent years, the popularity of the Waterfall method has waned somewhat, with more flexible and collaborative methods proving popular. Novel methodologies, which aimed to improve or replace Waterfall, such as Prototyping, Iterative, Spiral, V-Shape, were developed, came, and went, making way for more modern Agile frameworks such as Scrum, XP (Extreme Programming), and Kanban. First introduced in 2001 in the Manifesto for Agile Software Development[1], the Agile approach (an umbrella term used specifically for iterative SDLC methodologies that follow the 12 principles set out in the manifesto), offers iterative flexibility, with small parts of projects being built and tested simultaneously.
The success of Agile SDLC methodologies led enterprises to look to implement the same techniques across their business (so called Agile at Scale). Achieving Agile at Scale requires companies to address their full operating model, breaking down functional silos by creating cross-technology and business teams that are focused on a specific business process or product. Agile at Scale can extend to global transformation of the enterprise, with a single common goal – producing the best possible outcomes for customers.
Moreover, according to McKinsey[2], truly Agile organizations can develop products five times faster, make decisions three times faster, and reallocate resources adroitly and quickly. Exhilarating stuff. However, in the more mundane SDLC world, the Waterfall model remains relevant today, especially for short projects, where there are clear and fixed requirements, and the environment is stable with suitable and trained resources available to support the project.
CIS General Insurance Limited v IBM United Kingdom Limited (CIS v IBM)
CIS v IBM[3] is important not least because, to date, few cases involving Agile software development and implementation have appeared before the courts, compared with well-known project failures which have ended in litigation, such as BSkyB v EDS which was settled for a total amount of £318 million.
The case involved an Agile systems development project which went badly wrong and ended up in the Technology and Construction Court. CIS, the general insurance arm of the Co-op (primarily providing home insurance and motor insurance), needed to migrate from outdated legacy systems which it shared with the Co-op Bank to a modern IT infrastructure which would enable it to provide tailored services to its customers and to compete as a market-leading digital and data-based business. Following a competitive tender, CIS selected IBM and the parties entered into a 10-year master services agreement (MSA) for the supply of a new IT system for CIS’s insurance business and for management of the system. IBM in turn subcontracted a substantial part of the services to Innovation Group in particular the development of the insurance platform solution required which was to be based on Innovation Group’s proprietary software Insurer Suite.
The MSA provided contractual Milestone Release dates, which were aligned to CIS’s separation from the Co-op Bank’s infrastructure, as part of an internal reorganisation. However, in other respects it adopted an Agile approach based on the Scrum framework. Delays occurred with IBM exercising audit, and subsequently, step-in rights against Innovation Group and, ultimately, the relationship between IBM and CIS broke down, with IBM serving notice of termination when CIS failed to pay an invoice for around £3 million. Consequentially, CIS alleged repudiatory breach of contract and, alternatively, that the agreed milestones were unachievable and that IBM was in breach of a warranty as to its performance of the MSA. CIS then sued IBM, claiming damages of £128 million in respect of its wasted costs arising out of the alleged wrongful termination by IBM. CIS subsequently decided to abandon the project and sold its insurance business to another insurer, Royal London.
The judgement, some 754 paragraphs long, was handed down by Mrs. Justice O’Farrell on 19 February 2021 following a 32-day hearing. The judge held that:
- The £3 million invoice was payable but, because it was disputed by CIS under an agreed contractual procedure, its non-payment did not entitle IBM to terminate.
- IBM was responsible for the critical delays to the project, which were largely due to failures by Innovation Group to whom it had subcontracted work. IBM failed to meet key milestones and to provide accurate reports as to delays during the project, in clear breach of the MSA.
O'Farrell J dismissed CIS’s claim for its £128 million in wasted costs, as this was expressly excluded under the MSA, but she awarded CIS almost £16 million for additional costs incurred as a result of delay in reaching contractual milestones, reduced by around £3 million by setting off the unpaid invoice.
Lessons learnt
In the past, some commentators have suggested that software development projects that adopt an Agile approach are less likely to fail, compared with the Waterfall methodology.
CIS v IBM is an example of an Agile project which failed spectacularly.
Neither CIS nor IBM come out of this looking spotless. Compared with typical Waterfall projects, Agile implementations can be much more complicated – they 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. In the present case, matters were further complicated by the substantial portion of work subcontracted to Innovation Group, which itself was sold to new owners, the Carlyle Group, during the project’s life.
A frequent problem in Agile projects is that of timing. Delay also played a role in the CIS v IBM case and appears to have been one of the contributing factors of the project’s failure. The parties to an Agile development agreement should take extreme care when agreeing key milestones and particularly project completion dates. A fixed completion date may work in Waterfall contracts but does not lend itself to be easily adopted in an Agile context. At the beginning of an Agile project, the supplier will often not know what the totality of the customer’s requirements are. Also, the customer requirements are often subject to significant change as the project develops. Product backlogs often set out several user stories, not all of which will be allocated to a sprint backlog for delivery during the available sprints. More flexibility with regard to timing and constant party interaction needs to be built into a project to avoid a build-up of delays which ultimately then results in a project’s failure.
Where used within the context of a large enterprise, such as the Co-op, undergoing a significant degree of change, Agile mythologies may be better used as part of a programme of incremental change rather than as a lever for transformation.
[1] https://agilemanifesto.org/
