Capita Business Services Limited v IBM United Kingdom Limited

The Agreement runs to approximately 450 pages, beginning with a relatively short section of “main clauses”, which are then supplemented by a series of very detailed schedules. Clause 1.4 sets out the hierarchy of the various documents making up the Agreement, with the main clauses and the definitions in Schedule 1 appearing at the top, then Schedule 21 (addressing the IT Upgrade Programme), then Schedule 2 (with which this hearing is concerned) and then various other named schedules, with “the remaining schedules” at the end.

Clause 3.1 provides that “Capita appoints the Contractor to provide the Services in accordance with the terms of this Agreement”.

Clause 4.5 provides:

Clause 5.1 provides:

Clause 5.3 addressed the position where IBM failed to meet “any of its obligations under Schedule 2”, including a right on IBM’s part for an entitlement to apply for relief from the consequences of such failure (referred to as a “Relief Event Application”). Such relief can be obtained where the failure results from the fact that the relevant product was not “In Support”, or had a “Known Limitation”. If a Relief Event Application is justifiably and appropriately made, “Capita’s approval of the Relief Event Application at the next Commercial Meeting shall not be unreasonably withheld or delayed.” However, the clause does not relieve IBM “from its Managed Service obligations, as more particularly described in Schedule 2 (Managed Service), which the Parties acknowledge and agree apply to both the End of Support products and those elements of the System with Known Limitations throughout the Term.” As a result:

Clause 5.3.5 provides:

Clause 5.4 provides that “in providing the Services”, IBM shall “do nothing which damages Capita’s business interests, reputation or goodwill with the [client] or the reputation or goodwill of the [client] …” and “use its best endeavours to make sure that nothing is done by it, its Employees, permitted agents or permitted subcontractors in the provision of the Services or otherwise which prevents or hinders Capita from performing its obligations to the [client under the Head Contract].”

Clause 32.1 provided that “on and from the Commencement Date the Contractor shall provide the Services in accordance with the Service Architecture.”

Clause 34.1 obliges IBM to indemnify Capita and the client in relation to “any and all Losses … in consequence of” breach by IBM of its obligations as to various matters, including data protection, compliance with the law, security requirements and compliance with the standards and policies of Capita and the client.

Clause 38.8 provides:

Clause 39 addressed IBM’s exit from the Agreement, requiring it “to provide the Services on an interim basis after the Term until such time as a Successor Service Provider has been appointed, so as to ensure a Smooth Transfer (and in such circumstances the terms of this Agreement shall remain in full force and effect during any such period in which the Contractor is continuing to provide the Services, which for the avoidance of doubt shall include Capita continuing to pay the Charges).” On expiry or termination, Capita is obliged to pay “Contractor’s Breakage Costs” as set out in Schedule 5 and IBM is required to return all items and property belonging to Capita.

IBM’s obligations in this regard were set out at greater length in Schedule 11. It was envisaged that IBM would submit a “Draft Exit Plan” no later than 3 months after the Commencement Date. This was defined by reference to paragraph 1.2 of Schedule 2, where the Commencement Date is “the point at which application support was migrated from the Incumbent by the Contractor to its own control”. This was, therefore, a date early in the life of the initial term of the Agreement (the expression “Extension Commencement Date” is used to refer to 2022). The Draft Exit Plan was to be approved by Capita, or amended to reflect Capita’s reasonable requirements, and updated annually. The implementation of the (agreed) Exit Plan follows the Exit Start Date, being either (i) the date when Capita gives notice to terminate the Agreement or (ii) 18 months prior to the expiry of the Agreement. The “Smooth Transfer” provisions gave Capita various rights intended to ensure continuity of service, including (at paragraph 13.1)

Clause 54 provided that “without prejudice to Clause 39, and as a separate and independent obligation, the Contractor shall do all such things, and provide all reasonable assistance to Capita, to enable Capita to fully comply with its obligations under Schedule 11 (Exit) to the [Head Contract].”

As is frequently the case in long term IT contracts, the parties anticipated that it might be necessary to adjust the scope of the contractual services and/or the terms and conditions during the Agreement’s life, and made provision for this through a “Change Control Procedure.” As this procedure is referred to in a number of the contractual provisions which are central to the dispute, I will summarise it now.

The Change Control Procedure is set out in Schedule 7 to the Agreement. The procedure distinguishes between changes requested by Capita, and those requested by IBM. IBM is not “entitled to unreasonably refuse” a change request made by Capita (Schedule 7, paragraph 3.2 and clause 24.2), but there is no equivalent provision for changes requested by IBM. Where the implementation of a change requires an increase in the Charges payable to IBM, “such increase shall in all cases be fair and reasonable in accordance with Best Industry Practice” (clause 24.5). An agreed set of daily rates is to be used when calculating the cost of any Change (Schedule 5 paragraph 7), but if the estimated cost of the Change exceeds £100,000, IBM can present a Fixed Price.

