Why Public Sector AI Projects Fail: They Are Designed for Committees, Not Citizens

Public Sector AI Insight

Why Public Sector AI Projects Fail: They Are Designed for Committees, Not Citizens

Artificial intelligence can improve public services, but many government AI projects stall because they are shaped around internal governance, consensus and risk avoidance rather than the citizen experience they are meant to improve.

The promise

Public sector AI should make services faster, fairer and more responsive.

In the public sector, artificial intelligence holds enormous promise: faster processing of citizen applications, more accurate risk assessments in social services, predictive maintenance for infrastructure and more efficient allocation of limited resources.

Yet across governments worldwide, including in New Zealand, many AI initiatives stall, deliver underwhelming results or quietly disappear after substantial investment.

The core problem is not usually the algorithm. More often, the project has been designed around internal machinery rather than the person who needs the service.

Projects are shaped around steering groups, approvals and internal consensus.
Citizen outcomes become diluted as each agency, department or function adds requirements.
Risk management becomes more visible than service improvement.
The project delivers something defensible internally, but weak in the hands of the public.
The structural problem

Public sector AI failure is rarely just a technology failure.

The failure rate for AI projects is high across enterprise and public contexts. Research and industry analysis frequently point to weak problem definition, poor data quality, unclear value, governance friction and implementation barriers as repeated causes of AI project failure.

In public sector environments, those risks are amplified. AI projects must work inside fragmented legacy systems, inter-agency boundaries, privacy obligations, procurement rules, political sensitivity and public accountability expectations.

That makes decision quality essential. Before a public agency asks whether the AI model can work, it should ask whether the decision environment around the project has been properly tested.

Failure pattern 01

Misaligned or diluted objectives from the start.

Public sector projects often begin with broad, aspirational goals shaped in steering groups, workshops and inter-agency consultations. By the time requirements are documented, the original citizen problem can become diluted.

A problem such as reducing wait times for benefit applications may slowly become a specification that satisfies policy, legal, operational, reporting and political requirements, while losing focus on the person waiting for help.

RAND Corporation research on AI failure has highlighted misunderstanding or miscommunication of the core problem as a major risk. In government, that risk is often magnified by the number of actors involved.

Original need Improve the citizen experience.

The public-facing problem is often clear at the beginning: faster decisions, better access, clearer support or less friction.

Committee effect Requirements become diluted.

Every internal group adds constraints, preferences and controls until the original problem becomes secondary.

Outcome risk The system works internally, but not publicly.

The project may satisfy sign-off requirements while failing to meaningfully improve the citizen outcome.

Failure pattern 02

Endless layers of governance and approval.

Public sector AI projects can accumulate committees quickly: project boards, risk registers, ethics panels, procurement teams, privacy impact assessments, technical reviews and senior oversight. Each layer may add scrutiny, but not necessarily better decision insight.

When approval processes stretch for months, pilots lose urgency and the original service problem fades into governance procedure. Risk-averse cultures can end up prioritising “no surprises” over practical learning.

Pilots become slower than the problems they were meant to solve.
Project teams optimise for approval rather than adoption.
Governance bodies add controls without always improving technical or citizen insight.
The result is often a safe but shallow solution that struggles to scale.
Failure pattern 03

Internal compliance becomes more important than citizen outcomes.

Public sector AI is often optimised for audit trails, explainability to internal reviewers and defensibility in information requests. These things matter, but they can overwhelm the actual service experience if they become the dominant design logic.

Interfaces become clunky to accommodate every possible edge case. Features are stripped out to minimise perceived risk. The system technically works, but citizens experience it as another bureaucratic layer.

Governance should protect citizens, not displace them from the centre of the design.

Failure pattern 04

Data and integration problems are amplified by silos.

Public data is often fragmented across legacy systems, departmental boundaries and inconsistent formats. AI needs clean, integrated and high-quality data to be useful, but public sector projects often defer the difficult work of data sharing, governance and modernisation.

Instead, they settle for narrow pilots using whatever data is easiest to access. That may be enough to demonstrate a concept, but not enough to support a reliable public service.

Data quality AI cannot fix weak foundations.

If the underlying data is inconsistent, incomplete or poorly governed, AI outputs will inherit those weaknesses.

Integration Silos reduce usefulness.

When departments cannot share or connect data effectively, AI projects become narrow and fragile.

Privacy Fear replaces design.

Privacy concerns should be designed into the work early, not used late as a reason to avoid difficult decisions.

Failure pattern 05

Projects resist iteration and real user feedback.

Private-sector AI often improves through rapid iteration: build, test with users, learn and refine. Public sector projects shaped by committee consensus often resist change once scoped.

Citizen testing can become tokenistic or too late in the process. Negative feedback triggers more review, rather than fast improvement. The outcome is a system designed for sign-off, not adoption.

Citizens are consulted after the project direction is already locked in.
User feedback is treated as risk rather than evidence.
Scope becomes difficult to change because too many committees have approved it.
The project becomes mediocre by design.
The insight

