HT-2020-000448 - [2024] EWHC 1185 (TCC)

I take these two together as they give rise to the same contractual issues. I read the first of these two as a reference to what has been considered above to be the ‘RFC 607’ issue, namely the proposed change to stagger the data migration approach and create a new solution where an RB could exist and send applications in both legacy R0 or R1. The ‘GDPR’ RFC was an important ‘Must Have’ in the chronology set out above.

As set out in its Written Closing Submissions, DBS’s short legal answer to these claims is that the complaints are fundamentally misconceived: the contractual approach (i.e. scope) remained as per the terms of the Agreement unless and until it was changed by way of an agreed CCN.

DBS contends that a change to the contractual scope of work can only be effected by way of a CCN signed by both parties. DBS points to Clause 2 of Schedule 2-7 to the Agreement which states:

DBS therefore argues as a matter of contract: (1) the contractual scope of work can only be changed by a CCN signed by both parties; (2) until that occurs, TCS must perform in accordance with the original scope of work; and (3) if TCS decides to work on a proposed Change before a CCN has been signed, or pauses work pending a change (which is really the cause of delay here), it does so at its own risk. It is said that it follows that a failure to agree a CCN cannot amount to a delay event: the work which TCS is required to deliver by the relevant Milestone remains the same until the CCN is agreed. An RFC is insufficient to change TCS’s obligations in this regard.

In response, TCS contends that the only party that could specify the changes that were needed to be made to the R1-D specification via RFC to meet DBS’s requirements, who could engage stakeholders such as RBs and who could decide on a migration strategy for the RBs, was DBS. As a matter of natural and ordinary language (and, it argues, common sense) those matters were ‘AUTHORITY Responsibilities’, delay to which was thus ‘AUTHORITY Cause’. I have concluded above that ‘AUTHORITY Responsibilities’ must be grounded in contractual obligations.

TCS also relies on paragraphs 5.1 and 5.2 of Sch. 2-6 to the Agreement: DBS’s failure to decide upon and approve the requisite set of RFCs and its approach to RFC 607 constituted a failure to ‘co-operate in the provision of information necessary for the successful operation and assessment of performance of the Services and other obligations under this Agreement’.

TCS further submits that DBS’s contention that TCS should have no relief because it had an obligation to plough on regardless of the RFC position is commercially unrealistic because it would have led to TCS delivering a solution that it knew that DBS did not in fact want and which could not go live. Where progress, at least at some point in the future, depended upon co-operation from DBS (through the provision of RBs to assist with testing), immediate progress would be to no purpose. This submission, standing alone, does not have a legal footing, however, but it is relevant context in which to analyse the legal basis of any relief.

TCS lastly advances a case (pleaded at paragraph 31 of the Amended Reply and Defence to Counterclaim) that both parties treated the agreement of the scope of R1 Disclosure as a pre-requisite for progressing the release, that the Defendant never confirmed what, if any, functionality it actually wanted in these areas, and that in the premises, TCS could not simply proceed without confirmed functionality. To do so would breach TCS’s own cooperation obligations under paragraphs 5.1 and 5.2 of Schedule 2-6. Alternatively, TCS contends that DBS is estopped from contending that TCS should have progressed Final SIT without an agreed scope, because the parties conducted themselves on the basis that the TCS should not do so. It would be unjust and/or unconscionable for DBS to act contrary to that convention now. Paragraph 31 was not specifically pleaded to in the Amended Rejoinder, although at paragraph 5.3 of that pleading, DBS plead that TCS did not comply with the Contract Change Procedure, and was not prevented from complying by DBS.

In my judgment, DBS’s analysis of the contractual framework for CCNs is the correct starting point.

The key clause is Clause 2.3. This provides a clear obligation upon TCS to continue to provide and make available to DBS the Services (which in this context means the development of R1-D) in accordance with the existing terms of the Agreement until such time as a CCN has been signed by both parties, unless DBS expressly agrees otherwise in writing.

Clauses 2.5 and 10.1 are not duplicative of Clause 2.3 and deal with slightly different things. Clause 2.5 ensures that discussions, negotiations or other communications remain without prejudice to the parties’ rights until the CCN is signed (e.g. the parties are not bound until the CCN is signed). Clause 10.1 is directed at preventing a claim relating to the implementation of change related work prior to the CCN.

The express requirement to continue with the original scope unless and until agreement is reached by way of CCN does not prevent the parties, as part of their obligation to collaborate in an environment of co-operation, from agreeing that planning and thereafter progress was dependent upon scope clarification. The need for co-operation in circumstances where, absent co-operation, TCS would have continued to develop and test something which DBS did not want is plain. It was accepted by Dr Hunt (Day 20/194):