Paragraph 3.4 of Schedule 7 provides for the preparation of an “Impact Assessment” when a Change is requested. This is a written assessment by IBM of “the impact of the proposed Change” including “any anticipated impact on the Contractor's charges in the provision of the Services” and “any impact on the level of Charges.”

Condition 2 is to be found in Schedule 2, Annex 2 to the Agreement. Schedule 2 deals with the important concept of Managed Service, first introduced by clause 5.1 of the Agreement.

Schedule 2 paragraph 1.1 provides that it sets out “the Managed Service that the Contractor shall deliver throughout the Term.”

Paragraph 1.3 provides that the Managed Service “must be resilient, secure and flexible”, paragraph 2 that the Managed Service must meet various standards, service levels, regulations and policies.

Paragraph 4.14 provides:

Paragraph 5.1 provides:

Paragraph 5.2 provides for IBM to “perform software version upgrades as required to ensure the applications remain in support in accordance with Annex 2”. Paragraph 5.4 then provides:

Paragraph 5.4 provides:

Paragraph 5.17 provides:

Paragraph 5.28 sets out the specifications for the Managed Services in respect of the Relevant Service. These include requirements as to the security of the Relevant Service, and an obligation to update it “in a manner consistent with the Law”. It is supplemented by clauses 5.1 to 5.14, which set out the obligations generally applicable to application support, maintenance and management. It is not in dispute that the language used had the effect of obliging IBM to support the Relevant Service in the period up to 30 August 2023.

Annex 2 to Schedule 2 “provides details of all the software products include in the Services, including the version numbers and Support Status of each version (in accordance with the key below), from the Commencement Date and on completion of the IT Upgrade Programme.” There is a threefold classification of “Support Status”: 1 in the product is “in support”, 2 if it is in “extended support” and 3 if it has reached “End of Support” (defined as “the relevant item is not in Support”).

Table A in Annex 2 is headed “Support Status at Extension Commencement Date” and defines “the support state of the included Software as of the Extension Date” (i.e. 2022). There are ten columns: the application; the application version; the support status of that application (“SS”); the operating system; the SS of the operating system; the database; the SS of the database; the Middleware; the SS of the Middleware; the Underlying Hardware and the SS of the Underlying Hardware.

One of the applications is “[the Relevant Service].” Within this application:

Table B is headed “Support Status after completion of the IT Upgrade Programme”, and sets out “the Support Status of each of the included products at the completion of the IT Upgrade Programme, and whether a Major Upgrade will be required for each product” by reference to the following column headings:

For a number of those products, the words “N/A Decommissioned” appear. In all cases save for “[the Relevant Service]”, the row for those products which are expected to be decommissioned cross-refer (under the column “Target Date of Upgrade”) to “Condition 1 below with date of 30 June 2023” (in one case, “with date of 31 December 2022” and in one case “N/a – decommissioned pre-Extension Commencement Date”).

In a contract of the length of the Agreement, it is those provisions which are closest to Condition 2, both in terms of where they appear in the Agreement, and in the similarity of the purpose they are intended to serve, which have the greatest explanatory power when ascertaining the meaning of the term in dispute. Conditions 1, 2 and 3 in Annex 2 of Schedule 2 are all referred to in, and set out consecutively after, Table B. Each addresses and expands on the position where Table B assumes that applications which were supported in 2022 will no longer be in operation. They were all introduced at the same time (in 2022). For that reason, I have found Conditions 1 and 3 particularly helpful in ascertaining the meaning of Condition 2.

Condition 1 provides:

It will be noted that Condition 1 is concerned with Capita’s intention. It makes express provision for what is to happen if the decommissioning of the existing system is not completed by the specified date, with the cost consequences of that decision subject to revision through the Change Control Procedure. The implications of the provision are that the current terms of the Agreement assume that the decommissioning will be effected by the specified date, requiring an adjustment to the terms if this does not happen. There is no provision for IBM’s support to cease, whether or not the relevant decommissioning takes place on a timely basis or at all.

There is a single entry for “[the Relevant Service]” in Table B which states:

To repeat the terms of Condition 2:

