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

Louise Bartlett, a User Researcher for the Home Office also carried out a ‘Assessment of DBS Basic Application’ and provided a presentation on 15 August 2016. This stated that the digital team had been asked to provide advice and support to the DBS project, prioritising the work on the ‘basic’ service at that point which had a go-live date of 1 January 2017. There were a number of ‘detailed findings’ which identified useability issues. For example:

The review also identified 12 additional ‘user journeys’. These were essentially functionalities that were not available. By way of example, 2 of the 12 related to the user being able to grant consent to a third party/employer so the other party could view the certificate; and 3 related to third parties being able to log in and view an applicant’s certificate. The absence of these appears to have fed into Ms Bartlett’s ‘high level’ criticism that the project was ‘seen as ‘digitalising’ a paper process, not improving it’. However, I note that, as explained by Lisa Keenaghan, who was a DBS project manager at the time, when DBS’s replacement served was launched following the removal from TCS, the solution did not even provide for a user (let alone a third party) to go online and access and view their certificate: they had to await a paper certificate. This was on the basis that it had been determined by DBS during their ‘discovery phase’ that these aspects of the service, whilst providing a better service, were not critical to the disclosure check taking place. These were regarded as ‘new features’ with prioritised development for the future.

The high level finding also concluded:

The Home Office review then tabulated their perception of TCS’s compliance with the 18 DbD principles, and concluded that apart from ‘some’ compliance with principles 6 and 7, none of the criteria were met. I have found that there was no obligation to comply with DbD. However, as identified above, there is cross-over between some of the DbD principles and GIP. In my view, a failure by TCS to have understood user needs (principle 1) would generally be a failure to comply with GIP. That said, it is also the case that the particular elements of missing functionality identified by Ms Bartlett (and reviewed by Dr Hunt) were not tied back – either at the time, or as part of DBS’s case - to any prescriptive requirements identifiable within the Agreement, and there is necessarily a degree of subjectivity around what ‘user needs’ may be. As Mr Britton points out, it is not clear on what basis Ms Bartlett (who did not give evidence) concluded that this functionality was contractually required. The presentation itself provided very limited substantiation to enable anyone to understand Ms Bartlett’s justification for her view on DbD compliance. As Mr Croall put in his questions to Mr Britton at one point, there is a difference between functionality and useability. It seems to me that these criticisms really went to functionality (which TCS was reasonable to assume should have been specified) rather than useability.

Although Ms Bartlett’s review is relied upon by DBS against TCS now, the view of David Charles of DBS at the time was that the conclusions were ‘overly harsh’:

DBS was well aware of the gap between the methodological requirements for development to a specification imposed by the Agreement on TCS and the GDS expectations of a solution fully compliant with all principles of DbD.

DBS carried out its own assessment at the time, and provided a useability test report. The output of this was summarised by Angela Maxwell of DBS in an email to Mr Malik of TCS at the time (4 August 2016) as follows:

The presentation produced broke the results down into a number of pie charts, splitting the issues into categories: the ‘High severity’ chart identified 3 aesthetic issues, 5 navigation issues and 4 (testing) guidance issues. It also identified 4 prototype specific issues. Under ‘cosmetic useability’ issues, there were 54 syntax issues (such as an ‘s’ missing off a word) and 11 aesthetic issues. The next step was stated as being: ‘DBS to workshop with TCS around usability issues and timescales for fixes.’

It is, of course, important context that at this point, in around August 2016, TCS was still in the middle of the testing phases. It was clear that changes would be required coming out of the test phases, and TCS had indicated that it was prepared to ensure the necessary changes could be implemented prior to Go-Live on 1 January 2017. As reported in the R1 Project Board minutes of 3 August 2016:

Ms Keenaghan also accepted in evidence that she understood that resource had been committed to make user research cosmetic changes and other changes (Day 12/129).

The PB continued:

The reference to the HOD User Researcher is a reference to Ms Bartlett’s user review considered above, which led to the identification of the usability issues, and functionality concerns, relied upon by DBS. The agreement to deal with any usability issues arising out of UAT was also recorded in Mr Sands’ June assessment of compliance with DbD (in the context of principle 12).

In any event, both IT experts agree that the useability issues that IBM, GDS and DBS identified could have been resolved ‘relatively easily’. Dr Hunt’s evidence in cross-examination about the fixing the issues she identified in her report was as follows (Day 20/124):

The assumptions Dr Hunt was asked to assume reflected the facts as I have found them to be. As to the likely cost of fixing the useability issues, Mr Murphy of TCS gave the following evidence (Day 5/105):

