You are about to launch an ERP project.
And as often happens, the danger does not arrive “out of nowhere” at month 8.
In reality, many ERP projects signal their derailment… before the kick-off even takes place.
Here is a list of very concrete red flags, organized by theme, to spot projects that will end in: budget overruns, schedule slippage, demotivated teams… and a return to Excel.
1 - Scoping & Perimeter
Red flag #1 — “We’ll define the scope during the project”
Translation: no clear perimeter, no exclusions, no assumptions.
➡️ Direct risk: scope creep, workshops become a battlefield, and the quote becomes “a baseline.”
Red flag #2 — No measurable objectives
Examples of measurable objectives:
- reduce the monthly close from 10 days to 5 days
- cut the invoicing error rate in half
- reduce stockouts
- ensure reliable product master data
➡️ Without KPIs, you will never know if the project “succeeds”… so everything becomes debatable.
Red flag #3 — Too much “custom” from the start
If everything is “special” from day 1, without challenging the standard, it is a bad sign.
➡️ You are buying an ERP… and rebuilding a bespoke application (more expensive, longer, more fragile).
Red flag #4 — External dependencies are not listed
CRM, e-commerce, WMS, BI, POS systems, PIM…
If these are not clearly listed and prioritized, you will discover the problems at the worst possible time.
➡️ Interfaces are often the #1 source of “surprises.”
2 - Quote & Budget
Red flag #5 — Lump-sum quote with no detail
No detailed deliverables, no assumptions, no exclusions.
➡️ You are not comparing 3 proposals. You are comparing 3 slogans.
Red flag #6 — The price looks “too good” because everything is optional
Data, training, testing, support… everything is optional, so the displayed price is artificial.
➡️ The project is then paid for through change orders.
Red flag #7 — No run cost estimate (TCO ignored)
Support, SLAs, upgrades, infrastructure, licenses, monitoring…
If no one discusses the cost “after go-live,” you are flying blind.
➡️ The project may look profitable… and become a money pit in operations.
Red flag #8 — Change Requests are not defined
If change management is not defined (process, costing, arbitration), it is a trap.
➡️ Every “small adjustment” becomes a negotiation.
3 - Planning & Methodology
Red flag #9 — Aggressive timeline with no buffers, no milestones, no client-side workload
A “tight” timeline can exist… but without:
- safety buffers
- acceptance milestones
- client-side workload (business team availability)
➡️ It is often a sales promise, not a realistic plan.
Red flag #10 — Tunnel effect
No regular demos, no incremental deliveries.
➡️ You discover reality too late, when everything is already “configured.”
Red flag #11 — Vague governance
Who arbitrates? Who decides? When?
Without a RACI, steering committees, decision rules… it devolves into chaos.
➡️ Decisions pile up, the project slows down, conflicts take root.
Red flag #12 — “We’ll do acceptance testing at the end”
If there is no test strategy based on business scenarios from the start…
➡️ You “test” when there is no time left. And you go live with risk.
4 - Integrator Team
Red flag #13 — Impossible to know the actual team
No names, no roles, no seniority levels, no allocation percentages.
➡️ Risk: you are buying a senior… and you receive a junior team.
Red flag #14 — Seniors sell then disappear
A classic move.
➡️ The project loses its leadership and its ability to make decisions.
Red flag #15 — Turnover implicitly announced
“We’ll see who’s available,” “it will depend on staffing.”
➡️ Every consultant change = rework + loss of context.
Red flag #16 — No backup plan
No identified replacement if a key consultant leaves.
➡️ The project can come to a dead stop for several weeks.
5 - Data (the #1 Source of Overruns)
Red flag #17 — “We’ll just import a CSV”
Data migration is never “just an import.”
➡️ It involves mapping, cleansing, business rules, testing, and validation.
Red flag #18 — No “data readiness”
Quality, master data, duplicates, historical records, business rules.
➡️ If the data is bad, the ERP will be bad. Period.
Red flag #19 — No iterative migrations / cutover rehearsals
Without rehearsals, the cutover becomes a gamble.
➡️ And a gamble in production is very costly.
Red flag #20 — Unclear data responsibilities
Who cleanses? Who validates? Who decides on a rule?
➡️ Without an owner, data becomes a “no man’s land” issue.
6 - Integrations & IT
Red flag #21 — Interfaces underestimated (“it’s simple”)
No mapping, no responsibilities, no known limitations…
➡️ “It’s simple” is often the beginning of a future incident.
Red flag #22 — No monitoring / logs / alerting
Without monitoring, you will not know when something breaks.
➡️ And you will learn about incidents… from the users.
Red flag #23 — Security / permissions / GDPR addressed late
If permissions, access, audit trails, and GDPR compliance arrive at the end of the project…
➡️ You redo part of the configuration.
Red flag #24 — Custom connector with no planned maintenance
A custom connector is a product that needs to be maintained.
➡️ If that is not planned, it becomes technical debt.
7 - Adoption & Change Management
Red flag #25 — Training reduced to a demo
No role-based learning paths, no key users, no documentation.
➡️ Low adoption, passive resistance, workarounds.
Red flag #26 — No post go-live support (hypercare)
Without hypercare, the first few days become a crisis.
➡️ This is when the ERP “earns love”… or hatred.
Red flag #27 — “IT-only” project
If business teams are not involved, ground-level reality is missing.
➡️ You deliver an ERP that is “technically OK” but unusable.
Red flag #28 — “Excel just in case”
If no one plans the switchover and the decommissioning of legacy tools…
➡️ You keep two systems running, and nobody trusts either one.
8 - Contractual
Red flag #29 — Deliverables not listed in black and white
Specs, configuration, documentation, testing, training…
If there is no list, there is no commitment.
➡️ And you cannot formally accept deliveries.
Red flag #30 — No reversibility / ownership / data access
Who owns the developments? Who has access to the source code? How do you exit?
➡️ Without this, you are locked in.
Red flag #31 — SLAs / support not defined
Response times, severity levels, channels, costs.
➡️ The day something breaks… you discover the rules.
Conclusion
An ERP project that derails is not inevitable.
But if you let these red flags slide before the kick-off, you pay the price later: in budget, in delays, and in trust.
The simple rule:
If it is not written, it is not true.
If it is not proven, it is not under control.
