Traditional GDS model versus Test and Learn
Trying to reconcile Test and Learn approach to building (and indeed improving or replacing) services while complying with the latest GDS Digital and Spend controls, and I’m struggling.
The work: six months of team funding; first six weeks is mobilisation, inception and discovery; then six weeks of designing, prototyping, testing, iterating (say, a form or a tracker or something else that might shift service performance metrics); then eight weeks of building, testing, iterating - maybe with 20 users to begin with, up to 200 by the end; and the final weeks articulating the questions to be answered before it can be scaled to the whole service, working through as many of the answers as they can (collaborating with experts from around the organisation, many embedded in the team and having provided continuous assurance from within). We, of course, don’t actually know that this is the work - it depends on what we learn. But this is what we hope.
The rules:
* get spend approval when you first start to plan to spend any money, or 12 months in advance of planned spend (28 day SLA if a GDS review is needed)
* get approval when you start to buy something
* get approval before you award a contract
* get approval at each business case stage (SOC, PBC, OBC, FBC)
* get approval at the start of Discovery, Alpha, Beta, Public Beta
It basically makes it impossible to spin something up quickly and fund teams (not programmes) that take a test and learn approach to testing and (in)validating hypotheses quickly, delivering small chunks of value regularly.
Let’s be honest - current governance is designed for (a) Wagile within programmes (large sums, long timescales, chunky phases); and (b) greenfield service development in lower-capability spaces (buying a discovery; buying an alpha; then buying a build partner for the thing you’ve designed etc - still chunky phases, rarely fast-paced).
“Give me some money to spend a few weeks knocking up and quickly testing out this idea to see if it will shift that service metric” - isn’t possible for plenty of services - because traditionally if you’re not part of a programme, you’re BAU and so don’t have the contingency in your budget for this way of working. The model is still “change belongs in programmes”.