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

There was an issue of principle between the parties as to whether TCS was required to comply with the Government’s Design by Default (or ‘DbD’) Standards.

A ‘poster’ format of the 18 principles applicable as of 19 March 2016 was included in the supplemental report of Mr Britton:

As will become clear, DBS’s case on breach of DbD was limited to 5 of the DbD principles: 1, 2, 7, 9 and 12 (as explained by Mr Croall in oral Opening Submissions).

The IT experts agree that the DbD standard describes sensible principles and processes that if applied appropriately should help achieve a high-quality result, and that many of these, including for example researching user needs, building a working prototype and testing the end-to-end service, can be used regardless of the software development methodology that is adopted. At paragraph 40 of the Joint Statement, Dr Hunt’s view was stated to be that many of principles set out in the GDS Digital By Default standard should be used as part of Good Industry Practice (my emphasis: DBS overstated the position in its Written Closing Submissions by suggesting in this paragraph Dr Hunt’s position was simply that ‘the DbD standards reflect Good Industry Standards’).

It is of note that of the principles which DBS does not rely, it is principles 4 and 5 which would have required the Solution to be build in an ‘Agile’ methodology, so as to provide a service that can be iterated and improved on a frequent basis. As Mr Sands, a technical architect employed by DBS agreed, the DbD standard is very much focused on ‘Agile’ as a methodology.

‘Waterfall’ and ‘Agile’ refer to two different development approaches: adopting, as I do, TCS’s summary within their Closing Submissions of the explanation given in Mr Britton’s report of the two approaches: ‘Waterfall’ is characterised by successive lifecycle phases for each release (i.e. requirements, design, build, test, deploy); ‘Agile’ involves short sprints during which parts of the system (usually discrete pieces of functionality) are taken from being a requirement to being ‘Done’ (i.e. built, tested and accepted).

TCS’s contracted approach as set out in Schedule 3 (Contractor’s Solution) to the Agreement was as follows:

This was further described in TCS’s Solution Support Document, which stated:

As confirmed by Dr Hunt, the experts broadly agreed that TCS was contracted to use a ‘modified’ Waterfall approach rather than an ‘Agile’ approach:

This is consistent with the contemporaneous analysis of Mr Sands, of DBS, when assessing the Solution against DbD requirements in June 2016: