The technology is rarely the hard part. After a decade of leading digital transformation programmes — at banks, government agencies, manufacturers, and retailers across Nigeria — the single most consistent finding is this: transformation programmes fail in the people layer, not the technology layer.

A core banking system migration that takes 18 months to complete technically can take 36 months because of organisational resistance. An ERP implementation with a technically sound design can deliver negative ROI because end users find workarounds rather than adopt the new system. A cloud migration that completes on schedule fails to generate savings because nobody changed the procurement processes that were the real source of waste.

This is the CIO's playbook for getting it right — drawn from our most successful and most painful engagements.

Chapter 1: The Mandate Must Come From the Top

Digital transformation cannot be a technology department initiative. It must be a board-mandated, CEO-sponsored programme with explicit executive accountability. If the CIO is the only executive sponsor, the programme is already in trouble.

In practice, this means the transformation vision must appear in the CEO's annual message, the board must receive quarterly progress briefings, and the CFO must have approved a multi-year investment case — not just a one-year project budget. Without this foundation, every major decision becomes a negotiation against competing departmental priorities.

Chapter 2: Map the Organisation Before You Map the Technology

Before designing any system, we conduct a 30-day organisational readiness assessment. This covers:

  • Power mapping: Who are the informal decision-makers and gatekeepers? In Nigerian organisations, this is often not reflected in the org chart
  • Resistance identification: Which leaders feel threatened by the change? What are their specific concerns?
  • Champion identification: Who are the early adopters who will become internal advocates?
  • Process archaeology: What are the actual (not documented) workflows? Shadow processes are the most dangerous because they are the ones that will break if you digitise only the official process

Chapter 3: Small Wins First — Always

The instinct of most technology teams is to tackle the biggest, most complex problem first. This is almost always wrong. The first phase of transformation must generate visible, concrete improvements for frontline staff within 90 days — not 18 months.

A classic example: a retail bank we worked with had a digital transformation roadmap that started with core banking replacement. We convinced them to start instead with digitising the loan approval workflow — a 45-day project that reduced approval time from 11 days to same-day for standard applications. Within three months, that programme had more internal advocates than any initiative in the bank's history. The core banking project that followed had an entirely different cultural environment to land in.

Chapter 4: Training Is Not a Phase — It's a Programme

Most project plans allocate 5% of the budget and 2 weeks at the end of the timeline to "training." This is not training. It is a ritual that satisfies a project milestone while virtually guaranteeing poor adoption.

Effective digital adoption requires:

  • Role-specific training designed for how each group actually uses the system — not a generic "features tour"
  • Embedded "superusers" in each department who receive deeper training and become the first line of support
  • A hypercare period of at least 60 days post-go-live with dedicated support staffing
  • Continuous learning nudges — short videos, quick-reference cards, in-app guidance — delivered over months, not days

Chapter 5: Measure What Matters, Not What's Easy

A digital transformation programme's success metrics should not be "went live on schedule" or "delivered on budget." Those are delivery metrics. Outcome metrics are what matter:

  • Process cycle time reduction (e.g., account opening from 3 days to 4 hours)
  • Staff time freed from manual tasks (measurable in FTE hours per week)
  • Customer satisfaction scores (NPS, CSAT) specific to the digitised touchpoints
  • Error and exception rates in automated processes versus manual baselines

Instrument these metrics before go-live, not after. You need a baseline to prove the transformation worked.

The Uncomfortable Truth

Some people will not make the transition. A 20-year employee whose entire value was managing a manual process that has just been automated is not going to become a data analyst overnight. The most ethical and practical approach is to identify this reality early — during the organisational readiness assessment — and work with HR to plan for it honestly. Redeployment, early retirement, or restructuring are difficult conversations, but having them at the start of a programme is vastly better than having them after a failed go-live.

Digital transformation done well is one of the most powerful things an organisation can do for its long-term competitiveness. Done poorly, it is an expensive reminder that technology is only as good as the organisation that deploys it.