Digital Transformation in Africa: What Actually Works, and What Stalls

The instinct is to open with the most visible system, the one named in the strategy document. The better first phase is a process that is already painful, already measured, and owned by one department, because it produces evidence inside a single budget cycle and buys the political room for the harder work that follows.

A first phase that cannot be evaluated in weeks tends to be evaluated by rumour instead, which is how transformation programmes acquire a reputation before they acquire a result.

Almost every schedule slip we see traces back to source data: records held in three incompatible systems, identifiers that do not reconcile, historic entries captured by hand, exports that arrive monthly when the process runs daily. None of this is unusual and none of it is disqualifying, but it has to be discovered during assessment rather than during delivery.

That is why our engagements open with a two to four week assessment before any build commitment. The purpose is to look at the actual tables and the actual exports, then write a scope against what exists rather than what the org chart implies exists.

Consultancies can build a system. They cannot hold a decision. Programmes move when one named person inside the organisation can settle a scope question in a day, approve access, and say no to additions, and they stall when that authority sits in a committee that meets monthly.

The same person should be the one who inherits the system. If nobody internal wants to own it after handover, that is useful information about the project before it starts rather than after.

A system your team cannot operate is a subscription to the vendor who built it. Training the people who will run the platform, documenting the decisions rather than only the code, and handing over repositories and infrastructure are the difference between an asset and a dependency.

We structure engagements so the client team holds the code and the credentials, with a defined support window after handover instead of an indefinite retainer that quietly becomes the operating model.

In broad terms: a two to four week assessment covering process, data and constraints; an eight to sixteen week build of a scoped system against agreed acceptance criteria; then roughly ninety days of support while the client team takes over day-to-day operation.

Those durations are not a price list, and they move with data quality, integration count and approval cycles. They are useful as a planning frame when you are deciding whether a programme fits a fiscal year.