Building, buying, laughing, crying
A lot of my work over the last couple of years working on public digital services has touched on decisions about the best way to deliver some ‘thing’. Lots of questions come up, like ‘should we build or buy?’, ‘do we have the capability to run this ourselves or do we need a supplier to do it?’, ‘X has a product that could do 50%/80%/100% of that, should we just use that?’. At the same time, I’ve run into situations where I (and others) have felt that we don’t have enough ability to effect change in a service, because control over it sits firmly with a supplier.
There are a few different connected questions at issue here — often the most obvious is a decision between in-house delivery vs. outsourcing, but I’m not really going to focus on that one. I’m going to focus instead about the ‘build vs. buy’ question — by which I mean:
‘should we pay someone to build a thing, or pay to use something that someone has already been built’
The interesting thing about this, and why I think this is still worthy of a conversation, is that the decisions made around this vary a lot across government in the UK. There are pockets of delivery where public services are largely custom-built, but there are huge swathes of services that are delivered using commercial products. There was lots of talk at Services Week about a ‘long tail’ of services, and how we as those working in public services should best deliver less widely used services in a way that meets user needs.
I don’t really have any answers to this, but I thought I’d write something to try and marshal my own thoughts at this point in time, and hopefully it opens up a useful discussion.
The theory
On the face of it, the idea of buying a product that does what you’re looking for, rather than paying someone to build one just for you, seems to make a lot of sense. After all, ‘economies of scale’ enable products to be made available very cheaply. I certainly appreciate not having to grow my own food, for instance.
Wardley mapping is an approach which can help guide us through a problem space, and guide us towards which things are better bought and which are better built (along the left-to-right axis). But I’m fairly new to the approach, and still learning a lot, so I won’t talk about it much — only to point out some of the examples in the below, such as ‘compute’ and ‘power’, which sit towards the right of the diagram.
OK, so we’ve at least got a theory for why buying and benefiting from economies of scale might work. Where does it start to break down, and particularly in government-procured products, why doesn’t it help us meet user needs?
Challenge 1: fake COTS (commercial off-the-shelf software)
Given the above narrative, it often benefits suppliers to label software as COTS. It also gives the impression of a piece of software that’s ready to go, and suggests that purchasers won’t have to enter into the gnarly issues of configuration or integration.
However, government needs for software are often not widely shared amongst the private sector. So a “COTS” solution may not really be COTS at all, a veneer over custom-built software. As 18F, the US government digital agency, put it:
Government services to the public are often unique and distinct from private sector offerings. Therefore, if a private company offers a product to manage a government service, it was likely developed to be sold to multiple government entities, making use of decentralized government purchasing. — 18F
Here, the argument for COTS starts to break down. Now, instead of being something developed in an open, competitive marketplace to meet customer needs, it’s something developed by a small number of suppliers with very little consideration of those needs.
The COTS veneer also allows suppliers to refuse to meet the demands of their customers. The product vision and roadmap (if there is one) now sits firmly with the supplier, rather than with the procuring body.
A one-day rule (or similar) might help us cut through this marketing to evaluate whether we’re really talking about a COTS product.
Challenge 2: User needs and intermediate consumers
We sometimes get really confused about what the private sector — or, more correctly, a competitive market — brings to a problem space. Public sector decision-makers may look at a lot of the products and services that they use in their own private lives, provided by private companies, and find that some of them are designed well and meet their needs.
But let’s look at what’s going on here in a bit more detail. In theory, the market for a commercial B2C product looks something like this: a market in which customers can choose from a range of competing suppliers.
But for a service provided by government, the interactions look more like this:
The difference is profound. A couple of the key changes are:
- There is no direct relationship between the users of a service and its consumer. Those of us working in government now have a responsibility to discover our users’ needs, communicate them to our suppliers, and hold them to account in delivering them. If we don’t do that, our users will have a bad experience with a service, often with very serious consequences for their lives.
- The relationship between government and the supplier market tends to be just with one supplier. Government buyers tend not to have the flexibility to buy from multiple suppliers for the same service at the same time, for a variety of reasons I won’t go into. Imagine that you had to evaluate each of a few supermarkets and commit to buying all your food from that supermarket for the next 5 years. Wouldn’t that be weird? But that’s often how public procurement works.
Even in ‘well-functioning’ markets, we have to acknowledge that not everyone is served well — think about the prices paid for energy by those who don’t have an internet connection. Accessibility is also neglected in many commercial products, which ought to be non-negotiable in anything delivered for and on behalf of the public:
Custom-build
As a result of a lot of the challenges above, there’s been a huge shift in central government in the UK, in particular at GDS, as well as at other departments, towards custom-built services. This has been enormously successful in delivering better digital public services, and has involved a huge expansion of capability, both in terms of increased in-house delivery, and better interactions with suppliers.
But in the world of local government (which is my real area of interest), this approach can often seem unattainable. Budgets are much smaller, the number of users of services tends to be smaller (local government, by its nature, covering smaller populations), and capabilities are often much more limited. At the same time, there are a lot of (mostly poor) commercial products used to deliver public services that make me sad and/or angry.
I have mixed views about what the right answers are here. On the one hand, a lot of off-the-shelf commercial products are just pretty rubbish, and by extension provide a rubbish experience to our citizens, who deserve much better. On the other hand, it does seem on the face of it to be a bit wasteful to build these things over and over again, so in a well-functioning market, with good-quality suppliers, and most importantly strong client capabilities, there could be opportunities to use commercial products to deliver services.
Shared capabilities: a third way?
I’ve been inspired by people in the public sector that are delivering products for use by others delivering public services. I was lucky enough to be working on a service over the last few weeks where I used the wonderful GOV.UK Notify and a popular commercial rival at the same time. There was no comparison between the two products — Notify just did a much better job in every respect. A less technically minded team member got up and running in no time with a bit of guidance, while I was getting to work with automating bits and pieces in Python. It made me smile.
GOV.UK Pay is another great example — and I love the below tweet from Steve Messer — sums up what I think we can all aspire to.
And in the local government world, the below from Kit Collingwood at Greenwich gives me a lot of hope for a better way forward. Hard work ahead for sure, but well worth it.
Easy answers
I didn’t promise any easy answers at the beginning of this, and you’re not going to get any now, even if you got this far! I think in the end, the build/buy question comes back, to most things, to something like “it depends”. A mix of bought, built and shared products will probably all play a part in the years to come.
What I am more confident in saying is:
- Delivering good services is hard, and takes a lot of work.
- Those of us delivering public services need to take responsibility and ownership for the quality of those services, regardless of how they are delivered. You can’t outsource outcome risk to suppliers. A bad outcome is a bad outcome, however you got there.
- Markets and commercial suppliers don’t just deliver good things by themselves. They require constant assessment and supervision to keep the market working well.
- Using off-the-shelf products doesn’t remove the need for government to have strong in-house capabilities.
It helped me to write about this, and I hope it helped you too, if you got this far. I’d love to hear your thoughts on this, especially if you think I’ve got it completely wrong — join the conversation on Twitter.
