New Zealand INCIS: The Police Information System That Never Delivered Its Promise
New Zealand Police's INCIS program accumulated changing architecture, schedule pressure, commercial disputes, and governance weaknesses until it was disestablished in 1999 without full delivery.
INCIS was meant to modernize policing, not just replace one application
New Zealand Police conceived INCIS as a broad information, investigation, infrastructure, and desktop modernization effort. IBM was selected as preferred vendor in 1992 and the major contract was signed in 1994, creating the largest single capital technology investment Police had undertaken. [1] This mattered because a national police information and investigation platform could not be evaluated like a standalone application. The operational promise depended on software, data, users, interfaces, suppliers, and organizational authority remaining aligned. A milestone that proved only one component therefore gave decision-makers incomplete evidence about whether the service itself was ready. The engineering standard has to be end-to-end mission performance, not the number of modules that compile or contract deliverables marked complete.
The assumption underneath
The case is especially useful because it exposes a hidden assumption in a national police information and investigation platform: that normal operating conditions would continue while a major change was introduced. Good resilience engineering instead assumes partial failure, imperfect data, human workarounds, and delayed dependencies. That is why stable architecture before contracting, smaller increments, credible risk escalation, benefits tracking, and governance that can change the plan have to be designed and rehearsed before the service becomes dependent on the new system.
Independent reviews repeatedly described the program as high risk
The later Ministerial Inquiry reconstructed a history in which schedule, architecture, requirements, and readiness concerns were visible long before collapse. Reviews repeatedly raised risk while official delivery expectations remained ambitious. [2] The recurring weakness was an assumption that problems discovered during delivery could be absorbed without changing the plan. In a system of this kind, unresolved uncertainty accumulates: requirements changes alter tests, architectural changes alter interfaces, and schedule compression removes time for validation. The practical control is to make stable architecture before contracting, smaller increments, credible risk escalation, benefits tracking, and governance that can change the plan explicit go/no-go criteria rather than recommendations that leadership can acknowledge while continuing unchanged.
Why the safeguard was too weak
The case is especially useful because it exposes a hidden assumption in a national police information and investigation platform: that normal operating conditions would continue while a major change was introduced. Good resilience engineering instead assumes partial failure, imperfect data, human workarounds, and delayed dependencies. That is why stable architecture before contracting, smaller increments, credible risk escalation, benefits tracking, and governance that can change the plan have to be designed and rehearsed before the service becomes dependent on the new system.
Architecture changed after the commercial relationship was already committed
Police and IBM were working under contract while important technical choices were still moving. The program reconsidered platform architecture and shifted desktop direction from OS/2 toward Windows NT, forcing redesign and affecting delivery assumptions. [3] Once the problem crossed organizational boundaries, local fixes became insufficient. A contractor could repair code while the customer still lacked clean data; an agency could clarify policy while interfaces remained unstable; a technical team could restore a server while operators no longer trusted the workflow. Reliability therefore depends on containment: failures should stop at well-defined boundaries instead of forcing every connected organization into emergency coordination.
Where the blast radius grew
The case is especially useful because it exposes a hidden assumption in a national police information and investigation platform: that normal operating conditions would continue while a major change was introduced. Good resilience engineering instead assumes partial failure, imperfect data, human workarounds, and delayed dependencies. That is why stable architecture before contracting, smaller increments, credible risk escalation, benefits tracking, and governance that can change the plan have to be designed and rehearsed before the service becomes dependent on the new system.
Commercial disagreement became part of the technical system
As requirements evolved, Police and IBM increasingly disagreed about whether changes were inside the contracted scope, who should pay for them, and what could still be delivered on time. The relationship ultimately collapsed into legal claims and settlement. [4] Recovery also required reconstructing trustworthy state and restoring confidence, not merely restarting technology. Public services keep creating new cases, payments, calls, investigations, or records while engineers work. That means the recovery plan must define what happened during the gap, which transactions can be replayed, which need manual review, and how users learn that the service is safe to rely on again.
Why recovery was harder than expected
The case is especially useful because it exposes a hidden assumption in a national police information and investigation platform: that normal operating conditions would continue while a major change was introduced. Good resilience engineering instead assumes partial failure, imperfect data, human workarounds, and delayed dependencies. That is why stable architecture before contracting, smaller increments, credible risk escalation, benefits tracking, and governance that can change the plan have to be designed and rehearsed before the service becomes dependent on the new system.
The project ended without delivering the integrated promise
By 1999 INCIS was disestablished without completion of all planned deliverables and after substantial delay and cost escalation. Some infrastructure and components retained value, but the integrated operational capability promised by the program did not arrive. [5] The source record shows why the incident cannot be reduced to a single ‘bad software’ explanation. Technical defects mattered, but management decisions determined whether those defects were detected before launch, how far they propagated, and whether warnings changed course. The relevant unit of analysis is the delivery system: architecture, procurement, testing, operations, governance, and the people asked to work around failure.
Government treated INCIS as a lesson for the wider public-sector IT portfolio
New Zealand commissioned a formal inquiry and had already begun broader stocktaking of public-sector IT investment. The response recognized that the failure involved sponsorship, reporting, contracting, architecture, and cross-agency oversight. The remediation lesson is therefore broader than replacing the failed component. Organizations need evidence that stable architecture before contracting, smaller increments, credible risk escalation, benefits tracking, and governance that can change the plan are institutional capabilities rather than promises made after an incident. Those capabilities should be exercised before the next major migration, because an emergency is the worst possible time to discover that ownership, rollback, data reconciliation, or escalation rights exist only on paper.
Smaller capabilities would have created clearer off-ramps
A modular program could have separated desktops, networking, data conversion, investigative workflow, and analytics into increments with measurable policing benefits. That would have made architecture changes less contagious and cancellation less all-or-nothing. A modern implementation can improve the odds by using smaller releases, production-like testing, machine-readable observability, and independent challenge. The purpose is not to eliminate every defect; that is impossible. It is to prevent one defect or one mistaken assumption from acquiring enough authority to become a national service failure. Architecture should be judged partly by how cheaply the organization can discover that it was wrong.
Why INCIS still matters
INCIS demonstrates how large programs fail when uncertainty is locked into a giant contract and risk reporting lacks enough authority to change scope or schedule. The lesson is to create increments that can stand alone and governance that treats warnings as decision triggers. The enduring value of the case is that it links software engineering to public accountability. Citizens cannot switch providers easily when the failing system is an ambulance service, police platform, national benefit, payroll, court evidence source, or health infrastructure. Public-sector reliability therefore requires unusually transparent evidence about readiness, failure, cost, and remediation. Technical uncertainty should be disclosed early enough for oversight to change the decision.
Works Cited
- 01
- 02Ministerial Inquiry into INCIS cs.auckland.ac.nz
- 03New Zealand Treasury — Pre-Election Economic and Fiscal Update 1999 treasury.govt.nz
- 04ANZSOG — INCIS Case Study anzsog.edu.au
- 05New Zealand Government — Information Technology Stocktake beehive.govt.nz
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.