England and Wales High Court (Technology and Construction Court) Decisions

i)                    the contractual completion date for the home insurance platform (“Release 1 Go Live”) was 30 April 2016, subsequently extended to the end of May 2016 by way of a working agreement;

ii)                  the contractual completion date for the motor insurance platform (“Release 2 Go Live”) was 15 August 2016; and

iii)                the contractual date by which all historic customer data would be transferred from the existing system to the new system was the end of October 2016.

i)                    CISGIL’s delays in providing details of its requirements and other necessary information required to build Release 1;

ii)                  CISGIL’s failure to conduct User Acceptance Testing (“UAT”) of Release 1 timeously or competently; and

iii)                CISGIL’s delays in providing its requirements and other necessary information required to build Release 2, together with resource constraints.

Chronology

Background to the transformation programme

Text set out in the confidential schedule.

The tender process

“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 … ”

“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.”

“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 IT solution proposed by IBM

i)                    configuration, that is, modifying the behaviour of a software package by setting parameters so that it behaves in a particular way, typically using configuration software provided with the package, without writing new code;

ii)                  customisation, that is, modifying the behaviour of a product, by developing new source code which is added to the source code of the existing package, or by re-writing or modifying the existing source code to work in a different way; and

iii)                base development, that is, the incorporation of additional features into the base software package supplied to all clients; such additional features would become part of the base software and would be maintained by the developer.

Due Diligence

Interim Services Agreement

The MSA

“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.”

“There are several objectives which underpin the Customer's strategic aims for the Programme. The Supplier acknowledges that the following guiding principles are intended to be met through the delivery of the Core Services and shall provide context when determining each party's obligations in each Statement of Work for Core Services:

(a)          Technology Led Transformation — the technology plan and Roadmap will be the leading factor in both the plan for delivery and for any changes to the Customer's organisation and operating model. Business structures, processes and transformation plans will be adapted to the capabilities and limitation of the Solution and the technology delivery plans;

(b)         Buy not Build — the Solution shall be based on a set of standard, market strength, regulatory compliant software products; and

(c)          Out-of-the-Box — the Software forming part of the Solution shall be used in an out-of-the-box fashion.”

“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.”

i)                    Clause 4.3:

“The Customer with effect from the Effective Date appoints the Supplier and the Supplier agrees:

(a)          to provide and perform all the Core Services and Deliverables set out in the Implementation Services SOW and Managed Services SOW during the Term; and

(b)          to otherwise perform its obligations,

in each case in accordance with this Agreement.”

ii)                  Clause 4.5:

“The Supplier shall:

(a)          provide the Core Services and any Programme Related Services that relate to the Core Services in accordance with the Solution Design, and in particular ensure that each Deliverable forming part of the Implementation Services complies with all relevant aspects of the Solution Design and must continue to so comply when combined with any other Deliverable forming part of the Implementation Services, previously implemented;

(b)         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;

…

(e)          comply with and shall procure that its Approved Subcontractors comply with (i) all Relevant Laws applicable to Supplier and the Approved Subcontractors as the provider of IT Services, and (ii) the specific provisions of any Relevant Laws which the Customer or any member of the Customer Group has notified the Supplier of in writing, in each case applicable to the performance of the Services …

…

(g)         not do or omit to do anything that would cause any member of the Customer Group to be in breach of any of the standards, policies and procedures set out in clause 4.5(d) and/or any Relevant Laws as described in clause 4.5(e);

(h)         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 compliance with clauses 4.5(d) and 4.5(e); and

(i)          subject to the Customer providing copies, not put the Customer in breach of any Third Party Contracts that the Customer has that are used by the Supplier to provide the Services.”

iii)                Clause 4.8:

“Subject to clause 9, the Supplier shall be responsible for providing everything required to enable it to perform the Services, including any accommodation, facilities, equipment, networks and labour. The Supplier shall obtain, at its own cost, all consents, approvals or licences which are necessary from time to time to enable the Supplier as a information technology provider to perform the Services in accordance with this Agreement and for the Customer and any member of the Customer Group to receive the Services (excluding any consents Customer requires from a Competent Authority) and use any Materials and/or Deliverables provided by the Supplier, in each case in accordance with this Agreement.”

iv)                Clause 4.12:

“The Supplier shall co-operate with the Customer and third party suppliers to assist the Customer with the implementation and operation of the Services and the wider requirements of the Programme. This may include working with members of the Customer Group and third party suppliers to agree implementation plans, to co-operate during testing, and to assist with the development of interfaces. The extent of these obligations and associated commercials shall be further described in a Statement of Work.”

“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.”

“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.”

i)                    Clause 12.1:

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

(a)          the Supplier has the requisite power and authority to enter into this Agreement and to carry out the obligations contemplated by it and that the execution and performance of this Agreement has been duly authorised by the required corporate action by the Supplier;

(b)         the Supplier is able to execute the Agreement without being in violation of any judgment, order or decree or breach of any existing contracts with the Supplier, any of its Affiliates and/or any of the Supplier third parties involved in the Solution; and

(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.”

ii)                  Clause 12.2:

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

…

(e)          the Solution shall meet the Customer Requirements as varied by the Traceability Matrix for the Term …

“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).”

“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).”

“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).”

“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 …”

“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 …”

“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:

(a)          the Supplier is in material breach of this Agreement which is incapable of remedy or which, if capable of remedy, has not been remedied within 30 (thirty) days of receipt of a written notice from the Customer specifying the breach and requiring the same to be remedied …”

“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.”

“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.”

“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.”

“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.”

“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).”

“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 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…”

“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).”

“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.”

Implementation tools

i)                    ‘Rational Project Documents’, a document repository which facilitated document sharing between IBM, IG and CISGIL;

ii)                  ‘Rational Change and Configuration Management’, which allowed records of tasks, defects, changes, risks and other items to be recorded and shared between team members;

iii)                ‘Rational Requirements Management’, which was used to record and trace the business requirements; and

iv)                ‘Rational Quality Management’, which was used to record test plans, scripts and test results.

Agile methodology

Release 1

“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.”

“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.”

“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.”

“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.”

i)                    CISGIL would provide business information by 9 October 2015 and IBM/IG would provide the technical configuration for delivery of Drop 1 by 23 November 2015, to include interfaces, Insurer core processes, NOM product and COM products;

ii)                  CISGIL would provide business information by 13 October 2015, documents by 30 October 2015 and IBM/IG would provide the technical configuration for delivery of Drop 2 by 18 December 2015, to include interfaces, Insurer core processes, documents and portals;

