Implementation Science: Pilot to Scale

Most African digital health projects fail not because the technology is weak, but because they were built as pilots: staffed for a demonstration, then ended when the grant closed, the champion transferred, or the server bill arrived. This Level II course is the treatment protocol for the pathology the field calls pilotitis. In eight weeks (15 CEU), it teaches the discipline that turns a prototype into a system that is simply how the health system works, grounded in the NASSS framework, the MAPS toolkit, and WHO investment guidance.

You will run a disciplined lifecycle that baselines the problem before choosing technology, escape pilot purgatory through design-for-scale and institutionalization, lead the change that wins adoption, defeat the donor cliff through full-lifecycle costing and domesticated financing, and build monitoring and evaluation that steers adaptation. Drawing on African programs, it suits program officers, implementers, project leads, and students in health, informatics, and management.

Course glossary

• Pilotitis (pilot purgatory) — the field's defining failure pattern in which technically successful pilots fail to scale or sustain because they were designed, financed, and staffed for demonstration rather than absorption.
• Donor cliff — the abrupt loss of a service when grant financing ends and no domestic budget line or revenue instrument has been prepared to absorb its recurrent costs.
• Institutionalization — the deliberate, dated transfer of every life function of a system (budget line, staffing establishment, maintenance contract, governance home, data ownership) from a project to a government institution.
• Scale (institutional condition) — the state in which a system's functioning no longer depends on any particular project, person, or donor.
• Problem statement with a baseline — a quantified statement of a gap, its affected population, its workflow location, and its proximate cause, used as the reference point for all later design and evaluation.
• Health system challenge / bottleneck / pain point — the generic name for a gap (e.g., "loss to follow-up"); the same gap from the system's view; and the same gap in the affected person's own words.
• Alignment — the degree to which an intervention sits inside the national architecture and strategy, thereby inheriting financing, governance, and scale pathways.
• Coalition for scale — the durable multi-stakeholder group that co-owns a system from inception through institutionalization, with the eventual owner as protagonist throughout.
• NASSS framework — a model locating digital health failure in accumulating complexity across seven domains (condition, technology, value proposition, adopters, organization, wider system, embedding/adaptation over time).
• Design for scale — making the architecture, unit-economics, workforce, operations, and evidence decisions required for national absorption at version one.
• Unit economics — the cost per facility or per user, and its trajectory with scale, used to test national affordability early.
• Run on roles, not heroes — documenting operations so any competent person in a defined role can run the system, immunizing it against champion turnover.
• Decision rules — pre-committed, written criteria specifying what evidence will trigger scaling, redesigning, or stopping a pilot.
• Rational resistance — well-founded user reluctance responding to genuine costs (added time, broken-tool history, status anxiety, surveillance) rather than to ignorance.
• Value equation — the user-level balance between a system's demands and its perceived value; adoption fails when demands exceed value to the user.
• Dual-entry trap — the abandonment-inducing practice of running paper and digital in parallel indefinitely rather than to a short, dated cut-over.
• Champion / super-user — a respected peer or clinical leader who fronts the change and provides standing internal training and support.
• New mindset — a workforce culture treating data as a clinical instrument, expecting evidence-argued decisions, and regarding tool-learning as ordinary professionalism.
• Institutional rituals — recurring practices (data review meetings, audit cycles, feedback loops) that make data consequential and build a data-use culture.
• Total cost of ownership (TCO) — the full five-to-ten-year cost across capital and recurrent categories, in which recurrent (operating) costs typically dominate.
• CapEx / OpEx — one-off capital costs (devices, development, launch training) versus ongoing operating costs (hosting, support, replacement, onboarding, governance) that determine survival.
• Domestication — migrating a system's core operating costs onto durable domestic instruments before external financing recedes.
• Health financing integration — embedding digital services in insurance, reimbursement, and purchasing so the system becomes revenue infrastructure rather than a cost center.
• Contracting for outcomes — a public-private model (e.g., Zipline's pay-per-delivery) in which the partner finances capability and the state pays against a performance specification, governed by exit clauses and data sovereignty.
• MEL — monitoring, evaluation, and learning: the discipline of measuring a system to steer its adaptation, not to decorate reports.
• Logic model / theory of change — the explicit causal chain from inputs through activities, outputs, and outcomes to impact.
• Adoption / performance / equity indicators — the three indicator families that belong permanently on every dashboard: active use, the targeted process change, and disaggregated reach.
• Adaptive management — short review cycles against pre-set decision rules, documented adaptations, and the authority to redesign or stop.
• Strategic persistence — sustained, problem-first, evidence-steered effort across political and funding cycles, the decade-long condition of durable scale.
• DIIG — the WHO Digital Implementation Investment Guide, the systematic reference for planning, costing, and implementing digital health interventions within a digital health enterprise.
• MAPS toolkit — the WHO/ITU mHealth Assessment and Planning for Scale instrument, assessing scale-readiness across management, financing, technology, partnerships, and integration.

Frequently asked questions

Q: What is the single most important idea in this course? A: That you must design for scale and institutional absorption from day one. Pilotitis is not a technology failure; it is a design failure committed in the funding proposal, when a project is built for demonstration rather than for survival. Almost everything else in the course — problem baselining, coalition-building, TCO, domestication, decision rules — is a way of operationalizing that one shift in mindset.

Q: How is "implementation science" different from project management or software delivery? A: Project management delivers a system on time and budget; implementation science makes the system survive — outliving staff turnover, donor cycles, and political change until its functioning depends on no particular project, person, or donor. The build is the easy part; the institutional embedding (financing, governance, ownership, learning) is the discipline this course teaches.

Q: We have a working pilot that everyone praises but it won't scale. Where do we start? A: Run a NASSS pre-mortem (Lesson 2.1) to find which of the seven domains are hot — usually the value proposition for frontline users, the organization's recurrent budget, or the wider system's financing. Then check the five design-for-scale decisions (Lesson 2.2): are you on the national architecture, do you know your unit economics, are you using existing cadres, are operations documented, and did you set decision rules? Praise is not adoption; baseline your adoption and performance honestly before investing another cycle.

Q: What exactly is the "donor cliff" and how do we avoid it? A: It is the abrupt stop that happens when grant money ends and no domestic budget line or reimbursement exists to carry the recurrent costs. You avoid it by domestication (Lesson 4.2): build an honest five-to-ten-year TCO, then schedule the migration of operating costs onto government budget, governed donor transitions, insurance/reimbursement, or disciplined PPPs — and write that transition plan into the funding proposal, not the exit report.

Q: Why does the course insist that recurrent costs dominate, when devices and software look so expensive up front? A: Because over a five-to-ten-year horizon, hosting and connectivity, device replacement every three-to-five years, continuous onboarding for staff turnover, helpdesk and support, maintenance, and governance add up to far more than the one-off build. Pilot budgets fund the visible CapEx and omit the invisible OpEx — which is precisely why systems get built but not kept. A TCO over the real operating horizon makes this undeniable.

Q: Our health workers are resisting the new system. Isn't this just an attitude problem we can fix with training? A: Almost never. Resistance is usually rational — the tool adds workload, or they've seen tools break and vanish, or it exposes them to surveillance, or it inverts status. The fix is to manage the value equation (Lesson 3.1): co-design the workflow, keep dual paper-and-digital periods short and dated, deploy champions, sequence visible wins, and have respected clinicians (not IT staff) front the change. More training on top of a bad value equation just produces more resistance.

Q: What should we actually measure, and how often? A: Keep a small, permanent set: adoption (active use — the honest early warning), performance (the targeted process measure from your baselined problem statement), and equity (disaggregated by geography, gender, language, wealth). Review them on a short cycle (monthly or quarterly) against decision rules you set before launch, and route the data into the routine HMIS rather than parallel surveys so the measurement survives the project. The point of measuring is to steer — including the authority to stop or redesign.

Q: How long does it realistically take to go from pilot to a truly institutionalized platform? A: In the honest experience of the programs this course draws on, the better part of a decade of strategic persistence — sustained problem-first design, coalition maintenance, architecture discipline, costed honesty, financing domestication, and evidence-steered adaptation across political and funding cycles. There is no shortcut, but the payoff compounds: each system that crosses from pilot to platform permanently raises the floor for everything built after it.