AI NZ

Crown Entity Restructure: Verifying Operational Reality

by

Constructed Scenario Analysis Crown Entity Restructure: Testing Structural Variations Against Front-line Reality This use case examines how the Ministry of Insights could assist a governance board to stress-test a proposed national organizational reconfiguration, exposing operational dependencies before ministerial approval is sought. Week Identity Week 02: Governance Under Pressure[cite: 1] Featured Lab Insights Lab[cite: 1] Sector … Read more

Change Lab Case Study

by
Change Lab Case Study

Testing whether change can survive the real operating environment.

This case study shows how Ministry of Insights can use Change Lab to test whether a proposed transformation is realistic before leaders commit people, time, reputation and delivery capacity.

Lab Change Lab
Focus Adoption, readiness and implementation realism
Related Labs Insights Lab and Engage Lab
Best used when The decision only succeeds if people change behaviour
The situation

The plan looked sensible. The adoption conditions were uncertain.

An organisation was preparing to introduce a significant operational change. The intended future state was clear enough on paper, but leaders were not confident that the change could survive day-to-day reality.

The risk was not that the strategy lacked logic. The risk was that the implementation plan assumed too much: too much available capacity, too much staff confidence, too much behavioural change and too little friction between current work and future expectations.

Change Lab is designed for this exact point: before the implementation pathway is locked in, when there is still time to test whether the change can realistically land.

The current operating environment was already under pressure.
The proposed change depended on people adopting new routines, responsibilities and decision behaviours.
Leaders needed more than a communications plan. They needed a realistic view of adoption risk.
The organisation needed to understand what had to be true before the change could be safely committed.
The challenge

Most change risk was hiding in the space between approval and behaviour.

On paper, the change could be described as a logical improvement. In practice, it required people to understand the reason for change, trust the direction, absorb new work, shift established habits and continue delivering existing services at the same time.

That meant the real question was not simply whether the change was desirable. The question was whether the organisation had the readiness, capacity, leadership clarity and behavioural conditions needed for the change to hold.

The Change Lab approach

Change realism before implementation commitment.

The work used Change Lab as a structured decision environment, not a generic change management template. The focus was on testing the conditions that would make adoption possible or fragile.

Step 01
Clarify the change being proposed.

The first step was to define what was actually changing, including roles, routines, decisions, responsibilities, systems, reporting and expected behaviours.

Step 02
Test current-state reality.

Where needed, the work connected with Insights Lab thinking to understand operational pressure, workarounds, constraints and existing failure points.

Step 03
Map adoption risk.

The analysis identified where staff confidence, capability, incentives, time, decision rights or leadership alignment could affect adoption.

Step 04
Translate risk into decision conditions.

The findings were turned into practical conditions leaders could use before approving, sequencing or adjusting the change pathway.

What was tested

The Lab focused on the things that usually break change after approval.

Readiness Can the organisation absorb the change?

Leadership clarity, operating load, fatigue, competing priorities and capability were tested against the proposed pathway.

Behaviour What must people do differently?

The work separated general awareness from the specific behaviours, decisions and routines that had to change.

Friction Where will implementation struggle?

Likely points of confusion, resistance, delay, low ownership or rework were made visible before rollout.

The insight

The change was not only a delivery problem. It was a decision-quality problem.

The key finding was that implementation confidence could not be separated from decision confidence. Leaders needed to know whether the change pathway was realistic before treating the decision as ready for commitment.

This is where MOI’s wider AI Simulation Labs model becomes useful. The Lab does not replace leadership judgement. It improves the evidence available before that judgement is exercised.

The output

A practical adoption pathway, not a motivational change plan.

The final output helped leaders understand what had to be strengthened before the change moved forward. The goal was not to slow the decision down. The goal was to reduce the likelihood of preventable implementation failure.

A clearer view of the current operating pressure affecting adoption.
A practical map of behaviours, roles and routines that needed to change.
A ranked view of adoption risks and implementation friction.
Decision conditions showing what needed to be true before approval or rollout.
Recommended sequencing to reduce overload, confusion and avoidable resistance.
Why it matters

