Tata Consultancy Services Limited v Disclosure and Barring Service [2024] EWHC 1185 (TCC)

‘i) The court construes the relevant words of a contract in their documentary, factual and commercial context, assessed in the light of (i) the natural and ordinary meaning of the provision being construed, (ii) any other relevant provisions of the contract being construed, (iii) the overall purpose of the provision being construed and the contract or order in which it is contained, (iv) the facts and circumstances known or assumed by the parties at the time that the document was executed, and (v) commercial common sense, but (vi) disregarding subjective evidence of any party's intentions – see Arnold v. Britton 6 [2015] AC 1619 per Lord Neuberger PSC at paragraph 15 and the earlier cases he refers to in that paragraph; ii) A court can only consider facts or circumstances known or reasonably available to both parties that existed at the time that the contract or order was made - see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 20; iii) In arriving at the true meaning and effect of a contract or order, the departure point in most cases will be the language used by the parties because (a) the parties have control over the language they use in a contract or consent order and (b) the parties must have been specifically focussing on the issue covered by the disputed clause or clauses when agreeing the wording of that provision – see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 17; iv) Where the parties have used unambiguous language, the court must apply it – see Rainy Sky SA v. Kookmin Bank [2011] UKSC 50 [2011] 1 WLR 2900 per Lord Clarke JSC at paragraph 23; v) Where the language used by the parties is unclear the court can properly depart from its natural meaning where the context suggests that an alternative meaning more accurately reflects what a reasonable person with the parties' actual and presumed knowledge would conclude the parties had meant by the language they used but that does not justify the court searching for drafting infelicities in order to facilitate a departure from the natural meaning of the language used – see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 18; vi) If there are two possible constructions, the court is entitled to prefer the construction which is consistent with business common sense and to reject the other – see Rainy Sky SA v. Kookmin Bank (ibid.) per Lord Clarke JSC at paragraph 2 - but commercial common sense is relevant only to the extent of how matters would have been perceived by reasonable people in the position of the parties, as at the date that the contract was made – see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 19; vii) In striking a balance between the indications given by the language and those arising contextually, the court must consider the quality of drafting of the clause and the agreement in which it appears – see Wood v. Capita Insurance Services Limited [2017] UKSC 24 per Lord Hodge JSC at paragraph 11. Sophisticated, complex agreements drafted by skilled professionals are likely to be interpreted principally by textual analysis unless a provision lacks clarity or is apparently illogical or incoherent– see Wood v. Capita Insurance Services Limited (ibid.) per Lord Hodge JSC at paragraph 13; and viii) A court should not reject the natural meaning of a provision as correct simply because it appears to be a very imprudent term for one of the parties to have agreed, even ignoring the benefit of wisdom of hindsight, because it is not the function of a court when interpreting an agreement to relieve a party from a bad bargain - see Arnold v. Britton (ibid.) per Lord Neuberger PSC at paragraph 20 and Wood v. Capita Insurance Services Limited (ibid.) per Lord Hodge JSC at paragraph 11.’

‘The fact is that in the present case we have no evidence of why specific changes were made, nor any evidence that the parties turned their minds to the differences between the two forms and there must be a real likelihood that they simply reached for the current form without any consideration of the earlier version. … In my view the right course when seeking to ascertain the intention of the parties is to consider this contract on its own terms against the commercial background as it existed at the time it was made.’

‘included timeously fulfilling the function of systems integrator, or alternatively appointing [TCS] or a third party to act as systems integrator, and otherwise taking such steps as were necessary to ensure that the activities reasonably expected of a systems integrator were timeously performed. Such activities included: 26.3.1 Defining the high-level design approach for the project; 26.3.2 Defining the approach to integrating components and planning when each supplier needed to deliver its components; 26.3.3 Identifying dependencies between organisations and planning when each supplier needed to deliver its components; 26.3.4 Ensuring that suppliers committed to appropriate delivery dates and turnaround times; 26.3.5 Providing (or procuring) an infrastructure specification so that [TCS] was able to understand what infrastructure components were available, what capabilities they offered, and how they were to be configured; 26.3.6 Implementing reliable and consistent processes for processing infrastructure set up and configuration requests; 26.3.7 Ensuring that the technical infrastructure services that [TCS] was required to use to develop, test and deploy the Solution were fit for those purposes; 26.3.8 Ensuring that the technical infrastructure was built and supported with reasonable skill and care and in accordance with good industry practices.’

‘any breach of the obligations of any party (including but not limited to fundamental breach or breach of a fundamental term) or any default, act, omission, negligence or statement of any party, its employees, agents or sub- contractors in connection with or in relation to the subject matter of this Agreement and in respect of which such party is liable to the other.’

‘108. The modern view is accordingly to recognise that commercial parties are free to make their own bargains and allocate risks as they think fit, and that the task of the court is to interpret the words used fairly applying the ordinary methods of contractual interpretation. It also remains necessary, however, to recognise that a vital part of the setting in which parties contract is a framework of rights and obligations established by the common law (and often now codified in statute). These comprise duties imposed by the law of tort and also norms of commerce which have come to be recognised as ordinary incidents of particular types of contract or relationship and which often take the form of terms implied in the contract by law. Although its strength will vary according to the circumstances of the case, the court in construing the contract starts from the assumption that in the absence of clear words the parties did not intend the contract to derogate from these normal rights and obligations. … 111. To the extent that the process has not been completed already, old and outmoded formulas such as the three-limb test in Canada Steamship Lines Ltd v The King [1952] AC 192, 208, and the “contra proferentem” rule are steadily losing their last vestiges of independent authority and being subsumed within the wider Gilbert-Ash principle. As Andrew Burrows QC, sitting as a Deputy High Court Judge, said in Federal Republic of Nigeria v JP Morgan Chase Bank NA [2019] EWHC 347 (Comm); [2019] 1 CLC 207, para 34(iii): ‘Applying the modern approach, the force of what was the contra proferentem rule is embraced by recognising that a party is unlikely to have agreed to give up a valuable right that it would otherwise have had without clear words. And as Moore-Bick LJ put it in the Stocznia case, at para 23, ‘The more valuable the right, the clearer the language will need to be’

‘that the issue for decision in this case is one of construction of a particular clause in a particular contract, and that consideration of how courts have construed differently worded clauses in different contracts is necessarily of limited assistance. It seems to me that, while taking note of the reasoning in the authorities cited, the correct approach is to focus on the precise terms of the Agreements with which the present case is concerned and ascertain their meaning applying the ordinary principles of contract interpretation.’

‘Whether this clause is a condition precedent or a contractual term of some other character must depend on (i) the form of the clause itself, (ii) the relation of the clause to the contract as a whole, (iii) general considerations of law.’

‘21. Prohibition In case of prohibition of export, blockade or hostilities or in case of any executive or legislative act done by or on behalf of the Government of the country of origin or of the territory where the port or ports of shipment named herein is/are situate, preventing fulfilment, this contract or any unfulfilled portion thereof so affected shall be cancelled. In the event of shipment proving impossible during the contract period by reason of any of the causes enumerated herein, sellers shall advise buyers of the reasons therefor. If required, sellers must produce proof to justify their claim for cancellation.’

‘If by reason of any circumstance which entitles the Contractor to an extension of time … the Sub-Contractor shall be delayed in the execution of the Sub-Contract Works, then in any such case provided the Sub-Contractor shall have given within a reasonable period written notice to the Contractor of the circumstances giving rise to the delay, the time for completion hereunder shall be extended ….’

‘In my opinion the real issue which is raised on the wording of this clause is whether those clear words by themselves suffice, or whether the clause also needs to include some express statement to the effect that unless written notice is given within a reasonable time the sub-contractor will not be entitled to an extension of time. …In my judgment a further express statement of that kind is not necessary. I consider that a notification requirement may, and in this case does, operate as a condition precedent even though it does not contain an express warning as to the consequence of non-compliance. It is true that in many cases (see for example the contract in the Multiplex case itself) careful drafters will include such an express statement, in order to put the matter beyond doubt. It does not however follow, in my opinion, that a clause – such as the one used here - which makes it clear in ordinary language that the right to an extension of time is conditional on notification being given should not be treated as a condition precedent.’

‘If the Sub-Contractor fails to complete the Sub-Contract Works or such works in any Section within the relevant period or periods for completion, and if the Contractor gives notice to that effect to the Sub-Contractor within a reasonable time of the expiry of the period or periods, the Sub-Contractor shall pay or allow to the Contractor the amount of any direct loss and/or expense suffered of incurred by the Contractor and cased by that failure.’

‘I recognise that a claim for negligent misrepresentation involves an allegation of fault and involves a different measure of damages, but it seems to me that a court should at least have in mind the contractual allocation of risk and reward when deciding whether the parties are to be taken to have intended that claims for misrepresentation based on the same facts as give rise to the claim for breach of warranty are to fall entirely outside the confined liability prescribed by the SPA.’

