CIS General Insurance Ltd v IBM United Kingdom Ltd

Introduction Para 1-25

Chronology

The Dispute Para 186-190

Issue 1- Termination Para 198-200

Issue 2- Breach of Warranty Claim Para 401-402

Issue 3- Reporting Claim on State of Insurer Suite Para 501-503

This case concerns a claim for wasted costs and damages arising out of the termination of a contract for a new information technology system.

The claimant (“CISGIL”) was a wholly owned subsidiary of the Co-operative Group Limited (“the Co-op Group”). CISGIL's business is the underwriting and distribution of general insurance products. Its principal products are home insurance and motor insurance which it underwrites and sells to its members and customers through a variety of retail channels, including direct website and telephone sales, aggregators (comparison web sites) and third-party brokers.

In about 2014, there was a re-organisation within the Co-op Group. The life insurance division was divested and separation of the Co-op Bank was initiated. CISGIL’s network infrastructure, data centre, hardware, software and applications were all shared with the Co-op Bank. They were cumbersome and outdated and, when the Coop Bank left the shared platform, the operation and maintenance costs would be unsustainable. CISGIL considered that access to a flexible and contemporary IT infrastructure would enable it to provide tailored services to its customers and to compete as a market-leading digital and data-based business. Therefore, CISGIL decided to purchase and implement a new IT solution for its business (“Project Cobalt”).

On 16 June 2015 CISGIL entered into a contract with the defendant (“IBM”) for the supply of a new IT system for CISGIL’s insurance business and for management of the system for a term of ten years. The contract comprised a Master Services

The cost of supply and implementation of the new system was £50.2 million. The cost of the management services to be provided over a period of ten years from implementation of the system was estimated to be £125.6 million.

By a contract dated 16 June 2015 IBM engaged Innovation Group (“IG”) to supply software and services for the insurance platform solution required, using a proprietary software called “Insurer Suite”.

The MSA provided for IBM to deliver the new operating platform substantially before the longstop date of 31 December 2017, when CISGIL’s insurance business would be separated from the Co-op Bank:

Delays occurred to Project Cobalt. The contractual dates for Release 1 Go Live and Release 2 Go Live were not met.

In 2016 IBM exercised its audit rights against IG and in 2017 it exercised step-in rights against IG.

On 24 March 2017 IBM submitted an invoice in the sum of £2.9 million in respect of milestone Application Gate 5. IBM’s position is that the AG5 milestone reflected payments due in respect of software licences and became payable in January 2017.

By email dated 27 March 2017 CISGIL refused to accept or pay IBM’s invoice for the milestone payment.

On 12 May 2017 CISGIL gave notice that it intended to exercise rights of set off against any sums due in respect of the invoice.

On 22 June 2017 IBM served on CISGIL a final notice in respect of the invoice. CISGIL did not pay the invoice.

On 27 July 2017 IBM purported to exercise a contractual right of termination based on CISGIL’s failure to pay the invoice for the AG5 milestone.

CISGIL disputed IBM’s right to terminate, treated the purported termination as repudiatory breach and by letter dated 28 July 2017 purported to accept such repudiation.

CISGIL’s primary claim is for damages of £128 million in respect of its wasted costs arising out of the alleged wrongful termination by IBM.

CISGIL has an alternative claim against IBM for breach of a contractual warranty. Its case is that IBM contractually warranted that it had taken all reasonable steps and satisfied itself as to all risk, contingencies and circumstances as to its performance of the MSA but the warranty was untrue. Insurer Suite was not a proven, commercial off-the-shelf product that was highly configurable and capable of meeting most of CISGIL’s requirements with a minimum amount of customisation of the out-of-thebox (“OOTB”) product. IG did not have the resources to undertake the nature and extent of base development required. Damages in the sum of £70.4 million are claimed on the basis that CISGIL would not have entered into the MSA had it known that the warranty was untrue.

CISGIL has alternative claims against IBM arising out of the delays to the project. Its case is that a material factor in the late delivery of the platform was that Insurer Suite had been developed for use in the United States but not the United Kingdom. The base code development that was required had not been completed prior to the MSA and IG did not have the necessary resources to carry out and complete the substantial re-writing and development required within the contractual timescales. Damages of £128 million; alternatively, £36.1 million, are claimed on the basis that it would have terminated the contract early if IBM had satisfied its reporting obligations.

CISGIL has a further alternative claim for damages of £27.2 million for the costs of delay to the project caused by IBM and its failure to report accurately on progress.

IBM disputes the termination claim. Its case is that it was entitled under the MSA to payment of the invoice in respect of milestone AG5, regardless of any failures to meet other milestones. CISGIL wrongfully failed to pay the invoice and was not entitled to rely on any right of set off because any such right was exercised too late. As a result, IBM was entitled to exercise its contractual right to terminate.

IBM disputes breach of any contractual warranty. Its case is that Insurer Suite was developed for an international market and did not need to be re-written or redeveloped for UK insurers. The parties recognised that base development, customisation and configuration would be necessary to the software to meet CISGIL’s business requirements as set out in the MSA. Delays occurred as a result of failures for which both parties were responsible but the platform was capable of being delivered to meet the requirements of CISGIL.

IBM’s case is that it was not liable for the delays to the project because they were caused by:

IBM contends that it complied with its reporting obligations and, even if the Court finds against it on any part of the claims, there was no wilful default.

Quantum is disputed. IBM accepts that £29.1 million was wasted expenditure but submits that such costs are excluded; in particular, the finance costs claimed are indirect or consequential losses that are excluded by express terms of the MSA or are too remote. Further, reliance is placed on a contractual cap of £15.7 million.

IBM has a counterclaim in the sum of £2,889,600 in respect of the unpaid invoice for the AG5 milestone.

CISGIL sells home and motor insurance to consumers through multiple channels which include telephone sales, direct web sales and indirect sales through brokers. The business transformation programme initiated by CISGIL was intended to create a new operating model (“NOM”) for the business, which would be supported by new IT infrastructure and software.

Support for the home insurance business was planned for Release 1 and support for the motor insurance business was planned for Release 2.

Prior to the project, CISGIL was part of the Co-operative Banking Group umbrella (“the Group”), alongside the life insurance division and the Co-operative Bank. Following CISGIL’s merger with Britannia Building Society in 2009, the Group suffered a financial crisis. As a result, in 2013 the life insurance division was sold to Royal London and separation of the Co-operative Bank from the Group was instigated to comply with regulatory requirements.

Mark Summerfield, the Chief Executive Officer of CISGIL, explained in his evidence that CISGIL’s legacy business, the current operation model (“COM”), was supported by systems shared with the Co-op Bank. However, the shared legacy IT infrastructure was expensive to maintain and, once the Co-op Bank exited the shared estate, CISGIL could not afford the running costs of approximately £100 million per annum.

In 2014, CISGIL was advised by consultants, Deloitte, that its options were, either to keep the existing system with enhancements and move to the Co-op Group infrastructure (“the lift and shift option”), or transfer to a new technology solution hosted on a third-party platform (“the re-platform option”). The investment requirements for each option would be similar but a new IT system would provide long-term cost savings and would support CISGIL’s strategy to become a marketleading digital and data-based business.

The CISGIL Board decided to pursue the new IT system as its preferred option.

Further impetus was given to the project by CISGIL’s recognition that its existing technology was not capable of meeting the changing and increasing demands of its customers and by concerns expressed by the regulators. CISGIL is authorised by the Prudential Regulatory Authority (“the PRA”) and regulated by the PRA together with the Financial Conduct Authority (“the FCA”). The PRA’s function includes regulation of CISGIL’s liquidity and capital reserves, which were subject to stringent scrutiny in the wake of the financial crisis.

In a letter dated 15 September 2014 the PRA stated to CISGIL:

Mr Summerfield’s view was that the new platform would improve CISGIL’s competitiveness by producing increased revenues, increased profits and reduced costs. Further, it would improve CISGIL’s ability to deliver to customers flexible, coordinated products that would meet their needs.

The introduction of the new IT solution required the migration of all existing customer data onto the new system by a phased transition. The old system would not be decommissioned until the new system had gone live and all migration activities were complete. During the transition phase, both systems would be required to operate, entailing the costs of maintaining both the old system and the new system concurrently. As such, CISGIL was concerned to keep the transition period as short as possible to minimise costs and the risks to customer data.

The timetable which both CISGIL and the Co-op Bank were working towards was to exit the legacy estate by mid-2017 and for the old platform to be decommissioned by a long-stop date of 31 December 2017. It was essential for CISGIL to be in a position

It was imperative to CISGIL's business that the new IT solution and the data centre on which it was to be hosted was fully compliant with all regulatory requirements for a general insurance organisation.

The tender process started on 6 June 2014 by the issue of the Request for Proposal (“RFP”) in respect of a new IT solution for CISGIL. The stated objectives of the IT solution included delivery of a fully managed end-to-end new solution for CISGIL’s business, including core policy administration, billing, claims and enterprise systems, human resources, data warehouse and relationship management. The RFP stated that the IT solution should be a managed service from the provider’s own data centres/hosting facilities with no interfaces or integration with the existing (COM) system. It had to include full disaster recovery capability, comply with all UK insurance regulatory requirements and have the flexibility to adapt to market and consumer changes. Regular upgrades would be required as part of the standard solution. Historical data would have to be migrated into the core applications or as a read only basis for analysis. The IT solution was required to enable the introduction of new products, sourced by CISGIL or by third parties.

On 26 June 2014 an initial “Deep Dive” meeting was held at which IBM and IG made an initial presentation to CISGIL in respect of the project.

On 4 July 2014 IBM prepared its executive summary proposal, including the following:

“In our view, what you are asking for in your RFP does not exist in the UK market today.

A number of suppliers offer core insurance products that could eventually fulfil your policy admin and claims requirements but no supplier has a proven, modern, ready to deploy offering for a fully managed GI insurance IT service.

Our solution brings the best of IBM and Innovation Group to deliver you this full service from proven individual components

...

The core of our solution is the Innovation Group Insurer platform. IG Insurer is a fully integrated, core insurance platform with a modern architecture. It provides end-to-end functionality from omni-channel customer service through to claims processing, supplier management and advanced analytics. It is a solution design for rapid deployment and implementation out-of-the-box. Its predefined business processes will simplify your operations and its ease of configuration will allow you to launch new products quickly and put your business users in control … ”

By an email dated 21 August 2014, Chris Jackson, executive partner (insurance) at IBM, stated to CISGIL:

“Innovation Group is not only a software company it is also a BPO [business process outsourcing] provider to many GI businesses, mostly (but not always) for claims handling so we felt that utilising this capability and the more efficient business process that supports self-service and other developing activities that characterise a 'social Insurer' gave us the flexibility to re-frame the end to end business process flow and tailor something very specific for Coop GI - but driven by the

'out of the box' process flow that comes with Insurer.”

In August and September 2014 IBM submitted its responses to the RFP which included working with IG as the application software provider.

In a paper dated 24 September 2014 prepared by Tom Hardcastle, the separation and integration director at CISGIL, for the CISGIL Board, the IBM proposal was described as follows:

“Most of the solution consists of Innovation Group (IG) Insurer Suite components which are already in use in the UK and which IG offer as a service from their UK based data centres. The IG product set is an end to end integrated insurance platform utilising single source data. The remaining parts of the solution are predominantly an IBM Omni-channel suite for marketing and customer management and Oracle for financials. As they are able to utilise an existing integrated core platform this leads to the lowest costs and the shortest timeline to deliver.”

The IBM proposal was ranked first out of four proposals across all evaluation elements and CISGIL's board approved Mr Hardcastle's recommendation to proceed to the due diligence and design phase with IBM.

IBM’s proposal was based on provision of the core sales, policy administration and claims functionality through the Insurer Suite application software supplied by IG. These components provided core functionality for sales, administration of insurance policies and claims, accessed by call centre staff and administrators using a webbased interface. Insurer analytics functionality provided management information (“MI”) and a database to support reporting,

Additional components supplied by third parties were integrated with the IG developed components. Exago was a reporting software tool used to design and execute reports. ITP was automated standard document production software from AIA (subsequently purchased by Kofax) used to merge data from the Insurer Suite database with CISGIL’s template documents to generate letters, policy and other documents. Edge Connect was development software for building web applications, used by IG to develop the consumer, home and motor portals. The quote and buy portal was a consumer-facing website which allowed customers to obtain quotes and purchase insurance. The customer portal was a consumer-facing website that allowed customers to view policy documents, renew policies and initiate claims. The home supplier portal was a website for suppliers offering repair or replacement services in respect of home policy claims.

Aggregators are third party websites that allow users to compare quotations from multiple insurers. IG developed the adaptive rating component to generate prices for customers based on a series of rating factors to support the aggregator functions.

The IG data centre hosted both the core Insurer Suite application components and the components to be implemented by IBM, such as marketing, fraud, finance and other supporting functions.

CISGIL would provide and support elements such as desktop computers and software, together with telephony through a third party supplier, Avaya.

Insurer Suite was an existing, developed and tested software package, providing a substantial amount of standard business functionality OOTB. However, it would be necessary to make changes to the OOTB software for the proposed IT solution to meet the specific needs of CISGIL by:

On 31 October 2014 the parties agreed terms of engagement for due diligence, which was undertaken between October and December 2014. Louise Keohane, head of enterprise and business architecture at the Co-op Group, led the due diligence exercise. She explained in evidence that the due diligence phase focused on CISGIL’s detailed business requirements to enable IBM and IG to understand what CISGIL wanted and ensure that CISGIL was happy with those requirements.

A spreadsheet was produced, containing a description of CISGIL’s requirements, identifying whether they were within scope and therefore included in the price, and whether the requirements could be met by OOTB, configuration, customisation or development. The spreadsheet indicated that 104 out of the 414 entries within scope required a degree of development or customisation.

On 8 December 2014 the Transformation Executive Steering Committee (“TES”) concluded that CISGIL’s requirements could be met by Insurer Suite.

In December 2014 IBM produced its outline plans for delivery of the IT solution, including a spreadsheet identifying the CISGIL requirements that would be met by the base OOTB product, base design, configuration or customisation.

Chandler Gilmour Associates (“CGA”) were engaged by CISGIL to provide ongoing quality assurance to CISGIL and oversight on the due diligence phase. At a board meeting on 21 January 2015 Donald Martin of CGA presented a report stating that he was comfortable that the IBM/IG solution would be fit for purpose and that CISGIL was in a position to proceed to the detailed design stage.

On 23 January 2015 Ms Keohane produced a report entitled ‘Due Diligence Output’, stating that at the end of due diligence, the assessment of the IBM/IG IT solution was positive. There were no requirements within scope that could not be met by the solution but requirements were identified which were not included in IBM’s cost that would be reviewed in the early stage of the design. Confidence in IBM’s strategic leadership was low but CISGIL had formed a very favourable impression of IG, which was described as having strong insurance and system knowledge.

On 21 January 2015 CISGIL and IBM entered into the Interim Services Agreement

The services provided under the ISA included the fit-gap analysis, a detailed exercise to develop the earlier spreadsheet of requirements into a contractual document that would define CISGIL’s 551 requirements. The fit-gap analysis was a joint exercise between CISGIL’s subject matter experts (“SMEs”) and the IG/IBM product experts to find gaps between what was required and what would be delivered and identify the solution to close the gaps.

The exercise involved demonstration of the standard OOTB functionality to the SMEs and workshops to identify any gaps between the base product and CISGIL’s requirements. Where gaps in functionality were identified that could not be filled by configuration of the existing package, CISGIL would have to decide whether to change its business processes to accommodate the existing functionality of the software, or to customise the base product to meet CISGIL’s requirements.

The fit-gap assessment spreadsheets identified each requirement that would be delivered by development or customisation. Some elements were shown as OOTB but

The fit-gap spreadsheets were all signed off by the SMEs and by IG.

CISGIL decided to raise capital for the project through a market specialist debt fund. CISGIL's Board approved the decision to raise £70 million of capital by issuing subordinated debt. In May 2015 CISGIL raised £70 million of subordinated debt with a 10 year term (with an option to repay after 5 years) and a coupon rate of 12% (“the Bond”).

On 16 June 2015 CISGIL and IBM entered into the MSA.

Clause 2.1 of the MSA set out the benefits expected by CISGIL from Project Cobalt:

“The Customer is undertaking the Programme to enable business transformation and is implementing the Solution in order to generate tangible business benefits, including greater efficiency and a integrated omni-channel route to market for the Customer's insurance products. The Customer has a strategic intent to become the insurer of choice for members of the Customer Group. In order to achieve this intent, the Customer has set out a vision of a new "greenfield" technology platform which is current, easily configurable, proven, scaleable and resilient, to be provided as a managed service which will support the following elements of the Customer's business vision:

(a)

member focused, maximising insurance needs met;

(b)

purpose reinforcing, championing "better insurance";

(c)

personal lines focused with manufacturing / sourcing mix optimised;

(d)

end to end digital proposition, service orientated;

(e)

risk reduction to reduce capital requirements;

(f)

use of underwriting panels to increase extend distribution reach;

(g)

strong analytical and data capabilities; and

(h)

building relevant partnerships to support economies of scale and profit.”

Clause 2.2 identified the guiding principles that would apply to the project, including recognition that CISGIL’s business processes would be tailored to fit the new operating model introduced by the IT solution and the requirement that the IT solution

Clause 2.5 made provision for changes to be requested by CISGIL:

“The parties acknowledge and agree that:

(a)

the Core Services will be provided pursuant to the Implementation Services SOW and Managed Services SOW, to enable the logical sequencing of both activity and achievement of requirements in accordance with the Roadmap; and

(b)

the Customer may request the provision of Services and Deliverables that are:

(i)

related to the Programme but did not form part of the Core Services as at the Effective Date (including any project services, services to assist and/or other professional services) (Programme Related Services); and /or

(ii)

not related to the Programme and/or the Core Services (including any project services, services to assist and/or other professional services) (Additional Services), through this Agreement, in accordance with clause 3.”

Clause 2.8 recorded that the expected contract value for the Core Services was £181 million (inclusive of VAT and expenses), subject to adjustments pursuant to schedule 5 (Charges) and/or additional charges agreed as part of a Change.

Clause 3 provided for CISGIL to place orders for the provision of Services and Deliverables through Statements of Work (“SOW”). Two SOWs were entered into pursuant to the MSA, one for ‘Implementation Services’ and another for ‘Managed Services’.

Clause 4 set out the obligations of IBM to provide those services, including:

Clause 5.1 set out IBM’s obligation as to the timetable for delivery of the services: “The Supplier will perform its obligations set out in this Agreement and each SOW in accordance with the timetable detailed in the Roadmap and each relevant SOW timetable (as applicable), and will complete each Key Milestone by the date

Clause 5.5 provided that a failure to meet any of the Key Milestones entitled CISGIL to liquidated damages, subject to a contractual cap of 10% of the Charges.

Clause 6 stated:

“The provisions of schedule 6 (Acceptance Procedure) shall apply and each of the parties shall carry out their respective obligations in respect of Acceptance set out in the relevant SOW.”

Clause 10.1 provided for the grant of a licence by IBM for the IT solution.

Clause 12 contained contractual warranties on the part of IBM, including:

Clause 13.1 provided:

“No variation of this Agreement shall be effective unless it is in writing and is signed by or on behalf of each of the parties, who are authorised to do so as set out in schedule 12 (Governance and Reporting).”

Clause 13.2 provided:

“Subject to clauses 2.11 and 13.1, all Changes (including Changes to any SOW) shall be assessed and implemented in accordance with schedule 9 (Change Control Procedure).”

Clause 14 set out the applicable payment provisions:

“In consideration of the performance of the Services, the Customer shall pay the Supplier the Charges as set out in and/or as calculated in accordance with schedule 5 (Charges), which shall be invoiced at the times and in the manner specified in schedule 5 (Charges).”

Clause 18.5 provided in relation to sub-contracts the following:

“Where the Supplier subcontracts any of its obligations under this Agreement (including those under clauses 18.2 and 18.3):

(a)

the Supplier shall not be relieved of any of its liabilities or obligations under this Agreement by entering into any subcontract and the Supplier accepts liability for the acts and omissions of any Contractor or any of the Contractor's staff …”

Clause 23 contained exclusion and limitation of liability provisions.

Clause 26.1 specified the term of the MSA:

“This Agreement shall be effective from the Effective Date and shall continue in force until the earlier of:

(a)

termination by either party under this clause 26 (or as expressly provided elsewhere in this Agreement); or

(b)

ten (10) Years from the Managed Services Start Date

…”

Clause 26.2 contained CISGIL’s right to terminate for breach: “The Customer may terminate the Agreement and/or any of the Services in whole or in part immediately, by giving written notice to the Supplier, (as of a date specified in the notice of termination, such date not to be earlier than the date on which the notice is received by the Supplier) if one or more of the following occurs:

Clause 26.3 entitled CISGIL to terminate for convenience on notice to IBM and for termination charges to be paid in such circumstances.

Clause 26.7 contained IBM’s right to terminate for any wrongful failure to pay sums due by CISGIL:

“The Supplier shall have the right to serve on the Customer a written notice (Final Notice) if the Customer has failed to pay undisputed invoiced amounts which in aggregate exceed £1 million (one million pounds sterling) and which have been due and payable for a period in excess of forty five (45) days. Any such Final Notice shall itemise the undisputed invoiced amounts to which it relates and be addressed for the attention of The Chief Financial Officer of the Customer stating the Supplier's intention to terminate this Agreement and specifically referring to this clause 26.7. If the Customer fails to pay such undisputed invoiced amounts fifteen (15) Business Days of receipt of the Final Notice the Supplier may terminate this Agreement immediately.”

Clause 37 contained an entire agreement provision:

“This Agreement sets out the entire agreement and understanding between the parties, and supersedes all proposals and prior agreements, arrangements and understandings between the parties, relating to its subject matter. In particular all terms, conditions or warranties implied by statute, law or otherwise as to the merchantability and fitness for purpose of the Services and/or any equipment or goods used in the provision of the Services are hereby expressly excluded, other than those implied undertakings as to title in section 12 of Sale of Goods Act 1979 which cannot be excluded at law.”

Clause 38 contained a non-reliance provision:

“Each party acknowledges that in entering into this Agreement it does not rely on any representation, warranty, collateral contract or other assurance of any person (whether party to this Agreement or not) that is not set out in this Agreement or the documents specifically incorporated in it. Each party waives all rights and remedies which, but for this clause, might otherwise be available to it in respect of any such representation, warranty, collateral Agreement or other assurance. The only remedy available to any party in respect of any representation, warranty, collateral contract or other assurance that is set out in this Agreement is for breach of Agreement under the terms of this Agreement.”

Clause 40 stated:

“Termination or expiry of this Agreement for any reason shall not affect any rights or liabilities that have accrued prior to such termination or expiry or the coming into force or continuance in force of any term that is expressly or by implication intended to come into or continue in force on or after termination or expiry.”

Clause 41 contained a non-waiver provision:

“Delay in exercising, or failure to exercise, any right or remedy in connection with this Agreement shall not operate as a waiver of that right or remedy. The waiver of a right to require compliance with any provision of this Agreement in any instance shall not operate as a waiver of any further exercise or enforcement of that right and the waiver of any breach shall not operate as a waiver of any subsequent breach. No waiver in connection with this Agreement shall, in any event, be effective unless it is in writing, refers expressly to this clause, is duly signed by or on behalf of the party granting it and is communicated to the other party in accordance with clause 35 (Notices).”

Schedule 2 set out the customer requirements:

“1.1

In outline the Supplier is required to deliver a new general insurance technology platform for the Customer through the provision of technology services.

1.2

The Supplier will provide the Customer with a series of services as particularised in Schedule 3 in order to meet the requirements collectively specified in the accompanying schedules in this agreement and the following documents:

a)

DLV-001 Business Functional Requirement

Specification Version 1.0.0 05 06 2015

b)

DLV-002 Architecture Model Diagrams (E2E

Schedule 3 defined the end-to-end services to be provided by IBM in respect of implementation, testing and transition to the new IT system, including:

“7 Application Management

7.1

The Supplier shall:

a)

deliver Software “out-of-the-box” to satisfy the

Customer Requirements as defined in DLV0001 (business requirements), appended to schedule 2 (Customer requirements);

b)

configure the “out-of-the-box” Software to meet the Customer Requirements as defined in DLV001 (business requirements), appended to schedule 2 (Customer requirements);

c)

move and redeploy versions of the Solution, Software and Data between different technical environments within the Solution;

d)

monitoring and refining the performance of Software to meet … the Architecture Non Functional Requirements defined in DLV012, appended to schedule 2 (Customer requirements).

8 Integration

8.1

The Supplier shall plan, manage, design, build and test the Solution required to deliver full interoperability of the Solution with external parties with which the Solution interfaces as set out in the Interface Inventory, DLV-004 and infrastructure and performance of the Managed Services …

9 Data Migration

9.1

The Customer shall extract Data from its legacy software and data stores, as agreed between the parties and in line with the Implementation Plan.

9.2

The Supplier shall perform the transform and load of the Customer data provided under paragraph 9.1 into the Solution, to meet the requirements defined in DLV001 (as appended to schedule 2 (Customer Requirements)), in accordance with the Implementation Plan. The Supplier shall not be responsible for cleansing the data supplied by the Customer.

10 Test Management

The Supplier shall test any Service, Release or Deliverable in accordance with the Test Strategy (DLV-013) (as set out in appendix C to this schedule 3

(Services) and schedule 6 (Acceptance).”

Schedule 6 contained the acceptance criteria and procedures.

The Implementation SOW dated 16 June 2015, including the following obligations on the part of IBM at paragraph 1.5.4:

“a)

Implement all the applications required to deliver, operate and manage the Solution, such applications shall be based on the Architecture Software Bill of Materials (DLV-003);

b)

Source, configure “Out of the Box”, test and deploy, as required, versions of Software and data in all technical environments necessary to deliver, support (including training facilities) and develop the Solution to meet the Customer Requirements.”

Under the MSA the core IT solution was to be delivered over two separate 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.

Paragraph 3.3 of the Implementation SOW specified that IBM should deliver the Deliverables and Services in line with the delivery dates set out in Table A.1. Table A.1, entitled “Roadmap”, was contained in Appendix A to the Implementation SOW and identified the minimum delivery milestones to be achieved by IBM in order to complete the SOW as specified together with the milestone payments. Key milestones included the following:

IBM used software development support tools during the implementation phase. This included:

IG used ‘SubVersion One’, a tool used to manage source code files and keep a record of changes made during the project.

The agile approach to development was adopted by the parties in this case. Such an approach involves incremental development taking place through an iterative process of software development by the supplier and feedback from the customer in ongoing cycles. The process requires a high level of collaboration and interaction between the supplier and customer. This can be contrasted with the traditional, sequential or waterfall approach to software development, in which each stage of specification, software development, configuration or testing is completed before the next stage starts.

At the outset of the agile process, a product backlog is produced, identifying all the features and functions of the customer’s requirements. For Project Cobalt, this was done through production of user stories by CISGIL, setting out the business processes and functions to be achieved.

Following preparation of the product backlog, a joint team of business users (SMEs) and technical staff (business analysts, developers and testers) work through it in a series of short cycles, typically two to three weeks long, known as “sprints”, where each cycle produces a working piece of software that can be tested and reviewed to check that it meet the users’ expectations (“unit testing”). The joint team is known as

“the Scrum Team” and the project manager, responsible for ensuring that the team works effectively, is known as “the Scrum Master”.

At the sprint planning session, the Scrum Team will ensure that the user stories are sufficiently clear and understood for development to proceed. Accepted user stories are placed on the “Scrum Board”. Daily stand up meetings are held to report on progress and any problems that arise. At the end of each sprint a review of the work carried out takes place, typically involving a demonstration of the functionality that has been produced.

An online project management tool, ‘Version One’, was used for Project Cobalt to support the agile process. The users would enter details of the backlog items that needed to be developed, typically including estimates of their size. The backlog items would be assigned to sprints, using the software. As work progressed, each user would change the status of the items on which they were working to reflect progress. This was intended to be updated in real time so there was full transparency of the process.

There were six sprints for Release 1, each lasting three weeks. The first sprint started on 1 July 2015. They were not a success.

The DVL-008 Programme Management plan set out the principles for successful delivery of Release 1, including:

“The applications are to be delivered in an ‘out-of-the-box’ basis. This has two consequences (i) the future operating model for CISGIL will be dictated in part by the usage of the delivered application components, (ii) there may be features of CIGILs existing environment that cannot be fully supported by the new application set.”

The release plan identified the following responsibilities on the part of CISGIL in respect of the policy application for Release 1:

“To provide … detailed product descriptions for the single Home product per May 1st at the latest. To participate in sprint events to provide details required for the configuration of the solution and to make such decisions as are necessary to complete the sprint objectives for each print. To provide templates for all automated and manual communications to provide the configuration of all business rules over and above the standard products configured by the IBM/IG team. To provide all end user training. Provide Telephony Solution.”

On 23 July 2015 Alison Neate, Transformation Director at CISGIL, reported to Mr Summerfield that there were a number of issues impeding the progress of the sprints.

On 4 August 2015 Ms Neate reported her concerns again to Mr Summerfield:

“We are heading for a relief event on strategic sourcing.

We have not moved this forward for over a week. We still have 4 suppliers not spoken to. At today’s 8.30 call no one turned up again.

After the initial contact it seems that follow up has been poor and momentum has stalled…

IBM have stepped away and I would expect IBM will now start to position this as a relief event

We need to discuss this. Of all the plates spinning this is the one that I believe will now physically stop the programme from succeeding.”

At the TES meeting on 27 August 2015, issues recorded included that required third party interfaces were not maturing fast enough to support the plan and that the development of user stories by CISGIL was too slow.

On 1 September 2015 at the Programme Management Group (“PMG”) meeting, the status overview included reference to areas of concern for Release 1, relating mainly to the sprints, interfaces and the delivery of the network, equipment, systems and telephony (“NEST”) requirements. Although CISGIL would meet its user story target, it would not achieve the fit gap coverage expected because it was recognised that additional user stories were needed.

On 2 September 2015 Ms Neate informed Mr Summerfield:

“It’s clear that the sprint process is not working ... One of the key issues is that we cannot create user stories linked to fit gaps at the rate necessary to configure. Equally, IBM are unsure whether the fit gaps will deliver the right outcome ie deliver the business requirement.”

On 4 September 2015 Ms Neate reported that the sprints were close to collapse.

Denise Barnes, the delivery executive at IBM, agreed with Ms Neate that the sprint approach was not working. Her view was that the sprint failure was caused by a combination of IG’s inability to plan, control and monitor the process and CISGIL’s late provision of information and changes to the scope of work. A revised approach was agreed between IBM and IG, approved by CISGIL, using workshops to control the process. The workshops started on 15 September 2015 but quickly it became apparent that they were not achieving the desired outcome.

On 25 September 2015, Angie Moore of the transformation group at CISGIL, produced a report on sprint workshops to Mr Summerfield, stating her concern that

Susan Balcombe, insurance business consultant for IBM, considered that the process should be changed to a series of workshops led by IG, with a smaller number of people attending so that decision making would be more efficient. She was concerned that there needed to be more creativity so that functionality could be dropped into system integration testing (“SIT”) more quickly.

Jacqueline Boast, a managing director of IG, agreed that IG, IBM and CISGIL needed to change the approach to delivery and assigned to Ric Wood, then part of the delivery team at IG, the task of preparing an alternative proposal to recover the delay.

On 26 September 2015 Mr Wood produced a proposal whereby Release 1 would be delivered in three separate drops of functionality into SIT. A revised sprint plan was produced for the TES meeting on 8 October 2015, showing the following:

Under the MSA, milestone IMP-018 required the technology for Release 1 to be successfully built and ready for testing by no later than the end of December 2015. On completion of the milestone, a milestone payment of £4,920,000 would be due and payable to IBM.

On 26 October 2015 Ms Neate suggested to Leah Noakes, commercial manager for CISGIL, that the Release 1 completion milestone could be divided up to reflect the three drops of functionality as IMP-18a, 18b and 18c. This would be financially advantageous to IBM as the first two parts of the milestone would become payable by the end of 2015. Drops 1 and 2 were due to be delivered before the year end but, unless the payment milestone was similarly divided up, no payment would be made to IBM until January 2016, on delivery of the third drop. The advantage to CISGIL of this approach was that it would allow it to retain financial leverage pending delivery of each drop.

At this time, it was recognised by CISGIL and IBM that some slippage was likely to occur to the Release 1 go live date. On 28 October 2015 Ms Neate sent an email to Mr Summerfield recording an agreement reached with Ms Barnes of IBM:

“I have agreed with Denise we will go live with R1 on either 30 April or contingency 30 May.

IBM will absorb all costs up to 30 April and we would aim to share costs for May – but we expect this to be low as we will be in UAT and all working on 2. We are NOT planning on 30 May

– we are planning 30 April.”

The revised plan was approved by the Board Transformation Committee (“BTC”) on 17 November 2015.

On 2 December 2015 CISGIL and IBM entered into a further agreement (“the Amendment Agreement”).

Under the Amendment Agreement, the starting date for system integration testing (“SIT”) was pushed back by one week to 30 November 2015 and milestone IMP-018 was divided into the three drops: IMP-018a by 23 November 2015, IMP-018b by 18 December 2015 and IMP-018c by 31 January 2016. On completion of each milestone, IBM would be entitled to a milestone payment of £1,640,000.

Further delays occurred. CISGIL produced some of the required business information late and IG failed to deliver the technical drops as agreed. By email dated 2 November 2015 Ms Barnes told Ms Boast:

“I am very uncomfortable on progress and am not confident that we will make the Release 1 date … seems everything that has a dependency on insurer is turning red! Unless we get some real progress in the next two weeks I think we are looking straight down the barrel of the LD gun for Release 1 and that could even stretch to release 2 as we have not got underway with that for insurer yet …”

