Many companies declare their ERP project a failure as soon as go-live dates have been postponed several times and the budget has long since been exceeded. According to a study by Horváth In SAP S/4HANA transformations, 60 percent of projects exceed their budget and schedule (Horváth, 03/2025). Those who are familiar with the typical patterns of such a crisis can take corrective action earlier, rather than waiting until they see the remaining budget list to react.
An ERP project is considered a failure if the budget, schedule, or planned process quality consistently go off track. According to Horváth (03/2025), this applies to 60 percent of SAP transformations; on average, they take 30 percent longer than planned. Those who address the common causes recognizes the problem and can take corrective action before termination becomes the only option.
The Most Common Reasons Why an ERP Project Has Failed
Horváth has examined SAP S/4HANA transformations and has reached a clear conclusion: 60 percent of projects exceed their budget and schedule; on average, they take 30 percent longer than originally planned (Horváth, 03/2025). Even in cases where the project ultimately goes live, there are often still some unresolved issues remaining.
Despite exceeding budgets and deadlines, the companies also report quality issues during ongoing operations.
Horváth, March 2025
One reason for this lies in the scope of the projects themselves. According to the same study, 78 percent of the companies surveyed say that too many issues are being crammed into the transformation at once (Horváth, 03/2025). An ERP project that is supposed to address the organizational structure, reporting, and several legacy issues in parallel with the system migration loses the focus that a program of this size requires.
A second finding illustrates just how far-reaching this effect is. The Computer Week reports, citing an ISG report, that only 18 percent of companies actually redesign their processes during migration, while 49 percent carry over the old processes largely unchanged (Computerwoche, 02/2026). Those who use the new software the same way they used the old one forfeit a large portion of the actual benefits while still paying the full project costs.
| Cause | Impact on the Project |
|---|---|
| Scope Expansion | Additional topics are overshadowing the original focus of the project |
| Poor Project Management | Risks and delays become apparent late rather than early |
| An Underestimated Testing Phase | Errors don't become apparent until shortly before or after the go-live |
| Underestimated Data Migration | Legacy data does not fit the new data model; rework ties up capacity |
| Unresolved Decisions | Unresolved issues are piling up and delaying subsequent work packages |
These five causes rarely occur in isolation. An overly large project scope complicates project management; an overburdened project management team keeps postponing decisions; and a lack of decisions, in turn, causes the testing phase to shrink. Anyone who addresses only one of these causes while the others remain unaddressed usually only postpones the actual problem by a few weeks. This article describes how to limit a growing project scope from the very beginning Stopping Scope Creep: How Projects Can Regain Control of Their Scope.
What Steps Can Help Overcome the ERP Crisis
The first step is to take a sober look at the current situation, regardless of how the project has been organized so far. People who report on their own progress tend to portray it as more optimistic than it actually is, especially when their own position depends on a positive outcome. No one can be personally blamed for this, but it doesn’t change the fact that the numbers must add up in the end. An external perspective on the budget, test coverage, and pending decisions lays the foundation on which meaningful further planning can even take place. Without this step, any further planning will be based on a set of numbers that already lags behind reality.
This is followed by a clear distinction between what is mandatory and what is optional. Topics that were not originally part of the project should be moved back to a separate initiative, even if that is inconvenient and disappoints stakeholders. A project that is reduced back to its original core regains manageability.
Testing and data migration phases then require their own realistic timeline rather than a residual buffer at the end of the project. If you run migration processes through in their entirety for the first time only shortly before go-live, you’ll discover data issues too late to resolve them in an orderly manner.
Finally, pending decisions need a name and a deadline. A decision-making bottleneck can rarely be resolved by holding more meetings; in most cases, it requires effective project governance with a single person who has the authority to definitively resolve a pending issue. Sometimes, the way out of a crisis involves changing the managing partner. This article explains how this can be implemented in a legally and technically sound manner. Changing Service Providers Mid-Project: Legal and Technical Considerations.
Not every ERP project in crisis can be saved. If the original system choice no longer aligns with the business model, or if the remaining costs of continuing the project exceed the costs of starting over, an orderly termination is the more cost-effective decision, however uncomfortable it may seem at the moment.
Assessing the Status of Your Own ERP Project
An external assessment of the budget, schedule, and risks can usually be scheduled within a few days.
Frequently Asked Questions
How can you tell early on that an ERP project has failed?
Early warning signs include repeatedly postponed milestones, a growing list of unresolved technical issues, and testing phases that are systematically shortened in the schedule as soon as things get tight. An increasing number of workarounds in day-to-day project work also suggests that the original plan no longer aligns with reality. Another sign can be found in the tone of status reports. When numbers are replaced by vague phrasing, it’s usually the very number that no one wants to report that’s missing.
Renegotiate or walk away?
That depends on the cause. If the problem stems from scope, resources, or the timeline, it’s usually possible to renegotiate—for example, by reducing the scope of features or postponing the go-live date. If the problem stems from the system decision itself or from a service provider lacking the necessary experience, renegotiating often only leads to a delayed recurrence of the same problem. Both approaches involve the same calculation: namely, what it will cost to continue working as is from today onward, and what a fresh start would cost.
Who should conduct the analysis?
A person or team with no responsibility for the project’s progress to date can provide a more independent assessment. Someone who has been leading their own project for months rarely has the perspective needed to openly acknowledge their own misjudgments—even with the best of intentions. External reviewers also bring a comparative perspective from other projects, which helps put the scope and urgency of the situation into context. Internally, this role can only be filled if the reviewer can demonstrably show no personal stake in the outcome—which is rarely the case in practice.
An ERP project in crisis needs someone to take the reins and make the remaining decisions. To this end, torck provides its own development and project teams in Maxhütte-Haidhof, Vienna, and Rabat, and manages the technical aspects of the turnaround itself, rather than simply delivering yet another report. The contracting party is the German company torck GmbH. Anyone who needs a second opinion on their own ERP project can do so in a Initial Consultation .
German 
English 
French