Nigeria has produced some genuinely world-class digital government projects in the last decade. The Lagos State Residents Registration Agency (LASRRA), the National Identity Management Commission (NIMC) integration layer, and several state-level revenue management platforms have demonstrated that public sector digital transformation in Nigeria is not only possible but can be done at speed and scale.

We have had the privilege of delivering three major government platforms and contributing to several others as systems integrators. Here is what we have identified as the factors that separate successful programmes from the ones that stall — or worse, get completed but never used.

Lesson 1: Political Will Is a Technical Requirement

In the private sector, a digital transformation programme needs executive sponsorship. In government, it needs political will at the ministerial or gubernatorial level — and this is a harder thing to sustain.

The revenue management platform we built for a state government was preceded by two failed attempts by other vendors over eight years. The third attempt succeeded not because the technology was different (it was not dramatically so) but because a new governor had staked political capital on it as a visible demonstration of reform. Ministerial-level attention meant that procurement moved faster, inter-departmental conflicts were resolved quickly, and legacy staff resistance was managed actively rather than ignored.

When evaluating a government engagement, the first question we now ask is: "Who owns the outcome politically, and what happens to them if this fails?" The answer predicts the project's probability of success more reliably than any technical assessment.

Lesson 2: The Citizen Experience Must Be Simpler Than the Alternative

Government digitisation projects fail adoption when they translate existing bureaucratic complexity into digital form. A 14-step paper form that becomes a 14-screen digital form has not improved the citizen experience — it has just moved the frustration to a different medium.

The LASG revenue platform we built was designed with a different principle: a Lagos resident paying a land use charge should be able to complete the entire transaction on a feature phone via USSD in under three minutes. That design constraint forced simplification at every step — of the process, of the data required, and of the integration with backend tax assessment systems.

Citizen adoption of digital government services follows the same logic as consumer app adoption: if it is not markedly easier than the alternative (walking to a government office), people will choose the alternative.

Lesson 3: Offline-First Architecture Is Not Optional

Any government digital service designed for Nigerian citizens must work on intermittent connectivity. This is not a constraint unique to rural areas — Lagos has significant connectivity gaps, and the population of Nigerians who regularly experience slow or absent internet access is large even in urban centres.

For our government projects, this means:

  • Progressive web apps with offline caching for core functions
  • USSD channels as a first-class interface, not an afterthought
  • SMS confirmation and notification rather than (or in addition to) email
  • Sync architecture that handles intermittent connectivity gracefully — queuing local actions and syncing when connection is restored
  • Graceful degradation at every layer — the system should degrade to partial functionality, never to a crash or a white screen

Lesson 4: Legacy Integration Is the Long Tail

Every government digital transformation encounters a moment when the new system needs to integrate with a 1990s Oracle database, a COBOL system running on hardware that is no longer manufactured, or a proprietary software package whose vendor no longer exists.

This is inevitable, and it is consistently underestimated in project timelines. The discovery that a tax assessment system exposes no API, and that the data can only be extracted via screen-scraping or manual re-entry, happens in month three of a twelve-month project and can consume months of remediation work.

Our standard approach: include a dedicated legacy integration discovery sprint in the first month of every government engagement, before the project timeline is fixed. The findings from this sprint establish the realistic integration scope — and sometimes change the architecture of the entire solution.

Lesson 5: Sustainability Requires Local Ownership

The most common failure mode of successful government technology projects is what happens three years after go-live. The vendor has moved on. The internal champions have been transferred or promoted. The engineers who were trained have left for higher-paying private sector roles. The system is running but nobody fully understands it, and when something breaks, it breaks for weeks rather than hours.

Every government engagement we undertake now includes an explicit technology transfer programme: detailed technical documentation written for successors, not for the team that built it; a minimum of six months of joint operations with government IT staff before full handover; and a support retainer structured to gradually reduce our involvement rather than terminate it abruptly.

The measure of a successful government technology project is not whether it goes live. It is whether it is still running well, and still being used by citizens, five years later.