On 16 November 2015 Arie Bruggink of IBM noted that IG was behind programme targets on drops 1, 2 and 3.

On 19 November 2015 Ms Barnes sent an email to Mr Jackson, stating her frustration with IG’s failure to perform:

“I and the team are totally fed up that we are still having issues with IG and if they really want to be a strategic partner they need to step up and act like one. Milestones are being missed and yet we are not being given warning and there is no urgency to get back in line or regret of missing them. I have been escalating the same issues for months, unfortunately many of the impacts have materialised and these could have been avoided… drop 1 will not be on time and a week late … Drop 2 in IG words has significant risk, drop 3 even more – I have no confidence that these will be delivered… ”

By email dated 8 December 2015 Mike Freeman of IG informed Ms Barnes of IBM that the delivery of drops 2 and 3 was challenging but achievable, subject to the postponement of some fit gaps from drop 2 into drop 3.

In mid-January 2016, Ms Neate of CISGIL agreed with Ms Barnes of IBM that the April go-live date for Release 1 would be moved to 30 May 2016. At the time of this discussion, the Co-op Group was carrying out a re-branding exercise (“Pioneer”). Postponing the go-live date would afford additional time to achieve alignment of the product rebranding and the new websites. Although there was no formal amendment to the key milestone dates, on 19 January 2016 the revised date was approved by the BTC.

IBM failed to deliver the complete build of the Release 1 code by the end of January 2016 as required by the Amendment Agreement. Technical drop 3 was deployed into SIT but there were missing elements and CISGIL was told by IBM that additional drops would be required to complete the functionality that should have been delivered. Initially, the outstanding functionality was to be provided by drops 4, 5 and 6 but subsequently numerous further drops and fixes were required. On IBM’s case, based on Dr McArdle’s opinion, all Release 1 functionality was provided by drop 24 on 24 June 2016; on CISGIL’s case, based on Dr Hunt’s opinion, it was not provided until drop 33 on 26 August 2016.

On 17 February 2016 Chris Pickup and Scott Paton of PA Consulting Group prepared a report for the BTC, stating:

“In the BTC on 19 January 2016, the CEO requested a delay to

Release 1 (R1) go-live to 30 May 2016 and a delay to Release 2 (R2) to the end of September 2016. … Since then the programme has entered a difficult period where more delivery issues have arisen and the timely delivery of the releases against the revised delivery dates is at risk… Whilst there are issues of CISGIL origin that are increasing the risk of delay, such as delays in customer documentation provision to IBM and CISGIL network (VPN) problems that have limited the number of users able to access the Insurer system, many of the issues faced by the Programme relate to a combination of the IBM delivery approach, the lack of transparency in IBM communication and 1Insurer resource constraints…”

The recommendations in the report included improved oversight and management of

In early March 2016 it was recognised by CISGIL and IBM that the May 2016 go-live date for Release 1 was unlikely to be met. Issues included late configuration of the software by IG and delays to UAT preparation by CISGIL. At the TES meeting on 9 March 2016 approval was given for IBM’s proposal to split the components of Release 1 into two releases: Release 1, which comprised delivery of the NOM functionality and renewals, by the end of May 2016; and Release 1.1, which comprised the COM functionality and aggregators, by June or July 2016.

User acceptance testing (“UAT”) is intended to test and validate that the IT solution operates properly and satisfies the business requirements and processes. Release 1 UAT was carried out by CISGIL, with support from IBM and IG, using business level scenarios to test that the system functioned as required. Release 1 UAT was scheduled to start on 30 March 2016. By 23 March 2016 IBM had not completed SIT, not all the UAT entry criteria had been met and there were outstanding issues which required further work. However, on 29 March 2016 CISGIL reviewed the UAT test plan and concluded that it should enter UAT to try and meet the Release 1 go-live date of 30 May 2016.

Unfortunately, by 13 April 2016, Ms Neate reported that UAT had already ground to a halt. Difficulties were caused by defects and the UAT team had run out of test scripts that defined the business scenarios and functionality to be tested. Erratic behaviour of functionality was experienced between code drops and there were a substantial number of defects, including critical key defects which prevented further testing of that part of the process (“blockers”). The UAT Status and Defect Report produced on 22 April 2016 recorded that nearly 1,000 scripts were blocked.

On 19 April 2016, a meeting was held between Mr Summerfield, Ms Neate, Darren Coomer, Mr Jackson and Ms Barnes to discuss revised dates for the Release 1 milestones. There is a dispute as to what was stated at the meeting. CISGIL understood that IBM had proposed a revised date of mid-July 2016 for the Release 1 go-live milestone and a Release 2 go-live date of the end of September 2016, albeit with reduced scope and a subsequent Release 2.5 at the end of 2016 which was to be considered at the next TES. IBM understood that dates between June and August 2016 were discussed for Release 1 but no dates were discussed for Release 2.

The following day, Ms Barnes informed Mr Summerfield that whilst IBM’s components of the IT solution for Release 2 were on schedule, IG had not started work on its components and that they would not be delivered by September 2016.

This marked a turning point in the relationship between CISGIL and IBM. It is clear from the competing accounts of meetings from this time onwards and the tone of the written communications, that there was a complete breakdown in trust.

There were also increasing tensions within CISGIL. Mr Coomer’s approach caused conflict with Ms Neate. On 27 April 2016 Ms Neate tendered her resignation, stating:

“I am tired of the general lack of respect I get for running the programme and criticism of it.”

On 28 April 2016 Mr Summerfield responded:

“I believe in you. I believe you are the right person to get R1 in. Whilst as a team Coop may have contributed to the delay to R1,

On 6 May 2016 CISGIL suspended UAT.

On 12 May 2016 CISGIL sent a letter to IBM alleging that IBM was in breach of the MSA, having missed milestones IMP-018c (Release 1 Build Complete due 31 January 216), IMP-021 (Release 1 due end March 2016) and IMP-022 (Release 1 Go Live due end April 2016). Milestone IMP-023 (Release 2 build Complete due end May 2016) would also be missed. CISGIL required IBM to produce revised implementation plans for Release 1 and Release 2, with documentary evidence that appropriate levels of resources would be available to support the plans.

On 24 May 2016 CISGIL served a formal notice of breach on IBM.

At this time, CISGIL made direct contact with IG’s new owners, the Carlyle Group, to discuss its concerns about slow progress on the project. At a TES meeting on 13 June 2016 Mr Summerfield reported that:

“… he and Darren Coomer had met with the Carlyle Group, the owners of One Insurer (‘1i’), and informed the Committee that the meeting had been encouraging despite Carlyle’s frustration with IBM, and Mark suggested that 1i and Carlyle Group be included in the communications loop and that the programme governance should be reset to accommodate this…

Mark Summerfield stated that the nature of the relationship between 1i, Carlyle Group and Co-op Insurance was obstructive as IBM were acting as a go-between, preventing any meaningful interaction on a tripartite basis. He added that the relationship with IBM was becoming increasingly frustrated. Mark Summerfield stated that the team had lost faith in Chris Jackson, whose role was focussed more on selling the solution than delivery, and that Denise Barnes’ behaviour had become less co-operative and as such was impacting effective decision making and communication, which was echoed by Alison Neate. Mark added that he had discussed this with Angela Magee who had agreed that Denise Barnes would not continue as delivery lead beyond Release 1.

The Committee agreed that … Denise Barnes should be replaced with someone with greater experience of delivery…

Mark Summerfield informed the Committee that Alison Neate had made the decision to step down due to a change in personal circumstances and intended to leave the business on 18 July 2016.”

On 16 June 2016 CISGIL notified IBM that it wished to exercise its rights of audit under the MSA. PWC was appointed to undertake the audit.

By letter dated 1 July 2016, IBM wrote to IG in the following terms:

“The 1insurer Release 1 build has missed its planned delivery dates which has accounted for the depletion of time contingency built into the entire programme. 1insurer has continued to not deliver on committed timelines despite many re-plans and agreements to achieve revised dates. The obligation on 1insurer to satisfy, namely that “each Service and Deliverable is Ready for Use by the applicable Milestone Date, Key Milestone Date or other date of delivery specified in the table or in accordance with the Implementation Plan” (SOW,

“Key Milestones and Dates”), has consistently been missed.”

In July 2016 Ms Barnes ceased to have delivery responsibility for the Project, although she continued to provide commercial assistance until the end of the year, and Ms Neate left CISGIL.

Mr Summerfield’s evidence was that at this stage, CISGIL did not consider terminating the MSA. Its primary objective was to exit from the existing platform, which would produce contract cost savings of £9.1 million, together with the substantial IT infrastructure cost reduction of £15m by moving to the new IBM system.

In August 2016 CISGIL, IBM and IG held a series of meetings to discuss the way forward. One option proposed was a minimal viable product (“MVP2”) that could be delivered to enable CISGIL to exit from the existing platform. At the TES meeting on 18 August 2016, Richard White was introduced as the new transformation director for CISGIL and the MVP2 proposal was discussed. The original plan was to implement the new operating IT system and then migrate the COM products to the new system. The programme assumed that Release 2 would be running by Autumn 2016, enabling CISGIL to exit the COM by early 2017. The new proposal was to re-implement the existing operating model and legacy products in Insurer Suite (excluding legacy technology and processes) so that CISGIL could decommission the existing data centre. Thereafter, new business would be introduced on a minimum basis. Phased data migration would follow once all new build products had been completed. CISGIL didn’t accept the proposal because it had concerns that it would not be viable.

On 6 September 2016 IBM sent a written notification of breach to IG, stating that IG failed to deliver on committed milestones and revised dates and was in material breach of its contractual obligations.

IBM stated that it had incurred and continued to incur significant costs, expenses and other losses resulting from such breaches and from the consequential delays to the programme, which it intended to recover from IG:

“To the extent that CISGIL claims against IBM, IBM acknowledges that such claims result from 1insurer’s breach of its obligations and IBM will seek full recovery from 1insurer.”

By early October 2016 IBM had completed the SIT process for Release 1. On 14 October 2016, at an extraordinary TES meeting, CISGIL made a decision to recommence UAT on 17 October 2016. Not all entry criteria had been met; there were outstanding defects that would require further testing and the UAT period was extended informally from six weeks to 14 weeks (plus a contingency period of 4 weeks). Progress would be monitored on a daily basis through triage meetings and through weekly checkpoints with updates.

On 2 December 2016 Richard White of CISGIL issued IBM with a defect notice at the end of the first cycle of UAT on the ground that UAT exit criteria had not been met due to high numbers of unresolved defects and a low pass rate of test scripts.

Various revised plans for Release 1 and Release 2 were proposed by IBM and rejected by CISGIL during the second half of 2016 but the parties continued negotiations to explore options for a revised programme and amended commercial terms. Pending the outcome of those negotiations, CISGIL continued to pay IBM invoices submitted against milestones, including the IMP-018c milestone which was paid at the end of December 2016.

During this period, Mr Coomer set up the Technology, Innovation and Change (“TIC”) Group to work on the “Pinarello” initiative, a proposal to consider the removal of IBM from the project, through the exercise of step-in rights under the MSA, leaving CISGIL to continue, working directly with IG. At an internal CISGIL meeting held on 14 November 2016, Mr Coomer presented TIC’s findings and recommendations. The Pinarello scenario was identified as a contingency option for delivery of the transformation programme. It would result in an increase in delivery costs but a reduction in the charges and support costs over the 10-year service period.

On 22 December 2016 the PRA wrote to CISGIL in respect of its annual risk assessment, stating:

Commercial discussions took place between the parties towards the end of 2016 but no agreement was reached.

IBM commissioned an internal audit to review IG, including a source code assessment carried out by Omnext. On 27 November 2016 initial findings were shared with IG and set out in an interim audit report. The report raised concerns about the approach used by IG to develop the Release 1 product:

On 12 January 2017 the final audit report was produced by IBM. The findings included required improvements by IG for the maintenance and support of Release 1.

On 18 January 2017 IBM served a demand notice under the parent company guarantee given by the Innovation Group Limited:

“2.3

To date 1i has failed to comply with its obligations under the Contracts, including the obligation to deliver the Key Milestones as agreed. IBM has been engaging with 1i to achieve delivery of the Services by 1i pursuant to the terms of the eContracts. However, 1i’s failure to comply with its obligations is continuing. A recent example of this is that upon undertaking a code review earlier this month it has come to IBM’s attention that the quality of the code provided by 1i as part of hits Services under the Contract is very poor. This is demonstrated by, for example:

2.3.1

the use of free open source software (FOSS) in the customised code. An analysis of the customised code showed 182 different components of FOSS. This creates various legal and security risks, for example, with the use of FOSS there are restrictions on use by licence or conditions on use which may be as severe as having to publish all work derived from the use of the software under the same FOSS licence.

2.3.2

During system integration testing (SIT) there were a large number of failures around interfaces and customer facing documents. Additionally there were a larger than expected level of functional failures and a high fix fail rate.

2.3.3

The Kofax documents are constructed with many hard coded items which does not enable efficient updating and change tracking in the future…

2.5

1i’s failure to comply with its obligations under the Contracts is causing, among other things, significant delay to the Programme (as defined in the MSOW) and resulting in significant losses to IBM. IBM expects its losses to be in excess of £8.5m.”

On 24 January 2017 the TIC Group produced the Pinarello Summary for the Board:

“The recommended option is for GI to take over the IBM work, complete the remaining build on the 1i platform then subsequently operating and supporting, utilising 1i for 3^rd line. The risk for delivery and subsequent support and operations would transfer to Co-Op Insurance and any future chosen partners (inc Group).”

The discussion pack for the Board identified its immediate objectives as building an IT platform to migrate the current trading business, guarantee exit from the COM and complete COM decommissioning by the end of 2018. The options included:

By letter dated 7 February 2017 CISGIL complained to IBM about further slippages that had occurred and the increased costs of the implementation services.

By letter dated 21 February 2017 IBM served a further breach notice on IG:

“…1i has failed to comply with its obligations under the Agreements. We set out below a non-exhaustive list of those areas where 1i has failed to comply with its obligations…

…

The quality of the code provided by 1i as part of its Services under the Agreement is very poor and in breach of 1i’s obligations…

IBM is continuing to suffer losses as a result of 1i’s continued breach of its obligations under the Agreement. These losses are in excess of 1i’s liability caps in clause 21.3 of the MSOW of £7,500,000 per year for the years June 2015 to June 2016 and June 2016 to June 2017 … £20 million…

It is clear from the amount of customisations that 1i has undertaken in developing Release 1 that statements like the above were not true at the time they were made and 1i and IG would have been aware of this given it was your product and you have full knowledge of its capabilities…

It also appear that from the amount of the development work that has been needed in relation to Release 1 that at the time of entering into the Agreements, 1i did not have a base product that was capable of meeting the Customer Requirements …”

The programme update for the TES meeting on 2 March 2017 recorded that IBM’s revised draft plan showed a technical go-live date for Release 1.0 of 26 June 2017 and Release 2.1 of April 2018.

In March 2017 Mr Coomer prepared a paper for the CISGIL board setting out mitigation plans for the project:

“Since the start of NOM Transformation, IBM have consistently failed to deliver upon their contractual obligations, as defined within the Transformation MSA signed June 2015. Furthermore, IBM’s continued unfulfilled promises, further missed deadlines, attempts to shift blame towards GI or their sub-contractors and general lack of credible management across the programme has led CISGIL to conclude that IBM is unlikely to be able to complete the programme within an acceptable timeframe. Whilst IBM have continued to fail, missing their original deadline of April 2016 for new home business and home back book migration, several other key factors are influencing the CISGIL Transformation roadmap.

1)

the Co-operative Bank has exited several platforms shared with CISGIL…

2)

The Co-operative Bank has been put up for sale, increasing CISGIL’s risk on both the shared IT asset estate and our reliance on support services delivered by Bank Colleagues. The first service termination notice has already been received from Bank.

3)

GI Renew has commenced to determine the medium and long term strategic business operating model for CISGIL. Exploring, amongst others, opportunities to move towards a more distribution, member centric model to reduce capital requirements.

The above factors accelerate the needs of CISGIL to create independence from Bank and exit the COM estate. In addition, GI renew may suggest a 10 yr, fixed operating model delivered by IBM is inappropriate for our medium and long term future.”

Thus, by this stage, the risks to the business caused by continuing delays and failures to deliver the project were escalating; at the same time, CISGIL was questioning whether it was commercially advantageous to remain in the ten-year service agreement with IBM.

On 25 March 2017 IBM submitted to CISGIL its invoice for Application Gate 5 in the sum of £2,889,600.

On 27 March 2017 the invoice was rejected by CISGIL and payment was not made.

On 13 April 2017 Addleshaw Goddard, solicitors acting for CISGIL, sent a letter to CMS CameronMcKenna, solicitors acting for IBM, notifying a dispute pursuant to paragraph 2.2 of the Dispute Resolution Schedule (Schedule 19 to the MSA) in respect of IBM’s alleged breaches of the MSA. At paragraph 179 under the heading “set off”, the letter stated:

“By reason of the substantial loss and damage that CISGIL has clearly incurred, as identified above, CISGIL reserves the right to exercise its right to set off any IBM invoices which properly fall due for payment against its much larger claim for damages arising from IBM's breaches. It will assess this on a case by case basis as invoices are tendered or are said to fall due for payment Any decision by CISGIL to make payment of a particular invoice, even if disputed and paid under protest, should not be construed as an acceptance that any other invoices tendered are due and payable or waiver of its general set off rights.”

By letter dated 28 April 2017, CMS sent a holding reply to Addleshaws, indicating that it would provide a substantive response to the allegations and a willingness to mediate the dispute.

On 4 May 2017 Mr Osborne of IBM sent an internal email to Angela Magee, Graham Perrott and Steve Allen, stating:

“The situation with regards to 1insurer delivery capability appears to be unravelling we are finding more and more deficiencies on their plan, quality and estimating. There appears to be a deliberate attempt to hide things from us and divert attention from their own deficiencies and failings.

At this time I am unable to provide an accurate prediction for the completion of either release 1 or release 2 due to lack of clarity from 1insurer and lack of confidence in any estimate or commitments that 1insurer provide.”

On 12 May 2017 Addleshaws sent a further letter to CMS, confirming CISGIL’s intention to exercise its right to set-off its claims for damages against any sums which might otherwise be due to IBM:

“We refer to our letter of 13 April 2017.

At paragraph 179 of that letter we reserved CISGIL's right to set off against any invoices from your client properly falling due for payment (including those falling due on the attainment of a particular delivery milestone) its much larger claim for damages arising from your client's breaches.

We are writing to confirm our client's intention to exercise its right to set off its claim for damages against any amounts which might otherwise be due from CISGIL to IBM.

The attached Schedule sets out losses and costs which our client states it has incurred and are immediately available to set off against such sums. As you will be aware as there is further delay to the Programme our client will suffer further losses and costs caused by your client's breaches which it will also be entitled to set off against any sums that would otherwise be due to IBM.

Should CISGIL make payment of a particular sums due to IBM notwithstanding CISGIL's right of set-off, this should not be construed as an acceptance that any other sums or invoices tendered are due and payable or as a waiver of CISGIL's general right to set off its losses against that particular, or any other sum or invoice. Equally, exercising a right of set off with respect to any invoice should not be construed as an acceptance that the invoice in question or any other invoice is otherwise due and payable.”

A further letter was sent by Addleshaws to CMS on 12 May 2017 stating:

“On 25 March 2017, your client submitted a purported invoice for £2.9 million allegedly with respect to work conducted on the Application Gate 5 milestone.

The purported invoice did not record a unique purchase order number, contained an incorrect and incomplete description of the milestone to which it related and lacked the full name of the relevant Statement of Work and so did not comply with the requirements of clause 11.4 (b) of Schedule 5 (Charges) of the Master Services Agreement. Further, the purported invoice was not submitted to CISGIL in accordance with the agreed procedure.

Critically Application Gate 5 (IMP 30) is phased to take place (in the contractual Roadmap at Appendix A to the Implementation SOW) after Release 1 and 2 Go Live and Motor Data Bulk Migration Complete. However as you know at present neither Release 1 nor Release 2 have gone live. Your client stated in its letter of 7 April 2017 that the indicative revised long stop date for what your client has termed Release 2.1 in its draft revised plan is 11 March 2019 (which, for the avoidance of doubt, CISGIL has not agreed). Although our client has stated that such a long stop date is unsatisfactory, by any measure it is exceptionally premature for IBM to raise an invoice in respect of IMP 30 now. The invoice should not be raised until after IMP 1 - IMP 29 have completed.

Our client has therefore rightly both disputed IBM's right to raise an invoice in respect of Application Gate 5 and refused to provide a purchase order. IBM has stated that it is entitled to raise an invoice on the basis that the Latest Delivery Date for IMP 30 is stated in the Roadmap to be beginning January 2017. However whilst our client has not agreed to any changes to the Roadmap or to IBM's various revised draft plans, at best it is disingenuous for IBM to suggest that the Application Gate 5 payment is due now when IBM has failed to deliver on all but the first key milestones and it is suggesting that the Programme is over 2 years away from reaching the stage when the Application Gate 5 payment would be due according to the Roadmap. In light of this it is inappropriate for IBM to seek a Purchase Order and our client is not obliged to provide one.

If your client does not agree to this analysis then it should invoke the appropriate contractual dispute procedure.

In any event, should any sum be or become otherwise due to IBM in respect of Application Gate 5, our client intends to set off against it its costs and losses as detailed in our letter of 12 May 2017.”

By letter dated 19 May 2017, CMS proposed to Addleshaws that they should enter into discussions with a view to operating the dispute resolution procedure.

By letter dated 2 June 2017, CMS disputed CISGIL’s claimed right of set-off and responded to the points made in respect of the AG5 invoice:

“IBM issued its invoice number 5803171298 on 24 March

2017.

This invoice stated that it was in relation to

“Implementation Services under the Master Services Agreement” and for the Application Gate 5 milestone. Whilst the invoice stated that it was in relation to “IMP-020” rather than “IMP-030”, CISGIL is clearly not in any doubt that this invoice was in relation to IMP-030 - Application Gate 5. CISGIL has already paid the invoice in relation to IMP-020 - Application Gate 4. The invoice states on its face that it relates to Application Gate 5 and the invoice amount reflects the payment for IMP-030 as per Appendix A of the

Implementation Services SOW.

The invoice did not quote a purchase order (PO) number because CISGIL refused to provide one. IBM first requested for a PO number in relation to this milestone at the Commercial Management Group (CMG) meeting on 14 December 2016. IBM again requested a PO number at the CMGs on 26 April 2017 and 3 May 2017.

IBM is required by paragraph 11.5 of Schedule 5 of the MSA to submit an invoice within 180 days of the date on which it completes the relevant milestone, failing which it is barred from recovery of the relevant charges. It follows that CISGIL is required to issue a PO in respect of any milestone whose delivery is not disputed in time for IBM to comply with the 180-day deadline. It is evident from your second letter dated 12 May 2017 that CISGIL does not dispute that the milestone was delivered, it merely objects to it occurring when other unrelated milestones have been delayed. As such, CISGIL cannot now rely on the lack of a PO number being quoted on the invoice as a ground to refuse to pay it; CISGIL is not entitled to take advantage of its own breach.

Your assertion that the IMP-030 - Application Gate 5 milestone is phased to take place after Releases 1 and 2 and therefore, it is premature for IBM to invoice in relation to it, is contrary to the express terms of Appendix A of the Implementation Services SOW. There are no predecessor or successor milestones to IMP-030 and this milestone is not subject to Schedule 6 acceptance as clearly identified in Appendix A of the Implementation Services SOW.

In addition, you acknowledge in your second letter dated 12 May 2017 that CISGIL has not agreed to any changes to Appendix A of the Implementation Services SOW. On that basis CISGIL cannot on the one hand assert that the dates in Appendix A of the Implementation Services SOW have not been amended but on the other refuse to make payment in relation to milestones that have been achieved as per the dates therein.

In light of the above, the Application Gate 5 invoice was due and payable on 4 April 2017. Please arrange for CISGIL to pay this overdue invoice promptly. Failing which, IBM will take steps to enforce its rights without further notice.”

On 20 June 2017 Omnext produced a further report for IBM, containing an assessment of the Insurer source code:

“1Insurer scores 3,00 (out of 5.0) for the structural quality rating. This indicates that the source code of 1Insurer can be considered as source code with a medium maintainability risk.

When looking at the different structural maintainability risks, duplication, unit size and complexity can be considered as quality attributes with a medium to high maintenance risk…

In addition to the areas of concern in the field of maintainability the number of blocking and critical violations in the source code regarding coding standards can be considered as high. In the source code 6,135 blocking and 31,797 critical violations are found.

Based on the maintainability risks and standards & guidelines violations the technical debt of 1Insurer is estimated on approximately 26,000 hours.”

Stephen Allen, project manager for IBM, accepted that IBM would have to undertake a significant amount of work if it chose to exercise its step-in rights and take over IG’s obligations. Firstly, IG’s approach of copying the base code and customising it for Release 1, rather than developing CISGIL-specific modifications within the source code, required IBM to transfer all the configurations and the source code customisations in Release 1 into Release 2. Secondly, IBM would have to retrofit all defect fixes into Release 2. Thirdly, some customised parts of Release 1 had been made redundant by new functionality in version 7.6, issued on 13 October 2016, such as the portals, aggregators and interface elements. Fourthly, although IG had carried out significant remediation work, IBM would have to carry out any outstanding upgrades required to the FOSS components and maintain them. Fifthly, regression testing, system testing, SIT, and UAT would have to be carried out in respect of the outstanding work. Finally, IBM would be responsible for ongoing maintenance in respect of the system, which was likely to be higher than expected for a newly developed solution as a result of the large number of violations against industry standard guidelines.

IBM’s position was that it could resolve the difficulties with IG and deliver the solution. It is clear that by this stage, the project had become very challenging.

On 22 June 2017 IBM served a Final Notice pursuant to clause 26.7 of the MSA:

“We refer to our invoice dated 24 March 2017 in the sum of £2,889,600, invoice number: 5803171298 (the "Invoice").

Pursuant to paragraph 11.7 of Schedule 5 of the MSA, the Invoice was due and payable by 4 April 2017. To date we have not yet received payment. It is now over 45 days since the Invoice was due and payable. As such we hereby give you notice that if the Invoice is not paid within the next 15 Business Days we intend to terminate the MSA as per clause 26.7 of the MSA.

IBM reserves all of its rights in full.”

In anticipation of the termination, Mr Coomer of CISGIL devised a protocol for actions to be taken to secure the IT system in his updated ‘Armada plan’ dated 17 July 2017.

On 18 July 2017 Mr Coomer produced a document entitled ‘Blenheim - Update and Proposed Transition Roadmap’ for discussion:

“Over the past several months, a detailed analysis of alternative options to transform the GI business, in the event of IBM failure, has been conducted under the codename Blenheim. This pack describes the proposed Blenheim end state and various transition states to achieve transformation without IBM…

Key Objective

Exit the Bank and COM estate whilst delivering a target business and technical architecture which supports the business strategy of distributing and underwriting insurance products to meet our members’ and customers’ needs, keeping in mind the Co-op purpose.”

On 27 July 2017 IBM served its notice, purporting to exercise its right to terminate under the MSA. Before the letter was sent, Mr Perrott of IBM and Mr Summerfield of CISGIL spoke by telephone to confirm IBM’s intention to terminate. In their discussion, neither party attempted to avert the impending termination.

By letter dated 28 July 2017 Addleshaws informed CMS that CISGIL considered IBM’s termination notice to be invalid and repudiation of the MSA, which repudiation was accepted by CISGIL.

CISGIL’s position is that at termination in July 2017, the project was seriously in delay. User acceptance testing for Release 1 had still not been completed and was about 1 year, 4 months behind programme. Although CISGIL had been told that the date for Release 1 Go Live with aggregators was June 2017, IBM had internally recognised that this would not be achieved before November 2017. Release 2 was still in the process of being built and IBM had put forward no credible plan for completion. On 7 April 2017 the anticipated delivery date for Release 2.0 was September 2018 and the delivery date for Release 2.1 was March 2019. CISIGL considered that the project was out of control. If the time lapse between Release 1 and Release 2 grew significantly greater that or original planned three months, the cost and feasibility of running the business across two platforms would become impracticable. Against the history of missed forecasts, CISGIL had no confidence in IBM’s ability to deliver the project.

IBM’s position is that as at termination, IG was significantly behind programme, particularly in defect correction, and substantial additional resources would be required to correct the deficiencies in the software but it would have been possible to deliver the IT solution. However, CISGIL’s refusal to pay the AG5 milestone was the tip of the iceberg. It made clear to IBM that not only would the invoice not be paid but that no further invoices would be paid and IBM would be expected to complete the project without recompense, after which CISGIL would claim its losses arising out of the delays. IBM was not prepared to continue the project on that basis.

Mr Summerfield explained in evidence that, following termination of IBM’s involvement, CISGIL entered into an initial contract with CDL Strata in respect of an alternative platform but ultimately decided not to proceed with them. In Autumn 2017/early 2018 the strategic direction of the Co-op Group changed. It decided to move away from capital intense businesses, including insurance, and moved towards a distribution business.

In February 2018 the Co-op Group entered into a contract to sell CISGIL to Markerstudy. The Bank separated from the Group in January 2020.

Project Cobalt was a failure. The parties abandoned unfinished a project that had consumed costs in excess of £120 million, leaving them with a system offering little or no value and substantial financial losses.

On 18 December 2017 CISGIL initiated these proceedings, claiming damages from IBM.

CISGIL’s pleaded case is that:

Damages claimed are based on wasted expenditure and/or losses incurred as a result of the breaches.

IBM’s pleaded defence is that:

IBM disputes quantum and has a counterclaim for payment of the outstanding AG5 invoice.

The issues can be summarised as follows:

The court heard evidence from the following factual witnesses:

Both parties submit that their witnesses were straightforward and honest. It has been suggested that some of the witnesses were untruthful or misleading. I reject the general attacks on the honesty and integrity of the witnesses. It is clear that they formed their own views on certain key issues of rights, responsibilities and blame for the failure of the project. It is likely that those views have been reinforced by reading the documents, pleadings and submissions through the prism of the legal analysis provided by the legal representatives of both parties. The passage of time will have clouded some recollection of events. It does not follow that the whole of their evidence is inaccurate or unreliable.

Given the number of issues in the case, it is unlikely that it would turn on the evidence or credibility of one witness. In a case such as this, where so much was documented at the time that events unfolded, it is necessary to consider each part of the factual evidence from the witnesses against the evidence of other witnesses and the contemporaneous documents in order to determine on the balance of probabilities what happened.

The court received reports and heard the oral evidence from the following experts:

Unfortunately, this case was an early victim of disruption caused by the COVID-19 pandemic. The quantum experts completed their evidence on Thursday 19 March

Subsequently, the parties agreed that closing submissions and reply submissions would be delivered in writing with no oral hearing. Although the Court was deprived of oral argument in closing, I am grateful to the parties for their clear and comprehensive written submissions.

It is common ground that IBM’s future performance under the MSA was terminated in July/August 2017. The issue for the Court is whether IBM exercised a valid right of termination by reason of CISGIL’s failure to pay invoice AG5, or whether its purported termination amounted to repudiatory breach, which repudiation CISGIL was entitled to, and did, accept.

CISGIL’s case is:

IBM’s case is:

CISGIL required a number of software licences from IBM and third parties for implementation and operation of the new IT solution.

On 5 January 2015 Ian Bowen of IG sent an email to Chris Jackson of IBM, indicating that IG would need a licence agreement in place before it would release any software to CISGIL:

“Although the draft contract from Co-op gives some protection re IP it does not allow for licences that Co-op will need if they are to start training and developing in workshops. Tom has made it clear in the plan that we cannot undertake activities that require licences at this stage until a licence agreement is signed…

We identified … approximately 2,500 man days that we have provisionally committed to develop in the base product, in timeframes that meet the Co-op requirements, to deliver at no cost to the Co-op or IBM… At the moment Co-op is leading the requirements for the base product and has priority. To sustain this we need a licence contract as soon as possible as this is what funds the development. You know from the meeting in December we are expecting a one off perpetual licence of £4m…”

Initially, IG’s position was that it wanted payment of the £4 million licence fee in full from IBM at the outset.

On 20 January 2015 IBM sent an email to CISGIL, explaining the need for the software licences before conclusion of the MSA:

“IG are committing to incorporate 2500 days of development that Co-op have identified as required into the core product. This development will commence as release 7.5 which is scheduled to start from 09/02/15 to ensure all functionality is available for Co-op in good time for go live January 2016. Signed licence agreements drive roadmap development and without a signed licence it is likely Co-op requirements currently prioritised for 7.5 will be deferred to 7.6 in favour of other customers who have signed licences…

To ensure we can install Insurer for Co-op and begin using the system as part of Solution Design we propose a separate SOW under the ISA that allows IBM to sub-licence the software to Co-op. This will be for the full Insurer perpetual licence of £4m but with an exit point after the ISA SOWs are completed if Coop do not proceed. Once the MSA is signed the balance of £3m will be payable in instalments and there are no further exit points. Each payment is non-refundable once made even if Coop do not proceed…”

By email dated 27 January 2015 CISGIL responded positively to the suggestion that software licence payments would be required prior to the MSA but subject to appropriate commercial terms.

On 13 March 2015 Mr Bowen threatened that IG would stop working on the project unless a contract was concluded with a commitment to payment of the licence fees.

On 27 March 2015 IBM and IG entered into an agreement (“the Licence Agreement”) whereby IBM agreed to pay IG a licence fee of £3.5 million in three instalments:

