Roughly 40% of ERP projects underdeliver against their original scope, budget, or timeline — a figure industry analyses have repeated for years. What that statistic hides: almost none of them fail suddenly. They drift, and everyone feels it long before anyone says it.
I take on Odoo rescue work — stalled builds, broken go-lives, partners who disappeared. These are the signs I see over and over, usually months before the project is officially “in trouble.”
The seven signs
1. Go-live has moved more than twice. One slip is planning. Two is a pattern. By the third postponement, the team has usually stopped believing the date — and behaves accordingly.
2. Your team is keeping the old system alive “just in case.” Parallel spreadsheets and a still-subscribed legacy tool aren’t caution; they’re a no-confidence vote from the people closest to the work.
3. Nobody can name the owner on the vendor side. If your questions bounce between a salesperson, a project manager, and rotating developers, no one owns your outcome. ERP projects don’t survive ownership vacuums.
4. Every requirement becomes a customization. Odoo covers a remarkable amount of standard business process. When the answer to everything is custom code, you’re either working with developers who don’t know the standard product — or nobody challenged the requirements. Both end the same way: an unupgradeable system.
5. Reports don’t match reality. Users check the system, then verify by phone. The moment data trust breaks, adoption follows it down, and “the ERP is wrong” becomes office truth — deserved or not.
6. Training keeps being postponed. Teams delay training when they quietly know the system isn’t ready. It’s one of the most reliable leading indicators I know.
7. The invoices keep coming, the demos don’t. Steady billing against vague progress (“backend work”) for more than a sprint or two means the plan and reality have parted ways.
If three or more sound familiar
First: stop new development. Adding features to an unstable foundation converts money into deeper problems. A pause costs nothing compared to building more of the wrong thing.
Second: get an independent read. Not a sales audit from a competing agency hunting for a rebuild — an honest technical and functional assessment: what’s salvageable, what isn’t, what go-live actually requires. In my rescue work this usually takes days, not weeks, and most systems have far more salvageable than the frustrated team believes.
Third: re-sequence around one workflow. Failing projects try to fix everything at once. Working rescues pick the single most painful business flow — often invoicing or inventory — and make it genuinely reliable. Trust returns one working workflow at a time.
What’s usually actually broken
After enough of these, patterns emerge: the gap is rarely raw code quality alone. It’s requirements that were never truly understood, business workflows forced into the wrong modules, too much customization where configuration existed, and no one on the project who spoke both business and Odoo fluently.
That’s also why rescues succeed: the diagnosis is usually simpler than the mess suggests — it just requires someone accountable for the outcome, not the hours.
If this article felt uncomfortably specific, an honest assessment costs a conversation: book a rescue assessment call or read about how I run ERP rescues.