What is GDS for? It’s a question that should be asked at a fundamental level at least every year for an organisation that set out to be agile, iterative and user led. It’s easy to be superficial when asking such a seemingly simple question. People inside the organisation are afraid to ask it, doubtless they’re busy being busy at what they’re doing. They’re afraid of the consequences. They don’t want to touch the question in case it bites – the electric fence that prevents introspection and, perhaps more importantly, outrospection.
There are several reasons why this question should be asked, but one that I would take as important, right now, is because GDS don’t know themselves, as the NAO highlighted recently.
“GDS has found it difficult to redefine its role as it has grown … initially, GDS supported exemplars of digital transformation … major transformations have had only mixed success … GDS has not sustained it’s framework of standards and guidance … roles and responsibilities are evolving … it is not yet clear what role GDS will play [in relation to transformation]”
If there was ever a time to ask “What is GDS for?”, it’s now … to help understand these numbers:
The budget is £150m in 16/17 and 17/18 (though it falls over coming years, to £77m in 19/20) and GDS has around 850 staff today (again, falling to 780 by 19/20).
Let me ask again, what is GDS for?
When those 850 staff bounce into work every morning, what is it that they are looking forward to doing? What user needs are they going to address? How will they know that they have been successful? How will the rest of us know?
Given a budget, Parkinson’s Law of Government, says the department will expand to absorb that budget.
GDS has demonstrated this law in action:
- The exemplars have finished, with varying degrees of success. There are no further exemplars planned. The organisation has only grown.
- Major digital projects have stumbled badly and, in some cases, failed entirely, for instance:
- The RPA Common Agriculture Programme, specifically re-engineered by GDS early in its life and then directly overseen by senior staff, failed to deliver. The lessons learned in the previous RPA project, 7 years earlier, were not learned and the result was the same – a system that was late, high disallowance costs and a poor experience for the real users, the farmers.
- Digital Borders is progressing slowly at best, even allowing for the tuned and optimistic language in the IPA report. Seven years after the last programme was terminated in difficult circumstances, the first, less aggressive than planned, rollout of new capability is starting now
- Nearly 5 years after DWP were ready to complete their identity procurement and around three years since its replacement, Verify design to save millions, was about to enter public Beta, the Government Gateway is still there, 16 years old and looking not a day older than it did in 2006 when the UI was last refreshed. Verify has garnered around 1.4m users, a very small fraction of even Self Assessment users, let alone overall Gateway users.
- The Government Gateway is slated for replacement soon, but Verify is clearly not going to replace it – it doesn’t handle transaction throughput and validation, it doesn’t handle nomination (e.g. please let my accountant handle my Self Assessment) and, most obviously, it doesn’t handle business identity. Given the vision that we laid down for the Gateway and all of the work that was done to lay the foundations for a long term programme that would support all aspects of identity management, Verify is nothing short of a fiasco, as demonstrated by the increasingly vocal war about its future, with HMRC seemingly building its own identity platform. Others far more able than me, including Jerry Fishenden and David Moss have exposed its flaws, muddled thinking and the triumph of hope over ability.
- Even now, instead of bringing departmental transactions on board, addressing true user needs and massively improving completion rate from its current low of less than 50%, the Verify team are talking up their prospects of getting 20m users by lowering identity standards and getting the private sector on board. They blame lack of take up to date on slow delivery of digital services by departments, according to the IPA report.
- Gov.uk, whilst a triumphal demonstration of political will to drive consolidation and a far greater achievement in presenting a joined up view of government to the citizen than achieved before, is still a patchy consolidation with formats and styles changing as you move from level to level, departmental websites still having their own separate space (compromising, as soon as you arrive in a departmental domain, the sense of consolidation), PDFs abound, and, of course, it lacks major transactions (and those that are available often have a very disjointed journey – follow the route to filing a VAT return for instance). The enormous early progress seems to have lapsed into iterative tinkering.
- Alongside all of that we have the latest in a long series of transformation strategies. For many months the strapline on this blog read “transforming government is like trying to relocate a cemetery, you can’t expect the residents to help”. Since then I’ve revised my view and now believe, firmly, that in any effort to achieve transformation, government will remain the catalyst, in the true chemical sense of the word. This strategy says that by 2020 “we will”
- design and deliver joined-up, end-to-end services
- deliver the major transformation programmes
- establish a whole-government approach to transformation, laying the ground for broader transformation across the public sector
- We all want to believe those words. We know that these have been the goals for years, decades even. We know that little has really been achieved. And yet here we are, after 7 years of GDS, being asked to believe that transformation can be achieved in the next 3. There is a Jerry Maguire feeling to this, not so much “show me the money” as “show me the plan”
- And, lastly, we have Government as a Platform. No one was ever quite sure what it was. It might include the Notifications and Payments service – oddly, two services that were available on the Gateway in 2002/3, but that were turned off for some reason.
- In 2015, Mike Bracken defined it initially as Gov.UK and Verify, with a shiny video to go with it, but promised much more, saying “While the next wave of platforms has yet to be finalised, what is clear is the enthusiasm government has for the concept; taking a join-up approach to service provision that’s going to be genuinely transformational. I’m excited for what’s to come.”
- Just so we are clear, it’s not the same as Gov.UK’s Platform as a Service, because, well, because.
- The foundations page outlines how we’ll know what it is when we see it, but there’s no sign of it just yet
GDS is for facilitating the re-engineering of the way government does business – changing from the traditional, departmentally-led silos and individual forms to joined-up, proactive, thought-through interactions that range widely across government. It is not, in my view, about controlling, stopping, writing code or religious/philosophical debates about what’s right. It’s job is to remove the obstacles that stop government from championing the user cause.
Within that the main jobs are:
- Standards and guidelines for IT across government. This could get dangerously out of hand but, as the NAO note, GDS has, to date, not kept its standards up to date. Some key areas:
- Data formats – messaging standards to allow full interoperability between government services and out to third parties through APIs. In 2000, we called this govtalk and it worked well
- Architecture – eventually, government IT will want to converge on a common architecture. We are likely decades away from that on the basis it’s hardly started and replacing some of the existing systems will take more money than is available, let alone increased capacity across the user and technology community at a time when they have plenty going on. New projects, though, should be set on a path to convergence wherever possible – that doesn’t mean getting religious about open source, but it does mean being clear about what products work and what doesn’t, how interactions should be managed and how we streamline the IT estate, improve resilience and reliability and reduce overall cost. This team will show what the art of the possible is with small proofs of concept that can be developed by departments
- Common component planning – all the way back in 2003 I published a first take on what that could look like. It’s not the answer, but it’s a start. I’m a strong believer in the underlying principles of Government as a Platform – there are some components that government doesn’t need more than one of and some that it needs just a few of. They need to be in place before anyone can intercept with them – promising to deliver and then having a queue of projects held up by their non-availability won’t work. And they don’t have to be delivered centrally, but they do have to take into account wider requirements than just those of whoever built them
- Gov.uk publishing team – joined up content will best come from the centre. This team will control what to publish and how to publish and how to ensure consistency across Gov.uk. They will rationalise the content is there, doing what Martha originally set out – kill or cure – to make sure that the user is getting what they need
- Agile and user needs – perhaps the single largest achievement of GDS so far, far beyond consolidating websites for me, is getting government to recognise that there are many ways to deliver IT and that taking a user-led approach is an essential part of any of them. I’m not wedded to agile or any other methodology, but there’s a strong argument for a central team who can coach departments through this and checkpoint with them to see how they are doing, refresh knowledge and transfer skills so that everyone isn’t learning the same lessons over and over again
- Spending controls – a team of elite people who know how to get inside the biggest projects, not waste time on the small ones, and understand what’s being built and why and who can help design the solution at a lower cost than proposed, who can help create the hooks for current and/or future common components and who can help negotiate better deals. These folks should be the best that can be found – a SWAT team sent to work on mission critical projects. Their job will be to help drive delivery, not slow it down through interminable bureaucracy and arguments about the philosophy of open source.
- Transactions team – people who go beyond the pure publishing role into understanding how to hook users into a transaction and drive completion through smart design, innate user understanding and the ability partner with departments, not preach to them from some remote ivory tower. These folks won’t make promises they can’t keep, they will work closely with departments to move transactions that are offline today to the online world, designing them to foster high take up rates and better service for users. This team is the future of government – they will be a mix of people who can help rethink policy and legislation, service designers, UI folks who know how to put something slick together and technologists who can understand how to manage load and resilience and integrate with third parties inside and outside of government.
- Project managers – a mixed team who know how to deliver small and large projects, who are comfortable managing all aspects of delivery, can work with users as well as departments and suppliers and who understand the tension that is always there between waiting and shipping.
- Gov.uk development – Personally, I’m in favour of using companies to do build work. They can maintain a bench and keep their teams up to date with evolving technologies. They can locate wherever it makes sense and call on disparate teams, around the globe if necessary. They can call on experience from other clients and use relationships with partners and the big vendors to do the heavy lifting. The in-house project managers will keep the suppliers in check and will manage scope, cost and time to bring projects home. This is contentious I know – there’s an increasing appetite for government to bring development in-house; some departments, such as HMRC, have had to locate far from the usual places to ensure that they can recruit and retain staff and I think, if you’re going to do it, that’s more sensible than trying to recruit in Holborn or Shoreditch. But, me, I would give it to an up and coming UK company that was passionate about growth, entirely aligned with the user led approach and looking to make a splash. I’d then work closely with them to make an effective transition, assuming that the code stands up to such a transition.
- Verify – It’s time to be brave and ignore sunk costs (investment to date and contractual exit costs if any) and let this one go. It hasn’t achieved any of the plans that were set out for it and it isn’t magically going to get to 20m users in the next couple of years, least of all if HMRC are going their own way. The real reason for letting it go, though, is that it doesn’t solve the real problem – identity is multi-faceted. I’m me, but I do my mother’s tax return, but appoint my accountant to do mins, but I work for a company and I do their payroll, and I counter-sign the VAT return that is prepared by someone else, and I act as the power of attorney for my blind father. Taking a slice of that isn’t helping. Having many systems that each do a piece of that is as far from handling user needs as you can get. Driving take up by having a lower burden of proof isn’t useful either – ask the Tax Credits folks. HMRC are, by far, the biggest user of the Gateway. They need citizen and business (big business, sole trader, small company) capability. Let them take the lead – they did on the Gateway and that worked out well – and put support around them to help ensure it meets the wider needs.