The real constraint is not technology
Discussions about digital transformation in Africa often begin with infrastructure, devices and connectivity. These matter, but they describe only part of the problem. Across schools, associations, public institutions and small businesses, a more persistent constraint is the distance between a technology becoming available and people being equipped to use it productively.
That distance has three dimensions: a skills gap, an access gap and an adoption gap. Each has different causes and requires a different response. Treating them as a single problem is one reason many digital programmes produce impressive launches and modest results.
This article sets out what each gap looks like in practice, why the three reinforce one another, and how institutions, funders and training providers can respond in a way that produces lasting change rather than a successful launch. It is written for leaders and practitioners who need practical direction rather than a technical specification.
Why the three gaps compound one another
It is tempting to address the most visible gap and assume the others will follow. In reality the gaps interact. People who have been trained but have no reliable access cannot practise, and skills that are not practised fade. Connectivity and devices without training are underused, because staff do not know what the tools can do or fear making costly mistakes. Systems that are well built but do not fit how people work are abandoned, and each abandoned system makes staff more sceptical of the next one.
This is why a programme that tackles only one gap often disappoints. A training course delivered to people who lack devices produces enthusiasm that cannot be used. A laptop donation without training produces equipment that is used for little. A new software platform introduced without either produces a login that nobody opens after the first month. The three gaps need to be addressed in the same plan, even if they are not addressed all at once.
| Gap | What it looks like | Common cause | First practical response |
|---|---|---|---|
| Skills | A few confident users, and a majority who avoid the tools | Training is occasional, generic and disconnected from daily tasks | Short, repeated, role-specific sessions that produce a real work product |
| Access | Trained people cannot practise; some groups are never reached | Courses assume new devices, fast connections or prior technical experience | Design around the devices and connectivity participants actually have |
| Adoption | Systems are bought or built, then quietly abandoned | Technology was chosen before the problem was understood and never fitted to the workflow | Start with the bottleneck and choose the simplest system that removes it |
The skills gap
New tools, from AI assistants to cloud-based software, are released at a pace that formal training cannot match. Professionals who could benefit most are frequently left to learn alone, through trial and error, or not at all. The result is uneven capability within the same institution: a few confident users, and a majority who avoid the tools altogether.
- Training must be continuous and role-specific, not a one-off workshop.
- Content should be taught in plain language and tied to tasks participants already perform.
- Learning should result in a work product, such as a cleaned dataset, a draft policy brief or a working form, rather than a certificate alone.
Why one-off training rarely changes practice
A single workshop can inspire, but it rarely changes how people work. Skills are retained when they are applied soon after learning and applied again in the weeks that follow. When participants return to their desks and nothing prompts them to use what they learned, the habit never forms. The pattern is familiar to many trainers: a well-attended session, positive feedback forms, and little visible change three months later.
What continuous, role-specific training looks like
Role-specific training starts from the tasks a person actually performs. A finance officer, a school administrator and a programme officer may all need to work with spreadsheets, but they need different things from them. The finance officer needs reliable formulas and reconciliations, the administrator needs clean records and simple reports, and the programme officer needs to track activities against a plan. Teaching all three the same generic course wastes time for each of them. A practical sequence often includes:
- a short orientation that explains what the tool can and cannot do;
- a hands-on session in which participants work on their own material;
- a follow-up session two to four weeks later to resolve problems and introduce the next skill; and
- a simple check of what has changed in the way work is done.
The access gap
Hands-on training remains difficult to find, and where it exists it often assumes a new laptop, a fast connection or prior technical experience. These assumptions quietly exclude the very groups that digital inclusion efforts aim to reach, including young people outside major cities, educators in under-resourced schools and micro-enterprises.
- Design learning around the devices and connectivity participants actually have.
- Favour offline-capable and low-bandwidth methods where possible.
- Do not treat a computing degree as an entry requirement for any practical course.
Access has several layers
Access is more than owning a device. Hands-on learning depends on a combination of conditions, and the absence of any one of them can shut a learner out.
- Devices. A shared phone, an older laptop or a device that belongs to an employer may be the only option, and each has limits on what can be installed or saved.
- Connectivity and data cost. Even where a signal exists, the cost of data shapes how long people can stay online and what they are willing to download.
- Place and power. Reliable electricity, a quiet place to practise and time away from other duties are often taken for granted by course designers.
- Language and confidence. Training delivered in jargon, or in a way that makes beginners feel exposed, loses the people who most need it.
Designing learning around real constraints
Training providers can reduce these barriers without lowering standards. Materials can be provided in printable or downloadable form so that participants can study offline. Exercises can use free or lightweight tools that run on modest hardware. Sessions can be scheduled around working hours and shared devices, and group work can allow one connected device to serve several learners. Most importantly, the course should state its real prerequisites honestly, so that nobody is deterred by assumptions that are never actually needed.
The test is simple: could a motivated person with a mid-range phone and an intermittent connection complete this activity? If the answer is no, the activity should be redesigned or an alternative offered.
The adoption gap
Many organisations know how they want to operate but lack the systems to match. Software is purchased but never configured properly, or deployed without testing, and is quietly abandoned. Adoption fails not because the technology is poor, but because it was never fitted to the workflow, the staff or the context.
The remedy is to begin with the problem rather than the product. A simple system that fixes the actual bottleneck will outperform a sophisticated one that no one trusts.
Why systems are abandoned
Abandoned systems tend to share a handful of causes. Recognising them early allows leaders to intervene before money and goodwill are lost.
- The system was chosen before the problem was clearly defined, so it solves something nobody was struggling with.
- It was set up generically and never configured for the way the organisation names, counts and approves things.
- It was launched without testing with the people who would use it every day.
- Nobody was made responsible for it after launch, so small faults accumulated and trust fell.
- Staff were never trained beyond a single demonstration.
Start with the problem, not the product
Before approving any technology purchase or build, it helps to ask a short sequence of questions. What specific task or decision is currently slow, costly or unreliable? Who performs it today, and how? What would a better outcome look like, and how would we notice? What is the smallest change that would deliver it? Only then should products be compared. A modest tool that removes the actual bottleneck will almost always outperform an impressive one that does not.
Who needs to act
Closing the three gaps is not the job of any single actor. Each has a distinct part to play, and the effort works best when the parts are coordinated.
| Who | What they can do |
|---|---|
| Institutional leaders | Define the problems worth solving, protect staff time for learning, and name an owner for every system introduced. |
| Funders and development partners | Fund follow-up and support rather than launch events alone, and ask for evidence of changed practice instead of attendance counts. |
| Training providers | Teach role-specific, practical content on the devices participants have, and aim for work products rather than certificates alone. |
| Technology service providers | Scope honestly, build the simplest effective system, test with real users and leave staff able to run what has been built. |
| Individual professionals | Practise regularly on real tasks, share what they learn with colleagues and report what does not work. |
Measuring progress beyond launches
A launch is an event; transformation is a change in how work is done. Programmes that report only the number of people trained, devices distributed or systems deployed describe activity, not results. A more useful picture combines a few indicators for each gap.
| Gap | Useful indicators |
|---|---|
| Skills | Share of trained staff who apply a new skill after an agreed interval; quality of the work products produced; confidence reported by participants. |
| Access | Share of participants who can practise between sessions; completion rates among groups previously excluded; share of activities that work offline or on low bandwidth. |
| Adoption | Share of target tasks completed in the new system; time taken for a routine report before and after; number of staff who can use and explain the system independently. |
These measures need not be elaborate. What matters is that they are agreed at the start, collected consistently and reviewed honestly, including when the results are disappointing.
A ninety-day starting plan
Institutions that want to begin without waiting for a large programme can follow a modest sequence.
- Weeks 1 to 2: Diagnose. Identify two or three tasks that are slow, costly or error-prone. Ask staff where they lose time and which tools they avoid.
- Weeks 3 to 4: Choose one problem. Select the problem where a small improvement would be most visible, and define how success will be recognised.
- Weeks 5 to 8: Train and build together. Run short, role-specific sessions on real material while setting up the simplest tool that addresses the problem.
- Weeks 9 to 12: Use, review and adjust. Use the new approach in daily work, hold a short review, record what changed and decide what to extend.
What a practical agenda looks like
A practical agenda joins the three responses together. Training builds the capability to use tools; accessible design ensures that capability can be applied in real conditions; and well-scoped technology services give institutions systems they will genuinely use. Delivered separately, each is weaker. Delivered together, they reinforce one another.
