Why ERP Implementations Fail in Kenya
Six ways a rollout dies, ranked by how often we see them, and all six are organisational rather than technical. The ones that kill a project are not the ones people worry about — nobody has ever abandoned a system because the reports were ugly.
Failed implementations do not announce themselves. There is no meeting where a Kenyan business decides to stop using the system it paid for. What happens instead is that a parallel record survives a little too long, the storekeeper starts entering yesterday's movements tomorrow, and then one month nobody runs the report — and by the time anyone notices, going back would mean admitting the last eight months were wasted, so nobody does.
The causes are boringly consistent. Here they are in the order we actually encounter them, with the earliest warning sign for each, because all six are cheap to fix in week two and expensive in month five.
One: nobody owns it
The most common cause by a wide margin. The MD sponsored it, IT installed it, the vendor configured it, and the person who has to decide whether a storekeeper may write off damage on their own authority does not exist. So that question, and forty others like it, gets answered differently each time by whoever is nearest.
Ownership is not sponsorship. The owner is whoever will be personally embarrassed if the stock figures are wrong — usually the operations or finance manager. They need decision authority and about two half-days a week for six weeks, taken off something else in writing. A rollout with a steering committee and no owner has a body that meets and nobody who decides.
If
nobody can name the owner in one sentence
Stop. This is not a delay, it is the work. Pick a person, tell them, tell everyone else, and write down what they are allowed to decide alone.
If
the named owner has no time freed up
They are not the owner, they are the blame-holder. Take something off their plate visibly, so the organisation can see the trade-off was made deliberately.
If
the owner is the IT person
Reconsider. IT can make the system work; they cannot decide whether a short delivery gets received. The owner has to be someone who lives with the consequences of the answer.
Two: the old system never stopped
Parallel running is correct — for one module, for about four weeks, with a stop date announced in advance. What kills projects is parallel running with no end date. Staff are not being obstructive when they keep the book; they are managing risk sensibly, because the book has never let them down and the new thing might. But two records means one is redundant, and the redundant one is always the one with more friction.
The warning sign is specific and easy to spot: ask when the last handwritten entry was made. If the answer is "this morning" and you went live in April, you do not have an adoption problem in the future tense.
Nobody chooses the harder system. If the old process is still available, the new one has to be easier — not better, easier — or it loses.
Three: the opening data was garbage and everyone knew
Stock figures copied from a spreadsheet rather than counted. An item list with the same product on it three times. Suppliers who left in 2022. The system then reports faithfully on all of it, staff see figures they know to be wrong, and within a fortnight they have learned that the system is not to be trusted. That lesson, once learned, does not unlearn — you can fix the data in month three and the reputation takes a year.
This one is entirely preventable and it costs one Saturday and about eight hours of list cleaning. Data migration and the opening stock count are the two pieces of homework, and both are duller than anything else in the project, which is exactly why they get dropped.
Four: everything was switched on at once
Inventory, procurement, sales, POS, HR and accounting, in one go, because the licence covers it and it seemed wasteful not to. Now every problem in the first month has six possible causes, every member of staff has a new way of working, and the two modules that would have delivered value on their own are buried under four that nobody had time to configure properly.
The counter-argument is real: phasing means running two ways of working for longer. That is a genuine cost, and it is smaller than the cost of a first month in which nothing works and everyone concludes the system is the problem. Phased versus big-bang works through where the line actually sits.
Five: permissions were designed after go-live
Everyone gets admin so nothing blocks the rollout, and the intention is to tighten it later. Later never has a date. Six months on, the audit trail records that seventeen people could have done it, approval means nothing because approvers can approve their own requests, and the first person to tighten anything becomes the villain who broke someone's workflow.
Designing roles takes about two hours before go-live and is politically free, because nobody has a habit to defend yet. The same conversation in month six costs a week and makes enemies. Designing roles before go-live is the two-hour version.
Six: training was a day, and it was in week one
A full-day session, three weeks before anyone has a real reason to use the thing, delivered to everybody at once regardless of what they will actually touch. Retention from that is close to zero, which everybody knows and nobody says, because the session is what the plan called for and it happened.
What works is short, role-specific and repeated at the moment of need — the storekeeper learns receiving on the day the first delivery comes in. Training and adoption goes into the shape of it.
Score your own rollout, honestly
Six checks, worth doing at week two and again at week eight
Any two failures and the project is drifting. Three and it is in trouble, whatever the status report says.
One named owner, with time visibly freed up
Make them prove it: Ask three staff who owns the system. If you get three answers, it is nobody.
A stated date the old process stops
Make them prove it: Ask when the last handwritten entry was made. Not whether — when.
Opening stock was counted, not copied
Make them prove it: Ask to see the count sheets. If they do not exist, it was copied.
One or two modules live, not six
Make them prove it: Count the modules staff are being asked to change their day for.
Roles designed before anyone got a login
Make them prove it: Count the administrators. More than three in an SME is a design that never happened.
Training in short role-specific bursts, ongoing
Make them prove it: Ask when the most recent training was. If the answer is "at go-live", it has stopped.
What is not on the list
Missing features. In nine years around this problem, a missing feature has never been the reason a rollout collapsed. Missing features cause negotiation, workarounds, occasionally a build, and sometimes a switch of vendor — all of which are survivable and normal. Every collapse we have seen came from the six causes above.
This matters for how you spend your evaluation time. The feature comparison is the enjoyable part of buying software and the least predictive. The predictive questions are duller: who will own this, when does the old process stop, who is cleaning the item list, and what are we switching on first. A vendor who cannot discuss those in detail is selling you a demo.
Also not on the list: cost
Businesses do abandon systems over cost, but that is a different failure — a decision made deliberately, usually correctly, and usually because the value never arrived. The value not arriving is one of the six causes above. Cost is how it gets discussed afterwards.
Our take
Every one of the six is cheap in week two and expensive in month five, and none of them is a software problem. If you fix only two, fix ownership and the stop date — they are the two that reliably kill projects on their own, and both are decided in a meeting rather than bought.
Run the six checks before you sign
We would rather have the awkward conversation about who owns it and when the old book stops than sell a licence into a rollout that is already drifting. Bring us the honest answers and we will tell you what we would not attempt yet.
See plans & pricingFrequently asked questions
What is the single most common reason ERP rollouts fail?
No named internal owner. Sponsorship is not ownership: the owner is whoever will be personally embarrassed if the numbers are wrong, usually the operations or finance manager, and they need decision authority plus about two half-days a week for six weeks taken off something else. A project with a steering committee and no owner has a body that meets and nobody who decides.
How long should we run the old system in parallel?
About four weeks, for one module, with a stop date announced in advance. Parallel running finds differences while they are small. It becomes fatal when it has no end date, because two records means one is redundant and the redundant one is always whichever has more friction — which early on is the new system.
Is it really a problem to switch on all the modules at once?
Usually yes. Every problem in month one then has six possible causes, every member of staff has a new way of working simultaneously, and the two modules that would have paid for themselves are buried under four nobody configured properly. Phasing does mean running two ways of working for longer, which is a genuine cost — just a smaller one.
Why does permission design have to happen before go-live?
Because it is politically free before anyone has a habit to defend, and expensive afterwards. Give everyone admin at go-live and six months later the audit trail says seventeen people could have done it, approval means nothing because approvers can approve their own requests, and whoever tightens it first becomes the person who broke someone's workflow.
Do missing features cause rollouts to fail?
Very rarely. Missing features cause negotiation, workarounds, occasionally a custom build, sometimes a change of vendor — all survivable. The collapses come from ownership, an old process that never stopped, bad opening data, too many modules at once, permissions designed late, and one-off training. Which is why the enjoyable part of evaluation, the feature comparison, is also the least predictive part.
How do we tell early that a rollout is drifting?
Ask three staff who owns the system and see whether you get one answer. Ask when the last handwritten entry was made. Ask to see the opening count sheets. Ask how many administrators there are. Those four questions at week two and again at week eight will tell you more than any status report, because each one has a factual answer that cannot be reframed.