‘52.2 Subject to clause 52.1, the CONTRACTOR's total aggregate liability: 52.2.1 in respect of the indemnity in clauses 17.2 (Tax), 29 (Employment Indemnity), and 51 (IPR Indemnity), shall be unlimited; 52.2.2 for all loss of or damage to the AUTHORITY Premises, property or assets (including technical infrastructure, assets or equipment but excluding any loss or damage to the AUTHORITY's Data or any other data) of the AUTHORITY caused by the CONTRACTOR's Default shall in no event exceed £5,000,000 (subject to indexation); 52.2.3 for all loss, destruction, corruption, degradation, inaccuracy or damage to the AUTHORITY Data caused by the CONTRACTOR's Default shall be £5,000,000 (subject to indexation); 52.2.4 in respect of Services Credits shall be limited in each Service Year to 10% of the Charges in that year; 52.2.5 in respect of Delay Payments shall be limited to 10% of the implementation Charges. 52.2.6 in respect of all other claims, losses or damages, shall in no event exceed £10,000,000 (subject to indexation) or, if greater, an amount equivalent to 100% of the Charges paid under this Agreement during the 12 month period immediately preceding the date of the event giving rise to the claim under consideration less in all circumstances any amounts previously paid (as at the date of satisfaction of such liability) by the CONTRACTOR to the AUTHORITY in satisfaction of any liability under this Agreement. 52.3. Subject to clause 52.1, the AUTHORITY's total aggregate liability, (in addition to its obligation to pay the Charges as and when they fall due for payment): 52.3.1 for all Defaults by the AUTHORITY resulting in loss of or damage to the property or assets (including technical infrastructure, assets or equipment) of the CONTRACTOR shall in no event exceed £5,000,0000 (subject to indexation); 52.3.2 for the Termination Payment, shall not exceed: 52.3.2.1 in first Contract Year, £35,000,000 (subject to indexation); 52.3.2.2 in the Contract Years two and three and four and five, £25,000,000 (subject to indexation) for that respective year 52.3.2.3 in the final Contract year, £15,000,000 (subject to indexation);and 52.3.3 for the Compensation Payment, shall not exceed £10,000,000 (subject to indexation); 52.3.4 in respect of all other Defaults by the AUTHORITY shall in no event exceed the greater of: 52.3.4.1 an amount equivalent to the total Charges paid or properly invoiced and due to be paid under this Agreement in the 12 month period immediately preceding the event giving rise to the liability; or 52.3.4.2 £25,000,000. 52.4 Subject to clauses 52.1 and 52.5, neither party will be liable to the other party for: 52.4.1 any indirect, special or consequential loss or damage; or 52.4.2 any loss of profits, turnover, business opportunities or damage to goodwill (whether direct or indirect). 52.5 Subject to clause 52.2, the AUTHORITY may, amongst other things, recover as a direct loss: 52.5.1 any additional operational and/or administrative costs and expenses arising from the CONTRACTOR's Default; 52.5.2 any wasted expenditure or charges rendered unnecessary and/or incurred by the AUTHORITY arising from the CONTRACTOR's Default; and 52.5.3 the additional cost of procuring Replacement Services for the remainder of the Term; and 52.5.4 any anticipated savings.’

“9.2 The aggregate liability of the Contractor in accordance with sub-clause 8.1.2 paragraph (b) shall not exceed: 9.2.1 for any claim arising in the first 12 months of the term of the Contract, the Total Contract Price as set out in section 1.1; or 9.2.2 for claims arising after the first 12 months of the Contract, the total Contract Charges paid in the 12 months prior to the date of that claim.”

‘33.2 Subject to clauses 33.1, 33.3, 33.5 and 33.6, the Supplier's total liability to the Customer, whether in contract, tort (including negligence), for breach of statutory duty or otherwise, arising out of or in connection with this Agreement (including all Statements of Work) shall be limited to an amount equivalent to 150% of the Charges paid or payable in the preceding twelve months from the date the claim first arose. If the claim arises in the first Contract Year then the amount shall be calculated as 150% of an estimate of the Charges paid and payable for a full twelve months. 33.3 The Supplier's total aggregate liability arising out of or in relation to this Agreement for any and all claims related to breach of any provision of clause 21 whether arising in contract (including under an indemnity), tort (including negligence), breach of statutory duty, laws or otherwise, shall in no event exceed 200% of the Charges paid or payable in the preceding twelve months from the date the claim first arose or £20m (whichever is greater).’

‘The loss of revenue claim is advanced on the basis that (i) the per transaction cost to the Claimant of processing each of Basic Disclosure, Standard Disclosure, Enhanced Disclosure and Update transactions was anticipated to fall substantially on Go-Live of R1 owing to the efficiencies of operating the Solution compared with the legacy R0 processes; (ii) the contractual charging scheme reflected that anticipated lower cost to the Claimant, principally by means of a substantial drop in the Transaction Charges after Service Year 3; (iii) by reason of the delay to Go-Live of R1 Barring & Basics and the lack of Go-Live of R1 Disclosure, the Claimant was not able to achieve the contractually anticipated savings but was still subject to the reduced Transaction Charges; (iv) the result was that the Claimant’s net revenues from Transaction Charges were substantially lower than they would have been but for the delay in relation to R1 Barring & Basics and non-implementation of R1 Disclosure. Pending expert evidence, the Claimant has calculated its losses only for the period April 2017 to March 2020, and has done so by reference to the difference between the Transaction Charges applicable during that period as set out in paragraph 2.3.1 of Schedule 2-3 and the Transaction Charge that would have been paid had the Service Year 3 Transaction Charges continued to apply in Service Year 4 onwards, such difference in charges being a proxy for and reasonable estimate of the lost anticipated cost savings.’

‘Losses arising under and/or in connection with this Agreement (whether in contract, tort (including negligence), breach of statutory or otherwise) which are indirect or consequential Losses, or for loss of profit, revenue, savings (including anticipated savings), data …, goodwill , reputation (in all cases whether direct or indirect)’. ‘Losses’ were defined as ‘All losses, liabilities, damages, costs and expenses including reasonable legal fees on a solicitors/client basis and disbursements and reasonable costs of investigation, litigation settlement, judgment, interest.’

‘The claimant can either claim its loss of profits or, alternatively, its wasted expenditure. If the claim is for wasted expenditure, it is not limited to the expenditure incurred after the contract was made but can also include the expenditure before the contract, provided it was reasonably in the contemplation of the parties as likely to be wasted if the contract were broken: see Anglia Television Limited v Reed [1972] 1 QB 60. In that case, Lord Denning MR said: ‘It seems to me that a plaintiff in such a case as this has an election: he can either claim for loss of profits; or for his wasted expenditure. But he must elect between them. He cannot claim both. If he has not suffered any loss of profits- or if he cannot prove what his profits would have been- he can claim in the alternative the expenditure which has been thrown away, that is, wasted, by reason of the breach.’

‘68. All loss of profit/revenue/savings claims are difficult for the potential contract-breaker to estimate in advance. They can be notoriously open-ended. Claims for loss of profit, revenue and savings are therefore types of potential loss which, because of those problems of speculation and ascertainment, are routinely excluded by clauses like clause 23.3. 69. Claims for wasted expenditure are an entirely different animal. To be able to claim such wasted expenditure is a valuable right: see Anglia v Reed and Yam Seng. Moreover, if the victim of a breach of contract has spent money in anticipation that the contract would be performed, then his or her loss is easy to ascertain: there will be invoices, contracts, receipts and the like. This type of loss is the opposite of speculative: it is precisely ascertainable. It is a pure accounting exercise. Perhaps for that reason, such claims are not usually regarded as claims for consequential loss. …. 70. This distinction is also in accordance with the law. That these are different types of loss as a matter of law is underlined by the decision in Anglia Television (paragraph 40 above). When a contract is repudiated, the victim can claim loss of profits or the expenditure which has been thrown away as a result of the repudiation. He or she cannot claim both and, to address a point touched on in Treitel's The Law of Contract, 15th Edition at 20-036, also edited by Professor Peel, there are "formidable objections to running the two claims in the alternative": see Filoblake Ltd v Rondo Ltd at [64]. On its face, therefore, clause 23.3 expressly excluded the former type of loss, but did not exclude the latter.’

‘Current situation is: 1. Updated HPE Delivery Plan I believe TCS received this yesterday and Paul Martin is working on plugging it in to the TCS plan. 2. Decision on Verify / Post Office Contingency TCS has been informed that Verify is the solution. 3. Confirmation of Verify stage completion dates Planning session this week. 4. Dates by which all other external dependencies will be met. We will need to plan on the basis of assumptions (e.g. those we have for Vodafone and HOT)’

“(or such other period as the AUTHORITY may permit and notify to the CONTRACTOR in writing)”

‘I note that you never formally responded to our request in that letter for an extension within which to submit an Exception Report.’

‘We all focussed on regulating the position by re-planning and then we would know that the consequences of the delays were – and would in fact have already sorted them out. We could then serve the Exception Report. ….There is no doubt that [DBS] knew we needed specific information to complete the draft Exception Report that DBS could not readily provide, and the process we were all embarked upon was a collaborative one to ascertain and understand when all parties could complete the relevant tasks so that an effective-plan for delivery could be prepared. I also do not recall any occasion on which DBS asserted, prior to the service of the draft Exception Report, that TCS would not be entitled to compensation for the delays described in the Notice of Delay because it had not served the draft Exception Report within five working days.’

