Why data-driven working in government often stalls (and how you break through)

Translated with AI. This article was translated by an AI model from an article by Twentynext in another language, and the translation was checked automatically against the original. Verify figures and sources before acting on them. See our disclaimer.

In many municipalities, provinces and implementing bodies, data-driven working is now part of a vision document or coalition agreement. There is a BI team, there are dashboards, pilots are running. And yet, when you ask further, you keep hearing the same thing: “We are on our way, but it is not yet part of our daily work.”

That pattern is no coincidence, nor is it a matter of too little ambition. It has a few identifiable causes that come up time and again. Below you will read what they are, what makes the public sector extra challenging in this respect, and what actually helps in practice to get beyond the next pilot.

The familiar pattern: many dashboards, the same decisions

A familiar scenario: budget is made available, along with a programme manager and a supplier for a data platform. After a while, a series of dashboards is in place. In such a scenario, management reports generally become available faster than before and look well presented.

But look at how decisions are actually taken in the management team, the municipal executive or the team meeting. Are they still based on the conversation, the memo and the experience of the most experienced person present? And is the dashboard only opened afterwards, to confirm what people already thought?

If you recognise that, then that is the core problem: data infrastructure has been built, but the way of steering has not changed. Many of the bottlenecks that arise afterwards are linked to the common causes below.

Cause 1: starting without a steering question

Many organisations board the train of data-driven working without a final destination in mind. The trigger is an administrative wish, a national programme or the fact that the neighbouring municipality is doing it too. The question “which decision do we want to take better with this?” is not asked.

The result is that the data team starts collecting what is available and turns it into reports. The risk then is that dashboards emerge about what is measurable, and too few about what really matters in steering a process.

A useful test: can the process owner say in one sentence which choice he or she would make differently if a particular figure changes? If not, there is no steering question yet and it is too early to build.

Cause 2: it is treated as an IT or dashboard project

Data-driven working is often placed with the information management department. That is logical, because that is where the systems are. But it thereby becomes a technical delivery project: platform set up, interfaces built, dashboards published, project closed.

The change that is needed, however, lies in the line organisation. A Wmo team leader (Wmo: Wet maatschappelijke ondersteuning, the Dutch Social Support Act) or a head of the permits department has to organise their meetings differently, start asking different questions and accept that the figures sometimes show something different from gut feeling. That is organisational development, not technology.

Where this is not acknowledged, a predictable situation arises. The data team delivers, the line organisation looks on, and after delivery nobody has the mandate to enforce use. The dashboards continue to exist, but usage can fade away.

Cause 3: pilots remain pilots

Starting small is sensible. A well-defined pilot shows where data quality falls short, which definitions are incorrect and whether the insight delivers anything in practice. There is nothing wrong with that.

The problem arises when the pilot has no place in a bigger picture. Then, afterwards, there is no answer to the questions: who will manage this later, who will pay for it on a structural basis, and how does this scale to other teams? Without those answers, every pilot remains an island.

Pilots in the public sector can end with an enthusiastic evaluation and a recommendation to “scale up”, while the programme budget has by then been spent. The insight may have been real, but no path to ongoing management has been designed. A good pilot has that path on paper from the start.

What makes it extra complicated in government

These causes also occur in the business world. But the public sector has a number of characteristics of its own that make the journey harder and that you need to take into account in advance.

Ownership of data is dispersed and unclear

Data about residents is usually spread across the specialist applications of different departments, often with different suppliers, definitions and administrators. Ownership of the whole is then not always assigned. Who decides what “a household” is when the social domain, taxes and civil affairs all register it differently?

As long as that question remains unanswered, every meeting debates the figures instead of the decision. That is often mistaken for resistance, but it can also be a legitimate signal that definitions have not been aligned.

Privacy and the fear of profiling

Government bodies process data about residents; the legal basis for this and the resident’s freedom of choice differ per processing operation. The AVG (Algemene verordening gegevensbescherming, the Dutch name for the GDPR) sets requirements for this; think of a legal basis for the processing, purpose limitation and data minimisation. These are broadly known principles, but what they mean for a specific analytical question requires early involvement of the privacy, legal and information security functions in your organisation, depending on the risk and the internal agreements that have been made about this.

On top of that, profiling by government has negative connotations, and not without reason. That can make teams cautious, sometimes to the point where even aggregated analyses with limited risk grind to a halt. Even with aggregation, traceability, group profiling and purpose limitation can play a role. That argues for a risk assessment per question, in which the distinction between steering on groups and deciding on individuals is made explicit in advance.

The political cycle and project funding

Administrators want results within their term of office. However, making data-driven working stick takes time, and in many cases the funding comes from one-off programme resources. Structural management, data quality and training are not always budgeted for in those.

The risk is a wave pattern: a new programme and a new platform every administrative term, and the same lessons being learned all over again.

How you break through

There is no method that solves this in one go. But there are choices that make the difference between an initiative that sticks and one that comes to a standstill after the pilot phase.

Start with one process and one process owner

Choose a process where the owner personally suffers from a lack of insight and is willing to steer differently. Think of lead times for permits, waiting times in the social domain or staffing levels at a customer contact centre. The process owner formulates the steering question; the data team translates it.

This feels smaller than an organisation-wide roll-out. It is also more effective, because there is someone who genuinely needs the result and is accountable for it.

Design the management before the build

Before a single line of code is written, record who will safeguard the definitions after delivery, who will maintain data quality and which budget this comes from. If that answer cannot be given, that is a signal not to start yet. It is better to do one thing structurally well than five things temporarily.

Establish definitions with the line organisation, not in the data team

Let the departments involved reach agreement on core concepts themselves and record them in a simple glossary that is maintained. This is tough work that can take months. It is also the work that later prevents every meeting from being about the figures.

Measure use, not delivery

A dashboard that has been delivered is not a result. A dashboard that is opened every week in the team meeting and leads to different choices is. So agree a few usage and effect indicators with the process owner in advance: for example, how often the insight comes up in the meeting, and which decisions have demonstrably been adjusted on the basis of it.

Track those indicators and discuss periodically with the process owner whether the insight still matches the questions that are live. What is not used is switched off.

Invest in the people who have to work with it

Employees who are given a dashboard without explanation do not use it. Training in reading and questioning figures, room to experiment and attention to this when onboarding new colleagues are not side issues. They are important conditions for making the investment in technology pay off.

A practical first step

Schedule a one-hour conversation with one process owner who says they have too little grip on their process. Ask three questions: which decision do you take regularly where you currently rely on gut feeling, which information would change that decision, and who would need to maintain that information after delivery?

If you can answer those three questions, you have a starting point that goes further than a pilot. If you cannot, you know that the organisation is not yet ready to build, and that is more useful to know now than after a year and a programme budget.