The numbers back this up. Panorama Consulting's 2026 ERP Report found that almost a quarter of organisations ran over schedule and more than a quarter over budget, with organisational issues the most common cause of delay. This guide covers each mistake, the early warning sign, the fix, and a worked example of a project brought back on track.
Which ERP implementation mistakes are most common?
These seven, roughly in the order they appear in a project. Each has a warning sign you can spot weeks before it becomes a delay.
| # | Mistake | Early warning sign | Fix |
|---|---|---|---|
| 1 | No business owner | Steering meetings attended only by IT and the vendor | Name an owner from the business with authority over all departments |
| 2 | Slow decisions | The list of open questions grows every week | A decision log with an owner and a due date for each item |
| 3 | Copying old processes | Customisation requests start in the first month | Start from the standard process; customise only with a business case |
| 4 | Dirty master data | Duplicate customers or items found in the first trial load | Give each list a business owner and run two trial loads |
| 5 | Testing with made-up cases | Test scripts written by the consultants alone | User acceptance testing with last month's real transactions |
| 6 | Training at the wrong time | Training booked months before go-live, or for key users only | Role-based training one to two weeks before go-live |
| 7 | Going live with no fallback | No written go or no-go criteria a week before the date | A cutover plan, go or no-go checklist and hypercare period |
The first three cost the most time because they hold up everything after them. The last four are cheaper to fix but more visible: they decide whether week one after go-live is calm or chaotic.
1. Who should own an ERP project?
Someone senior from the business, not IT and not the vendor. ERP changes how sales, purchasing, the warehouse and finance work together, and only someone with authority over all of them can settle a dispute between departments.
The warning sign is a steering meeting attended by the IT manager and the vendor's project manager, with department heads sending apologies. The fix:
- Name a project owner, usually the CFO, finance manager or general manager.
- Give them a fixed share of their week for the project and make it part of their goals.
- Hold a steering meeting every two weeks, with every department head present.
- Name a key user in each department who will test, train others and answer questions after go-live.
2. Why do slow decisions delay ERP projects more than software?
Because software can be configured in days, but a decision left in an inbox for three weeks costs three weeks. Typical decisions are the new chart of accounts, approval limits, pricing rules, costing method and which reports replace which spreadsheets.
The fix is a decision log: one line per open question, with an owner, a due date and the options. Agree a rule at kickoff, for example that any decision not made within five working days goes to the steering meeting. When the log stops growing and starts shrinking, the project is on track.
3. Should you copy your old processes into the new ERP?
No. Rebuilding every old spreadsheet and workaround in a new system is the most expensive way to stand still. Each customisation adds build time, testing and upgrade work for years.
Start from the system's standard process and change it only when there is a clear reason: a legal requirement, such as a ZATCA or UAE e-invoicing rule, or something that genuinely sets you apart from competitors. Ask for every customisation request in writing, with the business reason, the owner and the cost. Many requests disappear once someone has to sign them.
4. Why does dirty master data break go-live?
Because every transaction uses it. A customer saved twice under two codes splits its balance, an item without the right unit of measure cannot be sold by the carton, and opening stock taken from the books instead of a count is wrong from day one.
Give each list a business owner who cleans it and signs it off: sales for customers, purchasing for suppliers, the warehouse for items, finance for accounts. Run at least two trial loads, count the stock, and tie every opening balance back to the old system. Our ERP data migration checklist covers this step by step.
5. Why do projects pass testing and still fail in week one?
Because the tests used made-up cases that the consultants wrote and ran. Real work brings the exceptions: a partial delivery, a credit note against an old invoice, a price change mid-month, a customer over their credit limit.
Have the people who will use the system test it, with last month's real transactions, from order to cash and from purchase to payment. Sign off only when every critical process works end to end, including VAT and e-invoicing. Our user acceptance testing checklist lists what to test.
6. When should ERP training happen, and for whom?
One to two weeks before go-live, for everyone who will use the system, in their own role. Training three months early is forgotten by go-live; training only key users leaves the rest learning on live data.
- Train by role: a salesman learns orders and returns, not the general ledger.
- Use your own data in the test system, not the vendor's demo company.
- Give each role a short guide, in English and Arabic where needed.
- Keep key users on the floor during the first week to answer questions on the spot.
7. Is going live with no fallback a mistake?
Yes. A go-live date is a decision, not a deadline, and it needs criteria. A week before, check a written go or no-go list: user testing signed off, opening balances tied out, users trained, e-invoicing tested, and the old system available read-only.
Pick a date at the start of a VAT return period and outside your peak season. Plan about four weeks of hypercare, until the first month-end close, when the implementation team stays close to fix problems quickly. Our ERP implementation timeline shows where go-live sits in a typical plan.
What does fixing these mistakes look like? A worked example
A building materials trader in Sharjah has one company, one warehouse and 60 users. It planned a 16-week implementation, followed by four weeks of hypercare. At week 10 it was five weeks behind, and the team expected go-live to slip to week 30. The example is illustrative.
The review at week 10 found five of the seven mistakes. Four are in this table:
| Symptom at week 10 | Mistake | Fix agreed | Effect |
|---|---|---|---|
| 38 open questions, the oldest seven weeks old | 2, slow decisions | Decision log reviewed weekly; anything older than five working days goes to the general manager | 31 closed in three weeks |
| 14 customisation requests, mostly copies of old reports | 3, copying old processes | Each request needs a written reason and an owner | 9 withdrawn, 5 built |
| 1,900 customers in the trial load, about 300 of them duplicates | 4, dirty master data | Sales manager owns the customer list; second trial load | Clean load in week 13 |
| Test scripts written only by the consultants | 5, made-up test cases | Key users re-test with last month's transactions | 22 issues found before go-live, not after |
The general manager became the project owner, replacing the IT manager, which fixed the fifth, mistake 1. Go-live moved to week 22, at the start of the next VAT quarter. That was six weeks late against the plan, but eight weeks earlier than the team expected at week 10.
The lesson: none of the fixes were technical. They were decisions about who decides, and by when.
Which mistakes does HYP see most often?
The first two. In the implementations HYP runs across the UAE and Saudi Arabia, projects rarely slip because of configuration or data volumes. They slip when nobody in the business can make a decision stick, or when decisions wait for a meeting that keeps moving.
Three habits separate the projects that go live on time:
- The owner is the person who signs off the budget, not someone reporting to them.
- Open decisions are reviewed every week, with names beside them.
- Key users are freed from part of their day job during testing and the first weeks after go-live.
Our ERP implementation timeline shows how long each phase takes when these habits are in place. To see how HYP's consultants run a project, from discovery to hypercare, visit our ERP Implementation & Migration page.