Why Fixed-Price ERP Implementations Fail, and What to Sell Instead

A manufacturer wants ERPNext. Accounts, stock, manufacturing, payroll, "and just connect it to our current system". You scope it over two calls, quote a fixed KES 1.4 million, and win it because the alternative quoted 3.5 million plus licences.

Eleven months later you are still on it. You have burned twice the days you priced. Every conversation now includes the word "scope". The client thinks you are slow and dishonest. You think they are disorganised and dishonest. Both of you are partly right, and neither of you is the reason it failed.

My thesis: a fixed price is a bet that the requirements are knowable before you have touched the client's data. In an ERP implementation, they never are, because you are not building software. You are renegotiating how a business works, using software as the excuse.

What the industry data says

This is not a personal failing and it is not an African problem. Panorama Consulting's 2023 research found that 53 percent of ERP projects exceeded their original budget, with a median overrun of around 24 percent. Their post-mortem work also consistently points at internal, client-side causes as the dominant factor: poor requirements definition, weak change management and disengaged executives show up in nearly every failure review.

Panorama has also written about the unintended consequences of fixed-cost ERP contracts specifically: vendors manage their execution risk by building large buffers into the bid while simultaneously narrowing the scope they will accept, pushing the time-consuming activities onto the client. Then every gap becomes a change order.

So the fixed price does not remove risk. It relocates it, adds a margin for holding it, and converts the working relationship into a claims process.

Six mechanisms that actually break the price

1. Discovery happens after signature

You priced from two meetings and a demo. Real discovery starts when you open their books. In week five you find that the chart of accounts has 400 lines with duplicate cost centres, opening balances have never been reconciled, and three "departments" are actually the same department under different managers. None of that was visible from outside, and all of it is now inside your fixed price.

2. Data migration is a client problem sold as a vendor deliverable

The item master has four spellings of the same SKU. Customer records exist in the accounting system, a spreadsheet and one salesperson's phone. Nobody in the client organisation owns cleaning it, because cleaning it means someone must decide which record is true, and that decision has consequences.

So it lands on you. And it is the single most reliable schedule killer in ERP work, because it is not one migration, it is three or four cycles: load, review, discover the numbers are wrong, clean, reload. Worse, migrating dirty data produces visibly wrong numbers in week one of go-live, and user trust, once lost to "the new system is wrong", is very hard to recover.

3. "Just the standard modules" is not a scope

Every client believes their requirements are standard. What "standard accounts and stock" actually means in practice, in this market: their multi-tier pricing rules, their approval hierarchy, KRA electronic invoicing integration, M-Pesa and bank reconciliation against statement formats that differ per bank, statutory payroll deductions, and a landed-cost calculation someone invented in 2014 and never wrote down.

None of that is exotic. All of it is work. And none of it was in the two-call scope.

4. Customisation becomes a substitute for business decisions

This is the expensive one. A user says the system must match their current process. The honest answer is often that the current process is bad and the standard workflow is better. But that is a management conversation, and under a fixed price with a burning schedule, it is faster to write a customisation than to run the change conversation.

So you customise. And the cost compounds: every custom doctype, hook and patched form becomes an upgrade liability that you pay for again at every version bump, forever. Undisciplined early customisation is the most expensive mistake in ERP work by total cost, precisely because the bill arrives in instalments over years.

5. The client-side project owner does not exist

Someone was named in the kickoff. In practice they have a full-time job, no authority over other departments, and no mandate to force decisions. Your project now waits on decisions nobody is empowered to make. A fixed price does nothing about this and, as I will argue below, actively makes it worse.

6. Nobody defined go-live

Is it when the system is configured? When users are trained? When the first month closes correctly? When the old system is switched off? On a fixed-price contract, every one of those definitions costs a different amount, and in the absence of a written definition the client will always use the most expensive one.

The incentive inversion

Under a fixed price, your economics improve with less client contact. Under any honest reading of ERP success, the project improves with more. You have signed a contract that pays you to do the wrong thing.

