Only around 15% of African e-government projects succeed as intended—and the reason is rarely that the technology is wrong, but because of procurement structure, change management, and vendor dependency. Five patterns account for most failures: misaligned procurement incentives, technology-first design, inadequate connectivity assumptions, staff non-adoption, and absence of post-launch ownership. Each has a proven fix.
The typical government procurement process evaluates vendors primarily on price and compliance documentation. Technical evaluation criteria—code quality, data architecture, offline capability, scalability under African infrastructure conditions—are either absent from tender specifications or assessed by committees that lack the expertise to evaluate them accurately.
The result is a selection bias toward large foreign vendors with robust compliance teams and thin local delivery capacity, and away from smaller, locally-grounded firms that understand the operating environment but struggle with lengthy tender requirements. The irony is that technical capacity—the thing most likely to determine whether the system works—is the least reliably assessed dimension of procurement.
The fix: require a technical proof of concept or working prototype as part of the tender evaluation, scored by an independent technical panel with AI and software engineering expertise. At least two West African finance ministries have adopted this approach in the past 18 months and report dramatically improved vendor quality at similar cost.
The most expensive mistake in government digitisation is to digitise a broken process rather than fix the process first. The system is faster than the paper version. It is still dysfunctional.
Effective digitisation begins with process mapping and redesign. What decisions need to be made? Who has the authority to make them? What information is genuinely required? What steps exist only because the paper-based system required them and can be eliminated in a digital environment? The answer to these questions should precede any technology selection by months.
The digital system was then built for the redesigned process—which is why it works.
Government digital systems are routinely specified and tested on urban broadband connections. They are then deployed to district offices with 2G connectivity, frequent power outages, and shared devices. Systems that work flawlessly in the ministry's Accra headquarters fail consistently at the district level—which is precisely where the highest volume of citizen service delivery occurs.
Every government digital system deployed in Africa should be designed and tested under degraded connectivity conditions from the start. This means offline-first data entry, synchronisation that handles conflict resolution gracefully, interfaces optimised for slow load times, and device compatibility testing on low-end Android handsets. These are not optional features to add later. They are table stakes for any system that needs to work outside the capital.
Digital systems fail when the staff who operate them do not use them. Staff non-adoption is rarely about the technology—it is about change management. Civil servants who were not consulted in the design process, who received inadequate training, and who do not understand how the new system affects their existing workflows will find ways to work around it. Within six months of go-live, parallel paper systems reemerge.
The fix requires involving end-users in design from the start, building training programmes that are specific to roles rather than generic, and identifying internal champions at each deployment site before launch. Change management is not a communication exercise. It is sustained, personalised support through the discomfort of new ways of working.
Finally: many government digital systems are delivered by vendors and then abandoned to ministries that lack the technical capacity to operate and maintain them. When the vendor's support contract ends, so does system functionality. The only sustainable model builds internal government capacity—either within the ministry or within a shared government IT service—to own and evolve the system independently.
Nova Create Hub, 32 Fourth Circular Rd 9, Cantonments, Accra, Ghana. info@novacreatehub.com