What does a failed ERP project cost?

The costs of a failed ERP project arise on three levels: directly in the project (top-ups, external days, licences paid for but unused), in the organisation (key people tied up for months, other initiatives standing still, trust used up) and in the future (the second attempt starts with worse data, tired teams and higher pressure to justify). Of these, the project budget is regularly the smallest item.

What does the damage really consist of?

The visible level is the money: extended consultant contracts, additional licensing, a duplicated system landscape in prolonged parallel operation. These items appear on invoices and can be added up.

More expensive is the invisible level: the best people from the business and IT are stuck in the project instead of the business, process improvements and other initiatives wait, and with every postponed go-live the organisation's willingness to believe the next date sinks. This loss of trust is the item that makes the second attempt most expensive.

And getting to that point is no isolated case: budget and schedule overruns are the rule rather than the exception in large technology programmes. The eight structural patterns behind them are described in the article Why ERP projects fail.

Why is the damage so often underestimated?

Because the largest part is incurred outside the project budget and never appears in any project calculation. The controller sees the consultant invoice, but not the sales director who spends six months checking master data instead of developing customers.

Add to that the logic of sunk costs: the more has been invested, the harder it is to stop, even though the money already spent should play no role in the decision. Green status reports reinforce this, because they report progress against a plan that never contained the real problems. Which signals are more reliable than the report is shown in the answer on the five warning signs.

When is countersteering cheaper than letting it run?

Almost always when the cause is structural and keeps working: a scope that was never really agreed, decisions nobody takes, a data foundation nobody has clarified. In this situation a top-up without corrected steering buys no solution, only time until the next overrun. What to do concretely in this situation is covered in ERP project over budget: what now?

The rule of thumb from project rescue: the best moment to countersteer is the moment the project is honestly measured for the first time. Every later moment is more expensive, because the cost of intervention rises and the window shrinks.

What does the second attempt cost, and when is it worth it?

An orderly second attempt is regularly cheaper than years of muddling through, but only under one condition: the causes of the first failure are named and fixed before new money flows. Otherwise the second attempt repeats the first, only with less trust and worse data. How to set up a restart cleanly is described in The second attempt after a failed ERP project.

How do you protect the budget from the start?

With the three things whose absence causes the damage: a governance with real decision moments, a scope agreed before the start, and a data foundation clarified before automation. Whoever wants to measure a running project against these gets an honest assessment of where it stands with a senior-led assessment , before the next tranche flows.

The bigger picture behind this question: ERP implementation: the overview.