ERP projects rarely fail at the start. They fail around month seven, when the initial enthusiasm has faded and the difficult modules arrive. Here is what that failure looks like and how to avoid it.
ERP implementations almost never collapse in month one. Month one is the honeymoon: the demo went well, the kickoff was energetic, everyone can see the destination. The failure happens later, and it is remarkably consistent about when.
The shape of the problem
The first modules delivered are usually the easy ones — a customer master, a basic invoice, a report. They land well and confidence builds. Then the project reaches the modules that touch how the business really operates: production scheduling with its dozen undocumented exceptions, the pricing logic that lives in a sales manager's head, the approval process that formally requires three signatures and informally requires one.
These modules take longer than estimated, because the estimate was built on the assumption that the process was as documented. Timelines slip. The sponsor who championed the project starts fielding questions. Enthusiasm becomes tolerance, and tolerance becomes resistance.
Why the estimate was wrong
The estimate was not wrong because the estimator was careless. It was wrong because discovery captured the process as management understands it rather than as staff perform it. Those two are almost never identical, and the gap is where the difficult modules live.
The process that is documented is the process that was designed. The process that runs is the process that survived contact with reality.
What actually helps
Sequence the hard modules early
It is tempting to build the easy modules first because they demonstrate progress. Resist it. Build one genuinely difficult module in the first eight weeks. You will learn more about the real complexity of the engagement from that one module than from three easy ones, and you will learn it while there is still time to adjust.
Watch the work, do not just ask about it
Sit with the person doing the job for a day. You will see the sticky note on the monitor, the second spreadsheet, the phone call that unblocks the exception. None of that appears in a requirements workshop.
Define what done means, in numbers
"Improve inventory accuracy" is not a target. "Cycle count variance below two percent" is. Agree the number before the build starts and measure the baseline, so that month seven has a fact to argue with rather than an impression.
Deliver value in increments that stand alone
Each phase should be useful even if the next phase never happens. That constraint forces honest sequencing and gives the sponsor something concrete to defend when the questions start.
The uncomfortable conclusion
Most ERP failures are not technology failures. The software usually works. What fails is the assumption that an organisation can absorb a large operating change on a fixed timeline while continuing to run at full capacity. Plan for that reality and month seven is uneventful.