Ministry of Insights

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

by
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.

Topic Public sector AI failure
MOI lens Decision Assurance Lab
Related Labs Civic Lab and Engage Lab
Core issue Designed for committees, not citizens
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

by
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.

Topic Digital transformation and automation
MOI lens Change Lab
Related Labs Insights Lab and Decision Assurance Lab
Core shift From transformation projects to transformation habits
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 →

Decision Assurance Lab Case Study

by
Decision Assurance Lab Case Study

Stress-testing a high-stakes decision before commitment.

This case study shows how Ministry of Insights can use Decision Assurance Lab to test evidence, assumptions, scenarios, stakeholder consequence and delivery reality before leaders commit money, people, reputation or public trust.

Lab Decision Assurance Lab
Focus Evidence, assumptions, risk and scenario pathways
Related Labs Consult Lab and Change Lab
Best used when The cost of being wrong is material
The situation

The recommendation looked ready, but the confidence behind it needed testing.

An organisation was preparing to approve a major decision. The decision had a clear rationale, documented benefits and a pathway that appeared achievable on paper. It also carried meaningful consequence: budget, delivery capacity, stakeholder confidence and reputational exposure.

Leaders were not looking for another layer of bureaucracy. They needed a disciplined pre-commitment test to understand whether the recommendation was strong enough to approve, adjust, pause or challenge.

Decision Assurance Lab is designed for this point: when a decision is close enough to commitment that consequences are becoming real, but early enough that leaders can still strengthen the pathway.

The decision would commit significant people, money or delivery capacity.
The evidence base looked coherent, but several assumptions had not been stress-tested.
Stakeholder, operational or adoption risks could affect the outcome after approval.
Leaders needed decision confidence before commitment hardened.
The challenge

A polished business case can still carry hidden decision risk.

High-stakes decisions are often supported by detailed papers, financial models, implementation plans and risk registers. These can be useful, but they do not always test whether the recommendation will survive real operating conditions.

The challenge was to separate documented confidence from decision confidence. Leaders needed to know what was evidenced, what was assumed, what was uncertain and what could change the recommendation if tested more deeply.

The Decision Assurance approach

Pre-commitment stress testing before approval.

The work used Decision Assurance Lab as a structured review environment. The aim was not to slow the decision down or make the paper look safer. The aim was to test the conditions that would determine whether the decision could be approved with confidence.

Step 01
Frame the decision and exposure.

The first step was to clarify what was being approved, what would become committed, who would be affected and what consequences would follow if the decision was wrong.

Step 02
Test evidence and assumptions.

The Lab separated verified evidence from inference, optimism, missing information, untested beliefs and assumptions that carried decision risk.

Step 03
Simulate scenario pathways.

The decision was tested against likely pathways, second-order effects, implementation friction, stakeholder responses and conditions that could shift the outcome.

Step 04
Translate findings into decision conditions.

The findings were turned into practical conditions, challenge points, risk notes and recommendations leaders could use before approval.

What was tested

The Lab focused on the risks that often appear after commitment.

Evidence What is known, inferred or missing?

The Lab tested the quality of the decision base and separated strong evidence from assumption, optimism or unsupported confidence.

Scenario What may happen after approval?

Scenario pathways were explored to show how operational, stakeholder or adoption conditions could affect the decision.

Conditions What should be true before commitment?

The work identified what needed to be strengthened, clarified, monitored, changed or escalated before leaders committed.

The insight

Decision assurance is not delay. It is protection before exposure.

The key finding was that the decision did not need more polish. It needed sharper clarity about where confidence was justified and where the organisation was relying on assumptions that could become expensive later.

This is where the wider MOI AI Simulation Labs model becomes useful. Decision Assurance Lab gives leaders a structured way to test a recommendation before consequences become real.

The output

A clearer decision pathway before approval.

The final output helped leaders understand whether the decision was ready to approve, needed further evidence, required adjustment or should be paused until specific conditions were met.

A decision assurance brief showing the strength and weakness of the recommendation.
An evidence and assumption map separating known facts from untested beliefs.
A scenario summary showing likely consequence pathways and pressure points.
Decision conditions showing what needed to be changed, clarified or monitored before commitment.
Practical recommendations for approval, revision, escalation, pause or further assurance.
Why it matters

The best time to find decision risk is before approval.

Once a high-stakes decision is approved, the organisation starts spending trust, money, time and attention. Weak assumptions become delivery problems. Missing evidence becomes governance risk. Stakeholder silence becomes resistance. Optimistic implementation logic becomes rework.

Decision Assurance Lab helps leaders see those risks earlier, while the pathway can still be adjusted. It supports better judgement by testing the decision before commitment becomes exposure.

Discuss Decision Assurance → Explore Decision Assurance Lab → View case studies →
Related decision support