‘So I think even when we were trying to do the replanning, you will find that in a period of three to four or five months, each of the elements of delivery from the delivery partners, like HPE, were shifting 12, 15, 16 times. So we could not – it’s a moving feast. We just couldn’t pinpoint in terms of any of those details that is required, because for an Exception Report in our mind to be complete, we need to give some kind of a realistic assumption in terms of when these partners can deliver, based on which, when we can deliver the final outcome. And every time we prepare one, we find that they come back in the next week or session and give us a delay which is again further on. So we find multiple iterations coming from all the time. So we couldn’t collate it in any sensible shape or form, because from one reporting period to the other, so many delays are happening, so we couldn’t have a feel. Even though, again, that’s a frustration I would have in my witness statement is that we want to do it and we have expressed with DBS that we would like these teams to come together to help us prepare to do it, but it – it just doesn’t happen.’

"I have then reported that as the reason for the date slipping or (in several instances) moving forward."

‘On an IT project, activities that are not on the critical path will tend to extend to fill the time available and activities that are one the critical path will tend to be compressed and overlapped or a completely new strategy will be devised if the project is late. Dependencies are fluid and can often be waived or postponed…Teams can be asked to work additional hours over limited numbers of weeks to speed up delivery if required. Unlike a construction project, resources cannot simply be brought on and laid off a project as and when required…..If software is not on the critical path, then ways need to be found to keep these team members productive, by slimming the team down (a route that cannot easily be retraced) or by finding additional work for them to do, such as implementing change requests or non-essential improvements and defect fixes. Changes may be agreed without requesting an extension when one would have been insisted on if the software was critical.’….Once a delay to a milestone has been forecast on an IT project, the software-delivery workstream will work to the new forecast date.’

‘While I have not been able to assess TCS’s progress in development and testing in detail, because of the lack of a development tracking tool, I have seen no evidence to suggest that TCS’s development and testing team were in effect ‘pacing’ their activity while waiting for other critical activities to complete. On the contrary there is evidence that TCS did not have sufficient resource to carry out the necessary work in 2016, for example: • DBS expressed concerns at the lack of test resource, completeness of test plans and a lack of a release manager in March 2016 • TCS’s proposal to re-sequence test phases in May 2016 was accompanied by a proposal to significantly increase on-shore testing resource • TCS did not have sufficient resource to test and support both Barring & Basics and Disclosure in June 2016 • Suggestions that TCS should implement changes to the portals for usability reasons caused concern about build impact in TCS’s build team’

‘As per the update shared yesterday, today We have taken support from build team to analyse all the failed and blocked scenarios in PMS area and identified the one's which needed further clarification, testing, test data creation, or if it is a new requirement. There was slow progress in execution today due to teams involved in these discussions on previous failed, blocked scenarios and unavailability of test data in the SIT-L environment (since regression and BPO UAT testing is going in parallel and test data creation needs support from testing team).’ (3) Similar problems continued to occur. Some days (e.g. 29 November 2016) no official testing took place because of lack of availability of the Finance team. There was still a large number of blocked and failed scenarios as at 2 December 2016. From Amit Kumar Tyagi: ‘There are total 142 blocked scenarios, the reasons for the blockage of these scenarios is summarised as follows - 1) Blocked in PMS - 112 a) Finance unable to close period - 73 b) Reporting logic incorrect - 15 (5 scenarios have failed which were attempted full test of similar scenarios but the logic seems to be incorrect due to which these have been put as blocked) c) Test data creation in progress to retest and confirm - 8 d) User Training under progress to carry on testing - 2 e) The remaining 14 include Test Scenarios dependent on other Failed/Blocked Scenarios 2) Blocked in non-PMS i.e. Contact Centre, BPO, MIS etc - 30 a) Blocked by RBAC's - 27 b) Blocked due to other Failed Scenarios - 3 In addition to the blocked scenarios, there are total 87 failed scenarios (29 non-PMS and 58 PMS). The defects have been raised for these and are being discussed/reviewed during daily triage call. The defect summary has been skipped from this status update and will be continued from 05-Dec-16 daily status report.’ [PMS is Payment Management System; MIS is Management Information System; RBAC is Role Based Access Control] (4) On 9 December 2016, Ms Wagner rejected as unrealistic a plan to complete BPO UAT by the end of December. She asked for a realistic plan that could be delivered. The report also referred to the fact that ‘BPO have struggled… due to lack of resource on our part” and that the “test team have committed to providing us with two additional resource to aid the progress of retesting.’ (5) On 9 January 2017, Mr Bhatia reported internally that BPO UAT had “not gone well and the statistics [had] not been very encouraging so far…” (6) A status update on 20 February 2017 reported that there were still 87 defects in re-testing which it was hoped would be completed by 6 March 2017, following which there would be a round of regression testing (7) An internal TCS message on 1 March 2017 referred to the fact that BPO UAT had not been run as efficiently due to inexperience of the TCS BPO UAT team in running tests. (8) By the end of March (27 March 2017), Mr Foster reported the status as follows ‘Please find below. We have had no update from testing today due to the system being unavailable for nearly all of the day. With regards to Barring testing we are still waiting for the resolution of the outstanding cases from last week. The build team have made a number of updates to this but over the last week everytime an issue is fixed it causes a problem in another area.’ (9) Mr Swain of TCS disagreed with this characterisation of the problem, hinting it seems that it was the approach of the BPO team which was causing the problems: ‘I would disagree with the statement that everytime an issue is fixed it creates more problems. We meet several times a day on various issues, we can discuss and try resolve in an efficient manner if it's such a problem. I have given below an extract of fixes released/tested in last 2-3 weeks… We understand the criticality of this phase and try to ensure that you get the fixes as soon as possible.’

“The Agreement was awarded on the basis that physical hosting of the CONTACTOR’s solution would be provided via an existing Home Office contract. Prior to contract award, the AUTHORITY was directed by Cabinet Office to market test virtual offerings from the Cloud. This resulted in award of a contract for hosting to Skyscape. However, because of technical constraints later identified with the Skyscape solution, a further procurement was undertaken and the CONTRACTOR provided support to that procurement exercise to ensure its technical requirements were met. Consequently, to ensure the deployment of a more resilient infrastructure in support of Release 1 (R1), the AUTHORITY awarded a contract to [HPE] on 29th August 2014. This solution is a mix of physical and virtual, rather than pure physical, as envisaged by the Agreement. […] The CONTRACTOR shall undertake its roles and responsibilities in relation to implementation and delivery of service management activities and operation of the technical interfaces required to enable hosting of the CONTRACTOR’s System on the Hosting Platform procured by the AUHTORITY from [HPE] in accordance with Application Management responsibility Matrix ver1 and Schedule 2-6 of the Agreement, as amended for the purposes of this CCN. […] IT IS AGREED that with effect from the CCN Effective Date the Agreement shall be amended as set out in this CCN, and save as herein amended, all other terms and conditions of the Agreement inclusive of any previous CCNs shall remain in full force and effect.”

‘In or around January 2016, the parties agreed that the Claimant would pay the Defendant the sum of £4,559,439 to compensate it for the delay up to 31 March 2016. The parties also agreed that the Go-Live date for R1 Barring would be revised to 15 September 2016, the Go-Live date for R1 Basics would be revised to 1 January 2017 and the Go-Live date for R1 Disclosure would be 28 November 2017…. … The Claimant could not have delivered R1 Disclosure prior to the expiry of the Agreement or by the deadline of 28 November 2017, nor can it establish an entitlement to an extension of time for the reasons given in paragraphs 39-42 above.’

‘I am instructed that between 29 June 2016 and 19 December 2016, DBS agreed that TCS would focus on Barring and Basics, with Disclosure to be delivered afterwards. DBS's claim is on the basis of an envisaged Go-Live date of 28 November 2017.’

‘I think that's very important, for the court to really understand the difference between where we were in September 2017 versus where we were in May of 2018. So what I mention in my evidence, in my witness statement, was that before September 2017 we had finished CIT and SIT of Disclosure, and at that point in time the software was ready to enter Final SIT, and I stand by that. If the Disclosure environment was available, had it been available at that time, had the third parties been ready at that time, including registered bodies, we would have been ready to enter Final SIT back in September 2017. That's still a valid statement. Now, if you see -- if you see, if you fast-forward to what happened in the six or seven months between then -- that time frame and May 2018, a lot of things have changed, a number of RFCs, requests for change, landed in our bucket and many of them were stated as must have for R1 Disclosure, including the RFC 417 content inspection for Helion-G. You may remember, we said Helion-C was mandatory for Barring release and the back-end of that was mandatory for Disclosure release. So amongst many things, there were several new things that we introduced between Barring Go-Live and this time frame we are looking at, the email. So it is true that I said we finished CIT and SIT in 2017 and we would have wanted to -- we wanted to enter Final SIT at that stage, but because the other thing happened, other changes being introduced, we were not ready to jump into Final SIT in May 2018. So I say both are valid statements.’

‘A significant amount of work is still required to understand the solution for Standard and Enhanced Disclosures, and also the implementation and migration approach for the Registered Bodies (RBs), before we consider involving them in System Integration Testing. DBS currently have over 160 organisations that submit nearly 4million Standard and Enhanced Disclosure Applications. Some of these Disclosure Applications exist within the RB systems or the DBS systems for up-to 6 months. So far, within the R1 solution for Standard and Enhanced Disclosures there is no consideration for a phased migration of the RBs to migrate from R0 to R1, or how the solution implementation will provide business continuity for all the RBs during the R1 Disclosure Release. Experience (from the Digital Connect Hub project) and feedback from the RBs has already informed DBS that the solution cannot be implemented in a “Big Bang” approach for all RBs, and in fact the migration will take a number of months.’

