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

There is no dispute between the IT experts that documents were named with lengthy alphanumeric reference numbers when loaded automatically from SPS. I find, as Mr Britton accepted in his second report that ‘it would have been a great improvement in the User Interface to have provided meaningful names’: The other naming issue, not raised in cross-examination or disputed by Mr Britton, was, as Dr Hunt identified in her first report, that even if the user changed the document names manually, this name would not be displayed when trying to select documents to insert into a bundle. Instead, only the internal content identifier was visible.

I accept Dr Hunt’s conclusion, unchallenged in cross-examination, that TCS’s ‘design of the integration between Siebel, document generation and bundling appears to have taken no account of how users would work with the system’, and that as such it would not have been carried out in accordance with GIP. I also accept Dr Hunt’s evidence that TCS’s design of the integration between Snowbound and Siebel made the bundling functionality ‘effectively unusable’. Mr Britton’s evidence was not materially different. He accepted in cross-examination (Day19/30):

Part of the DBS process related to the creation of a minded to bar (‘MTB’) bundle. This included identifying the correct documents, redacting them, creating an appendix of the documents, and drafting an accompanying letter. As such, it was a task impacted by the Snowbound issues discussed above and I accept that, as a result of the issues they encountered with snowbound, DBS implemented a workaround to create bundles in excess of 200 pages manually.

As to wider performance issues generally, DBS plead that ‘the system is slow, in that every action a user attempts to perform on the system suffers from a time lag of several seconds’ (paragraph 99.3 of the Amended Defence and Counterclaim). DBS also made complaints about reliability and log in times (paragraphs 99.2.1 and 99.2.2 of the Amended Defence and Counterclaim).

There was a performance test in the SIT-L environment, which was explored in cross-examination. The Non Functional Requirement for retrieval of a .pdf document from the database was to test a 10-page document, and the test was passed in relation to load times for retrieval of documents. I accept Dr Hunt’s opinion that the testing ought, in compliance with GIP, to have included a test under the load likely to be expected in use, and that, having reviewed the Test Completion report for Performance Testing that it did not. Moreover, other response times applicable to caseworkers’ use of the Snowbound tool were exceeded. The Agreement specified Application Response Times of 99% within 2 seconds and 1% within 3 seconds for a user executing any transaction within the application: Schedule 2-2. I accept TCS’s submission that the results show each response time was in excess of this requirement, and that similar response times were encountered even after Snowbound had been upgraded by TCS to version 4.13.

However, Dr Hunt, in her Appendix K, analysed the Post Go-Live Defects in relation to the reliability, login failures and time lag pleaded at paragraph 99.2 of the Amended Particulars of Claim, and in relation to each one concluded that responsibility was ‘primarily’ HPE, because of bandwidth limits imposed. Dr Hunt also concluded that these issues should have been rectified by BCR1642 but implementation of this was delayed by issues which were the responsibility of HPE and DBS. Dr Hunt’s conclusion on performance in cross-examination was as follows (Day 19/176):

Snowbound updates were carried out in July 2018 from v4.7.2 to v4.10: the v4.8 and v4.9 updates had stability problems and were not implemented) and to v4.13 in June 2019. In the circumstances, it is not possible to conclude that there existed general performance related issues which were the responsibility of TCS, other than those associated with Snowbound integration, even though it is likely that the problems encountered post-Go Live would probably have been identified sooner if the testing had taken place at appropriate load. The system performance problems themselves were, as Dr Hunt concluded and I accept, primarily the responsibility of HPE and bandwidth related issues.

I accept that the Snowbound issues which have been established were a material contribution to the decision by DBS to implement a workaround to create MTB bundles in excess of 200 pages. DBS submits that it continued to experience issues with creating MTB bundles, even after the bandwidth issue had been resolved. That this was so was supported by Dr Hunt’s analysis (see first report paragraph 495). Contemporaneous support is also found in some of the documents: see for example the email exchange dated 19 February 2018, in which it was recorded that, ‘we have not found that lift of the cap on bandwidth by one of our suppliers, has seen a decent improvement on the DMT specifically. It didn’t demonstrate any improvement in the speed of Siebel generally however…’ Having sought feedback from caseworkers dealing with MTB bundles in excess of 50 pages, one caseworker stated: ‘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.’

In terms of specific cost claims arising out of Snowbound (as opposed to DBS’s loss of anticipated efficiency claim, of which the Snowbound complaints play a part), DBS claims Snowbound Tool remediation costs in the sum of £293,069 (item 21 of the Updated Schedule of Loss), and Adobe licence costs, in the sum of £8,270 (item 20 of the Updated Schedule of Loss).