iii)                CISGIL would provide business information by 20 November 2015, documents by 18 December 2015 and IBM/IG would provide the technical configuration for delivery of Drop 3 by 12 January 2016, to include interfaces, aggregators, contact centre and documents.  

“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.”

“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 …”

“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… ”

“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 turning point

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

“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, I believe the fault predominantly lies with IBM and the subcontractors. You have managed a difficult project under significant constraints with great diligence and driven us to this point. To stop now would be disappointing both for the team but also it would be unfair for you not to get the recognition for the job you have done. Would you please reflect on the position over the next couple of days…”

Deterioration of the relationship between the parties

“… 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.”

“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.”

“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.”

Text set out in the confidential schedule.

i)                    The amount of code identified suggested that it was a copy of the base (referred to as “a fork”), rather than customer-specific extensions to the base.

ii)                  It found that a significant amount of customisation had been created using a ‘copy and modify’ approach, some of which was being back ported into the base code.

iii)                The application was categorised as source code with a moderate to low maintenance risk but, given its recent development, it should have been lower.

iv)                The amount of customisation grew significantly from drop 1 to drop 17.

v)                  The volume, duplication and complexity of code units gave rise to a high to very high maintenance level.

vi)                The code was well-structured but there were a high number of violations against best practice coding standards, leading to a technical debt (deferred maintenance required to resolve issues in the code) of over 4,000 man hours of work.

vii)              Further, the use of free open source software (“FOSS”) items, a number of which were not the most recent stable version, raised potential issues of licence restrictions and security risks.

“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.”

“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).”

i)                    Plan A - continue the project with IBM and IG and seek to agree a compromise on the larger value items still under dispute;

ii)                  Plan B - seek to remove IBM under favourable circumstances for CISGIL, such that the programme could be completed under CISGIL’s direction, possibly funded by IBM compromise payments; and 

iii)                Plan C - alternatives, such as new suppliers, or cancellation of the project and review the corporate structure, operating model and ownership options, including sale or run-off.

“…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 …”

“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.”

The AG 5 invoice issue

“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.”

“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.”

“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.”

“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.”

“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.”

“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.”

Termination

“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.”

“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.”

The Dispute

i)                    IBM was in repudiatory breach of the MSA by its purported notice of termination and its stated intention not to provide further services under the MSA, which repudiation was accepted by CISGIL.

ii)                  IBM’s repudiation was an intentional breach of the MSA, designed to bring the MSA to an end so that IBM could escape its obligations under the MSA, the Implementation SOW and the other SOWs, and it was reckless as to the consequences of such intentional breach. As such, it amounted to wilful default.

iii)                IBM was in breach of the warranty at Clause 12.1(c) of the MSA. As at the date of the MSA, IBM had not taken all reasonable steps (including making all appropriate enquiries and obtaining all appropriate professional and technical advice) with a view to ascertaining whether IG’s software was capable of providing the solution within the contractual or other reasonable timescale.

iv)                In breach of clauses 4.5(b) and 4.5(h) of the MSA, Schedule 3 and Schedule 12, IBM failed to inform CISGIL at any stage that the Insurer Suite did not provide the configurable OOTB solution upon which the MSA and the key milestones were predicated, nor that the Insurer Suite had to be substantially re-written and/or redeveloped in order to meet the requirements it had contracted for and that the key milestones were unachievable.

v)                  IBM’s failure to inform CISGIL that the key milestones were unachievable was an intentional breach of the MSA, as from about November 2015, and it was reckless as to the consequences of such intentional breach. As such, it amounted to wilful default.

vi)                In breach of clauses 4.5(b) and 4.5(h) of the MSA, Schedule 3 and Schedule 12, IBM failed to achieve the key milestones by the dates specified in the Roadmap, and failed to manage the programme or report actual and probable future progress with reasonable accuracy so as to enable CISGIL to plan its expenditure on resources and third party contractors with reasonable efficiency.

i)                    IBM was lawfully entitled to terminate under the MSA by reason of CISGIL’s wrongful failure to pay the AG5 invoice in respect of software licences.

ii)                  The IG software did not need substantial re-writing or development to meet the requirements of the UK market or to satisfy IBM’s obligations under the MSA. The agreed fit-gap analysis identified the extent of base code development, customisation and configuration required to implement the solution.

iii)                IBM complied with its reporting obligations, including notifications of delays to the project.

iv)                IBM achieved all milestones prior to IMP-018c by the contractual delivery dates. As at the date of termination, all of the Release 1 functionality and much of the Release 2 functionality had been built, and IBM had delivered a complete finance system, marketing operations and regulatory document repository solution, and quantitative reporting for solvency II solution. The project was in delay but a substantial cause of the delay was CISGIL’s failures, including late supply of information and UAT inadequacies.

v)                  There was no wilful default on the part of IBM.

The Issues

i)                    Issue 1: whether IBM was entitled to exercise its termination rights under the MSA by reason of CISGIL’s failure to pay the invoice dated 27 March 2017 in respect of milestone AG5:

a)                  whether the milestone AG5 was due and payable by early 2017;

b)                 whether the AG5 invoice as submitted by IBM was due and payable;

c)                  whether CISGIL disputed the AG5 invoice;

d)                 whether CISGIL was entitled to rely on set-off to resist payment;

e)                  whether IBM exercised any right to terminate in accordance with the provisions of the MSA or was in repudiatory breach;

f)                  whether IBM’s purported termination constituted “wilful default” for the purpose of clause 23.5 of the MSA.

ii)                  Issue 2: whether IBM was in breach of the warranty and representation in clause 12.1 of the MSA:

a)                  the meaning and effect of clause 12.1 of the MSA;

b)                 whether Insurer Suite required substantial re-writing and development as alleged by CISGIL;

c)                  whether IBM failed to take reasonable steps to ascertain the risks associated with Insurer Suite and/or misrepresented the nature and scope of the required development of the product;

d)                 whether CISGIL would have entered into or continued with the project if IBM had given full information.

iii)                Issue 3: whether IBM was in breach of clause 4.5, Schedule 3 and/or Schedule 12 of the MSA in failing to report on the true state of the project:

a)                  whether Insurer Suite had to be substantially re-written and/or redeveloped in order to meet CISGIL’s requirements so that the key milestones were unachievable;

b)                 what was IBM’s state of knowledge at the relevant time(s);

c)                  what IBM reported to CISGIL and/or what CISGIL knew as to outstanding base development required;

d)                 whether IBM was in breach of its reporting obligations;

e)                  whether CISGIL would have cancelled the project if it had been properly informed of the true state of the project.

iv)                Issue 4: whether IBM was in breach of the MSA for any delays and/or failures to report in respect of such delays:

a)                  the nature and extent of any delays to milestones IMP-018c, IMP-021 and the Release 2 milestones;

