Before :
MR JUSTICE FOXTON
Between :
CAPITA BUSINESS SERVICES LIMITED | Claimant |
– and – IBM UNITED KINGDOM LIMITED – and – KYNDRYL UK LIMITED | Defendant/ Part 20 Claimant Part 20 Defendant |
James Howells KC (instructed by) (instructed by Dentons UK and Middle East LLP) for the Claimant
Neil Kitchener KC and Owain Draper (instructed by Womble Bond Dickinson (UK) LLP) for the Defendant
Patrick Clarke (instructed by Stewarts) for the Part 20 Defendant
Hearing dates: 10 and 11 October 2023
Draft Judgment Circulated: 12 October 2023
Approved Judgment
I direct that no official shorthand note shall be taken of this Judgment and that copies of this version as handed down may be treated as authentic.
.............................
THE HONOURABLE MR JUSTICE FOXTON
This judgment was handed down by the judge remotely by circulation to the parties’ representatives by email and release to The National Archives. The date and time for hand-down is deemed to be Friday 20 October 2023 at 10:00am.
The Honourable Mr Justice Foxton:
INTRODUCTION
In this Part 8 Claim, the Claimant (“Capita”) seeks declarations as to the true meaning and effect of the Restated and Amended IBM Agreement (“the Agreement”) between Capita and IBM United Kingdom Limited (“IBM”). IBM has raised the same issues in relation to its sub-contract (“the Sub-Contract”) with Kyndryl UK Limited (“Kyndryl”).
The dispute is as to the proper interpretation of Condition 2 to Table B in Annex 2 to Schedule 2 of the Agreement (“Condition 2”). This provides (separating the constituent sentences out for ease of analysis):
“Capita is awaiting the [client] to commission work to replace the [Relevant Service], and contract for the ongoing Managed Service of such, and it is assumed that this replacement [Relevant Service] will be operational on or before 30 August 2023.
As such the Contractor’s obligations for the Managed Services relating to the current [Relevant Service] shall cease at that time.
Further, any requirement for the Contractor to design and/or build and/or implement such a replacement [Relevant Service], and/or to operate such replacement [Relevant Service], shall be handled pursuant to the Change Control Procedure and at Capita’s expense, whether the impact is against the Managed Service, or the IT Upgrade Programme, or other work commissioned by Capita, or a combination thereof.”
The issue between the parties, in short, is whether IBM’s “obligations for the Managed Services relating to the current [Relevant Service]” cease when any replacement service becomes operational, or on 30 August 2023, even if (as has proved to be the case) the replacement [Relevant Service] is not operational by that date.
It is a rare dispute as to the construction of a contract where one or both parties do not make some appeal to matters of factual matrix to support their construction. In this case, there has been extensive reference to material of this kind, with much of the evidence and argument directed to it. That has made this judgment longer than might be expected for a decision resolving a dispute as to the meaning of three words.
THE BACKGROUND
Capita provides services under a contract between Capita and the client¸ first entered into in 2011, and amended on a number of occasions (“the Head Contract”).
The services provided by Capita under the Head Contract include IT-related services and business applications. Since 2016, Capita has sub-contracted these services to IBM under the Agreement. The Agreement’s original term extended to 2020, and it was extended to 2022.
The services which IBM agreed to perform include services for the provision of "the Relevant Service".
The Relevant Service operates across a number of operating systems and involves middleware and various applications.
During 2020, Capita and the client commenced negotiations about a second extension to the term of the Head Contract to 2027. In parallel, but by way of a separate and distinct negotiating channel, Capita also began negotiations with IBM about a similar extension to the Agreement. An issue which loomed large in both sets of negotiations was the Relevant Service:
On 25 November 2019, IBM had written to Capita, referring to “[issues with the services under the Agreement],” including the Relevant Service.
On 1 May 2020, IBM wrote to Capita repeating those concerns.
IBM also relied upon a third-party assessment of the Relevant Service published in 2020.
It is common ground that IBM expressed concerns about the Relevant Service during the negotiations for the extension of the Agreement.
As a result, the discussions for extending the Head Contract and the Agreement both addressed the issue of an upgrade to the client's existing IT. However, while the respective parties (the client and Capita, Capita and IBM) were able to reach agreement about the hardware and software upgrades (“the IT Upgrade Programme”), and incorporate that agreement into the extended contracts, this was not the case for the Relevant Service, the commercial proposal put forward by IBM not proving acceptable to the other parties. As a result, the replacement of the Relevant Service was excluded from the scope of the IT Upgrade Programme, the parties agreeing to extend their respective agreements, and continue discussions regarding a replacement of the Relevant Service.
In 2021, IBM transferred that part of its business which was most closely involved with supporting the Head Contract (some 70% of the work, and 80% of the work in supporting the Relevant Service) to Kyndryl, an independent company. On 1 September, IBM entered into the Sub-Contract with Kyndryl, which ran until 2022. The negotiations for an extension of the Agreement between Capita and IBM occasioned negotiations between IBM and Kyndryl to extend the Sub-Contract.
I accept that, when the extension of the Agreement was in imminent contemplation, Capita expected that the client would commission a replacement to the Relevant Service within a relatively short period, and that the mutual expectation was that a replacement for the Relevant Service would be operational before 30 August 2023. It was in that context that Condition 2 emerged in the negotiations, having been drafted (on the evidence) by IBM.
More particularly, in 2022, IBM responded to a request by Capita that it explain the assumptions underlying the table that became Table B in Annex 2 to Schedule 2 by putting forward the language which, in substance, became Conditions 1, 2 and 3 of Annex 2 to Schedule 2, stating:
“I appreciate that the above wording is verbose, but it is an important caveat behind IBM’s solution and pricing”.
(As it happens, a little more verbosity might have been helpful).
In 2022, the client and Capita agreed to amend and extend the Head Contract, which runs until 2027. On the following day, Capita and IBM signed an extension to the Agreement, which also runs until 2027.
The position after the extensions to the Head Contract and the Agreement came into effect
Discussions between Capita and IBM in relation to the replacement of the Relevant Service continued after the Agreement had been extended. IBM’s position, during those negotiations, was that, in the absence of a variation agreed through the Change Control Procedure, if the Relevant Service had not been replaced by 31 August 2023, it had no contractual responsibility to operate it. Thus on 1 July 2022, IBM emailed Capita, referring to Condition 2, and stating:
“The impact of work not being commissioned in a timely fashion means that, per Condition 2 above, IBM will cease to … support the current [Relevant Service] on 1 September 2023. If ongoing … support is required, a request to extend the service is required pursuant to the Change Control Procedure, which should be provided by no later than 29 July 2022.”
For what it is worth (and the present orthodoxy under English law is “not much”: Sir Kim Lewison, The Interpretation of Contracts (7th) (“Lewison”), [3.183]-[3.189]), Capita’s response did not challenge that assertion, stating:
“Any change to [servicing] requirements will be managed via change control. We are not clear why any extension in the support required would require over a year’s notice. As set out above pricing to the [client] is being targeted for end of July and no decisions will be made until post that date.”
(the reference to “over a year’s notice” being a response to IBM’s statement that a Change Control request should be served by no later than 29 July 2022, but otherwise accepting maintenance of the Relevant Service after 31 August 2023 would involve an “extension” and would require a Change Control request by Capita).
IBM repeated its position on 8 September 2022, and again on 27 October 2022, and Capita did not challenge (or engage with) that assertion. IBM repeated its position yet once more, and in particularly clear terms, on 26 January 2023, stating it was not willing to support the Relevant Service after 31 August 2023. The first response from Capita appears to have come on 9 March 2023, when Capita’s legal department replied challenging IBM’s interpretation of Condition 2 that it had, in effect, an unfettered right to walk away from supporting the Relevant Service from 31 August 2023. However, Capita’s email appeared to acknowledge that the provision of support for the Relevant Service after 30 August 2023 would involve a variation to IBM’s contractual service, and trigger the Change Control Procedure, the email continuing:
“In relation to costs for IBM services from 30 August 2023, as required by the Agreement, we intend to submit a Change Request.”
IBM in turn challenged Capita’s position as set out in that email, but accepted Capita’s right to seek support from 31 August 2023 by invoking the Change Control Procedure.
Capita issued a Change Request for “pricing for continued support of the existing [Relevant Service] beyond August 2023 through to … 2027” on 3 April 2023. IBM provided its proposal on 16 July 2023. There were commercial negotiations between the parties, outside of the Change Control Procedure, for the provision of support services for the Relevant Service after 31 August 2023, but these did not result in a concluded agreement. Each side has criticised the approach adopted by the other in those negotiations, but those criticisms have no relevance to the issue before me, whatever relevance they might have if the Change Control Procedure had been invoked.
As at 31 August 2023 (and to date), the client has yet to commission a replacement to the Relevant Service, and the legal and commercial impasse between the parties remains unresolved. On 24 August 2023, Capita issued a Part 8 Claim Form seeking a declaration that IBM was obliged to maintain the Relevant Service after 30 August 2023, until the earlier of 2027 or a replacement of the Relevant Service is commissioned by the client and is ready for operation. Capita also sought interim injunctive relief, with a view to ensuring that IBM continued to support the Relevant Service until the meaning of the Agreement had been determined by the court.
In the event, the parties were able to agree that the dispute as to the meaning of Condition 2 would be resolved on an expedited basis, and the terms of a moratorium whereby IBM continued to support the Relevant Service in the interim (“the Moratorium”). The parties have agreed, as a term of that mortarium, that they will:
“work together in good faith to seek to agree terms for providing [the Relevant Service] (which may include the Smooth Transfer of the [Relevant Service] to a Capita nominated vendor) for a period of up to 12 weeks.”
THE APPLICABLE LEGAL PRINCIPLES
There was no disagreement between the parties as to the principles to be applied in interpreting the Agreement, both sides being content for the court to apply the principles set out by Lord Hodge in Wood v Capita Insurance Services Ltd [2017] AC 1173, [10]-[14]. Given the familiarity of those principles, I have not lengthened this judgment by setting them out.
It is also well-established that, when construing a contract, a specific provision will be given greater weight than a general provision, when the facts in issue fall within the scope of the specific provision (Lewison, [7.46]). Lewison cites a useful summary of the principle given in the Irish decision of Welch v Bowmaker (Ir) Ltd [1980] IR 251:
“The relevant rule of interpretation is that encapsulated in the maxim generalia specialibus non derogant. In plain English, when you find a particular situation dealt with in special terms, and later in the same document you find general words used which could be said to encompass and deal differently with that particular situation, the general words will not, in the absence of an indication of a definite intention to do so, be held to undermine or abrogate the effect of the special words which were used to deal with the particular situation. This is but a commonsense way of giving effect to the true or primary intention of the draftsman, for the general words will usually have been used in inadvertence of the fact that the particular situation has already been specially dealt with.”
Finally, there was evidence adduced by both Capita and IBM as to what they were seeking to achieve through Condition 2. I was not persuaded that this evidence was admissible (Arnold v Britton [2015] AC 1619, [15]), nor ultimately helpful. The commercial goals of each side in those negotiations are obvious – it suited Capita to be “back-to-back” with its obligations to the client under the Head Contract, and it suited IBM not to undertake a legal obligation to maintain the Relevant Service until 2027. The key issue, as always, is how far a party succeeded in realising its commercial goal through the wording of the Agreement, read in context. In Prenn v Simmonds [1971] 1 WLR 1381, 1384-85, Lord Wilberforce explained the position in terms which have yet to be improved upon, and which have a particular resonance to the construction dispute which arises in this case:
“The reason for not admitting evidence of these exchanges is not a technical one or even mainly one of convenience, (though the attempt to admit it did greatly prolong the case and add to its expense). It is simply that such evidence is unhelpful. By the nature of things, where negotiations are difficult, the parties' positions, with each passing letter, are changing and until the final agreement, though converging, still divergent. It is only the final document which records a consensus. If the previous documents use different expressions, how does construction of those expressions, itself a doubtful process, help on the construction of the contractual words? If the same expressions are used, nothing is gained by looking back: indeed, something may be lost since the relevant surrounding circumstances may be different. And at this stage there is no consensus of the parties to appeal to. It may be said that previous documents may be looked at to explain the aims of the parties. In a limited sense this is true: the commercial, or business object, of the transaction, objectively ascertained, may be a surrounding fact. Cardozo J. thought so in the Utica Bank case. And if it can be shown that one interpretation completely frustrates that object, to the extent of rendering the contract futile, that may be a strong argument for an alternative interpretation, if that can reasonably be found. But beyond that it may be difficult to go: it may be a matter of degree, or of judgment, how far one interpretation, or another, gives effect to a common intention: the parties, indeed, may be pursuing that intention with differing emphasis, and hoping to achieve it to an extent which may differ, and in different ways. The words used may, and often do, represent a formula which means different things to each side, yet may be accepted because that is the only way to get “agreement” and in the hope that disputes will not arise. The only course then can be to try to ascertain the “natural” meaning. Far more, and indeed totally, dangerous is it to admit evidence of one party's objective — even if this is known to the other party. However strongly pursued this may be, the other party may only be willing to give it partial recognition, and in a world of give and take, men often have to be satisfied with less than they want.”
THE AGREEMENT
The main terms
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:
“… [T]he Parties acknowledge and agree that Capita has further extended the [Head Contract] by a period of five years. Therefore, pursuant to clause 4.1 of this Agreement, the Parties agree that the term of this Agreement shall also be extended for an additional five-year period, commencing on the expiry of the Extended Period and terminating [in] 2027 (‘Second Extended Period’), subject to any earlier termination in accordance with this Agreement.”
Clause 5.1 provides:
“The Contractor shall perform the Services in accordance with Schedule 2 (Managed Service), Schedule 6 (Service Level Agreement), and Schedule 18 (ADM Projects) and all other applicable provisions if this Agreement from the Effective Date and at all times thereafter during the term of this Agreement.”
While clause 5.1 might suggest that Schedule 2 defines the manner in which IBM must provide Services under the Agreement, rather than the content of the Services which it is to provide, “Services” is defined as “the services specified in Schedule 2 (Managed Service), Schedule 18 (ADM Projects) and Schedule 21 (IT Upgrade Programme)”.
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:
“subject to clause 5.3.5, it is further agreed that the Contractor shall not receive any relief from its Managed Service obligations as a result of an End of Support product and/or Known Limitation other than to the extent agreed in a Relief Event Application”.
Clause 5.3.5 provides:
“For the avoidance of doubt, in the event of any failure or anticipated failure by the Contractor to comply with its Managed Service obligations, while it is acknowledged that completion of the IT Upgrade Programme may provide remediation for such failure or anticipated failure, the Contractor shall use its commercially reasonable endeavours to find workarounds to comply with its Managed Service obligations until such time as the IT Upgrade Programme addresses the failure or anticipated failure concerned.”
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:
“Capita may terminate this Agreement in whole or, subject to Clause 38.7, terminate any part of the Services hereunder for convenience at any time during the Term by giving the Contractor at least three (3) months' prior written notice of its intention to do so, and in this event Capita shall be liable to pay the Contractor’s Breakage Costs.”
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)
“The Contractor shall not unreasonably refuse any contractual amendments required by Capita in order to facilitate a Smooth Transfer of the Services (either in whole or in part), including, for the avoidance of doubt, any requests from Capita that the Contractor provide Capita with exit assistance in addition to the obligations set out in the Exit Plan, however, the reasonable costs to the Parties of such changes (in a "no better, no worse basis") will be agreed in good faith in accordance with Schedule 7 (Change Control Procedure).”
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].”
The Change Control Procedure
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.”
The Managed Service
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:
TABLE 1 – SERVICE HOURS | ||
System/Application | Online Day | Support Day |
[The Relevant Service] | 24 hours per day and 365 days per year | 24 hours per day and 365 days per year |
Security incident management shall be provided 24 hours per day and 365 days per year for all elements of the System.
Paragraph 5.1 provides:
“With respect to the Managed Service, the Contractor shall:
5.1.1 provide support and maintenance capability, including third party vendor support, for all applications and technologies identified in Annex 2 (Applications, Software and Third Party Support Agreements) of this Schedule.”
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:
“In so far as Table B in Annex 2 to this Schedule shows the Major Upgrades that may be required during the Term, this does not constitute a commitment to perform such Major Upgrades, such activity to be pursuant to the Change Control Procedure and at Capita’s expense.”
Paragraph 5.4 provides:
“In so far as Table B in Annex 2 to this Schedule shows the Major Upgrades that may be required during the Term, this does not constitute a commitment to perform such Major Upgrades, such activity to be pursuant to the Change Control Procedure and at Capita’s expense.”
Paragraph 5.17 provides:
“The Contractor shall supply, support and maintain the Handheld solution including the Handheld devices, all software running on the device, the mobile network, the backend solution and the Contractor’s process for ensuring all field officers are equipped with devices in accordance with paragraphs 5.18 to 5.23. Capita have instigated a phased programme to replace the Motorola Handheld device. Under this programme the Contractor will be required to support Capita with parallel running of the current Handheld solution and its replacement, integrating the Business Applications, and decommissioning of the current solution, such activities to be pursuant to the Change Control Procedure. Notwithstanding the above, the Contractor will cease support for the Motorola Handheld devices on 31st December 2022.”
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:
There are two application versions, both of which have an SS of “End of Support”.
There are five operating systems, three of which have an SS of “End of Support”, and the other two, “extended support”.
There is one database, which has an SS of “End of Support”.
There are three items of Middleware, all of which have an SS of “End of Support.”
There are two items of Underlying Hardware, one of which has an SS of “extended support”, the other of “End of Support”.
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:
Application | Application Version | Operating System | Database | Middleware | Underlying Hardware | Target Date of Upgrade |
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:
“Capita intend to commission work that will enable the decommissioning of this application. Should the decommissioning not be complete by the date specified in the relevant entry in Table B above, or a different approach be taken by Capita with regards the application and/or its functionality, the impact of such decision shall be handled pursuant to the Change Control Procedure with such impact being at Capita's expense, whether the impact is against the Managed Service, or the IT Upgrade Programme, or other work commissioned by Capita, or a combination thereof.”
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:
Application | Application Version | Operating System | Database | Middleware | Underlying Hardware | Target Date of Upgrade |
[The Relevant Service] | N/A Decommissioned | See Condition 2 below. | ||||
To repeat the terms of Condition 2:
“Capita is awaiting the [client] to commission work to replace the current [Relevant Service], and contract for the ongoing Managed Service of such, and it is assumed that this replacement [Relevant Service] will be operational on or before 30 August 2023.
As such the Contractor’s obligations for the Managed Services relating to the current [Relevant Service] shall cease at that time.
Further, any requirement for the Contractor to design and/or build and/or implement such a replacement [Relevant Service], and/or to operate such replacement [Relevant Service], shall be handled pursuant to the Change Control Procedure and at Capita’s expense, whether the impact is against the Managed Service, or the IT Upgrade Programme, or other work commissioned by Capita, or a combination thereof.”
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:
“1. The Parties shall continue to work to agree the migration of [various services] under RFC 4407 [a Change Control request which had already been made, but which had yet to be agreed].
2. If RFC 4407 is agreed and executed it will be delivered in parallel with, but distinct to, the IT Upgrade Programme. Prior to IT Upgrade Programme Milestones MS05, MS06, and MS07 the Parties will then assess whether the implementation of RFC 4407 can be completed on or before these Milestones.
a. If the assessment determines that RFC 4407 will complete on or before those Milestones, the IT Upgrade Programme will continue, with the Data Centre Migration including [various services], according to the plans described in Schedule 21.
b. If the assessment determines that RFC 4407 will not complete on or before these Milestones:
i. the IT Upgrade Programme will continue, with the Data Centre Migration excluding [various services];
ii. the impact against RFC 4407 will be assessed pursuant to the Change Control Procedure, which may include, but not be limited to, additional project charges for RFC 4407, and/or incremental charges … to … support [various services] in an alternative data centre until such a time as they can be migrated .... “
3. In the event that RFC 4407 is not agreed:
a. the IT Upgrade Programme will continue, with the Data Centre Migration excluding [various services];
b. the impact of such will be assessed pursuant to the Change Control Procedure, which may include, but not be limited to, additional project charges, and/or incremental Managed Service Charges to … support [various services] in an alternative data centre until such a time as they can be migrated ....”
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.
The Sub-Contract
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.
PRICING EVIDENCE
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:
Mainframe (zCloud)
Traditional Server & Storage Management
Cloud Server & Storage Management
Base Service Charge
Database Service Exadata
Database and Middleware
Security.
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.
THE MEANING OF CONDITION 2
Arguments based on the language of Condition 2 itself
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:
Capita argues that it is clear that the second sentence is contingent on a replacement for the Relevant Service being operational, as anticipated in the first sentence. However, the words “as such” do not clearly signal such a contingency, and can equally (and in my view more naturally) be read as reflecting the fact that the parties have agreed a termination date of 30 August 2023, that date having been selected on the basis of their assumption as to when the replacement system would be operational, but without being contingent on the fact.
Capita also argues that the third sentence supports its construction, because it “makes clear that all aspects of any commission for a new [Relevant Service], both as to the work to develop or implement a new [Relevant Service] or to operate a new [Relevant Service] would all be subject to change control”. I accept the third sentence does have this effect, but I am not persuaded that that supports Capita’s construction. On both Capita’s and IBM’s construction, the existing charges do not address the costs of operating the (hypothetical) replacement Relevant Service, and new contractual terms arrived at through the Change Control Process would be required to arrive at those terms if IBM was selected to perform this task.
Capita contrasts Condition 2 with Paragraph 5.17 of Schedule 2, which refers to the programme to replace the Handheld devices, with the existing systems being supported by IBM in parallel for an initial period, but “notwithstanding the above, the Contractor shall cease support for the Motorola Handheld devices on 31st December 2022.” Paragraph 5.17 was addressing a situation in which a replacement solution had already been instigated by Capita, and IBM had been retained to support it. Neither of these factors existed in relation to the Relevant Service. While I accept that the last sentence of Paragraph 5.17 is particularly clear, I am not persuaded that, in its different context, it sets a linguistic benchmark which Condition 2 must match before it could have the effect for which IBM contends.
Turning to IBM’s arguments:
IBM alleges that the words “‘as such’ make clear that the agreed assumption of a new Relevant Service being operational by 30 August 2023 is the reason that IBM’s obligations in relation to the old Relevant Service cease at that date”. I accept that the words “as such” link the cessation date with the matters in the previous sentence, but I do not think they make it sufficiently clear whether the link is to the event anticipated (a new system becoming operational) or the date by which it is anticipated that the event will have taken place, whether or not it does so (30 August 2023).
However, I accept IBM’s argument that the use of the word “assumption” rather than “expectation” is significant – it is language frequently used to describe the basis on which the parties are contracting. While there are many contexts in which it is clear that assumptions are merely a present view which can be revisited – a “working assumption” for example – there is no language addressing the consequences of revisiting that assumption in Condition 2.
The significance of that point is reinforced by IBM’s next point: that there was no reason for setting out the parties’ assumption as to the date a replacement system would become operational in the first sentence unless that assumed date is intended to have contractual effect. There is also force in IBM’s further submission that it would be surprising if the first two sentences are intended to do no more than make the obvious point that the obligation to maintain the Relevant Service will cease (and only cease) when that Relevant Service is replaced.
IBM alleges that “it is axiomatic that a fixed price service contract requires a fixed and certain duration”. However, it can be said that there is no certain duration on either party’s case. While IBM’s case is that “that time” as referred to in the second sentence is 30 August 2023, IBM accepts that if the Relevant Service is replaced by an operational new Relevant Service prior to that date, the services “relating to the current [Relevant Service]” will in practice cease prior to that date. On both parties’ case, therefore, the duration of IBM’s obligations has an uncertain start date but a fixed long-stop date: on Capita’s case, the date a replacement Relevant Service becomes operational or 2027; on IBM’s case, the date a replacement Relevant Service becomes operational or 30 August 2023 (albeit I accept that the parties would not have been particularly concerned about what would, in all probability, have been at best a very short period between a replacement system becoming operational before 30 August 2023, and the latter date).
IBM also relies on the third sentence of Condition 2, and the recognition that any replacement Relevant Service is to be operated “at Capita’s expense”, arguing “on Capita’s case, once the new [Relevant Service] became operational, it would be paying IBM twice.” However, the price for supporting the replacement Relevant Service falls to be fixed through the Change Control Procedure. In determining the impact of the change for the purposes of the Impact Assessment, and what price is “fair and reasonable in accordance with Best Industry Practice”, it seems to me probable that any saving in existing commitments which would fall away with the Change would naturally fall to be taken into account (and I would not regard the words “at Capita’s expense” as sufficient to compel a different result). Even if this is not the case, then it would be implicit in any Change which involved the replacement of part of the existing Managed Service with something new that Capita would be “paying twice” in the sense relied upon by IBM. This point only has limited weight.
There is, however, a difficulty with Capita’s case in the scenario where the client and Capita commission a replacement Relevant Service, but the work of building and/or operating that service is given to someone other than IBM (as Capita accepts could happen). In that eventuality, on Capita’s case, it would have agreed to pay a price intended to cover support for the Relevant Service for five years, with no mechanism for reducing that price when another Relevant Service was commissioned and supported by another provider. I was unable to accept Mr Howells KC’s argument that the third sentence of Condition 2 would apply in these circumstances, because that sentence only applies where IBM is required to design, build, replace, implement or operate the replacement Relevant Service. As an alternative, Mr Howells KC suggested that in those circumstances Capita could terminate that part of the Managed Service under clause 38.8, in return for paying Breakage Costs. That might provide an answer to this difficulty, although there was no discussion of the scope of Breakage Costs, which would appear to involve a number of adverse consequences for Capita including the payment of a Termination Fee. It would also involve the replacement of the Relevant Service being treated differently in this regard from other parts of the systems upgrade, where the termination of the service of support for the existing application on the replacement becoming operational is assumed, and where I doubt Capita accepts that termination under clause 38.8 and payment of Breakage Costs and Termination Fees is required.
IBM also contended that the contemplation in Condition 2 that IBM would be paid for “operat[ing] a replacement [Relevant Service]” would be “extremely odd if … the agreed price already included the costs of running the old [Relevant Service] until 2027, a fortiori given that the costs of running the new applications would be lower than the cost of running the old applications”. I accept that a replacement modern system ought, in principle, to be cheaper to operate (and this was not challenged), on which basis there is something in this point. However, the weight which can be attributed to it is attenuated by the fact that the words “at Capita’s expense” follow a portmanteau description covering the “design and/or build and/or implement[ation]” of the replacement Relevant Service as well as its operation.
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.
The immediate contractual context to Condition 2
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:
As I have stated, all three Conditions were introduced at the same time, to address the same broad topic of what was to happen if anticipated upgrades to the existing IT estate were not implemented as anticipated. In time, place and origin, they are very close to the textual epicentre of this dispute.
Conditions 1 and 3 expressly provide for what is to happen if anticipated improvements are not undertaken, or undertaken in time, and for IBM to continue to support the existing IT estate so far as it pertains to the relevant applications, but with a right to seek a price adjustment through the Change Control Process. Neither of them include a date when IBM’s support for the relevant applications would cease, but simply assumed the obvious (that it would cease if the application was replaced).
Against that background, the inclusion of a cessation date in Condition 2 is particularly significant, as is the absence of any reference to the Change Control Process applying so as to permit IBM to increase the charges if the replacement Relevant Service was not operational by the anticipated date.
The conclusion which obviously follows from those facts is that the cessation date was included in the second sentence of Condition 2 because it applies whether or not a replacement Relevant Service is operational, and the absence of any reference to the Change Control Procedure applying where the anticipated operation of the replacement Relevant Service is not achieved is because Condition 2 does not oblige IBM to maintain the Relevant Service after 30 August 2023 in that eventuality.
The main terms of the Agreement
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:
The scope of IBM’s obligations in clause 5 is to “perform the Services in accordance with Schedule 2 (Managed Service) …”, expressly limiting the obligations assumed by reference to the terms of that schedule.
Another way of making the same point is that the generality of those provisions must yield to the specific consideration given to the Relevant Service in Table B to Annex 2 to Schedule 2, and to Condition 2.
Capita’s argument would prove too much. Capita accepts that the main terms impose obligations on IBM to support certain applications and their associated IT estate up to the point of a systems upgrade, but that the effect of Schedule 2 is that those obligations will no longer apply when those applications are replaced. It also accepts that the support of those applications will be “in price” for the subject-matter of Conditions 1 and 3 up to a certain date, but can be the subject of a further price claim thereafter. This illustrates the difficulties with an argument which seeks to read down the relevant terms in Schedule 2 by reference to the main terms.
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:
Clause 39.1.2 obliges IBM “from expiry (in whole or in part) of this Agreement” to comply with Schedule 11.
Paragraph 1.2 of Schedule 11 states that the objective of the regime in Schedule 11 is “to ensure a Smooth Transfer of the Services in whole or in part”.
Paragraph 2.1.4 requires the Draft Exit Plan to show “the method by which systems and Services could be divided to enable part or full termination of the Services.”
There are similar references to termination “in part” in paragraphs 4.2, 4.2.1, 4.3, 5.2, 7.6, 9.3, 9.4.1, 9.5, 9.8 and 13.1.
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.
Arguments by reference to business common sense
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:
First, when the Agreement was extended in 2022, on IBM’s construction the “hard stop” of 30 August 2023 was known, and some time away. The material before me does not come close to demonstrating that it would not have been possible for Capita to prepare a transition plan to address the possibility that no replacement system would be operational by that point. In weighing an appeal to commercial common sense, the issue falls to be tested at the date the Agreement was concluded, not the position which Capita in fact found itself in on 31 August 2023 (Arnold v Britton [2015] AC 1619, [19]).
Second, a rational businessperson’s response to the risk of being left without IBM support for the Relevant Service on 31 August 2023, at the date of the extension of the Agreement, would be influenced by how likely the possibility of there being no operational replacement Relevant Service at that date was perceived to be. The terms of Condition 2, and the expectation of the parties, is that it was not thought to be a likely prospect.
Third, the Agreement did not leave Capita entirely without protection in that scenario. It had the right to issue a Change request, which IBM was not entitled unreasonably to refuse, albeit this would have involved a variation of the terms and the risk of additional payments fixed under the Change Control Procedure: see [39]. It is accepted that the “Smooth Transfer” provisions of clause 39 and Schedule 11 apply. While there was a dispute between the parties as to how easy it would be to transfer support of the Relevant Service to a new vendor, it is of note that the Moratorium agreed between Capita and IBM on 30 August 2023 assumes that steps concerning a “Smooth Transfer” to a new vendor (the precise nature of which it is not necessary to determine) could be effected within 12 weeks of the end of the Moratorium Period.
Fourth, arguments of business common sense require the effect of that common sense to be objectively apparent to both contracting parties at the time of contracting – it cannot be enough for a particular construction to be unbusinesslike for private reasons apparent only to one party. There is no evidence before me to suggest that IBM was aware of what commitments Capita had made to the client, and whether this included an obligation to maintain the Relevant Service if no replacement system had been commissioned by the client so as to become operational by 31 August 2023 and/or to continue to provide such support in circumstances in which IBM was no longer doing so. As it happens (although, because it was unknown to IBM, it is not relevant to the meaning of Condition 2), Capita had promised the client that it would be in a position to take over in the event of a sub-contractor’s default (clause 44.4 of the Head Contract).
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:
It is difficult to evaluate an argument based on the allegedly uncommercial nature of one obligation in a much larger bargain, given the obvious potential for trade-offs in the ultimate decision to contract.
While I accept that an ongoing obligation to support the Relevant Service was not attractive to IBM, on its own case it was willing to do so until 30 August 2023, and, for all I know, it may have been sufficiently confident of a replacement Relevant Service being operational by that date to be willing to run a contractual risk of subsequent support if the unexpected happened.
The Agreement did provide some protection against the risks identified, in the form of the Relief Event Application regime in clause 5.3. Mr Kitchener KC may be right about the limits of that protection, but that is essentially a question of commercial judgment on which it is very difficult for the court to arrive at a clear view.
Mr Kitchener KC is right to say that adopting this approach might have reduced the incentive on the client's part to commission a new system, which I accept would not have been in IBM’s commercial interest. But an argument of “business common sense” of this kind would require the court to venture into the “game theory” of the parties’ commercial strategies, with the inherent uncertainty and speculation which that would entail.
Conclusion
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.