Condition 2, unlike Condition 1, refers to the fact that the decision to commission the relevant work is that of a third party, the client, not Capita. Unlike Condition 1, it makes no provision for what is to happen if the relevant work is not commissioned, or commissioned later than the specified date. It is the adjusted service – supporting the replacement Relevant Service – which triggers the application of the Change Control Procedure. Finally, in contrast to Condition 1, there is provision for IBM’s support of the application to cease.

Finally, for six applications, the “Target Date of Upgrade” column states “Subject to Condition 3 below.” Condition 3 provides:

Condition 3 addresses the position both where RFC 4407 is agreed but cannot be achieved by the anticipated date, and where RFC 4407 is not agreed. In both these cases, Condition 3 provides for the application of the Change Control Procedure to any “additional project … and/or incremental charges to … support” the existing systems prior to their replacement or if no replacement takes place.

Many of the terms in the Agreement are replicated in the Sub-Contract, including Condition 2. No party suggested that Condition 2 had a different meaning in the Sub-Contract from the meaning it had in the Agreement.

Mr Howells KC attempted to derive support for his argument as to the construction of Condition 2 of the Agreement from provisions in the Sub-Contract, even though it was accepted that Capita had not seen the Sub-Contract prior to these proceedings. I was not persuaded that this formed part of the admissible factual matrix.

In any event, the document in question does not assist. It addresses the scope of work for the replacement of the Relevant Service, but as Mr Howells KC acknowledged, it would only have effect if the client commissioned a new Relevant Service and Capita retained IBM to deliver that. It does not assist in ascertaining the position where no such Relevant Service is commissioned. That eventuality was addressed in the Sub-Contract, as it was in the Agreement, by Condition 2.

Both sides sought to bolster their arguments on construction by reference to the pricing adopted in the Agreement, an approach which led to the deployment of commercially sensitive pricing information at the hearing, and necessary derogations from the principle of open justice to preserve that confidentiality.

IBM sent an excel spreadsheet to Capita with its proposed pricing in January 2022, in the form of a spreadsheet referred to as the “Five year detailed price book”. This document recorded IBM’s total proposed charges over the 5 years of the Agreement, broken down between “Ongoing Charges (Managed Service)” and “IT Upgrade Charges” and further broken down within those headings. There was a charge for each of the 60 months of the Agreement, which was the aggregate of the price for that month of the following items:

The price for many of these individual line items did not change between August and September 2023, albeit there were small changes in the figures for Cloud Server & Storage Management (upwards), Base Service Charge (a minimal upwards increase), Database and Middleware (downwards) and Network (a minimal upwards increase). The net effect of these changes was that the total monthly charge in September was some £5,000 higher than the previous month, albeit £17,000 lower than that for July 2023.

Those matters are relied upon by Capita in support of its construction, its contention being that if IBM’s obligation to support the Relevant Service had ceased on 30 August 2023, a fall in the price charged would be expected. However, I have not found the prices quoted by IBM for each month particularly enlightening. The basis on which IBM’s pricing was arrived at is opaque (indeed this has been a persistent complaint of Capita). It is the evidence of IBM that the prices charged reflected many variables and was in part the product of negotiations, albeit he does point to an overall reduction in pricing between 30 August 2023 and June 2024, the date by which it was anticipated that the IT Update Programme and decommissioning of applications was anticipated to be complete. On any view, this was not a “pass through” contract in which IBM was entitled to a fixed level of costs plus overhead, still less could it reasonably be assumed that the dates when individual elements making up total costs anticipated over the 5 years of the second extension period would map perfectly to the price charged for the month in which they were incurred (as opposed to there being some “smoothing” of the total cost over the life of the Agreement).

For largely the same reasons, I do not feel able to draw any conclusion from the overall movement of price between 30 August 2023 and June 2024. This may have reflected a number of factors, including the effect of the IT Update Programme but not the anticipated replacement of the Relevant Service, or IBM’s readiness to work on the basis that it would benefit from a replacement Relevant Service, even if the services it had to provide were not conditional upon a replacement Relevant Service becoming operational during the life of the Agreement.

Inevitably, both Capita and IBM contended that their interpretation of Condition 2 was plain and clear on the language of the clause.

So far as Capita’s arguments based on the language of Condition 2 are concerned:

Turning to IBM’s arguments:

Looking at the competing arguments on the meaning of Condition 2 by reference solely to the terms of the clause, I am satisfied that the wording of the clause is significantly more consistent with IBM’s suggested interpretation than with Capita’s.

Capita relies on the fact that Condition 2 is first introduced in a column headed “Target Date of Upgrade”, and relies on this to suggest that the date of 30 August 2023 in the second sentence of Condition 2 is aspirational, and therefore unlikely to be a date when IBM can cease to provide what, up to that point, has formed part of the Managed Service.