Change does not fail in the slide deck. It fails in the handover to real work.

Many organisations approve change because the strategic logic is sound. Change Lab helps leaders ask a different question before commitment: can the organisation realistically act on this decision?

When the answer is uncertain, the decision should not be treated as implementation-ready. It should be tested, adjusted and strengthened before people are expected to absorb the consequences.

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

Change Lab can work alone or as part of a wider assurance pathway.

Where the change depends on operational truth, stakeholder alignment, public confidence or high-stakes approval, Change Lab can connect with other MOI Labs.

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

What Is AI Simulation and Why Should New Zealand Businesses Care?

by
AI Simulation Insight

What Is AI Simulation and Why Should New Zealand Businesses Care?

Every organisation makes decisions based on incomplete information. AI simulation does not fix that, but it lets you see how those decisions are likely to play out before you commit real money, real people and real reputation to finding out the hard way.

Topic AI simulation for decision quality
Audience New Zealand businesses, councils and complex organisations
MOI lens Decision Assurance Lab
Core issue The gap between deciding and knowing what happens next
The decision gap

The gap is between deciding and knowing what happens next.

There is a gap in how most New Zealand businesses make decisions, and it is not where people think it is.

The gap is not in strategy. Most organisations have more strategy than they can execute. It is not in data either. There is plenty of it, even if it is messy. And it is not in leadership intent. Most leaders want to make good decisions.

The gap is between deciding and knowing what happens next.

AI simulation exists to test consequences before the organisation has to learn them through cost, resistance, rework or public backlash.

A council approves a rates increase. What happens to public trust? Which community groups mobilise? Does the backlash hit the mayor’s office or the front-desk staff first?
A business restructures its customer service team. Where do the bottlenecks appear? Which processes break? Does the workload redistribute evenly or crush the two people who already carry everything?
An organisation rolls out a new system. Who adopts it? Who works around it? Where does the training fail to translate into changed behaviour?
Plain language

AI simulation is structured exploration of consequences.

Strip away the jargon and AI simulation is a straightforward concept: you build a model of how your organisation, community or system actually works, then you run scenarios through it to see what is likely to happen.

It is not prediction. Nobody is claiming to tell the future. It is structured exploration of consequences, a way to ask “what if” questions against a realistic model of your environment rather than against assumptions in someone’s head.

Traditional planning does this informally. Leaders sit in a room, discuss options and mentally model the likely outcomes. The problem is that mental models are limited by individual experience, biased by optimism and invisible to everyone else in the room.

How it works

AI simulation makes assumptions explicit, visible and testable.

Two people can look at the same proposal and have completely different assumptions about how it will land, and neither knows the other’s assumptions exist.

AI simulation makes those assumptions explicit. It builds them into a model you can see, test, challenge and refine. Then it runs scenarios across that model, not once, but many times under different conditions, to show the range of likely outcomes rather than the single outcome you were hoping for.

The AI component accelerates what would otherwise take weeks of manual analysis. It synthesises messy inputs, including interview data, operational metrics, stakeholder feedback and financial constraints, into a coherent model faster than any team could do manually.

But the human stays in charge. AI does not make the decision. It shows you what your decisions are likely to produce, so you can adjust before committing.

See Decision Assurance Lab → Explore the Lab system →
Why this matters now

Three pressures are converging on New Zealand businesses and public organisations.

AI simulation is relevant now in a way it was not even two years ago because organisations are being asked to make bigger decisions with less margin for error.

The cost of getting decisions wrong is rising.

Cost Failed decisions are harder to absorb.

Margins are tighter. Budgets are constrained. Councils are under pressure from ratepayers. A botched restructure or system implementation can set an organisation back years.

Pace Change is stacking up.

AI adoption, digital transformation, service redesign and workforce restructuring are often happening simultaneously, without a clear view of how they interact.

Trust Public confidence is fragile.

Councils and public organisations need to understand not just operational impact but civic impact: how communities respond, where resistance forms and what narratives take hold.

AI simulation addresses all three by letting leaders test before they commit, grounded in actual data, actual constraints and the actual operating environment.