b)                 the party responsible for any delays;

c)                  whether IBM was in breach of its reporting obligations in respect of such delays.

v)                  Issue 5: Quantum :-

a)                  whether any of the claims are excluded or subject to limitation by clauses 23.3 and/or 23.5 of the MSA;

b)                 whether the sums claimed by CISGIL by way of wasted expenditure were actually and reasonably incurred, and recoverable as damages;

c)                  quantification of any alternative claims;

d)                 IBM’s set-off and counterclaim for payment of the AG5 invoice.

Evidence

i)                    Neil Southworth, CISGIL’s chief risk officer;

ii)                  Mark Summerfield, CISGIL’s chief executive officer, responsible for Project Cobalt;

iii)                Richard White, a consultant engaged by CISGIL in September 2016 as programme director for the project;

iv)                Ric Wood, an IT contractor, who worked for IG between August 2015 and early 2016, and for CISGIL from February 2016;

v)                  Leah Noakes, commercial manager for CISGIL, involved in the purchase order process, payment milestones and invoicing;

vi)                Louise Keohane, of Co-op, involved in the tender and due diligence phases of the project;

vii)              Gary Craven, an IT contractor engaged on the project from April 2016 to manage Release 1 UAT 1 and UAT 2;

viii)            Matt Legerton, head of IT architecture for insurance at Co-op, involved in the tender, due diligence and solution outline phases;

ix)                Chris Rielly, project finance manager for CISGIL in 2017, dealing with the AG5 invoice and quantum;

x)                  Joanne Harvey, chartered accountant, head of financial planning and analysis at CISGIL, dealing with quantum;

xi)                Christopher Jackson, executive partner, insurance, at IBM;

xii)              Christopher Down, IBM’s bid manager for the project;

xiii)            Denise Barnes, executive partner at IBM responsible for delivery of the Project;

xiv)            Graham Perrott, general manager, Global Business Solutions;

xv)              Stephen Allen, project manager at IBM;

xvi)            Katie Hyman, commercial manager at IBM;

xvii)          Martin Broughton - associate partner at IBM;

xviii)        Jacqueline Boast - former global chief marketing officer of IG;

xix)            Susan Balcombe - senior management consultant at IBM;

xx)              John Dobey - senior management consultant and lead on testing.

i)                    Dr Hunt - IT expert instructed by CISGIL on issues of base code development and delay to implementation of Insurer Suite;

ii)                  Dr McArdle - IT expert instructed by IBM on issues of base code development;

iii)                Mr Morgan - project management expert instructed by IBM on issues of delay;

iv)                Mr Eastwood, chartered accountant and senior managing director in FTI, instructed by CISGIL on quantum;

v)                  Mr Ilett, a partner in Haberman Ilett, instructed by IBM on quantum.

Issue 1 - Termination

i)                    The AG5 milestone was not achieved and was not approved by CISGIL. The AG5 milestone (IMP-30) formed part of the Roadmap by which the solution was to be delivered. It was not payable because of IBM’s failures to meet prior milestones, in particular Release 1 go-live (IMP-22) and Release 2 go-live (IMP-26). Further, and in any event, before it became payable, CISGIL’s approval of the AG5 milestone was required. No such approval was given and therefore the AG5 milestone was not due and payable.

ii)                  The AG5 invoice was not correctly prepared or properly submitted as required by Schedule 5 of the MSA.

iii)                The AG5 invoice was disputed by CISGIL by email dated 27 March 2017.

iv)                CISGIL asserted rights of set-off against the AG5 invoice by notice dated 12 May 2017.

v)                  IBM lost any right of termination by its delay.

vi)                IBM was in wilful default. CISGIL alleges that IBM knew at the time that it purported to terminate the MSA that it did not have any right of termination; its purported termination was a deliberate breach of the MSA and IBM was reckless as to the financial consequences for CISGIL.

i)                    The AG5 milestone (IMP-30) was not dependent on achievement of any other milestones; the sum was in respect of software licences and became due and payable in January 2017 as set out in the Roadmap at Appendix A of the MSA. Payment was not subject to CISGIL’s approval of the AG5 milestone; in any event there was no ground on which CISGIL could properly withhold approval and the payment was due and payable.

ii)                  The AG5 invoice was correctly prepared and properly submitted as required by Schedule 5 of the MSA, save that there was no purchase number for the invoice because it had been wrongfully withheld by CISGIL.

iii)                The AG5 invoice was not disputed by CISGIL within seven business days of the invoice (by 4 April 2017); accordingly CISGIL had a contractual obligation to pay the same.

iv)                CISGIL failed to assert any rights of set-off against the AG5 invoice until the time for doing so had expired.

v)                  IBM did not lose its right of termination by reason of delay. The MSA stipulated a protracted period for CISGIL to consider its position: 45 days before a final notice, then 15 business days before IBM could exercise its termination right under clause 26.7. IBM gave CISGIL slightly longer but the notice was served within a reasonable time of CISGIL’s default.

vi)                Even if the Court finds against IBM on the issue of termination, there was no wilful default on its part. At the time of termination, CISGIL had made it clear that no further payments would be made to IBM and resisted all attempts by IBM to salvage the project.

The software licence payments

“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…”

“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 Co-op 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 Co-op do not proceed…”

i)                    £500,000 would be invoiced on signature of the Licence Agreement and payable within 60 days;

ii)                  £1 million would be invoiced on signature of the MSA (or 29 May 2015 if earlier), of which £500,000 would be payable within 60 days and £500,000 would be payable following delivery into UAT (or 15 September 2015 if earlier); and

iii)                £2 million would be invoiced by 15 September 2015 and payable in accordance with payment milestones to be agreed between the parties in good faith, provided that such payments would be fully paid no later than 1 January 2016.

“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.”

“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.”

“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 …”

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

“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.”

AG5 Milestone

“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.”

“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.”

“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.”

“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.”

i)                    IMP-004 - Application Gate 1 - Application delivery phase 1 - latest delivery date of end June 2015;

ii)                  IMP-009 - Application Gate 2 - Application delivery phase 2 - latest delivery date of start September 2015;

iii)                IMP-017 - Application Gate 3 - Application delivery phase 3 - latest delivery date of start December 2015;

iv)                IMP-020 - Application Gate 4 - Application delivery phase 4 - latest delivery date of end March 2016;

v)                  IMP-030 - Application Gate 5 - Application delivery phase 5 - latest delivery date of start January 2017.

“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.”

“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.”

“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.”

“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.”

Milestone payment process

i)                    Tom Phillpott (finance manager) would identify the need to raise a purchase order (‘PO’);

