Why most digital transformation programmes in African banking fail in year two.

The first twelve months are easy. The second twelve are where governance erodes, change fatigue sets in, and competing roadmaps quietly unmake the work.

African business professionals — digital banking transformation

Roughly seven out of every ten large-bank transformation programmes we've studied in East Africa hit their year-one milestones. Roughly three of those seven hit their year-two milestones. The rest don't fail dramatically. They drift — and by month thirty they look, from the inside, like the previous regime with a slightly nicer login screen.

We've been involved, in one capacity or another, with twelve such programmes over the last decade. Some as full implementation partners, some as the team brought in to diagnose why a previous programme stalled. The patterns that emerge are remarkably consistent. This is an attempt to name them.

1. Year one is a different sport from year two

Year one of a bank transformation has clear marks of progress: a new core or channel goes live, a fanfare press release goes out, the board sees a green dashboard. Year one is, in management terms, a building exercise — capital committed, contracts signed, milestones banked.

Year two is operating-model work. The new platform exists; the question is whether the bank's actual processes have moved to it. Day-to-day work is now the work — and it is much, much harder than the work of building.

~70%
Hit year-one milestones
~30%
Reach year-two outcomes
Programme directors changed on average between year 1 and year 3

2. Governance erodes when the launch theatre ends

The steering committee that met weekly for the eighteen months leading to launch shifts to monthly, then quarterly. The executive sponsor moves on to the next thing. The programme director — the person who knew where every body was buried — is promoted or leaves.

What's left is a portfolio of half-migrated systems, a backlog of "phase-two" features, and a steering committee that quietly de-prioritises the ones that are politically difficult. Year two then becomes a slow walk away from the original ambition rather than a march toward it.

A useful test: in year two, who can kill a piece of the original scope? If the answer is "the senior business leader who didn't want it in the first place", the programme is in trouble.

3. Change fatigue is a real, measurable phenomenon

Branch staff who absorbed three system changes in eighteen months are now being asked to absorb a fourth. Risk and compliance, who shouldered the audit burden of the launch, are now being asked to support a new product set on the same platform. Eventually, the organisation refuses — politely, slowly, but firmly.

We measure this by looking at training-completion rates, ticket-deflection patterns, and the proportion of branches meeting a defined "platform-adoption" threshold. By month eighteen, on most programmes, those metrics have plateaued. That plateau is the signal — not later, when the year-two scope formally slips.

What we recommend

Build a change-load budget for the organisation from the outset, and refuse to schedule changes that exceed it. This is a constraint, not a target — and it has to be enforced by the COO, not the programme team.

4. Platform debt compounds invisibly

Every short-cut taken in year one to hit the year-one launch date is now a piece of debt. The integration that was "good enough to go live" still hasn't been productionised. The data-quality rules that were waived for migration have not been reinstated. The reporting layer that was bolted on for the regulator is the only way anyone can actually read the data.

We've found that a deliberate "year-two debt audit" — a structured stocktake of every short-cut taken in the build, with an explicit accept-or-pay-down decision attached to each — is one of the highest-leverage interventions a CIO can run.

5. Competing roadmaps fragment the platform

The new core was supposed to be the platform. By year two, the business lines have all begun building parallel capabilities around it: a separate CRM here, a digital-onboarding mini-platform there, a vendor-supplied loan-origination system that integrates "later". By year three, the bank has the same platform sprawl problem it set out to solve — only at a higher cost base, because the original platform is still in service.

The structural fix here is organisational: a single accountable owner for the platform roadmap, with the authority to say no to a business sponsor without escalating to the CEO. Most banks don't have this role. The ones that succeed in year two created it.

6. AI is making this worse, not better

We hear a lot about generative-AI initiatives layered onto bank transformation programmes. Recent industry research suggests something close to 80% of senior banking executives believe generative AI will be transformative, while only around 20% say their institution is ready to adopt it. Those two numbers, taken together, predict what happens next: a wave of AI pilots that compete with the original transformation for governance attention, budget, and the same scarce engineering capacity.

We are not against AI in banking — there is real value, especially in credit risk, customer service, and fraud detection. We are against running AI as a parallel programme alongside an unfinished platform transformation. The platform has to be done first, or the AI work is built on sand.

What does the 30% do differently?

Across the programmes that made it through year two intact, four things stand out:

  • An executive sponsor whose compensation, not just job description, was tied to year-three outcomes.
  • A programme structure that survived the launch — same director, same operating cadence, same KPIs.
  • A protected "do not disturb" zone around the platform team in year two — no new initiatives, no off-roadmap requests.
  • A quarterly external review by a partner with no stake in the implementation — to give the executive committee an unvarnished view.

None of these are exotic. All of them are politically expensive. That's why most programmes don't do them.

A note on our practice

We typically come in to bank transformation programmes either at month-zero (helping design the operating model and governance from day one) or somewhere around month-eighteen (when the year-two drift is showing and the executive committee wants an honest outside view). Both are valuable. The cost of the second engagement is usually a few multiples of what the first would have cost — but it's also the engagement that, more often than not, saves the programme.

Drawn from twelve programmes across Kenya, Uganda, Rwanda and Tanzania between 2014 and 2025. Anonymised. Any identifying details have been changed.

Read next

More from our team

Working on a programme that has reached month-eighteen?

An external view from a partner with no stake in the implementation. Two-week diagnostic, fixed price.