When Services Never Stop Changing

I keep coming back to a distinction in government between running something and changing it.

The running is BAU. The changing is a programme.

That distinction is deeply embedded in how organisations think about funding, governance and accountability. A programme can have a defined objective, a business case, a start and end date, a benefits profile and a point at which it is considered complete.

But what if the thing being changed should never really be complete?

That is increasingly true of digital services. A service used by real people exists in an environment that keeps moving. User needs change. Legislation changes. Security threats change. Technology changes. Data improves. The organisation learns more about where the friction actually sits.

A good service should be getting better all the time.

This is where I wonder whether some of our governance is better suited to approving change than sustaining improvement.

In a large operating business, continuous improvement is often simply part of running the operation. The business still cares about cost, service, risk and performance, but making the operation better is not treated as a temporary activity that eventually hands back to BAU.

Government can feel more episodic.

We identify a significant problem. We create a transformation programme. We fund the change. We deliver it. We close the programme and hand the result into BAU.

Then, over time, the gap between the service and what is now possible begins to grow again. Eventually the case for another transformation becomes strong enough and the cycle starts again.

I do not think that necessarily reflects poor leadership. It may reflect the incentives created by the system.

A bounded programme is relatively easy to describe. We can say what money is required, what will be delivered and what benefit should result.

A permanent capability to keep improving a service is harder to express in the same terms because there is no final destination.

That matters even more as the economics of change shift.

AI is part of this, but it is not really an AI argument.

If software, automation and experimentation become dramatically cheaper, the sensible pattern is likely to involve more small changes rather than fewer large ones. Test something. Learn. Improve it. Remove something that no longer works. Repeat.

That is much closer to a permanent product or service capability than a conventional transformation programme.

The governance question then becomes more interesting.

How do we fund enduring capability without turning it into an entitlement to permanent spending?

How do we hold a team accountable when the proposition is not “deliver these 12 things by this date” but “keep improving this service and demonstrate that the investment remains worthwhile”?

How do spending decisions recognise avoided cost, reduced failure demand, better user outcomes or a service that simply becomes steadily easier and cheaper to operate?

There are no trivial answers to those questions.

But the problem feels increasingly important because the technology is making incremental improvement easier at exactly the point when many of our organisational mechanisms still reward large, legible packages of change.

We have governance for programmes of change.

Do we have equally good governance for services that should never stop changing?