ii)                  the PO requisition form would be completed and sent to one of Ms Neate (programme director), Mr O’Keefe (chief financial officer) or Mr Summerfield (CEO), depending on the value, who would give approval via the purchase to pay system;

iii)                a PO number would be created and sent to Mr Phillpott;

iv)                Mr Phillpott would send the PO number to Katie Hyman (lead commercial manager) at IBM;

v)                  IBM would advise Mr Phillpott and Kevin Webb (programme commercial lead) of CISGIL prior to starting its internal invoice-raising process; in turn, Mr Phillpott would advise Ms Neate, Mr Summerfield and Mr O’Keefe of the same;

vi)                IBM would submit the invoice to Purchase to Pay, Mr Webb, Ms Bradley, Mr Phillpott and Ms Neate at CISGIL;

vii)              Mr Phillpott would obtain the nominated customer approval, following which the accounts department would be advised to make payment;

viii)            payment would be made;

ix)                IBM would confirm payment receipt.

“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.”

“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.”

“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?”

“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?”

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

“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.”

“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.”

“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.”

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

“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.”

“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 e-invoice solutions using an ePDF solution. Accordingly, to confirm we will deliver e-invoices to you relating to IBM products and/or Services…”

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

“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.”

AG milestone dispute

“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.”

“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.”

“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.”

“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?”

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

“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.”

“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. ”

“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 date-based), 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.”

“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.”

 Discussion and finding on the AG5 milestone

“The Supplier grants to the Customer, each member of the Customer Group (each, a Licensee) an exclusive, non-assignable … right in the Territory for the Term to access the Solution and to use the Solution together with the right to permit any and all Users to access and use the Solution, in each case:

(a) for the insurance business purposes of each Licensee;

(b) to offer or make available insurance products and services to the Licensee's customers;

(c) to provide services and training to the Licensees; and

(d) to allow suppliers (including Outsource Providers) of any Licensee to use the Solution solely as required in connection with the provision of goods and/or services to any Licensee for any of the purposes in sub clauses 10.1 (a), (b) and (c) above.

(Licensed Purposes).”

“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.”

Contractual provisions re invoices

“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).”

“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.”

AG 5 invoice submission and rejection

“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.”

“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.”

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

“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.”

“Can’t say I am surprised.”

“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.”

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

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

“Reject. We will need to consider how to advise IBM.”

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

“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.”

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

Validity of invoice

i)                    In breach of paragraph 11.4(b) of Schedule 5 of the MSA, the invoice did not quote a Customer purchase order number.

ii)                  In breach of paragraph 11.4(b) of Schedule 5, the invoice did not quote the relevant Statement of Work identifier, which was “SOW-001”. CISGIL accepted in its closing submissions that this complaint was not pursued.

iii)                In breach of paragraph 11.4(c) of Schedule 5, the invoice did not show the relevant payment milestone, IMP-030 Application Gate 5, but instead identified the milestone as “IMP-020 Application Gate 5.”

iv)                In breach of paragraph 11.1(a) of Schedule 5, IBM did not send a copy of the purported invoice by email to the following address: gifinancialreportingteam@cooperative.coop. CISGIL accepted in its opening submissions that this complaint was not pursued.

v)                  In breach of the IBM Purchase Order to Payments process, and/or in breach of paragraph 11.3 of Schedule 5, IBM did not send a copy of the AG5 invoice by email to CISGIL’s personnel as appointed or agreed between the parties for that purpose; IBM only sent the purported invoice by email to purchase2pay@cfs.coop and failed to provide back-up data.

Was the AG5 invoice disputed?

i)                    IBM had sought payment of AG5 and requested a purchase order for it in December 2016 but CISGIL intentionally failed to provide a purchase order number to IBM for the invoice;

ii)                  CISGIL chose, deliberately, not to tell IBM that it had decided not to provide it with a purchase order or to pay the invoice, or that it was disputed;

iii)                CISGIL chose not to invoke the dispute resolution procedure by serving a notice on IBM with sufficient information to enable IBM to appreciate the nature of the dispute; and

iv)                CISGIL acted wrongfully in that it was not entitled to withhold the purchase order.

Set-off

“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…” 

“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.”

“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.”

“(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 cross-claim". 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…”

“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 …”

“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.”

“[83] A right of set-off may be excluded by agreement of the parties. If set-off is to be excluded by contract, clear and unambiguous language is required … But no more than that is required. In particular such a term is not to be treated in the same way as an exclusion clause…

“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.”

“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.”

“…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.”

“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 ...”

Termination

“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.”

“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 …”

Wilful Default

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

·         “This is a troubled project.

·         One major contractual payment was due in January 2017 for software that is being used in the Programme. CISGIL has, despite repeated requests, not paid that invoice.

·         CISGIL’s refusal to pay the invoice is not an isolated event. CISGIL continues to refuse payment in relation to IBM’s other invoices. We believe CISGIL will refuse to pay all further charges.

·         IBM has followed the lengthy escalation process in the contract in relation to non-payment of this invoice and has given CISGIL every opportunity to make the payment.

·         IBM has the right to terminate the contract with CISGIL in the event of non-payment of undisputed invoices in excess of £1m…

·         Approval is sought to terminate the contract, subject to the provision of the full financial impact of Q3 and beyond, as will be provided by Accounting.”

·         “According to the Roadmap in the Implementation SOW, the Application Gate 5 Milestone was stated to have the “Latest Delivery Date” of beginning January 2017.

·         IBM was required to deliver the invoice for Application Gate 5 within 180 days otherwise IBM would not have been able to recover the charges.

·         IBM requested CISGIL to provide the purchase order (PO) number in relation to Application Gate 5 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. To date CISGIL has refused to provide a PO number.

·         IBM issued the invoice in relation to Application Gate 5 on 24 March 2017 (invoice number: 5803171298) in the sum of £2,889.600 (including VAT).

·         The invoice was due and payable by 4 April 2017.

·         CISGIL has refused to pay the invoice.

·         CISGIL did not follow the dispute procedure in accordance with Schedule 5 of the MSA…”

·         “Clause 26.7 of the MSA entitles IBM to issue a Final Notice if CISGIL has failed to pay an undisputed invoiced amount in excess of £1m for a period in excess of 45 days.

·         As the invoice was unpaid in excess of 45 days, IBM issued the Final Notice in relation to the Invoice on 22 June 2017. Despite this CISGIL has not paid the invoice.

·         The invoice is more than 15 Business Days overdue since the date of the Final Notice.

·         IBM is now entitled to terminate the contract. This will result in the MSA terminating with immediate effect…”

“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.”

“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. ”

“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. ”

“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…”

“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.”

“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.”

“Understood. I don’t think this is for revenue, more for strengthening our position in 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.”

“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.”

“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 …  ”

“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.”

Summary of findings on termination

i)                    the AG5 milestone became due and payable in January 2017; there was no ground on which CISGIL could properly withhold approval;

