Why ERP projects fail in the GCC, and how to de-risk yours
Most ERP projects that fail were set up to fail before the first workshop. The causes are predictable, they show up early, and nearly all of them can be closed off in the proposal you sign.
When an ERP project fails, the software usually takes the blame. In the projects we are called in to rescue across the Gulf, it is almost never the software. It is a scope nobody wrote down, a billing model that rewards hours over outcomes, a data migration left to the last month, or a team that was trained once and then went back to Excel.
The useful part is that these causes are predictable. They show up in the proposal, in the first invoices and in the first steering meeting, long before go-live. This guide sets out the six patterns we see most often, how to spot each one early, and what to put in the contract so it cannot happen to you.
Key takeaways
- Most ERP failures are contract and discipline problems, not platform problems, which is why they are preventable.
- A signed process-level blueprint is the single strongest protection. Without it, no project can be declared finished.
- Bill by phase against gates you sign, not by the hour, and price every change before work starts.
- Treat data migration and user adoption as workstreams with owners and sign-offs, not as tasks at the end.
- Name the senior consultants who will deliver the work in the contract itself.
Pattern 1: the scope was never written down
The proposal lists modules: Sales, Purchase, Inventory, Accounting. It does not describe how an order moves from quote to cash in your business, who approves what, or which reports finance needs at month end. Without that, there is no definition of done. Every gap becomes a debate, every debate becomes a change request, and the project drifts.
De-risk it: insist on a business blueprint before any build work. It should describe each process step by step, list the reports and approvals, and be signed by your process owners. The build is then measured against that document, not against memory.
Pattern 2: open-ended hourly billing
Time and materials sounds flexible. In practice it means the partner earns more the longer the project runs, and you carry all of the risk of their estimate. We regularly meet businesses that have paid for more hours than the original quote and are still not live.
De-risk it: fix the price per phase against the signed blueprint. Tie each payment to a gate you sign off: blueprint approved, configuration accepted, migration reconciled, users trained, go-live stable. Agree in writing that any change request is priced and approved before anyone starts on it.
Pattern 3: a senior sale, a junior delivery
The person who ran the demo is not the person who configures your system. Junior consultants learning on your project make reasonable-looking decisions that become expensive six months later, usually in costing, tax setup or multi-company structure.
De-risk it: name the delivery consultants in the contract, with their experience, and agree that substitutions need your approval. Ask who will sit in the blueprint workshops. That person should still be on the project at go-live.
Pattern 4: migration left to the end
Data migration is a project inside the project. Customer masters that exist in four versions, item codes nobody can explain, opening balances that do not reconcile. When migration is treated as a task for the final month, users meet the new system with numbers they do not trust, and they go back to their spreadsheets. Our data migration checklist covers the full approach.
De-risk it: start migration in the blueprint phase. Name an owner for each data object, decide early what not to migrate, run at least two full trial loads, and make a signed reconciliation of receivables, payables, stock and the trial balance the gate for go-live.
Pattern 5: adoption left to a training PDF
A system that is technically live but bypassed in practice is a failed project with a licence fee. This happens when training is a single session or a handover document, and when the old workaround is never switched off.
De-risk it: train by role, on your own data, close to go-live. Pick the workflows people currently run outside the system and retire the spreadsheet or the side tool on a date everyone knows. Then check usage in the system itself during the first month, not in a survey.
Pattern 6: customising instead of adapting
Every business believes its processes are unique. Some are. Most are standard processes with local habits layered on top. Rebuilding those habits in custom code makes the system slower to deliver, harder to support and painful to upgrade. The rarer opposite case is a platform that genuinely does not fit, which is a selection problem that should have surfaced in the blueprint.
De-risk it: customise only where the process is a real competitive advantage or a legal requirement. For everything else, adopt the standard flow and change the habit. Where a customisation is approved, document why, so the next upgrade does not surprise you.
What is different in the Gulf
The six patterns are universal, but a few conditions make them more likely here:
- Group structures. Many businesses run several legal entities, sometimes across the UAE and Saudi Arabia, with intercompany trading. A multi-company design decided late is expensive to undo. If you trade in both markets, plan for ZATCA Phase 2 as well as UAE requirements from the start.
- Compliance in the design. VAT, corporate tax and the coming UAE e-invoicing requirements belong in the blueprint, not in a later phase.
- Owner-led sign-off. In founder-managed companies every decision waits for one person. Name a delegated process owner per area so gates do not stall.
- Partner turnover. Consultants move between firms often. Documented configuration and a written blueprint protect you if your partner changes.
A warning-sign checklist by stage
| Stage | Warning sign | What to do |
|---|---|---|
| Proposal | Modules listed, processes not described | Ask for a blueprint phase with a fixed price before build |
| Proposal | Hourly billing with no cap | Move to fixed price per phase, paid against signed gates |
| Contract | No named delivery consultants | Name them, with approval rights on substitutions |
| First two months | Invoices for hours with no matching deliverable | Stop and agree deliverables in writing |
| Build | Migration still described as a later phase | Start trial loads now, with named data owners |
| Pre go-live | Training planned as one session | Role-based training and a date to retire the workaround |
| After go-live | Users still exporting to Excel to do their jobs | Find the workflow that fails them and fix it first |
What a de-risked project looks like
It is not dramatic. A signed blueprint, a fixed price per phase, named senior consultants, migration reconciled before go-live and users trained on their own data. For one appliances distributor we work with, that meant one system from order to service call, with full stock and service visibility in the same place. An operations director at an equipment company we delivered for put the outcome in a sentence: they "delivered exactly what they promised, on schedule." That is what written scope and signed gates buy you.
If your project is already in trouble, the same principles apply in reverse. Our guide to rescuing a failed ERP implementation covers triage, root cause and the keep, fix or restart decision.
About to sign an ERP proposal?
Talk to a senior consultant first. We will walk through the scope, the billing model and the sign-off gates with you, and show you where the risk sits before the first invoice lands.
Book a discovery call →