In May 2015 CISGIL expressed concern that it would not be able to meet the capital costs of the project whilst keeping its solvency risk ratio in alignment with that agreed by the PRA, as explained by Mr Summerfield in his witness statement:

“CISGIL has to be able to demonstrate to the PRA that its costs and expenditure are adequately funded and affordable. It also has strict capital requirements. As an insurance company it must hold sufficient capital to cover unexpected losses and to ensure it can meet its obligations to policyholders. It has a Minimum Capital Requirement and a Solvency Capital

Requirement – the latter is calculated in line with a prescribed standard formula which gives a capital ratio percentage. If an insurer's capital ratio falls below 120%, then the insurer will typically come under close scrutiny from the regulator.

CISGIL's capital is projected on a two-year forward looking basis. The Board sets its capital risk appetite. For a number of years, the capital ratio set by the Board was 130%, giving a 10% buffer over the PRA's recommended solvency / capital requirement. Given the scale of the transformation programme and the sensitive nature of capital ratio which can fluctuate easily, I wanted to take a prudent approach when considering the financial aspects of the project. My view (which was adopted by the Board) was that we should target a capital ratio of 140% to ensure that CISGIL's capital was sufficient to withstand any adverse events along the way.”

CISGIL entered into discussions with IBM, centred around displacing some of the capital commitment for the project from 2015/16 to a later fiscal period (‘financial smoothing’). Part of the solution entailed moving some of the capital costs of the project into the management services phase, as suggested by Mr O’Keeffe, then CISGIL’s chief finance officer. It was agreed by the parties that £9 million of engineered costs and revenue would be moved from 2016 to 2017.

The parties also agreed to staged payments for the software licence costs needed for implementation of the new IT system, using financing for the first two years and adjusting the payment profiles under the MSA in subsequent years to pass those costs through to CISGIL. This arrangement was explained by Mr Down, the bid manager for IBM, in his witness statement:

“IBM arranged for a structure where Innovation Group (“IG”) was to buy the IBM software product licences from IBM software group and in turn license those products to IBM as part of the IG contract. IG’s purchase of IBM software product licences was in turn funded by a loan from IBM Global Financing to IG.

I updated the Charges Profile on 26 May 2015 to reflect what had been agreed. The IBM software payment date moved from June 2015 to January 2017 and the other software payments were smoothed across the 3 years.

I created an updated Charges Profile on 4 June 2015 where software payments (“Software” and “SaaS” (software as a service) under the heading “Implementation SOW”)) were set across 6 dates in May 2015, June 2015, September 2015, December 2015, March 2016 and January 2017.”

On 21 May 2015 Oscar Brennan explained the proposal to Graham Asquith in an internal IBM email as follows:

“For the £2.4m in March next year we can move all of this into Jan 2017 when IG will need to settle back to IGF. My assumption is that this is when you will bill CISGIL for this amount and IG will be made whole. There is as you can see an interest costs of £100,714 to finance this…

IGF Pricing

1.

£2.4m plus VAT financed March 2016 has following profile:

Amount financed £2,880,000 Payments:

January 2017 £2,980,714

Interest cost therefore £100,714

2.

£500K plus VAT financed May 2015 has following profile:

Amount financed £600,000

Payments:

March 2016 £254,358

January 2017 £381,534

Interest cost therefore £35,892 …”

The Project Cobalt implementation and run charges spreadsheet dated 26 May 2015 included under ‘Fixed Price’ for implementation services the base cost sum of £2,408,000 payable for IBM software in January 2017.

On 4 June 2015 Mr Gilroy, the CISGIL IT transformation manager, sent Ms Barnes of IBM a draft of the proposed payment schedule for the Implementation SOW, stating:

“Total figures are notional at the moment … We will also add milestones to reflect the payments required for S/W & H/W pass-through… ”

Following comments in response from IBM, on 4 June 2015 Mr Gilroy sent Ms Barnes a further draft of the proposed payment schedule for the Implementation SOW. The schedule linked payments to the delivery of specific milestones, save for the payments in respect of IBM, IG and other third party software. The software payments, a total of £7.696 million, were spread over five payments, which were not explicitly linked to any activity and were described as “committed software passthrough spend” items. The software payments included a payment of £2.89 million at the beginning of January 2017.

At a meeting on 8 June 2015 the parties agreed that the ‘software payment’ items in the Implementation SOW spreadsheet would be re-named ‘Application Management Gates’. Ms Barnes’ unchallenged evidence on this was:

“I attended with Mr Punwar, Mr Bolton, Mr Webb, Mr Gilroy and Robert Garwood of CISGIL’s solicitors, Addleshaw Goddard. At this meeting we went through the Implementation SOW line by line finalising the details. One of the details we discussed was the change of the naming convention for

“software payments” to become “Application Management Gates”. This was because CISGIL did not want to use the term “software payments” as they (at least Mr Bolton, Mr Webb and Mr Gilroy based on my discussions with them) thought it showed or suggested ownership of the software and they wanted to avoid this. I agreed to the change on the basis that this did not actually change the meaning or the substance of what these payments were.”

On 10 June 2015 the description was revised to ‘Application Gates’ by CISGIL but with the comment “Committed Software pass-through spend” retained against the software summary line.

On 16 June 2015 the MSA, the Implementation SOW and the Managed Service SOW were executed by the parties.

Paragraph 1.1 of the Implementation SOW stated:

“The Supplier shall provide the following Services and Deliverables to the Customer in accordance with the Terms of the Agreement and this Statement of Work, in order to implement the Solution.”

Paragraph 1.5 identified specific functions that IBM was required to perform, including at 1.5.4:

“a)

Implement all the applications required to deliver, operate and manage the Solution, such applications shall be based on the Architecture Software Bill of Materials (DLV-003);

b)

Source, configure “Out of the Box”, test and deploy, as required, versions of Software and data in all technical environments necessary to deliver, support (including

training facilities) and develop the Solution to meet the Customer Requirements.”

By paragraph 1.5.10, IBM was required to deliver the Deliverables, including the

Paragraph 3 (Delivery Timetable) of the Implementation SOW included:

“3.3

The Supplier shall deliver the Deliverables and Services in line with the delivery dates as set out in Table A.1.

3.4

The Deliverables and Services in Appendix A represent a combination of significant programme milestones and key gating points within the project management methodology for each of the technology Releases. This Appendix A manages the pathway from confirming acceptance and testing requirements, through the design, build and testing of the technology associated with each Release, data migration and finally the transition to live and implicit handover of the service to the Managed Service (delivered via a separate SOW).

3.5

The Supplier shall ensure that each Service and Deliverable is Ready for Use by the applicable Milestone Date, Key Milestone Date or other date of delivery specified in Table A.1 in Appendix A or in accordance with the Implementation Plan as applicable.”

Paragraph 5.1.2 (Fixed Price Component) of the Implementation SOW stated:

“5.1.2.1 The Charges for fixed priced components are payable in line with milestone payment schedule set out in the Roadmap at Table A.1 in Appendix A to this SOW.

5.1.2.2 In respect of each Milestone, [IBM] shall be entitled to invoice the amount set out in column [L] of the Roadmap, on such Milestone being completed in accordance with the terms of this Agreement.”

The contractual milestones set out in Schedule A to the Implementation SOW at Table A.1 included the ‘Application Gates’:

Paragraph 4.1 of the Implementation SOW distinguished between milestones which were subject to ‘acceptance tests’ and ‘acceptance criteria’ as provided for by clause 6 and Schedule 6 of the MSA, and milestones that were not subject to such acceptance tests or criteria.

Paragraph 4.1.1 stated:

“Pursuant to clause 6 of the Agreement, the Deliverables or Services which will be subject to Acceptance will be identified and the tests (and test cases) that are to be carried out by the Supplier and the relevant Acceptance Criteria will be agreed between the parties as part of IMP-005, IMP-008, IMP-010, IMP-028 in Appendix A of this SOW.”

Table A.1 of the Implementation SOW included the word “No” in column H against each of the five application gate milestones, identifying that they were not subject to Schedule 6 Acceptance.

Para.4.1.2 of the Implementation SOW stated:

“Where Appendix A of this SOW identifies a direct predecessor Milestone Serial No on which that Deliverable is dependent, the predecessor Milestone must be completed prior to the relevant Deliverable or Service being completed.”

Table A.1 of the Implementation SOW included the letters “n/a” in columns E and F against each of the five application gate milestones, identifying that none of the application gate milestones in the Roadmap had any direct predecessor (or successor) milestones set against them.

Paragraph 4.1.4 stated:

“Where Appendix A specifies that a Milestone is not subject to Acceptance (in accordance with schedule 6), the criteria and process for completing such milestone (including the sign off process) shall be articulated as part of the Implementation

Plan.”

The implementation plan produced by IBM for IMP-003 did not include reference to the criteria or process for completing the five application gate milestones (or the other milestones where Schedule 6 Acceptance was not specified).

Paragraph 4.2.1 of the Implementation SOW stated:

“CISGIL Transformation Director or CISGIL IT Director shall be responsible for agreeing in writing that a Deliverable or Service has met the Acceptance Criteria and has been accepted by the Customer.”

Table A.1 of the Implementation SOW stated that the ‘Nominated Customer Approver’ for each of the five application gate milestones was the ‘Customer Transformation Director’. The Customer Transformation Director identified in paragraph 9.2 of the Implementation SOW was Alison Neate (and from mid-2016 this role was performed by Richard White).

The milestone sign off process, the milestone change control process and the IBM Purchase Order to Payment processes were produced and reviewed at the TES meeting on 8 August 2015. The Purchase Order to Payment process document provided for the following procedure to be followed:

As Mr Tozzi QC, leading counsel for IBM stated, IBM could only follow the above payment process if Mr Phillpott of CISGIL sent a purchase order number to IBM in respect of any payment due. The document did not provide for what IBM should do if CISGIL wrongly failed to provide a purchase order number.

Application Gate 1 (milestone IMP-004) had a latest delivery date of end June 2015 shown in the Roadmap.

Following a query raised by Mr Phillpott regarding the procedure for approving this milestone, on 13 July 2015 Mr Webb of CISGIL sent an email to Ms Barnes of IBM, stating:

“Can you remind me of OUR thinking at the time. I believe the intent was that Tom Hardcastle would be approver for the Application gates – but I need to be reminded of the actual delivery. I know Imp-004 is purely about licence costs and that in practice Alison could/should have been the approver. What’s your view on the remaining application gates and what is actually being approved – none of which are Key Milestones or subject to schedule 6 acceptance.”

On 15 July 2015 Mr Webb sent an internal email to Mr Phillpott:

“I have confirmed that all Application Gates in the Implementation SoW are for pass-through licence costs. On this basis, Alison should provide the approval / sign-off – not Tom Hardcastle.”

That email was also sent by Mr Webb to Ms Barnes:

“See below regarding approver for Application Gates. As these only relate to pass through license costs – can Alison be shown / given something which evidences them being incurred for the purposes of the approval?”

On 22 July 2015 Mr Phillpott sent a further email to Ms Barnes in respect of the signoff documents for Application Gate 1:

“My understanding is that this gate is a pass through of licence charges. To enable sign off when you invoice for this gate can you send through evidence for this pass through please?”

On 4 August 2015 Mr Phillpott sent a further email to Ms Barnes:

“To manage expectations – I am not after the invoice – I’m after the evidence that would enable sign off…”

In response, Karen Delaney-Reed at IBM sent a table, setting out the scope of the Application Gates:

“This should help give you the traceability within the MSA to confirm invoice approval for Application Gate 1 and future Application Gates.

The Application Delivery Phases, relate in summary to the Applications detailed below, the full list of Applications are contained in Schedule 5, referenced in section 13 Product List and detailed in Appendix H.

Note: The initial 1/7^th payment for the Insurer Product was paid during the Solution Outline phase.”

Applications	Implementation SOW Fixed Price: Application Gate Scope
	Gate 1	Gate 2	Gate 3	Gate 4	Gate 5
IBM SaaS Products	July to Sept 2015	Oct to Dec 2015	Jan to Mar 2016	Apr to Jun 2016
Oracle Fusion SaaS Products	July to Sept 2015	Oct to Dec 2015	Jan to Mar 2016
Insurer Products	Commitment Increment of 1/7th	Commitment Increment of 5/7th
SAS Products	July 2015 to Sept 2016
IBM Software Products					July 2015 to June 2016
Milestone Payment	£1,329,000	£3,412,000	£202,000	£133,000	£2,890,000
Milestone Number	IMP-004	IMP-009	IMP-017	IMP-020	IMP-030

On 12 August 2015 Katie Hyman, lead commercial manager at IBM, sent the invoice in respect of Application Gate 1 to Mr Phillpott, Ms Neate, Ms Bradley and Mr Webb of CISGIL, in the sum of £1,328,614.80. A back-up table was also sent, as per the table above but showing the precise amounts for each milestone payment and the invoice number for Application Gate 1.

CISGIL paid the invoice for Application Gate 1.

Ms Hyman was cross-examined about the invoice process used:

“Q. There then comes a time, 12 August, where you start to you email invoices to purchase2pay and to the names that we see there, Tom Phillpott, Alison Neate, Kay Bradley and Kevin Webb, do you see that?

A. I don’t think at this stage I was sending to purchase2pay. I think these were paper copies…

Q. Why were you sending them to Alison Neate, Kay Bradley and Kevin Webb in addition to Tom Phillpott at this stage?

A. Because in conversation Tom asked me to… I remember my conversation with Tom, he was very anxious about the seven days payment terms, he was very anxious that he knew what was coming, so we would regularly talk in person so that he had no surprises, and he asked me to send copies to these people…

Q. Can I suggest that the real reason why you sent the email invoices to those representatives is because you’d had a discussion with Ms Barnes and she told you about the purchase order to pay process?

A. That’s not correct, no.”

Whatever the basis for the initial invoicing procedure, Ms Hyman explained in her witness statement that it was changed in late 2015:

“Initially, I would formally submit the invoices by post and also send copies via email…

In late October 2015, the invoicing team at IBM advised me that in order to send invoices electronically (including by copy) they needed to be an image or a PDF so that they were not capable of being edited. I was advised that, if CISGIL actually wanted to be billed electronically, a formal system would need to be set up…

On 3 November 2015 I had a conversation in CISGIL’s office in Arndale with Ms Bradley, who confirmed that CISGIL definitely wanted to move to the e-billing system and specifically asked for CISGIL’s accounts payable email address, purchase2pay@cfs.coop (“Purchase2pay”) to be used… I had a similar conversation with Mr Phillpott around the same time. My understanding from these conversations was that once Purchase2pay had received the invoice, the accounts payable team at CISGIL would then send the invoice on for internal approval.

Following these conversations, I contacted colleagues in the invoicing team at IBM to set up the internal process to allow for invoices to be sent to Purchase2pay, as requested by Ms Bradley and Mr Phillpott.

As a result of CISGIL’s request, we changed the formal process for submitting invoices, replacing sending invoices by post with a quicker process where invoices would be sent via email to the Purchase2pay address. On 16 December 2015, I sent Ms Bradley confirmation that, after successful ‘end-to-end’ testing, the e-billing service had gone live.

Once this was set up, invoices, when raised, were automatically submitted directly to CISGIL by IBM’s e-billing system via email to Purchase2pay instead of being posted.

IBM’s internal systems allow me to download a copy of the invoice once it had been submitted. When the invoice was available, I would download a copy of this and send this, together with any agreed backup information, by email as I had done previously… I did this because I was aware that Mr Phillpott was anxious about the 7-day payment commitment and I wanted to give him copies of the invoice and backing data as quickly as possible…

With the copy of each invoice, for the Application Gates 1-4 invoices, I sent a spreadsheet which set out the amount due in respect of each Application Gate and which software payments it covered… The list of software was a straight copy from the contract and the spreadsheet covered all 5 Application Gates. It was always the same spreadsheet.

The purpose of sending the information separately was to help Mr Phillpott so that he was able to review the invoice before he received it from CISGIL’s accounts payable team. He would therefore know in advance what was coming and what he would be asked to authorise accounts payable to pay within the 7-days contractual timeframe. The automated invoice to Purchase2pay did not allow backup information to be attached so this was only sent with the emails I sent attaching the copy invoices as mentioned above.”

That explanation is supported by the contemporaneous documents. Early invoices were sent, with supporting documents, by Ms Hyman to the named CISGIL individuals but not to the Purchase2pay email address.

On 3 November 2015 Ms Hyman stated in an internal email:

“Have discussed with Co-Op today. They definitely want to move to electronic billing – the email address is purchase2pay@cfs.coop.”

On 11 November 2015 Ms Hyman sent details of the CISGIL accounts department and customer number to Ms Pett, stating:

“My contact in the Co-Op, Kay Bradley, said that the email address that should be used is purchase2pay@cfs.coop – they just want the invoices emailed to them.”

On 16 December 2015 Ms Hyman sent an email to Ms Bradley at CISGIL, stating:

“As promised we’ve set up the e-invoicing and I’m told I need to send you this ‘official’ confirmation! Co-op General Insurance has gone live today for ePDF and we will deliver the invoices to: purchase2pay@cfs.coop.

IBM UK Ltd are responding to your request for us to enable einvoice solutions using an ePDF solution. Accordingly, to confirm we will deliver e-invoices to you relating to IBM products and/or Services…”

Thereafter, the invoices were submitted via the e-billing system. Copies of the invoices were emailed to Mr Phillpott, cc’d to various others, including Ms Neate, Ms Bradley, Leah Noakes of CISGIL and Ms Barnes of IBM.

CISGIL paid the invoices for Application Gate 2 and Application Gate 3.

By March 2016, IBM had failed to complete delivery of the Release 1 functionality through IMP-018c. In an email dated 18 March 2016 Mr Phillpott discussed with Ms Neate the anticipated submission by IBM of the invoice for Application Gate 4 and stated:

“While you are away – IMP-020 will probably come in. This is the £133k Application gate four. As this is separate from IMP018 I believe our position is to pay this. (I will send separate authorisation request to keep things clean).”

The invoice in respect of Application Gate 4 was submitted by IBM to CISGIL on 12 April 2016. The invoice was paid following Mr Phillpott’s recommendation:

“This is an Application Gate invoice and not a delivery gate as such… I confirm I had this item accrued at the end of March… Unless you are aware of any commercial discussions that might impact the payment of this invoice – Then I would recommend payment of this invoice.”

At the Commercial Management Group (“CMG”) meeting held on 14 December 2016, Ms Barnes of IBM requested that CISGIL should release Milestone 30 – Application Gate 5 payment of £2,890,000. Mr Phillpott confirmed that this was not due until early January 2017. He stated that he would check with Richard Houghton (the chief financial officer of CISGIL) and Mr Summerfield as their approval would be required for the purchase order.

By email on 16 December 2016 Mr Phillpott reported IBM’s request to Mr Houghton and confirmed his view that:

“Application gate 5 is due at the beginning of January … The salient point is that I am not planning to start discussing / requesting the approval of Application gate 5 until 2017.”

Mr Summerfield was aware that by the end of December 2016 IBM wanted CISGIL to authorise a purchase order for the Application Gate 5 milestone but he did not believe that the AG5 payment was due and therefore was not prepared to authorise a purchase order, as explained in his witness statement:

“My view at the time was that given the chronic delay in delivery of the solution and IBM's failure to deliver key milestones, payment for AG5 was not yet due. I know from conversations I had with Richard Houghton at the time that he shared my view. AG5 was the penultimate payment under the Implementation SOW and we were nowhere near go-live for Release 1 or Release 2. As I did not believe that the AG5 payment was due, I was not prepared to authorise a purchase order to allow IBM to bill another £2.4 million.”

On 11 January 2017 Mr Phillpott sent an email to Mr Houghton, indicating a change in his position as to the AG5 milestone:

“We technically have 2 IBM Milestones Payments due in January per existing contract I have, that don’t have delivery attached per se …

More important is the stance on AG5 for £2.89m. The line here I will use here unless advised otherwise is “I will begin the PO raising process when advised by RH.” This is in our forecast in January. Although my personal view point is that this was envisaged to be paid after the Release 2 Go Live and Motor Date Migration is complete - Therefore this would be when we would look at this payment. Obviously that is a simplistic and not a holistic view point not taking into account wider commercial discussions.”

On 25 January 2017 Mr Phillpott sent a further email to Mr Houghton:

“I have been asked for a forecast so that your team can include from a cash flow forecast.

Application gate 5 is in Early January 2017 per the current contract. I will therefore include in January – and include a caveat that it is unlikely that this will be paid in January. Value is £2.9m.

If you have a different steer – please could you let me know?”

Mr Houghton’s response was:

“No way it will be paid then, suggest put into february.”

On 31 January 2017 Mr Phillpott sent the breakdown of the software for the application gate invoices to Chris Rielly (IT finance business partner at CISGIL):

“This has a breakdown of the Software, SaaS and PaaS etc below. This is related to the application gates and specifically Application gate 5 which is the £2.9m … with regards to Milestone payments in 2017.”

On 14 February 2017 Leah Noakes, supplier manager at CISGIL, expressed surprise to Mr Rielly that there were no outstanding IBM invoices and noted that IBM had stopped asking about application gate 5. Mr Rielly responded that he would check the records for any invoices.

On 21 February 2017 Ms Noakes had a further email exchange with Mr Rielly, in which she stated:

“We’ve been expecting IBM to invoice for Application Gate 5 £2.89m. They know we’d probably dispute, and we haven’t seen it yet…

I don’t think we ever raised a PO, it would be good to check. ”

Despite the absence of a purchase order from CISGIL, on 24 March 2017 IBM submitted an invoice in the sum of £2,889,600 in respect of the Application Gate 5

Jonathan Smith, risk consultant and delivery excellence SME at IBM, understood that the invoice was controversial:

“I confirm that the issuing of the invoice is more a leverage tool. Contractually the client should have issued a PO as there are no acceptance criteria around this milestone (it is datebased), but we do expect it to provoke a response from the client, and until we see the responses, we should ensure no revenue is recognised.”

On 27 March 2017 Rachel Clough, of CISGIL’s invoice processing support team, sent the following response to IBM:

“Please can this invoice be re-submitted with the correct Purchase Order Number quoted on it.

We cannot accept this invoice for payment without a Purchase Order Number quoted on the invoices.”

There is no dispute as to the approach by the Court to questions of contractual interpretation. When interpreting a written contract, the Court is concerned to ascertain the intention of the parties by reference to what a reasonable person, having all the background knowledge which would have been available to the parties, would have understood them to be using the language in the contract. It does so by focussing on the meaning of the relevant words in their documentary, factual and commercial context. That meaning has to be assessed in the light of (i) the natural and ordinary meaning of the clause, (ii) any other relevant provisions of the contract, (iii) the overall purpose of the clause and the contract, (iv) the facts and circumstances known or assumed by the parties at the time that the document was executed, and (v) commercial common sense, but (vi) disregarding subjective evidence of any party's intentions: Arnold v Britton [2015] UKSC 36 per Lord Neuberger Paras.15-23; Rainy Sky SA v Kookmin Bank [2011] UKSC 50 per Lord Clarke Paras.21-30; Chartbrook Ltd v Persimmon Homes Ltd [2009] UKHL 38 per Lord Hoffmann Paras.14-15, 2025.

The natural and ordinary meaning of the Roadmap, read together with paragraphs 4.1 and 5.1.2 of the Implementation SOW, was that the AG5 milestone payment obligation became due at the beginning of January 2017 for the following reasons.

Firstly, the Implementation SOW and the Roadmap did not articulate any criteria for completing milestone AG5 beyond delivery of the IBM software licences. The IBM software licences were a software deliverable within the meaning of the Implementation SOW and were identified in paragraph 13 and Appendix H to Schedule 5 of the MSA; they formed an essential part of the overall IT solution but they were distinct from the Releases for which separate completion criteria were identified in the Roadmap.

Secondly, the Roadmap explicitly stated that the AG5 milestone was not subject to any formal Schedule 6 acceptance procedure, such as review, testing or acceptance, in contrast to the Release 1 and Release 2 acceptance milestones, which were subject to Schedule 6 acceptance procedures.

Thirdly, the AG5 milestone had no direct predecessor milestones; as such, it was a free-standing milestone and was not dependent on completion of prior milestones pursuant to paragraph 4.1.2 of the Implementation SOW. It would have been open to the parties to agree that the AG5 milestone should be dependent on achievement of the Release 1 Go Live and Release 2 Go Live milestones but they did not provide for it to be linked to the progress of other project activities in the Roadmap or elsewhere in the Implementation SOW.

Fourthly, although paragraph 4.1.4 of the Implementation SOW provided for the parties to agree the criteria and process for completion of any milestones that were not subject to Schedule 6 acceptance procedures, the parties did not include such criteria or process for the application gate milestones in the implementation plan. The Purchase Order to Payment document identified the sign off process that was generally applicable for purchase orders but it did not address the basis on which any milestone would be considered to be completed or certified as such.

Fifthly, paragraph 4.2.1 of the Implementation SOW provided for the CISGIL

The factual matrix supports IBM’s position that both parties recognised and understood that the application gates were five stages of a committed payment for offthe-shelf software licences and they did not relate to project progress. The fixed cost of the software licences for the project was initially anticipated to be incurred in 2015. However, as set out above, the parties agreed to structure the payments so that they became due in stages, with the last stage payment for the licences being deferred to January 2017. To facilitate this arrangement, IBM arranged for IG to buy the necessary licences using a loan from IBM Global Financing, which was subsequently to be repaid when CISGIL paid the Application Gate instalments.

CISGIL submits that achievement of the Release 1 Go Live and Release 2 Go Live milestones were pre-conditions for achievement of the AG5 milestone. In support of that argument, it relies on the definition of ‘Licensed Purposes’ in clause 10.1 of the

CISGIL submits that the ‘Solution’ was the whole of the web-based platform which included but was not confined to software. As a practical matter, CISGIL could not use the software for the Licensed Purposes until Release 1 go-live. Reading the Implementation SOW with clause 10, it is impossible to divorce the software licence payments with which each application gate was concerned from the delivery of software and the overall delivery of the Solution for which CISGIL was licensed under the MSA.

That argument, based on commercial efficacy, is not sufficient to displace the plain and natural meaning of the Roadmap, when construed against the factual matrix. It is self-evident that the software could not be used for the ‘Licensed Purposes’ until the relevant insurance platform was live but business use of the software was not a stated criterion for achievement of the application gate milestones; the parties knew and understood at the time of the MSA that the application gates did not reflect progress of the implementation phase but the software licence costs. Those software licence fees would have been payable at the outset of the project but for the arrangement whereby they were financed through IG and IBM Global Finance so that CISGIL could pay them in later stages through to 2017.

CISGIL submits that IBM did not take any steps to obtain approval from the Nominated Customer Approver and the Application Gate 5 milestone had not been approved by Mr White, the Customer Transformation Director in 2017. However, there was no formal approval process for those milestones that were not subject to the Schedule 6 acceptance procedure. The four earlier application gate milestones were approved without any formal document submission beyond the table prepared by Ms Delaney-Reed, showing the basis on which the application gates were due. IBM made a clear request for a purchase order in respect of the AG5 milestone at the CMG meeting on 14 December 2016. The AG5 milestone became due and payable at the beginning of January 2017. CISGIL was obliged to approve the milestone and to issue a purchase order number for the same.

I accept IBM’s submission that CISGIL can’t rely on the absence of approval to withhold payment of the AG5 milestone where such approval was wrongfully withheld. In Alghussein Establishment v Eton College [1988] 1 WLR 587 the House of Lords held that the appellant tenant was not entitled to rely on its own failure to carry out the development of property to enforce a provision in the agreement requiring the respondent landlord to grant a lease of the property. Having considered the authorities on this point, Lord Jauncey stated at p.594C:

“Although the authorities to which I have already referred involve cases of avoidance the clear theme running through them is that no man can take advantage of his own wrong. There was nothing in any of them to suggest that the foregoing proposition was limited to cases where the parties in breach were seeking to avoid the contract and I can see no reason for so limiting it. A party who seeks to obtain a benefit under a continuing contract is just as much taking advantage of his own wrong as a party who relies on his breach to avoid a contract and thereby escape his obligations.”

CISGIL was obliged to approve the achievement of the AG5 milestone in January 2017. That obligation was owed to IBM under the terms of the MSA, the Implementation SOW and the Roadmap. In breach of its obligation, CISGIL failed to approve the milestone. CISGIL is not entitled to benefit from its own default in seeking to avoid payment by asserting the invalidity of the AG5 invoice based on the absence of approval.

For the above reasons, I reject CISGIL’s case that the Application Gate 5 milestone was not due in January 2017 because milestones IMP-021 to IMP-029 had not been achieved in accordance with the terms of the MSA and the Implementation SOW or because formal approval of the milestone was not given by CISGIL.

In the light of the above determination, it is not necessary to consider IBM’s alternative arguments based on implied terms or estoppel.

Clause 14 of the MSA set out the requirements for invoicing the Charges:

“In consideration of the performance of the Services, the Customer shall pay the Supplier the Charges as set out in and/or as calculated in accordance with schedule 5 (Charges), which shall be invoiced at the times and in the manner specified in schedule 5 (Charges).”

Schedule 5 – Charges contained the invoicing and payment obligations of the parties, including the following:

“1.2

This schedule sets out the Charges and/or the methodology for calculating the Charges applicable to this Agreement together with certain financial related rules and processes that apply to the calculation, invoicing and payment of the Charges.

…

11.1

All invoices under this Agreement must be addressed to the following address (unless agreed otherwise in writing by the Customer):

(a)

by email to purchase2pay@cfs.coop, simultaneously copied by email to

gifinancialreportingteam@co-operative.coop; or

(b)

via post to The Co-operative, GI Invoice processing, 6th Floor Angel Sq, Manchester M60 OAG and simultaneously copied by post to GI Financial Reporting 10th Floor Angel Sq, Manchester M60 OAG.

…

11.3

The Supplier shall submit hard copy invoices to the Customer together with the invoice back-up in soft copy form, unless otherwise agreed by the parties. Invoices shall be submitted to such authorised representative as may be appointed or as may be agreed between the Supplier and the Customer from time-to-time.

11.4

Unless otherwise agreed by the parties, each Supplier invoice shall:

(a)

reflect and support the pricing and financial provisions set out in this schedule 5 (Charges);

(b)

quote the relevant Statement of Work identifier and the unique Customer purchase order number;

(c)

clearly show the basis of the Charges including the calculations used to establish the Charges for time and material Statements of Work and the relevant payment milestone for fixed price Statements of Work; and

(d)

provide a summary of the Charges incurred each month separately for each Statement of Work;

11.5

Unless otherwise set out in a Statement of Work, the Supplier shall invoice the Customer in respect of the Charges to which it is entitled under the Agreement within 180 days of the date on which the Supplier completes the relevant Milestone identified in the relevant Statement of Work. Any Charges which are not invoiced within this timeframe shall not be recoverable by the Supplier. The parties agree that this paragraph 11.5 shall not apply in cases where there is a dispute between the parties relating to Charges including the applicability of taxes and the parties agree that the timeline for invoicing shall be subject to extension in such cases.

…

11.7

Unless the Customer disputes an invoice in good faith in accordance with paragraphs 11.11 and 11.12 of this schedule 5 (Charges), the Customer shall pay correctly prepared invoices properly submitted in relation to payments to be made under this Agreement within seven (7) Business Days of receipt.

11.10

An invoice from the Supplier in relation to any part of the Charges is deemed not to have been correctly prepared if the Supplier has failed, in relation to that invoice and the supporting relevant documentation to be provided in relation to that invoice, to meet the

relevant requirements for an invoice as set out in this schedule 5 (Charges).

11.11

If, at any time, the Customer acting in good faith disputes an invoice or an amount shown in an invoice delivered by the Supplier, the Customer shall pay the undisputed amount (if any) of the invoice within the period required under paragraph 11.7 above. The Customer shall within seven (7) Business Days of receipt of an invoice notify the Supplier in writing if it disputes any element of the invoice with details of the amounts (Disputed Amount) and reasons for disputing the relevant part of the invoice.

11.12

Provided the Customer has given the notice in paragraph 11.11, the Customer may withhold payment of, and meet with the Supplier to discuss, the Disputed Amount, and will request at such meeting any additional details that it may need to verify the accuracy of the Disputed Amount within ten (10) Business Days of notifying the Supplier of the Disputed Amount. The Supplier shall comply with each such request from the Customer for additional information. If within (10) Business Days after the date on which the Customer has received the additional details requested from the Supplier, the Disputed Amount has not been agreed, then the Customer and the Supplier shall resolve the matter in accordance with the dispute resolution process set out in schedule

19 (Dispute Resolution) of this Agreement.”

On 24 March 2017, IBM issued invoice No. 5803171298 in the sum of £2,889,600 (£2,408,000 plus VAT) for:

“Implementation Services under the Master Services Agreement.

B04004 – IMP - 020 Application Gate 5

Application Gate 5 - covers IBM Software Products.

Note invoice due 7 business days from receipt of email containing invoice.”

On 25 March 2017 IBM sent the AG5 Invoice electronically to the Accounts Payable department at its email address, purchase2pay@cfs.coop.

On 27 March 2017 Ms Clough of CISGIL sent an email, rejecting the AG5 milestone invoice:

“Please can this invoice be re-submitted with the correct Purchase Order Number quoted on it.

We cannot accept this invoice for payment without a Purchase Order Number quoted on the invoices.”

On 28 March 2017 Marta Kowalik of IBM noted:

“The client is rejecting the invoice due to missing PO on it. Can you please arrange for credit & rebill with the PO included?”

On 31 March 2017 Ms Rigby, part of IBM’s debt resolution team, recorded that the invoice had been rejected because it was issued without a purchase order and stated:

“The Client has rejected the invoice as we have issued without PO reference, I can see Jakub questioned it at the time of raising please see screen shot section below.