The fact that this may be appropriate has been expressly contemplated in Clause 2.5, by recognising that DBS may agree in writing that the obligation may be disapplied. Therefore, as a matter of contractual analysis, it is correct that TCS is generally at contractual risk if it fails to progress its scope of work whilst discussing potential changes in scope. There may be room for an argument that, if TCS asked DBS to provide an agreement in writing pursuant to Clause 2.5 that the Services or part of them do not need to proceed pending the outcome of particular discussions on scope change and DBS refused, that could be a breach of DBS’s obligation to conduct discussions relating to proposed changes in good faith, pursuant to Clause 2.2 of the Schedule and/or a breach of the obligation to collaborate in an environment of mutual respect and co-operation pursuant to Clause 5.1 of Schedule 5.6. However, there is a contractual process for being relieved from the obligation at Clause 2.5 which, unless invoked, clearly states that TCS must proceed irrespective of negotiations about change. The clause promotes certainty. It is a requirement that itself could only be waived in writing (Clause 62.1).

Therefore, prior to 6 February 2018, notwithstanding that the parties were generally aware of the others’ position, there was no agreement in writing in place to satisfy the caveat in Clause 2.5. TCS had not sought comfort in this regard. The correct analysis for this period is therefore that TCS was, pursuant to Clause 2.5 of the Agreement, at risk for the critical delays being caused by failing to proceed. For the reasons I have set out above, TCS could not have commenced SIT Final at this time, in any event, because of the absence of the availability of the SIT-L environment with connectivity. There are therefore two causes of delay in this period. Although neither expert analysed it in this way, it seems likely that this was a period of true concurrency where there were two equally potent effective causes of failing to progress to Final SIT: the absence of a software drop (due to lack of finalised scope which remained at TCS risk at this point) and lack of environment in which to test. In the context of Clause 7 relief, it does not matter whether these are truly concurrent, or whether the matter for which TCS is at contractual risk is in truth sub-critical: TCS would not be entitled to relief for this period.

However, in my judgment, the agreement reached in February 2018 which was recorded in writing by Ms Downey, properly construed in its factual context, satisfies the caveat (‘unless the AUTHORITY expressly agrees otherwise in writing’) and renders Clause 2.3 inoperative from that point onwards. It was in both parties’ interests to do so in circumstances where to do otherwise would have led to TCS delivering a solution DBS did not in fact want and which could not go live, and where the solution depended upon co-operation from DBS (through, not least, the provision of RBs to assist with testing).

It would not be correct to conclude, as TCS assert, that the approach taken by DBS in February could properly be characterised as a breach by DBS of Clauses 5.1 and/or Clause 5.2 of Schedule 2.6 to the Contract. The parties were engaged in commercial negotiations expressly on the basis that the conclusion of those negotiations was required to permit progress towards delivery a scope which required changes to the specification. That embodied, albeit strained at times, the very co-operation in the provision of information necessary for the successful operation and assessment of performance of the Services and other obligations under the Agreement envisaged by these clauses.

It is not right, therefore, to analyse this factual situation through the lens of ‘AUTHORITY Cause’ for the purposes of Clause 7 (which would give TCS the right to payment for these delays during the period of agreed re-planning, which would not in my judgment be implicit in the co-operative agreement reached at this point).

Instead, the parties’ conduct (embodied in the agreement set out by Ms Downey) upon which TCS’s argument relies and the consequent disapplication of the obligation within Clause 2.3 upon which DBS relies is given effect to merely by forbearance by each side of a claim that the other is responsible for the period of delay generated during this period of commercial negotiation. An alternative and equally valid analysis is that, as pleaded by TCS, DBS is estopped from contending that from 6 February 2018 onwards TCS should have progressed Final SIT without an agreed scope, because the parties conducted themselves on the basis that TCS should not do so. It would be unjust and/or unconscionable for DBS to act contrary to that convention now. That estoppel, in my judgment, does not arise earlier than 6 February which is the point at which the contractual answer to the estoppel falls away.

On my analysis of the facts above, there came a point where co-operation from DBS in order to provide information to allow the R1-D to be provided ceased. The most sensible date to identify this point by is 13 June 2018, when TCS downed tools and DBS resolved with certainty (albeit still subject to Home Office approval) that it did not want R1-D to be delivered by TCS and worked to execute that strategy. The correct factual analysis at this point is that an ‘AUTHORITY Cause’ pursuant to Clause 7 arose because as a matter of fact, DBS was no longer co-operating in the provision of information necessary for the successful operation and assessment of performance of the Services; rather it was executing its strategy which specifically involved TCS not delivering R1-D. As Dr Hunt agreed, TCS could not ‘strike out alone’ and DBS’s lack of constructive engagement in delivery of a minimum viable R1-D solution through TCS from June 2018 onwards breached Clauses 5.1 and 5.2 of Schedule 5-6 of the Agreement.

This ties in with the fourth pleaded allegation relied upon (at paragraph 36.4 of the Amended Particulars of Claim):