7 Warning Signs of a Failing ERP Project

1. The scope exists only in emails and memories

Ask two people what the first release includes. If their answers differ on entities, workflows, reports or integrations, the project does not have a shared baseline. A long proposal is not sufficient if acceptance remains vague. “Inventory included” can mean basic stock records to one person and barcode receiving, transfers and valuation reconciliation to another.

Recovery action: produce a short workflow-based scope with inclusions, exclusions and acceptance examples. Have the business owner and implementer approve the same version. Use the budgeting guide to separate configuration, migration, development and support rather than arguing over an undifferentiated total.

2. Nobody can make a binding business decision

A project can have many active participants and still have no owner. Decisions circulate between finance, operations and management while the vendor keeps configuring around assumptions. Watch for repeated meetings about the same unresolved workflow, contradictory approvals or a critical question with no deadline and no accountable decision-maker.

Recovery action: name a business sponsor with authority to resolve conflicts and assign process owners beneath that role. Keep a decision log with question, options, impact, owner and due date. Escalate overdue decisions explicitly. The implementer can explain system consequences, but should not silently choose the business policy simply to keep development moving.

3. Progress reports replace end-to-end demonstrations

Screens may look finished while the handoffs between them fail. Ask a normal user to complete a transaction from start to finish, including the accounting or reporting consequence. Test an exception such as a return or partial delivery. If the demonstration depends on an administrator quietly correcting data between steps, the workflow has not yet been accepted.

Recovery action: create a small acceptance pack using representative data and real roles. Record expected outcome, observed result and defect owner. Retest after corrections. An Odoo implementation should be judged by these working scenarios, not the number of menus enabled or training slides prepared.

4. Data problems are postponed until the final import

Unreconciled balances, duplicate suppliers and missing product units are not minor formatting tasks. They can change configuration and invalidate testing. A warning sign is a plan that schedules data work after all workflows are declared complete, or assumes the client will deliver a perfect spreadsheet without an agreed owner and validation process.

Recovery action: import a representative sample immediately into a test environment and reconcile it with finance. Maintain a reject list and assign business owners to uncertain records. Follow the migration playbook for mapping, rehearsals and sign-off. Do not close an exception by inventing a value just to make the import pass.

5. Training is a presentation in the final week

Users need to practise decisions and mistakes, not simply watch the implementer click through a perfect example. Late training can conceal a process that staff do not understand or cannot execute with their permissions. If no one has processed a return, corrected an input error or closed a shift, a completed attendance sheet is weak evidence of readiness.

Recovery action: train by role on realistic scenarios, then observe users performing them independently. Record gaps and update concise job instructions. Include supervisors who will answer questions after launch. Schedule time for retraining when workflows change instead of assuming that one early demonstration remains valid throughout the project.

6. Small changes accumulate without impact decisions

One extra field can be harmless; a new approval, integration or accounting rule may affect several processes. Watch for an expanding informal list that nobody has estimated or prioritised. The problem is not that requirements evolve. It is that the launch commitment remains unchanged while the work and risk keep growing.

Recovery action: record each change with business value, effort, dependencies and acceptance impact. Decide whether it belongs before launch or in a later release. Keep defect fixes distinct from new scope. Review approved changes against the budget and timeline so both parties understand what was traded off rather than discovering the cost at the final invoice.

7. The launch plan has no rehearsal or recovery decision

A date on a calendar is not a cutover plan. Ask who freezes data, takes backups, imports final records, reconciles balances and authorises users to begin. If a critical check fails, the team must know who can pause the launch and how operations continue. “We will work through the night” is not a substitute for that agreement.

Recovery action: rehearse the sequence, record timings and define go/no-go criteria and rollback limits. Test restore capability in a safe environment. Confirm the support rota and escalation route for the first days. If the project is already in trouble, an Odoo support review should first establish the actual configuration and evidence before promising a rescue date.

Turn the warning signs into a weekly recovery review

Use one page containing the seven risks, current evidence, owner and next decision date. Close an item when its evidence is accepted, not when someone says it is almost done. As an external implementation reference, Odoo’s published implementation methodology provides useful project-role context; adapt your controls to the actual scope and contract rather than copying a timetable blindly.

A checklist to use in your next review