ERP Projects Fail for Reasons That Have Nothing to Do With the Software
No executive sponsor. No internal owner with time freed up. Scope agreed verbally in a workshop. Dirty data found in month five. Training cut to protect the budget. A go-live date picked by a board rather than by readiness. That list is the real risk register, and it is identical whether you choose ERPNext, Odoo or SAP. We run the method that closes it.
50+ ERP and software projects. Zero failed projects since 2021.
The causes of failure are organisational, not technical
In twenty years of post mortems, the software is almost never the culprit. The recurring causes are sponsorship, ownership, scope, data and training. All five are within your control, and all five are cheap to fix at the start and expensive to fix at month six.
Six causes, and not one of them is the product
No executive sponsor, so nobody can force a decision between two departments. No internal owner with time freed up, so every question waits a week. Scope agreed verbally in a workshop and remembered differently by both sides. Dirty data discovered in month five, when there is no slack left. Training cut when the budget gets tight, which guarantees people work around the system. And a go-live date chosen by a board rather than by readiness. Name these at kick-off and most of them stop happening.
- A sponsor who can settle a cross-department argument in a week.
- A named internal owner with real hours released, not a title.
- Scope written down, priced, and signed before build starts.
Phased is right for most organisations, and we will say so
A phased rollout puts a working system in front of people early. They learn it on real transactions, the second phase lands faster because the team already knows the product, and a problem in phase one is contained to phase one. Big bang is justified in one situation: when running the old and new systems side by side would need temporary integration that costs more, in money and risk, than the exposure it removes. That is a real case, and it is narrower than most vendors admit. If you go big bang, budget honestly for a longer transaction freeze and a larger hypercare team.
- Phase one is the smallest set that closes the ledger properly.
- Big bang needs a longer freeze, more testing and more support cover.
- The decision is made on integration cost, not on impatience.
Six workstreams run inside every implementation
They overlap, they are not a queue, and each one has a named decision maker on your side. When a project slips, it is nearly always because one of these six was left without an owner.
Five stages, with data work running from day one
What you get from an implementation we run
Process design pack
Current and future state flows per department, with every deviation from standard justified in writing and priced.
Configured system
Accounts, taxes, approvals, warehouses, pricing and access rights set to the signed design and tested against it.
Migrated, reconciled data
Masters cleaned and de-duplicated, opening balances loaded, and a trial balance and stock position that tie back to the old system.
UAT scripts and sign-off
Test scripts per department in your own language, run by your own people, with a signed acceptance record for each team.
Cutover runbook
An hour-by-hour plan with owners, a full dress rehearsal, a defined rollback position and a documented go or no-go gate.
Training and handover
Role-based sessions on your own data, written guides per job, and a support runbook so your team is not dependent on us.
What a disciplined implementation actually buys you
Already know which ERP you want?
Read the choice on fit and on running cost, not on feature lists. The method below is the same on all three, so pick the one whose shape matches your business.
Why teams hand us the implementation
ERP implementation questions
How long does an ERP implementation take?
What does an ERP implementation cost and what drives the price?
Should we go phased or big bang?
How much time will this take from our own team?
What happens if we are not ready on the go-live date?
How do you handle scope changes during the project?
Scope Your ERP Implementation
Book a free consultation. We will walk your processes, look at the state of your data, and give you a straight view on phasing, timeline, internal effort and what the project will actually demand from your team before you commit to a platform.
Book a Free Consultation →No commitment. A practical first look at your implementation, whichever ERP you end up choosing.
What Is Inside an ERP Implementation
The method is the product. Here is what we design before anyone configures a screen, how the data work runs, what your own team does during testing, and how a cutover is rehearsed so that go-live is a decision rather than a gamble.
From how work really flows to a go-live you can defend
We record how work actually flows, not what the manual claims
We sit with the people doing the job and follow a real order, a real purchase and a real month-end from start to finish, including the spreadsheets and the phone calls that never made it into the procedure document. Only then do we decide, item by item, which processes change to fit the standard system and which are genuinely differentiating and worth configuring around. Most of what feels custom is habit inherited from an old system, and saying so early saves months of build.
- Current state observed on the floor, not collected in a questionnaire.
- Every gap marked standard, configure, or change the business.
- Deviations priced and signed, so nothing is agreed verbally.
Data work starts in week one because it is the usual schedule killer
Extraction, cleansing, de-duplication, opening balances and reconciliation back to the old system. Clients consistently underestimate this, and it is the workstream that most often decides whether a go-live date holds. We pull a first extract in the opening fortnight precisely so the ugly surprises surface while there is still slack in the plan. Integrations run alongside, each with a named owner, a field mapping, a defined error path and its own test.
- A first data extract inside the first two weeks, not after build.
- Masters de-duplicated before loading, with the merge rules written down.
- Trial balance and stock position reconciled line by line to the old system.
Your departments test it, and the cutover is rehearsed first
User acceptance means each department running its own real transactions end to end, on its own migrated data, and signing off. A consultant demonstrating that the software works is a demo, not a test. Cutover then runs from an hour-by-hour runbook with named owners, rehearsed at least once in full, with a rollback position agreed in advance. We stay close through the first month-end close, because that is when the gaps in tax setup, cost postings and reporting actually surface.
- Test scripts per department, run by your people, signed per team.
- A full dress rehearsal of cutover before the date is confirmed.
- Hypercare through the first month-end close, with a formal exit.
Everything the implementation hands over
Scope and process pack
Phase boundaries agreed in writing, with current and future state flows recorded per department.
Configured system
Accounts, taxes, approval limits, warehouses, pricing, numbering and access rights, tested against the design.
Reconciled migration
Masters, balances and open documents loaded and checked against your old system before anyone signs.
Integration register
Every interface listed with its owner, field mapping, retry behaviour and who gets called when it fails.
Cutover runbook
An hour-by-hour plan with owners, a rehearsal record, a rollback position and the go or no-go criteria.
Training and handover
Role-based guides, recorded sessions and a support runbook, so your team can run the system without us.