Every extra workshop, every process discussion, every extra training session eats your margin. Meanwhile the failures that end ERP projects are all in exactly those activities. Under time and materials, running one more workshop is a decision. Under fixed price, it is a loss. That is the structural problem, and no amount of good intent survives it for eleven months.

What to sell instead

Model	Use when	Watch out for
Paid Phase 0 blueprint (fixed, small)	Always, before any implementation price	Must produce a real deliverable the client owns, not a sales document
Fixed price per phase, after blueprint	Scope is genuinely known for that phase	Phase boundaries must be functional, not calendar
Capped time and materials	Client wants budget certainty but scope is fluid	You still carry overrun risk at the cap; keep the cap per phase
Fixed core plus change pool	Most mid-sized implementations	Pool must be visible, drawn down transparently, refundable or convertible
Retainer for support and hypercare	Post go-live, always separate	Never bundle unlimited post-go-live support into a build price

Phase 0: sell the blueprint

Ten to fifteen days, fixed price, typically five to fifteen percent of the expected implementation value. Deliverables: process maps for the in-scope areas, a chart of accounts and opening balance strategy, a data quality assessment against their actual exported files, an integration inventory, a customisation list separated into "must" and "should be a process change instead", a phased plan and a costed implementation proposal.

Two commercial details that make this work. First, the client owns the blueprint outright and can take it to another vendor. That is what makes it worth paying for, and it makes you sell it honestly. Second, credit half the fee against the implementation if they proceed within sixty days. You lose nothing and you remove the "this is just a sales tactic" objection.

If a client will not pay for Phase 0, you have learned something important very cheaply: they will not pay for anything they cannot see, which means they will not pay for change requests either.

Price migration by cycles, not by promise

Quote a fixed number of migration cycles, for example three, on data supplied in a specified template by a specified date. The client owns cleaning. You own loading, validating and reporting the errors back. Additional cycles are charged at your day rate. This is the single most effective change you can make to an ERP quote, because it puts the cost of dirty data on the only party who can fix it.

Make the change pool visible

Add a contingency pool of fifteen to twenty-five percent of the contract as an explicit line item, drawn down against signed change requests at your published day rate, with unused balance refunded or converted into support months. Clients find this far easier to accept than a hidden buffer, and it changes the psychology completely: the client is now spending their pool, so they prioritise, and small requests stop being free.

If you must quote fixed price, quote against this checklist

Answer all of these in writing first. If you cannot, you are not quoting a price, you are buying a project.

• Which modules, and which specific processes inside each module, with a named exclusion list
• How many legal entities, warehouses, currencies and price lists
• How many users by role, and how many training sessions at what location
• Which integrations, against which specific systems, with which documented APIs, and who owns third-party access
• How many migration cycles, on which data sets, in whose template
• Which reports, listed by name, with sample outputs attached
• Who on the client side signs off, and what happens when they are unavailable
• What "go-live" means, as a checklist that both parties can tick
• What hypercare is included: how many days, what response times, what is excluded
• What the standby rate is when the client blocks you

The contract clauses that save this work

• Client obligations with consequences. Named project owner, response within five working days, data by a stated date, users released for UAT. Timelines extend day for day, and standby is chargeable after a grace period.
• Deemed acceptance. Defects submitted in writing within a defined window, otherwise the milestone is accepted. Without this, ERP projects hang for months on a phase nobody has formally rejected.
• Defect versus change definition. A defect is a failure against the blueprint. Everything else is a change. Write it in those words.
• Go-live definition as a checklist. Attached as an annex, ticked jointly.
• Support starts at go-live and is priced separately. Hypercare has a stated number of days, then the retainer begins.

What this costs you commercially

Be honest with yourself about the trade. You will lose deals. Some clients will take the vendor who says yes to a fixed price with no discovery, and a few of those projects will even go fine.

But look at which deals you lose. They are the ones where the buyer will not pay for discovery, will not name an owner, will not commit to data cleanup and wants a single number for something nobody has looked at. That is not a lost client. That is the eleven month project you did not take, and the margin you did not spend the following year repairing.

Fixed price is not a pricing model for ERP. It is a transfer of the client's uncertainty onto your balance sheet, priced by someone who had two meetings and no access to the data.