The project has to be designed around the citizen problem, not the committee process.

Fixing public sector AI failure does not require abandoning governance. It requires reorienting governance around outcomes, evidence and citizen value.

New Zealand already has useful guidance through the Public Service AI Framework, MBIE Responsible AI Guidance and the broader New Zealand AI Strategy. The challenge is turning guidance into working delivery conditions.

A better path

Citizen-centred AI needs lighter, sharper and more outcome-focused assurance.

The answer is not reckless experimentation. It is disciplined, citizen-centred testing before the project becomes too large, slow or politically exposed to change.

Step 01
Start with the citizen problem.

Define the specific service friction, delay, risk or unfairness the AI project is meant to improve. Keep that problem visible throughout the project.

Step 02
Use small, empowered teams.

Cross-functional teams should be able to define narrow, high-impact scopes without every decision being diluted through committee consensus.

Step 03
Test with real users early.

Citizen and frontline feedback should be treated as evidence, not a threat to the project plan.

Step 04
Invest in data foundations.

Data quality, privacy, integration and governance need to be solved as core project conditions, not left as late-stage blockers.

Step 05
Shift governance from sign-off to assurance.

Governance should test whether the project is useful, safe, lawful, explainable and improving the citizen outcome it was created for.

Where MOI fits

Public sector AI needs decision assurance before procurement and implementation.

Ministry of Insights is built for this kind of pre-commitment testing. The MOI Lab system helps leaders test the decision environment before money, people, data, reputation or public trust are placed at risk.

Civic Lab tests trust, legitimacy, public consequence and community confidence.
Insights Lab tests operational reality, data quality, constraints and failure loops.
Engage Lab tests stakeholder power, resistance, alignment and influence.
Change Lab tests adoption, behaviour change and implementation friction.
Consult Lab provides independent challenge before the recommendation becomes policy.
Decision Assurance Lab stress-tests high-stakes AI decisions before commitment.
The takeaway

The cost is not just failed technology. It is lost public trust.

When public sector AI projects fail, the cost is not only financial. It is the lost opportunity to make government services faster, fairer and more responsive at a time when public trust is fragile.

New Zealand’s public sector has strengths: pragmatism, a relatively small scale for testing and growing AI guidance from MBIE and the Government Chief Digital Office. But until AI projects are genuinely designed around citizens rather than committees, many will continue to underperform.

Talk to MOI Explore Decision Assurance Lab Explore the Lab system
Related reading

Decision support, responsible AI and public-sector assurance.

For broader context, review MOI’s Lab system, responsible AI position and relevant public-sector AI guidance.

MOI Lab system MOI Ethical AI Policy RAND research OECD AI Policy Observatory

The Death of the “Digital Transformation Project

Continuous Automation Insight

The Death of the Digital Transformation Project

For more than two decades, organisations have invested in large, multi-year digital transformation programmes. Many begin with energy, ambition and executive sponsorship, then quietly stall under the weight of reality.

The old model

The era of the big digital transformation project is ending.

Large transformation programmes usually start with glossy roadmaps, new platforms and ambitious promises about efficiency, insight and cultural change.

Then budgets blow out. Timelines slip. Systems are delivered that only partially fit reality. Staff learn to work around them. Leadership changes. Priorities shift. What was meant to transform the organisation becomes another expensive layer sitting on top of old processes.

At Ministry of Insights, we see this pattern repeatedly. Not because leaders are careless or teams are incompetent, but because the traditional transformation project model is structurally misaligned with how organisations actually work.

What is replacing it is something quieter, more practical and far more effective: continuous, small-scale automation and improvement cycles.

Why they struggle

Large transformation programmes are built on assumptions that rarely hold.

Most major transformation initiatives assume that processes can be fully mapped upfront, future requirements can be predicted with reasonable accuracy, behaviour will follow once a new system is delivered and organisational reality is stable enough to support a multi-year redesign.

In practice, none of these assumptions hold for long. Processes evolve as soon as they are documented. Policy settings shift. Market conditions change. New regulations appear. Key staff leave. Informal workarounds emerge. Data quality issues surface late. Political dynamics reshape priorities.

By the time a major system is ready for deployment, the environment it was designed for often no longer exists.

The three systemic problems

Big transformation creates risk by delaying contact with reality.

Problem 01 Designed work drifts from real work.

Formal workflows look elegant on paper. Actual workflows remain messy, adaptive and human. Large systems struggle to bridge this gap.

Problem 02 Risk accumulates invisibly.

Because delivery is staged over years, problems are often detected late, when they are expensive to fix and politically difficult to admit.

Problem 03 Learning is delayed.

Teams do not get fast feedback on whether changes are helping or harming performance. Improvement becomes theoretical rather than evidence-based.

The result is a cycle of optimism, disappointment and reinvention.

The hidden cost

Big bang change often reduces resilience.

Large transformation projects are usually justified on scale. Leaders are told that only major investment can deliver major results. Fragmented improvement is framed as inefficient or timid.