However, while Condition 2 first appears in a column with that heading, its clear purpose is to add matters of contractual significance and which go beyond a descriptive entry in a table. It is for that reason that Condition 2 (like Conditions 1 and 3), when it appears in a table, is a cross-reference to a detailed provision below, the importance of which is signalled by the use of avowedly contractual language (“Condition”) to describe it.

By contrast, there is real force in IBM’s argument that its construction of Condition 2 is strongly supported by its immediate contractual context, Conditions 1 and 3:

Capita relies on clauses 4.5 and 5 of the main terms, and paragraphs 5.1 to 5.14 and 5.28 of Schedule 2. It is accepted that in the period up to 30 August 2023, the effect of those provisions is to oblige IBM to support the Relevant Service. Capita contends that, in the absence of any contractual provisions which expressly limit or curtail the ambit of the obligations in the period after 30 August 2023, it must follow that those clauses continue to oblige IBM to support the Relevant Service after that date. However:

Capita also relies on the provisions intended to ensure a “Smooth Transfer” following IBM’s exit from the Agreement, and argues that these show that the parties cannot have intended that IBM could suddenly cease supporting the Relevant Service on 31 August 2023. Capita did not challenge IBM’s position that these clauses would apply on IBM’s construction of Condition 2, but contended that the parties would have re-visited the terms of Schedule 11 to make them more appropriate for application in this context if Condition 2 was intended to have the effect for which IBM contend.

The Smooth Transfer provisions have appeared in the Agreement from its inception in 2016. They contain numerous provisions referring to the possibility of a partial cessation. Thus:

There are provisions in Schedule 11 whose application to a cessation of the kind under discussion is not without difficulty (in particular the definition of Exit Start Date). However, the parties appear to have been content to let Schedule 11 operate by reference to its original terms, notwithstanding the extensive alterations made to the Agreement in the 2022 extension – for example it still referred to the production of a Draft Exit Plan “not later than 3 months” after the date when IBM took over application support from the previous incumbent, which would have been back in 2016, albeit that was to be refreshed annually. I am not persuaded that the parties’ failure to re-visit the terms of Schedule 11 assists in the construction of Condition 2 (particularly when both parties accept it continues to apply, whichever construction of Condition 2 is adopted).

Finally, Mr Kitchener KC placed reliance on a “High Level Plan” which appears in Annex 2 to Schedule 21, and which shows certain hardware (x 86 hardware and Sparc Hardware) and two data centres being phased out by mid-2024. IBM has adduced unchallenged evidence from the Contracts and Commercial Lead for IBM’s support of the Agreement, that this hardware (or equivalent) would be needed if the Relevant Service was to remain in operation, and data centres would be required to service it.

I accept that this provides some support for IBM’s construction – at least to the extent that if IBM had undertaken a potential 5-year commitment to support the Relevant Service while signing up to a project plan under which hardware and premises currently supporting that system were to be phased out within just over 2 years, it is surprising that there are no contractual terms addressing what would have been a very significant issue. However, I am only able to place limited weight on this factor, because of the obvious opacity of the material relied upon, and the fact that the failure to address this scenario may have reflected a high level of confidence that it would not come to pass.

Finally, both parties sought to support their arguments by reference to considerations of business common sense. The limits of arguments of this kind are noted in Arnold v Britton [2015] AC 1619, [19]-[20]. In this case, the language and contractual context of Condition 2 clearly support IBM’s construction, and any appeal to the allegedly uncommercial consequences of that construction would have to be particularly compelling before it could begin to move the dial.

I have already explained (at [66]-[70] above) why I have not found the appeals made (by both parties) to the pricing of the Agreement of any real assistance.

Capita also contends that any construction which permitted IBM to stop support for the Relevant Service on 31 August 2023, even if no replacement system was operational, would be wholly uncommercial, because of the hugely adverse consequences which would follow, reputationally and financially, to the client and Capita if this were to occur. There are a number of reasons why I have not found this consideration of particular assistance in the construction of Condition 2:

For its part, IBM contends that any construction which required it to continue to maintain the Relevant Service after 30 August if an event wholly outside its control (the failure to commission a functioning Relevant Service by that date) came to pass would defy business common sense, because of what is said to be highly onerous and risky nature of the task. Given my clear conclusions on the effect of the language of Condition 2, and its contractual context, IBM does not need to bolster its position by reference to arguments of commercial common sense. In any event, I would not have felt able to place any significant weight on this factor:

For these reasons, Capita’s application for the declarations it seeks is refused and IBM’s contingent application for equivalent declarations against Kyndryl does not arise.