Meta: course=implementation · module=1 · lesson=1.1 · ~70 min · keywords: pilotitis, pilot purgatory, donor cliff, sustainability, implementation science, NASSS, design for scale, institutionalization Objectives:
- Define pilotitis and explain the four ways pilots typically end.
- Distinguish a pilot designed for demonstration from one designed for absorption.
- Name the four movements of the implementation discipline that defeat pilotitis.
The African digital health landscape is littered with technically sound projects that worked — and then ended. This is the field's defining pathology, named pilotitis (also "pilot purgatory" or, in the global literature, the failure to scale). It is worth being precise about how pilots die, because each ending has a different cause and a different countermeasure. A pilot ends when the grant ends and no domestic budget line exists to carry hosting, support, or device replacement. It ends when the champion is transferred and the system that ran on one heroic individual loses its only operator. It ends when the server bill arrives because recurrent operating costs were never budgeted — only the launch was. And it ends when the NGO closes its country office, taking with it the staff, the institutional memory, and the maintenance contract. None of these is a technology failure. All of them are design failures, scheduled years in advance by the way the project was conceived.
The structural diagnosis, established across the mHealth and implementation-science literature, is blunt: pilots are typically designed as pilots. They are financed for a fixed term, staffed by a project team rather than the eventual owner, and architected on a bespoke stack that scaling would require redesigning — redesign that no one budgeted. Under those conditions, scale would demand starting over, so the pilot becomes the product. The corollary is the central lesson of this entire course: if you want a system that survives, you must design for scale and for absorption from day one. The choice is not made at the end of the pilot; it is made in the funding proposal.
This is what makes the work implementation science rather than software delivery. The hard part is not building the tool — Chapters 5 and 7 of the founders book cover the toolkit. The hard part is making the tool survive: outliving staff turnover, donor cycles, and political change until its functioning no longer depends on any particular project, person, or donor. The contrast is visible across the continent. South Africa's MomConnect, Ethiopia's national community-health information system (eCHIS), and DHIS2 deployments in dozens of countries are systems that are simply how the health system now works. Against them stand thousands of pilots nobody remembers — the "pilot graveyard" — equally clever at launch, fatally unplanned for the day after.
The treatment protocol has four components, and they organize this course. First, a disciplined implementation lifecycle, beginning with honest problem definition and stakeholder engagement (Module 1). Second, a deliberate strategy for escaping pilot purgatory through designed-for-scale decisions and institutionalization, with change management to carry the people (Modules 2 and 3). Third, financial sustainability, built on full-lifecycle costing and diversified, domesticated financing (Module 4). Fourth, monitoring, evaluation, and learning (MEL) that steers adaptation rather than decorating reports (Module 5). None of it is glamorous. All of it is what distinguishes the platforms now serving millions from the pilots that vanished. As the founders book puts it, health systems are transformed "not by a thousand flowers blooming, but by a few deep roots holding."
Key terms:
- Pilotitis (pilot purgatory) — the field's defining failure pattern in which technically successful pilots fail to scale or sustain because they were designed for demonstration, not absorption.
- Donor cliff — the abrupt loss of a service when grant financing ends and no domestic budget or revenue instrument absorbs its recurrent costs.
- Institutionalization — the deliberate transfer of every life function of a system (budget, staffing, maintenance, governance, data ownership) from a project to a government institution.
- Scale (as an institutional condition) — the state in which a system's functioning no longer depends on any particular project, person, or donor.
Knowledge check: Q: A telemedicine service launched on grant money, performed well for three years, then stopped abruptly. Was this a technology failure? A: No. It was a design failure — domestication of recurrent costs (a budget line or reimbursement) was never scheduled. The diagnosis is "donor cliff," and the cure belonged in the funding proposal, not the exit report.
Q: Why does the founders book say a pilot built on a bespoke stack is "a future migration project"? A: Because scaling it nationally would require rebuilding it on the national platform and standards — redesign work that the pilot never budgeted, which is precisely why such pilots stall.
Q: What single shift in mindset most reduces the risk of pilotitis? A: Deciding to design for scale and institutional absorption from version one, rather than treating scale as a separate phase to plan after the pilot "succeeds."
Summary: Pilots die in four predictable ways — grant, champion, server bill, NGO exit — and every one is a design failure baked in at the proposal stage, not a technology failure. The discipline that defeats pilotitis has four movements (lifecycle, scale/institutionalization, financing, MEL), and its governing principle is to design for survival from day one.