ii)                  the AG5 invoice was correctly prepared and properly submitted as required by Schedule 5 of the MSA; CISGIL was not entitled to rely on the absence of a purchase order number because it had been wrongfully withheld;

iii)                the AG5 invoice was disputed validly by CISGIL by the email dated 27 March 2017;

iv)                CISGIL failed to assert any rights of equitable set-off against the AG5 invoice in accordance with the Schedule 5 procedure;

v)                  IBM did not lose any right of termination by reason of delay in operating clause 26.7 of the MSA but it was not entitled to serve a Final Notice or terminate under clause 26.7 because the AG5 invoice was disputed by CISGIL;

vi)                IBM’s purported termination by notice dated 27 July 2017 amounted to repudiation of the MSA and the SOWs, which CISGIL accepted by letter dated 28 July 2017;

vii)              there was no wilful default on the part of IBM within the meaning of the MSA.

Issue 2 - Breach of Warranty Claim

i)                    Clause 12.1(c) of the MSA contained a warranty that IBM had satisfied itself as to all risk, contingencies and circumstances regarding performance of the MSA and the SOWs.

ii)                  Insurer Suite was not a UK ready product that could meet CISGIL’s requirements OOTB with the level of configuration and customisation that had been identified pre-MSA. Insurer Suite required substantial base code development and IG did not have the resources required to meet the project timescales.

iii)                IBM failed to ascertain the extent of the risks and take reasonable steps to satisfy itself as to the risks. Prior to the MSA, IBM failed to take all reasonable steps to ascertain:

a)                  the true state of Insurer Suite;

b)                 the nature and extent of base development that IG undertook to carry out and for which it had estimated 2,500 man days;

c)                  whether, and if so what, base development was required for Release 1 Go Live and Release 2 Go Live and how far advanced it was at the date of the MSA;

d)                 whether at the date of the MSA, IG had the resources needed to complete the work at the same time as the customisation and configuration work which had been identified in the pre-MSA fit-gap exercise.

iv)                CISGIL would not have entered into the contract had the warranty been true and IBM notified it as to the true state of Insurer Suite.

i)                    CISGIL has misconstrued clause 12.1(c) of the MSA: its effect is to prevent IBM from excusing its performance or from claiming against CISGIL by relying on risks, contingencies and circumstances that it should have satisfied itself about prior to entering into the MSA. CISGIL’s case requires the warranty to impose on IBM an obligation to inform CISGIL of the outcome of its internal investigations and risk analysis prior to contracting, so as to give CISGIL an opportunity to decline entering into the MSA. No such obligation can sensibly be read into the language of the clause.

ii)                  Insurer Suite did not need a very substantial re-write or redevelopment to be ‘UK Ready’ or to meet CISGIL’s requirements. It did need additional development to meet certain of CISGIL’s requirements, but that need was identified and shared with CISGIL prior to the MSA. Any suggestion that, by the time of the MSA, IBM or CISGIL thought that Insurer Suite could meet the requirements OOTB without further development or customisation is contrary to the evidence.

iii)                Even if Insurer Suite did need very substantial re-writing or redevelopment, or any development at all beyond that which was anticipated prior to the MSA, there were no reasonable steps that IBM failed to take that would have led to that discovery.

iv)                CISGIL has failed to establish that had IBM not been in breach, CISGIL would have declined to enter into the MSA. In reality CISGIL had no viable options other than the MSA.

Clause 12.1(c) warranty

“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.”

i)                    it had taken all reasonable steps to ascertain all risk, contingencies and circumstances to do with its performance of the Agreement; and

ii)                  it had satisfied itself as to such risk, contingencies and circumstances to do with its performance of the Agreement.

“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]

Pleaded case

“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 A to Schedule 3 and the terms of the Implementation SOW (clause 1.5.4(b)), the new end-to-end IT Solution it contracted to provide and the project milestones which it agreed to meet were predicated on the basis of a configurable software solution that met the Claimant's functional requirements “Out of the Box” (i.e. with a minimum of new code).

(ii)     Innovation Group’s suite of software called ‘Insurer’ (the “Insurer Suite”) (which product was the core of the Defendant’s software solution) had been developed for the US market not the UK market. The Defendant should have made inquiries that ascertained that fact.

(iii)    If the Defendant had done so it should have further inquired and investigated (i) the extent to which the US insurance market differed from the UK market and how that impacted upon the Insurer Suite’s Out of the Box configure ability; (ii) whether the Insurer Suite needed to be re-written and/or redeveloped to meet the Claimant’s functional requirements in the UK, including regulatory requirements; and (iii) if so, whether Innovation Group had the resources to re-write, develop and test the new software in the time scales required by the Claimant.

43A.      Had the Defendant made such inquiries and investigations, the Defendant would have realised that Innovation Group did not have a ‘UK-ready’ platform, particularly in relation to home insurance (Release 1), that the Insurer Suite could not meet the Claimant’s functional and regulatory requirements by configuring the Insurer Suite Out of the Box and that a very substantial re-write and/or redevelopment of the Insurer Suite was required (in which event, the Insurer Suite would no longer be a commercial-off- the-shelf product). Further, the Defendant would have known that the risks associated with a substantial re-write and or redevelopment of the core solution software were far greater than a solution based on a commercial-off-the-shelf product and that the Defendant would not or was unlikely to be able to meet its contractual obligations in the time scale contracted for (or anything close to the Key Milestones). Had the Claimant been informed of the true position in relation to the Insurer Suite, it would not have entered into the MSA.”

Whether Insurer Suite was written for the US market

“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.”

“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.”

“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.

Extent to which Insurer Suite re-written or developed

“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.”

“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.”

“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)…”

i)                    DLV001 - a schedule containing a brief description of the 551 requirements, including the key functional area for each requirement and whether the requirement would be met by the application to be provided as part of the IT solution;

ii)                  DLV004 - the interface inventory document, indicating whether each interface was external with a third party or internal with CISGIL, and whether it would be provided OOTB or custom built for CISGIL;

iii)                DLV-017 - claims management fit-gap assessment;

iv)                DLV019 - customer contact centre fit-gap assessment;

v)                  DLV020 - customer fit-gap assessment - policy administration;

vi)                DLV021 - customer fit-gap assessment - payment;

vii)              DLV023 - data and analytics fit-gap assessment;

viii)            DLV028 - finance fit-gap assessment;

