Every ministry has one: a system that cost real money, was launched with a ribbon and a workshop, and now sits unused while staff quietly returned to spreadsheets. The software worked. The project failed. Having built and rebuilt systems for national programmes, including the HSNP management information system and a national GIS monitoring platform for housing, we have strong views about why this happens and how to prevent it.
Launch is the easy part. The test that matters comes eighteen months later: has the system survived a staff transfer, a budget cycle and a version update without the original developers in the room? Most procurement evaluates the build. Almost none evaluates the handover, and that is precisely where the investment is won or lost.
A system designed for the IT department a ministry wishes it had will fail the department it actually has. Before we write a line of code, we map who will administer the system, what they already know and what training can realistically change. Feature lists shrink when this discipline is applied. Survival rates rise.
We hand over source code, admin guides, user manuals and a maintenance plan as contract deliverables with acceptance criteria, not as goodwill at the end. When documentation is priced and inspected like concrete, it gets built like concrete.
An empty system convinces nobody. Migration of existing records, however messy, belongs in the core scope. The moment staff see their own caseloads, their own sites and their own history inside the new system, adoption stops being a training problem and becomes momentum.
The question is never whether the system works. It is whether it still works when nobody from the project is left in the building.Omariman digital systems team
Public digital systems are infrastructure. Specified, inspected and handed over with the same seriousness as a classroom or a borehole, they last. Treated as an IT purchase, they join the graveyard. The choice is made at procurement, long before the first line of code.
