How does the second attempt after a failed ERP project succeed?

A second attempt succeeds in three steps: first, an honest diagnosis of why the first attempt failed, named in causes rather than culprits. Second, an inventory of what remains usable: data, process documentation, training knowledge. Third, a restart with changed steering, a smaller first step and a progress measure that does not consist of status reports. Whoever only renews the timeline repeats the project.

Why second attempts fail differently from first ones

The first attempt fails on causes, the second on mortgages. The budget is depleted, the management's patience used up, and the team has learned that announcements cost nothing. A second attempt therefore never starts at zero but in the red, and that is exactly what plans overlook that are simply a new version of the old project plan.

Added to this is a silent time pressure: the business has moved on. Processes have changed, data has aged, requirements from back then no longer hold. The longer ago the first attempt, the less its concept works as a template.

The good news stands against this: most abandoned projects have fixable causes. Whether a failed ERP project can be rescuedis almost always decided by steering, ownership and data quality, not by the software.

Diagnosis first, then the restart

Before every restart stands the question of what the first attempt really failed on. The in-house answer is often "the partner" or "the system", and both are convenient because they point at nobody in your own house. A reliable diagnosis checks four fields: were processes and requirements clarified? Did the data foundation hold? Was there steering with decision-making authority? And did the implementation partner have the right task, or the wrong one under wrong specifications?

For this diagnosis an outside view pays off, because those involved in the first attempt are a party to it. A second opinion from outside delivers the findings in days instead of months and answers the most delicate question along the way: whether the current partner should be part of the second attempt.

The diagnosis includes an inventory of what is usable. Cleaned master data, documented processes, trained key users and even the first attempt's list of defects are paid-for capital. It would be expensive to throw them out in frustration.

The restart plan in five steps

1. Put the findings in writing: causes, what is usable, what is non-negotiable. One page, signed by the management.
2. Re-staff the steering: one person with decision-making authority on your side, one escalation path, a progress measure from the system instead of from slides.
3. Data foundation before functions: first bring the data up to the level the first attempt failed to deliver, then talk about functions.
4. A small first step: one delimited area live, with a real month-end close. The second attempt needs proof early, not a promise.
5. Settle the partner question in an orderly way: stay, re-tender or change the partner mid-project. Each of the three answers is legitimate, but only as a result of the findings.

Go-live rescue: when the project tips over just before launch

A special case of the second attempt begins just before the first: the go-live date is set, but migration tests fail, open items grow faster than they close, and nobody wants to say the word postponement. Here the rule is: a postponed launch costs weeks, a failed one costs the trust of the whole company and often the project.

The decision needs hard criteria instead of confidence: a complete dress rehearsal of the data migration, a rehearsed daily operation for the core processes, named owners for the first week and a fallback line in case things get serious. If these points are not demonstrably met, postponement is not a defeat but steering. If the launch tips over anyway, the same sequence applies as for the big restart: stabilise, findings, then start up again in an orderly way.

How to recognise a second attempt that will hold

By three features, before the first function is even live: the findings of the first attempt exist in writing and were not moderated away. The progress measure comes from the system, for instance from migration runs and test coverage, not from traffic-light slides. And there is a person on your side who is allowed to say no, to the scope, to the date and to the partner.

If one of these is missing, the second attempt is the first one with a new date. The warning signs are the same as the first time, they just arrive faster. This is exactly the steering we take on, senior-led: governance and delivery management, with steering on your side and Business Central as home.