ix)                DLV041 - claims fit-gap assessment - fraud;

x)                  DLV061 - customer fit-gap assessment - product.

i)                    Release 7.5 made available on 29 September 2015;

ii)                  Release 7.5.0.1 made available on 14 November 2015;

iii)                Base web service module made available on 26 November 2015;

iv)                Release 7.5.0.2 made available on 26 February 2016;

v)                  Release 7.5.1 made available on 15 June 2016;

vi)                Release 7.6 made available on 13 October 2016.

“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.”

“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.”

“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.”

Analysis of Insurer Suite Code

“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.”

i)                    there is no reliable evidence that Insurer Suite needed re-writing or redevelopment to meet CISGIL’s UK regulatory requirements beyond the level of configuration and customisation that was identified in the MSA;

ii)                  the total amount of CISGIL-specific added code was not substantially beyond what was estimated in the fit-gaps;

iii)                the base product code that was replaced or re-written for CISGIL was not substantial;

iv)                Insurer Suite was not substantially re-written or redeveloped, save as provided for in the MSA.

All reasonable steps

“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.”

i)                    the fit of the proposed Solution to the customer’s requirements;

ii)                  an estimate of the required time and effort required to meet those requirements;

iii)                an assessment of the subcontractor’s resourcing approach and availability; and

iv)                an assessment of the subcontractor’s implementation capabilities and methodology.

“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.”

“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…”

“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.  ”

“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.”

“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. ”

Consequences of any breach of warranty

“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.”

“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

i)                    Clause 12.1(c) of the MSA imposed on IBM an obligation to take all reasonable steps to ascertain the risks associated with implementing the project using Insurer Suite;

ii)                  IBM took all reasonable steps to ascertain the risks associated with Insurer Suite and did not misrepresent the nature and scope of the required development of the product;

iii)                Insurer Suite did not require substantial re-writing and development as alleged by CISGIL;

iv)                IBM was not in breach of the clause 12.1(c) warranty;

v)                  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

i)                    At the date of the MSA, Insurer Suite was not a UK-ready commercial off the shelf product which could be configured to meet CISGIL’s requirements OOTB because it required to be substantially re-written and/or re-developed.

ii)                  Under the MSA, IBM was responsible for the performance of its sub-contractor, IG, and therefore, was imputed with IG’s knowledge as to the matters in i) above.

iii)                By October/November 2015, it was clear to IBM that Insurer Suite would require significant base code development and IG did not have adequate resources to achieve the project milestones.

iv)                IBM failed to report to CISGIL as to the true state of the project.

v)                  If IBM had satisfied its reporting obligations, CISGIL would have terminated the MSA.

i)                    Insurer Suite did not require substantial re-writing or base development beyond the customisation and development set out in the MSA.

ii)                  The MSA did not attribute to IBM its sub-contractors’ knowledge for the purpose of IBM’s reporting obligations.

iii)                By October/November 2015, IBM was not aware that Insurer Suite had been written for the US insurance market not the UK market or that it had to be substantially re-written and/or redeveloped to meet CISGIL’s requirements.

iv)                In any event, CISGIL would not have terminated the MSA in 2015.

Reporting obligations

“The Supplier shall:

…

(h)         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).”

“The Supplier shall report on progress of the Implementation Services, in accordance with schedule 12 (Governance and Reporting).”

“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.”

Pleaded allegation

“… 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 commercial-off-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.   ”

Insurer Suite as at the date of the MSA

Knowledge attributable to IBM

Cards on table meeting

“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.   ”

“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.”

“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.”

“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.”

“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.”

“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.”

“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.”

Consequences if IBM reported difficulties

“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.”

i)                    Insurer Suite did not require substantial re-writing or base development beyond the customisation and development set out in the MSA.

ii)                  The MSA did not attribute to IBM its sub-contractors’ knowledge for the purpose of IBM’s reporting obligations.

iii)                By October/November 2015, IBM was not aware that Insurer Suite had been written for the US insurance market not the UK market or that it had to be substantially re-written and/or redeveloped to meet CISGIL’s requirements.

iv)                In any event, CISGIL would not have terminated the MSA in 2015 or by February 2016.

Issue 4 - Delays and reporting failures

i)                    IMP-018c (Release 1 Build Complete: the release technology successfully built by Supplier and ready for testing) was due by 31 January 2016 but not achieved before 17 October 2016;

ii)                  IMP-021 (Release 1 Accepted: the Release has successfully completed all testing and is accepted by the Customer) was due at the end of March 2016 but not achieved;

iii)                by the date of termination, the following Release 2 milestones had not been achieved: IMP-023 (Release 2 Build Complete) due end May 2016, IMP-024 (Release 2 Accepted) due end July 2016, IMP-028 (Motor Data Bulk Migration Complete) due end October 2016 (wrongly pleaded as IMP-025) and IMP-026 (Release 2 Go Live) - due by 15 August 2016.

iv)                IBM failed to satisfy its project management and reporting obligations with sufficient accuracy so as to enable CISGIL to plan its expenditure on its own resources and third party contactors with reasonable efficiency.

v)                  CISGIL would have terminated the contract early had IBM not breached its reporting obligations.

i)                    Although the Release 1 acceptance milestone IMP-021 and the Release 2 milestones beyond IMP-016 were not achieved by the date of termination, all Release 1 Insurer Suite functionality and much of the Release 2 Insurer Suite functionality had been built.

ii)                  The delays to IMP-018c were caused by CISGIL’s failures, namely, slow decision making, deferral of backlog functionality to later sprints and failure to generate user stories at the planned rate to maintain progress of the sprints; late delivery of CISGIL’s detailed requirements and business information for the revised Release 1 timetable, resulting in deferral of functionality to later drops; and numerous disruptive change requests.

iii)                The delays to IMP-021 were caused by CISGIL’s failure to conduct UAT timeously and/or competently: testing scripts were late, on 4 May 2016 UAT was suspended without justification, there were disputes as to the scope of IBM’s delivery obligations and CISGIL incorrectly raised defects.

iv)                The delays to the Release 2 milestones were caused by CISGIL’s failure to deliver its detailed requirements and business information in accordance with the agreed timetables, revisions to the Release 2 delivery plan and disruption caused by the Release 1 delays.

v)                  IBM was not in breach of its project management and reporting obligations and, in any event, CISGIL would not have terminated early.

IBM’s obligation to achieve the Milestone Dates

“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.”

“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.”

“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.”

“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).”

“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.”

“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. ”

i)                    In relation to critical delay to the project (a) prior to 12 May 2017 and (b) thereafter:

