An ERP implementation can start with a capable team, a sound business idea, and management support—and still never reach completion.
In my experience, the biggest threats are underestimated complexity, a business owner who disengages, poorly understood data, employees who are unprepared to use the system, and communication that never leads to decisions. These are systemic problems. They affect the entire project, and no software fix can resolve them on its own.
First, let me explain what I mean by failure. Finishing a couple of months late does not automatically make an ERP project unsuccessful. I am primarily talking about implementations abandoned because completion has become unrealistic, or projects that take two, three, or four times longer than planned.
You may eventually deliver such a project. But when the schedule grows several times over, you need to ask serious questions about how the implementation was managed. A project can also finish on time and still fail to deliver the business outcome it was meant to achieve. Here, I am focusing on the systemic causes that stop an implementation or make its duration multiply.
First, treat ERP implementation as a project
PMI’s definition, used in the PMBOK Guide, describes a project as a temporary endeavor undertaken to create a unique product, service, or result. The two defining characteristics are its temporary nature and its unique outcome. Source: PMI.
That is a practical starting point for ERP implementation. You need agreed objectives, scope, a schedule, a budget, a team, and someone on the customer’s side who makes decisions and accepts the results.
Budgets can change. Scope can evolve. But someone must manage and approve those changes. Otherwise, implementation can become an ongoing activity that keeps generating work while its finish line becomes increasingly difficult to define.
Before starting, agree on what you are delivering, who has the authority to make decisions, and what will count as completion.
For a practical discussion of how to organize delivery, see my guide to ERP implementation phases and approaches.
1. The team underestimates the complexity
This is the first and most obvious cause. The plan includes configuration, development, and data migration. But approvals, waiting for decisions, and discovering how the business actually operates barely appear in the estimate.
Migration makes this particularly clear. Until the team has examined real customer records, master data, and historical transactions, there are limits to how accurately it can estimate the work. It still needs to understand what those records contain, whether they are consistent, and what decisions migration will require.
The same applies to business processes. A procedure may sound straightforward in the first meeting. Look more closely, and you discover several departments, multiple exceptions, and no agreed final process.
An inexperienced team estimates the visible technical tasks but misses the work between them. That work then arrives as a series of surprises. The schedule expands, workloads increase, and the original plan stops being useful.
Before committing to a delivery date, identify the unknowns that could materially change the work. If you do not yet have enough information, make that uncertainty explicit in the estimate.
The team you select matters here. My article on choosing an Odoo ERP consultant looks at delivery roles, costs, and red flags.
2. The business owner disengages
Although this is second on my list, in my practice, the business owner losing interest is the most likely cause of an ERP project coming to a halt.
By “business owner,” I mean the person on the customer’s side who is accountable for the outcome and has the authority to make business decisions. This does not necessarily mean the owner of the company. The role may sit with a sponsor or another designated executive; the title matters less than their active participation.
At the beginning, everything feels promising. People discuss the future system, new capabilities, and business improvements. The business owner is happy to participate. Then the work starts requiring something more demanding.
They need to get into the details, resolve conflicts between departments, answer specific questions with no convenient answer, and bring several experts with different opinions to a shared decision. They need to explain why the team originally agreed on one approach and is now taking another, and why the scope is growing. Eventually, they need to take responsibility for saying: “Yes, this deliverable is ready. We accept it.”
This is where interest can disappear. Replies become less frequent, meetings get postponed, and approvals remain outstanding. Sometimes the business owner simply refuses to engage with the questions. Nobody formally cancels the project. It just slows to a stop.
The project manager keeps chasing answers, bringing people together, and proposing options. Personal determination can keep an implementation moving for a while. But a project manager cannot indefinitely make decisions on the business owner’s behalf or accept the results for them.
What makes this especially difficult is how unevenly the consequences can fall. In situations I have encountered, the business owner could withdraw from active participation with little personal consequence. The project manager was still left accountable for the schedule, budget, and commitments. They had to explain the standstill and find a way forward, even though the decision needed to move ahead was outside their authority.
Support at kickoff does not guarantee the business owner’s involvement through completion. Their willingness to deal with difficult questions is a project risk in its own right.
I have developed several methods for maintaining and increasing the business owner’s engagement. Those deserve a separate article. Their existence should tell you something about how often I have needed them.
3. The team starts examining the data too late
An ERP system without data serves no purpose. The business needs reliable information it can use to run operations and make decisions. That is what gives the functionality its value.
I would go further: think of ERP implementation as a project to make business data available—data the company previously could not access in a consistent, usable form. Some of that information is genuinely new. Some already exists, scattered across spreadsheets, email, and employees’ heads. It still needs to be collected, agreed upon, and turned into something the company can trust.
My practical advice is simple: examine real data before estimating the implementation. And look much further than the migration files.
What data does the project team need?
Source records and transactions. Orders, sales, purchases, payments, inventory movements, opening balances, outstanding receivables and payables, and historical transactions. What gets recorded? Who records it, and when? How complete is it?
Master data and classifications. Customers, suppliers, products, services, departments, contracts, currencies, cost categories, revenue sources, and revenue allocation categories. Understand how the company classifies these things and why those distinctions matter.
Approval rules and operational conditions. Who approves a purchase? What amount triggers an additional approval? Which information is mandatory before a transaction can proceed? What exceptions are allowed?
Reports—including the ones nobody mentions in the first meetings. What does management need? What do accounting, sales, and logistics need? Which figures do employees currently compile by hand, and how do they calculate them?
I would specifically ask to see the spreadsheets prepared for weekly and monthly meetings. They can reveal requirements that nobody has yet articulated to the implementation team. If the business expects ERP to produce those reports, the underlying data must come from somewhere.
Text and templates. Notifications, emails, standard comments, payment descriptions, document templates, and printed forms. Someone must supply the content, check the wording, and approve the versions. That is project work too.
One report field can hide a whole chain of decisions
For example, suppose the company wants revenue broken down by sales channel. Adding a column to a report will not be enough. First, you need to define the channels. Then agree on how sales are assigned to them, identify the source of that information, and decide who will maintain it. Then there is the history. Do previous transactions contain the necessary information? Can it be reconstructed?
One reporting request becomes a chain of decisions and tasks. Until the team has worked through that chain, its estimate is incomplete.
Examining data is how I test whether we understand the business. It exposes decisions that have not been made, information that does not exist, and work hidden behind phrases such as “migrate the customer list” or “configure the report.”
An ERP project that underestimates its data requirements can continue indefinitely. New classifications, missing fields, forgotten reports, templates, and exceptions keep appearing. Each task looks small. Together, they keep moving the finish line.
Before committing to dates, agree on what data must be available, where it will come from, who will prepare it, and how you will decide it is ready for use.
If your project involves moving existing records, our Odoo migration services cover the migration side of that work. The business still needs to agree what those records mean and how they will be used.
4. Customer employees lack the necessary skills
The people using ERP will be warehouse staff, purchasing staff, salespeople, accountants, and others doing their daily jobs. Implementation planning needs to reflect their actual level of preparation.
There are several different issues here, and I would assess them separately.
Skills and process knowledge. Some employees may still be on probation and learning the company’s processes. Others may know their existing application well but have a very different understanding of how ERP works. Some work confidently from written procedures; others need someone beside them saying: “Open this screen, click here, and check the result.”
Language. Some employees struggle with the English used in the interface or training. That affects how you explain the work and check understanding; it does not, by itself, tell you how well they know their job.
Willingness to change. An employee may have spent years using another application and have little interest in changing. Someone can be experienced in their current work and still be reluctant to adopt a new system.
If your implementation plan assumes a uniformly skilled and motivated group of users, you may be in for an unpleasant surprise. Different gaps need different responses, so understand which ones you are dealing with before planning the training and launch.
I trained employees at a company in Uganda. That experience made me reconsider my assumptions about user preparation and how to introduce new processes.
I could not simply take my usual training approach into a different working environment and expect the same result. Language, previous experience, familiarity with the operations, and the way people were accustomed to learning all mattered.
I would not use that experience to generalize about employees across a country or a continent. What it taught me was how dangerous it is to plan training around an imaginary “typical user.”
The way you launch ERP must match the preparation of the people who will actually use it.
Check readiness through real tasks. Can a warehouse employee independently receive goods? Can a purchasing employee complete the required workflow? Do they know what to do when something goes wrong or differs from the example shown during training? Holding a training session does not answer those questions.
If employees need more preparation than expected, the project will require more explanation, practice, and support. Account for that time and effort. Otherwise, you can finish configuring the system, load the data, and still leave the business unable to work effectively.
Our Odoo training options provide a starting point for discussing the roles and workflows your team needs to learn.
5. Communication is underestimated
Communication includes the entire approval process: who makes a decision, whose agreement is mandatory, who should be consulted, and who simply needs to be informed.
There is a trap here. If you involve everyone in every discussion and seek unanimous agreement on every question, you may never finish. Every department will have its own requests, exceptions, and arguments.
But the opposite approach is equally dangerous. The solution is implemented, the work is ready, and the person responsible for acceptance disagrees. Nobody secured their agreement when it mattered. Now there is no sign-off.
Decide in advance who has decision-making authority and whose participation is necessary. That is the practical purpose of a communication matrix: to establish responsibilities and how people will work together.
Project visibility and open working correspondence also matter. Participants should be able to see the decisions, understand the reasoning, and know which questions remain unresolved. An agreement between two people should not stay in a private conversation when it affects several departments.
Common sense and specific questions help enormously. “What does everyone think?” can open an endless discussion. A more useful question is: “We propose this solution. Will it work for your department? If not, which operation would it prevent you from completing?”
The project manager also needs to take the initiative and set limits. We cannot accommodate every preference in this implementation. We need a decision that allows us to deliver the agreed scope.
Some conflicts, however, are outside the project manager’s authority. If departments cannot agree, escalate the issue to the business owner, steering committee, or sponsor—whoever has the authority to resolve it. The project manager should present the disagreement, the available options, and their consequences.
A conflict between departments needs a clear route to a final decision. Without one, meetings and correspondence can continue indefinitely while implementation stands still.
Why I have said so little about technical problems
Integrations, data cleansing, and master data configuration require skill and time. But for an experienced ERP team, these are familiar professional tasks. There is a problem to solve, a way to approach it, and an outcome to verify.
Securing the business owner’s involvement, resolving contradictory business rules, preparing employees, and aligning departments are much harder. The technical team can do its work well while the overall implementation moves toward a standstill. That is why I pay so much attention to the organizational causes.
I also do not automatically treat a budget overrun as proof of failure. Additional spending may mean the work required more resources. You need to understand why the budget changed and what the business received.
I am more concerned about an implementation that never finishes, or one that takes several times longer than planned.
For a concrete account of the delivery challenges behind a working system, see our Odoo implementation story across five companies and seven 3PLs.
A practical exercise: why would your competitor’s ERP project fail?
There is a simple exercise that consistently worked in the project management training I delivered. Ask the team:
Imagine a competing company is starting an ERP implementation. Name up to ten reasons why it will fail to complete the project.
The competitor can be entirely fictional. You only need to imagine a business facing challenges similar to yours.
Focus on causes that could make completion impossible or make the project take several times longer than planned. A delay of a couple of weeks is too small for this exercise.
When discussing your own implementation, it is easy to defend existing decisions:
“Our team is experienced.” “Management supports us.” “We’ll sort out the data.”
Talking about an imaginary competitor is easier. Suddenly, people can identify a disengaged business owner, unprepared employees, and conflicts between departments that nobody intends to resolve. That shift helps people name risks they tend to underestimate in their own project.
Write down the reasons. Then return to your implementation and ask, for each one:
- Could this happen here?
- What signs of it can we already see?
- What must we do to prevent it from stopping the project?
- Who is responsible for that action?
“The competitor’s business owner will stop making decisions” becomes a concrete check: Who makes our key decisions? Do they have the time and authority? What happens if they stop participating?
First, explain why your competitor will fail to implement ERP. Then check which of those conditions already exist in your own project.
You will have a practical list of risks and conditions needed for completion. The best time to act on it is before missing decisions, missing data, and unprepared people start multiplying your delivery schedule.
If you are preparing an implementation, explore our Odoo implementation services or discuss your project with me.