The blog post announcing the formal launch of the Government Digital Service closed with this paragraph:
Next year we look forward to a faster pace for delivery. While our roadmap is not finalised, and indeed will never be given the agility to which we aspire, we can look forward to some major releases.
Since reading it I’ve been wrestling with what I think of the approach that GDS is taking. Several times (at least) I’ve decided that I agree with it; several other times I’ve thought it wrong – the issue I’m debating stays the same and, that is, whether it’s wrong or right for government to build a team in-house to design, develop, deliver and operate a system.
The early deliveries from GDS are interesting markers but not definitive about capability – e-petitions was fast and did what it was supposed to (but there was already a perfectly adequate solution in place; replacing it doesn’t seem to have achieved anything new); alpha.gov looked nice and stirred up some interesting debates (accessibility, IE6 and so on) which needed to be had (I’m looking forward to the debate on whether Welsh will be supported and at what cost) but, to the casual viewer, it was just a website (to the techs i spoke to, it was just a custom-built website and many wondered why anyone had bothered to build from scratch again); and the identity programme has been relaunched (early days yet but my fingers are firmly crossed). It’s good and right that if you’re going to try a new approach you don’t take on something big for your first deliver of course.
The thing that I debate is whether, in an environment where the strategy is reuse, commercial products, British SMEs and frameworks like gCloud (plus PSN and others), should part of government be building a team who will deliver a website that will be the view that almost the entire population has of government online?
An argument for doing it this way might be that the single domain game plan is so different from what the market already has that custom building is the only option. That would, indeed, be the argument that I used in 2002 when we built a new platform for direct.gov the first time round. We took a different approach then – we built a team to architect the strategy and then we partnered with commercial companies to design, deliver and support the site. That didn’t mean that I didn’t get called at 3am if there was a problem, but it did mean that I wasn’t the first person to be called (the suppliers own escalation chain made sure I was called when it was necessary). We ended up having to build a substantial service management wrapper around our suppliers though – some cared more than others for customers, some cared more than others about paying away service credits and some didn’t seem to care for one or the other.
Ultimately, we had top designers/architects on the team and a world-class service management team – and our suppliers fielded top class people in the design and architecture space too. But we didn’t have a team coding, building user interfaces, handling style sheets, deploying code on servers, thinking about performanace optimisation, worrying about how much RAM was needed on a server or whether we had enough disk space allocated and so on. We did, for quite a while, have a great team building trial versions of applications that we thought might be useful in the future, but everything that went into production was built and managed by suppliers under contract.
Our contracts were not of the traditional “come up with all the requirements, fix the price and wait for it all to go wrong” variety – we managed our projects in tight phases with agreed deliverables (and agreed assumptions) and we built in flexibility to change direction if an assumption proved wrong or if we needed to trade features coming up to a deadline. In an early 2000s sort of way, that was probably agile or something like it.
GDS, of course, are huge proponents of the Agile process. Having your own team isn’t a pre-requisite of being agile but it probably makes it easier – if you can switch direction and take your team with you without thinking about deliverables in a contract you can probably move faster (of course, if you have to switch direction too often, you probably should spend more time up front thinking about what it is that you want to get done first). Brent Hoberman at Lastminute told me once, whilst he was still running the show there, that he revelled in his ability to walk out onto the floor and have the developers change something – if the sales numbers had dropped, for instance, and he needed to raise the profile of a particular promotion. You can, of course, do the same with a team provided by a supplier – a lot depends on how you structure the contract and how much resource you have available for “pool” work or support work.
What happens, I wonder, when the site is live (I was going to write “done” but I realise that the paragraph I highlighted from the GDS blog suggests that “done” is going to be all too subjective”)? Does GDS scale down its team and maintain a small dev/fix team and keep service management in-house? Does it move the operation to a supplier (transitioning live code developed by one team to another team can be very challenging – especially if the documentation and comments are less than complete)? Does it keep the team large because, actually, it’s true that a site as vast as this can’t ever actually be done and there will always be new features to add, things to tweak or things to replace because they don’t quite work how it was all imagined?
In the 1990s, government started outsourcing its IT. I’d like to think, had I been there at the time, that I would have argued for keeping it in-house and for outsourcing the handling of all of the paper processing (a set of processes with a low rate of change that cried out for being made more efficient – and that could have been made so with better control of the IT). Since then, almost every central government department and something like 40% of local authorities, have moved their IT to an outside supplier. They made that choice for a variety of reasons – some would have looked at their own organisation and decided it was too small to operate at an efficient price, some would have found suppliers able to stay up to date with new technology, others would have looked at what everyone else was doing and copied them, some would have wondered how to build a career structure for a role that increasingly looked like a dead end within their own organisation and so on.
So is the GDS strategy a reversal of 20 years of outsourcing? It is it a one-off aberration that will stand or fall based on the management team in place today? Is it an experiment that could lead to new approaches right across government in certain niche areas? Is it an attempt to do something new and the only way do to that was to build a team and, when it’s not new, the team will eventually disband? Is it a spot of empire-building? I simply don’t know.
The degree of transparency that GDS have opened up about their development process (and the debates therein) is very much to be applauded. No government team has said quite so much about what they are up to as this one, I’m sure.
I’d like, then, to see the same transparency about what the roadmap (incomplete as it may be) looks like – when does alpha move to beta, when does beta move to production (indeed, is beta going to be production itself), when will the service move to a UK host and to which one, what happens to service management? What will the team look like in six months, a year, two years? Sometimes the broadcasts need to step out of the weeds and show us the whole landscape so that we can appreciate the true majesty.
Outsource or in-house? Hard to call. I wonder how much is to do with control (as you say re Brent), how much empire building and how much to do with supplier performance and cost. Probably a mix of all. You touch on some worrying points (hint rather) which may be an issue.What I suspect we will see is a cycle as both models if done badly will make the other look desirable. When moving from in-house to outsource one forgets (or has not experienced) the problems of outsource. Probably the reverse is true. Organisations to not move to an new model, they move away from the old, which is why neither seems to work.The in-house team will no doubt appear to be good. As you touch on though, will the same quality and demands be made of the in-house team as is made of a supplier. Probably not. Will their documentation be any good, if productivity falls will there be a route to force improvement at the expense of the supplier? No. Holding the reigns of in-house development is hard. It is a totally different game to outsource. In-house development is not the cheap version of outsourced development. If it considered to be that then you one is going to hit real issues.The second issue with in-house is it is hard (and expensive) to keep in-house development teams up to speed on technology that completely changes every 3 years. Training overheads can be large (and rarely considered when comparisons to outsourcing is undertaken).Finally, the in-house development team is in danger of bespoking not just the design of things like web sites but also the product sets that could be used. Is it cheaper to enhance an open source product to do a wider range of things or to buy a product. The drift from simple web site design into actual product development is a slow drift, but in many ways inevitable. As you rightly point out, the move from a bespoke to a product based CMS was a shame but done for good reason. But again, the suppliers let the side down and costs exploded. Perhaps the secret is to pick suppliers who make products that can be used by smaller in-house teams to use. Make sure the in-house team is contractpr based so the agility can be dealt with.But I suspect the grass is never greener.
Interesting post. Actually outsourcing began in the 1980s for the NHS. And there is a case for arguing that some of the failure of NPfIT is due to the decline of in-house capability and service provision which began with the out-sourcing of regional IT units.