Why ERP projects overrun, and how to prevent it

It is usually the same few causes, and they are all avoidable.

Nothing was written down at the start

The single biggest cause. Without a signed scope document, every conversation can become a requirement. Six months in, nobody can agree what was promised, because nothing was ever recorded.

Fix: write the scope before configuration starts, list what is explicitly excluded, and get it signed. The exclusion list matters more than the inclusion list.

Requirements arrive continuously

Once users see the system, they think of things. This is healthy — it means they are engaged. It becomes fatal when every new idea goes straight into the build with no assessment and no price.

Fix: a change request process from day one. Every new request gets a number, an estimate and a decision. Even the ones you do for free. The log itself slows the flow, because the client can see the total.

The client's data is not ready

Teams underestimate this enormously. Cleaning thirty thousand item codes is weeks of work, and it is the client's work, not the implementer's.

Fix: start data cleaning in week one, with named owners and dates. Track it visibly.

No freeze before testing

If requirements keep arriving during user testing, testing never finishes, because the thing being tested keeps changing.

Fix: a written scope freeze date. After it, everything is phase two.

Nobody closed anything

Projects rarely fail loudly. They just never end — no acceptance, no sign-off, no moment where someone says this part is done.

Fix: sign off in pieces. Each module, each department, as it completes. A project made of closed sections finishes. One that is open everywhere does not.

None of this is about working faster. It is about closing things.