The pattern we keep seeing
A State Ministry of Health launches an HMIS. The procurement took eighteen months. The vendor delivered on the contract. The training was done in three regional centres. Three years later, the system has a 14 percent monthly login rate among facility staff. Field workers continue to keep paper registers because the paper registers are what they actually use to make clinical decisions, and the digital system is what they use to satisfy the monthly reporting requirement. The Ministry, in turn, receives reports that have been entered twice: once on paper for clinical use, and once into the system for reporting. The system has not improved a single clinical decision. It has, however, added a step.
This is not a story about a bad vendor, a bad platform, or bad staff. It is the most common pattern of digital system failure we encounter in our evaluation work, and it is almost never diagnosed correctly. The diagnosis is usually that the platform was poorly chosen, that the training was inadequate, that the connectivity was unreliable, or that the staff were resistant. None of these are wrong, exactly. They are just downstream of the actual problem.
The actual problem is that nobody, at any point in the procurement, asked the only question that matters: what decision is this system meant to inform?
What the failure numbers actually say
The figure most commonly cited in this space, that 70 percent of digital transformations fail, has become a kind of incantation on the opening slide of digital strategy decks. It is worth tracing where it comes from, because the provenance matters for what we do with it.
The figure is a paraphrase drawn from several sources. BCG's 2020 research, Flipping the Odds of Digital Transformation Success, found that 70 percent of digital transformations fell short of their objectives. The breakdown is more useful than the headline: 30 percent of transformations fully succeeded, 44 percent created some value but missed their targets, and 26 percent created little or no value. Bain's 2024 study went further, finding that 88 percent of business transformations failed to achieve their original ambitions. McKinsey's 2018 global survey found that only 16 percent of respondents said their digital transformations had both improved performance and sustained the improvement.
For work in the development and government sectors, the most honest anchor is older and starker. Richard Heeks, in his 2002 paper Information Systems and Developing Countries: Failure, Success, and Local Improvisations, argued that the majority of information systems introduced into developing country contexts fail either totally or partially, and the failures cluster around a predictable set of gaps between the design assumptions of the system and the operational realities of the organisations meant to use them.
The headline numbers matter less than the pattern underneath them. The pattern is this: technology deployed without a clearly defined function tends to underperform, regardless of how good the technology is. The 70 percent, the 88 percent, and Heeks's "majority" are all measuring versions of the same thing.
The function-first principle
By "function" we do not mean a feature, a use case, or a department. We mean the specific decision the system must support, the workflow that decision sits inside, and the user outcome the system is meant to produce. A digital system that does not change a decision is a digital system that has not earned its budget.
Heeks's design-reality gap framework (ITPOSMO) is the most useful diagnostic we know of for anticipating failure before it happens. The framework rates the gap between design assumptions and operational reality across seven dimensions: Information, Technology, Processes, Objectives and Values, Staffing and Skills, Management Systems, and Other Resources. In the cases we evaluate, the largest gaps are almost never on the Technology dimension. They are on Information (the system assumes data exists that does not exist), on Processes (the system assumes a workflow that the organisation does not actually perform), and on Objectives and Values (the system assumes that the people meant to use it want what the system is offering them).
The WHO Global Strategy on Digital Health 2020–2025 puts it bluntly: digital health initiatives must be guided by a strategy that integrates financial, organisational, human, and technological resources — in that order. Technology is listed last. It is not a typo.
Before a single platform is shortlisted, three questions should be answerable on one page:
(1) What decision will this system change, and for whom?
(2) Whose workflow does this decision sit inside, and what does that workflow look like today?
(3) What does the user need to do their job better, and what would they do differently with the information the system provides?
If a commissioning party cannot answer these three questions in plain language, no amount of vendor selection or platform evaluation will rescue the engagement.
Case 1 — the HMIS nobody opens
The HMIS pattern we described in the opening is not hypothetical. In our own technological development work, we have built and supported health management information systems for State Ministries of Health in Nigeria, including an offline-first, web-based HMIS that digitises patient records, automates monthly reporting, and provides role-based access for several hundred facility and district staff. The lesson from those engagements is that two design philosophies produce radically different adoption outcomes, even when the underlying technology is similar.
The first philosophy builds around the reporting requirement. The system captures what the Ministry wants to know, in the format the Ministry wants to receive it, on the schedule the Ministry wants to receive it. Clinicians experience this system as additional work that does not change their day. Adoption is low, data quality is poor, and the Ministry eventually accepts that the paper register is the source of truth and the system is the source of reports.
The second philosophy builds around the clinical decision. The system captures what the clinician needs to make a better decision at the point of care: the patient's history, the contraindications, the drug interactions, the stock position of the next clinic. Reporting is a byproduct, generated automatically from clinical use, not a separate workflow. Adoption is high, data quality is high, and the Ministry gets reports that are one week fresher than they were under the paper system.
The same platform, configured differently, produces either shelfware or the system that the whole team opens on Monday morning. The difference is not the technology. The difference is which function the technology was built to serve. Bagherian and colleagues, in their 2022 review of health information systems in developing countries, concluded that organisational and human elements play a more critical role in the success or failure of these systems than the technical elements do — a finding that maps almost exactly onto what we see in the field.
Case 2 — when digitising a paper form just makes a faster paper form
The same pattern repeats in field data collection. An organisation has a paper instrument that has been refined over years of use. The instrument works, in the sense that field staff know how to administer it, supervisors know how to check it, and analysts know how to read it. The organisation decides to digitise. The vendor scans the paper form into a mobile app, replicates every question, every skip pattern, every validation rule. The app is deployed. The data comes back faster and cleaner, which is a real improvement.
But the underlying instrument was designed for paper. Paper instruments optimise for compactness (because each page costs money to print) and for clarity of handwriting (because someone has to read it later). A digital instrument should optimise for different things: for the decision the data must inform, for the workflow of the enumerator, for the constraints of the field, and for the analytical plan that will be applied to the dataset. A direct translation of a paper form into a digital form usually fails on all four of those dimensions, even though it succeeds at digitisation.
We have built mobile data collection systems for field research, including an offline-capable React Native application with local SQLite storage that allows field researchers to collect survey data in zero-connectivity areas and sync automatically when connectivity is restored. The offline capability is what the spec usually emphasises, but it is the least interesting part of the system. The interesting part is that the instrument was redesigned around the decisions the data had to inform: which questions were essential, which were nice to have, which could be derived, and which could be dropped. The offline capability is just plumbing. The function-first redesign is what made the system produce decision-ready data.
Case 3 — dashboards nobody opens on Monday morning
Gartner has reported for years that 70 to 80 percent of business intelligence initiatives fail, and that analytics and business intelligence tools are used by only around 29 percent of employees on average. The reasons are usually summarised as adoption problems. They are really function problems.
A dashboard that displays data is not the same as a dashboard that supports a decision. The first is read once, by the person who commissioned it, and then forgotten. The second is opened every Monday morning, by the person whose job depends on the decision it informs, because it tells them something they need to know that they cannot get any other way.
We built and deployed a mobile-to-web dashboard for field officers to upload GPS-tagged water point functionality data, enabling real-time tracking of 400 boreholes and reducing reporting lag from 30 days to under 24 hours. The reporting lag reduction is the part that gets quoted. It is the wrong headline. The reason the reporting lag dropped from 30 days to 24 hours is not that we built faster technology. It is that the system was built around a specific decision: which borehole needs repair this week? Every design choice — the GPS tagging, the mobile-first input, the daily refresh, the colour-coded failure status — was in service of that decision. The reporting lag improvement was a byproduct of building for the right function, not the goal of the project.
How to apply function-first thinking
A practical diagnostic before any digital procurement
- Define the decision. Write down, in one sentence, the decision this system is meant to change, and the person who will make that decision. If you cannot, stop.
- Map the workflow that decision sits inside. Walk the workflow from end to end with the people who actually perform it. Note where information is lost, delayed, or distorted. The system should fix one of those points, not add a new step alongside them.
- Identify the smallest unit of technology that serves that decision. Resist the temptation to procure a platform that solves seven problems at once. Solve one. Prove it. Then expand.
- Specify what the user would do differently with the information. If you cannot describe the behavioural change the system is meant to produce, the system will not produce it.
This diagnostic is not exotic. It is, in substance, an application of the OECD-DAC evaluation criteria — relevance and efficiency in particular — to a digital investment decision. A digital solution that does not pass a relevance test (is this the right thing to do?) and an efficiency test (is this the best use of resources to do it?) should not be funded, regardless of how attractive the platform demo looks. The World Bank's Digital Adoption Index and the 2025 Digital Progress and Trends Report make the same point at the macro level: digital adoption, in itself, does not produce dividends. The function the digital adoption serves does.
The work, not the wire
We build digital systems for a living, and we will continue to. But the most consequential work we do on any engagement is the conversation that happens before a single platform is shortlisted. That conversation is about the function: the decision, the workflow, the user, the change. The technology is downstream of that conversation, and it is the easiest part of it. The hard part is asking the question that the procurement process is usually designed to skip.
If your organisation is about to commission a digital system — an HMIS, a field data collection app, a dashboard, a platform — and you have not yet answered the four questions in the diagnostic above, that is the work to do first. We are happy to be part of that conversation. The platforms can wait.
References
- Heeks, R. (2002). Information Systems and Developing Countries: Failure, Success, and Local Improvisations. The Information Society, 18(2), 101–112. tandfonline.com/doi/abs/10.1080/01972240290075039
- Heeks, R. Design-Reality Gap Analysis (ITPOSMO framework). eGovernment for Development, University of Manchester. egov4dev.org/success/techniques/idfailure_drg.shtml
- Boston Consulting Group (2020). Flipping the Odds of Digital Transformation Success. bcg.com/publications/2020/increasing-odds-of-success-in-digital-transformation
- Bain & Company (2024). 88% of Business Transformations Fail to Achieve Their Original Ambitions. Press release, 15 April 2024. bain.com (press release)
- McKinsey & Company (2018). Unlocking Success in Digital Transformations. McKinsey Global Survey on digital transformations.
- World Health Organization (2021). Global Strategy on Digital Health 2020–2025. ISBN 978-92-4-002092-4. who.int/publications/i/item/9789240020924
- Bagherian, H., et al. (2022). Health Information System in Developing Countries: A Review. (PMC9700424.) pmc.ncbi.nlm.nih.gov/articles/PMC9700424
- Health Metrics Network / WHO. Framework and Standards for Country Health Information Systems. WHO Regional Office for Africa. afro.who.int (PDF)
- World Bank. Digital Adoption Index (DAI). World Development Report 2016: Digital Dividends. worldbank.org/en/publication/wdr2016/Digital-Adoption-Index
- World Bank (2024). Digital Progress and Trends Report 2025. openknowledge.worldbank.org
- OECD. DAC Evaluation Criteria: relevance, coherence, effectiveness, efficiency, impact, sustainability. oecd.org/evaluation-criteria
- Gartner. Analytics and Business Intelligence Platforms. Cited in CIO, "4 reasons most companies fail at business intelligence" (2017). cio.com/article/230614
- GSMA (2024). The Mobile Economy: Sub-Saharan Africa 2024. gsma.com/mobile-economy/sub-saharan-africa-2024