This is also why the work often connects with Civic Lab, Engage Lab, Change Lab and Decision Assurance Lab.

What it looks like in practice

AI simulation is an approach to decision-making, not a single tool.

This is not a single platform. It is a decision approach that uses AI-supported models to explore outcomes across several practical use cases.

Use 01
Organisational reality mapping.

Before you can simulate change, you need to know how things actually work today: where work gets stuck, where handoffs fail, where decisions stall and where informal workarounds keep things running.

Use 02
Change impact simulation.

Before a restructure, new system, automation programme or service shift goes live, you model it against the operational baseline to test workload, capacity, service levels and friction.

Use 03
Stakeholder and civic simulation.

For councils and public organisations, simulation can model how different community segments may respond, where trust is fragile and where engagement needs to build legitimacy.

Use 04
Decision stress-testing.

Before committing to a major investment, policy change or transformation programme, leaders can test operational constraints, funding scenarios, adoption dynamics and stakeholder behaviour over time.

Use 05
Scenario comparison.

AI simulation lets leadership teams model several scenarios side by side, with explicit assumptions and transparent reasoning, so options can be compared on evidence rather than instinct.

Implementation through Changeable → Explore Insights Lab → Explore Change Lab →
What AI simulation is not

The boundaries matter.

The term “simulation” can carry expectations from other fields that do not apply here.

It is not engineering-grade modelling that predicts outcomes to three decimal places. The goal is decision-ready insight, not false precision.
It is not a platform clients buy and operate. In the MOI model, simulation is a consulting methodology supported by AI, not a software product.
It is not a replacement for human judgement. The simulation informs. Leaders decide.
It is not a crystal ball. It shows likely consequences based on the best available evidence and explicit assumptions.

When assumptions change, the model changes. That is a feature, not a flaw. It means the reasoning is traceable and challengeable.

The New Zealand opportunity

New Zealand has characteristics that make AI simulation particularly valuable.

New Zealand is small enough that decisions have outsized impact. A restructure in a 200-person council affects a meaningful part of the community it serves. A botched system implementation in a regional business can lose money and the institutional knowledge of the people who leave because of it.

We also have a concentrated stakeholder environment. In many New Zealand communities, the people affected by a decision and the people making it are separated by one or two degrees. This creates accountability, but it also creates pressure to get things right the first time.

Our public sector is being pushed to adopt AI while still figuring out how. The government’s own AI direction and responsible AI guidance are useful, but organisations still need practical ways to test where AI will genuinely remove work and where it may simply shift problems elsewhere.

NZ AI Strategy → MBIE Responsible AI → MOI Ethical AI Policy →
Where to start

AI simulation does not have to start as a large enterprise exercise.

A focused simulation engagement can be scoped around a single decision, a single service area or a single change programme. It does not require perfect data. It works with what exists and fills gaps through targeted discovery.

The starting point is almost always understanding reality. What is actually happening in your organisation today? Where does work get stuck? Where are the constraints? What assumptions are being made about capacity, capability and readiness that may not be true?

Once that baseline exists, everything else becomes possible: change simulation, scenario comparison, stakeholder modelling and decision stress-testing. Every decision after that is made against evidence rather than optimism.

The takeaway

The organisations that navigate the next few years best will test strategy against reality before committing to it.

The organisations that will navigate the next few years most successfully will not simply be the ones with the best strategies. They will be the ones that tested those strategies against reality before committing to them.

Ministry of Insights uses AI-supported simulation to help councils, SMEs and complex organisations make better decisions with less regret.

Next step

Bring the decision before reality tests it for you.

If your organisation is considering a restructure, service redesign, system implementation, automation programme, AI adoption pathway or public-facing decision, the best time to test the consequences is before commitment hardens.

Talk to MOI → Explore Decision Assurance Lab → Explore the AI Simulation Labs →
Related decision support

AI simulation sits behind the wider MOI Lab system.

The Lab system applies AI-supported simulation to different kinds of decision pressure, including operational reality, civic consequence, stakeholder alignment, adoption risk, independent challenge and full decision assurance.

MOI Lab system → Civic Lab → Insights Lab → Change Lab →

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 →