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

The RFC and CGI letter-related claims are no longer pursued. The only relevant claim relates to the provision of header/footer information on a single HTML letter. Letters sent to Police Forces needed to have “Official Sensitive” in the header and footer of each page. DBS rely upon the requirement that TCS was (by Clause 2.17.1.16 of Schedule 2-2) to ensure the Solution would ‘enable the AUTHORITY to create letters using standard letter templates and/or electronic documents’.

The document provided for the original upload to Siebel did show the header and footer security marking on each page, and when the system generated letters in PDF form, the headers and footers were shown. However, in relation to letters rendered using HTML (which does not paginate) the header and footer would only be displayed at the very top and bottom of the letter if it were to be printed out at the ‘client’ (i.e. police) side.

Both IT Experts agree that if a header and footer was required on each page, then this was a defect providing that there was a requirement with which this did not comply: (Dr Hunt at Day 20/16, Mr Britton at Day 19/42). Dr Hunt agreed that she did not consider the existence of this issue was caused by any failure to have complied with GIP.

In my judgment, if the system permitted the generation of the police information letter in HTML, it was also necessary that the relevant coding was included to comply with the appropriate template. It was, presumably, not necessary for the functionality for the system to generate this particular letter in HTML: the letter generation could, presumably, remain limited to PDFs for printing or downloading, which would have avoided the problem. I therefore find that the fact that HTML letters were generated was strictly a defect, even if not one caused by a failure to comply with GIP.

I accept that this issue would have caused some loss of efficiency. The contemporaneous evidence suggested in August 2019 (at which point a new workaround letter template had been produced) that about 100-110 of these letters per week were being produced – see the exchange between Mr Sheahan and Mr Blanchard of 2 August 2019.

The second issue concerns letter address fields. Automatically generated letters intended to be sent out under the autobar process would sometimes pull through inappropriate data because, in some cases, the PNC had included information in the address field such as “sex offender”. DBS suggests that dealing with low quality input data, including from the PNC, was an expected aspect of TCS’s obligations, relying in Closing Submission upon :

It is plain that these clauses do not impose on TCS an obligation to have anticipated that users of the PNC would have used the address field to include wholly inappropriate information like ‘sex offender’. As Dr Hunt wryly observed, ‘my impression is that it’s not that the PNC is routinely using it for that, it’s just that occasionally those words happen to get put in, presumably by a policeman who feels like it would be quite a sneaky thing to pop it into the address field’.. (Day 20/22). The unreliability of PNC data in this particular way was plainly not a TCS responsibility, as Dr Hunt accepted (Day 20/17). I accept her evidence, as set out in row 10 of Appendix 12 (‘Workarounds’) that this was ‘not a defect’, and I reject the submissions, insofar as it is pursued, that the failure to have foreseen this issue and dealt with it was a failure of GIP.

DBS also rely upon the fact that on 4 November 2015 DBS had highlighted to TCS that:

TCS accepted this was technically feasible, but, as Mr Agarwal indicated in his email to Mr Prabhakaran 2 days later, it was complex to implement and would need to be developed from scratch. Mr Prabhakaran told Mr Agarwal ‘we do not want to accept this requirement’.

However, I reject DBS’s submission that TCS chose ‘to ignore it’ and deliver a Solution in which this problem eventuated as a complete mischaracterisation of the facts. Instead, an RFC was raised – entirely appropriately. The ‘History’ section of the RFC tracker shows that this was under various stages of consideration through 2016 and 2017 until it was withdrawn by DBS. I note that on 6 September 2016, for example, the history states, ‘Barring confirmed content to wait for this RfC until post R1 release strategy is confirmed. In addition, no changes to requirements are needed at this time’.

It was for DBS to weigh up the cost implications of paying for a complex technical solution by way of an RFC against the implications of a manual workaround, e.g. by physically checking addresses before letters go out. It has plainly chosen to go with the manual workaround as more cost effective, as this is the solution still in place many years later (see exchange with Dr Hunt on Day 20/22-3).

It is this problem which DBS contend, in its Written Closing Submissions, meant that the automation promised for the Autobar team was not delivered, and that DBS suffered a loss efficiency caused in that it was necessary to switch off the automatic dispatch of Autobar letters from the point of Go-live. This is not, however, the responsibility of TCS. [Row 17 of the Spegilman Schedule confirms the remaining Autobar case as limited to the ‘Letter Address Field’ issue].