‘DBS has indicated that there may be RfCs that are required (Must Have) for Disclosure. However the list is neither firmed-up nor agreed. Hence there is a risk that code changes to accommodate the Must-have RfCs may be deployed to Test Environment, while Final SIT is underway.’

‘My thoughts are that we should completely shut down R1 transformation, have a lean team to debate on finalising the list of 52, and purpose re start, only on the finalisation of the list and the scope. Our argument would have to be that the list of 52, along with the decisions that DBS has to make on strategy of disclosure release, makes it impossible to finalise the scope and strategy of our delivery. I feel we will continue to burn heavily in any pursuit to deliver Disclosure, without containing its scope or re work.’

‘This is in line with what we discussed. Let’s scale down our R1 team drastically and not entertain any planning discussions until we resolve the 52 (or 38 as I understand) outstanding issues.’

‘Deployment scope and date is still under discussion with TCS Lessons learned from Barring and Basics deployment will inform strategy e.g. data migration eRB transition Protection of DBS live service remains the priority.’

‘All RBs must be able to submit applications into R1. This will require RB’s to be transitioned off R0 and onto R1 over an agreed period of time…. The solution must ensure that at least 6 months’ notice of the change is communicated to RB’s. … If the change is not implemented, there is a risk that RBs will not successfully transition onto the R1 service, leaving them without an electronic channel to submit applications. DBS will not be able to cope with the volume of paper applications if RBs cannot submit applications electronically and, as a result, revert to a contingency process…’

‘As discussed in my first report the challenges of migrating a large number of RBs from R0 to R1 was not a new issue as moving all 170 e-RBS from one interface to another simultaneously would always have been very challenging, if not impossible, to achieve. TCS’s Data Migration Strategy does not consider this issue, it focuses on identifying data that needs to be migrated from R0 to R1 in a ‘big bang’ approach. I have not been able in the time available to identify what approach TCS intended to take to RB’s prior to RFC 607 but note that they appear to have included an R0-R1 bridge which would be tested as part of SIT 253. This would presumably have allowed data to flow between the systems during parallel operations. I agree with Mr Britton that the parties’ apparent inability to agree an approach to data migration introduced significant uncertainty and made it difficult to produce a complete plan. However, it does not appear to have affected TCS’s ability to enter Final SIT.’

‘Indeed, any plans for R1 Disclosure were disrupted because we always thought we had an agreed plan for data migration, but DBS said that they wanted to change the approach. Standard and Enhanced Disclosure checks were already taking place and so there was a lot of existing data to migrate. The planned approach was a "big bang", meaning we'd shut down the legacy system and start with R1 Disclosure at once. This was a complex data migration project with a huge data volume. In early 2018, DBS said that there was a huge risk that the RBs would not be ready and therefore the "big bang" data migration approach would not work. DBS no longer had the appetite to take that risk. I first heard about this from Amit, who had received the message from Peter Evans. An RFC was raised (RFC 607) to stagger the data migration and create a new solution where an RB could exist and send applications in both legacy R0 or R1. I felt this was a very significant change.’

‘Both, Thank you for meeting Paul [Whiting] and I today. I found the meeting very helpful in outlining our positions and agreeing how we will take forward the forthcoming commercial discussions. Commercial issues At our meeting today we agreed the scope of the commercials that have thwarted progress with the remaining disclosure deployment. We agreed that the discussions should consider all matters as a package with a view to reaching agreement on a safe delivery of R1 disclosure as part of an agreed extension period. The individual elements to be discussed being: Disclosure scope; to include phased RB migration Ticket price and volumes; this can include proposals for a revised payment mechanism for the extension period and a review of basic volume forecasts for 17-18, and other forecasts for the final year of the contract R0 extension costs; taking into account risk and additional cost to run the service Cause for delay In order to maintain progress with the disclosure planning, in principle DBS agreed to consider the actual additional third party costs accruing to TCS above the 110% threshold for 2017/18, subject to these being appropriately evidenced.’

“Following the productive joint meetings that have taken place between colleagues in India and in the UK, we have reached joint agreement in principle for the Disclosure re-planning exercise, subject to validation of one commercial matter to be concluded by close on Monday 12 February. Both teams are therefore commissioned to conduct a joint re-planning exercise that will result in a Disclosure delivery date and broad cost proposals for agreed changes to scope. This is to be agreed by 23rd February to form part of the formal negotiations that will take place week of 26 February.”

‘…Plan indicates a Disclosure Go-Live of July 2019 which is driven by TCS assumptions. [Mr Evans] agrees that the plan is viable/achievable but contains no contingency although may contain some optimism bias. Large part of plan is taken up by eRB transition with an overall total Programme cost of approximately £19.5m to reach Disclosure Go-Live.’

‘11. Disclosure plan ‘[Amit Shah of TCS] advised that the plan as presented has already moved by four weeks and that R1 PB should not look at dates but what needs to be done. This plan is more activity driven with the first item on the critical path being RfCs, then when these are finalised will move onto GDPR and then stakeholder readiness. …His biggest worry on the plan is RfCs, data migration and scoring on Update Service profiles as this will also generate lots of work for DBS. AS feels that these items are captured in the plan.’

‘DBS have taken the decision to not proceed with this RFC. DBS position is that the parallel running of R0 and R1 was discussed between the technical teams in order to prevent TCS to have to write complex migration rules for in-flight applications. However as was discussed and agreed in the forum, data migration is a TCS responsibility and as such, if this is the approach that TCS wants to take the decision rests with TCS. Any period of time during which both applications need to be up to enable DBS to complete the in-flight applications in R0 because TCS have elected not to migrate the in-flight applications is at TCS own cost. The transformation tool will allow all applications to be submitted into R1 from the point at which it goes live so the only reason for R0 to not be decommissioned is to allow DBS to complete the in-flight applications which TCS have chosen not to migrate until they are complete in R0. So, currently DBS do not view this as requiring an RFC.’

‘3. The major dependency is on eRBs; with DBS holding the line that the eRBs need 6 months notice before implementing any changes. DBS will not engage with the eRBs, because the ICD has not been approved. We are waiting for the GDPR change to be raised and approved before updating and issuing the ICD. I think we should make any corrections to the ICD, resulting from the Barring / Basic release, and issue the ICD as it is. When the GDPR RFC is approved we can commence work on the changes. 4. Although the availability of eRBs appears to be on the critical path, the introduction of the bridge means that R1 Disclosure can go live without eRBs converting to the new R1 solution. 5. The availability of MET to engage with us to progress Final SIT. MET are likely to be available by the end of May. However, MET do not have to make changes to consume the Web Service. 6. ANI being ready to participate in Final SIT. ANI / DBS are disputing who should pay for changes to the ANI systems. This probably won't be resolved until the end of May and then ANI's suppliers will have to make the software changes; which would take approximately 4-8 weeks to develop and test. 7. Disclosure Scotland's availability to participate in Final SIT. They are unlikely to be available until the end of May or later.’

‘The concept of parallel running was accordingly proposed by DBS in its first problem statement and then planned by TCS in order to assist DBS. For DBS to now assert that RO/R1 Disclosure parallel running is a TCS requirement so as to avoid migration of in-flight applications is very disappointing and disingenuous. It appears that this is another case of DBS again trying to unjustifiably shift blame to TCS for changes to implementation of R1, when the primary driver for RU/R1 parallel running was a change in DBS' risk appetite concerning the approach towards service cutover. If, as your emails dated 25th April 2018 (previously referenced), and also the updated Rfc 607 (v1.4) seem to suggest, DBS does not require this change then TCS will revert back to its original solution, i.e. TCS will plan to migrate all in-flight RU applications to R1 in a single migration, with no requirement for parallel running. We will now re-engage with DBS to agree how we move forward with in-flight application migration and we will move ahead on the basis that DBS have now accepted the risk that comes with this approach.’

‘…So, again, I know this is not your letter, of course, it's a TCS letter, but if you agree with the first sentence, as I have just asked you about and as you've indicated that you do, then it does follow, doesn't it, that in fact R0/R1 Disclosure parallel running was not in fact the idea of or a request of or arose from something on the TCS side, it arose from something on the DBS side? A. Yes, that -- that's my understanding.’

‘The team will cease to work on any disclosure activities. This will include ... releases in drop 8, drop 8 review items, drop 8 defect fix, PMS development, drop 8 ... including PMS testing.’

‘• That their priority is to protect the live service; • No option is without risk and on balance Board agreed that the revised plan provides the best approach to manage the risk and protect delivery of the service. • That R1 performance is not acceptable and therefore too risky for disclosure; • It is more complicated to build a new R1 platform with another provider for disclosure to then disaggregate from it; • That should we not pursue R1 Disclosure and therefore DBS doesn't need to continue with TCS This recommendation is to continue with the preferred course of action to negotiate with TCS in order to securely exit the current contract.’

