Ask anyone who has lived through a failed ERP project what went wrong and you will rarely hear a complaint about the software. You will hear about the sponsor who was never available, the requirements that changed every week, the training that happened too late and the go live date that nobody dared move. The pattern repeats across systems and industries. Here are the six causes we see most often and what to do about each.
Nobody owns it on the client side
An ERP project needs a person in the business who has the time and the authority to run it. In many projects that person has a full time job as well, and the project gets the evenings. Decisions wait. Workshops are rescheduled. The supplier fills the gap with assumptions, and the assumptions are wrong.
What to do: name a project lead and free at least two days a week of their time for the duration. If nobody can be freed, the project is not ready to start.
The wrong people write the requirements
Requirements gathered from managers describe how a process is supposed to work. The people who actually run it know how it really works, including the exceptions that happen every day. When they are not in the room, the system is designed for a business that does not exist, and the exceptions surface at go live.
What to do: put the person who raises the invoices, the person who picks the stock and the person who closes the month in the workshops. Managers can attend too, but the doers must.
Custom code is the first answer
Every gap between the business and the standard system can be closed with code. Code is expensive to write, expensive to test and expensive to carry through every future upgrade. Projects that reach for it by default end up with a system nobody can change and an upgrade nobody can afford.
What to do: for every gap, ask three questions in order. Can the process change? Can standard configuration handle it? Is there an existing module? Only then consider code, and write down why.
Data is left to the end
Master data is exported the week before go live, and the years of duplicates and dead records go live with it. Reports are wrong from day one, stock figures cannot be trusted and the finance team spends the first quarter cleaning up.
What to do: start cleaning customers, suppliers, products and the chart of accounts in the first week. Give the work to people who know the business and give them time. Load data into a test database at least twice before the real cut over.
Training and change are an afterthought
Staff learn about the new system when they are told to attend a training session. The session is a large group, a week before go live, covering everything at once. People go back to their desks, forget most of it, and blame the system when it does not behave like the old one.
What to do: involve users from the first workshop so the system is theirs by the time it launches. Train per module and per role, close to the point of use, with recordings and short guides they can return to. Explain why the change is happening before you explain how the buttons work.
The go live date is fixed before the readiness is
A date is chosen at the start, often for good reasons, and then defended regardless of what the project finds. Testing is compressed. Open issues are carried live. The first weeks are spent firefighting problems that a further fortnight would have prevented.
What to do: define readiness criteria per department at the start: data reconciled, processes tested end to end, key users trained, open issues below an agreed threshold. Confirm the date only when the criteria are met, and be willing to move it.
What this means for your Odoo project
None of this is about Odoo in particular. It applies to every ERP. What Odoo changes is the cost of getting it right: the software is affordable enough that the implementation, not the licence, is the main investment, which makes the quality of the project the thing that determines the return.
If you are planning a project and would like to test your preparation against these six points, our readiness checklist covers each of them in detail, and we are glad to talk it through.
Frequently asked questions
How long does an Odoo implementation take?
A focused first phase covering sales, invoicing or accounting, inventory and purchasing for a single company typically runs a few months from discovery to go live. Adding manufacturing, eCommerce, projects or several legal entities extends that. The largest factors are the number of processes, the state of your data and how much time your team can give the project. We give you a timeline with the roadmap and update it at every phase boundary.
Do we go live with everything at once?
Usually not. We recommend going live with the core apps first, because that is where the data flows connect, and adding further apps in later phases once the core is stable. For groups, roll out is typically entity by entity using the first as a template. A single big go live is possible when the business needs it, but it carries more risk and needs more preparation.
How much of our team’s time will the project need?
More than most people expect. A project lead needs at least two days a week. Each key user needs time for workshops, testing and training, which can add up to several days per module. We estimate these hours per role and per phase in the roadmap so that managers can plan for them.
Will you customise Odoo for us?
Where there is a clear business case, yes. Our default is to configure standard Odoo first, use existing modules second and write code last. Every customisation is documented with the reason it exists, because each one adds cost at every future upgrade.
How do you handle training?
Per module and per role, close to the point of use. Key users are trained as each module is configured and they in turn test it. End users are trained before go live with sessions, recordings and short written guides that you keep. We avoid a single large session a week before launch.
What happens after go live?
A hypercare period with daily contact for the first weeks, followed by handover to our managed service if you want ongoing support, or to your internal team with documentation and a knowledge base.
