Seeing apples and oranges, not just "fruit" - on build vs buy
[First published here on February 28, 2020]
We need to stop treating all our services the same. Organisations that are blind to the different imperatives driving their services will needlessly waste money and fail to deliver the outcomes they seek.
Lots of services exist to address very well defined problems and needs. HR, Finance and IT services, for example, address user needs so universal that the digital elements of their provision are by and large commodity services with different levels of configurability. There’s still room for innovation – as user needs evolve and technology opportunities emerge – and the size of the market gives the private sector the incentive it needs to invest in making these services better.
By and large suppliers are focused on making these services quicker and cheaper because their customers are driven to optimise for cost and efficiency. They can still be “good services” in many of the ways that Lou Downe describes. But few organisations are sufficiently dissatisfied with what the market provides to invest in in-house development of alternatives. The scale of the potential benefit is usually too small to justify the anticipated total lifetime cost – and so configurable commodity solutions are a better fit for most.
This is a solid judgment to make when you are confident that requirements are unlikely to change over the lifetime of the service. The cost-benefit analysis works because your benefits are accrued internally, your costs are the bottom line in an invoice, and changes are so infrequent that it doesn’t matter much if the cost of change is high.
However.
It’s a mistake to treat all services like this.
Apples and oranges
First, even in the commoditised service space, there are contexts where the size of the prize will justify in-house development and continuous improvement. This might be:
where you are seeking market leadership in a commodity space – as Amazon seized with its AWS offering for hosting
where a function is seen as core to the raison d’etre of an organisation – as the school funding service is for the Department for Education, or
where the sheer scale of your user base shifts the balance on your benefits case – as is true for the NHS and Teacher jobs services.
Second, commercial-off-the-shelf services are simply inappropriate where the problem space is under-explored, user needs are undefined, contexts are uncertain, and organisational imperatives are changing.
Policy teams don’t dive into these uncomfortable spaces for the sake of it: there’s usually a mighty big prize they’re chasing.
The outcomes they’re seeking to deliver are scaled across the country and across public service ecosystems. Consider DfE — the potential benefits that better education, training and care can yield to our population, our economy and our collective future are incalculable and immense. The services being designed and delivered are our public services. If we don’t want to get these right, we might as well pack up and go home. So that’s why policy and service teams wade willingly into uncertainty, ambiguity and complexity.
Faced with this context, teams respond with research. They spend a great deal of time learning about needs and constraints, defining the policy outcomes they’re seeking to deliver and exploring the potential mechanisms they have for delivering them (often manifested in a theory of change). Even then, they’re unlikely to have “the answer”: there’s usually too much uncertainty of context and causality to confidently choose the right solution from the start – let alone to produce requirements or specifications for it.
This is where the value of in-house research, design and development capability comes into its own. Because these teams build to learn.
The true value of a low cost of change
Service teams bring policy and delivery experts together to generate hypotheses and design experiments to test them. They tackle their riskiest assumptions around the design, build and operation of the service - systematically increasing confidence that their service will meet needs whilst de-risking the service. By keeping the cost of change low, these user-centred agile service teams develop services that deliver policy outcomes in complex problem spaces – and continue to do so as needs and contexts evolve.
Over time certainty grows. User needs and service requirements become clear, and the changes to the user experience get ever smaller. But the job isn’t done once you’ve secured your policy outcomes – now you can start refactoring your service stack, looking for further opportunities to reduce costs and optimise for efficiency. Now is the time to think about buying those software-as-a-service commodity products for parts of your service. Perhaps your content management needs aren’t so unique; or maybe your identity management isn’t core to the value of your service offering and will be fine off-the-shelf.
In-house design and build isn’t an end in itself – often outcomes will be best delivered through a mixed economy of service components. But it remains true that large long-term contracts for “enterprise software” that seem cheaper upfront simply aren’t effective nor cost-effective in this space because of the price tag attached to the cost of change.
A high cost of change is a high cost of learning - so in complex and changing contexts the wrong approach will allow suppliers hold you to ransom.
Just like Gillette – selling their razors as loss leaders knowing you’ll go on to spend a small fortune in razor blades – these suppliers know to offer you loss-leading discounts to get you over a barrel and bleed you dry through change requests.
The organisational imperative for services in these contexts is policy outcomes first – with cost and efficiency important but ultimately secondary considerations.
It’s critical that organisations learn to recognise the difference between these two modes. If you have certainty and predictability, don’t build a commodity product from scratch unless you have money you want to burn. If you are trying to deliver policy outcomes in a volatile, uncertain, complex or ambiguous context, you need to keep the cost of change low so that you can build to learn.