Late ERP projects have become almost a cliché. The usual explanation is technical: the software fell short, the consultant was inexperienced, the integration turned out harder than expected. What we see in the field is different. Most of the delay comes from processes that were never made explicit — long before anyone wrote a line of code.
Where the delay actually begins
An ERP rollout forces an organization to write down how it works. In most companies, this happens for the first time during that very project. Rules that "everyone knows" but nobody has documented only become visible when someone tries to turn them into a screen.
Two things surface at once: different departments describe the same process differently, and some decisions turn out to depend on a particular person. The project timeline, meanwhile, was usually agreed before any of this discovery took place.
Questions worth asking during analysis
In our experience, asking the following early removes a large share of the surprises that would otherwise appear months later:
- Who makes this decision? Every step in an approval chain needs an owner. "It depends" marks the exact spot where a workflow will later break.
- What data do they look at? If a decision rests on a report, that report must be producible in the system. If it rests on a spreadsheet someone corrects by hand, you first need to understand what that correction is.
- How often does the exception occur? Building custom logic for something that happens once a month makes the project both more expensive and slower. Measure it early.
- Is this step still necessary? Digitalization is not copying the current process onto a screen. Some controls that made sense on paper become redundant in a system.
Managing scope creep
Growing scope is not the problem; unmanaged scope is. New requirements emerging during analysis is normal — the organization is seeing its own processes more clearly as it goes.
What works is meeting every new request with one question: now, or after the first release? Queueing a request rather than rejecting it keeps both morale and the timeline intact. A system that hasn't gone live helps nobody; an incomplete system that works does.
Data migration is underestimated
The most consistently underestimated item is data migration. Data from the old system is usually inconsistent: the same customer exists under three names, stock codes changed over the years, balances were adjusted manually.
This cleanup looks technical but actually needs decisions from the business. A developer cannot know which record is correct. So migration should start in parallel with analysis, not be left to the end.
A practical checklist
- Don't commit to a timeline before discovery is finished.
- Name a single decision-maker for every process.
- Measure exceptions with numbers, not impressions.
- Start data cleanup on day one.
- Keep the first release small and go live early.
- Spread user training across development, not into the delivery week.
ERP projects are complex, but they are not unpredictable. Most of the delay is the bill for unanswered questions — and the cheapest time to ask them is at the beginning.