The state-centric philosophy at the heart of GDS is driving risk, says Jack Perschke, Head of Central Government Consulting at BDO, following the publication of the BDO Government Digital Service report 2015.
The Government Digital Service (GDS) has been to government’s massive systems integrators what Alexander’s sword was to the Gordian Knot, but now their challenge is to construct a new approach to government IT.
Had the BDO Government Digital Service paper been published a couple of years ago, the risks outlined would have been theoretical but, with GDS just past its third birthday, we know that many of the risks it outlines are fast becoming issues.
Accountability is already being blurred. Staff and contractors are no more accountable for high-profile and expensive failures like the Rural Payments Agency Digital Service programme than they ever were. Arguably, with advisory and oversight roles being confused, they are less accountable.
The paper also outlines the commercial risks being absorbed by GDS. Tens of millions of pounds have been spent on a network of suppliers incentivised to maximise inputs rather than outcomes. This is reflected in the remarkable increase in taxpayers’ money being spent with specialist firms of agile coders that have been close to GDS from the outset. Their exposure to the government market now rivals some of the Systems Integrators that they so deride.
The final risk discussed in the report is that of inefficiency. Can a monolithic GDS of 600 people with all the vested interests and perverse incentives that brings, really sit at the heart of a genuine digital revolution?
So why are we passively standing by as the Gordian Knot is re-tied by new providers and the failures of the past are being repeated by a new generation? The reason is written on the back of Liam Maxwell’s smart phone.
“What is the user need?” the government Chief Technology Officer asks while brandishing the cover of a phone that asks the same question. The answer he is waiting for is, “We don’t know – please tell us.” The answer he should be getting is, “We don’t know – and neither do you.”
User need is elusive. It cannot be set out, it cannot be described or drawn and it cannot be replicated. User need is necessarily decided by users, usually after being exposed to a number of different options. Business strategists talk of inchoate demand and the emergence of dominant design. I prefer to misquote Chairman Mao Zedong as he set China out on their long path to reform, “Letting a hundred flowers blossom and a hundred schools of thought contend is the policy for meeting the user need”.
Let the users decide from a multitude of options what meets their need and let GDS be the facilitator – not the monopolistic supplier.
To do this, we have to understand why we need IT systems. Government needs IT systems in order to process data. Whether these systems are built by large systems integrators or scrums of agile coders, they are generally taking data through a series of processes in order to pump processed data packages out of the other end.
This is often a complicated process and, when faced with complexity, we humans have a tendency to feel that our intellect and endurance have been challenged and feel the need to rise to the challenge. When the answer is not forthcoming, we work harder at it (effort = cost) and, as Fred Brooks described in 1975, as we throw-in more resources, the more complex and more expensive it becomes.
So what’s the alternative? Instead of trying to build systems to process data, GDS should be using all its energy and considerable insight to allow government entities to buy the thing they wanted in the first place which is processed data. Why does DEFRA want a digital system for rural payments? It doesn’t. It just wants some processed data about farmers. Why not simply set a price for each data package processed to the desired standard and let the market meet the need? £50 per processed package should do it.
If we set the price like this, suppliers of all shapes and sizes would have a go at creating a simple but robust digital interface. You could even imagine some IT-literate farmers getting together to create a system that would actually work for them. Some of these attempts would be good, some would be useless. Overtime, the good ones would attract the most users (because they meet their needs) and the poor ones would wither. Soon, you have a couple of products following a dominant design that meets user needs (as decided by the users). This would have costs DEFRA no pounds to create. This would have required no coders to be employed by GDS and this would have seen all of the risk taken by the market.
We see examples of this all around us. Google provide mapping data packages, Linked-In provide employment data packages and Experian provide credit rating data packages. The revenue model may vary, but the principle remains; understand the challenge and exchange money for solutions not systems.
This approach is not only good for government but it is good for innovation too. On their journey to solve the Rural Payments problem for DEFRA, some of our providers may instead discover that they have solved a new problem for the fertiliser industry, or the tractor industry, or flood risk management, or bee population monitoring, or any of a million other challenges. Indeed they may solve many of them at once by building on the first initial product. This ability to drive innovation is part of the power of government’s scale and it is currently being wasted.
The accompanying report outlines the key risks that GDS faces today. Those risks are present, urgent and the result of a state-centric philosophy that belongs in the history books. The state does not have the answers. GDS does not have the answers. The innovation of the market has the answers; the role of GDS should not be to impose its solutions but to help its government clients define the questions.
Jack Perschke is BDO’s Head of Central Government Consulting and a recognised thought-leader in the future of digital government. For a copy of the full report, please email Jack.Perschke@bdo.co.uk