According to recent industry studies, 60 to 70% of ERP projects exceed their initial budget or timeline. One-third are considered partial or complete failures by the organizations themselves. These figures don’t mean ERP is a bad idea — they mean most organizations repeat the same mistakes, project after project.
The good news: these mistakes are known, documented, and perfectly avoidable. Here are the 10 most common mistakes I’ve observed in the field, with a precise diagnosis and concrete solution for each pitfall.
Mistake 1: Starting without real executive sponsorship
The diagnosis. The ERP project is initiated by IT or Finance, but without visible commitment from the CEO or Managing Director. Result: when difficult trade-offs arise (additional budget, choice between conflicting business processes, organizational restructuring), there’s no one to make decisions. The project gets stuck in committees.
What we observe. Steering committees with no decisions. Trade-offs postponed week after week. Delays that slip because no one wants to take responsibility.
The solution. Before signing the purchase order, obtain formal commitment from the executive team: a monthly steering meeting that the CEO or MD physically attends, with a reserve budget validated upfront (typically 20-25% of the initial budget) for contingencies. Without this commitment, delay the launch.
Key takeaway: An ERP is an enterprise transformation project, not an IT project. Without executive-level leadership, the project will fail — even with the best integrator on the market.
Mistake 2: Underestimating the scoping phase
The diagnosis. The company wants to move fast. Scoping is rushed in 3 weeks instead of 3 months. Processes aren’t documented, edge cases aren’t identified, business exceptions are ignored.
What we observe. Additional development requests that emerge during user acceptance testing — each “oversight” is billed in consultant daily rates. Budget overrun that starts even before go-live.
The solution. Plan a scoping phase of at least 6-12 weeks depending on project size. Involve managers from each functional domain. Document processes as they exist today (AS-IS) before describing target processes (TO-BE). Edge cases and exceptions often represent 30% of the real project complexity.
Mistake 3: Wanting to migrate 100% of historical data
The diagnosis. IT announces that 15 years of transactional history must be migrated “to not lose the company’s memory.” This decision can multiply data migration duration and cost by 2 or 3.
What we observe. Weeks of data cleaning and mapping. Migration bugs that delay go-live. And ultimately, historical data that no one ever uses in the new ERP.
The solution. Separate active data (customers, suppliers, items, work in progress) from historical data. Migrate only what’s necessary to operate at go-live. History can be preserved in a separate data warehouse or in the old system kept read-only for 2-3 years. It’s less glamorous, but it works.
Mistake 4: Heavily customizing the ERP instead of adapting processes
The diagnosis. Each department wants the ERP to work exactly like the old system. Management validates all customization requests without arbitration. The project transforms into a custom development project.
What we observe. Customization costs exceeding 40% of total budget. ERP updates blocked for years because customizations aren’t compatible. A system that becomes impossible to evolve.
The solution. Apply the 80/20 rule: if the ERP covers 80% of your need in standard, adapt your processes for the remaining 20% — unless that 20% is a real competitive advantage. Create a waiver committee that evaluates each customization request on three criteria: business impact, development cost, maintenance cost over 5 years.
Field advice: ERP vendors spend billions optimizing their standard processes. In 9 cases out of 10, their standard process is better than your homegrown process.
Mistake 5: Neglecting key user training
The diagnosis. The training budget is reduced during budget arbitrations. Key users receive 2 days of training for a solution that will radically change their daily work. Go-live happens with teams who don’t master the tool.
What we observe. Productivity collapses for 3-6 months after go-live. A help desk overwhelmed. Processes performed outside the ERP (Excel, paper) because users don’t know how to do otherwise.
The solution. Plan training in 3 levels: (1) super users (key users) who must master the tool perfectly and become their teams’ references; (2) standard users with targeted training on their workflows; (3) managers with training on dashboards and reporting. Recommended budget: 10-15% of total project budget.
Mistake 6: Go-live during peak activity periods
The diagnosis. The go-live date is set without considering the business calendar. The startup ends up during year-end closing, product launch period, or peak commercial activity.
What we observe. Over-solicited teams who don’t have time to handle go-live incidents. Operational errors with direct financial consequences. Extreme pressure on teams.
The solution. Identify the 3-4 quietest periods of the year for your business and plan go-live during one of them. Plan a 4-6 week buffer before the next peak activity period to absorb post go-live adjustments.
Mistake 7: Lack of project governance on the client side
The diagnosis. The client-side project manager is a junior profile or is overloaded by operational responsibilities. They don’t have authority to make decisions nor time to actually manage the project.
What we observe. Delays in validations. Meetings without minutes. Commitments not kept on client deliverables (data provision, key user availability for workshops, acceptance validation).
The solution. The client project manager must be dedicated 50-80% of their time to the project during the active phase. They must have real decision delegation on operational matters and direct access to the executive sponsor for strategic arbitrations. It’s a key position, not an accessory mission.
Mistake 8: Choosing the integrator on price
The diagnosis. The RFP is won by the cheapest integrator, who proposed a junior team and tight fixed price. The offer was based on an optimistic scope estimate.
What we observe. Time and materials overruns from the scoping phase. Consultant turnover forcing re-explanation of context to each new resource. Insufficient delivery quality generating technical debt.
The solution. Evaluate integrators on 5 criteria: (1) references in your sector, (2) stability of the proposed team (ask for nominative CVs and presence commitments), (3) project methodology, (4) post go-live support capacity, (5) price. Price should be the last criterion, not the first. The difference between cheapest and best positioned is often 20-30% — which represents much less than the cost of a failed project.
For deeper integrator selection guidance, consult our 100-point scoring grid to compare 3 integrators.
Mistake 9: Ignoring load and performance testing
The diagnosis. Tests are performed with 5-10 simultaneous users. Go-live happens with 200 users. The ERP proves catastrophically slow or unstable in production.
What we observe. Response times of 30-60 seconds for basic operations. Timeouts during month-end closings. An unusable system during peak periods.
The solution. Plan load tests with the real volume of simultaneous users, multiplied by 1.5 to simulate a peak. Specifically test mass processes (closings, price calculations, EDI imports) that concentrate the load. Contractually require maximum response times for critical transactions.
Mistake 10: No rollback plan
The diagnosis. The project is planned in one direction: go-live and that’s it. No one has thought about what would happen if the go-live had to be cancelled or postponed urgently.
What we observe. During a major go-live incident, the company is paralyzed. The old system has been cut off. Data is partially migrated. There’s no rollback procedure.
The solution. Document your Plan B before go-live: until when can we roll back? What are the rollback trigger conditions? Who makes the decision? Maintain read-only access to the old system for at least 3 months after go-live. It’s inexpensive insurance against a potentially catastrophic risk.
In summary: the profile of a successful ERP project
A successful ERP project means:
- An executive sponsor who is committed and visible
- Rigorous scoping before startup
- Realistic and pragmatic data management
- A culture of “standard before specific”
- A non-negotiable investment in training
- Planning aligned with the business calendar
- A dedicated and empowered client project manager
- An integrator selected on value, not price
- Performance testing conducted under real conditions
- A documented and tested rollback plan
These 10 points aren’t luxuries reserved for large companies. They apply from 50 users and €200K budget. Companies that respect them succeed. Others feed the failure statistics.
The difference between a project that succeeds and one that fails rarely comes down to technology. It comes down to the quality of governance, the rigor of scoping, and the honesty with which teams assess their capacity to lead change.