If the Client has agreement to settle without PO have you something in writing that can be referred back to them? A contact?

I would say this dispute is time sensitive due to value and timing of payment due.” 289. Ms Hyman replied:

“Can’t say I am surprised.”

On 31 March 2017 Mr Hano sent internal emails within IBM, stating that the AG5 milestone sum should be credited.

On 6 April 2017 Ms Rigby sent an email stating:

“The cleanest way to handle this is for the invoice to be credited and re-issued with a PO reference … I have to make the assumption that as the invoice was disputed the Client would not accept a notification letter confirming the PO to be applied so cr/dr is most effective way to resolve.”

On 14 April 2017 Mr Smith stated that IBM Legal would draft a letter challenging the rejection of the invoice but such a letter was not sent.

At a CMG meeting on 26 April 2017, IBM asked for purchase orders to be raised relating to items including the AG5 milestone payment. On the same day, Tina Broadway of IBM sent an email to Chris Rielly of CISGIL, requesting a PO number for the AG5 milestone payment and stating:

“The attached invoice was rejected last month because no purchase order was provided.

Please would you raise and advise the purchase order number?”

The request was passed on to Leah Noakes who responded:

“Reject. We will need to consider how to advise IBM.” 295. Mr Houghton sent an email to Ms Noakes, stating:

“What’s it for, Leah? Would it be something that we would apply set off against do you think?”

On 27 April 2017 Ms Noakes sent Mr Rielly an email with suggested wording for a response to IBM:

“The Application Gateway was only mentioned to me in CMG for the first time yesterday. Even though it is dated a month ago it didn’t come through to me with last month’s invoices and it hadn’t been raised in CMG as a pending invoice or PO requirement, so I need to look into it and understand the details.”

Mr Rielly was uncomfortable sending this email because it was not true; he already understood the details of the issue. But he followed the instructions from Ms Noakes and sent the email to IBM.

At the CMG meeting on 3 May 2017 the invoice was discussed. IBM’s stated position was that the AG5 milestone payment was due and payable. CISGIL’s stated position was that the payment would become due at the contracted point in the programme delivery.

At the CMG meeting on 9 May 2017 it was noted that Application Gate 5 would be included as a disputed invoice:

“It was agreed that the invoice for AG5 would be added to the table of disputed invoices on Slide 9.”

CISGIL’s pleaded case is that the AG5 milestone invoice was invalidly submitted, based on the following alleged defects:

IBM’s case is that the complaints are invalid and/or trivial. CISGIL did not complain about the SOW identifier, absence of back up material or email address to which it was sent within seven business days of the invoice as required by paragraph 11.11 of Schedule 5. The invoice was not rejected on any ground other than the absence of a purchase order number.

CISGIL’s first complaint is that the invoice did not quote a Customer purchase order number. It is common ground that the AG5 invoice did not contain a purchase order number because CISGIL refused to issue the same. As set out above, CISGIL’s failure to approve achievement of the AG5 milestone and issue a purchase order number was in breach of its obligations under the MSA and the Implementation SOW and it is not entitled to rely on its own breach to escape any obligation to pay.

CISGIL’s second complaint is that the invoice did not quote the correct milestone number, referring to IMP-020 instead of IMP-030. Paragraph 11.4(c) of Schedule 5 did not stipulate that the milestone number had to be recited on the invoice; it simply required identification of the relevant payment milestone. Clearly, the reference to IMP-020 was a minor clerical error. There is no suggestion that this caused any confusion for CISGIL. IMP-020 was the AG 4 milestone which had already been paid by CISGIL. It would be obvious to anyone reading the invoice that it concerned application gate 5 and not application gate 4. The invoice expressly stated on its face that it was in respect of application gate 5. The sum invoiced was the value of the AG 5 milestone. That was sufficient to identify the relevant payment milestone and comply with paragraph 11.4(c).

CISGIL’s final complaint is that in breach of the IBM Purchase Order to Payments process and/or paragraph 11.3 of Schedule 5, IBM did not send a copy of its invoice by email to the relevant CISGIL personnel, Leah Noakes, Darren Coomer and Chris Rielly, and failed to send back-up data for the invoice.

It is common ground that the AG5 invoice was sent by email to the purchase2pay email address but no hard copy invoice or supporting information was sent to the above CISGIL representatives.

Para.11.3 of Schedule 5 required hard copy invoices and soft copy backup documents to be submitted to such authorised representative as appointed or agreed by the parties from time to time, “unless otherwise agreed by the parties”. This must be read in the context of paragraph 11 as a whole, which set out the process for submission and payment of invoices but provided for some of the detailed machinery to be agreed by the parties. Such detailed machinery included the individuals to whom invoices would be sent and the format in which the invoices would be provided.

CISGIL relies on the “Purchase Order to Payment” Process Flow document dated 22 July 2015, which provided for IBM to send invoices to the purchase2pay email address and identified the relevant individuals (by initials and the document key) as KW (Kevin Webb), KB (Kay Bradley), TP (Tom Phillpott) and AN (Alison Neate).

IBM submits that the Purchase Order to Payment process document was not agreed by IBM. That is a difficult submission to sustain in the light of Ms Barnes’ evidence in cross-examination that the document was produced for the PMG meeting in July 2015, it was circulated to her and others at IBM subsequently for comment and discussion, and there is no documentary evidence that IBM disputed it. Ms Hyman’s evidence was that she was shown the document by Mr Phillpott in about July 2015 and thereafter followed it by submitting invoices to the identified individuals from August 2015 onwards, save that by March 2017 the relevant individuals were Ms Noakes, Mr Coomer and Mr Rielly.

However, there is more substance in IBM’s case that in November 2015 CISGIL and IBM agreed to use electronic billing only. Initially, as Ms Hyman confirmed, invoices were sent to CISGIL by post and copies were sent to the named individuals in the Purchase Order to Payment process document. However, as set out above, in about November 2015 the parties agreed that they would use an e-billing process and that IBM would send its invoices to the purchase2pay email address.

CISGIL submits that the agreed electronic billing did not alter the requirements of paragraphs 11.1 or 11.3 of Schedule 5 and there was no formal change request or variation to the MSA. CISGIL correctly relies on Rock Advertising Ltd v. MWB Business Exchange Centres Ltd [2018] UKSC 24 in support of its submission that any valid variation to the MSA was required to be in writing. However, it was not necessary for there to be any change request or variation to the MSA. The paragraph 11 machinery permitted the parties to agree alternative procedural processes for invoices. Thus, such agreements were made pursuant to the existing provisions of the MSA and not by variation to the same. Such alternative arrangement included the initial Purchase Order to Payment process document, which was consistent with, but not the same as, the provisions in paragraph 11; contrary to paragraph 11.1(a), the Purchase Order to Payment document did not require invoices to be copied to the gifinancialreportingteam email. Likewise, in November 2015 the electronic billing process was agreed pursuant to paragraph 11.3 which provided for hard copy invoices and soft copy back-up to be submitted “unless otherwise agreed by the parties”. The revised procedure was confirmed in writing by Ms Hyman’s email dated 16 December 2015.

CISGIL places reliance on the fact that IBM continued to send emails to the identified key representatives as well as sending invoices by e-billing but this was simply a continuation of Ms Hyman’s agreement to send copies of the invoices to Mr Phillpott, reached prior to the e-billing agreement. It was not done consistently as it did not include IMP-018c in August 2016 and did not alter the agreement to use e-billing to one stipulated account address. In any event, only copies of the invoices were sent to the identified individuals; this did not affect the validity or otherwise of the invoices sent by the agreed e-billing process.

No supporting documentation was sent with the AG 5 invoice. However, no supporting documentation was required, given the nature of the AG 5 milestone, namely, a pass-through of agreed software licence payments. In any event, the table providing a breakdown of the application gate milestones was sent to CISGIL in August 2015 and with the other application gate invoices.

Paragraph 11.10 of Schedule 5 provided that an invoice was deemed not to have been properly prepared if it did not meet the requirements set out in Schedule 5. For the reasons set out above, the AG 5 invoice did meet the requirements of Schedule 5 and therefore was valid.

Paragraph 11.7 of Schedule 5 limited CISGIL’s obligation to pay invoices to those that were correctly prepared and properly submitted. CISGIL correctly draws attention to the stringent requirement for correctly prepared and properly submitted invoices, unless disputed, to be paid within seven days. Against those requirements, it might be open to CISGIL to rely on any failure by IBM to send copies of the invoice to the authorised representatives as default that relieved CISGIL of its obligation to raise any dispute within seven days or its obligation to pay interest on any late payment, if it had inadequate notice of the invoice. However, in this case no prejudice was suffered by CISGIL through any failure on IBM’s part to send copies of the invoices to those individuals. CISGIL received the invoice, considered it and rejected it promptly.

For the above reasons, I reject CISGIL’s complaints that the AG5 invoice was defective and/or not properly submitted. Those complaints were not articulated at the time that the invoice was considered and rejected. They have no merit.

In this case, the real dispute as to validity of the invoice was whether IBM was entitled to submit any invoice for Application Gate 5 in the light of its failure to achieve earlier milestones and the absence of authorisation by CISGIL. That was the basis on which CISGIL refused to issue the purchase order number or pay the invoice. Was the AG5 invoice disputed?

IBM’s position is that Paragraph 11.11 of Schedule 5 provides that CISGIL was obligated to notify IBM if it disputed any invoice within seven business days of delivery of the invoice in question. CISGIL did not do so in relation to the invoice, and it thereby lost the right to withhold payment.

IBM submits that CISGIL’s email of 27 March 2017 did not dispute the invoice for the purpose of paragraph 11.11 because it did not challenge the sum claimed, or any part thereof; it did not challenge CISGIL’s underlying liability to pay for AG5; it did not complain about a failure to send copies of the invoice to other personnel at CISGIL; or complain about an absence of any back up documents. CISGIL simply asked for a purchase order number, which it knew IBM could not provide because CISGIL had taken a deliberate decision to withhold the purchase order.

IBM accepts that CISGIL retained the right to argue in due course that the invoiced sum was not due but it lost the right to withhold payment pending determination of the dispute as to the validity of the invoice.

It is not in dispute that the notice requirement in paragraph 11.7 of Schedule 5 was in clear terms. Unless CISGIL disputed the invoice in good faith in accordance with paragraphs 11.11 and 11.12, it was obligated to pay the invoice within seven days of receipt.

A similar provision was upheld as enforceable in The Atlantic Tonjer [2019] EWHC 1213 (Comm) per Sir Ross Cranston:

“[32] Those time periods had been negotiated by two commercial parties. There was no suggestion that they were not of equal bargaining power in the shipping market. Consequently, the hypothetical case of a challenge to an invoice having to be given in 2 or 3 business days has no traction. Even if that had been the case it would have been the period freely negotiated and determined by express agreement. In any event, clause 12(e) does not preclude charterers from bringing claims (in our case the counterclaim referenced by the Tribunal) or withholding payment (that being subject, of course, to notice being given, so that if no notice if given a defence to payment cannot be raised). What clause 12(e) requires is prompt payment or prompt identification of any issue preventing payment.

[33]

On this reading of the clause, if charterers reasonably believe that there is an error in the invoice they can withhold payment of the disputed amount by notifying the owners under the clause within the period they have agreed in the contract. They also have the audit rights under clause 12 (g) to reclaim amounts paid through accounting-type errors (wrong hire rate, wrong number of meals and so) up to four years ahead. Further, as the Tribunal correctly concluded, the charterers can always bring a counterclaim if they have paid sums which they later believe were not properly payable. Counterclaims in this context would include a claim for breach of contract or one for unjust enrichment.

[34]

In other words, clause 12(e) is not analogous to a time bar clause or any other type of clause limiting or excluding liability. Nothing is being implied into the clause. It may be that the charterers are required by clause 12(e) to act in a certain way if they dispute an invoice and wish to withhold payment. But as Lewison LJ said in the Interactive E-Solutions case [2018] EWCA Civ 62, this type of clause is to be construed in accordance with the same principles as any other clause. Adopting that approach, the clause properly construed means that, within 21 days of receipt of an invoice, charterers have to form a view about it. If they reasonably believe it is incorrect they do not have to pay, but they must give the requisite notice.

[35]

This interpretation of clause 12(e) is in line with commercial common sense. In paragraph 46 of its Reasons, the Tribunal quoted the impeccable authority of Robert Goff J in The Kostas Melas [1981] 1 Lloyd's Rep 18, that cash flow is a matter of considerable, sometimes crucial, importance to the owners of ships. That dictum has been underlined in later cases and is undisturbed by anything said in the judgments in Spar Shipping AS v Grand China Logistics (Group) Co Ltd [2016] EWCA Civ 982; [2017] Bus LR 663. In my view there is nothing uncommercial in charterers being obliged to raise bona fide disputes timeously, at a time when the owners have an opportunity to exercise the rights and remedies they have under the charterparty such as under clause 12(f).”

It is common ground that CISGIL’s Accounts Payable department received the AG5 invoice on 24 March 2017. It is also common ground that on 27 March 2017 Ms Clough rejected the invoice because there was no purchase order quoted in it.

In my judgment, on the facts of this case, CISGIL disputed the invoice by rejecting it, for the following reasons.

Firstly, IBM is correct that Ms Clough did not challenge CISGIL’s underlying liability in respect of the AG5 milestone payment; nor did she challenge IBM’s entitlement to submit an invoice for the milestone; nor did she challenge the amount invoiced; nor did she assert any of the technical defects subsequently relied on by CISGIL that the Court has dismissed as unmeritorious. Ms Clough rejected the whole of the AG5 invoice on one ground alone, that was the absence of a purchase order number. I accept CISGIL’s submission that under paragraph 11.11 of Schedule 5, that was sufficient notification for the purposes of placing the AG5 invoice in dispute.

IBM’s submission that Ms Clough did not dispute the invoice is simply wrong. Ms Clough asked for the invoice to be re-submitted with the correct purchase order number quoted but she also stated that: “We can not accept this invoice for payment without a Purchase Order Number quoted on the invoices”. On any sensible interpretation of those words, CISGIL disputed the invoice submitted and indicated that it would not pay it.

Secondly, when this issue arose initially, IBM accepted that the invoice had been rejected and was in dispute. The invoice was credited in its internal accounting system and identified as disputed. At the CMG meeting on 3 May 2017, Steve Allen of IBM raised concern at CISGIL’s failure to issue a purchase order for the application gate 5 milestone. Ms Noakes stated that CISGIL’s position was that the milestone would become due at the contracted point in the programme delivery. At the CMG meeting on 9 May 2017 it was recorded that application gate 5 would be added to the table of disputed invoices.

Thirdly, the invoice was disputed in good faith. IBM submits that CISGIL is not entitled to rely on the stated ground of dispute, namely, the absence of a purchase order number, because such rejection would not satisfy the requirement of paragraph 11.11 that the invoice must be disputed “in good faith”:

Mr Summerfield of CISGIL admitted that he took a deliberate decision to withhold the purchase order number for application gate 5 because he did not consider that IBM was entitled to payment, having failed to achieve the Release 1 and Release 2 Go Live milestones. As set out above, that was wrong. IBM was entitled to the purchase order for the AG5 milestone because payment was not conditional on progress of the project. However, CISGIL’s case on construction of the Roadmap, the relevant provisions of the MSA and the Implementation SOW against the relevant factual matrix, was worthy of scrutiny and could not be considered unarguable. On that basis, it was a position that was not so unreasonable that it amounted to bad faith.

Fourthly, there was no contractual obligation on CISGIL to forewarn IBM of its decision to withhold the purchase order for the application gate 5 milestone, to justify its decision to withhold the purchase order, or to activate the dispute resolution procedure. IBM was well aware that CISGIL did not intend to pay the AG5 milestone, as evidenced by Jonathan Smith’s internal email. The purchase order had been requested and had not been issued. Both parties knew that the AG5 milestone payment was controversial; both parties had the opportunity, but failed, to use the dispute resolution procedure in respect of the matter.

For the above reasons, I find that CISGIL validly disputed the AG5 invoice for the purpose of paragraph 11.11 of Schedule 5, entitling it to withhold payment of the same.

CISGIL’s case is that it was entitled to set off its claim for unliquidated damages against any sum payable under the AG5 invoice by way of equitable set-off. It purported to exercise such right of set-off by letters dated 12 May 2017, 8 June 2017 and 4 July 2017.

IBM accepts that if, as CISGIL contends, CISGIL had a claim for damages arising out of delay at the time the invoice was raised, it was in principle entitled to set off its claim against liability on the invoice. However, it submits that CISGIL failed to comply with the procedure for disputing the invoice set out in paragraph 11 of Schedule 5 and, as a result, forfeited any set-off entitlement.

Reliance on an argument of set-off was first raised by Addleshaws in its letter dated 13 April 2017:

“By reason of the substantial loss and damage that CISGIL has clearly incurred, as identified above, CISGIL reserves the right to exercise its right to set off any IBM invoices which properly fall due for payment against its much larger claim for damages arising from IBM’s breaches…”

On 12 May 2017, Addleshaws wrote to CMS, referring to the letter above and stating:

“We are writing to confirm our client’s intention to exercise its right to set off its claim for damages against any amounts which might otherwise be due from CISGIL to IBM.”

By further letter dated 12 May 2017, Addleshaws set out the CISGIL position that the AG5 milestone had not yet fallen due and stated:

“Our client has therefore rightly both disputed IBM’s right to raise an invoice in respect of Application Gate 5 and refused to provide a purchase order …

In any event, should any sum be or become otherwise due to IBM in respect of Application Gate 5 our client intends to set off against it the costs and losses as detailed in our letter of 12 May 2017.”

By letter dated 8 June 2017, Addleshaws set out CISGIL’s arguments on the invalidity of the AG5 invoice and asserted its right to set off against any invoices its claim for damages, which arguments were repeated in its letter dated 4 July 2017.

CISGIL’s position is that its cross claims were sufficiently closely connected to the AG5 Invoice so as to satisfy the test for equitable set-off. It submits that it was entitled to rely on its right of set-off (if, and to the extent that it had any liability to pay the AG5 invoice). CISGIL did not have to substantiate any claim for damages; all that was necessary was that CISGIL reasonably thought in good faith that it had such a claim for damages. CISGIL believed, reasonably and in good faith, that it had suffered serious loss and damage (and was entitled to liquidated damages) during 2016 by reason of the delays that had occurred.

It is reasonably clear that, as a matter of principle, CISGIL’s claims against IBM for culpable delay in failing to achieve key milestones in the Roadmap gave rise to an equitable set-off.

In Geldof Metallconstructie NV v Simon Carves Ltd [2010] EWCA Civ 667 Rix LJ set out a jurisprudential analysis of the law of equitable set-off:

“[22] It is generally considered that the modern law of equitable set-off dates from Hanak v. Green [1958] 2 QB 9. Morris LJ's judgment there has been described as a masterly account of the subject (Gilbert Ash (Northern) v. Modern Engineering (Bristol) Ltd [1974] AC 689 at 717 per Lord Diplock). In Dole Dried Fruit v. Trustin Kerwood Ltd [1990] 2 Lloyd's Rep 309 at 310 Lloyd LJ said that for all ordinary purposes, the modern law of equitable set-off is to be taken as accurately stated there. Morris LJ set out the law in these terms: "The position is, therefore, that since the Judicature Acts there may be (1) a set-off of mutual debts; (2) in certain cases a setting up of matters of complaint which, established, reduce or even extinguish the claim; and (3) reliance as a matter of defence upon matters of equity which formerly might have called for injunction or prohibition…The cases within group (3) are those in which a court of equity would have regarded the crossclaims as entitling the defendant to be protected in one way or another against the plaintiff's claim" (at 23).

However, that did not mean that all cross-claims may be relied on as defences to claims. In his examination of Bankes v. Jarvis [1903] 1 KB 549, Morris LJ identified two factors as critical: it would have been "manifestly unjust" for the claim to be enforced without regard to the cross-claim; and "there was a close relationship between the dealings and transactions which gave rise to the respective claims" (at 24).

…

[26]… Federal Commerce & Navigation Co Ltd v. Molena Alpha Inc [1978] 2 QB 927 (The "Nanfri") … was the occasion for a further consideration of the doctrine of equitable set-off. Lord Denning MR said (at 974G/975A):”

"… We have no longer to ask ourselves: what would the courts of common law or the courts of equity have done before the Judicature Act? We have to ask ourselves: what should we do now so as to ensure fair dealing between the parties? See United Scientific Holdings Ltd. v. Burnley Borough Council [1978] A.C. 904 per Lord Diplock. This question must be asked in each case as it arises for decision: and then, from case to case, we shall build up a series of precedents to guide those who come after us. But one thing is clear: it is not every cross-claim which can be deducted. It is only cross-claims that arise out of the same transaction or are closely connected with it. And it is only cross-claims which go directly to impeach the plaintiff's demands, that is, so closely connected with his demands that it would be manifestly unjust to allow him to enforce payment without taking into account the cross-claim. Such was…Hanak v. Green..."

In summarising the applicable principles, Rix LJ stated at [43]:

“(ii)

There is clearly a formal requirement of close connection. All the modern cases state that, whether Hanak v. Green, The

Nanfri, The Dominique (by reference to the Newfoundland Railway case), Dole Dried Fruit or Bim Kemi. The requirement is put in various ways in various cases. Morris LJ in Hanak v.

Green spoke of a "close relationship between the dealings and transactions which gave rise to the respective claims". Lord Denning in The Nanfri spoke of claims and cross-claims which are "closely connected". How closely? "[S]o closely connected with his demands that it would be manifestly unjust to allow him to enforce payment without taking into account the crossclaim". The Dominique adapted the Newfoundland Railway test and spoke of a cross-claim "flowing out of and inseparably connected with the dealings and transactions which also give rise to the claim". Dole Dried Fruit returned to Lord Denning's test in The Nanfri but also spoke of a claim and cross-claim which was so "inseparably connected that the one ought not to be enforced without taking into account the other". Bim Kemi expressed a preference for the test in The Dominique, while warning against being caught up in the nuances of different formulations.

…

(iv)

There is also clearly a functional requirement whereby it needs to be unjust to enforce the claim without taking into account the cross-claim. This functional requirement is emphasised in all the modern cases, viz Hanak v. Green, The Aries, The Nanfri, Dole Dried Fruit, Esso v. Milton, and Bim Kemi. The only modern authority cited above which does not in terms refer to the functional requirement of injustice is Lord Brandon's discussion in The Dominique. This has led Potter LJ in Bim Kemi (at para 38) to remark on the absence of reference to "manifest injustice" by Lord Brandon: but nevertheless it did not lead him to dispense with that requirement (ibid). It seems to me impossible to do so: it is not coherent to have a doctrine of equitable set-off which ignores the need for consideration of aspects of justice and fairness…

…

(vi)

For all these reasons, I would underline Lord Denning's test, freed of any reference to the concept of impeachment, as the best restatement of the test, and the one most frequently referred to and applied, namely: "cross-claims…so closely connected with [the plaintiff's] demands that it would be manifestly unjust to allow him to enforce payment without taking into account the cross-claim". That emphasises the importance of the two elements identified in Hanak v. Green; it defines the necessity of a close connection by reference to the rationality of justice and the avoidance of injustice; and its general formulation, "without taking into account", avoids any traps of quasi-statutory language which otherwise might seem to require that the cross-claim must arise out of the same dealings as the claim, as distinct from vice versa…”

In Fearns v. Anglo-Dutch Paint & Chemical Co Ltd [2010] EWHC 2366 (Ch.) George Leggatt QC (as he then was) reviewed the authorities on the nature of equitable set-off, including Lord Denning’s formulation in The Nanfri:

“[19] The correct test for equitable set-off has been further considered in later cases, most recently by the Court of Appeal in Geldof Metallconstructie NV v Simon Carves Ltd [2010] EWCA Civ 667. In Geldof, at para 43(vi), the Court of Appeal has endorsed as the best statement of the test, and the one most frequently referred to and applied, that formulated by Lord Denning in Federal Commerce & Navigation Co Ltd v Molena Alpha Inc (The "Nanfri") [1978] 2 QB 927 at 975, namely that equitable set-off is available where a cross-claim is "so closely connected with [the claim] that it would be manifestly unjust to allow [the claimant] to enforce payment without taking into account the cross-claim".

…

[23] The importance of this decision is that it establishes that an equitable set-off can be relied on outside the context of proceedings as an immediate answer to a liability to pay money otherwise due and to the exercise of rights, such as a right to terminate a contract, which are contingent on such nonpayment.”

In Equitas Limited and Others v. Walsham Brothers & Co Ltd [2013] EWHC 3264 (Comm); Males J (as he then was) summarised the operation of such equitable set-off at [176]:

“A right of set off may be exercised by being asserted. Upon the exercise of the right in this way, a claimant who seeks to enforce or rely on its own claim (for example, by terminating a contract, as in the typical case of withdrawal from a time charter for non-payment of hire) without taking the cross claim into account acts at its peril. But if the set off is not even asserted, it can have no effect at all. A cross claim which has not even been asserted can hardly affect the claimant’s conscience so as to make it manifestly unjust to enforce the claim without taking account of the cross claim. However, even the exercise of the right in this way does not operate to extinguish or reduce the claim. That can only be done by agreement or by judgment …”

CISGIL submits that the MSA and Schedule 5 of the Implementation SOW did not contain any express term excluding any rights of set-off. It asserted a valid right of set-off as a ground for disputing payment of the AG5 Invoice.

IBM submits that paragraphs 11.7, 11.11 and 11.12 of Schedule 5 were unambiguous. They provided a complete and mandatory code for dealing with any disputes as to the validity or content of an invoice. The language of paragraph 11.7 was clear in specifying one route alone for challenging an invoice and providing that unless that route was followed the invoice had to be paid. Paragraph 11.11 provided that if CISGIL disputed any element of the invoice it was required to notify IBM (in writing) within seven business days of receipt of the invoice. Paragraph 11.12 reiterated that it was only a “Disputed Amount” (an invoice or an amount which had been disputed in accordance with paragraph 11.11) that CISGIL might decline to pay.

IBM’s construction is clearly correct to the extent that paragraph 11 of Schedule 5 provided a complete and mandatory code for disputing the validity or content of an invoice. If, contrary to the Court’s finding above, CISGIL had failed to dispute the AG5 invoice within seven days of receipt, it would have been precluded from challenging IBM’s contractual entitlement to payment. However, the Court must also address the question as to whether CISGIL could nonetheless assert an equitable right of set-off against any such contractual entitlement to payment; that is, whether the right of set-off was excluded on a proper construction of the MSA.

There is established authority that clear words would be required if such rights of setoff were to be excluded. In Gilbert-Ash (Northern) Ltd v Modern Engineering (Bristol) Ltd [1974] AC 689 Lord Diplock stated at p.717:

“It is, of course, open to parties to a contract for sale of goods or for work and labour or for both to exclude by express agreement a remedy for its breach which would otherwise arise by operation of law … But in construing such a contract one starts with the presumption that neither party intends to abandon any remedies for its breach arising by operation of law, and clear express words must be used in order to rebut this presumption.”

In Nile Co for the Export of Agricultural Crops v. Bennett (H & JM) (Commodities) Ltd [1986] 1 Lloyd’s Rep. 555, the court was required to construe a contract for shipments of potatoes, some of which were found on delivery to be in an unsatisfactory condition. Evans J held that the contract excluded the defendants’ right of deduction but did not bar the claim. Clause 4 of the agreement did not preclude the defendant from bringing damages claims in cases where they had failed to invoke the clause 4 procedure but it did prevent them from deducting such claims from the fob amount drawn by the plaintiffs which was payable in full subject only to claims made in accordance with that clause:

“There is no express wording in cl.4 which purports to have this effect. The question is, therefore, whether the clause properly construed carries by implication the clear and unequivocal meaning for which the plaintiffs contend. In my judgment, two factors in particular work strongly in their favour. First, the defendant can hardly be heard to say that it was theirs and the plaintiffs’ intention, when the agreement was made, that they were to remain free to ignore the cl.4 machinery and to make their damages claims or deductions in such other ways as they might choose, either at the time or subsequently within (presumably) a six-year limitation period. Secondly, if it is accepted that ignoring cl. 4 would itself amount to a breach of contract, for which the defendants would be liable to the plaintiffs in damages, the measure of such damages would be practically impossible to calculate...

Essentially, the question is one of construction, and the answer depends, as always upon the intention of the parties, properly derived from the terms of their agreement and the admissible surrounding circumstances …”

In Stocznia Gdynia SA v. Gearbulk Holdings Ltd [2009] 1 Lloyd’s Rep. 461 (CA), Moore-Bick LJ confirmed:

“The court is unlikely to be satisfied that a party to a contract has abandoned valuable rights arising by operation of law unless the terms of the contract make it sufficiently clear that that was intended. The more valuable the right, the clearer the language will need to be.”

In FG Wilson (Engineering) Ltd v. John Holt & Company (Liverpool) Ltd [2012] 2

There is a distinction to be drawn between a contractual provision that excludes rights of set-off and a contractual provision that makes the exercise of any right of set-off against particular payments conditional on notice. Clear and unambiguous language will be required before the Court is satisfied that a party has given up valuable rights of set-off; such a stringent test may not be required where a party retains its rights of set-off but agrees that notice conditions apply to the exercise of such rights.

In this case, the starting point is that there is no term in Schedule 5 or elsewhere in the MSA which expressly excludes the parties’ rights of set-off. Therefore, the presumption is that the parties have retained all remedies for breach of contract, including any equitable rights of set-off.

That presumption is reinforced by Clause 42 of the MSA, which provides:

“The rights and remedies of the parties in connection with this Agreement are cumulative and, except as expressly stated in this Agreement, are not exclusive of and may be exercised without prejudice to any other rights or remedies provided in this Agreement by law or equity or otherwise. Except as expressly stated in this Agreement (or in law or in equity in the case of rights and remedies provided by law or equity) any right or remedy may be exercised wholly or partially from time to time.”

However, the language of paragraph 11.7 of Schedule 5 expressly provides that invoices must be paid unless they have been disputed in accordance with the agreed procedure:

“Unless the Customer disputes an invoice in good faith in accordance with paragraphs 11.11 and 11.12 of this schedule 5 (Charges), the Customer shall pay correctly prepared invoices properly submitted in relation to payments to be made under this Agreement within seven (7) Business Days of receipt.”

Paragraph 11.11 sets out a mandatory period within which an invoice may be disputed:

“…The Customer shall within seven (7) Business Days of receipt of an invoice notify the Supplier in writing if it disputes any element of the invoice with details of the amounts (Disputed Amount) and reasons for disputing the relevant part of the invoice.”

Paragraph 11.12 imposes restrictions on the right to withhold part or all of any invoiced payment:

“Provided the Customer has given the notice in paragraph 11.11, the Customer may withhold payment of, and meet with the Supplier to discuss, the Disputed Amount ...”

The effect of those paragraphs, read together, was clear and unambiguous and introduced a ‘pay now, argue later’ principle. They did not exclude any right of setoff; CISGIL would retain its right of set-off against future payments due and would retain its right to counterclaim for damages; but the paragraph 11 provisions restricted the exercise of such set-off rights against invoices to those in respect of which a valid notice of dispute had been given within seven days.

CISGIL has a further argument that it could rely on equitable set-off, not to reduce or extinguish the AG5 Invoice, but to bar IBM’s right to rely on it by serving a Final Notice under clause 26.7 and thereafter terminating the MSA. However, that ignores the wording of clause 26.7, which permitted IBM to issue a Final Notice in circumstances where CISGIL failed to pay undisputed invoiced amounts. If CISGIL was unable to rely on set-off so as to render the AG5 invoice a Disputed Amount, IBM was entitled to issue a Final Notice. IBM’s entitlement to terminate was triggered by the failure of CISGIL to pay those undisputed amounts within fifteen days of receipt of the Final Notice.

For the above reasons, if, contrary to the Court’s finding above, CISGIL had failed to dispute invoice AG5 within seven days as required by paragraph 11.11 of Schedule 5, it would have lost its right to rely on any equitable set-off to justify withholding payment in respect of that invoice and to prevent IBM relying on clause 26.7 to exercise its right to terminate.

Clause 26.7 provided:

“The Supplier shall have the right to serve on the Customer a written notice (Final Notice) if the Customer has failed to pay undisputed invoiced amounts which in aggregate exceed £1 million (one million pounds sterling) and which have been due and payable for a period in excess of forty-five (45) days… If the Customer fails to pay such undisputed invoiced amounts fifteen (15) Business Days of receipt of the Final Notice the Supplier may terminate this Agreement immediately.”

On 22 June 2017 IBM served on CISGIL a Final Notice pursuant to clause 26.7 of the MSA.

By letter dated 18 July 2017, CMS informed Addleshaws:

“IBM has not yet received payment in relation to the invoice to which the Final Notice relates. …

IBM is now entitled to terminate the MSA. As this would be a significant decision IBM is entitled to a reasonable period of time to consider its position.

In the meantime, all of IBM’s right[s] are reserved, including its right to terminate pursuant to clause 26.7 of the MSA …”

The AG5 invoice was not paid. On 27 July 2017 IBM sent its letter of termination.

CISGIL submits that IBM should have served any Notice of Termination fifteen business days after the Final Notice, that is by 13 July 2017. By failing to send its letter of termination by 13 July 2017, it lost any right to terminate under clause 26.7. I reject that submission. Clause 26.7 provided for the minimum period of time that had to expire before any termination right arose, namely, fifteen business days; but it

However, as set out above, IBM was not entitled to exercise any right of termination under the MSA because CISGIL disputed the AG5 invoice within seven days of its receipt. In those circumstances, the purported termination amounted to repudiatory breach, which CISGIL was entitled to accept.

