Digital transformation in NGOs begins the way expensive mistakes begin: a polished presentation, a room full of well-intentioned people, and a shared belief that this time the system will make the work easier.
The platform goes live on Monday. By Friday, the field team has rebuilt the spreadsheet.
Not because they are resistant. Not because they fear technology. Because the spreadsheet, for all its limits, still understands their reality better than the platform does.
That gap is where most digital transformation fails.
It fails earlier, in the thinking that defines the problem, chooses the tool, and assumes the work can be simplified without first understanding how it is actually done.
NGOs rarely lack ambition when it comes to digitalisation. They invest in ERP systems, automated workflows, dashboards, digital tools, and data systems wrapped in the language of efficiency, speed, optimisation, and control. Yet too often, the result is something else: more cost, more friction, more duplication, and one more layer of work for people already stretched thin.
When organisations try to correct that failure, they often reach for Capital C Cuts: another platform, another unit, another strategy, another rollout, another promise made to people who have already heard it.
This piece is about the opposite.
Small c cuts.
Not the dramatic moves that get presented as transformation, but the disciplined corrections and practical changes that remove friction, challenge assumptions, and make transformation work where it can sustain and scale: in the workflow, among end users, and in the work culture.
These small c cuts come from what I have seen work and fail in NGO digital transformation.
The Problem Was Never Properly Named
The board approved the investment. A steering committee formed. Then a reference group and a working group. The agenda looked disciplined. Vendor shortlist. Budget allocation. Risk register. Every box was ticked.
The problem was not on the agenda.
Not which broken process, if fixed, would return the most time to programmes.
Not which missing data, if resolved, would change a decision before the next crisis.
Not which approval layer, if removed, would let the right person make the call without three sign-offs.
Not which existing initiative needed to stop before this one could start.
Those questions were not asked. The vendor gave a good demo instead.
The slides were clean. The case studies looked familiar. The procurement committee approved it in one meeting. Nobody from the field was in the room.
Or more precisely, someone was: a country director on a weak connection who nodded because it was easier than explaining, again, that the system assumed stable internet, a dedicated data entry person, and a workflow that had not existed in that context for three years.
The decision was made. The reality was not consulted.
It is like writing a prescription before seeing the patient. The medicine may be good. The diagnosis was never made. And when the patient gets worse, everyone points to the medicine.
This is how digital fragmentation happens. Governance of tools is easy. Governance of priorities forces leadership to choose.
Every request arrives dressed as urgency. Every gap becomes a system problem. Every system problem becomes a procurement decision. And the result is more systems, more logins, more reporting layers, and a mission that does not move faster because none of those systems were built around what was broken.
A foundational small c cut starts before any digital tool reaches procurement: require two things in writing from the people who will use it, not the people who will approve it.
Run a priority test. What is the single most painful problem this solves for the people closest to the work? What is the real cost if nothing changes? What existing initiative stops so this one can succeed?
Add a one-page problem statement. What task is failing? How often? What does that failure cost? What would fixed look like from the perspective of the person doing the work, in their actual context?
Then map the tool to that reality. If the mapping requires assumptions that do not exist in the field, procurement stops.
A tool that solves the wrong problem efficiently is a faster way to stay stuck.
Change Fatigue and Political Resistance
The all-staff email arrives. Another transformation. Another platform. Another promise that this time it will be easier.
The field team reads it. Closes it. Opens the spreadsheet.
This is not resistance. It is memory.
They have been here before. A new system arrives. Work increases before it improves. The old system never fully disappears. The burden lands on the same people it always does. Six months later, the new system joins the graveyard of tools that were going to change everything.
It is like getting a new alarm clock every year because you keep sleeping through the morning. The problem was never the clock.
That memory is rational. It is also one of the most expensive things an organisation can afford to ignore.
Then there is the other kind of resistance. Quieter. More organised.
The resistance of people who have something to lose when work becomes visible and accountability becomes traceable.
Some of what looks like resistance to technology is actually resistance to transparency, and that kind does not show up in a survey. It shows up in slow adoption, missing data, and decisions that somehow keep travelling through the old channels.
This is a workload problem, a trust problem, or a power problem wearing the clothes of a training problem.
A transformative small c cut begins before launch: ask three things. How much change have you already absorbed this year? What would need to stop for this to work? Where do you expect the friction to come from, and why?
Then map who loses something when this succeeds — control, discretion, visibility, the informal authority that lives in knowing things others do not. Map how workflows shift and which roles absorb the friction when the transformation lands. Trace the supply chains, the approval paths, the informal dependencies that never appear on an org chart but carry the work. Those are the places the rollout will slow, stall, or quietly reverse. Build adoption time into the plan as a line item and name the things that will stop so this can start.
And when the first signal of trouble appears — slow uptake, workarounds emerging, data quality dropping, the informal system reasserting itself — treat it as information, not insubordination.
That signal is not a failure. It is the field telling the truth earlier.
The earliest signal is the cheapest problem to fix. The ones that arrive six months later have already become something expensive to change.
You Automated the Wrong Process
The procurement process was slow.
Three weeks from request to approval.
A month to close the payment.
Programme teams were frustrated.
Finance was in conflict with procurement.
And procurement kept asking for a procurement plan that only existed as an annex to the proposal.
Something had to change.
Everyone agreed.
So it was automated. Digital forms. Automated routing. Approval notifications. Status tracking. Real-time visibility into where every request sat in the chain.
The process that once took three weeks of emails and chasing now takes three weeks of automated emails and automated chasing.
The bottleneck was never the form. It was the review and the approval chain nobody had the authority, or the courage, to redesign.
Automation preserved it perfectly. And because it now lived inside a system, it started to feel permanent. Harder to challenge than the old process that lived in inboxes and could have been changed quietly on any Tuesday afternoon.
It is like paving a dirt road that still leads to the wrong place. The ride feels smoother. You still end up where you should not be.
Automation captures what exists. It scales it. It standardises it. If what exists is broken, automation makes it easier to repeat the dysfunction. If what exists is unnecessarily complex, the system makes that complexity look intentional.
The most common error in automating processes inside NGOs is optimising things that should not exist.
A small c cut here starts with requirements. Before anything is mapped, modelled, or built, question what the process is for. Not what it has always done. What it should do.
Then delete before you design. Remove every step that exists only just-in-case, only by habit, or only because no one ever challenged it. The just-in-case logic is where broken processes hide. It sounds like caution. It functions like friction.
Then do mapping and apply one test to each step: does it add protection, add value, or add delay? If it only adds delay, remove it. If the protection is real but the method is slow, redesign it. If approval sits at the wrong level, move it before you automate it.
Then, and only then, automate what remains.
The Training Was Delivered. The Capability Did Not Stay.
The training happened. The slides were polished. The attendance sheet was full. The pre-post form came back positive.
Two weeks later, the field team was back on WhatsApp, asking each other how to do the same task the training had already covered.
This is one of the quietest failures in digital transformation, and one of the most expensive ones to repeat.
NGOs say capacity building when they mean system orientation.
They say digital literacy when they mean compliance.
People are shown the platform, but not how to use it under pressure, recover when it fails, or adapt it to the context they actually work in.
The training was designed around the system, not the task. It assumed stable connectivity, strong English, low staff turnover, and enough continuity for one session to become practice. In many field offices, none of those conditions exist.
One person becomes the informal expert. Everyone else learns just enough to get through the day. When that person leaves, the office loses its operational memory. And the next person starts from zero, asking the same WhatsApp questions, making the same mistakes, and costing the same hours nobody ever counted.
This is not a learning problem. It is a design problem.
If the system is built in English but the working language is Arabic, French, or Spanish, capability weakens immediately. If the tool works at headquarters but fails on the device used in the field, learning collapses on first use. If training covers the ideal workflow but not the offline workaround, the common errors, and the recovery steps, what was built is not capability. It is dependence dressed as training.
The small c cut here is investment in people: stop treating capacity building as a rollout activity and start designing it as operational infrastructure.
Train to real tasks, not platform features. Measure learning three weeks later, three months later, not at the end of the session. Build training in the working language of the users. Include failure states, low connectivity scenarios, device limitations, and the workflows people actually use under pressure.
And require every rollout to leave behind three things in each office. One local super user. One plain language troubleshooting guide. One repeatable way to train the next person after turnover happens, because it will.
Here is another small c cut: invest in the community of practice. The WhatsApp group that already exists is your fastest support channel. Name it. Resource it. Let it do what it is already doing, but deliberately.
And here is one more: those hundreds of pages of user manuals that nobody reads and nobody can find, put them in a chatbot. Make it available in every language your teams work in, in every location they work from. The knowledge already exists. The small c cut is just making it reachable.
And invest in local knowledge sharing. Not headquarters to country. Not region to country. Within the same country, peer to peer, office to office. Build the conditions for that knowledge to travel sideways, not just down.
The ERP Went Live. The Spreadsheet Came Back.
Six months of implementation. Three months of parallel running. Weeks of training. Days of kickoff. One go-live. Two weeks of hypercare. A sign-off meeting.
And then, quietly, in a shared drive somewhere, a new Excel file. Named something that suggests it is temporary. It is not temporary. It is the real system now.
The ERP is where data goes to satisfy the audit. The spreadsheet is where the work gets done.
This is not resistance to change. This is the organisation telling the truth.
The ERP was designed around a model of how the organisation works that does not match how the organisation actually works.
The approval workflow assumed two levels of sign off. The organisation uses four. The budget structure assumed cost centres mapped to programmes. They map to donors. The reporting cadence assumed monthly closes. The field reality is whenever connectivity allows.
Each mismatch was worked around, customised around, or silently ignored. By go-live, the system had been bent enough to pass testing and not enough to be genuinely useful.
The spreadsheet returned because it was built by the people doing the work, for the actual work, with no budget and no consultant and no eighteen month implementation plan. It solved the real problem. The ERP solved the problem described in a requirements document two years ago by people describing an organisation that had since changed its donor base, lost ten key staff, and opened two new country offices.
The organisation did not fail the ERP. The ERP failed the organisation.
A logical small c cut starts before implementation: start with mapping every workaround across finance and operations. Not the official process. The actual one. Every exception, every manual step, every export to Excel. Those workarounds are not user failure. They are requirements the processes never captured. Build them into the design before implementation, not after go-live.
The distance between the official process and the actual one is where implementation fails.
Make vendors compete on simplicity. Before any demo, give each shortlisted vendor the same three tasks from the perspective of frontliner in low connectivity location: submit a request, submit a report offline, recover from an error without IT support. Score each on completion time, steps, and whether the tool holds under realistic conditions.
Do a small c cut on customisation: every request needs one justification: is this specific to how we work, or resistance to changing how we work? Customisation costs more than the invoice. It makes upgrades harder, turns developers into single points of failure, and leaves the organisation on an older version because upgrading would break everything built on top. The default answer is no. The burden of proof sits with the request.
A small c cut on scope: the system is for finance and operations. The moment it also carries project management, donor reporting, and results tracking, it becomes too complex to own, too slow to use, and too fragile to trust. Let each tool do what it was built to do and consider if you want the ERP to cover programme management as well.
A small c cut on connectivity: if the ERP cannot queue transactions, sync on reconnection, and allow data entry without loss, it is not built for the field. Test offline behaviour before signing. An ERP that requires stable internet is not built for where the work happens.
The most important reframe: an ERP is not an IT system. It is an organisational system that runs on software. The decisions it encodes, who approves what, what triggers a payment, what counts as a complete record, are organisational decisions, not technical ones.
A small governance c cut is to build ERP governance that outlasts the implementation. Not a steering committee or a board meeting quarterly at headquarters, but a small group who understand process, can read a workflow, and have enough authority to decide without escalating everything. Give them a mandate, a meeting rhythm, and the ability to say no. The system will drift without them. With them, it has a chance of staying owned.
In most failed ERP projects, the system worked exactly as designed. The problem was that the design had little to do with how the organisation actually functioned.
The Field Team Collects. It Never Receives.
Somebody fills in the form. Somebody resubmits when the format is wrong. Somebody carries the device to a place with no signal. Somebody collects the data, enters the data, and gets asked about the data. Then asked again.
That somebody is almost always the field team.
And the field team almost never sees the output.
The data travels from community to tablet to server to dashboard to donor report. At no point does it return to the person who collected it in a form that helps the front liners understand anything better, or make a different decision tomorrow.
Digital systems in NGOs were designed for upward reporting. Data flows toward the people with the least contact with the field work and away from the people with the most.
The field team carries the collection burden for a system that serves someone else’s visibility. Because it does not serve them, they do not trust it. Because they do not trust it, the quality degrades.
This is extraction. Information taken from people who see no return from it. The sector has frameworks for community accountability. It has not yet applied them to its own data practices.
A small c cut starts with one question: what does the person collecting this data receive back from it? If the answer is nothing, redesign the output before mandating the input.
Every system should produce at least one output designed specifically for the field, something that makes the next visit, conversation, or decision more informed.
Data taken from people who see no return from it becomes data that cannot be trusted.
The Data Was Never Clean
The dashboard looks authoritative. The numbers update in real time. The visualisation is polished.
But three systems hold three versions of the same community record. The field team reported in one currency and the finance system converted at the wrong rate. Two country offices interpreted the same indicator differently for six months, and nobody caught it until the annual review.
The dashboard is presenting broken data beautifully. And because it looks authoritative, decisions are being made on it.
This is the data quality problem the sector avoids because it implicates everyone. The donor whose parallel reporting requirements created parallel data flows never designed to be compatible. The field team that filled in required fields with whatever kept the system from rejecting the submission.
Poor data does not become insight because the chart is beautiful. Automation scales it. AI amplifies it. A new platform migrates it.
The sector has invested heavily in making data visible. It has invested almost nothing in making data honest.
Here is the small c cut: before any new system is implemented, run an honesty audit on the single most important data set it will use. Not a technical audit. A human one. How was this data collected? By whom? Under what pressure? In which language? What happened when the real number did not match the expected one?
Map every point where the data could have been shaped between reality and system entry. Present the findings before implementation begins. If the foundation cannot hold the weight of what is being built on it, fix the foundation first.
A system built on unacknowledged data problems does not produce insight. It produces the appearance of it.
AI Is Already in the Building. Nobody Signed Off on It.
The field coordinator finished the situation report at eleven at night. One hour of generator left. One hour of connectivity. Six programmes to summarise in a format designed for a reader he would never meet. He opened ChatGPT, drafted the report in twenty minutes, cleaned it, and submitted it.
A country director wearing three hats after a funding cut — responding to headquarters, the region, the donor, the cluster — she opened Microsoft Copilot, drafted the emails, and sent them.
A grants manager and a head of programmes sat down to write their third proposal in a month. Claude was open on the screen. It finalised paragraphs. It drafted the annexes.
Nobody at headquarters knows. Nobody approved it. Nobody has a policy for it. And the report was better than the one from the month before.
This is where AI lives in most NGOs right now. Not in the strategy document. Not in the carefully governed pilot. In the field coordinator’s browser at eleven at night. In the country director summarising forty pages of partner reports before the next meeting. In the grants manager drafting annexes under time pressure in a context where English is her third language.
The people closest to the work have already decided. AI reduces friction. They are not waiting for permission.
Meanwhile, at headquarters, a different conversation is happening. Risk registers are being updated with AI liability clauses. Legal is drafting use policies. IT is blocking tools on the corporate network. A working group has been formed.
By the time the working group holds its first meeting, the field team is on its third AI tool.
This is not a technology gap. It is a governance gap dressed as caution.
The risks, hallucination, bias, data privacy, overreliance, are genuine. But the real exposure is not that AI is being used. It is that it is being used invisibly, unevenly, and without guidance, while leadership mistakes caution for control. The same coordinator drafting a situation report may also be summarising protection case notes or location data into a tool whose data residency and vendor jurisdiction nobody has reviewed. The friction she is solving is real. So is the exposure she is carrying alone. Governance that ignores either one is not governance. It is a policy document waiting for a crisis.
Most NGOs that have embraced AI have done so in fragments: a copilot here, a summarisation tool there, none connected to a workflow that matters, none attached to a decision that actually needed improving. That is not transformation. That is the same procurement mistake, only faster.
The small c cut is to govern what is already happening. Ask every team what AI tools they are currently using informally, and why. Map the real usage before writing the policy. Define three things in plain language: which uses are permitted now, which require review, and which are prohibited, and why, with data sensitivity and vendor jurisdiction as explicit criteria.
Then map where the work is genuinely slow, repetitive, or concentrated in too few people. Those are the places where generative AI can return real time to real work. Start there, not with the technology.
Find the people in your organisation who are already experimenting. Ask them what they are finding, including the failures. They are ahead of the policy. That is not a problem to manage. It is intelligence to use.
Engage vendors honestly. Ask hard questions about data residency, model training, and what happens to the information your teams input.
The goal is not to slow AI down. It is to make sure the people already using it have the guidance and protection they need to use it well.
AI is not arriving. It is already here. The question is whether the organisation will meet it.
Protect the Data Like You Protect the People
The data inside NGO systems is not ordinary operational data. It is displacement records, protection referrals, health histories, family cases, and the location of people in contexts where being found by the wrong actor is a matter of survival.
Most of it was collected with a promise. That it would be used to help the person it came from. That promise was made honestly. The system holding it was procured without asking what happens when the context changes. When a government falls. When a conflict actor gains access. When a vendor is acquired and the data moves with it.
In a commercial context, a breach is a reputational problem.
In a humanitarian context, it can be a protection crisis.
In an AI context, it is a prompt entered once, processed somewhere, stored by someone, and impossible to fully recall.
In a conflict context, it is a name, a location, a vulnerability that was never meant to leave the room.
That is not a legal distinction. It is the difference between a fine and a life.
A necessary small c cut is to slow down long enough to ask the questions that should have come first. Before any system holding sensitive data goes live, answer five questions: What is the worst realistic harm to the person described by this data if it is exposed? Who maintains the data controls? Where does the data go after collection, and who can access it beyond the programme team? What happens if the programme closes or the vendor stops supporting the product? Does that person know, in plain language, what their data will be used for and what rights they have?
If those questions cannot be answered before go-live, the system is not ready.
The people whose information fills these systems are not users or customers. They are people in acute vulnerability who trusted the organisation with information that could protect them or expose them.
That is not a data governance question. It is a moral one.
Support That Does Not Reach the Field
The ticket was submitted Monday.
The auto reply promised three to five business days.
The follow up went unanswered.
The escalation needed approval.
The person who usually fixes it was on leave.
For the field team, this can mean services delayed, data lost, or a decision made blind.
Eventually, the field team stops reporting the problem. Not because it is fixed. Because experience has taught them that reporting changes nothing. They absorb the failure quietly, build the workaround silently, carry the cost invisibly.
That silence is one of the most expensive data points in the system. It never appears on the dashboard.
What headquarters sees: low ticket volume, acceptable uptime, stable adoption rates.
What is actually happening: the field has stopped asking for help and started managing around the system entirely. That is not resilience. It is substitution.
A practical small c cut starts before deployment: before any system goes live in a field location, answer four questions. Who fixes it locally when it breaks? What is the escalation path if they cannot? What is the maximum acceptable downtime? What manual backup holds the work while the fix is underway?
If those answers do not exist before deployment, the system is not ready.
A second small c cut begins after go-live: measure one thing that never appears in IT reports, how often field teams fix a problem without logging a ticket. That number is not a sign of capability. It is a sign of abandonment.
A tool without support is not an asset. It is a liability the field team will carry quietly until they stop carrying it.
Digital Transformation Is Investment, Not Cost
Ask most NGO finance teams where digital transformation sits in the budget.
The answer is the same.
Overhead. Indirect cost. Something to defend and cut when funding gets tight.
That framing shapes everything. Digital roles stay junior. Systems stay underfunded. Maintenance contracts shrink. Training disappears. Critical infrastructure runs on the cheapest option available, supported by teams too small for contexts too complex to absorb failure when it comes.
Then the failure comes. A breach. A system outage during emergency response. An ERP that cannot handle scale-up. A payment system that collapses mid cycle.
Each failure has a cost. Not the technology cost. The recovery cost. Emergency support. Programme delays. Donor repair. Staff time pulled from work that needed doing.
Money cut from digital infrastructure does not disappear. It relocates into the crisis it was supposed to prevent.
There is a constraint that rarely appears in the digital strategy document: cybersecurity. Not as a policy annex. As a structural vulnerability the sector has systematically underfunded.
Digital infrastructure and cybersecurity sit in indirect costs, negotiated and reduced. Every new system is another surface. Every new integration is another exposure. A new risk.
Field teams entering data into multiple platforms and staff using personal devices because the organisation cannot provision them properly are not operational gaps. They are cybersecurity risks the funding model created.
Digital transformation cannot deliver security inside a system funded to produce exposure. That is not a technology problem. It is a structural one. Naming it is the first cut.
A strategic small c cut is to calculate what the last serious digital failure actually cost: system recovery, programme disruption, staff time diverted, partner and donor repair, and data risk exposure. Put that number next to the annual maintenance budget. Then take both to the next budget discussion.
Do the same for cybersecurity. What would a phishing attack cost? A single compromised account can expose community data, freeze operations, and trigger a donor notification process that takes months to close.
The gap between those numbers makes the argument on its own.
Digital infrastructure is not the price of modernity. It is the price of continuity. Fund it like you mean it.
Your Digital Lead Has No Seat at the Table
Investment approved. Budget allocated. A digital transformation lead hired for AI, ERP, automation, or whatever initiative made it into the strategy document. The mandate looked promising.
But the budget sat elsewhere. Process change needed approval from each function. Adoption depended on country directors and regional buy in. Legacy systems could only be retired through a governance group that met every couple of months.
The strategy appeared in leadership presentations and disappeared in daily operations. The digital lead wrote a good plan and a polished lessons learned report but nothing moved.
This is not a hiring problem. It is a governance problem handed to a person and called a role.
It is like appointing someone to fix the plumbing and giving them a notepad instead of a wrench.
Digital transformation is organisational change that happens to involve technology.
A leadership small c cut starts before hiring: answer three questions at leadership level. What exactly must change in the next two years that requires this role? What authority will this person have to mandate adoption across functions, not just influence it? What happens when a function refuses to implement an agreed change?
This role must work with the people who can mandate, not just recommend.
If those answers are weak, the organisation is not ready for the role.
The deeper small c cut is this: leadership cannot stop at the level of the individual, the team, or the organisation. It has to think at the level of the system. That means staying in the room when resistance appears. It means challenging what is broken instead of managing around it. It means naming what is not working and refusing to let bad habits hide behind process.
The digital lead needs to sit inside decision making, not alongside it. Not an advisory function others can take or leave. A voice with weight and the authority to use it.
A digital lead without authority is not leading transformation. They are recording its failure.
What Digital Transformation Was Always For
Digital transformation was meant to make work easier, not harder.
The community worker should finish a home visit, hit save, and immediately see something useful. The procurement officer should not be running an offline and online process at the same time, printing what the system should carry and chasing signatures that should be a click. The HR officer should be engaging with people, not managing a backlog of onboarding tickets and document requests because the process was never integrated. The finance officer should trace a variance in seconds, not days. The field team should spend less time feeding systems and more time with people.
That was the point.
Somewhere between that intention and the implementation plan, the technology became the point. The platform became the deliverable. The go-live became the measure of success. The dashboard became the proof of transformation.
Not all digital change belongs at the same level. Start with what helps one person work faster, with less friction. Build trust there. Build data discipline there. Build governance habits there. Then move to what reshapes a function. Then to what becomes embedded in the core processes the organisation cannot afford to lose control of. That sequence matters more than ambition.
Too many organisations want the language of transformation before the practice of readiness. Scale before trust. Big systems before small discipline. That is how digital transformation becomes another burden carried by the people it was supposed to help.
Small c cuts start with a different question, asked earlier, by different people, in a different room. Not what tool to procure, but what is actually broken, for whom, and how will we know it is fixed from the perspective of the person doing the work.
Ask that before procurement. During implementation. Six months after go-live.
Technology will only ever reflect the thinking behind it. And that thinking has to start with the people the mission was written for, before they became data points, before the field became a reporting unit, before the work became a dashboard.
First principles have not changed. Who we are accountable to. What problem we are fixing. What harm we refuse to cause. The digital part is detail.
The sector is not short of digital tools. It is not short of ambition. It is short of honest questions asked before buying them, and short of the investment that makes transformation innovative enough to matter, scalable enough to reach the field, and sustained enough to last.
Ali Al Mokdad
