Ethiopia has seen a significant increase in digital investment across government and development programs. Workflow platforms, service delivery applications, and data systems have been introduced across multiple sectors. The results have been uneven. Some systems are widely adopted and have measurably improved service delivery. Many others sit unused or underused, their failure attributed to connectivity, literacy, or budget constraints. The evidence suggests that the primary driver of failure is not technical. It is a mismatch between how systems are designed and how institutions actually function.
The Technology Bias in Digital Development
Digital projects in development contexts often start from technology platforms rather than from institutional processes. A donor or government agency identifies a platform that has worked elsewhere, proposes to adapt it for the local context, and begins configuration. The assumption is that the platform is the solution and the institution will adjust to accommodate it.
The result is systems that are technically functional but institutionally incompatible. The workflows embedded in the system do not match the workflows that actually govern how decisions are made and work is assigned. Staff who were not involved in the design do not understand why the system is structured the way it is. Supervisors who were not consulted during design find that the system does not give them the information they need to do their jobs.
The contrast with process-first design is direct. Process-first design begins by mapping how work actually happens: who does what, in what sequence, on what authority, with what inputs and outputs. The system is then designed to support that process, or to support a reformed version of it that the institution has already agreed to adopt. The technology follows the process, not the other way around.
What Process-First Design Looks Like
Process-first design starts with observation and documentation, not with software. It requires spending time with the staff who will use the system, watching how they work, asking what slows them down, and understanding what information they need at each step. This takes time. It is also the step most frequently skipped when project timelines are under pressure.
The design phase should involve the staff who will use the system in meaningful decisions, not just as validation subjects for choices already made. When users have shaped the system, adoption follows more readily because they recognize their own work in the interface. When they have been presented with a completed system and told to use it, they frequently find workarounds that preserve the informal processes they trust.
There is also an important distinction between digitizing a process and redesigning it. Digitizing an inefficient process produces a faster version of the same problem. A process-first approach creates an opportunity to ask whether the process itself is sound before automating it. That question requires political engagement with the institution, not just technical engagement with the system.
"A system that works on paper but not in practice has not solved the problem. It has added a layer to it."
The Adoption Problem
Adoption is the actual measure of success for a digital system, not deployment. A system that has been configured, installed, and launched but is not regularly used by the people it was designed for has not succeeded. It has consumed resources and created a maintenance obligation without delivering the intended benefit.
Adoption is driven by usability, fit with existing workflows, visible benefit to the user (not just to the supervisor or the reporting system), and training that matches actual use patterns. Systems that require users to do more work for the same output will not be adopted. Systems that make users' jobs easier will. This is obvious in principle. It is routinely ignored in practice because the metrics that matter to project managers are deployment metrics, not adoption metrics.
The visible benefit problem deserves particular attention. Many government digital systems are designed to improve reporting, monitoring, or supervisory oversight. The benefit accrues to the supervisor, the ministry, or the donor. The frontline staff member who is required to enter data sees no personal benefit and carries additional work. Designing systems that also benefit the person doing the data entry, by giving them useful feedback, simplifying their own workflow, or reducing paperwork elsewhere, changes the adoption calculus significantly.
Building for the Long Term
Digital systems need ongoing maintenance, updates, and institutional ownership. This is not a controversial statement, but it describes a requirement that development projects routinely fail to meet. Projects that treat deployment as the endpoint create systems that degrade. Software needs updates. Servers need maintenance. Staff turn over and institutional knowledge is lost. Within two to three years of a project's closure, systems without active institutional ownership frequently become inoperable.
Institutional ownership means more than having a named owner on an organogram. It means that a specific unit has budget authority over the system, technical capacity to maintain it, and organizational incentive to keep it running. Building that capacity alongside the system, rather than assuming it will emerge after deployment, is the difference between a system that lasts and one that doesn't.
Digital transformation, ultimately, is an organizational change process that happens to involve technology. The technology is not the hard part. The hard part is changing how people work, how decisions are made, and how institutional accountability is structured. Projects that understand this from the start build accordingly. Projects that treat it as a secondary consideration tend to produce technically sound systems that no one uses.