The failure of the rural payment digital service last week – and its subsequent replacement by paper forms – is not the IT disaster some would claim, but it is an embarrassment for the Government Digital Service (GDS).
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The project, budgeted to cost around £154m, has not seen all that money wasted. Only £73m has been spent so far, and very little of that has been wasted either. The system will still be developed, and will be used for next year’s round of farming subsidy claims – or that’s the plan at least.
The cost of failure this year amounts to the unbudgeted processing of paper forms, and the cost and effort involved in trying to correct the performance problems that have so far proved insurmountable. That’s probably several million pounds that nobody wants to have spent, but it’s tiny compared to past IT disasters.
GDS chief Mike Bracken’s words in a speech to the Institute of Government in October last year are worth quoting now:
“No policy or service we civil servants think up will ever work in practice the way we thought it would in theory. We must start out humble, and rapidly iterate in response to the messy reality of real users using real services,” said Bracken.
“We should say to critics in the media or elsewhere that failure is an essential part of government, just as it is in private enterprise. And the cost of failure should be tiny, dwarfed by its rewards,” he said.
“The cost of failure is only enormous if you plan to launch with a big bang on a fixed date in a couple of years’ time, with the world’s media and public watching – but before you’ve really started the work to understand how to best meet the needs of the people who will use the service. Big bang was fine in 1986. It is a disaster waiting to happen in 2014.”
Those apposite words frame the three issues that need to be addressed in the light of the rural payments problems.
1 – How does agile work with immovable deadlines?
For many years, one of the most frequent causes of government IT failures was the immovability of political deadlines. When the tax credits system fell over under the Labour administration, it turned out that testing was bypassed to meet the political deadline set by then-chancellor Gordon Brown. That’s a great example of what Bracken meant when he talked about avoiding fixed dates and big bangs. But the “messy reality” of government is that some deadlines will always be fixed.
If it weren’t for an EU deadline of 15 May (since shifted to 15 June) for farmers to claim for the new Basic Payment Scheme policy, the rural payment system might have had time to be fixed. In the end, that fix didn’t happen in time. GDS is left red-faced because farmers have been complaining about performance problems with the digital mapping tool since they started using it earlier this year.
Few would argue that avoiding big bang launches is a bad thing. Similarly, few would argue that the iterative approach preferred by GDS’s agile strategy is a bad thing. But in government, there will always be fixed deadlines, like it or not – and GDS needs to show that the iterative approach can still work in such circumstances when there are problems along the way.
2 – Was this a prototype or not?
The digital service launched to farmers was, in GDS parlance, still only a beta version. According to the GDS Service Design Manual – the current bible for government IT developments, mandated by force of Cabinet Office minister Francis Maude – a beta is: “A fully working prototype which you test with users. You’ll continuously improve on the prototype until it’s ready to go live, replacing or integrating with any existing services.” Only after a service has passed its public beta phase is it classified as a “live” system by GDS. But farmers were told that this was the mandatory route for making their claims.
The rural payments service was launched to all 110,000 farmers and 1,200 land agents to be used for the very live act of applying for their annual subsidy payments. As one source put it: “Beta is bullshit in this context”.
Farmers wouldn’t understand the digital concept of alphas and betas – all they wanted was a system that worked. Why wasn’t the service launched as a beta to a smaller group of users – preferably the more digitally literate – knowing that they were a test service, while planning from the start to use a paper-based alternative for the remainder of users? That way the developers learn, and they can better prepare for scaling up the service and for what Bracken has called the “edge cases” of farmers who need more digital assistance or live in rural areas with poor broadband?
Iteration, and learning as you go along, is commendable – but was it appropriate for the circumstances here, with a system launched to the entire user base, as the only option for making a claim, with a fixed deadline ahead?
3 – Make things open
Mike Bracken also wrote last year about, “Making things open, making things better“. One of GDS’s most prized – and widely applauded – principles is “make things open”. It refers to open source, open standards, coding in the open, and an open culture, with GDS staffers regularly blogging about the projects they work on, in a reversal of historic civil service practices and secrecy.
But now, when something has gone wrong, the shutters seem to have closed. The Cabinet Office press office suggested Computer Weekly talk to Defra, the department responsible for the policy. The Defra press office said we should talk to the Cabinet Office.
Now is the time for GDS to be completely open about what has happened. There is a growing perception among farmers and the media that the rural payments service is a failure, that the money has been wasted, and all the work done so far has been abandoned. In a vacuum of information from GDS and Defra, rumour and speculation turns into damaging fixed perceptions.
Rural payments is arguably the biggest hiccup for the GDS digital strategy so far. Other services that have gone live have generally worked well – register to vote, carer’s allowance, power of attorney, prison visits, online drivers’ licence details have all been successful digital launches. But rural payments is perhaps the biggest and most complex of the GDS digital exemplars to so far reach this stage.
The model for this service is classic GDS – multiple, smaller suppliers instead of one or two big system integrators; agile development; multiple off-the-shelf products instead of heavily bespoked versions. This is what we are told will be the model for much bigger services to come, such as online tax accounts, and the Universal Credit digital service – systems that would cause national political repercussions if they failed. It’s the model by which the future “government as a platform” will be built.
Furthermore, critics of GDS have warned of an over-focus on the web front-end and user experience, and a lack of attention to the thorny, IT-led area of scaling back-end systems and integrating with legacy IT. We know that the core of the problem with rural payments was difficulties between the front-end mapping tool and the back-end rules engine. Servers were hitting 100% utilisation and falling over, which suggests a scaling issue in the back-end software or the integration layer.
But what were the problems exactly? Were the suppliers to blame? What are the next steps to a resolution? What was broken? We just don’t know.
That is not “making things open”. Openness is to be welcomed, but it cannot only apply to the good news. The true test of openness for GDS is now, when something has seemingly gone badly wrong.
So over to you GDS – make things open, so we can see how you are making things better.