‘As you are aware, a detailed plan must still be agreed between the parties before we can continue with delivery of R1 Disclosure and it is incorrect and wholly impracticable for you to maintain that TCS should have continued to plan implementation whilst DBS had, at the same time, engaged TCS' migration resources (via RFC 607 and various workshops) to consider a different approach to migration, including parallel running of RO and R1 Disclosure. DBS made clear this was to assist with the staggered onboarding of Registered Bodies to R1.’

‘One of the issues in the dispute resolution procedure was the treatment of the so- called “Deferred items” and the timetable for delivery of Disclosure. It was clear, even in September 2017, that the parties would need to agree a timeframe for the delivery of Disclosure, which was (at that point) promised for November 2017. Since then, the parties have been unable to agree how to proceed with the project. In the circumstances, as a result of the Delay, our client sees no way that Disclosure can be delivered before expiry of the Term. In any event, the serious issues with Barring and Basics require urgent resolution before any further work is done.’

‘The project continues to be affected by poor planning. For example, TCS’ specification for the mapping and migration of disclosure data lacks detail and there remains a considerable amount of effort to complete the mapping specifications to the standard required. The strategy for migration of profiles and the update service subscriptions is reliant on manual input and support from DBS. No data cleansing strategy or rules have been published and therefore DBS cannot make an assessment of the extent of the necessary data cleansing tasks. DBS has no confidence that the data migration activities, a prerequisite for the delivery of Disclosure, can be performed before expiry of the Term. DBS has also repeatedly expressed concern about the fact that TCS wishes to migrate the data over nine days (one “big bang” cut-over event), rather than finding ways to make the task more manageable, less disruptive and risky. In short, TCS’ plan takes no account of the very serious issues experienced with data migration to date and it does not address the fact that DBS would not be able to operate its services during the nine-day cut-over period. Further, TCS expects to migrate all the Registered Bodies at once. There are around 2,000 Registered Bodies which are all independent of DBS. They do not all have the capability to develop and test a new interface to DBS without assistance. It is not sensible to assume that they could do this work within the 9 day cut-over window and, in any event, TCS has made no plan for this. The migration of 45 Registered Organisations to the new Basics platform required extensive planning and took 6 months. … There is not sufficient time within the remaining Term of the Agreement for R1 Disclosure to be delivered, even if TCS had a credible plan for delivery. TCS has missed the contractual Milestones already and it has also failed to meet its own subsequent deadlines. There is no realistic prospect of TCS delivering R1 Disclosure in accordance with the Agreement, whether within the remaining Term or at all. The breaches of clauses 3-6, the failure to produce Remedial Plans, the breakdown in the Contract Change Procedure (Schedule 2-7) are a result of TCS’ defaults. … DBS is entitled to rely on clauses 55.11-55.15 (the Partial Termination provisions) and thereby to invoke the Contract Change Procedure so as to remove R1 Disclosure from the scope of the Services. …DBS is actively contemplating exercising its right to rely on clauses 55.11-55.15 to remove R1 Disclosure from the scope of Services as identified … above.’

‘This letter is one month’s Notice, issued pursuant to clause 55.11. As set out in the letter from the Authority’s lawyers, Bristows LLP, dated 18 September 2018, TCS: 1. is in material default of the Agreement and such default or defaults are not capable of remedy; and/or 2. is responsible for material default(s) that have not been remedied in accordance with the Remedial Plan Process. These Defaults have already prevented the delivery of the new, modernised functionality known as “R1 Disclosure” (defined in Annex 1) on time or within the current Term of the Agreement. The Authority is therefore exercising its rights to vary the Agreement using the Contract Change Procedure, to remove R1 Disclosure from the scope of the Services, in reliance on and in accordance with the procedure set out in clauses 55.11 and 55.14.’

‘What was not clear at that time was if the functionality of citizens submitting the Basics Disclosure applications and the associated system-driven checks for the Accountable Officer ("AO") would work fine in the R1 Disclosure code base in spite of all the RFCs on the related functionalities. There were also some very key open questions about the AO verification process which needed to be clarified by DBS. (For example, under the original scope, the AO themselves needed to first submit a Basic Disclosure application in the R1 system so that they could be vetted; also the AO needed to have an active subscription for a recurring check called "The Update Service". With the original RFC all these functionalities were suppressed in the R1 B&B codebase and we were unclear whether DBS were looking for bringing back all these features when R1 Disclosure goes live.) So overall, while we had already completed the CIT and SIT on the R1 Disclosure, we were unclear on how much rework will be required based on what DBS may decide on the inclusion or exclusion of this citizen-facing functionality in the R1 Disclosure code base. I recall estimating approximately 100 person days' worth of effort for removing this functionality from the R1 Disclosure code base and testing it. This work had to complete before we could formally commence Final SIT.’

‘2.1 Under this Contract Change Procedure: … 2.1.5 no proposed Change shall be implemented by the CONTRACTOR until such time as a Contract Change Note (CCN) has been signed by both parties and issued by the AUTHORITY in accordance with paragraph 6.4. … 2.3 Until such time as a CCN has been signed by both parties, then, unless the AUTHORITY expressly agrees otherwise in writing, the CONTRACTOR shall continue to provide and make available to the AUTHORITY the Services in accordance with the existing terms of the Agreement. 2.4 Any work undertaken in connection with any Changes by the CONTRACTOR, its Sub-Contractors or agents (other than that which has previously been agreed in accordance with the provisions of paragraph 2.3 of this schedule 2-7) shall be undertaken entirely at the expense and liability of the CONTRACTOR unless otherwise agreed between the AUTHORITY and the CONTRACTOR in advance. 2.5 Any discussions, negotiations or other communications which may take place between the parties in connection with any proposed Changes, including the submission of any written communications, prior to the signing by both parties of the relevant CCN shall be without prejudice to the rights of either party…’

‘Subject to the provisions of clause 56 (Remedial Plan Process), the AUTHORITY may, by one (1) month's prior written notice, require the Partial Termination of any part of the Services on the occurrence in relation to that part of a material Default by the CONTRACTOR, where the Default is not capable of remedy or, if the Default is capable of remedy, the Default has not been remedied in accordance with the Remedial Plan Process.’

‘56.2.1 The AUTHORITY notifies the CONTRACTOR that it considers that the CONTRACTOR is in material Default and that it requires a Remedial Plan. The notice may specify the matters complained of in outline but must contain sufficient detail so that it is reasonably clear what the CONTRACTOR has to remedy. 56.2.2 The CONTRACTOR shall serve a draft Remedial Plan within 20 Working Days (or any other period agreed by the parties) even if the CONTRACTOR disputes that it is responsible for the matters complained of. 56.2.3 If the AUTHORITY considers that the draft Remedial Plan is insufficiently detailed to be properly evaluated, or will take too long to complete or will not remedy the matters complained of then it may either agree a further time period for the development and agreement of the Remedial Plan or escalate any issues with the draft Remedial Plan using the Escalation Process. 56.2.4 If despite the measures taken under clause 56.2.3 a Remedial Plan cannot be agreed within 10 Working Days of the date of its submission then the AUTHORITY may elect to end the Remedial Plan Process at the end of the escalation period set out in the Dispute Resolution Procedure and serve a Termination Notice which will take effect unless the CONTRACTOR remedies the Default within a period specified in the Termination Notice which shall not be less than 30 days from the date on which the Termination Notice is sent to the CONTRACTOR … .’

‘The question then is what is meant by the word ‘remedy’

‘It seems to me that the whole purpose of a provision in a contract by which a party contemplating the determination of the contract for breach on the part of the other party has to give a notice, if a breach is capable of remedy, is to give the party in default the chance to avoid the consequence of termination of the contract if, in substance, the other party can, at the point at which notice is given, be put in the position in which he would have been but for the breach. It is difficult to see how such a provision could be of any practical utility if the fact that the date for performance of a positive obligation had passed meant that the breach of that obligation was to be taken to be irremediable, even if it could be performed late. Until the last date for performance had passed there was no breach. It would be strange if in those circumstances, the moment there was a breach that breach was irremediable, however quickly thereafter the obligation could be performed. …’

‘[Janette Cowburn, DBS Associate Director for Commercial] advised she assumed TCS representatives were aware of the conversation between Adele Downey and Shankar Narayanan during which Adele had informed Shankar that DBS would not be continuing with R1 Disclosure and that its preference was for a 6-month extension only. This was due to be communicated formally shortly. CO suggested, and it was agreed, that the SLA action discussions be recommenced once this formal notice had been provided.’

‘Establishment of a Service Transition programme to exit from TCS as soon as operationally feasible, and no later than March 2021 … The business case proposes a contract extension to be applied flexibly — we currently plan to extend for six months to allow for transition to the new arrangements by September 2019.’

‘… I'll get you the range -- so the 3.6 is at the bottom of the range, the 9.7, the overlap with Mrs Wall, is at the top of the range, and then I think the figure that I promote is 1.5 million less than that, depending on whether you accept Mr Padannayi's evidence that the payroll costs in the final month for which we have data available carries on through to the end of the contract.’

