Three programmes dominate the public record of large public-sector IT failure. Read for the usual purpose they produce a list of things to avoid. Read for one question — what was handed over, to whom, and against what evidence — they produce something more specific.
Each is a historical case bounded by the audit that documents it, and the boundaries matter as much as the findings.
Phoenix: the cancelled readiness evidence
Canada’s federal pay system implementation was examined by the Auditor General in 2018, covering delivery and implementation through the second rollout in April 2016. That report excludes a full examination of the decisions leading to pay-advisor centralisation, and of later remediation.
Within that scope, three findings bear on transfer. Testing was incomplete, with records of pay functions removed or deferred. The planned departmental pilot was cancelled in June 2015, without an assessment of what cancelling it would cost. And there were weaknesses in involving and preparing the recipient departments, including unclear test criteria and incomplete risk information — alongside broader management and oversight failures.
The transfer reading is narrow and useful: the recipient’s requirements, the readiness evidence, the unresolved risks, and the decision authority stopped being connected to each other at the point of implementation. What the case does not establish is that any particular contracting structure would have prevented the outcome.
A March 2026 audit summary gives a favourable overall assessment of project management for the replacement while that replacement remained in planning, and identifies slow simplification of pay rules and the risk of unresolved transactions carrying errors into the new system. A favourable assessment of a plan is not a delivered result.
HealthCare.gov: sender and recipient inside one organisation
The 2016 inspector-general case study covers management of the Federal Marketplace, primarily through the second open-enrolment period in February 2015. Its method was interviews with selected officials, staff, contractors, and stakeholders, alongside document and testimony review, with purposive respondent selection and defined search parameters among its stated limitations.
The organisational finding is the transfer-relevant one. Moving marketplace work into CMS in January 2011 supplied resources and split policy and technical staff across divisions, and unclear leadership and coordination are identified among the contributors to the launch problems. The boundary that mattered was internal.
The contractor transition is documented as a sequence: one contractor leading with another supporting, the roles reversing, then the second performing the work with consultation as needed. Managers from both described it as smooth, which is attributed testimony rather than a measured outcome.
Recovery was substantial and the report retains continuing functionality, cost, and management concerns alongside it. So the case informs questions about leadership across organisational boundaries and about overlap between sender and recipient. It does not establish that phased handover caused the recovery, and its timing is not a template.
NPfIT: the component is the unit
The National Programme for IT in the NHS in England is documented by a 2011 audit of detailed care-record delivery and a 2013 review of the final benefits statement.
The 2011 report distinguishes useful national infrastructure and services from detailed care-record delivery that was delayed, reduced, and incomplete. It describes local trusts as responsible for business change, training, and system acceptance while central bodies managed the contracts, and warns of uncertainty about contract management, future costs, and service transfer as organisational arrangements changed.
That split is the transfer structure: acceptance responsibility sat locally and control over supplier terms sat centrally. A useful hypothesis from this case names a particular recipient duty and asks what authority, information, or capacity was needed to perform it — then tests that against evidence about product functionality, supplier delivery, and changing requirements. Diagnosing local resistance from deployment delay alone does not survive that test.
The 2013 review found a structured approach to compiling costs and benefits alongside substantial uncertainty, no comprehensive original baseline, and omitted future costs and benefits for one system. It explicitly did not validate individual figures, examples, or narrative. The word final in a benefits-statement title is not a claim about realised benefits.
Reading cases without overreaching
Process tracing tests hypothesised mechanisms against their observable implications, including contrary evidence, and requires attention to alternative explanations and to the possibility of several mechanisms operating together.
The practical discipline is separating four things that case narratives merge: dated events, judgements attributed to their source, the analyst’s mechanism hypothesis, and the evidence that would weaken it. Plans, assessment decisions, observed execution, and subsequent outcomes go in separate fields.
Two tests keep a hypothesis honest. Would the same evidence be expected if the proposed mechanism were false? If so it discriminates poorly. And is missing documentation informative here — which depends on whether its creation, retention, and availability were expected under the conditions that applied.
The three programmes also share a selection problem. They are documented because they went badly, which makes them evidence about failure modes and poor evidence about frequency. Cases with no audit are absent from the record by construction.
The rule
What stays fixed is that each finding belongs to a component, a date, and a source scope. What changes is which component resembles the engagement under study, and that comparison is the only thing that makes a case transferable.
Not to be confused with
A current assessment. All three entries are historical. None describes the present state of the payroll system, the marketplace, or NHS technology.
A single cause. Each audit identifies multiple contributing factors, and a transfer explanation competes with delivery, product, and requirements explanations rather than replacing them.