Decision Assurance Lab can draw on the full MOI Lab system.

Where the decision depends on operational reality, stakeholder confidence, adoption readiness or independent challenge, Decision Assurance Lab can connect with other MOI Labs.

Explore the Lab system → Consult Lab → Insights Lab → Change Lab →

Consult Lab Case Study

by
Consult Lab Case Study

Challenging a recommendation before it becomes commitment.

This case study shows how Ministry of Insights can use Consult Lab to test the quality of a recommendation, business case or decision paper before leaders approve, fund, defend or implement it.

Lab Consult Lab
Focus Independent challenge, executive synthesis and decision quality
Related Labs Decision Assurance Lab and Insights Lab
Best used when A recommendation needs sharper judgement before approval
The situation

The paper was polished, but the decision logic needed testing.

An organisation had a recommendation moving toward senior approval. The material looked professional. The structure was clear, the preferred option was stated and the case for action had been presented in a way that appeared ready for endorsement.

But there were still important questions beneath the surface. Was the evidence strong enough? Had the options been tested fairly? Were the risks clear? Did the recommendation follow from the analysis, or had the paper simply made one pathway look more certain than it was?

Consult Lab is designed for this point: when leaders need independent challenge before a recommendation becomes policy, investment, procurement, delivery work or public commitment.

The recommendation was nearing approval and needed sharper review.
The supporting material looked complete, but the strength of the evidence was uneven.
Some assumptions had been accepted without enough challenge.
Leaders needed a clearer view of what should be approved, revised, paused or escalated.
The challenge

Most executive review checks the paper. Consult Lab checks the decision.

Formal papers can meet formatting expectations while still carrying weak decision logic. They may present options without testing trade-offs properly, state risks without showing their implications, or rely on assumptions that would materially change the recommendation if challenged.

The challenge was to move beyond presentation quality and examine decision quality: the evidence, reasoning, assumptions, options, risks and conditions that leaders needed before committing.

The Consult Lab approach

Independent review, structured for senior judgement.

The work used Consult Lab as a focused decision challenge environment. The aim was not to rewrite the paper for style. The aim was to test whether the recommendation was sufficiently clear, evidenced and defensible.

Step 01
Review the decision material.

The first step was to examine the recommendation, problem framing, options, evidence base, assumptions, risks and proposed pathway.

Step 02
Test evidence and assumptions.

The Lab separated what was known from what was inferred, assumed, optimistic, missing or presented with more confidence than the evidence supported.

Step 03
Challenge the recommendation logic.

The work tested whether the preferred option followed from the evidence and whether alternative options, trade-offs and consequences had been considered fairly.

Step 04
Translate challenge into executive advice.

The findings were turned into decision conditions, clarifying questions, challenge points and practical advisory notes leaders could use before approval.

What was tested

The Lab focused on the areas where weak decisions often hide inside strong-looking papers.

Logic Does the recommendation follow from the evidence?

The Lab tested whether the problem, options, analysis, trade-offs and recommendation pathway were coherent.

Evidence What is proven, inferred or unsupported?

The work separated strong evidence from assertion, optimism, missing data and assumptions that required further testing.

Judgement What should leaders know before approval?

The output identified what should be clarified, revised, escalated or tested before the decision hardened.

The insight

A better paper is not the same as a better decision.

The key finding was that the organisation did not need more polish. It needed sharper judgement about the evidence, recommendation logic and conditions for approval.

This is where the wider MOI AI Simulation Labs model becomes useful. Consult Lab helps leaders test the quality of the decision before the organisation becomes committed to the consequences.

The output

Executive challenge points that improved the decision pathway.

The final output helped leaders understand where the recommendation was strong, where it needed revision and what should be clarified before approval. The goal was not to block the decision. The goal was to make the decision more defensible.

An independent review of the recommendation, options, evidence and decision logic.
A clear distinction between known facts, assumptions, gaps and unsupported confidence.
Challenge points showing where the recommendation needed stronger reasoning.
Decision conditions showing what should be clarified before approval.
Practical advisory notes supporting approval, revision, escalation, pause or further assurance.
Why it matters

Decision challenge should improve confidence, not slow momentum.

Leaders do not need every recommendation delayed by unnecessary review. But when a decision carries strategic, operational, financial, stakeholder or reputational consequence, weak reasoning can become expensive very quickly.

Consult Lab helps leaders see whether the recommendation is ready for judgement. It gives executives and boards a clearer basis for approval, revision, escalation or further testing.

Discuss Consult Lab → Explore Consult Lab → View case studies →
Related decision support

Consult Lab can work alone or lead into deeper assurance.

Where the recommendation depends on operational reality, stakeholder confidence, adoption readiness or high-stakes commitment, Consult Lab can connect with other MOI Labs.

Explore the Lab system → Decision Assurance Lab → Insights Lab → Engage Lab →