An ERP project is a noble undertaking: it brings order to processes, ensures data reliability, and prepares the company for growth. On paper, everyone is in favor. In real life, the ERP is also a revealer: it highlights the gray areas, the habits, and the famous: “yes, but we do it differently” (a phrase officially classified as having a “high potential for planning derailment”).
The good news: ERP projects often succeed for the same reasons. The less good news: they also derail... for equally repetitive reasons. So let's keep it simple, concrete, and actionable — with a little smile, because otherwise we might cry..
Why an ERP project rarely fails because of the software
Sometimes the tool is blamed: "the ERP is not suitable." In reality, most difficulties stem from very human factors: governance (who decides?), pace (are we making consistent progress?), availability (do we really have time?), and clarity of objectives (where are we going?).
An ERP is like a score: even the best one won’t have music if the orchestra doesn’t rehearse together. And if the drummer only shows up every other Tuesday, you get a novel concept: administrative jazz.
The 5 key success factors: from the slide to reality
A General Management that is involved (not just "aware")
An ERP touches the foundations: sales, purchases, inventory, accounting, production, service... So:it's a company project, not an “IT” project.
The involvement of top management is crucial for:
giving a clear priority to the project,
arbitrating when departments disagree,
avoiding the “we want everything” effect (and thus getting nothing),
securing resources and team availability.
The right level of involvement:
an identified sponsor,
regular steering points,
a capacity for quick arbitration.
Without this, the project moves forward... but with the handbrake on.
A single point of contact with a real business vision
You need a person (or a duo) who carries the business vision and centralizes decisions: internal project manager, transformation manager, cross-functional reference, Product Owner…
Their role is not to “be everywhere,” but to ensure:
overall flow consistency,
clear prioritization,
quick validations,
a common language between business and integrator.
Without a single point of contact, you often get:
validations from 10 people,
contradictory feedback,
decisions that change depending on the interlocutor,
and a lot of rework.
Translation: the ERP becomes a layered cake. It's rich... but no one asked for that for breakfast.
A project team available (a project at 5% progresses at 5%... but does not cost at 5%)
This is the crux of the matter. An ERP requires workshops, validations, tests, data migrations, training, and change management.
If key users and business references are only available "when they can", the project suffers a very costly phenomenon:stop-and-go progress. We think we save time by "going with the flow". In reality, we pay an invisible tax:the restart tax.
At Auguria, we systematically create reports... but that is not enough
Reports are essential: they clarify and secure. But a report tellswhat was said. However, an ERP mainly needs us to keepwhat has been decided, why, andwhat it implies afterwards.
Without rhythm, even very good reports are not enough to prevent the loss of context.
Why the lack of availability costs much more
We waste time "reconnecting".
When the project is interrupted regularly, each restart involves recontextualization, re-reading of reports, reminders of decisions, re-explanations. This time adds no value... but it repeats.
Decisions come too late: we wait or we move forward "at random".
An ERP progresses at the speed of business arbitrations (rules, exceptions, validations). Without availability, the integrator waits or moves forward on assumptions — then has to go back. In one case, we pay for the wait, in the other, we pay for the correction. Often both.
We do and undo (and end up paying twice).
Late validations lead to adjustments in settings, touch-ups, retesting, and sometimes retraining. Rework is one of the biggest cost overruns.
User testing becomes chaotic.
Without availability, anomalies accumulate, corrections come in bursts, production becomes stressful, and the schedule deteriorates.
Data recovery deteriorates.
Without business time to clean and validate, we import 'dirty' data and correct it later — which costs more and disrupts operations.
Clear and formalized objectives (otherwise, it’s just 'installing an ERP').
'Implementing an ERP' is not an objective, it’s a means.
An ERP project should be guided by a few simple, understandable, and measurable objectives, for example:
reduce billing time,
reliable stock and reduce discrepancies,
standardize the purchasing cycle,
reduce data re-entry,
improve reporting (D+3 instead of D+15),
accelerate order processing.
Why it’s vital: it allows prioritization, avoids the piling up of non-essential requests, and keeps a course when decisions need to be made.
An ambitious but realistic schedule (the ERP hates marathons without water).
A good ERP schedule is neither a Sunday stroll nor a suicidal sprint.
It must include:
internal workload (workshops, validations, tests),
business constraints (activity peaks, closures),
decision milestones,
regular deliverables.
The risk of a planning timeline that is too long: the project drags on, teams disengage, and decisions become diluted.
The point of focus that changes everything: regular breaks cause loss of continuity.
When an ERP project experiences 'stop & go', it loses its rhythm, memory, and momentum. And above all, it takes a significant risk:information loss.
A month without working on a project is costly.
Let's be clear: a month without activity is not 'neutral'. It’s an expensive restart (recontextualization, revalidation), topics that reopen, decisions that contradict each other, and rework that appears 'as if by magic'. (The magic here is mainly in the invoice.)
The risk of information loss: real and dangerous.
Loss of context: we forget why a decision was made.
Untracked implicit decisions: 'okay, we’ll do it this way'... then no one remembers.
Absences/turnover: a key person changes, a manager leaves, and part of the project disappears with them.
Reopening topics: due to lack of documentation, we discuss again, delay, and redo.
Consequence: inconsistencies, delays, rework... and stress at Go-live.
How to secure success (simple tips)
To avoid the 'dotted line' project, here are some very effective practices:
Stable rhythm: even if light, but continuous (workshops + validations + progress each week).
Decision log: who decided what, when, why (and impacts).
Prioritized backlog: what is important now vs later.
Frequent deliverables: validate something every 2–3 weeks.
Planned availability: reserved time in calendars, not "when we can."
Conclusion: a successful ERP is a matter of governance and rhythm.
The key factors are simple:
an involved executive management,
a single point of contact with business vision,
an available project team,
clear objectives,
an ambitious but realistic schedule,
and a rhythm without repeated interruptions.
The message to remember:an ERP project with little availability does not just slow down. It costs more, because it generates waiting, rework, chaotic testing, degraded data recovery... and a high risk of information loss.
If you want to stack the odds in your favor, the best investment is not an "extra function." It is a structured, rhythmic project, supported by the company.