CISGIL’s case is that IBM was in wilful default. IBM knew at the time that it issued the AG5 invoice that the preceding milestones had not been achieved, it did not have a relevant purchase order and the milestone payment was not due. Further, IBM knew at the time that it purported to exercise termination rights that the AG5 invoice was not due and payable, the AG5 invoice was disputed by CISGIL and CISGIL had asserted rights of set-off in respect of the AG5 invoice.

IBM’s position is that, even if the Court finds that its purported termination was wrongful, it was not in wilful default within the meaning of the MSA.

Schedule 1 to the MSA defines “wilful default” as:

“an intentional breach of the Agreement with either an intent to cause harm or recklessness with regard to the consequences of the breach.”

CISGIL submits that the ‘Briefing on Termination’ presentation made by Mr Perrott on 25 July 2017, for the purposes of obtaining high level approval within IBM for termination, was a sham. The slides were inaccurate, one-sided and distorted the true picture of the project.

The briefing document presented by Mr Perrott included the following bullet points:

In respect of Application Gate 5, the following points were made:

Much of the information on the slides was an accurate record of the MSA provisions and the events that occurred. The parties had very different views as to the interpretation of the Roadmap and the provisions of Schedule 5. As set out in answer to the AG5 milestone issues, on some points, IBM was correct; on others it was wrong. CISGIL’s criticism of it as inaccurate, one-sided and distorted is not justified.

CISGIL’s case that IBM must have known that no right of termination had arisen in July 2017 is not substantiated.

CISGIL contends that IBM knew that it was not entitled to render the AG5 invoice in the absence of a purchase order which it knew CISGIL had refused in good faith to provide for reasons of which it was also well aware. However, as set out above, IBM was entitled to render the AG5 invoice without a purchase order because it was entitled to the milestone payment.

CISGIL contends that IBM knew that the AG5 invoice had not been properly submitted but, as set out above, the invoice was properly prepared and submitted in accordance with paragraph 11 of Schedule 5.

CISGIL contends that IBM knew that the AG5 invoice had not fallen due for payment but that contention was not reflected in IBM’s internal communications.

On 23 December 2016 Ms Boast challenged IBM’s decision to withhold payment of IG’s invoice for £2.9 million in respect of the software licences:

“Can you confirm that the payment for £2.9m for the software we did a pass thru deal in for IBM software for coop is going to clear our bank account on the 3rd Jan 2017?

There seems to be some confusion that IBM are refusing to pay this invoice which I am sure is not correct considering it was done as a huge favour to IBM to support closing the coop contract for your software only.”

Mr Jackson confirmed this account in an internal IBM email:

“Is there a problem here? What Jaquie says below is true and it was a great favour they did us to help close the deal when Cisgil had reached their capital threshold. ”

On 5 January 2017 Sjang Ramaekers, IBM’s European Delivery Leader, set out his view:

“My understanding is that this amount is due to IG, who at the same time is not willing to pay for the resource is we made available to them to work on their scope for the project (not the supplementary staff). Much smaller amount, same principle.

On top of that, we have no clarity if we can raise the invoice to Cisgil for this (application gate 5) due to delay caused by 1i. The invoice circle we set up from Cisgil-IBM GBS-IG to IBM SWG should not lead to a loss of 3m for GBS.

The contract with IG allows for termination by IG, if we don't pay but only in April. We can stop this termination by paying. ”

The above exchanges confirm IBM’s account that the application gate payments were in respect of software licence payments that had been financed by IBM and IG to assist CISGIL’s capital restraints; also, IBM conceded that the invoice from IG was payable and should be honoured. Mr Allen, the programme and project manager at IBM, confirmed in cross-examination that IBM believed the AG5 milestone was due and IBM was entitled to the payment.

There was a discussion within IBM as to whether the AG5 invoice should be issued to CISGIL and whether it would be paid. Mr Smith, IBM’s risk consultant set out his views in an email dated 16 March 2017:

“Following a few conversations yesterday, there seems to be a view that we should issue the invoice for Application Gate 5 despite the client not issuing a PO for the invoice.

From a contractual perspective ... the Application Gate 5 was due in January (contractually at ‘Beginning Jan 17’), and is not subject to Schedule 6 Acceptance (it is a time-based milestone and does not require acceptance of Deliverables).

It is this invoice that would enable, if we agreed to, the payment of the software invoices from IG…”

Nigel Kennington, Vice President and Partner at IBM, responded:

“My logic would be that we have completed the work and that if we invoice and it isn’t paid then we have an option for putting them in breach for non payment (not necessarily to be exercised yet). Given they have upped the anti with lawyers letters, this could be one of our few levers.” 383. Angela Magee, Vice President of IBM, stated:

“I am happy with the logic, we just need to manage Accountings expectations. We have no PO matching the invoice value so cannot recognise revenue against it. We also have no prospect in the short term of securing this PO until we have reached a way forward with CISGIL and Carlyle.” 384. Mr Kennington replied:

“Understood. I don’t think this is for revenue, more for strengthening our position in dispute.”

The above exchanges indicate that IBM thought that it was entitled to payment in respect of the AG5 milestone; the decision to submit the invoice was designed to improve IBM’s negotiating position; there was recognition that it might be rejected but there is no evidence that it was disingenuous.

The invoice was validly sent by the e-billing system agreed by the parties.

CISGIL correctly notes that the AG5 invoice was disputed by CISGIL within seven date of receipt by Ms Clough’s email of 27 March 2017. IBM wrongly held the view that the invoice was not validly disputed in accordance with the Schedule 5 procedure but this does not indicate any bad faith on IBM’s part.

Mr Perrott was cross-examined on this issue. He explained that IBM considered that the AG5 milestone payment was due and that CISGIL’s erroneous argument for withholding the purchase order did not give rise to a valid dispute.

“Q. Mr Perrott, you're simply not telling the truth to the court on this subject: you knew full well, didn't you, as from 27 March, or when you were told by Mr Allen about the 27 March email, that the invoice was disputed; do you disagree with that?

A. I do. I am telling the truth. Our frustration was the client for -- in other instances they've given us a purchase order and there has been a dispute and the dispute either gets resolved or it stays in dispute and of course we got to a very difficult time on the programme. I still to this day don't understand why they wouldn't have given us a purchase order. It would have been a very simple thing to have done and it would have allowed us to fulfil the requests from their own finance team and then we would have appended it to our invoice.”

CISGIL contends that IBM knew that CISGIL was entitled to set-off its claim for damages against the AG5 invoice but, as set out above, such right was not exercisable against that invoice because it was not asserted in accordance with the Schedule 5 procedure.

CISGIL correctly notes that there were no undisputed invoiced sums over £1 million that had been due and payable by CISGIL for more than 45 days but this turns on IBM’s wrong but genuine belief that the AG5 invoice had not been disputed.

CISGIL submits that, by July 2017, IBM knew that it could not deliver the project with IG or its source code and that the risks and financial consequences of continuing were accordingly prohibitive. The initial findings of the audit carried out by IBM, sent to IG on 27 November 2016, raised a number of concerning issues, including:

“A significant amount of customisation has been created using a copy and modify approach, some of which is being back ported into the base code. The sustainability and maintainability of this approach is questionable.

The quality aspects at the code level have a high to very high maintenance level, a significant level of deferred maintenance, where there are a number of priority one and two violations against standard guidelines.

Significant issues have been identified in the use of Free Open Source Software which have associated legal and security risks.

The amount of code suggests that this is in fact a copy of the base (in software engineering this is called a fork), instead of customer specific extensions to the base.

A substantial part of the client specific code contains a large percentage of customised source code.

20% of the base code has been copied into the customer customisation area and further modified.

At the moment 6.5% of the copied code is in an area which will be back ported.”

The final version of the audit report was sent to CISGIL on 21 December 2016. The criticisms were not ‘watered-down’ in any material respect, as suggested by CISGIL. There were some minor changes to the words used but the key points remained intact. The report was sufficient to notify CISGIL as to the deficiencies that had been identified in IG’s approach to customisation of the source code.

Mr Allen accepted in cross-examination that if in 2017 IBM stepped in to perform IG’s obligations, significant additional work would be required:

“Q. The work IBM would have to undertake to get CISGIL onto a single code line to support both Release 1 and Released 2 involved firstly the retrofit of all release one defects into release 2? A. That's correct.

Q.

The rework of the customised parts of Release 1 that were made redundant by the new functionality in version 7.6 … the portals, the aggregators, and some interface elements?

A. Well, yes, they would have to be ported over.

Q. And then thirdly, there needed to be a transfer of everything into Release 2 that was in Release 1 i.e. the configurations and the source code customisations?

A. Yes, I would assume so...

Q. And next you would have to upgrade FOSS components that required upgrades?

A. That was being done by 1 Insurer so we would have to maintain them going forwards …

Q. Regression testing with Release 1 functionality would have to take place?

A. You would have to run regression tests … ”

However, Mr Allen maintained his view that although the project was in difficulty, it could still have been delivered:

“Q. This is a project … by this time which is failing. A. It’s in difficulty, yes.

Q.

You don’t like the word ‘failing’?

A. My view at the time was this project could have been delivered. So if that's failing, okay. My view is, it was in difficulty and could have been recovered.

Q. Okay. So milestones were seriously in delay?

A. There were delays to the milestones, yes.

Q. And there were resource issues with IG which you were trying to resolve? A. There were, yes.

…

Q. My suggestion to you is that when you say in paragraph 63 that you formed the impression by May that CISGIL didn’t want to go live, what’s really happening here is that you know that you’re being held to the contract and there is a tension between that legitimate desire to hold IBM to the contract and what you want to do, which is to desperately get something live. There’s a conflict there, isn’t there?

A. I'm a delivery person. Of course I want to get something live. I think the point I was trying to make is there were behaviours at the lower level which were not consistent with clients that I've seen in the past trying to get systems live, and we've touched on a couple of those already. One is around accepting

severity 3, severity 4 defects to go in. One is around accepting compromises. One is around managing dependencies across the parties, which Richard

[White] was reluctant to do.”

Mr Perrott was challenged in cross-examination about IBM’s motive for purporting to terminate. He denied that IBM was not prepared to take over the source code from IG; his view was that CISGIL changed its mind and decided that it no longer wanted the new system or to invest in a capital intensive business.

Having read the contemporaneous documents and having listened carefully to the factual witnesses, it is clear that by July 2017 both parties were resigned to abandonment of the project. Both parties retained legal teams and tried to manoeuvre themselves into a position where they could extricate themselves from the MSA with minimum damage. A high-risk strategy was adopted on both sides; the AG5 milestone payment, a modest sum in relation to the high value of the overall project, was the vehicle used to bring the project to an end.

Both parties took a decision not to operate the contractual disputes resolution procedure to resolve the AG5 invoice dispute until July 2017, when there were tentative, belated discussions about mediation. When Mr Perrott called Mr Summerfield to tell him that IBM had decided to terminate, neither party made any attempt to save the project.

None of the above indicates intentional or reckless breach; both parties thought that they were entitled to adopt their chosen stance and that their analysis of the issue was correct, or at least arguable. IBM rightly understood that it was entitled to payment in respect of the AG5 milestone. It wrongly thought that CISGIL was not entitled to reject the invoice and/or failed to do so effectively. It wrongly thought that it was entitled to exercise termination rights under the MSA.

For the above reasons, in my judgment there was no wilful default on the part of IBM within the meaning of the MSA.

In conclusion, the Court’s findings on termination are as follows:

CISGIL’s case is:

IBM’s case is:

Clause 12.1 provides:

“The Supplier warrants and represents to Customer and each member of the Customer Group that:

…

(c)

having taken all reasonable steps (including making all appropriate inquiries and obtaining all appropriate professional and technical advice) that it has satisfied itself as to all risk, contingencies and circumstances to do with its performance of the Agreement.”

The use of the word “represents” doesn’t add anything to the meaning of “warrants” in this context because clause 38 of the MSA is a non-reliance provision which limits each party’s remedy in respect of any representation to such remedy available for breach of contract under the terms of the MSA.

Neither party has suggested that the provision would not be effective as a term of the contract; rather, the issue concerns the nature of the contractual promise.

CISGIL submits that clause 12.1(c) imposes an obligation on IBM to take all reasonable steps to satisfy itself that IG’s software was capable of providing the IT solution within the contractual or other reasonable timescale.

IBM contends that clause 12.1(c) is directed towards IBM satisfying itself as to the risks associated with performance of the MSA, not to provide CISGIL with comfort or a potential remedy but to preclude IBM from subsequently making claims against CISGIL, or seeking relief from its obligations, in relation to matters which should have been reasonably foreseeable to IBM. IBM submits that the clause allocates the risk of increased time or cost as a result of adverse risks, contingencies and circumstances (which IBM should have anticipated) to IBM.

The natural and ordinary meaning of the words used are that IBM warranted or promised that at the date of the MSA:

I reject IBM’s argument that the purpose of the clause is to limit IBM’s ability to claim against CISGIL, or claim relief from its contractual obligations, by relying on matters that it should have anticipated but failed to anticipate.

Firstly, that is not what the words say. The clause is a simple promise that certain steps have been taken to ascertain the risks associated with the MSA.

Secondly, clause 12.1(c) contains no reference to any limitation on rights or claims IBM would otherwise have. In contrast, clause 4.1 uses explicit words where it is intended to have the effect of limiting IBM’s ability to claim remedy or relief against CISGIL:

“The Supplier acknowledges and confirms that it:

(a)

has had the opportunity to carry out:

(i)

a thorough due diligence exercise in relation to the Core Services that are categorised as fixed price in schedule 5 (Charges); and

(ii)

sufficient due diligence in relation to the Core Services that are categorised as capped price in the aggregate in schedule 5 (Charges);

(b)

has raised all relevant due diligence questions about the Core Services which are categorised as fixed price and capped price in schedule 5 (Charges) with the Customer before the Contract Date;

(c)

has received all information from the Customer that has been requested by it pursuant to clause 4.1(b) above, in order to enable it to determine whether it is able to provide the Core Services which are categorised as fixed price and capped price in schedule 5 (Charges) in accordance with the terms of this Agreement and to agree any fixed and capped Charges, and it agrees that no further amounts whatsoever will be sought from the Customer in addition to any

such fixed or capped Charges except pursuant to schedule 5 (Charges) and clauses 2.10 and 9.7; and

(d)

has entered into this Agreement in reliance on its own due diligence alone.”

[Emphasis added]

Thirdly, the allocation of risk between the parties regarding performance of the MSA is set out in other provisions. In particular, clauses 5 and 9 impose on IBM obligations regarding the time for performance and set out the limits of each party’s responsibility for delay.

Finally, IBM’s construction ignores the other provisions in clause 12.1 to which the warranty applies, namely, clause 12.1(a), a warranty that IBM has authority to enter into the MSA, and clause 12.1(b), a warranty that IBM is free to enter into the MSA. Collectively, the provisions in clause 12.1 provide assurances to CISGIL as to circumstances existing at the time of the MSA that might have a significant adverse impact on IBM’s ability to perform its obligations under the same.

CISGIL submits that the requirement to take all reasonable steps is a stringent one; there is no discernible difference between an obligation to use all reasonable endeavours and an obligation to use best endeavours. In each case, the obligation is to go on using endeavours until the point is reached when all reasonable endeavours have been exhausted. Reliance is placed on the decision of the Singapore Court of Appeal in KS Energy Services Ltd v BR Energy (M) Sdn Bhd [2014] SGCA 16.

Although the KS Energy judgment contains a very useful review of the authorities on this issue, I do not accept that an obligation to use ‘all reasonable endeavours’ is necessarily the same as an obligation to use ‘best endeavours’, although in many cases there may be no discernible difference in practice.

In Rhodia International Holdings Ltd & Anor v Huntsman International LLC [2007] EWHC 292 Julian Flaux QC (as he then was), sitting as a deputy High Court Judge, considered this issue:

“[31] First, there was some debate at the hearing as to whether "reasonable endeavours" is to be equated with "best endeavours", a question on which there seems to be some division of judicial opinion. At the end of the day I am not convinced that it makes much difference on the facts of this case, but since the point was fully argued, I should deal with it. Mr Beazley QC for Rhodia contended that there was no difference between the two phrases. He relied upon a passage from the judgment of Buckley LJ in IBM v Rockware Glass [1980] FSR 335 at 339:

"in the absence of any context indicating the contrary, this [an obligation to use its best endeavours] should be understood to mean that the purchaser is to do all he reasonably can to ensure that the planning permission is granted".

There are similar statements in the judgments of Geoffrey Lane LJ at 344-5 and Goff LJ at 348.

[32]

Mr Beazley also relied upon what Mustill J said in Overseas Buyers v Granadex [1980] 2 Lloyd's Rep 608 at 613:”

"it was argued that the arbitrators can be seen to have misdirected themselves as to the law to be applied, for they have found that EIC did "all that could reasonably be expected of them", rather than finding whether EIC used their "best endeavours" to obtain permission to export, which is the test laid down by the decided cases. I can frankly see no substance at all in this argument. Perhaps the words "best endeavours" in a statute or contract mean something different from doing all that can reasonably be expected-although I cannot think what the difference might be. (The unreported decision of the Court of Appeal in IBM v Rockware Glass upon which the buyers relied, does not to my mind suggest that such a difference exists…).

Mr Beazley pointed out that in Marc Rich v SOCAP (1992) Saville J equated best endeavours with due diligence and that Rix LJ in Galaxy Energy v Bayoil [2001] 1 Lloyd's Rep 512 at 516 equated reasonable efforts with due diligence, which suggested that best endeavours and reasonable endeavours meant the same thing. He sought to distinguish the unreported decision of Rougier J in UBH (Mechanical Services) v Standard Life (1986) that an obligation to use reasonable endeavours was less stringent than an obligation to use best endeavours, on the grounds that the point was not argued but conceded by Counsel.

[33]

I am not convinced that (apart from that decision of Rougier J [in UBH]) any of the judges in the cases upon which Mr Beazley relied were directing their minds specifically to the issue whether ‘best endeavours’ and ‘reasonable endeavours’ mean the same thing. As a matter of language and business common sense, untrammelled by authority, one would surely conclude that they did not. This is because there may be a number of reasonable courses which could be taken in a given situation to achieve a particular aim. An obligation to use reasonable endeavours to achieve the aim probably only requires a party to take one reasonable course, not all of them, whereas an obligation to use best endeavours probably requires a party to take all the reasonable courses he can. In that context, it may well be that an obligation to use all reasonable endeavours equates with using best endeavours and it seems to me that is essentially what Mustill J is saying in the Overseas Buyers case. One has a similar sense from a later passage at the end of the judgment of Buckley LJ in IBM v Rockware Glass at

343, to which Mr Edwards-Stuart QC drew my attention.”

What amounts to ‘best endeavours’ was considered by Moore-Bick LJ in Jet2.com v Blackpoool Airport Ltd [2012] EWCA Civ 417:

“[31] In my view the obligation to use best endeavours to promote Jet2’s business obliged BAL to do all that it reasonably could to enable that business to succeed and grow and I do not think the object of the best endeavours is too uncertain to be capable of giving rise to a legally binding obligation …

[32] It was a central plank of BAL’s argument before the judge that the obligation to use best endeavours did not require it to act contrary to its own commercial interests, which, in the context of this case, amounts to saying that BAL was not obliged to accept aircraft movements outside normal hours if that would cause it financial loss. Some support for that conclusion can be found in the cases, … but I think the judge was right in saying that whether, and if so to what extent, a person who has undertaken to use his best endeavours can have regard to his own financial interests will depend very much on the nature and terms of the contract in question …”

Although an obligation to use best endeavours is likely to encompass all reasonable steps that could be taken, it might extend to more than an accumulation of moderate or sensible steps. It is conceivable that the circumstances of a particular case could require the party with such an obligation to go further, such as taking steps that were against his own financial interests, or steps that required extraordinary efforts. Such steps are unlikely to fall within the scope of a ‘reasonable endeavours’ obligation.

The above authorities provide helpful guidance as to meaning of the phrase “all reasonable steps” but that does not obviate the need to interpret those words as part of the agreement between the parties in this case. The scope of “all reasonable steps” must be considered in the context of this particular contract, against the factual matrix and taking into account the expert evidence as to the reasonable steps that could, and should, have been taken.

CISGIL’s pleaded case is set out at paragraphs 40, 43 and 43A:

“40.

Following the Claimant's notice of dispute dated 13 April 2017 which set out the financial loss and damage which the Claimant expected to suffer as a result of the delays that had been incurred, the Defendant informed the Claimant that it would shortly be in receipt of a

report from its external consultants on the state of the source code of its subcontractor, Innovation Group. The Claimant infers that the purpose or one of the purposes of the review by the external consultants was to ascertain whether the Innovation Group software that the Defendant had contracted to provide was capable of delivering the Solution. The Claimant also infers that the Defendant had not carried out such a review before entering into the MSA.

…

43.

Whether Innovation Group’s software was capable of providing the Solution within the contractual or other reasonable timescale was a risk, contingency or circumstance to do with the Defendant’s performance of the MSA within the meaning of clause 12.1(c) of the MSA. Accordingly, in the premises set out at paragraph 40 above, it is to be inferred that the Defendant’s representation and warranty set out in clause 12.1(c) of the MSA was untrue. As at the date of the MSA, the Defendant had not taken all reasonable steps (including making all appropriate inquiries and obtaining all appropriate professional and technical advice) with a view to ascertaining whether Innovation Group’s software was capable of providing the Solution within the contractual or other reasonable time scale. This was a necessary and obvious step for the Defendant to take before entering into the MSA and it is to be inferred that the Defendant made no relevant inquiries of Innovation Group or that such inquiries as it made were inadequate.

PARTICULARS OF ENQUIRIES

(i)

As the Defendant was well aware inter alia from the terms of the MSA (clauses 2.2 (a) to (c), paragraphs 2.1(b) and 7.1(a) and (b) to Appendix

CISGIL’s case is that the Roadmap was extremely aggressive. The ability to configure an off-the-shelf product was critical to reducing the risks associated with the time and costs of the project. Insurer Suite did not meet the contractual requirements of a set of standard, market strength, regulatory compliant software products which could be used in an out of the box fashion. IG was unable to build the additional Insurer Suite functionality required for the UK insurance market and CISGIL within the contracted timescales, or within any reasonable extension of those timescales.

IBM’s case is that the MSA and Key Milestones were predicated on the basis that the Insurer Suite part of the Solution would be implemented through a combination of configuration, customisation and base product development, to the extent and in the manner identified by the fit-gap analysis undertaken pursuant to the ISA. Insurer Suite

This allegation was based on limited factual evidence. Ric Wood was employed by IG as the client account director for IBM between August 2015 and January 2016. In his witness statement he set out his understanding:

“At the point that I joined 1i, it was clear to me that 1i did not have a UK ready or an out of the box product for either direct home or motor offerings. Significant development was needed to the Insurer Suite software so that it would meet CISGIL’s or any UK insurer’s requirements.

It was not surprising that Insurer Suite was not UK ready as CISGIL was the first customer to take the Insurer Suite product end-to-end …

Based on the UK projects 1i had carried out, the Insurer Suite code had a more developed UK claims module (as compared to its Policy module) but any work to develop the Policy module would lead to work being required to the base code for the Claims module (as the two modules are intrinsically linked). From my point of view the team at 1i always understood that the Policy module was not ready for either the UK household or motor insurance market.

1i did have a “core code” for an insurance product but it was for a US motor and home offering. In particular 1i had a base ‘Policy and Claims’ system which enabled a US insurer to write, renew or amend a policy or to make a claim against it. It was sufficient to enable a simple and generic demonstration for sales purposes in the UK. But the code for an insurance IT platform is very different between the US and UK jurisdictions …

When I arrived at 1i in August 2015, the functionality required in respect of the … UK specific aspects did not exist or was not complete…

Given the above I did not believe that the project was deliverable in the timeframes that CISGIL required.”

Mr Wood was at IG for a short period of time, some five months, and his role was dealing with the IBM client account. He carried out no investigation into the status of the Insurer product and was not involved in its design or development. He stated that it was clear to him that significant items were not part of the core product but in crossexamination he was vague as to his understanding of the product. He stated that personnel at IG all knew that significant work was required to develop the product

Dr McArdle’s analysis of the Insurer software disclosed that the base code was segmented between common (‘International’) functions and certain specific (‘County Specific’) functions. Further, the software stack contained functions specific to a particular user (‘Customer’), as well as a ‘Hotfix’ area for temporary defect fixes. On that basis, his opinion was that Insurer Suite was intended for an international market; it was not written for the USA market; it was a highly configurable product suitable for use in a number of markets.

In her second report, Dr Hunt considered Dr McArdle’s above views and stated:

“48.

In my view, it would be more accurate to say that the structure of Insurer Suite is designed to allow the base product to be modified on a per region basis. It is not possible to say, simply on the basis of the architecture, whether the product had been developed for one market or another. The extent to which such regional modification had in fact been carried out by IG prior to the MSA can only be determined by considering the functionality of the product and the changes and enhancements that needed to be made to suit the UK.

49.

In my view, the amount and nature of the development that was required in Insurer Suite to support key UK functionality, such as aggregators, CUE, MID and so on, strongly suggests that the UK regional layer had not been fully developed at the time of the MSA.”

Thus, Dr Hunt did not disagree with Dr McArdle that the Insurer Suite product was designed for an international market and could be configured for use in a specific region, such as the UK. Her view, that it was necessary to look at the nature and extent of the development actually required to meet the requirements of the MSA, raises a valid, but different, point which is considered in more detail below.

CISGIL relies on an internal IBM email exchange between Mr Gill, Mr Ward and Mr Allen on 11 October 2016, in which the suitability of the rating component was discussed. Mr Ward stated:

“The rating component is in the 1i base product and is designed for US market. That base has been customised for UK and the Co-op requirement and will remain part of the base solution.”

This exchange certainly indicates that some degree of customisation would be required of the rating component to meet CISGIL’s requirements but it is flimsy evidence on which to base an allegation of breach of warranty in respect of the whole of the Insurer Suite product. It does not address the substantive issue, which is whether the extent of configuration and customisation required went beyond the agreed scope in the MSA.

The MSA contained the parties’ agreed understanding as to the functionality that would be provided by Insurer Suite and the development work required to provide the IT solution.

The Implementation SOW included the following provisions:

“1.1

The Supplier shall provide the following Services and Deliverables to the Customer in accordance with the terms of the Agreement and this Statement of Work, in order to implement the Solution.

…

1.5

The Supplier shall perform the following functions defined in Appendix A of Schedule 3 as well as specifically the following under this SOW:

…

1.5.4

Application Management:

a)

Implement all the applications required to deliver, operate and manage the Solution, such applications shall be based on the Architecture Software Bill of Materials (DLV-003);

b)

Source, configure “Out of the Box”, test and deploy, as required, versions of Software and data in all technical environments necessary to deliver, support (including training facilities) and develop the Solution to meet the Customer Requirements.” 431. Schedule 2 to the MSA stated:

“The Supplier will provide the Customer with a series of services as particularised in Schedule 3 in order to meet the requirements collectively specified in the accompanying schedules in this agreement and the following documents:

a)

DLV-001 Business Functional Requirement Specification

Version 1.0.0 05 06 2015

b)

DLV-002 Architecture Model Diagrams (E2E Solution)

Version 1.0.0 27 05 2015

c)

DLV-004 Integration Interface Inventory Version 1.0.0 27 05 2015

d)

DLV-012 Non-Functional Requirements Version 1.0.0 27 05 2015.”

Schedule 3 to the MSA stated:

“1.2

The Services to be provided by the Supplier to the Customer under this Agreement comprise: (a) Implementation Services (as set out at Appendix A).

…

7.1

The Supplier shall:

a)

deliver Software "out-of-the-box" to satisfy the Customer Requirements as defined in DLV0001 (business requirements), appended to schedule 2 (Customer Requirements);

b)

configure the "out-of-the-box" Software to meet the Customer Requirements as defined in DLV001 (business requirements), appended to schedule 2 (Customer Requirements)…”

Details of CISGIL’s requirements, how and to what extent they would be met, were set out in the following contractual documents:

The fit-gap documents set out CISGIL’s detailed requirements for the IT solution, the existing functionality provided by Insurer Suite and an assessment of how each requirement could be met. The schedules identified whether the requirements would be met by OOTB product, base development, customisation or configuration (unless out of scope), together with an estimate of the effort required and the relevant release under which the functionality would be provided.

The IT experts, Dr Hunt and Dr McArdle, were instructed to consider whether Insurer Suite was substantially re-written and/or re-developed during the course of the project to meet CISGIL’s requirements (including to meet UK regulatory requirements) beyond the development, configuration and customisation identified at the time of and/or in the MSA; if so, why, in what respects and to what extent.

In their joint statement dated 11 June 2019, they agreed that at the date of the MSA, Insurer Suite was an existing, developed and tested software package.

Dr Hunt’s opinion was that Insurer Suite was substantially re-written and redeveloped after the date of the MSA to meet CISGIL’s requirements and the scale of development work went far beyond what was envisaged at that date. The foundation of her assessment was that IG estimated that the necessary base development would require 2,500 days effort. On the assumption that IG intended to provide release 1 by September 2015, Dr Hunt considered that such base development should have been more than 50% complete by June 2015 but IG were still developing functionality included in the estimate in January 2017, two years’ later.

Dr Hunt carried out an analysis of the fit-gap schedules (save for DLV028), summarised in Appendix B to her first report. The fit-gap schedules identified 1235 fit-gaps, of which 97 required base development and 282 required customisation, some 30%. However, as Dr Hunt accepted in cross-examination, the 643 product items in the schedules included some that were not identified as available in release 0 “OOTB”; they would not be provided until releases 1, 2 or 3, indicating that further development would be required.

Dr Hunt’s opinion was that, save for ‘Claims’, the other components of Insurer Suite required more development than anticipated. She considered that, contrary to CISGIL’s requirements, significant areas of functionality that should have been built into the base code of Insurer Suite were instead delivered as customisation specific to CISGIL, taking the Solution off the standard upgrade path and adding substantial work and complexity to the implementation. This view was based on a comparison between the expected development identified in the fit-gap assessments and evidence of actual development in the Insurer Suite release notes, SubVersion, IBM’s code audit documentation and other documentary evidence.

The Insurer Suite release notes included the following:

Dr Hunt ascertained that 37 out of 110 new features included in the above releases were described as OOTB in the fit-gaps but required changes to the base Insurer Suite product. Her analysis included an assessment of the base development anticipated and required in specific areas of functionality.

The major core functionality modules in Insurer Suite were the ‘Claims’, ‘Policy’ and ‘Analytics’ modules.

In respect of the ‘Claims’ module, Dr Hunt’s assessment was that there was no additional development in Release 1 and only minor additional development in Release 2, broadly in line with what was expected at the date of the MSA.

In respect of the ‘Policy’ module, Dr Hunt’s assessment was that there were two key areas for Release 1 that underwent significant development.

The first area of development concerned the ‘Adaptive Rating Engine’ which was included in Release 7.4 of Insurer Suite but was replaced in its entirety in Release 7.5.02. Undoubtedly, this was significant development. However, the contemporaneous documents, including Ms Neate’s email of 6 April 2016, suggest that the Adaptive Rating Engine was re-written at CISGIL’s request during the course of the project. Dr Hunt accepted in cross-examination that this could explain the increase in base development.

The other area of development concerned the ‘Quote Guarantee’ component, which was identified in the fit-gap analysis as standard Innovation Insurer Suite functionality to be achieved by configuration. It was delivered in Drop 1, indicating that this area of functionality was built into the base code of Insurer Suite. Following delivery, it transpired that the functionality was defective. IBM conceded that it was defective. The problem was resolved; CISGIL accepted a workaround in the short term, it was fixed at no additional charge and delivered in Release 7.6. Dr Hunt considered that the Quote Guarantee issue was minor compared to the Rating Engine.

Dr Hunt’s view was that the fit-gap analysis indicated limited base development for the ‘Policy’ product for Release 2, through 11 fit-gaps but significantly more development was required to provide basic UK motor insurance functionality. However, in cross-examination she clarified that, under the MSA, additional fit-gaps to support the use of telematics indicated substantial base development and further development was anticipated for aggregators. That indicated that the anticipated base development and customisation was substantial (28 out of 54 entries in Dr Hunt’s Appendix B):

“Q. …you’ve described it as “limited” base development, and what I’m inviting you to agree with me, Dr Hunt, is that actually it’s not limited, it’s actually there’s more to it than that.

A. … I apologise if this is confusing. I think my conclusion is kind of in the wrong order. So I think what I’ve done is discount the telematics because that was deferred …telematics was a potentially fairly substantial piece of base development, but that essentially was deferred by agreement, I think, so I agree if you put telematics back into the pot, it’s more substantial…

Q … even if you take out the aggregators, the four aggregators at the bottom, and even if you take out telematics, it’s still not right to describe it as “some limited base development”; there’s still a significant amount of base development?

A. There’s a chunk of requirements that need to be developed, yes.”

Further, in relation to ‘Policy’ spin off functionality in Release 2, Dr Hunt was unable to form a view as to whether it was included in IG’s original estimate of 2,500 days’ base development, and whether it was UK specific work or more general additional functionality requested during the sprint process.

“Q. It’s possible, isn’t it, that some of these requirements, many of them, indeed, I would suggest, may have been provided in response to requests made during the sprints process as opposed to being part of the original functionality which IBM had agreed to provide?

A. We don’t really have anything that tells us exactly what IBM had agreed to provide at this level of detail… So the answer to that question is ‘Yes’.

Q. … indeed, some of them may be enhancements to the base product made by IG as part of its product development that had nothing to do with CISGIL?

A. It’s possible, yes.

Q. … can I suggest that the enhancements themselves, whether looked at individually or all together, were not significant in the context of the core policy functionality?

A. Only as far as they were significant for CISGIL to provide UK motor insurance. So they’re not, they’re certainly not substantial.”