a)                  what were the factors that prevented IBM from achieving Milestone IMP- 18c by its due date and which caused critical delays before and after that date, when was that Milestone actually achieved, who caused the delays, how and to what extent?

b)                 what were the factors that prevented IBM from achieving Milestone IMP- 21 by its due date and which caused critical delays before and after that date, who caused the delays, how and to what extent?

c)                  what were the factors that prevented IBM from achieving any of the Release 2 Milestones (save for IMP-016) prior to termination of the MSA, who caused the critical delays, how and to what extent and/or with what consequences?

ii)                  Did IBM manage the programme and/or report on the actual and probable future progress of the implementation of the Solution with reasonable accuracy, what did IBM do, and what were the consequences of what IBM did or failed to do?

i)                    examination in detail of the documentary records that enabled her to establish progress of the project up to achievement of each relevant milestone;

ii)                  compilation of schedules of the relevant release notes, functionality drop notes, change requests, notifications of delay, testing and defect records;

iii)                preparation of summary tables of the key information extracted from the schedules;

iv)                consideration of the allegations of delay made by the parties against those analyses;

v)                  conclusions drawn as to the causes of critical delay.

“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 ...”

“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.”

Milestone IMP-018c

i)                    the pricing and rating engine functionality for sales and service was delivered by June 2016;

ii)                  most of the claims functionality was delivered in drops 1, 2 and 3 as planned but thereafter outstanding items were delivered piecemeal through until June 2016;

iii)                delivery of documents into SIT was not achieved until July 2016;

iv)                Quote & Buy Portal and Home Supplier Portal functionality was delivered by June 2016;

v)                  Customer Portal functionality continued to be delivered until August 2016 and contained limited functionality;

vi)                Interfaces functionality was not delivered until May 2016;

vii)              data and analytics functionality, and TDS, were delivered in March 2016.

i)                    With the exception of Claims, IG did not have the base functionality for Insurer Suite required for the project in place at the date of the MSA. The amount of development work required to the base functionality in the period after the MSA was substantially more than anticipated.

ii)                  IG did not have sufficient resource to perform the Release 1 customisation and configuration work identified in the fit-gaps. This issue was exacerbated by IG’s decision to deliver some OOTB functionality as customisation.

iii)                The configuration and customisation work done by IG was of poor quality so that the resulting system suffered from a large number of defects that IG were slow to resolve. This meant that SIT took substantially longer than planned.

“…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 ...”

“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 …”

“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.”

“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.”

“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 …”

“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.”

“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.”

“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.”

Milestone IMP-021

i)                    Severity 1 - critical - the defect results in the failure of a business critical part of the deliverable and there is no work around. Reviews/ testing cannot proceed and, in a live environment, this defect would have a critical impact on the operation of the business;

ii)                  Severity 2 - major - either the defect results in the failure of a business critical part of the deliverable and there is a possible work around or a significant portion of the deliverable is not operational and, in a live environment, this defect would have a major impact on the operation of the business; although the functionality is not business critical, the system will not be accepted by the business with this fault;  

iii)                Severity 3 - serious - either a defect in a business critical function with minor consequences or a significant defect in a non-critical part of the deliverable; the system could be released into the business with agreed work arounds;

iv)                Severity 4 - minor - this is a fault which is at variance to the specification / requirements, but has minimal impact e.g. an incorrect font on a report or a spelling mistake; the defect could be accepted providing it was corrected in a subsequent release;

v)                  Severity 5 - exception -  This is functionality which is found to be within specification but either on seeing the delivered result could have been specified better or having tested the system this improvement would significantly increase system usability.

i)                    Priority 1 - critical - the defect has resulted in the halting of all testing, no work around is available and no further testing whatsoever can be performed until it is resolved;

ii)                  Priority 2 - high - the defect has resulted in the halting of one or more streams of testing, no work around is available but some testing can continue to be performed;

iii)                Priority 3 - medium - the defect has resulted in the halting of one or more streams of testing; a work around is available and some testing can continue to be performed;

iv)                Priority 4 - low - this is an isolated defect that has no impact on any stream of testing but it will still prevent completion of the test schedule; there may or may not be a work around;

v)                  Priority 5 - cosmetic - this is an isolated defect that has no impact on any stream of testing and will not prevent completion of the test schedule; there may or may not be a work around.    

i)                    Severity 1 - critical - defect severely impacts the test schedule, It is referred to as a ‘show stopper’ suggesting that no testing can continue until the defect is fixed or resolved; a resolution is urgently required to avoid further delays, for example testers cannot log onto system or the environment is unavailable;

ii)                  Severity 2 - high - defect impacts major functionality and stops items such as multiple test scripts, requirements or designs under test from being progressed; testing of such functionality cannot continue until the defect is fixed and there is no work around or it is cumbersome and time consuming;

iii)                Severity 3 - medium - defect has impacted on test schedules; testing can continue but will not be completed until the defect is resolved; defects that affect limited areas of functionality that can be worked around for a short period;

iv)                Severity 4 - low - defect has minimal or no impact on testing; a fix may not be required prior to the closure of testing and could possibly be scheduled into the next available release depending on the circumstances.

The notes above the severity table stated:

“Severity is set by the defect creator and can be subject to change in subsequent review processes. The severity of the defect should not be changed by any user outside of the originating test team or defect manager unless agreed in the daily defect meeting. ”

i)                    more than 25% of the time is being spent raising defects rather than testing;

ii)                  a "Showstopper Defect";

iii)                a large number of minor errors;

iv)                the test environment became unavailable for an extended period of minimum 8 hours, or for short durations of 2 hours on regular intervals;

v)                  major change requests raised that need requirements or the architecture to be changed, and significant areas of testing need to be re-planned as a result;

vi)                poor data quality and integrity.

“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.”

“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 …”

“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.”

“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.”

i)                    the number of defects found in UAT was substantially more than expected and predicted by IBM; and

ii)                  IG’s progress in fixing these defects was slow and did not accelerate as predicted by IBM.

Release 2 milestones

i)                    IMP-023 (Release 2 Build Complete) - the release technology successfully built by Supplier and ready for test - due end May 2016;

ii)                  IMP-024 (Release 2 Accepted) - the release has successfully completed all testing and is accepted by the Customer - due end July 2016;

iii)                IMP-026 (Release 2 Go Live) - the release is fully implemented and in live use by Customer and under warranty - due by 15 August 2016; and

iv)                IMP-028 (Motor Data Bulk Migration Complete) - bulk transfer of legacy Motor data from COM to NOM achieved - due end October 2016 [wrongly pleaded as IMP-025, Home Data Bulk Migration Complete, which related to Release 1].

“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.”

“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.”

“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.”