But scale comes with hidden costs. When change is concentrated into a single programme, organisations lose flexibility. Every adjustment becomes a negotiation. Every deviation becomes a risk. Local innovation is suppressed in favour of central consistency.

Staff become cautious. They wait for “the new system” rather than improving what exists. They defer problems instead of solving them. Capability atrophies while dependency grows.

Ironically, programmes designed to modernise often reduce resilience.

Explore Change Lab Explore Insights Lab
The replacement model

Continuous automation cycles are replacing large transformation programmes.

High-performing organisations rarely improve through massive redesign. They improve through constant, disciplined, small-scale experimentation.

In this model, change is not treated as a project. It is treated as an operating system.

What actually works

Small, governed cycles create faster learning and lower risk.

Small problems are identified early. Limited solutions are designed quickly. Automation is introduced in narrow contexts. Results are measured. Adjustments are made. Successful patterns are scaled. Failed ideas are retired with minimal cost.

Benefit 01
Learning is immediate.

Teams see within weeks, not years, whether something works.

Benefit 02
Risk is contained.

Failures are local and reversible. They do not threaten organisational stability.

Benefit 03
Capability grows internally.

Staff learn how to improve systems, not just how to use them.

Benefit 04
Solutions remain aligned with reality.

Because change is continuous, designs evolve alongside actual work practices.

Over time, hundreds of small improvements compound into significant transformation, without the trauma.

Automation as augmentation

The most valuable automation removes friction, not judgement.

A common fear in digital initiatives is that automation is primarily about removing people from processes.

In practice, the most valuable automation does something different. It removes friction, not judgement. It reduces manual effort, not accountability. It supports decision-making, not substitutes for it.

Small-scale automation is especially powerful because it targets specific pain points: repetitive data handling, fragmented reporting, inconsistent approvals, manual reconciliations and duplicated documentation.

Each improvement frees cognitive capacity. Each reduces error. Each improves visibility. Over time, people spend less energy managing systems and more energy managing outcomes.

Implementation through Changeable Decision Assurance Lab
Governance

Continuous improvement needs stronger guardrails, not uncontrolled sprawl.

One objection to incremental change is governance. Leaders worry that decentralised automation will lead to inconsistency, compliance risks and uncontrolled technology sprawl.

These risks are real. But they are not solved by centralising everything into a single programme. They are solved by shifting governance upstream.

In a continuous model, governance focuses on standards, guardrails and decision criteria rather than rigid designs. Clear principles are established for data use, privacy, security, validation, documentation and accountability.

Automation initiatives are reviewed against these principles early. Risk is assessed in small units, not retrospectively at scale. This produces stronger control, not weaker, because issues are visible while they are still manageable.

MOI Ethical AI Policy Privacy Policy
Leadership shift

Leaders must move from sponsors of programmes to stewards of learning systems.

Moving away from large transformation projects requires a different kind of leadership.

Instead of asking, “When will the transformation be finished?” leaders ask, “What did we learn this quarter?” Instead of demanding certainty upfront, they invest in fast feedback. Instead of rewarding compliance with plans, they reward evidence-based adaptation.

This does not mean abandoning ambition. It means pursuing ambition through disciplined iteration rather than grand design.

Replace fixed transformation end-dates with continuous improvement cycles.
Treat small failures as learning signals, not project embarrassments.
Fund experimentation in governed, measurable units.
Reward teams for evidence-based adaptation, not blind adherence to the original roadmap.
How MOI supports the shift

Ministry of Insights tests changes before they scale.

At Ministry of Insights, our work is built around this continuous improvement philosophy.

Through simulation and decision-assurance frameworks, we help organisations test changes before they scale. We model operational impacts, capacity constraints, behavioural responses and governance risks in advance.

Rather than delivering static roadmaps, we help clients build living systems for experimentation, learning and adjustment. Our focus is not on installing tools. It is on strengthening decision quality.

Insights Lab helps establish how work actually happens before improvement is designed.
Change Lab tests whether change can survive adoption, behaviour and implementation reality.
Consult Lab provides independent challenge before recommendations harden.
Decision Assurance Lab stress-tests consequential decisions before commitment.
The practical model

Small, well-designed changes. Tested rigorously. Governed intelligently. Scaled responsibly.

The idea of “finishing” digital transformation belongs to another era.

Modern organisations operate in permanent uncertainty. Technology evolves continuously. Expectations shift rapidly. Risks emerge unexpectedly.

In this environment, resilience comes from capability, not completion.

From projects to practice

The strongest organisations replace transformation projects with transformation habits.

The organisations that will thrive are not those with the biggest programmes. They are those with the strongest improvement muscles.

They treat automation as practice, not event. They replace transformation projects with transformation habits. And in doing so, they build systems that evolve as fast as the world around them.

Talk to MOI Explore the Lab system View case studies
Related decision support

Continuous automation still needs evidence, simulation and assurance.

Continuous improvement works best when each change is grounded in real operational evidence, tested before it scales and governed intelligently.

Change Lab Insights Lab Decision Assurance Lab Changeable