Dr Hunt confirmed in her evidence that she did not identify any unanticipated development in respect of the ‘Analytics’ module. In respect of the Transactional Data Store (“TDS”), used for numerous analytical requirements, Dr Hunt read the fit-

In respect of the ‘Complaints’ functionality, Dr Hunt’s report stated that more development was carried out than anticipated in Release 1 but in cross-examination she agreed that it would have been clear to anyone reviewing the fit gaps that a significant amount of development was required. This concession is supported by the factual evidence. Mr Southworth agreed in cross-examination that at date of the MSA, CISGIL understood that there was no OOTB product in existence for customer complaints and that customisation and base development would be required to achieve regulatory compliance. By late 2015 the parties agreed that not all functionality had been provided but there was a dispute as to the scope of functionality IBM was obliged to deliver. Pending resolution of that dispute, CISGIL was prepared to go live with Release 1 without any complaints functionality in Insurer Suite because it could continue to use its existing ‘Respond’ tool. It was common ground that some additional development was required to address regulatory issues. In

The ‘Customer’, ‘Quote & Buy’ and ‘Supplier’ Portals were user interface tools developed by Edge Connect that allowed users to interactively design screen layouts and sequences of actions, and automatically generate code. Schedule DVL001 to the MSA stated that a new portal would be built; the fit-gap schedules showed that significant base development and customisation was anticipated for the Customer Portal (including the Quote & Buy journey), as accepted by Dr Hunt in crossexamination. It was common ground that there were delays, changes and other developments to the portals but Dr Hunt agreed that IBM could not have anticipated such additional work.

Dr Hunt’s assessment in her first report was that there was substantially more than anticipated development for the Release 1 and Release 2 ‘Interfaces’ and ‘Aggregators’. However, in cross-examination, she agreed that Schedule DLV004 stated that it was a working document, indicating that further development might be required, and a large number of interfaces were identified in the fit-gap schedules as requiring customisation:

“Q. Can we agree this: on any view there was a substantial amount of work on the interfaces that was anticipated at the time of the MSA?

A. On interfaces generally, absolutely, yes.”

Dr Hunt’s assessment that the base development required was substantially more than anticipated was predicated on the delays that occurred to the interface and aggregate components for Release 1 and Release 2. This logic is flawed. Although development delay was a reasonable basis on which to identify areas that justified greater scrutiny, it was necessary to ascertain the underlying causes of such delay so as to understand whether the driving factor was additional base development or something else, such as inadequate resourcing or defective work. There could be many reasons for an element of work to be delayed or take longer than estimated; it does not follow that there must have been substantial, or indeed any, growth in the quantity of development or customisation carried out.

I accept IBM’s submission that Dr Hunt’s quantitative assessment of the extent of effort expended on development carried out during the project does not substantiate CISGIL’s case that there was substantially more development than anticipated at the time of the MSA, or that Insurer Suite was substantially re-written or redeveloped.

Dr McArdle carried out a different form of assessment by analysing the source code. He examined the Insurer Suite code in the Subversion repository using a tool known as ‘TORTOISE SVN’ and relied on an analysis of the Insurer Suite code carried out by Omnext, the results of which were appended to his second report dated 25 October 2019.

CISGIL has objected to any reliance on the Omnext appendices on the grounds that IBM does not have permission to adduce expert evidence from Omnext, they are not independent experts, having produced reports for IBM during the currency of the project, and Omnext was provided with source code by IG at IBM’s request which was not made available to CISGIL.

The basis on which Omnext were instructed was explained in a letter dated 11 November 2019 from CMS to Addleshaws. For the purpose of their analysis, Omnext were provided with extracts of Insurer Suite base code, namely, Versions 7.4, 7.5.02 and 7.6, together with a full download of the CISGIL-specific SVN code repository. The code extracts were supplied directly by IG; neither Dr McArdle nor Dr Hunt were provided with access to the base code but CISGIL was invited to instruct Omnext to perform further analysis if required. On 15 November 2019 this Court granted permission to CISGIL for Dr Hunt to file and serve a supplemental report to address the source code analysis section in Dr McArdle’s second report, without prejudice to CISGIL’s entitlement to contend that IBM was not entitled to adduce evidence from Omnext or rely on the same.

It is regrettable that this issue was not discussed between the parties or raised with the Court prior to any source code analysis by Omnext and the preparation of Dr

I have considered whether the Omnext evidence should be excluded, as submitted by CISGIL, but I have decided, on balance, that it should be admitted. The exercise carried out by Omnext was a discrete logic line counting exercise, the results of which were subject to critical analysis and opinion by the IT experts. Omnext did not provide any opinion on the conclusions, if any, that could be drawn from their exercise. Although the base code extracts were not made available, both IT experts and the parties were in the same position and therefore there was a level playing field. Dr Hunt was able to consider the Omnext exercise and respond to Dr McArdle’s expert evidence on this issue in her third report dated 29 November 2019. CISGIL was offered the opportunity to instruct Omnext directly to perform other analyses, without sharing them with IBM unless it wished to rely on them in the trial. I am satisfied that CISGIL has not been prejudiced by the inappropriate way in which the Omnext evidence was introduced.

As to the value of the exercise, the IT experts agreed that in theory it would be possible to measure the lines of code contained in the base product of Insurer Suite, the base releases and the customised code to understand the extent of development carried out as part of the project. Dr Hunt’s initial view was that such code analysis would not be viable in this case because of the lack of detail in the estimate of base development, the way that Insurer Suite was structured and IG’s approach to customisation. She considered that a comparison of the amount of code in each Insurer base release would give some indication of the amount of new code produced but would not identify any code that had been replaced or re-developed; the ‘copy and modify’ approach to customisation used by IG meant that customer-specific changes were not contained in clearly identifiable modules or areas; the Hotfix area could give an indication of how much code was designated as ‘back to base’ but this was based on IG’s subjective decisions about what to place in this area.

Dr McArdle agreed with Dr Hunt that they were hampered in their analysis by IG’s practice of copying across large quantities of code from the base product into the customer layer and making relatively small modifications to develop CISGIL-specific code, which could give a false indication of the amount of new code. However, his view was that, despite this difficulty, code analysis could be carried out by using automated code analysis tools to compare any two sets of code to establish how much code was copied across, added, modified or removed, giving a direct measure of the extent of any re-development of the product.

In cross-examination, Dr Hunt agreed that there would be some value in such analysis:

“Q. … Dr Hunt, would you nevertheless accept … that looking at the modified and deleted code in conjunction with the added code, can nevertheless give you an insight that you don’t get just from looking at the added code in isolation?

A. Yes.”

Dr McArdle procured two comparison exercises carried out by Omnext using their automated code comparison tools to count logical lines of code and detect additions, deletions and modifications. The first exercise compared different versions of the base product (International and Country-Specific Layers), namely, Release 7.4 (the base release on which the fit-gaps were based) and Release 7.6 plus Release 2 drop 23 (as at the date of termination), to identify any changes. The second exercise compared various drops of the CISGIL-specific code (Release 1 Drops 1, 33 and 80, and Release 2 Drop 23) with the base product (at Releases 7.5.0.2 and 7.4) to establish what parts of the CISGIL-specific code were copied from the base product without change, what was added and what was modified in the Customer Layer, including Hotfixes.

Dr McArdle’s analysis of the results concentrated on the changes to the Java code, which the IT experts agreed was the language in which the core functionality of Insurer Suite was written. The base code figures for the International and UK layers were reduced by 50% to reflect the fact that not all code was added for the benefit of CISGIL; when customising code, large parts of the international base code would be copied and pasted for the programmers to work on; if not changed, such code would already be accounted for in the international layer. Dr Hunt did not disagree with this approach.

The comparison between the Insurer Suite Java code as at Release 7.4 and the code as at Release 7.6 plus Release 2 drop 23 demonstrated an increase in CISGIL-specific new Java code of 18.17%. This percentage is not inconsistent with IG’s estimate precontract that a substantial amount of effort was required for customisation of Insurer Suite.

The analysis of the Java code that was modified or deleted demonstrated that 5.67% of the base product code was replaced or re-written. This percentage change can not be described as very substantial.

In her third expert report, Dr Hunt raised four concerns as to the accuracy and completeness of the Omnext exercise in reflecting the amount of Insurer Suite development during the project.

Firstly, Dr Hunt correctly noted that the Omnext analysis excluded any consideration of the source code for portals, TDS and Insurer analytics but accepted that the portals were developed outside Insurer Suite. Further, CISGIL did not take up the offer from IBM’s solicitors to instruct Omnext to carry out additional exercises to include those components.

Secondly, Dr Hunt raised a concern that the Omnext analysis might wrongly include free and open source software (FOSS) but she accepted in cross-examination that it would be very unusual for IG to download the source code for FOSS libraries. Again, CISGIL did not ask Omnext to check whether any Java source code from FOSS software was included in their analysis.

Thirdly, Dr Hunt pointed out that the Omnext analysis excluded any assessment of intermediate releases, such as Release 7.5; it simply identified the net number of changes to the final version. However, although the intermediate changes might be relevant to issues of delay, they would not affect the efficacy of the Omnext exercise,

Finally, Dr Hunt raised a legitimate point that because IG did not adopt a consistent method of assigning code to international, regional and customer layers, Omnext might have assigned base development changes and customisation to the wrong layers. However, she accepted in cross-examination that this was irrelevant if one was looking at the total amount of code across all layers, which was the basis of Dr McArdle’s conclusions.

I accept that the IT experts had a difficult task, in that the repository tools made available did not contain sufficient information to allow a detailed analysis of all of the code. However, the logic line code counting exercise carried out by Omnext provided them with the best evidence available to form an overview of changes to the source code. That provided the backdrop against which the experts could consider the factual witness and documentary evidence, and provide their assessment as to the extent of development and re-writing of the Insurer product.

Having considered the IT expert reports and listened carefully to their oral evidence, for the reasons set out above, I find that:

In the light of the above findings, it is not strictly necessary for the Court to determine whether IBM failed to take all reasonable steps to ascertain the risks associated with Insurer Suite. However, for completeness and because evidence was adduced on it, I address the issue below.

In their joint statement dated 11 June 2019, Dr Hunt and Dr McArdle set out the following agreement:

“We agree that in order to satisfy itself that Insurer Suite was capable of meeting the contractual specifications within the contractual time scale, we would have expected a party in IBM's position to have performed a due diligence investigation. We agree that there is no standardised approach to due diligence activity of this type and that different organisations perform different levels of investigation. We agree that a range of investigations and outline design were undertaken during the pre-contract due diligence phase and during the ISA phase of the project.”

The IT experts agreed that reasonable steps by IBM to satisfy itself as to the risks, contingencies and circumstances concerning the project would include the following areas:

The RFP period, due diligence and fit gap phases of investigation and collaborative working between CISGIL, IBM and IG occurred between June 2014 and June 2015. This amounted to a substantial effort expended over a period of a year prior to execution of the MSA.

Ms Keohane, lead for the integration and business operating model at CISGIL, agreed when giving her oral evidence that during the ‘Deep Dive’ sessions in 2014, IG demonstrated an end-to-end policy and claims process but it was understood that not all of CISGIL’s requirements would be met by Insurer Suite without customisation. The spreadsheet produced as a result of the due diligence phase at the end of 2014 / beginning of 2015 enabled Ms Keohane to establish which of CISGIL’s requirements were within the scope of the project; if so, whether they would be delivered OOTB, or by development or customisation. She accepted that the fit-gap analysis was a detailed breakdown of the product, base development, customisation and configuration that would be supplied by IBM to meet each of the business requirements identified by CISGIL; the fit-gaps were signed off by the SMEs and by Carl Burton of CISGIL; and the analysis enabled her to trace the fit-gaps back to the contractual 551 requirements.

Mr Summerfield accepted in cross examination that during the tender and due diligence phases, IBM was identified as the best option following a high degree of investigation. Questions of the capability of Insurer Suite were primarily addressed by IG, as CISGIL both knew and expected. IG’s reputation and industry standing was a factor which CISGIL took into account when selecting IBM as a supplier. CISGIL formed a positive impression of IG from interaction during the due diligence process and it was satisfied that Insurer Suite could meet CISGIL’s requirements. CISGIL was aware that there were a substantial number of its requirements that did not exist OOTB and therefore, would require at least some base development or customisation. He agreed that CISGIL did not suggest, or expect, IBM to carry out a code review of Insurer Suite; it expected IBM to rely on IG to deliver Insurer Suite.

Dr Hunt agreed in cross-examination that the fit-gap analysis was an appropriate way of understanding the fit between a customer’s functional requirements and the proposed solution, and that she would not expect a supplier to carry out a code review of its independent sub-contractor’s solution:

“Q. The subcontractor would be extremely unlikely to reveal its code to another supplier wouldn't it?

A. That's true and viewing the code would not necessarily tell you about the fit anyway.”

Mr Jackson of IBM explained in his witness statement that the due diligence phase (October 2014 to December 2014) comprised a series of workshops and meetings between CISGIL, IBM and IG. Their purpose was to enable CISGIL to understand what would be provided by Insurer Suite OOTB product and to enable IG to understand how Insurer Suite would need to be configured, customised or developed to meet CISGIL’s requirements. The due diligence exercise was subject to a quality assurance assessment by independent consultants, Chandler Gilmour Associates, who advised CISGIL that they were comfortable that the solution proposed by IBM and IG would be fit for purpose and that CISGIL could proceed to the detailed design stage.

IBM carried out an internal assessment of the technical and commercial risks associated with the project through its “Deal Board” meetings. In January 2015 IBM produced a delivery capability due diligence plan, which stated:

“IBM expects to enter into a contract with CISGIL … during Q1 2015 for the provision, implementation and long term run of a fully managed IT service supporting a new CISGIL business operating model. A significant component of these services will be provided by Innovation Group with IG’s Insurer product at the core of the solution. IBM intends to enter into a back to back contract with IG to support the agreement with CISGIL.

Prior to signing either of these contracts, IBM's internal governance process requires that a due diligence review of IG’s product and capabilities is conducted…”

Before IBM was prepared to provide its best and final offer to CISGIL, it recognised that further work was required to understand the detailed scope of the project. That led to the ISA, under which the fit-gap exercise was carried out. The IT experts both agreed that the fit-gap exercise was thorough. That is demonstrated by the level of detail in the MSA schedules. The product of that exercise, the fit-gap schedules, provided transparency as to the nature and extent of the development required, together with an assessment by IG of the effort required for such development.

IG set out its estimate of the effort necessary to meet the fit-gap requirements in the fit-gap spreadsheets. Dr Hunt converted the estimate of required time and effort set out in the fit gap assessment to 4,858 days, using an assumed 8 hour day (or 5,320 days, using the conversion rates in DLV-019). In addition, in January 2015 IG provisionally committed itself to carry out 2,500 man days of base development to meet CISGIL’s requirements, at no cost. IG stated that such development would commence as release 7.5, which was scheduled to start from September 2015.

IBM did not simply accept IG’s estimates; on 17 April 2015, Mr Down sent an email to Ian Bowen of IG asking for further details:

“there is an urgent need to increase CISGIL’s understanding of i) how estimates have been developed & validated at this stage of the programme, ii) the key drivers / risks of estimates needing to change and iii) the sensitivity of the estimates changing as a consequence.

… I'm contacting you as a work stream lead to respond by 10am on Monday 20/4 to the following three questions:-

1.

What are the method(s) / approach(s) used to develop and validate your workstreams estimates with regards to each of the key solution components

2.

What is the level of confidence you would assign to the estimates AND why

3.

What are the top 3-5 things which could cause your estimate to increase (or decrease) AND what is the approx.. sensitivity of your workstream solution component(s) to these parameters. ”

IG provided responses to these questions in the IBM Commercial Update document of 22 April 2015. The document set out the basis of IG’s workstream estimates for each key solution component, identifying the level of confidence in each estimate and the risk associated with each. Thereafter, weekly status update meetings were held to monitor ongoing progress.

Difficulties with IG resources were identified by IBM. On 22 April 2015 Arjan

On 20 May 2015 Martin Broughton of IBM chased IG for more details to support its fit-gap estimate of effort, such as the scale of costs and man days for customisations split by functional and integration activities. In response Ian Bowen produced a breakdown, showing total effort to meet requirements of 4,419 man days, of which 1,326 man days was estimated for customisation:

“Note: The efforts for customisation are taken from the fit gap for Insurer. Where any element of fit gap requires any customisation it is classified as a customisation requirement. In reality across these items less than 30% of the effort associated with the requirement is actual customisation, the rest is design, documentation, configuration and test.

As you can see approximately 50% of the effort is related to integration which all projects require. We estimate that we have spent of the order of 135,000 man days on developing the Insurer Suite to date (I have asked our product manager to confirm this) so the actual customisation is approximately 1% including integration or nearer 0.5% if we exclude integration.”

On 25 May 2015 Mr Bruggink sent a further email to Mr Jackson, entitled: “RED FLAG – IG performance puts project at risk: need help in managing them”, in which he stated:

“IG’s performance is becoming less co-operative and causes risk for the project …

IG does not have the bandwidth to work on anything else but sprint planning – thus creating issues with depending teams … The above puts deployment of R1 in March 16 at risk and avoids a start of R2 …

IG acknowledges all of the above, however also indicates that they do not have the means to solve the issues within weeks. I turn to you since my escalations do not have effect anymore (barking not biting). Need direction on how you want to progress. ”

These issues were escalated to Ian Bowen of IG, who explained in an email to Paul Osborne of IBM on 29 May 2015: “IG will only provide all resources on and off site once contracts are agreed.” He confirmed that IG would start the sprints a bit late but it still expected to achieve the overall end dates. Thus, the issue at this stage concerned IG’s reluctance to allocate resources to the project until it had a contract with IBM for the project-

Mr Jackson’s evidence was that there were 200-300 developers in Lahore, Pakistan carrying out development of the Insurer product. Although the base development was a substantial piece of work, he considered that it was achievable within a matter of three to six months. He accepted that IBM questioned the adequacy of IG’s resources during the ISA phase but this was prior to execution of the MSA and the contract with IG. At that stage, IG had no contractual requirement to start this work and any allocation of resources to the project was at its own risk. IG confirmed that it would have sufficient resources to meet the Release 1 completion date of March 2016.

In respect of the sub-contractor’s implementation capabilities and methodology, the ‘Agile’ methodology adopted by IG proved to be a failure but it had been developed with Deloitte’s specialist support and there was no flaw in the concept. Therefore, IBM could not be criticised for accepting use of such methodology for the project.

CISGIL is critical of IBM’s failure to secure a contract with IG that was on a full back-to-back basis with the MSA. IBM challenges CISGIL’s legal analysis of the IG contract and contends that it was back-to-back in essential respects. It is not necessary to resolve that dispute because it is immaterial to the steps which were reasonable for IBM to take to satisfy itself as to the risks concerned with contractual performance. Under the MSA, IBM had full responsibility for the performance of its sub-contractor, regardless of the terms on which its sub-contractor was engaged.

Drawing together the above evidence, it is apparent that the parties engaged in very substantial due diligence and fit-gap exercises that enabled IBM to satisfy itself as to IG’s capabilities to meet CISGIL’s requirements. Pre-contract, there was a very long period of collaborative working to ensure that the parties understood what was required and what would be supplied. The results of that collaborative working were the agreed fit-gap schedules. IBM obtained estimates for the time and effort required by IG to carry out the necessary base code development and to meet the requirements in the fit-gap assessments. It interrogated IG’s estimates for resourcing the project and considered the technical and financial risks associated with the same. No fatal flaw was identified in IG’s proposals for organising its work or its methodology. IBM took all reasonable steps to satisfy itself as to the risks, contingencies and circumstances concerned with its performance of the MSA.

For the reasons set out above, I reject CISGIL’s case that there was any breach of the warranty at clause 12.1(c) of the MSA.

For completeness I consider the consequences if, contrary to the finding above, CISGIL had established a breach of warranty as alleged.

I accept Mr Summerfield’s evidence that, if CISGIL had been told that Insurer Suite required substantially more development than identified in the fit-gap exercise and, as a result, the Key Milestones were unachievable, it is likely that it would have abandoned the project and not entered into the MSA. The benefits that CISGIL hoped to derive from Project Cobalt were substantial; they included increased competitiveness, cost savings, regulatory approval and a solution to the loss of the shared platform with Co-op Bank. However, prior to any commitment by executing the MSA, CISGIL would have paused if informed that those benefits might be in jeopardy. There remained the “lift and shift” option which, although inadequate to provide the business improvements desired by CISGIL, would have allowed it to exit the legacy platform prior to December 2017 and explore alternative long-term solutions.

In his witness statement, Mr Summerfield was careful to stress that he could not be certain as to what would have happened, if in 2015 he had been told that Insurer Suite required a substantial amount of rewriting or redevelopment to make it suitable for the UK insurance market. He stated that he would have asked for further details. His main concerns would have been increased costs and risk that it would jeopardise the deadline of December 2017 for CISGIL to exit the shared platform:

“Ultimately, I would not want to commit CISGIL to the MSA which placed heavy financial and other obligations on CISGIL if there were doubts over the feasibility, costs and timetable of the delivery and implementation.”

When it was suggested to him in cross-examination that the PRA would not have permitted CISGIL to continue without the transformation project, he responded:

“Well I'm afraid they would and they actually have. As a result of the failed programme we've had to do many of the things referred to in the previous documents that we shared… the PRA are allowing us to stay on the estate today, some considerable time after the programme was supposed to deliver. So yes, they would.” Conclusion on the warranty claim 500. In summary:

If all reasonable steps required to be taken by IBM had disclosed that Insurer Suite required substantial re-writing and development as alleged, CISGIL would not have entered into the MSA or continued with the project. Issue 3 – Reporting Claim on State of Insurer Suite

CISGIL’s case is that:

CISGIL stated in its closing submissions that it no longer pursues its allegation of “wilful default” in respect of this claim.

IBM’s case is that:

Clause 4.5 of the MSA, and Schedules 3 and 12 to the MSA, set out IBM’s relevant reporting obligations.

Clause 4.5(h) of the MSA including the following obligation on the part of IBM:

“The Supplier shall:

…

notify the Customer when it becomes aware of any development which may have a material impact on the Supplier’s ability to provide the Services effectively and in accordance with clause 4.5(d) and 4.5(e).” 506. Appendix A to Schedule 3 provided at paragraph 1.3:

“The Supplier shall report on progress of the Implementation Services, in accordance with schedule 12 (Governance and Reporting).”

Schedule 12 of the MSA included the following material provisions:

“3.1

This Schedule sets out the governance principles, structures, procedures and reporting activities that shall support the parties including, amongst other things, the following:

…

3.1.2

the ongoing assessment of whether or not Milestone Dates or Key Milestone Dates shall be achieved, and if not, why not and what remedial action can be taken to minimise the adverse impact of any delay;

3.1.3

the early identification of problems and issues so that they may be resolved in a prompt and co-operative manner…

3.2

The parties shall ensure that, through their

participation in the Governance Bodies they shall:

…

3.2.4

engender a relationship that is characterised by trust and openness.”

The above provisions imposed on IBM clear reporting obligations regarding progress of the project and any impediment that would prevent achievement of the key contractual milestone dates.

CISGIL’s pleaded case on this issue is set out at paragraph 43C of the Amended Particulars of Claim:

“… the Defendant did not inform the Claimant at any stage that the Insurer Suite did not provide the configurable Out of the Box solution upon which the MSA and the Key Milestones were predicated nor that the Insurer Suite had to be substantially rewritten and or redeveloped in order to meet the requirements it had contracted for and that the Key Milestones were unachievable. As to the timing of such breaches:

(i)

Innovation Group knew (because it owned the software) that the Insurer Suite was not “UK-ready”, could not be configured to meet the Claimant’s requirements Out of the Box and needed to be substantially re-written and/or redeveloped at the time the MSA was entered into. In consequence, it knew from the date of the MSA that the Key Milestones in the MSA and/or in its own subcontract were unlikely to be met or would not be met.

(ii)

At common law, Innovation Group’s knowledge is to be attributed to the Defendant because the Defendant was bound to perform its contractual obligations whether by itself or by its subcontractor. Alternatively, that is the effect of clause 18.5(a) of the MSA, whereby the Defendant agreed that it would not be relieved of any of its liabilities or obligations under the MSA by entering into any subcontract and it accepted liability for the acts and omissions of Innovation Group and its staff.

(iii)

At a meeting between the Defendant and Innovation Group in or about October or early November 2015 at Arndale House in Manchester, Jacqui Boast, CEO of Innovation Group, told the Defendant’s Denise Barnes that the Insurer Suite had been written for the US insurance market not the UK insurance market and that it had to be and was being substantially re-written and/or redeveloped in order to meet the Claimant’s requirements.

(iv)

Accordingly, from or about early November 2015, the Defendant knew that the solution it had contracted to provide could not be configured Out of the Box to meet the Claimant’s requirements, that the Insurance Suite for the UK market did not exist as a commercialoff-the-shelf product, that the Key Milestone dates that had been predicated on a configurable Out of the Box Solution had been compromised and that significant delays would or were likely to occur. ”

For the reasons set out above in respect of issue 2, in my judgment Insurer Suite did not require substantial re-writing and/or re-development to meet CISGIL’s UK regulatory or business requirements beyond that set out in the MSA. Therefore, this claim falls at the first hurdle.

Clause 18.5 of the MSA imposed on IBM responsibility for the performance of its contractual obligations regardless of whether those obligations were sub-contracted to others by IBM. It did not, expressly or implicitly, impute to IBM knowledge on the part of its sub-contractors. As IBM submits, the reporting and management obligations set out in the MSA were personal to IBM. The reporting obligations were limited to matters within IBM’s actual knowledge and did not extend to matters known only to IG.

I accept IBM’s submission that the proposition that IBM is immediately fixed with its sub-contractor’s knowledge is wrong and based on a flawed assumption. CISGIL submits that if IBM had sought to implement the core insurance functionality and had not sub-contracted it to IG, IBM would inevitably have had all IG’s knowledge about Insurer Suite. Clause 18.5(a) ensures that IBM cannot avoid liability because it subcontracted to IG and therefore did not acquire that knowledge itself. The flawed assumption is that IBM would have had IG’s knowledge about Insurer Suite. If IBM had not sub-contracted to IG, it would have had no knowledge of Insurer Suite. Almost certainly, it would have struggled to perform the MSA because it did not have the in-house knowledge and expertise to do so; hence the use of a specialist subcontractor. But it is unrealistic to suggest that IG would have handed over its intellectual property rights in Insurer Suite to allow IBM to ‘have a go’. CISGIL’s argument is a bad point.

CISGIL relies on an allegation in the Amended Particulars of Claim that at a meeting between IBM and IG in or about October or early November 2015 at Arndale House in Manchester, Jacqui Boast told Denise Barnes that Insurer Suite had been written for

This allegation was supported by Mr Wood’s witness statement:

“I recall attending a meeting with senior 1i and IBM executives which took place at CISGIL’s officer in the Arndale Centre Manchester (CISGIL did not attend). I had originally thought it was in late October or early November 2015 although now I believe it may well have been earlier, possibly September. Jacqui Boast, Steve Abbott, Ian Bowen, David Stokes and I attended the meeting from 1i and Denise Barnes, Martin Broughton, Sue Balcombe, Alistair Oldcorn and Arjan Bruggink attended from IBM (there may have been other attendees from 1i or IBM who I do not now recall). It was a big meeting of a “cards on the table” nature.

At that meeting, Jacqui Boast clearly explained to IBM:

(a)

how the core code for both home and motor still needed a significant amount of work to make it ready for the UK market, as well as to meet CISGIL’s requirements;

(b)

that Insurer Suite was miles (i.e. many months) away from being delivered to CISGIL; and

(c)

that to have a chance of delivering Insure Suite for home there would have to be delivery across three Drops, with only 5 to 10% of the required functionality being delivered in Drop 1, 20% in Drop 2, and 60 to 65% in Drop 3 with the corresponding extension to the contractual milestone dates. ”

Ms Boast, the former managing director EMEA and global CMO of IG, who left IG in April 2017, responded to that allegation in her witness statement:

“I have never told anyone that the Insurer Suite was written for the US insurance market but not the UK insurance market because I do not believe it to be the case. My understanding based on my knowledge of the software from my time as Managing Director of the EMEA division of li was that the Insurer Suite was not written specifically for the US market and it did not need substantial redevelopment for the UK market.”

In cross-examination, Ms Boast explained that the Insurer Suite product was largely developed in Pakistan by coders, based on designers in the UK and the US. She explained that when she joined IG in 2014, the product had been implemented in the US, the UK and Australia, mainly using the claims module.

“Q. What was happening in the CISGIL project, Project Cobalt, was that it was being customised for UK insurance requirements?

A.

The majority of the interfaces, the enrichment

interfaces, were new for the UK market …

Q. The enrichment you are talking about is the base development that needs to be carried out in order to make the rating engine work in the UK?

A. That's right and it was identified as a fit gap.”

When asked whether the “UK-isation” of the rating engine had not been undertaken prior to the MSA, Ms Boast responded:

“I don't think I could give an accurate answer to that. All I can say is that before we signed the contract, we put a full working version of the product into the sandbox so that everybody could see it, and we even built, from my memory, some dummy products, UK based products, that were available to CISGIL and to IBM to look at as part of the pre sales environment. So they had seen the rating engine and had used the rating engine in a sandbox environment before the contracts were signed.”

Ms Boast had no recollection of a meeting on about 29 September 2015 at which the three-drop strategy was discussed:

“Q. …at the meeting there was a discussion in which you were involved as to what parts of Insurer Suite functionality could be delivered into SIT on what dates?

A.

I don't have any recollection of a meeting.

Q. And in the course of that discussion, you told Ms Barnes that both the core code for … both home and motor still needed a significant amount of work to make it ready for the UK market, as well as to meet CISGIL’s requirements?

A. I don't remember saying that.

Q. That Insurer Suite was miles away from being delivered or deliverable to CISGIL? A. No, I don't believe I said that.

Q. And that to have any chance of delivering Insurer Suite for home, there would have to be delivery across three drops with 5-10% of functionality being delivered in drop 1, 20% in drop 2 and 60-65% in drop 3 with the corresponding extension to the contractual milestone date?

A. No, I don't recall having a conversation with Denise about percentages of drops.”

Ms Barnes also disputed that Ms Boast made any of the statements alleged above. When cross-examined on this issue, she confirmed that there was a meeting on 29 September 2015 but Ms Boast did not attend:

“There was a meeting on the 29th September but I don't believe Jacqui was there … Jacqui didn't get involved in that level of detail. She left it to Ric and to Steve Abbott, Dave Stokes, whoever was in the meeting. But Mr Wood was her

representative at that meeting.”

Ms Balcombe’s evidence was that there were meetings with IG prior to 30 September 2015 to discuss the three-drop plan; there was a meeting on 30 September 2015 with

When Mr Wood’s evidence was put to her in cross-examination, she disputed it:

“Q. Well, there was a full and frank exchange of views at that meeting and Ms Boast told you - you collectively - that there were serious issues with the state of Insurer Suite?

A.

No, absolutely not.

Q. And she told you that the code, the core code for Home and Motor still needed a significant amount of work to make it ready for the UK?

A. That would not make any sense based on the plan we were now putting together so no, absolutely not.

Q. And she also told you, didn't she, that Insurer Suite was miles away from being delivered or deliverable to CISGIL?

A. No, absolutely not. As I say we were doing a created plan with the same end date that didn't give anything – no, it would not have made any sense for her to have had that conversation and for us to present that to GI, absolutely not.”

Mr Broughton had no recollection of such a meeting and did not believe that Ms Boast had made the statements as alleged.

There are no notes of this meeting and no documents recording the statements that it is alleged were made. If Ms Boast had delivered the “cards on the table” bombshell, it is likely that there would have been some exchanges in writing evidencing this, internally at IBM, and between IBM and IG. IBM was not reticent in confronting IG when issues arose; this included concerns regarding compliance issues that were identified in the workshops and inadequate IG resources. Ms Barnes did not hold back when composing her emails to IG. The absence of any record of this issue strongly indicates that Mr Woods’ recollection and/or perception of what occurred was wrong.

Further, the evidence of Ms Boast, who no longer works for IG, Ms Barnes, Ms Balcombe and Mr Broughton is compelling. They each denied that such a meeting took place and provided explanations as to why Ms Boast would not have attended such a meeting or been involved in that level of detail. No evidence was produced which cast doubt on those explanations.

Finally, Mr Wood’s oral evidence contradicted the pleaded case. He stated that when he joined IG in August 2015, he didn’t have any concerns as to IG’s capacity and capability to deliver the solution. He recalled that after a couple of months working in the project, it became obvious to him that IG could not deliver within the timeframe that CISGIL required. However, he was the author of the three drops plan, initially produced at the end of September 2015 and revised in early October 2015. In crossexamination, Mr Wood agreed that at that stage he was confident that the revised plan could be met. His evidence was that this view changed by December 2015 but he did not share his new insight with anyone at IBM.

For the above reasons, CISGIL has failed to prove the central allegations relied on in support of this claim.

The pleaded case is that if IBM had reported the status of the project as set out in paragraph 43C of the Amended Particulars of Claim, CISGIL would have terminated the MSA and the SOWs, either immediately, for repudiatory breach, or in early

Mr Summerfield’s evidence is that if, between June 2015 and July 2016, he had been made aware of a delay of six months to original delivery dates, he would have recommended that CISGIL terminate the MSA as quickly as possible and rely on the “lift and shift” option.