That TCS was not asked for a costed proposal to fix these issues was consistent with the absence of evidence that TCS planned to charge DBS for this work. Whilst changes to functionality would potentially be matters for commercial resolution (and, if not a DBS requirement within the Agreement, that would be correct), the evidence as I find it to be is that TCS was prepared and preparing to address useability issues such as those identified in the DBS assessment referred to above. This is a different issue to whether TCS wanted the changes to be made documented through the RFC process, because it is necessary to agree how a particular issue is to be corrected/resolved (and thus that the solution is acceptable). TCS was always clear that it would want the changes it implemented to be documented through an RFC process. There was a debate in cross-examination of Dr Hunt about whether making changes in this way would be quicker through an agile working method; Dr Hunt did not agree that it necessarily would, and I accept that evidence. However, importantly, the discussion highlighted that whichever method of delivery is adopted, the documentation of changes to accommodate user feedback is part of the process whether or not the change is one which TCS is required to carry out as part of its scope, or whether it is a zero cost RFC (Day 20/121):

Indeed: this appeared to be agreed. As recorded at least internally within TCS, Ms Keenaghan agreed that no action on changes arising out of the useability testing was to be taken until an RFC was raised, impacted and approved. Requiring changes arising out of the user testing to be documented through the RFC process, TCS was in my judgment not acting unreasonably.

Dr Hunt nevertheless formed the view, in her report, that the decision by DBS to develop the customer facing Basics Portal itself was reasonable given the extent of work still to be done and the ‘risk’ that a further GDS review would identify more issues.

Mr Britton’s view was that DBS’s decision to start afresh was not justified on the basis of quality of the portal produces by TCS. This broadly accords with Dr Hunt’s view about the relative ease with which the issues she had identified could be resolved. Mr Britton’s view that the quality issues could not themselves have justified removing the scope and starting afresh was not directly challenged in cross-examination. Instead, the justification for starting afresh was put on the basis that if complying with the DbD principles is what TCS was meant to be doing, it would not be a question of simply fixing particular issues (Day 18/184):

In terms of the factual chronology, by the end of August, DBS had started to explore, internally, the formulation of an in-house digital team to look to develop a minimum viable product for the Basic product. It is clear on the evidence that DBS’s concern was the incompatibility of the solution with the broader DbD requirements (and in particular principles 4 and 5) which went – as did Mr Croall’s questions – to the fundamental methodology by which the solution had been developed and manner in which it could therefore be iterated in the future. Mr Sands’s evidence within his witness statement was that:

The first concern of Mr Sands relates to DbD standards 4 and 5; the second relates to DbD standards 15-17. None of these were TCS obligations, and, indeed, DBS does not rely upon breach of these DbD standards. Yet it is clear that these type of concerns were driving DBS to start again, from a different place.

At a meeting on 28 September 2016, TCS was informed that :

The parties eventually agreed that the removal of the portal was dealt with by an RFC. Internally, DBS recorded in October 2016 the driving rationale:

The RFC was 558. This was a consolidated RFC dealing with a number of matters, but which included RFC 552:

DBS contends, with some justification, that the issue of breach went essentially unchallenged with Dr Hunt. On breach, Dr Hunt concluded in respect of both portals:

On the evidence before the Court, this view is justified. It is clear that earlier user engagement should have been undertaken even using TCS’s modified Waterfall approach. I find that, in not doing so, TCS failed to comply with GIP. However, I do not regard that the complaints reviewed by Dr Hunt which consisted of missing functionality requirements not derived from Schedule 2-12 or Schedule 3 are made out.

Having established that at least some part of TCS’s development of the Basics Portal constituted a breached by TCS of GIP, it is for DBS to establish a causal connection with the loss claimed. In relation to a loss shown to be caused by its breaches in relation to the Basics Portal, the burden shifts to TCS to demonstrate that the loss ought not be recoverable if DBS acted unreasonably. I accept DBS’s submissions that, as a matter of law, that:

It is absolutely clear on the evidence, however, that the cause of the decision to implement a new solution was not the useability issues identified in August 2016, which were relatively easy to fix and in respect of which, I find, TCS was willing to fix without cost, and had the resources to do so. There is no evidence before me that doing so would not have been possible prior to Go-Live on 1 January 2017, and indeed at a project level the parties were working on this basis prior to the commencement of DBS’s parallel strategy. The evidence is also clear that in developing its own portal from scratch, DBS was seeking to obtain a fundamentally different product which was fully compliant with DbD, as it is clear GDS/Home Office was keen to happen. It was a product which TCS had not been contracted to supply.

Indeed, DBS’s case (paragraph 409.1 of Closing Submissions) is that it acted reasonably because TCS was not prepared to deliver a DbD-compliant Basics Portal. That reflects Mr Sands’s evidence. It is also entirely correct that TCS was not prepared to do so: but they had no obligation to do so. It is significant that within DBS’s Written Closing Submissions as to the reasonableness of its decision, an inability or unwillingness to fix the relatively easy to resolve useability issues (as opposed to the broader DbD compliance issues) are not referred to directly at all. These limited matters would certainly not have reasonably justified starting from scratch with a new solution.

DBS’s claim in respect of the Basics Portal therefore fails for the following reasons:

DBS’s Counterclaims in respect of items 12, 13 and 14 within the Updated Schedule of Loss fail.