i)                    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, and IG failed to deliver the basic motor functionality until October 2016.

ii)                  IG implemented Release 2 on a different version of Insurer Suite (Release 7.6) to Release 1 which meant that substantial extra work was required to retro-fit fixes from Release 1 into Release 2.

Reporting of delays

i)                    the original Release 1 Go Live date of 30 April 2016 was not met; nor was the informal revised date of 30 May 2016;

ii)                  on 19 April 2016 a revised Release 1 Go Live date was proposed by IBM of June-August 2016;

iii)                on 16 May 2016 IBM presented a revised plan showing Release 1 Go Live by end August 2016 and a new Release 1.1 by end October 2016;

iv)                on 25 January 2017 IBM produced a revised plan showing a Release 1 Go Live date for plus aggregators of 26 June 2017;

v)                  the original Release 2 Go Live date of end August 2016 was not met;

vi)                on 6 June 2016 IBM presented a revised plan for Release 2 Go Live by 30 January 2017 and Release 2.1 by 24 April 2017;

vii)              on 22nd September 2016 IBM indicated ‘go live’ dates for Release 2.0 of 30 June 2017 and Release 2.1 of 1 December 2017;

viii)            on 31 January 2017 IBM's revised plan indicated ‘go live’ dates for Release 2.0 of 16 October 2017 and Release 2.1 of 16 April 2018;

ix)                by letter dated 7 April 2017 IBM informed CIGIL that the anticipated ‘go live’ date for Release 2.0 was 10 September 2018 and for Release 2.1 was 11 March 2019 .   

Conclusions on delay and reporting

Issue 5 - Quantum

Contractual exclusion or limitation of liability

i)                    whether the claim for wasted expenditure is excluded by clause 23.3;

ii)                  whether the bond interest and transaction fees are excluded by clause 23.3;

iii)                whether the claim is subject to a contractual cap as set out in clauses 23.5(a) or 23.5(e).

Wasted expenditure claim

“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.”

“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.”

Legal principles 

“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.”

“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. ”

“ATOS’s submissions wrongly assume that any “contractual benefit” which is presumed to at least equal the value of the expenditure must represent profits, revenues or savings. In most commercial cases, there would be such a defined financial benefit that would be expected to defray the costs incurred and render the bargain financially viable. However, that is not the case where the contractual benefit is non-pecuniary. In those cases, the anticipated benefit is not a financial gain that could defray the costs incurred but rather a non-pecuniary benefit for which the claimant is prepared to incur such costs. In cases where a party does not expect to make a financial gain, it is the non-pecuniary “benefit” that is assigned a notional value equivalent to at least the amount of expenditure.”

The Bond interest and transactional fees

“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.”

Contractual caps

“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.”

Quantum of wasted expenditure claim

i)                    Each and every cost item within CISGIL’s claim does not need to be individually verified; a sampling approach to the verification of CISGIL’s claimed costs is appropriate;

ii)                  CISGIL’s Programme Ledger is a starting point for assessing the quantum of CISGIL’s claims. 

iii)                CISGIL incurred £34.1 million of the costs recorded on the Programme Ledger by way of payments to IBM.

iv)                The other third party costs recorded on the Programme Ledger were properly included as a matter of accounting principle and CISGIL incurred those costs.

v)                  The bond transaction fees of £2.4 million related to work concerning the subordinated debt and were paid.

vi)                Mr Eastwood's method of calculating the deduction for VAT was reasonable for the purposes of the claim and there was no reason to question CISGIL’s VAT accounting.

“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.”

“… 48 consultants have been brought in via the MSA and an additional 22 S&A contractors have been brought in via the Rullion contract. Our review found that a number of S&A contractors have been brought in to [CISGIL] using the Rullion contingent labour agreement as nominated workers, whereby individual contractors have been pre-selected to join the TIC division without being subject to any form of competition …

A series of factors are combining to produce an operational environment with inadequate controls design and a series of operating effectiveness failures. These factors include:

…

-       An over reliance on S&A contractors and consultants;

-       An inability to fulfil the role of intelligent client whereby [CISGIL] has a capability within the business to know in more detail what S&A are doing…

-       the absence of a clear performance monitoring framework …

…

There is a risk that S&A consultants or contractors use their position to bring individuals into the business that do not have the required level of skill or experience for a role.

There is a risk of resource is being brought into the business when there is no clear need.

There is a risk that there is not an adequate return on investment for new or extended consultancy roles.

There is a risk that a new/extended requirement is approved without the preceding approvals being in place.

…

There is an inherent direct conflict of interest in the CIO’s position as a senior executive of [CISGIL] and his position as a director and shareholder of S&A which can lead to personal gain.

… [CISGIL] is unable to validate the accuracy of invoices using an independent record of consultancy days worked and / or S&A overcharge [CISGIL] for consultancy time and the business has no way of independently identifying the overstatement.”

Claim for delay and reporting failures

i)                    The costs of the delay claim are based upon amounts included within the unlawful termination claim.

ii)                   The basis of delay attribution is an area outside both experts’ expertise.

iii)                Mr Eastwood's assessment is based on CISGIL’s case that IBM was the cause of the delays. 

NOM Resource

COM Exit

Property Costs

Testing Resource from SQS and Test Direct

Sopra Steria data migration resource and architect resource

Experian and GSX

Accenture

Assurance by PwC and PA Consulting

IMP-018 Milestone

IBM additional work

Dual run resource

Bottomline contract

Management expenses and secondees

IBM’s counterclaim

Conclusions

i)                    IBM was not entitled to exercise its termination rights under the MSA by reason of CISGIL’s failure to pay the AG5 invoice;

ii)                  IBM’s purported termination amounted to repudiatory breach which CISGIL accepted;

iii)                IBM wrongful termination did not constitute wilful default for the purpose of clause 23.5 of the MSA;

iv)                CISGIL’s claim for breach of the warranty in clause 12.1(c) of the MSA is dismissed;

v)                  CISGIL’s claim for IBM’s failure to report on the true state of the project is dismissed;

vi)                IBM was in breach of the MSA for delays to milestones IMP-018c, IMP-021 and the Release 2 milestones;

vii)              IBM was in breach of its reporting obligations in respect of the delays to the project;

viii)            CISGIL’s claims for wasted expenditure are excluded by clause 23.3 of the MSA;

ix)                CISGIL is entitled to £15,887,990 (subject to any applicable VAT reduction) in respect of additional costs incurred as a result of IBM’s breaches of contract;

x)                  IBM is entitled to set-off against CISGIL’s claims the sum of £2,889,600;

xi)                CISGIL is entitled to interest on the net sum of £12,998,390 (subject to any applicable VAT reduction).