I reject that evidence. By June 2015, CISGIL had committed significant time, resources and funding for the MSA. Mr Summerfield accepted in cross-examination that if it had terminated the MSA immediately, or soon after execution, CISGIL would have incurred losses of about £57.6 million. More significantly, CISGIL had told stakeholders and the regulators that Project Cobalt was a response to the PRA assessment that “the firm’s current business model is not sustainable”. It could justify abandoning the project prior to entering into the MSA, as the outcome of careful due diligence. It would be very difficult to justify abandoning the project immediately after the conclusion of the contract and would have a destabilising effect on CISGIL.

Likewise, I reject the suggestion that CISGIL would have terminated the project in

By the end of April 2016, Ms Neate had tendered her resignation, it was agreed that Ms Barnes would be removed from the project and it was clear that completion would be delayed until well into 2017. Yet Mr Summerfield stated that he did not consider termination at that stage:

“Q. There was never at any stage any consideration of terminating the MSA , was there, at this time?

A. At this point in time and with the information we'd got, we were still of the belief that we could deliver a programme. The most concerning thing … was in Darren's note where he refers to the fact that … actually we were looking at Q2 2017 and that was obviously now up against the cliff edge as we understood it.

Q. … you'd also been told, according to Mr Coomer, that Mr Moss had said they didn't have a package … armed with that information, you didn't consider terminating the MSA did you?

A.

They'd been building for 12 months now, so we ought, even if they didn't have a package, to have been able to get the software build in a place where we could get something they were going to use going forward for the market.”

Finally, as late as 2017, when most other milestones had been missed, CISGIL did not take the decision to terminate based on any delivery breach by IBM.

In summary, the Court finds that:

This claim is an alternative to the claim for unlawful termination losses and concerns pre-termination losses incurred as a result of IBM’s failure to meet contractual milestone dates.

CISGIL’s case is that IBM was responsible for delay to the project:

IBM’s case is:

The material obligation imposed on IBM in respect of the programme was set out in Clause 4.5(b) of the MSA:

“The Supplier shall perform the Services in accordance with all agreed timescales, including any Key Milestone Dates and in all other cases it will perform the Services promptly.”

Further provisions were contained in the Implementation SOW:

“3.3

The Supplier shall deliver the Deliverables and Services in line with the delivery dates as set out in Table A.1.

…

3.5

The Supplier shall ensure that each Service and Deliverable is Ready for Use by the applicable Milestone Date, Key Milestone Date or other date of delivery specified in Table A.1 in Appendix A or in accordance with the Implementation Plan as applicable.”

The Milestone Dates and Key Milestone Dates were set out in Table A.1 in Appendix A (the Roadmap).

Clause 5 contained further provisions for the timetable for delivery of the services, including:

“5.1

The Supplier will perform its obligations set out in this Agreement and each SOW in accordance with the timetable detailed in the Roadmap and each relevant SOW timetable (as applicable), and will complete each Key Milestone by the date set out in the Roadmap and relevant SOW (as applicable), subject always to the provisions of clause 9.

5.2

The Supplier shall perform each Service and deliver each Deliverable, (including where relevant such that it is capable of being duly tested for Acceptance) in accordance with the provisions of clause 6 (Acceptance) by the applicable date set out in the Roadmap and/or relevant SOW (as applicable).

5.3

Where the parties agree an SOW timetable (or changes to such timetable) which affects the Roadmap or any other timetable, the parties will agree that any consequential changes which are required to the Roadmap or any affected timetables will be implemented through the Change Control Procedure.

5.4

Subject to clauses 9 and 31, the Supplier shall ensure that each Deliverable required for each Release is Ready for Use by the applicable Go Live Date set out in the Roadmap.”

Clause 5.5 provided that a failure to meet any of the Key Milestones entitled CISGIL to liquidated damages, subject to a contractual cap of 10% of the Charges:

“Subject to clauses 9 and 31, in respect of the Implementation Services, if the Supplier fails to achieve a Key Milestone by the applicable date set out in the Roadmap:

(a)

then the Supplier shall pay to the Customer liquidated damages up to a maximum of £2,771,551 (two million, seven hundred and seventy one thousand five hundred and fifty one pounds) in total in respect of all Key Milestones allocated across the relevant Key Milestones as set out in the Implementation Services SOW;

(b)

the Customer and the Supplier agree that the liquidated damages set out in clause 5.5 (a) are fair and reasonable in all the circumstances and represent a genuine pre-estimate of the likely Losses that the Customer (and/or members of the Customer Group) are likely to suffer as a result of the failure to achieve the relevant Key Milestone by the applicable date set out in the Roadmap; and

(c)

if the relevant Key Milestone has not been achieved by the end of the period specified in table Al of Appendix A, to the Implementation Services SOW, this shall be deemed to be a breach of this Agreement which is not capable of remedy and the Customer shall (without prejudice to its other rights and remedies) be entitled (at its sole discretion) to claim general damages for loss or damage incurred in respect of any delay from the commencement of the delay (in substitution for claiming the amount specified in table Al of Appendix A, to the Implementation Services SOW) and/or to terminate this Agreement in whole or part in accordance with clause 26.2(a).”

Liquidated damages were payable only in respect of any failure to meet specified Key Milestone Dates, namely, IMP-022 (Release 1 Go Live), IMP-025 (Home Data Bulk Migration Complete), IMP-026 (Release 2 Go Live) and IMP-028 (Motor Data Bulk Migration Complete).

Clause 5.5(c) gave CISGIL an option to claim general damages for delay to the Key Milestone Dates, in substitution for the liquidated damages specified, and a further option to terminate for material breach pursuant to clause 26.2(a) of the MSA.

IBM was relieved from liability for delay in achieving the milestones to the extent set out in clause 9:

“9.4

The Supplier shall not be liable for any delay or failure to perform any of its obligations under this Agreement or any SOW if and to the extent that:

(a)

such delay or failure to perform is caused directly by a failure or delay by the Customer or any member of the Customer Group to perform the Customer Responsibilities in accordance with this Agreement that is material or has a material impact;

(b)

the Supplier has promptly notified the Customer when it reasonably believed that any failure by the Customer to perform the Customer Responsibilities in accordance with this Agreement has or is likely to have a detrimental effect on the Supplier's ability to perform its obligations; and

(c)

despite having done all that is reasonable to perform the Services and provide any Deliverables in such circumstances, the Supplier has been unable to do so.

…

9.5

The parties agree that in the circumstances set out in clause 9.4, the Supplier will be afforded a reasonable extension of time to perform its relevant obligations, including any obligations relating to subsequent dependent Milestones that are directly affected by the failure or delay, any such extension not to exceed the period of delay caused by the failure or delay and being agreed by the parties in accordance with the Change Control Procedure.”

IBM’s ability to rely on clauses 9.4 and 9.5 was dependent on IBM giving prompt notice to CISGIL of any failure by CISGIL directly causing delay to IBM. It appears to be common ground that no formal notices were issued by IBM, seeking relief under clauses 9.4 and 9.5 of the MSA. In particular, no extension of time was requested to the contractual milestone dates, save for the revisions to IMP-018 in the Amendment Agreement and the working agreement, extending the date for IMP-022 (Release 1 Go Live) to the end of May 2016.

IBM has pleaded an alternative case that pursuant to a term implied into the MSA, IBM would not be liable for late achievement or non-achievement of the milestones where such late or non-achievement was caused by CISGIL; alternatively, the prevention principle would prevent CISGIL from insisting on performance.

The general presumption is that no additional terms should be implied into a contract. As Lord Hoffmann observed in Attorney General of Belize v. Belize Telecom Ltd [2009] 1 WLR 1988 at [17]:

“The question of implication arises when the instrument does not expressly provide for what is to happen when some event occurs. The most usual inference in such a case is that nothing is to happen. If the parties had intended something to happen, the instrument would have said so. Otherwise, the express provisions of the instrument are to continue to operate undisturbed. If the event has caused loss to one or other of the parties, the loss lies where it falls.”

In Marks & Spencer plc v. BNP Paribas Securities Services Trust [2015] UKSC 72, the Supreme Court set out the requirements for implying a term into a commercial contract, approving the test set out in the Privy Council case BP Refinery (Westernport) Pty Ltd v. Shire of Hastings [1978] 52 ALJR 20 by Lord Simon of Glaisdale that:

“for a term to be implied, the following conditions (which may overlap) must be satisfied: (1) it must be reasonable and equitable; (2) it must be necessary to give business efficacy to the contract, so that no term will be implied if the contract is effective without it; (3) it must be so obvious that ‘it goes without saying’; (4) it must be capable of clear expression; (5) it must not contradict any express term of the contract.”

Having approved the above summary, Lord Neuberger added six comments at [21]:

“First, In Equitable Life Assurance Society v Hyman [2002] 1 AC 408, 459 Lord Steyn rightly observed that the implication of a term was ‘not critically dependent on proof of an actual intention of the parties’ when negotiating the contract. If one approaches the question by reference to what the parties would have agreed, one is not strictly concerned with the hypothetical answer of the actual parties, but with that of notional reasonable people in the position of the parties at the time at which they were contracting. Secondly, a term should not be implied into a detailed commercial contract merely because it appears fair or merely because one considers that the parties would have agreed it had it been suggested to them. Those are necessary but not sufficient grounds for including a term. However, and thirdly, it is questionable whether Lord Simon’s first requirement, reasonableness and equitableness, will usually, if ever, add anything: if a term satisfies the other requirements, it is hard to think that it would not be reasonable and equitable. Fourthly, … although Lord Simon’s requirements are otherwise cumulative, I would accept that business necessity and obviousness, his second and third requirements, can be alternatives in the sense that only one of them needs to be satisfied, although I suspect that in practice it would be a rare case where only one of those two requirements would be satisfied. Fifthly, if one approaches the issue by reference to the officious bystander, it is ‘vital to formulate the question to be posed by [him] with the utmost care… Sixthly, necessity for business efficacy involves a value judgment… the test is not one of ‘absolute necessity’, not least because the necessity is judged by reference to business efficacy. It may well be that a more helpful way of putting Lord Simon’s second requirement is … that a term can only be implied if, without the term, the contract would lack commercial or practical coherence.”

Applying that test to this case, IBM has not established an implied term exonerating it from liability for late achievement or non-achievement of the milestones where such late or non-achievement was caused by CISGIL. Although such an implied term might be reasonable and equitable, it is always open to the parties to allocate risk in a commercial contract. Such a term is not necessary to provide this contract with commercial or practical coherence and would contradict the express requirements for notice of delay to be given as a pre-condition to any relief. The above contractual provisions set out a complete code for the dates by which IBM was obliged to achieve the Milestone Dates, the circumstances in which, and the extent to which, it would be relieved from such obligations. There is simply no necessity to imply a term as alleged.

The prevention principle was considered by Jackson J in Multiplex Constructions (UK) Ltd v. Honeywell Control Systems Ltd [2007] EWHC 447 (TCC). Having considered the relevant authorities, he derived the following propositions at [56]:

“(i)

Actions by the employer which are perfectly legitimate under a construction contract may still be characterised as prevention, if those actions cause delay beyond the contractual completion date.

(ii)

Acts of prevention by an employer do not set time at large, if the contract provides for extension of time in respect of those events.

(iii)

In so far as the extension of time clause is ambiguous, it should be construed in favour of the contractor.”

One of the arguments posited by the sub-contractor in that case was that any failure on its part to comply with the notice provision, which operated as a condition precedent to an entitlement to extensions of time, would render time at large. Reliance was placed on the Australian decision in Gaymark Investments Pty Limited v Walter Construction Group Limited [1999] NTSC 143. That argument was rejected by the learned judge at [103]:

“I have considerable doubt that Gaymark represents the law of England. Contractual terms requiring a contractor to give prompt notice of delay serve a valuable purpose; such notice enables matters to be investigated while they are still current. Furthermore, such notice sometimes gives the employer the opportunity to withdraw instructions when the financial consequences become apparent. If Gaymark is good law, then a contractor could disregard with impunity any provision making proper notice a condition precedent. At his option the contractor could set time at large. ”

In any event, as submitted by CISGIL, if applicable, the prevention principle could only operate if IBM could establish that CISGIL’s conduct rendered it impossible or impracticable for IBM to meet the relevant milestones; the act relied on must cause some actual delay: Adyard Abu Dhabi v. SD Marine Services [2011] EWHC 848 (Comm) per Hamblen J (as he then was):

“[252] Even if Adyard is entitled to rely on the prevention principle this could only avail it, if its causation case is sound in law.

…

[263]

In my judgement Adyard’s approach is wrong as a matter of both principle and authority. It is also contrary to common sense …

[264]

It is wrong in principle because in essence Adyard’s case is that there is no need to prove causation in fact. On its case there is no need to prove the event or act causes any actual delay to the progress of the works. Notional or theoretical delay suffices. That would seem to involve turning the prevention principle on its head. The rationale of the principle is that it is unfair for a party to insist on performance of an obligation which he has prevented the other party from performing. That necessarily means prevention in fact; not prevention on some notional or hypothetical basis.

[281]

A … requirement of proof of delay to the actual progress of the works is apparent in the prevention principle cases, albeit that there the issue is viewed retrospectively.

[282]

The conduct therefore has to render it “impossible or impracticable for the other party to do the work within the stipulated time”. The act relied on must actually prevent the contractor from carrying out the works within the contract or, in other words, must cause some actual delay.

The expert issues regarding the delay and reporting claim are as follows:

Dr Hunt addressed these questions in her expert reports. Her careful and methodical approach to this exercise involved:

Dr McArdle was not instructed to provide an expert opinion on the delay issues; his review was limited to the use of user stories in the sprints and the conduct of Release 1 SIT and UAT.

Mr Morgan, IBM’s delay expert, was instructed to provide an expert opinion on the delay issues. He embarked on a simplified version of a ‘windows as planned vs as built’ delay analysis. He was hampered by the absence of project documents and programming tools, tracking planned and actual progress, that would usually be available for such exercise. He prepared a useful chronology of the delays that occurred against the contractual milestones and set out his views as to some of the causes of delay.

However, Mr Morgan then adopted an unconventional approach to his assessment. He apportioned the delay between CISGIL and IBM based on subjective attribution on a percentage basis allocation of responsibility for each delay factor that he considered to be critical and that he could quantify:

“The quantification of the assessment is the result of subjective opinion. It has been influenced by factors (which are quantified where possible) that are known and identified in this analysis. It also takes account of the unquantified ...”

Having assessed a percentage attribution for each delay factor within the window, Mr Morgan then averaged those percentage attributions to arrive at an average percentage attribution for the whole window.

As Dr Hunt stated in her reply report:

“The consequence of this process is that the only delay factors that contribute to Mr Morgan's conclusions are those that he has chosen to select from among the quantifiable delays. Conversely any delay factors that Mr Morgan believes caused delay but which he cannot quantify, or that he has chosen not to select, do not contribute in any way to the conclusions.”

Unfortunately, Mr Morgan’s subjective assessment of responsibility on a percentage basis is of limited assistance in this case and I prefer the evidence-based analysis of Dr Hunt.

Milestone IMP-018 was defined in the Roadmap as: “Release 1 Build Complete – the Release technology successfully built by Supplier and ready for testing”.

The IT experts agreed in their joint statement that ready for testing means that the software had completed system integration testing (“SIT”) and was ready for user acceptance testing (“UAT”). Therefore, this milestone required IBM to complete SIT, so that it was ready for UAT by CISGIL.

The original contractual date for completion of the milestone was the end of December 2015 but it was amended by the parties and the contractual date for delivery of milestone IMP-018c was 31 January 2016.

Although some functionality was delivered by that date, it was incomplete and further drops of functionality continued to be delivered into SIT well into 2016.

Dr McArdle’s view is that IMP-018c was achieved when Drop 24 was delivered on 24 June 2016. Dr Hunt’s view is that IMP-018c was not achieved until Drop 33 was delivered on 26 August 2016.

Details of the business and technical functionality provided by each of the drops delivered, following successive sprints, were set out in the drop release notes and portal release notes issued by IG. The release notes contained IG’s description of the drops by way of functional items, defect fixes and change requests. Dr Hunt carried

The delivery dates of functionality identified from the release notes can be summarised as follows:

That analysis supports Dr Hunt’s conclusion that functionality for Release 1 continued to be dropped into SIT until Drop 33 on 26 August 2016. Thereafter, the delivery drops continued but were mainly defect fixes and some change requests.

Dr Hunt concluded that the critical delay factors that prevented IBM from achieving IMP-18c as planned were as follows:

I have considered and rejected the argument that the amount of development work required to the base functionality in the period after the MSA was substantially more than anticipated. Therefore, I discount that as a cause of delay to Release 1.

However, there is ample evidence to support Dr Hunt’s opinion that IG did not have sufficient resources to carry out the work required to deliver the Release 1 functionality by the dates set out in the MSA and Implementation SOW, as amended.

On 27 August 2015 Ms Barnes expressed her concerns to Ms Boast concerning IG resources:

“…we really need more resource/depth on the ground for at least a couple months else I believe we will miss the key milestones …

Release 1 Insurer Status - I have turned this Red between us and am probably 2 weeks away from having to share this status with GI, and that will not be pleasant – at the moment pull back on track is looking slow and I am very concerned that unblocking a GI process block just leaves us exposed to having to show one of our own …

Base config fit gaps – we have about 60 fit gaps in here but as of last night we are all unclear on when this will arrive – we really need them completed …

… don’t forget release 2 is due to start next week which puts even more strain on a team which is already stretched ...”

On 17 September 2015 Ms Barnes was so concerned that she sent an email to Mr Jackson stating that she wanted to invoke the step in clause in the contract with IG.

On 19 November 2015 Ms Barnes sent an email to Mr Jackson stating:

“I and the team are totally fed up that we are still having issues with IG and if they really want to be a strategic partner they need to step up and act like one. Milestones are being missed and yet we are not being given warning and there is no urgency to get back in line or regret of missing them. I have been escalating the same issues for months, unfortunately many of the impacts have materialised and these could have been avoided…

The IG team has increased from about 16 to 92 as at today, and they still need more, whilst happy we have resources it's too much [sic] too late and a fair few are management - seems they are finally doing something but it asks the question what were they doing before and the MI and reporting was, as suspected, wholly inaccurate leading to a move in milestone dates …”

It is clear that the Release 1 sprints were not successful; they were slow and chaotic, rather than agile. Not all of the difficulties could be blamed on IG’s inadequate resourcing. Ms Barnes considered that some fault lay with CISGIL as well as IG. IBM relies on a number of notifications of delays during 2015 for which CISGIL was responsible, particularly in its progress reports. The contents of such notifications were taken into account by Dr Hunt in her assessment of critical delay.

Contemporaneous documents show that the parties identified failings on the part of

By September/October 2015, the parties recognised that revisions were required to the programme. Ms Barnes explained the genesis of the three drop approach in her witness statement:

“IBM and IG started discussing options to create more time for CISGIL and enable the completion of the sprints. We realised that milestone IMP-018 would be affected but all parties wanted to keep the Go-Live date the same. Over the next few days we came up with the 3 drop approach which gave CISGIL more time to provide the business information whilst ensuring IG had sufficient time to complete the configuration. Also, by delivering Release 1 in drops, it allowed some of the System Integration Testing (“SIT”) to start. In order to maintain the original Go-Live date, SIT had to start on time but would run for longer to accommodate the 3 drops. This was not normal but an attempt to keep to the schedule. It very much depended on getting the business information from CISGIL on time and IG configuring on time.”

The parties agreed to extend the time for milestone IMP-018 and split it into three drops. Each drop had a business drop which required CISGIL to provide business information and a technical drop which then required IBM and IG to configure based on that information. Ms Barnes explained in her witness statement that the business and technical drop dates would still enable the parties to meet the April 2016 Release 1 Go-Live date.

That agreement was the subject of the Amendment Agreement dated 2 December 2015, the terms of which included the following:

“2.1

With effect from [22 November 2015], [the MSA and Implementation SOW] shall be amended in accordance with the Amendments in consideration for which the parties shall pay to each other, if demanded, 1 pound Sterling.

2.2

Subject to clause 2.1 above, all clauses of [the MSA and Implementation SOW] shall remain in full force and effect.”

The Amendments were set out in Schedule 1 to the Amendment Agreement. They showed the deletion of the original delivery date for IMP-018 and revised delivery

There was no explanation for the revised dates in the preamble or other terms of the Amendment Agreement. However, it is clear from the exchanges between the parties at the time, and the evidence of Ms Barnes, that the agreed revised dates accounted for the delays to the project on both sides and maintained the contractual completion date for Release 1. Therefore, the Amendment Agreement had the effect of compromising any claims the parties might have had against each other for those early delays.

IBM achieved IMP-018a by 23 November 2015 and IMP-018b by 18 December 2015. However, IMP-018c was not delivered by 31 January 2016.

The evidence indicates that the main factors causing delay to IMP-018c were inadequate resourcing of the project by IG and defective configuration and customisation by IG, resulting in numerous defects in SIT.

On 30 November 2015 Ms Barnes raised the issue of inadequate IG resources with Mike Freeman of IG:

“Release 1 – there is a significant risk to drop 2 due to resource issues, and we need this for a meaningful model office drop for Release 0.

There is even more risk to drop 3 due to resource issues, and based on the latest MI this is now the biggest drop and was supposed to the be smallest …

We seem to also be getting a fait accompli drop 4! On the 25^th January and not just aggregator interfaces …

The overall situation seems to be we will miss the April date for Release 1 due to base delivery and lack of resources for the other drops, and Release 2 will be missed also due to lack of resources, base delivery timescales and not time now to do a plan …”

The exit criteria for SIT required a SIT test execution report to be completed and the resolution of all Severity 1 and 2 defects. SIT took longer than planned as a result of missing functionality and high numbers of defects.

At the TES meeting on 17 December 2015 IBM reported that 94 of the 218 insurer requirements for drop 1 had to be deferred to drops 2 and 3.

By the end of December 2015, 100 out of 159 tests were blocked as a result of nondelivery of interfaces or defects (although only a small number were identified as critical defects).

On 6 January 2016 Ms Barnes reported that late functionality drops into SIT by IG had resulted in cessation of Release 1 SIT and the release notes provided with drops 1 to 3 were not sufficiently detailed.

On 26 January 2016 Mr Dobey of IBM complained to IG that integration testing remained blocked by the number of defects and slow progress of defect fixes. On 12 February 2016 he complained again that the release into SIT would not produce any SIT scope for the team to execute the following week.

By 19 February 2016, a few days after UAT had been due to start, the daily defect report recorded a total of 101 open defects, of which 1 was critical, 12 were high severity and many had been open for 30 days or more. The SIT execution report for 18 February 2016 stated that of the total of 1095 tests IBM planned to run, 441 had passed, 81 had been run and failed and the remaining 573 had not been run, primarily because the relevant functionality was not available.

On 6 March 2016 Ms Barnes raised concerns about SIT progress with Ms Boast:

“We started this with all configuration complete by 3^rd November, having recognised the initial sprint approach was not working we changed to three drops, which 1i committed to with the final drop on Jan 12^th 2016. I accept there are some areas e.g. docs which did not conform to this. However, following a series of missed date promises since December (with the continual reason being no resources) we find ourselves facing a very unpalatable date for completion, which in turn pushes the go-live date out past May. The client is aware of the situation and has already mentioned the dreaded LDs.

Unfortunately, even if the new build dates are met I have no confidence that there will not be a plethora of defects to contend with. We spoke 6 weeks ago about defects and a dedicated defect team. I understand we now have 2 guys in Australia supporting which is good, but the resolution time is too long, we have over half of the defects at over 20 days old and half of these are over 60 days old with the oldest being 97 days and a critical one at 87 days. This is holding up SIT and will now affect UAT and as we enter UAT I am going to have to share the resolution statistics.”

By 26 April 2016 IBM recorded that 108 defects were outstanding in SIT, of which 2 were critical, 38 were high severity, 40 were medium severity and 28 were low severity. Of the total, 60 defects related to the Quote & Buy Portal, Customer Portal and Home Supplier Portal and were unresolved.

Delivery of Release 1 functionality continued until drop 33 on 26 August 2016. Thereafter, further releases were issued but primarily by way of defect fixes.

IBM’s case is that Release 1 was delayed by CISGIL’s late delivery of its requirements and numerous Change Requests.

Dr Hunt analysed the change control log and identified a total of 100 Change Requests that related to IBM's delivery, categorised and set out in Appendix I to her first report. Based on that analysis, her view was as follows:

“In my view the 100 changes raised against IBM’s total delivery is not a particularly large number of CRs for the scale of the project and I would expect any competent systems integrator to budget for providing impact assessments on this sort of scale. I would therefore not expect work done on discussing and assessing CRs on this scale to have had a significant impact on IBM's and IG’s ability to deliver the Solution.”

IBM was responsible for interfaces functionality and CISGIL was responsible for the wider telephony infrastructure. There were delays on both sides but telephony went live at the end of May 2016 and the majority of telephony functionality was deferred to Release 2, thereby having little effect on IMP-018c. Aggregator interfaces should have been delivered as part of Release 1 but were deferred to Release 1.1. At the time of termination, further development and testing was subject to the aggregators’ ability and willingness to make available resources but their reluctance to co-operate has to be assessed against the background of the earlier delays up to that point, which were caused by IBM’s failures.

The IT solution included the ability to generate documents automatically as part of CISGIL’s operational requirements. Delivery of documents into SIT was delayed by five and a half months until July 2016. Dr Hunt’s view was that IBM was responsible for three months of this delay for two reasons. Firstly, IG had sufficient information to deliver at least some documents for Drop 2, which would have allowed the Kofax interface to be tested in SIT and would have made the development of the remaining documents more efficient. Secondly, by March 2016 IG had been given all the specifications and IBM predicted delivery by the end of April, but in fact did not deliver all documents into SIT until late June 2016. Dr Hunt considered that CISGIL was responsible for the remaining two and a half months’ delay for document delivery into SIT but this had no impact on IBM’s ability to achieve IMP-18c because delay in providing the Kofax interface meant that neither IBM nor CISGIL were able to test the documents until after the suspension of UAT 1.

Dr Hunt agreed that if IBM had not caused delays to IMP-18c, CISGIL would have caused delay of 5.95 weeks for Change Requests and delay of 2.5 months by reason of late delivery of documents into SIT.

However, Dr Hunt’s concluded view was that SIT continued for an extended period from November 2015 through to October 2016 because IG continued to deliver Release 1 functionality on a piecemeal basis, its poor quality configuration and customisation work resulted in a large number of defects, and it did not provide sufficient resources for swift resolution of the defects.

Those views were shared by IBM during the project. In its audit report of IG’s performance in November 2016, the following difficulties were identified:

“Release 1 suffered from plans being based on unreliable estimates and a lack of planning and management by IG.

Interface testing was first undertaken during SIT which led to a high number of interface related defects being found that related to interfaces and functionality that should have been tested more thoroughly in system test. During SIT there were a large number of failures around interfaces and customer facing documents. Additionally there was a larger than expected level of functional failures and a high fix fail rate. This implies inadequate testing at ST level.”

On the basis of the factual and expert evidence, in my judgment, IBM was responsible for the critical delays that prevented milestone IMP-018c from being achieved prior to 26 August 2016.

Milestone IMP-021 was defined in the Roadmap as: “Release 1 Accepted – the

User acceptance testing (“UAT”) was carried out by CISGIL to test and validate that the solution for each Release met the business requirements, interfaces and business processes. UAT was planned to start on 15 February 2016 but IBM’s late delivery of the functionality drops for Release 1 into SIT pushed SIT into the UAT phase.

The entry criteria for UAT included no unresolved severity 1 or 2 defects from SIT. On 29 March 2016, although the numbers of outstanding severity 1 and 2 defects indicated that Release 1 was not ready for UAT, CISGIL agreed to start UAT and progress it in parallel with the ongoing SIT. Dr McArdle considered that this decision was premature. Such observation must be correct, given the status of SIT, but neither party at the time suggested that UAT should be postponed beyond this date, no doubt because they were optimistic that further delay could be minimised.

The scope of UAT was reduced by deferring testing for delayed elements, namely, SAS reporting, TDS, Supplier Portal, Aggregators, NOM renewal and COM functionality.

CISGIL was responsible for preparing test scenarios and scripts to simulate operation of the business processes. The test strategy provided that there should be full traceability of the business requirements to the test scenarios and test cases. Test cases, test scripts, test execution and defects were recorded in the online Quality Management tool, Rational, which was hosted by IBM.

The defects criteria were set out in the contractual test strategy document at DLV-013. Defects were allocated a severity level as follows:

The test strategy also contained a priority list for defects:

The Defects Management Process document (V1.0) dated 4 February 2016 contained a slightly different description of the severity levels, placing emphasis on the immediate impact of the defect on the testing process:

The UAT exit criteria included no unresolved severity 1 or 2 defects and a manageable number of severity 3 or 4 defects with an agreed work around in place.

Section 8.4 of DLV-013 set out the circumstances in which UAT could be suspended (the Test Suspension Criteria), including:

There was delay by CISGIL in preparing the test scenarios and scripts to simulate operation of the business processes. In March 2016, SQS was brought in to assist with script production and IBM provided additional assistance to CISGIL.

Instead of creating the scripts in Rational, CISGIL prepared the test scripts offline and uploaded them retrospectively. Rational was used for defects reporting. As a result, CISGIL did not record defects against the test scripts, which obstructed full traceability of the defects back to the 551 Requirements in the MSA. The IT experts agreed that this was unsatisfactory but this did not prevent IG/IBM from correcting the defects and did not prevent the experts from carrying out their own reviews to assess the significance of the defects that arose during UAT.

Delays to testing were caused by UAT environment configuration issues, requiring IG to update or change the UAT environment. Gary Craven was brought in by CISGIL at the beginning of April 2016 to troubleshoot the testing phase. He noted that there was a consistently high volume of defects, and difficulties were caused by missing functionality and instability of the UAT environment, as recorded in his progress report sent to Ms Neate on 8 April 2016. By email dated 7 April 2016 Ms Barnes notified Ms Boast that IG’s failure to provide the IT infrastructure was affecting UAT; the Kofax and Insurer Analytics components were not working and there were more than 100 defects across all test phases.

By May 2016, there were 258 outstanding defects recorded in the UAT report in Rational, of which 25 were severity 1, 60 were severity 2, 111 were severity 3 and 62 were severity 4.

On 6 May 2016 CISGIL formally suspended UAT, although some further testing continued until 16 May 2016.

Mr Craven identified a number of key issues that had arisen when UAT was suspended. Kofax (the documents generation system) was not available, preventing CISGIL from performing any tests on functions such as new policy documentation, blocking 255 tests. This was resolved by 11 May 2016 but that was after UAT had been suspended. The SIRA interface integration (including the fraud blocklist) was not available, although Mr Craven accepted in cross-examination that this issue was resolved by 27 April 2016. There were ongoing issues with the pricing component and the customer portal. Although that issue was resolved by 17 May 2016, that was after UAT had been suspended.

By mid-May 2016, CISGIL had planned to complete 3079 test scripts but had only executed 1447, of which 881 had been completed, 282 failed and 1,739 were blocked. Dr McArdle calculated that only 30.08% scripts had passed. His analysis of the defects recorded in Rational indicated that 73.53% of the fixed defects were caused by coding or configuration errors.

Dr Hunt carried out an analysis of the Severity 1 and Severity 2 defects recorded at this time, together with lower severity issues that CISGIL reported as blocking significant numbers of test scripts, a total of 87 defects. She carried out an independent assessment to identify the root cause of each defect, such as a defect in the base code, a configuration error or a testing error. She then assessed the severity of each defect, using the criteria set out in the Defect Management document (rather than the DLV-013 document). Dr Hunt found that approximately 23% of these defects in UAT were duplicates (incorrectly identified as defects) but she considered that this was well within the normal range of error. Of the correctly identified 67 defects, IG/IBM were responsible for 64 defects, which Dr Hunt classified as 12 critical, 19 high and 33 medium severity.

Dr Hunt’s view was that:

“Many of these issues remained unresolved by the time UAT 1 was suspended. In my view, the number and severity of environment configuration issues experienced would have severely impacted CISGIL’s testing effort. The prevalence of this type of issue strongly suggests a disorganised and unsystematic approach to the configuration and management of environments by IG.

…

In addition to environment configuration issues, the number and severity of Insurer Suite configuration errors that CISGIL encountered also suggest that the work required had not been completed or properly tested by IG prior to UAT.”

It is of significance that IBM did not protest against CISGIL’s decision to suspend UAT. The above evidence establishes that there were significant outstanding difficulties with UAT for which IBM was responsible and which justified suspension in May 2016.

In May 2016, IBM proposed a revised plan, under which SIT and UAT were divided into two phases, Release 1 and Release 1.1. Release 1 comprised NOM functionality and Release 1.1 comprised COM and Aggregators. The UAT period had a planned duration of 12 weeks.

There were Change Requests agreed by the parties during this period, which Dr Hunt assessed caused delay of 5.95 weeks.

IBM delivered drop 33 functionality into SIT by August 2016. However, in a Release 1 UAT review dated 25 August 2016, Rob Bown, IBM’s testing manager, reported:

“Evidence suggests SIT execution will not complete until w/e 18^th Sept 2016 and at a minimum further 3 fix drops are required to close out remaining open severity 1 / 2 defects. All open SIT defects must now be subject to technical and business reviews to assess whether they are blockers for starting UAT.

200 UAT observations have been raised of which 73 which may block UAT commencing on 19^th September. It is imperative that these observations are analysed and the fix strategy agreed between technical and business teams.

Confidence is low from UAT on ST and SIT test coverage and test result evidence. There is an urgent need for ST / SIT teams to perform further review test coverage with UAT teams to provide increased confidence in UAT execution and remove possible duplication giving possibilities to reduce UAT test scenario numbers.

The UAT Run Schedule does not consider all the required test planning variables. Until the UAT Run Schedule incorporates these planning variables the reviewer believes the current planned 6 weeks UAT execution duration cannot be achieved. A bottom up plan must be developed with all planning variables considered …

