There is an exchange that repeats itself in practically every public organisation, with variations in vocabulary and none at all in plot.

The policy area says technology does not deliver. Technology says the policy area does not know what it wants. Both are partly right, which is the worst possible configuration for solving a problem: each side has enough evidence to sustain its own version, and neither version leads to a solution.

When you open up that exchange, you almost always find the same origin. The demand reached technology already converted into a specification. Somewhere along the way, someone translated a public policy problem into a list of features, and the translation was lost in conversion.

The invisible cost of asking for the right thing the wrong way

Specifying is comfortable. It gives a sense of control, it fits in a document, it survives a procurement process. The problem is that a specification carries an embedded solution, and the embedded solution is usually the first one that occurred to whoever wrote it.

The costliest waste in the public sector is not the system that runs late. It is the system that arrives on time and nobody uses.

A well-stated problem is more uncomfortable and far cheaper. It says which outcome needs to change, for whom, and how we will know it changed. It leaves the path open, which allows the final solution to be simpler and cheaper than the first idea.

Three questions that change the conversation

  • Which behaviour, by the citizen or by the civil servant, needs to change for the policy to work better? If the answer is a screen, it is not yet an answer.
  • How will we know, in ninety days, whether the change happened? If there is no indicator with a baseline, there is no way to assess delivery, only to assess whether a deadline was met.
  • What would happen if we solved this with no new technology? The answer usually reveals how much of the problem is process, regulation or communication.

None of these three questions requires technical knowledge. They require management discipline. And they are precisely the ones almost never asked before terms of reference are written.

Why agile did not fix this

Many organisations adopted agile vocabulary without adopting the logic that sustains it. Delivery happens in short cycles, but a short cycle exists to accelerate learning, not production. The original point of delivering fast is to receive feedback fast and correct the hypothesis before it accumulates complexity, not to produce the same features in smaller packages.

When the policy area takes no part in the learning cycle, there is no feedback to receive. There is only more frequent production of the same thing. That is why so many organisations declare themselves agile and carry on delivering systems nobody genuinely asked for.

Where to start

Not only with technology. Also with training whoever frames the demand. Equipping the policy leader to state a problem, prioritise by value and recognise when experimentation must precede procurement changes the quality of everything that enters the queue, and it is the cheapest intervention available.

Technology does not need more production capacity. It needs better framed demand. That is a management problem, and management problems are solved by training managers.