Contents9
A badly launched ERP leaves marks: a blown budget, teams re-keying into the old tool “just in case”, leadership that no longer trusts the figures. The software is rarely at fault. The same six causes come back, and each can be prevented during scoping.
In short
Growing scope: write the out of scope and defend it.
Dirty data: clean before importing, test on a copy.
Heavy customisation: prefer the standard, develop as a last resort.
Low adoption: train by role and switch off the old tool.
Fuzzy steering: a decision-maker who settles within a week.
Big-bang go-live: open in batches, department by department.
1. The scope that grows
Every workshop adds a request: one more report, a special case, a module “while we are at it”. Taken one by one, they seem reasonable. Together, they double the duration. The counter is a written list of what is outside the first batch, in the requirements document, and a next batch where good ideas can be parked.
2. Data imported as is
Duplicate customers, items without units, suppliers with three spellings: importing this data into an ERP makes it visible to everyone, and errors spread to invoices. You need to clean beforehand, and test the import on a copy until it runs without manual fixes. The method is in ERP data migration.
3. Customisation that blocks upgrades
Recreating every habit of the old tool in the ERP leads to dozens of custom developments. Each must be reworked at every new version. After two years, the company is stuck on an old version because migrating costs too much. Our rule: first adapt the process to the standard, then configure, and only last develop. See Customising an ERP safely.
4. Spreadsheets that survive
If the old spreadsheet stays open, it becomes the reference again at the first doubt. Teams are not acting in bad faith: they trust what they know. The counter comes down to two moves: role-based training on real cases, and a date when the old tool goes read-only. See Training teams on an ERP.
5. Steering without a decision-maker
An ERP touches every department, and each department has its priorities. Without someone who decides, every disagreement becomes another meeting. You need a project lead on the company side, with the power to decide, and a rule: every open question gets an answer within a week.
6. The big-bang go-live
Opening everything the same Monday concentrates the risks: if invoicing blocks, everything blocks. Opening in batches (sales and invoicing first, then purchasing, then stock) leaves time to correct. Each batch is judged on the acceptance scenarios before the next one opens.
- Batch 1
Sales and invoicing, on cleaned data.
- Batch 2
Purchasing and suppliers.
- Batch 3
Stock and logistics, after a stock count.
- Batch 4
Dashboards and automations.
What experience shows
Studies of IT projects converge on this point: most overruns come from scope and organisation rather than technology. McKinsey’s report on large IT projects gives a measure of it: it covers projects much larger than most SME ERPs, but the causes it describes are the same.
The common counter
These six causes have one thing in common: they are prevented during scoping, not during the project. A written scope with its out of scope, a planned data migration, a customisation rule, a role-based training plan, a named decision-maker and a batched go-live fit on a few pages. The complete ERP guide goes through them step by step. It is also the method of our CRM and ERP offer: a fixed price on a written scope, batches validated one by one, and follow-ups at 30 then 90 days to check the project delivered what it promised.
Frequently asked questions
What is the first sign an ERP project is drifting?
A go-live date that slips while the scope has not changed, or workshops that multiply without decisions. Both say steering is not deciding. The right reflex is to go back to the requirements and move what is not essential to the next batch.
Can a badly started ERP project be saved?
Often, yes. Freeze the scope, take stock of what works, open a reduced first batch that really works, then resume the rest batch by batch. Starting from scratch is rarely necessary; starting from a smaller scope, almost always.
Who should own the project inside the company?
Someone who knows the flows and has leadership’s ear, often the finance director or the operations director. It is not a spare-time role: count a significant share of their time during the main batches.
Sources
Delivering large-scale IT projects on time, on budget, and on value, McKinsey
Read on mckinsey.com(new tab)Jim · founder of Brain Plus AI
Also in erp: odoo and dolibarr
Practical guide5 min The topic guide
ERP for a company of 20 to 500 people: the guide
An ERP brings sales, purchasing, stock and invoicing into one database. This guide explains when it becomes useful, how to choose between Odoo and Dolibarr, and what makes the project succeed or fail.
Practical guide4 min
ERP requirements document: the short template that works
An eighty-page ERP requirements document protects you from nothing, whereas a short document focused on flows and business rules makes a better project. The outline, section by section.
Understand4 min
AI in an ERP: what really helps, what can wait
Reading supplier invoices, bank reconciliation, answering questions about the data: AI has solid uses in an ERP, others are still demos. The sorting, use by use.