90% of ERP Failures in Kenyan SMEs Come From the Wrong Implementation Partner
ERP failures in Kenyan SMEs rarely begin during implementation. Faced with widely varying proposals, organisations often default to the lowest cost option without understanding what has been excluded.
The result is a predictable cycle of change orders, delayed timelines, and escalating budgets driven by unscoped data issues, unclear requirements, and missing post-go-live support.
Low-cost Kenyan ERP proposals hide full implementation cost
The economics of ERP underbidding are not complicated, but they are rarely explained to the organisations being underbid to. Implementation partners win contracts through low initial proposals and recover their margin through change orders. Every requirement that was described as standard in the original proposal becomes billable the moment it turns out to be non-standard in practice.
The mechanism works like this. A partner submits a KSh 3.1 million proposal knowing that the actual cost of a competent implementation for an organisation of that complexity is closer to KSh 6 million. They win the contract on price. They begin implementation. Within eight weeks, the data migration that was described as included surfaces a data quality problem that no one scoped — six years of inventory records in three different formats, supplier codes that do not match across systems, accounts that were never reconciled after a previous software migration. That data quality problem is now a KSh 800,000 custom development project that was not in the original proposal. The training that was described as included becomes a separate engagement when it becomes clear that the warehouse team needs three weeks of structured workshops, not three days of system walkthroughs. The integration with the organisation’s M-Pesa Business Pay bulk payment workflow — mentioned in the discovery meeting but not written into the scope document — is now a change order.
Each individual change order is defensible. Collectively, they represent the margin the partner knew they needed when they submitted the proposal. The organisation that selected Proposal C is not the victim of bad faith in every case. They are sometimes the victim of a bidding culture that has made scope ambiguity the primary competitive weapon in the Kenyan ERP market.
The organisations that select the realistic proposal — Proposal B, the one that budgeted for discovery, data migration complexity, and post-go-live support — consistently pay less in total than those that selected the lowest number. The realistic proposal is more expensive at signing precisely because it includes the costs that the cheap proposal deferred to change orders. There is no version of a competent ERP implementation that costs KSh 3.1 million for an organisation of meaningful operational complexity. The only question is whether the remaining cost is paid upfront, honestly, or later, under duress.
Ten Questions That Separate Credible ERP Partners From Dangerous Ones
The evaluation framework that most Kenyan organisations use for ERP partner selection is a proposal review followed by a presentation. This framework is designed to select the most persuasive vendor, not the most competent one. The following questions are designed to do the opposite — to surface the evidence that determines whether a partner can actually deliver what they are proposing.
First: How many Kenyan organisations have you taken live on this ERP in the last 24 months? The minimum acceptable answer is three. Request direct client contact details — not reference letters, which are self-selected — and call them. Ask specifically whether the implementation went live on the contracted date and whether the final cost matched the proposal.
Second: What was the go-live date in your last three implementations versus the contracted date? A credible partner will answer this honestly, explain the variance, and describe what they learned from it. A partner who claims every implementation went live on time is either working with very simple implementations or not telling the truth.
Third: What percentage of your implementations have required change orders? The honest answer from a credible partner is not zero. Change orders happen. The question reveals whether the partner manages scope proactively or uses ambiguity as a revenue mechanism.
Fourth: What does your data migration methodology look like, and how do you handle data quality problems discovered during migration? This question separates partners who have actually done data migration from those who have described it in a proposal. A credible answer includes a specific process for data profiling, a protocol for escalating quality problems, and a clear statement of what is included versus what triggers additional cost.
Fifth: Who specifically will work on our project? The person who presented the proposal is frequently not the person who will implement the system. Ask for the CVs of the specific consultants who will be assigned. Ask whether they will be dedicated to your project or working across multiple implementations simultaneously.
Sixth: What post-go-live support is included, and at what hourly rate for out-of-scope support? This must be in the contract. Organisations that negotiate post-go-live support after go-live, when they are operationally dependent on the vendor, will pay rates they did not price.
Seventh: Can you show us your standard project plan template? A partner who has delivered multiple implementations has a project plan template refined through experience. A partner who has to create one for your proposal has not.
Eighth: Have you implemented this ERP for a business in our industry? Industry-specific configuration — landed cost calculations for importers, batch tracking for food manufacturers, multi-county payroll for organisations operating across Kenya’s devolved structure — requires prior exposure. General ERP experience is not a substitute.
Ninth: What is your policy when a client’s timeline is unrealistic? This question reveals whether the partner has the professional integrity to push back on a client’s expectations, or whether they will agree to any timeline to win the contract and manage the consequences later.
Tenth: What would cause you to recommend not proceeding with the implementation? A partner who cannot answer this question honestly — who cannot describe the organisational conditions under which they would advise a client to delay — is a partner who will proceed regardless of readiness. That partner is not aligned with your outcome. They are aligned with their invoice.
The Discovery Phase Most Kenyan ERP Projects Skip — and Why Skipping It Doubles the Cost
The most reliable predictor of whether an ERP implementation will succeed or fail is not the software selected, the budget approved, or the executive sponsor assigned. It is whether the project began with a structured discovery phase.
A discovery phase — two to four weeks of systematic analysis of current processes, data quality, and organisational readiness, completed before implementation work begins — is included in most credible ERP proposals and excluded from most budget proposals. Its absence is one of the clearest signals that a proposal has been constructed to win on price rather than to deliver on outcome.
The discovery phase serves three specific functions that cannot be performed after implementation has begun without incurring significantly higher cost. First, it reveals data quality problems before migration begins. An organisation that has been running on a legacy system for seven years has seven years of data inconsistencies, duplicates, unmapped fields, and reconciliation gaps accumulated in that system. Discovering those problems during a discovery phase allows them to be scoped, priced, and addressed on a managed timeline. Discovering them during migration — which is the alternative — means discovering them at the moment of maximum cost and minimum flexibility.
Second, the discovery phase identifies the process changes required for the ERP to work as intended. An ERP system does not simply automate existing processes. It imposes a process logic that may differ substantially from how the organisation currently operates. The organisation’s procurement process, approval workflows, and inventory management practices may need to change before the ERP can function correctly. A discovery phase identifies those gaps before the system is configured around the wrong processes.
Third, and most consequentially, the discovery phase produces a project plan based on the actual complexity of the specific organisation — not the assumed complexity at bid time. The proposal that promises a four-month implementation has been written based on assumptions. The project plan produced by a discovery phase is based on evidence. Organisations that skip the discovery phase are, without exception, signing a contract based on assumptions. They are approving a budget for an implementation that has not yet been defined. They are, in the most precise sense, signing a blank cheque.
Post-go-live support: the hidden cost of ERP failure
Go-live is not the end of an ERP project. It is the point at which the organisation discovers everything the implementation did not achieve — the reports that were not configured, the integrations that were scoped but not built, the user adoption that was assumed but did not materialise, the edge cases in the organisation’s operations that the standard configuration does not handle. Every ERP implementation has a post-go-live phase. The organisations that manage it successfully are those that negotiated its terms before they signed the implementation contract. Those that did not are negotiating from a position of operational dependency, which is the weakest possible negotiating position.
The post-go-live support structure must specify: who is responsible for system issues versus user errors, what the response SLA is for critical failures, what constitutes an in-scope support request versus a billable change request, and what the hourly rate for out-of-scope work is. An organisation that goes live on an ERP system without a post-go-live support contract in place has handed operational continuity to a vendor with no contractual obligation to respond at a defined speed or a defined cost.
The uncomfortable arithmetic here is that the organisations most likely to find themselves in this position are those that selected on price. The partner who won on a KSh 3.1 million proposal does not have the margin to provide twelve months of post-go-live support without charging for it. The partner who proposed KSh 7.8 million built that support into the price. The post-go-live period is where the true cost of the cheap proposal becomes fully visible.
ERP failures reflect selection proces
Jansen Tech conducts ERP partner evaluation and implementation oversight for Kenyan organisations that have learned — through their own experience or through this analysis — that the selection decision is the most consequential decision in the project. The work involves structured reference verification against the ten questions above, discovery phase design and facilitation, and contract review to ensure that post-go-live obligations are specified before signing. It is the kind of work that does not appear in a proposal comparison spreadsheet but determines whether the comparison spreadsheet leads to the right decision.
The ERP market in Kenya has enough credible implementation partners to give every organisation a genuine choice. The problem is not scarcity of competent partners. It is that organisations are selecting implementation partners using the wrong criteria — price — and the wrong process — proposal evaluation without reference checks, discovery phase validation, or post-go-live contract review.
The due diligence process described above requires approximately three additional weeks before contract signature. It is not a complex process. It requires asking specific questions, verifying specific claims, and reading specific contract clauses carefully. Organisations that do this work consistently arrive at better selections, negotiate better contracts, and complete implementations closer to the originally proposed budget.
The organisations that do not do this work will continue to generate the statistic they are already generating: 90% failure rates, implementation costs that exceed proposals by 60 to 80%, and go-live dates that migrate across calendar years. The technology is not the problem. The selection methodology is. And unlike the technology, the selection methodology can be fixed before the contract is signed.