‘The AUTHORITY has undertaken an assessment of the delay and has claimed cost impacts from the CONTRACTOR. Pursuant to clause 6.3.2 of the Agreement, since the CONTRACTOR’s delay will be more than six (6) months, the AUTHORITY calculated its actual additional costs incurred as a result of the CONTRACTOR’s failure to Achieve Milestone GL R001(a) (Go Live of Phase 1 Barring – 17/12.2015) and GL R001(b) (Go Live of Phase 2 Disclosure – 31/03/2015, rather than relying solely on the Delay Payments provisions in the Agreement. While the AUTHORITY’s calculation indicated that it has incurred costs of more than £6.2m (inc. VAT), this figure was not agreed by the Parties and following further discussions the AUTHORITY has agreed to accept CONTRACTOR’s offer to pay damages in relation to the failure to Achieve Milestone GL R001(a) (Go Live of Phase 1 Barring – 17/12/2015); and failure to Achieve Milestone GL R001(b) (Go Live of Phase 2 Disclosure – 31/03/16) (together the “Breaches”), for the sum of £4.56m (inc. VAT) (the “Settlement Sum”). The CONTRACTOR shall, within seven (7) days of the date of each monthly Service Charge invoice provide a credit note to the AUTHORITY for the monthly sum of £316,666.66 (exclusive of VAT) to reimburse the Authority in respect of additional costs it will incur during the period of twelve (12) months from the CCN Effective Date. In the event that the entire Settlement Sum cannot be applied against future invoices within the period of twelve (12) months, the remainder of the Settlement Sum shall be paid immediately to the AUTHORITY upon written notice of the same, and such sums shall become a debt, together with any interest accrued in accordance with the Late Payment of Commercial Debts (Interest) Act 1998 … 7. CCN Effective Date (The date upon which changes to the Agreement are to take place). [INSERT]. IT IS AGREED that with effect from the CCN Effective Date the Agreement shall be amended as set out in this CCN, and save as herein amended, all other terms and conditions of the Agreement inclusive of any previous CCNs shall remain in full force and effect.’

‘There was a delay at the end of 2015 which is recorded in the unsigned copies of CCN 041. I remember this document because CCN041 was never signed off and therefore it was something that always appeared in our logs and meeting minutes. Also CCN041 was the first time TCS “held their hands up” and volunteered that they were responsible for delay. The sum recorded in CCN 041 was agreed (£4.56 million) and was never changed or disputed by TCS. In return for the delay payment, DBS also agreed to new dates for delivery of the Milestones at the end of 2016. However, whilst TCS and I were in the process of negotiating and writing up the wording CCN 041, there were more problems with the project which made DBS conclude that the new Milestones (at the end of 2016) were at risk of being missed as well.’

‘I remember participating in the discussions about the delays in 2015 which were caused by TCS (CCN041). I worked up the figures to calculate DBS losses in order to put them to the R1PB. Afterwards, I recall that negotiations with Mike McCarthy of TCS began. It was agreed that TCS had caused the delay and the sum itself was agreed and never in doubt. However, from my recollection, the change request itself was never finally agreed because it included additional points which TCS would not agree. Colette Owen was heavily involved with this.’

‘CCN 041 for the R1 Delay (September 2015) is yet to be signed. This now forms part of the commercial negotiations for the R1 Delay (July 2016).’

‘BH explained that the new letter of direction from the Minister was slightly different to previous letters of direction as it extended direction up until end June 2[0]18, if required. DBS has agreed a transition plan with Disclosure Scotland between 1 September and 31 December. These dates have been communicated to staff and Responsible Organisations (ROs). The transition plan is a phased approach over four months and will leave Disclosure Scotland with 10% of volumes. PCS welcomed the new letter of direction but was concerned because the transition was taking place during a time of peak volumes for DBS and Disclosure Scotland. BH advised the dates had been carefully considered but due to Disclosure Scotland’s contract with BT ending in March 2018 and FTE contracts ending, transition by December was most viable. BH confirmed the phasing approach was designed to deal with peak volumes and DBS was working with ROs to identify the most appropriate time for them to onboard. DBS had proposed to second staff to Disclosure Scotland to support the transition period. Due to other matters formal consultation on the secondment proposal had not yet commenced….’

"... to deal with peak volumes ..."

"... DBS was working with ROs to identify the most appropriate time for them to onboard."

‘In around May 2016, some work was started by Dawn Wayman, Head of Service for R1 Transformation in Barring, to try to forecast savings that would be achieved from delivery of R1 in Barring. To do this, the WFPM was looked at with a view to stripping out the functions that would be replaced by the R1 Solution (or transferred to TCS’ back-office processing) and to calculate the anticipated savings. I knew this wouldn’t give us an exact answer as to savings, because the WFPM was not a perfect reflection of existing workloads and the lack of visibility of the R1 solution meant that we did not yet fully understand the additional work that would be created by the changes to our processes. However, I accepted, based upon what I was told by Dawn Wayman, that such an approach would provide us with a usable estimate.’

‘Following that work I have written separately to Jenny on the R1 impact (current and future). I think it is wrong to focus on the removed tasks and a more holistic approach is required. Persisting in discussion with PCS around FTE reductions based on removed tasks, when their members are experiencing greatly extended timescales and increased effort in key processes is possibly not the best approach. Experience now shows that the previous analysis that informed the DLOD was very much guess work with no timings produced for existing or new processes in R1. There is therefore an urgent need for the completion of a WFPM for Barring for R1 based on timings / effort in R1 to produce an accurate picture re: any savings / required staffing. Jenny will obviously have a view on how to approach the meeting on the 20th however I have no longer have any confidence in the DLOD figures and would not want to persist in offering them as an accurate assessment of R1 impact.’

"There is therefore an urgent need for the completion of a WFPM for Barring for R1 based on timings/effort in R1 to produce an accurate picture re: any savings/required staffing."

‘The Solution will deliver capability and systems to support the Authority’s following strategic principles: [at least 50% of barring referrals online by Year 2 and 90% by Year 5 and 95% of applications made online by Year 5].’ (3) Clause 1.2.1.1 which states: ‘The portal will be designed to accommodate different types of usages, ranging from very occasional (e.g. an Applicant requesting a Disclosure) to very frequent users (e.g. a Registered Body checking applications every day). To that effect, the user interface will be clear, intuitive and optimised for efficient use, as well as customised for each type of user (e.g. an Applicant will have a dedicated, simple user interface; whereas a registered body will have access to more functions).’ (4) Clause 1.2.1.2 which states: ‘The portal will be designed to facilitate self-service: i. Easy navigation throughout the website, via navigation toolbars, breadcrumb and easily accessible shortcuts; ii. Powerful search engine that will allow a user to find information anywhere on the site; iii. Guidance through contextual help, regularly updated FAQs, etc. iv. User profile management for users to manage their credentials, preferences and personal details; v. Access to information such as previous applications, Case-related material, etc. stored in the document repository; vi. Access to business services & products such as Disclosure applications (basic, standard or enhanced), status checking, referrals, etc. The user journeys will be facilitated by wizard-type interfaces and online form validation; the Solution will also allow the users to save drafts and resume interrupted processes (draft applications will be stored in the secure database.’

‘The Contractor will conduct a requirements elaboration stage and the subsequent iterative development of the solution design and its build as described in the modified waterfall method.’

‘The Contractor will use a modified waterfall approach (with Waterfall as its main philosophy but with characteristics of the Agile integrated within it) in the development of the modernised Solution for the Authority.” And “The Contractor will use a modified waterfall approach (with Waterfall as its main philosophy but with characteristics of the Agile integrated within it) in the development of the modernised Solution for the Authority.’

‘Mr Britton and I agree that TCS adopted a primarily waterfall based approach to the project, although as discussed in my first report their ‘modified waterfall’ approach explicitly included the use of prototypes. I agree with Mr Britton that it is difficult to switch to a fully Agile approach mid-project and this would have required a change in the contractual framework to align milestones and so on to the new approach. However, TCS did move to an iterative delivery and test approach, which they described as Agile, and incorporated some Agile-like techniques in their initial design approach.. …’

‘The enclosed spread sheet lists all the standards and legislation that have been referenced from Schedule 2-2, 2-12 and 2-16 (Reference 3, 1, and 2 in 1.5 Document References) and identified based on discussions with the Authority during the Standards Non Functional Workshops.’

‘Where parties by an agreement import the terms of some other document as part of their agreement F those terms must be imported in their entirety, in my judgment, but subject to this: that if any of the imported terms in any way conflict with the expressly agreed terms, the latter must prevail over what would otherwise be imported.’

‘DBS need to resolve the GDS issue with TCS in the PM [Project Management] & commercial world but meantime I wanted to see if we could get the technical documents moving forwards. My suggestion is: We make an assumption that a CCN will [formally] bring into scope GDS for TCS. We document that assumption [formally] in the Standards Catalogue and then include the appropriate GDS standards in the catalogue. … I’ve discussed this with Fran [Sands] & Guru [Dsor] and I have sat down with Guru and put together some proposed changes to further this suggestion. …’

‘Following today’s call please find attached the report produced by the Home Office User Researcher who visited last Friday I would like to add some context before you read.... You may aware that the logistics of the day did not work very well in terms of access to the necessary environments As a consequence the assessment reinforces some of the initial feedback received regarding the GDS/HO view on the ‘user journey’ - The 1st pass Service Assessment (last 2 slides) is overly harsh in my view & separately I will address points such as Iterate/Open Source/ Test end to end/Offline/succeed first time/performance data etc... which DBS would have a different view’

‘DBS to workshop with TCS around usability issues and timescales for fixes.’

‘User Research and Test Phases User research will provide suggestions to improve the user experience. They would be prioritised for the first 1 January launch and expected to be largely cosmetic and contain nothing to derail the build. It is vital that the new system is something that customers want to use otherwise there will be potential for reputation damage and complaints. PB believes that September is the best time to decide as there will be significant progress made over the coming weeks. Resources need to be focussed on this delivery. TCS confirmed they have a ring fenced team in place to make this happen.’

‘Customer Experience User research was a requirement for TCS to carry out which has not been undertaken. Chair visited India in April 2016 during which she received assurances from TCS [Aarthi Subramanian] that any changes to the Basics solution as a result of user research would be delivered. PB requires TCS to honour the commitment. Home Office Digital (HOD) is sending a User Researcher to DBS on Monday [8 August] to commence work on this.’

‘I remember that TCS’ lack of user testing and agile development in response to user feedback was a significant issue…I also recall that TCS originally had no plans to implement web analytics into the Basics Portal to obtain performance metrics on their usage which I found surprising, and demonstrated to me TCS lack of experience in delivering web solutions to UK government.’

‘DBS, HO and GDS are developing a “minimum viable product’ which is undergoing user research and usability testing. These are planned up until 28 Nov. LK said that a meeting was being scheduled for 7 Oct, to discuss the potential impact on the DBS Release 1 portal.’

‘RFC 522 relieves TCS from its obligation to deliver the Basic TCS web portal for citizens, as well as removing the need for TCS to manage payment collection and identity verification. This entails in suppression of Basic online Application services for the citizen. The Update Service for Basic product is to be rolled out at the time Standard and Enhanced Disclosure go live.’

‘In my view changes for usability were to be expected given the approach that TCS had taken to portal design and they should have planned to do user testing and incorporate the resulting changes into the portal. TCS’s failure to do so means that they did not comply with GDS or the standards of Good Industry Practice and failed to design the portals using the principles and benefits of early engagement and feedback as intended in their own modified waterfall methodology.’

‘22. There is a central flaw in the appellants' submissions. Some claims for consequential loss are capable of being established with precision (for example, expenses incurred prior to the date of trial). Other forms of consequential loss are not capable of similarly precise calculation because they involve the attempted measurement of things which would or might have happened (or might not have happened) but for the defendant's wrongful conduct, as distinct from things which have happened. In such a situation the law does not require a claimant to perform the impossible, nor does it apply the balance of probability test to the measurement of the loss. 23. The claimant has first to establish an actionable head of loss. This may in some circumstances consist of the loss of a chance, for example, Chaplin v Hicks [1911] 2 KB 786 and Allied Maples Group Limited v Simmons and Simmons [1995] 1 WLR 1602, but we are not concerned with that situation in the present case, because the judge found that, but for Mr Bomford's fraud, on a balance of probability Tangent would have traded profitably at stage 1, and would have traded more profitably with a larger fund at stage 2. The next task is to quantify the loss. Where that involves a hypothetical exercise, the court does not apply the same balance of probability approach as it would to the proof of past facts. Rather, it estimates the loss by making the best attempt it can to evaluate the chances, great or small (unless those chances amount to no more than remote speculation), taking all significant factors into account. (See Davis v Taylor [1974] AC 207, 212 (Lord Reid) and Gregg v Scott [2005] 2 AC 176, para 17 (Lord Nicholls) and paras 67-69 (Lord Hoffmann)).’

‘The Solution shall enable the AUTHORITY to issue a request to obtain local police information from its sources where there are indications that further information exists.’ (2) At Schedule 3 to the Agreement: ‘Local Police Forces interface, which will allow to capture Police intelligence in a standardised way for both Disclosure and Barring purposes through the web portal (see section 1.2.1). Police Forces and the Authority will be able to interact in order to share and discuss information through a dedicated space on the web portal. The routing of information will be governed by Business Rules.’

‘After looking into the examples and the requirement from Barbara i.e. to show the text formatted on the Portal Notification, I would suggest this to be an attachment solution as compared to enlarging the existing “Requested Information” box. As just enlarging the box might give us more space to write the information, but it will not keep the format when presented back on Portal.’

“18. In the R1 Barring system we input information into text boxes in the system. There are text boxes for, by way of example, background information and PNC summaries. Often those text boxes are not big enough to contain all of the information which we need to input. For example, the background information section has three separate text boxes for background information in case one is insufficient. 19. In addition the text boxes are very small perhaps an inch and a half in height and so, even in cases where the boxes are large enough to contain the information you need to input, after inputting more than a few lines of text the preceding text is no longer visible within the box and it is necessary to scroll within the box to check what you have previously drafted. This is particularly an issue within the evidence evaluation tab. The evidence evaluation text boxes are even smaller than those in the background information tab, because the screen appears in a table form and so the boxes are much narrower in length. 20. In carrying out an assessment it is often necessary to move between tabs to review information to draft our summaries. We might need to go back and amend what we have inputted within text boxes as a result of further reviews and in that case we have to scroll within the box to check and amend what we have previously drafted. 21. As a result I draft information for data input in a separate Microsoft Word document and then cut and paste that over to the text box. It is simply not possible to efficiently and accurately use the text boxes solely due to the amount of information I need to input and the manner in which it is presented within the system. So far as I am aware, all other Caseworkers also use the same workaround. This workaround would have been unnecessary if, for example, the text boxes had a button which “popped” the box into a bigger screen for data input or review.”

‘Schedule 2-2, 2.21.8.18 The Solution shall enable the AUTHORITY to redact Case information on the DBS Technical Infrastructure that must not be disclosed in accordance with Business Rules [ … ] Schedule 3, 1.2.4.2(a)(viii) Bundle Creation [ … ] the Solution allows for the production of Case Bundles (e.g. at the ‘minded-to-bar’ stage). The bundle module provides two main functions: firstly to organise the information so that it can be distributed as a bundle, and secondly to support the redaction of information as a part of the bundle creation process […] Schedule 3, 1.2.4.2(a)(ix) For the redaction support process, rules will be established to allow for certain data fields to be removed or obfuscation rather than used in their actual data form. Also some documents in a Case will need to be duplicated and then some information redacted so that the redacted version is the version brought forward for the purposes of generating a bundle.’

‘I don’t have a case with over 50 pages but I have done a bundle this morning with 42 pages and it was horrendously slow. I could have gone to make a cup of tea each time I tried to move down a page.’

‘However all options have similar issues related to delivery timeframe, cost and technical risk. The option described in the RFC (2, above) is considered the best compromise of deliverability, cost and technical risk. The only option without technical risk is (3), but that would be very expensive and likely to have a major impact upon the dates.’

‘the Solution shall enable the AUTHORITY to identify and request a Case file that is archived off-site’, (2) Clause 2.25.6.7 of Schedule 2-2: ‘the Solution shall enable the AUTHORITY to record the returning of case files where appropriate to an off-site location following the conclusion of case’. (3) Section 1.1.2 of Schedule 3: ‘The Contractor will also provide a scanning facility to digitise any historic document that is required as part of an operational business process’; (4) Section 8.3.7(e)(ii) of Schedule 3: ‘The Contractor will scan paper files on a ‘as and when needed’ basis as new documentation for a Case enters the system workflow via the scanning process…’

‘The process currently referenced in Schedule 3 for ah-hoc scanning of paper files would commence from R1 go live. There is no discernible end date to this process. The impact of this is that there will be ongoing delivery and return of boxes between TNT and SPS. Boxes may be opened on numerous occasions and it will be necessary to keep a record of which files have been removed and which remain. The DBS will also not achieve its goal of a fully digitised solution. This will impact on the DBS’s ability to answer any questions and requests for information that come out of the Independent Enquiry into Child Sexual Abuse (IICSA). It will also slow down our ability to work on reactivated cases and new referrals for existing profiles. The affects our efficiency in dealing with appeal, reviews and referrals. It also affects our efficiency in dealing with Appeals, Reviews, SARs, FOIs and Parliamentary Questions.’

‘in some cases, the address data in the Autobar extract contains non-address data, for example it could contain phrases or abbreviations like “Register Sex Offender” or “RSO”. Clearly, we cannot accept this data being accepted as port of the address held on Siebel and the system absolutely cannot issue out an automatic notification with any such entry … can you explore the possibility of the system “sense checking” address details.’

‘The Defendant must plead and prove how specifically alleged breaches caused each of the said workarounds, and the cost and effort associated with each breach. In circumstances where the Defendant maintains that workarounds have persisted for years, including with a new supplier, the Claimant infers: either the issues complained of are insignificant; or the Defendant has failed to mitigate its loss through proper documented workarounds at an early stage and by taking appropriate steps to address issues.’

‘For each of 27 workarounds relied upon, please identify: (a) The relevant cells in the spreadsheet for the workaround; (b) How the workaround arises from the eight respects in which the Solution is said to have provided a poor and outdated user experience at paragraph 99.16 (and which – by the Response to Request 51 – the Defendant limits its claim); (c) Over what period the Defendant alleges the workaround was employed (noting the Response to Request 51, which states some lasted only a few months). (d) How the alleged workaround is quantified as a specific financial claim.’

‘The losses claimed at Item #24 are the losses flowing from the impact of the cumulative effect of the breaches which impacted on the efficiency of the operation of Barring. The claim does not seek to attribute any part of those losses to specific breaches including those identified at paragraph 115.11 and/or 115.12.’

‘2.36.7.1. The CONTRACTOR shall ensure that, except with the prior written consent of the AUTHORITY (such approval not to be unreasonably withheld) all software (meaning, for the avoidance of doubt, all software that is used directly by the Users and all software that is used by the CONTRACTOR to provide, support and manage the Services) is maintained at the most recent (n) or immediately previous (n-1) general, stable version. … 2.36.7.3. For the purposes of this paragraph, "(n)" means the major version of the software, and for the purposes of this schedule, the "major version" shall be what a relevant governance and/or review board determines is a major version, based on information from the vendor of the software in question.’

‘You may recall, from our last meeting, Phil Jelley had asked the teams to come up with a 'Big Bang' plan to upgrade all the remaining components of R1 system. While we cannot have a detailed plan at this time until we carry out POCs, our teams have come up with a high level plan with proposed elapsed durations as below: Offshore delivery (including Testing): 88 days (4.5 months) Onsite delivery (Infrastructure): 50 days (2.5 months) Onsite testing: 21 weeks (5.25 months) Based on this, it looks like over 12 months of continuous work, even in a good scenario!! Offshore CRM team is speaking with TCS CRM COE to get more inputs and best-practices. Now that we have commenced the Service Transition activities, the real question is: are we going to go back to DBS with such a big bang plan?’

‘The CONTRACTOR shall provide resources of sufficient skills and experience to carry out the activities required to fulfil the CONTRACTOR's obligations under this schedule 2-11 and the Service Transfer Plan. In order to fulfil such obligations the CONTRACTOR shall make full use of staff allocated to the provision of the Services (at no additional cost) and, further, shall provide at no additional cost to the AUTHORITY up to 60 man days of additional resources to carry out any activities which the CONTRACTOR is not ordinarily obliged to provide in the course of the day-to-day provision of the Services. Any additional resources required by the AUTHORITY from the CONTRACTOR in order for the CONTRACTOR to fulfil its obligations under this schedule 2-11 and the Service Transfer Plan shall be provided by the CONTRACTOR upon the request of the AUTHORITY and may be charged in accordance with the charges set out in schedule 2-3 (The Charges and Charges Variation Procedure).’

‘3.2.2. Identification of all Services; The Services are identified in the contractual Documentation, specifically Schedule 2-2 (The Services, Service Levels, Service Credits and Implementation Plan) and Schedule 3 (Contractor's Solution), as well as any additional RFC's/CCN's. In accordance with paragraph 3.2.1 of this Appendix B, the PMO will hold copies of all assured and shared Documentation (including such Documentation relating to design, build, test, training etc.) and this will collectively allow the Authority to identify all Services.’

‘TCS will produce a Documentation master list. Such Documentation master list will be provided to the Authority via the PMO during the planning phase of the Service Transfer process. The Documentation Master List will be transferred to the Replacement Contractor after validation of the list between TCS and the Authority, followed by the Documentation itself. TCS' PMO already maintains a list of up to date assured and shared Documentation and this will form the basis of the Documentation Master List.’

‘36. Because there was little co-operation from TCS and because we had no insight into what TCS would and would not do when it came to service transfer, we were forced to put projects in place to manage service transfer almost as though all the services were already with DBS or transferring to DBS rather than with a supplier. Although the DBS teams for the R0 premises and Payment Processing insourcing would have needed to exist in any event, I suspect there were at least 14 people (covering 12 different roles) we would not have needed in normal circumstances, as the work would have been handled by the incoming and outgoing suppliers. For example, in relation to the Contact Centre workstream additional staff that would not have normally been required included Laura Lord, two project support team members who worked with her, Neil Donlan, Paul Kerr, and Andy Copas. Additionally, Gary Salisbury and Karen Dooley were with the programme for a short period prior to Andy Copas and Paul Kerr joining. In relation to the Technology Services, additional staff who would not have been necessary included Neil Bhatta, Ian Woodley, Jordan Vaughan, Dave Norden and Steve Bowering. Harveen Kaur also joined the programme later on to lead the server room migration and over the transition period itself. Many of these people were engaged as consultants through CACI Limited, although Jordan Vaughan was from BJSS and Paul Kerr was from Accomplish Management Consulting. Other roles would have been needed anyway, but ended up being needed for more work than should have been necessary. This included Dave Sheppard who was brought in to help with the pricing model for tenders, but stayed longer than would have been necessary to support more broadly on the Contact Centre piece. Jacqui Gerrard (engaged via Certus Advisory) was involved with TUPE for the Payment Processing workstream, but probably spent about twice the amount of time as should have been necessary to also support on Contact Centre and the Technology Services. There were also several DBS subject matter experts who were called on more than should have been necessary throughout the tender and service transfer process, due to the absence of constructive engagement from TCS. 37. Furthermore, we realised that the issues around replacing R0 with R1 and service transition were both significant and that we would need to protect service transition from being affected by the work required to replace R0 by separating them into 2 programmes. As such, DBS had to double up on programme resources in order to be able to focus on both programmes with separate teams. R0 was becoming more pressing and an increasing risk to DBS because of the legacy systems involved. The discussions on whether or not to continue with plans to replace R0 and the commercial conversations about whether TCS met their contractual requirements in replacing R0, all played into the relationship with service transition.’

‘1.1 The Authority is on a journey to transform the way in which it delivers its core services to the public. This began with the R1 digital Modernisation Programme, and will further evolve over the coming years with the potential expiry of the existing R1 Support contract in March 2019. 1.2 The Authority is currently working through its options to transition the existing Application Technology & Infrastructure delivery model, but will require expert external support in all aspects of the exit & transition programme. 1.3 The timeframe is likely to be challenging and continuity of services is paramount for a safe transition. The future model is likely to be a partly disaggregated model rather than a "big bang" single supplier shift. 1.4 A small programme has been established and the Programme Team have created a roadmap with timelines, activities and dependencies, it is anticipated that the Authority will appoint a Transition and SIAM partner/s to deliver the transition and manage suppliers post transition. 1.5 DBS do have some technical, commercial, administrative and management resources already allocated to the programme team and if required more can be drawn upon to support delivery.’

‘2.8.4 If the Actual Transaction Percentage exceeds 110% (one hundred and ten percent) then the Transaction Charges for the subsequent Service Year may, at the Authority’s option, be reduced such that in the subsequent Service Year, the reduced Transaction Charges multiplied by the Predicted Transaction Volumes would give an under-recovery of Forecast Revenue in that Service Year equivalent (within 2%) to the over-recovery of the Forecast Revenue in excess of the 110% cap in the prior Service Year. The revised Transaction Charges shall apply from 1st April of the relevant year. 2.8.5 If the Actual Transaction Percentage is lower than 85% eighty five percent) but greater than 75% (seventy five percent) then the Transaction Charges for the subsequent Service Year shall be increased such that in the subsequent Service Year, the increased Transaction Charges multiplied by the Predicted Transaction Volumes would give an over-recovery of Forecast Revenue in that Service Year equivalent (within 2%) to the under-recovery of the Forecast Revenue in excess of the 85% cap in the prior Service Year. The revised Transaction Charges shall apply from 1st April of the relevant year. For illustration purposes only if the Actual Transaction Percentage equals 82% then the increase in Transaction Charges for the subsequent Service Year shall be such that the over recovery in the subsequent Service Year is equivalent to 3%, the difference between 82% and 85%.’

‘2.8.8 At the end of the Service Year 4 a minimum Transaction Volume shall be agreed for Service Year 5, on which the Volume Based Service Charge shall be calculated. This minimum Transaction Volume shall be 85% of the current Predicted Transaction Volume prevailing after any variation to the Predicted Transaction Volume made at the end of Service Year 4.’

‘The provisions of schedule 2.3 (The Charges and Charges Variation Procedure) shall apply in relation to the Financial Model and the parties shall comply with their respective obligations under schedule 2-3 (The Charges and Charges Variation Procedure) in this regard.’

‘to ensure that the Claimant’s revenues from the Transaction Charges remained broadly as envisaged by the Financial Model even if actual transaction volumes diverged significantly from the Predicted Volumes on which the Financial Model was predicated.’

‘Paragraphs 2.8.4 and 2.8.5 of Schedule 2-3 state that the Charges Variation Procedure operates such that the Transaction Charges for the subsequent Service Year “…may, at the Authority’s option, be reduced" or “…shall be increased" if the Actual Transaction Percentage is higher than 110% or lower than 85% respectively. I would expect that if the Actual Transaction Percentage were higher than 110%, the adjusted Transaction Charge for the subsequent Service Year to be lower than or equal to the contractual Transaction Charge set for the subsequent Service Year. I have therefore set a minimum value of either (i) the adjusted Transaction Charge calculated from the formula or (ii) the contractual Transaction Charge for the subsequent Service Year. Equally I would expect that if the Actual Transaction Percentage were lower than 85%, the adjusted Transaction Charge for the subsequent Service Year to be higher than or equal to the contractual Transaction Charge set for the subsequent Service Year. I have therefore set a maximum value of either (i) the adjusted Transaction Charge calculated from the formula or (ii) the contractual Transaction Charge for the subsequent Service Year.’

‘Reset as per Clause 2.8.6’