There are significant challenges in the UAT plan which must be undertaken; without doing so the 6 week UAT execution duration is unrealistic …

Improvements must be made in defect fixed turnaround time and defect fix quality (reducing the high % of bad fixes)…

The reviewer believes at minimum a 10 week UAT execution duration is required …”

On 30 August 2016 Mr Osborne of IBM informed Ms Magee that he estimated that a further three weeks was required to complete SIT and meet the UAT entry criteria.

On 17 October 2016 the second phase of UAT commenced, with an extended programme of 14 weeks (plus a 4 week contingency period). Although this programme was not formally approved by CISGIL, the parties used it as a working tool.

The extended UAT plan anticipated completion of Release 1 UAT by 24 January 2017. However, by 8 February 2017 there were still 325 open defects, with a total of 1074 defects having been raised during UAT to that date, and IBM reported that new defects were still being opened.

UAT for Release 1.1, which comprised functionality for the aggregators, started on 3 March 2017.

By April 2017 the parties were working to a UAT closure date of 26 June 2017 and IBM presented the ‘glide path’ diagram which showed the anticipated reduction in defect numbers. However, rather than the closure of defects accelerating as predicted, the rate of defect closure essentially maintained a straight line, as shown in the graph presented by IBM on 10 May 2017.

On 19 May 2017 Mr Broughton set out IBM’s position in an internal email to Mr Osborne:

“Defects

•

Over the course of SIT and UAT we have seen unusually high levels of defects being raised. The number and nature of the defects is not consistent with the configuration of a mature product, it is more akin to a bespoke development. However, even for a bespoke development the number of defects that are leaking into UAT is again unusually high and would indicate that the level of System Testing performed was wholly inadequate and lacked quality.

•

The rate of defect closure and the defect close time are also very poor and declining. The number of defects closed per week has shown a steady decline from a mean high of 55 defects per week to a current mean

high of 25 defects per week. No explanation has been given for this decline and yet 1i are insisting that no resources have been lost from the programme.

•

43% of all defects raised have taken over 30 days to resolve, with 10% taking over 90 days to resolve.”

IBM’s case is that CISGIL unreasonably increased the number of tests during the second phase of UAT. This was disputed by Mr White, who replaced Ms Neate as programme director at CISGIL. He stated that the increase in testing was caused by the errors in the code. His evidence was that the rate of progress of CISGIL's UAT team in running test scripts was consistent with his previous experience, namely approximately 400 UAT scripts a week or, perhaps 100 a day at a stretch for a team of seven to ten testers. He stated that:

“In my experience testers normally find the vast majority of defects in the early stages of testing, following which the rate at which defects are found decreases over time as fixes are applied (referred to as an "S curve"). In contrast, for UAT2 the high defect rate remained pretty constant throughout testing as we continued to test and re-test functionality

It was the continuing high volume of defects due to errors in the code that caused UAT to take much longer than planned. This also seemed to be a surprise to IBM who were expecting an "S curve" too. Significant numbers of defects were still being found when the Programme was terminated and UAT was not completed.”

Mr White’s explanation for the difficulties experienced in UAT is supported by the defect records. From the start of the second phase of UAT in October 2016 until termination, 1,784 defects were recorded by CISGIL, of which 116 were severity 1, 432 severity 2, 1,052 were severity 3 and 184 were severity 4. A higher percentage of the phase 2 UAT test cases were linked to the contractual 551 requirements: 53.5% rather than 12% for the first phase. Dr McArdle’s analysis of the defects recorded in Rational indicated that 76.36% of the fixed defects were caused by coding or configuration errors.

Dr Hunt carried out a defect assessment for the severity 1 and 2 defects (and one severity 3 issue) for the second phase of UAT, using the same criteria as for her defect assessment for the earlier phase of UAT. Of the 549 defects identified, Dr Hunt’s view was that 40 were severity 1 and 81 were severity 2. She categorised 200 of the items as invalid defects, 36.4% of the total, which was higher than she would have expected, but that left 349 valid defects.

Mr White conceded that there were differences between the contractual defect criteria applied at the time and Dr Hunt’s review. However, his evidence was that the characterisation of defects was open to discussion and challenge in the defect triage meetings. Even if the severity changed following review, although it affected the priority assigned to it, it did not detract from the fact that there was a defect. Mr White’s main concern was the overall number of defects in the system, demonstrated by Dr Hunt’s analysis.

IBM submits that defects wrongly attributed to IG/IBM and CISGIL’s zero tolerance to severity 3 and 4 defects extended the UAT timescales. However, those issues do not begin to explain the numerous, valid defects identified during UAT that continued throughout 2016 and into 2017. The glide path diagram produced by IBM on 12 July 2017 showed that it anticipated defect resolution continuing until September/October 2017.

Dr Hunt concluded that the critical delay factors that prevented IBM from achieving IMP-021 as planned, over and above the factors that caused delay to IMP-18c, were:

Dr Hunt’s conclusion, based on her careful and detailed analysis of the records of defects identified and resolved during both phases of UAT, is accepted as correct.

The relevant Release 2 milestones were:

The sprints for Release 2 were intended to take place between September 2015 and March 2016. Progress was disrupted by the delays to Release 1 and IG did not have sufficient resources to manage or perform Release 1 and Release 2 in parallel. In a frank email dated 22 April 2016 from Ms Barnes to Mr Jackson, she stated:

“Due to the non-delivery by 1i we are 6 months late on base delivery which has had a knock-on effect to all the testing and R2. The IBM SIT has been severely affected having to be extended several times and suffering from lack of significant defect resolution for several months.”

Following the suspension of UAT for Release 1 in May 2016, IG prepared revised plans for the project but they were criticised by IBM and rejected by CISGIL. In August 2016 IG produced a further revised plan, projecting that Release 2.0 would ‘go live’ by June 2017 and Release 2.1 would ‘go-live’ by November 2017.

By letter dated 6 September 2016 IBM sent a written notification of breach to IG, stating:

“After IBM initially highlighted 1insurer’s delivery issues in August 2015, this resulted in a new approach and plan being provided by 1insurer to IBM in September 2015. This included a change to the build milestone from December 2015 to January 2016, which still enabled Release 1 to be delivered to the agreed schedule. Notwithstanding this, there continues to be significant delays and unexpected events caused by 1insurer together with further changes to the proposed approach and milestone dates, all of which result from 1insurer’s continued non-performance of its obligations.

The original scheduled, and indeed re-scheduled, go-live dates for Release 1 have been missed and currently 1insurer’s inadequate defect resolution time has caused the SIT exit milestone to be missed, which will again affect the Release 1 plan.

Release 2 was due to go-live in August 2016 but as at the date of writing 1insurer has advised that the preparation has only just started.

1insurer has been actively involved in the re-planning of Release 2 over the last 9 weeks supplying three plans 4 June, 27 July and 23 August 2016 and yet no 1insurer plan has been provided which addresses in sufficient detail all of the scope items to provide certainty that the plans for Releases 1 and 2 in totality can be achieved.”

The IG release notes indicate that significant Release 2 functionality was not delivered until October 2016.

On 13 October 2016 IG issued a new version of Insurer Suite, Release 7.6.

IBM’s allegations against IG, in particular, those set out in its letter dated 21 February 2017, articulated the material breaches that are relied on in these proceedings by CISGIL against IBM:

“During system integration testing (SIT) and user acceptance testing (UAT) there have been a large number of failures around interfaces and customer facing documents. Additionally, there were a larger than expected level of

functional failures and a high fix fail rate…

The system testing undertaken by 1i has been very poor, significantly below industry standard and in breach of 1i’s obligations under the Agreements. This was demonstrated by the high number of defects that are arising during UAT. These defects ought to have been identified during system testing and resolved prior to commencement of UAT…

As stated in the September 2016 Breach Notice, 1i has, in breach of its obligations set out in section 2 above, missed all eleven milestones from IG-004 (save for the IMP-019 milestone which related to Release 0 Go Live) onwards…

In the September 2016 Breach Notice, IBM identified that 1i had failed to provide accurate and timely management information. IBM also identified that the timing, quality and level of documentation provided by 1i has been poor and inconsistent. This has continued since the September 2016 Breach Notice.

As stated in the September 2016 Breach Notice, 1i has been unable to resolve the defects arising during system testing in a timely manner and with a ‘right first time’ principle. This has continued since the September 2016 Breach Notice…

To date the number of defects that relate to 1i that have arisen during UAT is nearly 1,000. That is significantly higher than is to expected in a build of this nature during UAT. It is reflective of the poor quality of Services provided by 1i … In addition, the rate at which 1i has been resolving the defects has also been poor …

As stated in the September 2016 Breach Notice, li’s resources are constantly changing with little and/or late notification of such changes … This has continued since the September 2016 Breach Notice.”

IBM’s letter to CISGIL dated 7 April 2017, shortly before termination, stated that the projected Release 1 go live date was 26 June 2017; the estimated long stop date for Release 2.0 was 10 September 2018 and for Release 2.1 was 11 March 2019.

IBM’s factual and expert evidence offers no adequate explanation for such delay and does not exonerate IBM from its failure to meet the agreed milestone dates.

I have rejected Dr Hunt’s opinion that Release 2 required substantially more development than expected at the date of the MSA. Further, it is common ground that at termination the parties were in dispute as to the scope of Release 2.

However, I accept Dr Hunt’s conclusions that the following critical delay factors prevented IBM from achieving the relevant Release 2 milestones:

CISGIL’s case is that IBM failed to manage the programme and to report actual and probable future progress of the implementation of the solution with reasonable accuracy so as to enable CISGIL to plan its expenditure on its own resource’s and third party contractors with reasonable efficiency.

Ms Barnes explained in her witness statement that she held weekly workstream meetings within IBM at which each workstream lead would provide a report and highlight any issues impacting their workstream. Milestones were tracked by the workstream leads by monitoring them against a plan that was updated, recording the risks and issues arising, in the Rational tool to which IBM, CISGIL and IG had access. CISGIL also had access to VersionOne, which provided transparency in respect of the backlog and sprints. IBM provided written progress reports in advance of, and attended, the weekly programme management group (“PMG”) meetings. IBM also attended parts of the fortnightly transformation executive steering committee (“TES”) meetings and parts of the board transformation committee (“BTC”) meetings.

Ms Barnes of IBM and Ms Neate of CISGIL had regular exchanges concerning progress of the project and the contemporaneous documents do not indicate that IBM concealed difficulties that arose. Reliance has been placed on emails where Ms Barnes expressed her frustration at the lack of progress by IG, slippage of delivery dates promised and late or inadequate management information. But this is not sufficient to establish a breach of IBM’s reporting obligations; on the contrary, it shows IBM attempting to cajole IG into improving its performance.

Mr Summerfield accepted in cross-examination that by January 2016, he knew that IBM would not achieve the April 2016 milestone for Release 1. He discussed with Ms Neate the likelihood that Release 1 would be extended to the end of May 2016, although no formal amendment was made to the milestone.

It is clear that there were constant slippages in the programme, as evidenced by the correspondence, progress reports and IBM’s revised plans:

The picture that emerges is of a troubled project, that slipped further and further behind programme. IBM simply was unable to deliver the milestones in accordance with the MSA and Implementation SOW.

I have rejected CISGIL’s case that it would have terminated the project earlier, if it had known the full extent of the delays. However, it is clear that in breach of the MSA and the Implementation SOW, IBM failed to meet the key milestones for Release 1 and Release 2 and failed to provide accurate reports as to such delays during the project.

In summary, for the reasons set out above, in my judgment IBM was responsible for the critical delays to the project.

The cause of critical delay to milestone IMP-018c was IG’s inadequate resources to perform the Release 1 customisation and configuration work identified in the fit-gaps. Further, the configuration and customisation work done by IG was of poor quality, resulting in many defects that IG was slow to resolve, extending SIT until October 2016.

The cause of critical delay to milestone IMP-021 was IG’s failure to deliver adequate functionality to complete SIT and allow UAT to be carried out successfully. The number of defects found in UAT was substantially more than expected and predicted by IBM, and IG was slow in fixing them.

Initial delay to Release 2 was caused by the delays to Release 1. IG had insufficient resource to manage and perform Release 2 in parallel with Release 1. This meant no substantive work was done by IG on Release 2 until August 2016, when development of Release 1 had ceased. Further, IG implemented Release 2 on a different version of

For the reasons set out in relation to Issue 3 above, CISGIL has not established its case that, had IBM provided more accurate reporting of the delay, CISGIL would have terminated the contract early.

CISGIL’s primary claim is for wasted expenditure, namely, the costs incurred in respect of Project Cobalt in the sum of £128 million, resulting from wrongful termination.

CISGIL has an alternative claim for £27.2 million in respect of additional resource and third party costs which it would not have incurred if IBM had achieved the contractual milestones and/or informed CISGIL as to the true state of the project.

IBM has a set-off and counterclaim for £2,889,600 in respect of the AG 5 invoice.

The contractual issues on quantum are as follows:

Clause 23.3 of the MSA provides:

“Subject to clause 23.2 and 23.4, neither party shall be liable to the other or any third party for any Losses arising under and/or in connection with this Agreement (whether in contract, tort (including negligence), breach of statutory duty or otherwise) which are indirect or consequential Losses, or for loss of profit, revenue, savings (including anticipated savings), data (save as set out in clause 24.4(d)), goodwill, reputation (in all cases whether direct or indirect) even if such Losses were foreseeable and notwithstanding that a party had been advised of the possibility that such Losses were in the contemplation of the other party or any third party.”

‘Losses’ are defined in Schedule 1 to the MSA as:

“All losses, liabilities, damages, costs and expenses including reasonable legal fees on a solicitor/client basis and disbursements and reasonable costs of investigation, litigation, settlement, judgment, interest.”

IBM submits that CISGIL’s claim for wasted expenditure is excluded by clause 23.3. On analysis, it is a claim for loss of profit, revenue or savings; although the quantum of the loss is assessed by reference to the expenditure that has been incurred, the actual loss is the profit, revenue or savings through which that expenditure would have later been recouped but for the breach.

CISGIL submits that its claim for wasted expenditure is not a claim for loss of profit. Compensation for wasted expenditure puts it into a break-even position on the assumption that its financial and non-financial benefits from IBM's performance would have been worth at least as much to CISGIL as the amounts expended in reliance on the contract.

A fundamental principle of the common law relating to damages for breach of contract is that they are compensatory, intended to give effect to the contractual bargain. The established rule was set out in Robinson v Harman (1848) 1 Exch. 850 per Parke B p.855:

“The rule of the common law is, that where a party sustains a loss by reason of a breach of contract, he is, so far as money can do it, to be placed in the same situation, with respect of damages, as if the contract had been performed.”

The quantum of damages for breach of contract should reflect the value of the contractual bargain of which the claimant has been deprived as a result of the defendant’s breach: The Golden Strait Corporation v Nippon Yusen Kubishika Kaisha [2007] UKHL 12 (HL) per Lord Scott:

“[32] … The underlying principle is that the victim of a breach of contract is entitled to damages representing the value of the contractual benefit to which he was entitled but of which he has been deprived. He is entitled to be put in the same position, so far as money can do it, as if the contract had been performed.

[36] … The lodestar is that the damages should represent the value of the contractual benefits of which the claimant had been deprived by the breach of contract, no less but also no more. ”

The above rules were re-affirmed in Morris-Garner v One Step (Support) Ltd [2018] UKSC 20 per Lord Reed, who stated at [36]:

“The objective of compensating the claimant for the loss sustained as a result of non-performance (an expression used here in a broad sense, so as to encompass delayed performance and defective performance) makes it necessary to quantify the loss which he sustained as accurately as the circumstances permit. What is crucial is first to identify the loss: the difference between the claimant’s actual situation and the situation in which he would have been if the primary contractual obligation had been performed. Once the loss has been identified, the court then has to quantify it in monetary terms.”

In a commercial contract, the value of such damages is usually measured by reference to the additional amount of money that the claimant would require to achieve the financial value of the expected contractual benefit, such as lost profits, the cost of reinstatement or diminution in value (“the expectation basis”), as explained by Teare J in: Omak Maritime Ltd v Mamola Challenger Shipping Co [2010] EWHC 2026:

“[15] In a typical claim for damages for breach of contract on the expectancy basis both expected profits and necessary expenses will be taken into account. The claimant will claim a sum equal to the benefit he expected to earn from performance of the contract less the costs he would have had to have incurred in order to earn that benefit, which costs would include not only any sum he would have had to pay to the party in breach but also any expenses he would have had to incur in preparation for performance of the contract. Damages calculated in that way would put the claimant in the position he would have been in had the contract being performed.”

A claimant may elect to claim damages on an alternative basis by reference to expenditure incurred in reliance on the defendant’s promise, such as sums paid to the defendant or other wasted costs (“the reliance basis”): Cullinane v British Rema [1954] 1 QB 292; Anglia Television v Reed [1972] 1 QB 60 per Lord Denning at p.64:

“It seems to me that a plaintiff in such a case as this has an election: he can either claim for loss of profits; or for his wasted expenditure. But he must elect between them. He cannot claim both. If he has not suffered any loss of profits – or if he cannot prove what his profits would have been – he can claim in the alternative the expenditure which has been thrown away, that is, wasted, by reason of the breach.”

Where a claim is made for reliance losses, the innocent party is not entitled to recover expenditure that would have been wasted in any event because the bargain would have been loss-making: C&P Haulage v Middleton [1983] 1 WLR 1461 (CA) per Ackner LJ at pp.1466-1467:

“[The defendant] is not claiming for the loss of his bargain, which would involve being put in the position that he would have been in if the contract had been performed. He is not asking to be put in that position. He is asking to be put in the position he would have been in if the contract had never been made at all. If the contract had never been made at all, then he would not have incurred these expenses, and that is the essential approach he adopts in mounting this claim; because if the right approach is that he should be put in the position in which he would have been had the contract being performed, then it follows that he suffered no damage…

It is not the function of the courts where there is a breach of contract knowingly, as this would be the case, to put a plaintiff in a better financial position than if the contract had been properly performed.”

In CCC Films (London) Ltd v Impact Quadrant Films Ltd [1985] 1 QB 16 (QBD) the court considered the burden of proving that a claimant had suffered no damage in claims for wasted expenditure because of a bad bargain and concluded that the burden of proof was on the defendant: per Hutchinson J at pp.33-39:

“It is … common ground that a claim for wasted expenditure cannot succeed in a case where, even had the contract not being broken by the defendant, the returns earned by the plaintiff’s exploitation of the chattel or the rights the subject matter of the contract would not have been sufficient to recoup that expenditure …

On this crucial question of where the onus of proof lies in relation to whether or not the exploitation of the subject matter of the contract would or would not have recouped the expenditure, there are, however, a number of cases which are more directly relevant …

Even without the assistance of such authorities, I should have held on principle that the onus was on the defendant. it seems to me that at least in these cases were the plaintiff’s decision to base his claim on abortive expenditure was dictated by the practical impossibility of proving loss of profit rather than by unfettered choice, any other rule would largely, if not entirely, defeat the object of allowing this alternative method of formulating the claim. This is because, notwithstanding the distinction to which I have drawn attention between proving a loss of net profit and proving in general terms the probability of sufficient returns to cover expenditure, in the majority of contested cases impossibility of proof of the first would probably involve like impossibility in the case of the second. It appears to me to be eminently fair that in such cases where the plaintiff has by the defendant’s breach being prevented from exploiting the chattel or the right contracted for and therefore, putting to the test the question of whether he would have recouped his expenditure, the general rule as to the onus of proof of damage should be modified in this manner. ”

A claim for reliance losses uses a different method of measurement from that used to calculate expectation losses but both provide compensation for the same loss of the contractual bargain in accordance with the Robinson v Harman principle: Omak Maritime Ltd v Mamola Challenger Shipping Co [2010] EWHC 2026 per Teare J:

“[42] I consider that the weight of authority strongly suggests that reliance losses are a species of expectation losses and that they are neither … "fundamentally different" nor awarded on a different "juridical basis of claim". That they are a species of expectation losses is supported by the decision of the Court of Appeal in C&P Haulage v Middleton and by very persuasive authorities in the United States, Canada and Australia.

…

[44] It seems to me that the expectation loss analysis does provide a rational and sensible explanation for the award of damages in wasted expenditure cases. The expenditure which is sought to be recovered is incurred in expectation that the contract will be performed. It therefore appears to me to be rational to have regard to the position that the claimant would have been in had the contract been performed.

…

[55] I am not therefore persuaded that the right to choose or elect between claiming damages on an expectancy basis or on a reliance basis indicates that there are two different principles at work … I am unable to accept that there are two principles, rather than one, governing the law of damages for breach of contract.

…

[59] … the weight of authority firmly suggests that an award of reliance damages is governed by the principle in Robinson v Harman …”

In Yam Seng Pte Ltd v International Trade Corporation Ltd [2013] EWHC 111 (QBD) per Leggatt J (as he then was) considered this issue:

“[186] The basis on which wasted expenditure can be recovered as damages for breach of contract was considered by Teare J in Omak Maritime Ltd v Mamola Challenger Shipping

Co [2011] 1 Lloyd’s Rep 47. In his masterly judgment Teare J has shown that awarding compensation for wasted expenditure is not an exception to the fundamental principle stated by Baron Parke in Robinson v Harman (1848) 1 Exch 850 at page 855 that the aim of an award of damages for breach of contract is to put the injured party, so far as money can do it, in the same position as if the contract had been performed, but is a method of giving effect to that fundamental principle. That conclusion must logically follow once it is recognised, as it was by the Court of Appeal in C & P Haulage v Middleton [1983] 1 WLR 1461, that the court will not on a claim for reimbursement of losses incurred in reliance on the contract knowingly put the claimant in a better position than if the contract had been performed.

…

[190] … Parties in normal circumstances contract and incur expenditure in pursuance of their contract in the expectation of making a profit. Where money has been spent in that expectation but the defendant's breach of contract has prevented that expectation from being put to the test, it is fair to assume that the claimant would at least have recouped its expenditure had the contract been performed unless and to the extent that the defendant can prove otherwise.”

In The Royal Devon and Exeter NHS Foundation Trust v ATOS IT Services UK Ltd [2017] EWHC 2197 (TCC) this Court endeavoured to summarise the above principles at paragraphs [53] to [58], concluding that a claim for wasted costs can be explained as compensation for the loss of the bargain based on a rebuttable presumption that the value of the contractual benefit must be at least equal to the amount that the claimant is prepared to expend in order to obtain such benefit.

Applying the above principles to this case, the starting point is to identify the contractual benefit lost as a result of IBM’s repudiatory breach of contract.

CISGIL's business was the underwriting and distribution of general insurance products. The new IT solution which IBM promised to supply was anticipated to improve CISGIL’s competitiveness as a market-leading digital and data-based business, which would produce substantial savings, increased revenues and increased profits.

The loss of the bargain suffered by CISGIL as a result of IBM’s repudiatory breach comprised the savings, revenues and profits that would have been achieved had the IT solution been successfully implemented.

A conventional claim for damages in this type of commercial case would usually be quantified based on those lost savings, revenues and profits. CISGIL is entitled to frame its claim as one for wasted expenditure but that simply represents a different method of quantifying the loss of the bargain; it does not change the characteristics of the losses for which compensation is sought.

Clause 23.3 of the MSA excludes any claim by either party for “loss of profit, revenue, savings (including anticipated savings) … (in all cases whether direct or indirect) …”

In accordance with the above analysis, such a claim is excluded, whether it is quantified as the value of the lost profit, revenue and savings, or as wasted expenditure.

It follows that CISGIL’s claim for wasted expenditure is excluded by clause 23.3.

CISGIL seeks to rely on the decision of this Court in Royal Devon and Exeter where, on the facts of that case, in which the claimant was a non-profit making NHS trust, a

For the above reasons, CISGIL’s primary claim for wasted expenditure in respect of the wrongful termination by IBM, is excluded by clause 23.3 of the MSA and fails.

On 8 May 2015, CISGIL entered into a 10-year bond for £70 million paying 12% p.a.

CISGIL relies on the evidence of Mr Summerfield in his witness statement:

“The investment cost of a new IT solution was significant and required a capital injection in order to ensure CISGIL complied with the strict capital requirements of the PRA. Briefly, there were three options considered to raise the capital: (i) raising the funding internally through the Coop Group; (ii) raising external funding by inviting an external investor to purchase a minority equity stake; or (iii) raising debt finance in the public and private debt markets….

Having weighed up the pros and cons of the different options, we agreed that the best option was to raise capital through a market specialist debt fund …

The capital raised through the issuance of the Bond was deployed to strengthen CISGIL's capital base, and although the funds were not held in a specific Programme related bank account, the funds were critical to enable CISGIL to cover the costs of the implementation of the new IT solution and the amount raised (and more) was used for this purpose.”

In cross-examination, Mr Summerfield accepted that the bond was not strictly required for regulatory compliance but to provide a capital buffer during the transformation programme. The PRA expected CISGIL not to breach 120% of its solvency capital requirement but also expected it to assess the risks of its business and determine a suitable buffer. Generally, CISGIL operated with a buffer of 130%. In the autumn of 2014, CISGIL’s financial indicators were that it would fall below 120%, prompting questions from the regulator. It was agreed with the regulator that CISGIL should increase its capital buffer to 140% to support the new risks to the business by the transformation programme.

IBM’s case is that the claims for bond interest and transaction fees are excluded by clause 23.3 as indirect loss.

IBM submits that the bond was needed both to bring CISGIL back within the risk appetite set by the Board, and to ensure that CISGIL remained within that risk appetite during the transformation programme. Reliance is placed on Mr Summerfield’s evidence that the IT solution was only one element of the transformation programme.

IBM submits that interest on the bond is not a loss naturally arising from breach of the MSA. Rather, it is a loss that arises owing to the particular nature of CISGIL’s business, its capital adequacy position, the regulatory scrutiny that it was under, and its Board’s risk appetite; as such, it is a loss that could only have been in the contemplation of the parties had IBM specifically been told about it. It follows that interest on the bond is indirect loss and excluded by clause 23.3 of the MSA.

I am satisfied on Mr Summerfield’s evidence that the bond interest and the associated transaction fees were incurred in order to fund the IT project. Although part of the wider transformation programme, the IT solution was central to the programme and devoured the vast bulk of the expenditure. Funding for the project was a direct cost incurred by CISGIL. I am also satisfied that the decision by CISGIL to fund the project in this way was reasonable. As such, the bond interest and transaction fees were properly included in the claim for wasted expenditure and not excluded by clause 23.3 as indirect costs. However, for the reasons set out above, the claim for wasted expenditure fails.

Clause 23.5 provides:

“Subject to clauses 23.2, 23.3 and 23.6 the Supplier's aggregate liability to the Customer Group:

(a)

for the Implementation Services, shall be limited to 150% (one hundred and fifty percent) of the Charges paid and/or would have been payable by the Customer if the Implementation Services had been performed in full and there had been no claims or deductions;

…

(e)

arising otherwise under and/or in connection with this Agreement shall be limited to the greater of:

(i)

£15.7 million (fifteen million seven hundred thousand pounds); or

(ii)

125% (one hundred and twenty-five percent) of the total Charges paid and/or would have been payable for the Managed Services in the 12 (twelve) month period immediately preceding the first cause of action arising.

…

The provisions of this clause 23.5 shall operate as separate and additional liability limitations to all other limitations of liability in this clause 23.5 and clause 23 and any liability for any matters listed in this clause 23.5 shall not form part of any calculation of whether the limits of liability under any other provision of this clause 23 have been reached.”

The parties agree the method of calculating the value of the cap under clause 23.5(a), if applicable, but have arrived at different figures: CISGIL’s figure is £83.6 million; IBM’s figure is £83,463,768. As the Court has not been supplied with the competing calculations, and because it does not affect the outcome of the case, that discrepancy remains unresolved.

It is common ground that the cap under clause 23.5(e), if applicable, would be £15.7 million.

No increase is applied for wilful default because those allegations have been rejected on the evidence.

There is a disagreement between the parties as to the operation of the contractual caps in respect of the unlawful termination claim. IBM’s case is that the applicable cap for the unlawful termination claim is that under clause 23.5(e), namely £15.7 million; CISGIL’s case is that the caps under clause 23.5(a) and 23.5(e) fall to be aggregated, namely, an overall cap of £99.3 million.

As set out above the Court has dismissed CISGIL’s claim for wasted expenditure and therefore this issue falls away.

IBM accepts that CISGIL’s alternative claim for delay and reporting failures is not excluded by clause 23.3. It is common ground that such claim concerns liability for the Implementation Services and is subject to the clause 23.5(a) cap of £83.6 million or £83.4 million.

CISGIL’s alternative claim in respect of additional resource and third party costs as a result of delays and inaccurate reporting is £27.2 million, falling well within either valuation of the cap.

For completeness, I deal briefly with the material differences between the parties in respect of the quantum of the wasted expenditure claim.

IBM submits that there is inadequate evidence as to the extent to which costs were actually wasted because CISGIL has failed to provide any explanation as to what it did after termination and what parts, if any, of the IT solution were used.

Ms Noakes stated that CISGIL obtained some value relating to IBM’s ‘Be The

IBM accepts that amounts paid to it in relation to Release 1 and Release 2 have largely been wasted by reason of the termination. It does not accept, however, that the amounts paid to it in relation to the Oracle finance implementation (‘Hyperion’ and ‘Fusion’) have been wasted by reason of any breach by IBM. It submits that those costs have been wasted for the simple reason that CISGIL has chosen not to use the system.

Ms Noakes’ evidence was that ‘Hyperion’ was of no value to CISGIL after termination and CISGIL decided not to go ahead with the implementation of ‘Oracle’ as it was too slow and more expensive than expected.

Ms Harvey’s evidence was that, post termination, CISGIL made the decision to sell the business and migrate all data to the buyer’s systems; against that decision, the costs and time of implementing Fusion outweighed any benefit that might be derived from it.

Following IBM’s unlawful termination, against the backdrop of a disastrous IT project, it was reasonable for CISGIL to review its strategy for the business. IBM has not discharged its burden of proof that CISGIL failed to mitigate its loss.

Mr Summerfield explained in his evidence, which I accept, that CISGIL continued to operate on the legacy platform until January 2020, pending completion of its sale to Markerstudy. On that basis, the costs of the IT solution were wasted in their entirety.

CISGIL’s claim, based on Mr Eastwood’s assessment, is £128 million. IBM’s case, based on Mr Ilett’s assessment, is that £28.3 million has been verified, £43.5 million is unverified and should be rejected and £56.4 million is unverified as to amount.

The sums claimed and the differences between the experts (subject to issues of fact and law affecting recovery) can be summarised as follows:

The experts agreed in their first joint statement that the costs recorded in the claim were paid by CISGIL. Further, they agreed that:

The pre-adjusted supplier costs claimed by CISGIL and recorded in the Programme Ledger were set out in an agreed table by the experts appended to an addendum to their joint statement:

CISGIL used Oracle, an industry standard accounting system, to record its financial information on a general ledger which summarised information relating to each financial transaction. Mr Eastwood interrogated the costs included in the Programme Ledger, checking 79% of the pre-termination amount by value to underlying records such as invoices, 95% of the amount by value to records of contemporaneous approval, and 95% of the amount by value to evidence of payment. He reviewed the system within CISGIL for authorising expenditure through the issue of purchase orders and approving invoices.

CISGIL’s financial statements were subject to annual external audits. Its auditors during the project were KPMG LLP for the year ended 31 December 2015, and Ernst & Young LLP for the years ended 31 December 2016, 2017 and 2018. For each of those years, KPMG or EY issued an unqualified audit report on the financial statements.

Mr Eastwood’s opinion was that:

“In my view, the fact that the cost entries recorded in the Programme Ledger were contemporaneously subject to review by multiple parties, provides evidence of the reliability of those cost entries as the basis for the quantification of CISGIL’s alleged losses. Furthermore, the results of the testing I have performed, described in the later sections of this report, suggest that the purchase order approval and invoice payment processes relating to the Programme were working effectively.”

Mr Ilett’s opinion is that CISGIL’s Programme Ledger is not a reliable basis for quantification of the claims. First, CISGIL’s accounting processes were not sufficiently robust to allow meaningful validation that costs on the Programme Ledger actually related to the project (rather than to other aspects of CISGIL’s business) and were properly incurred. Secondly, the testing that Mr Eastwood carried out to support the claim was superficial and inadequate. Mr Eastwood failed to investigate how the contractors responsible for approving costs actually did so, and to take any independent steps to verify that the figures presented to him by CISGIL were (i) properly to be treated as costs incurred in relation to the project and (ii) those costs were wasted by reason of breaches by IBM.

I am satisfied that Mr Eastwood’s approach to the verification of the wasted costs claimed by CISGIL was reasonable and proportionate.

That is subject to specific matters identified by Mr Ilett in his report regarding

The first issue concerns Rullion. Rullion was a recruitment agency that provided external contractors to work on the project, in particular for the Technology, Innovation and Change (“TIC”) group chaired by Mr Coomer.

Mr Rielly, programme accountant for CISGIL from 2017, explained in his witness statement that the general process for the recording of Rullion Recharges was as follows. Rullion contractors recorded their time on Rullion’s time recording platform. On a periodic basis, it would send timesheet extracts of the time recorded by the contractors and their associated costs to CISGIL, showing (i) the name of each contractor; (ii) the time and cost relating to the contractor; (iii) the period to which the cost related; and (iv) the CISGIL cost centre to which the work related. CISGIL would centrally review and update the Rullion timesheets and send them to the individuals responsible for the cost centres to which the costs related. The NOM Project Management Office would review the Rullion timesheet and, if satisfied that the time and costs were correct, approve the costs relevant to their cost centre once all entries on the timesheet were approved. CISGIL would raise a purchase order and