An ERP project overruns its budget when effort and duration are significantly above the plan without a technical defect being the cause. In practice this is the rule, not the exception: analyses, including from McKinsey, put the share of programmes that overrun budget or time at 65 to 80 percent. The reason is almost never the system. It lies in governance and in decisions that are made too late or not at all.
Is it true that most ERP projects fail?
Yes, if you define "fail" honestly. Few projects are cancelled outright. But the large majority exceed budget and timeline, deliver less value than promised, or produce a data foundation after go-live that no one trusts. From a CFO's point of view that is a failure, even if the system runs in the end.
The important distinction is between a system that runs and a system that holds. A system can run technically clean and still not support the business, because the rules beneath it are contradictory. This is exactly where the costs arise that never appear in the business case.
Is it the technology?
No, only in the rarest cases. Microsoft Dynamics 365 Business Central, SAP and comparable systems work. The software is mature, the implementation methods are known. When a project overruns, we almost always find the cause one level deeper: in the way decisions are made, and in the quality of the data those decisions are based on.
That is good news. Technical problems are expensive but solvable. The real causes are solvable too, and before the budget starts to flow. You just have to name them.
What is the real cause?
Governance and decision quality. In over 25 years of international projects we see the same three patterns again and again.
Pattern 1: The decision vacuum
A process question is on the table and no one is authorised to decide it. So it is deferred. The deferred decision becomes a workaround, the workaround a special path that others copy. Three months later an open question has become a structural problem. Governance is not a document, it is the answer to the question "who decides now".
Pattern 2: Multiple master data truths
Sales, finance and logistics each hold their own view of the same customer, the same item, the same order. Each plausible on its own. Together a set of reports no one trusts. No change of system solves this, because the problem is not in the system but in the question of which definition applies and who owns it.
Pattern 3: A new system on old processes
The most expensive mistake is to cast the old world one-to-one into a new tool. Then the company pays for modernity and gets its old bottlenecks, prettier. Transformation means starting with the processes and the competitive advantage, not with the surface.
What does the data foundation have to do with it?
Everything. Software interfaces change, the data foundation stays. Rules, processes and master data are the foundation every system runs on, and on which every AI will decide in future. An AI agent in Business Central, whether for incoming invoices or order entry, makes its decisions on the basis of your data. Poor master data leads to poor decisions, only faster and at greater scale.
That is why the data foundation is the real lever against overruns. Getting it right before touching the system prevents the three patterns above and, at the same time, prepares you for any change of technology.
What does a project that overruns cost?
More than the obvious budget overrun. On top of the direct costs come the more expensive indirect ones: management time that flows into escalations instead of running the programme, deferred efficiency gains and an organisation that, after a difficult project, dreads the next one. At an industrial client, a previously manual order entry only became automatable through a clean data foundation, not through the technology. In the reverse order we would have got expensively automated errors by the minute.
How do you prevent overruns?
With an honest assessment before the investment and with control rather than advice during the project. Concretely, that means three things.
First, name the gaps before the budget flows. A structured assessment checks along four dimensions where the risk lies: strategy, governance, delivery and readiness. It makes process errors visible while they are still cheap to fix, and delivers the diagnosis for a running project in a few days.
Second, establish clear ownership. For every central question it must be clear who decides and who owns the data. That closes the decision vacuum before it forms.
Third, take control where others advise. A recommendation in a slide deck changes no project. What counts is someone who stays in the room when the uncomfortable decision is due, and makes it with the customer. This is exactly where it is decided whether a project holds.
The first step: know where you stand
Before you invest in the next system, the next project or the next AI, an honest assessment is worth it. Let us look at how sound your data foundation is and where your first step lies in a conversation, senior-led and with Business Central as home.
Frequently asked questions
Why do ERP projects most commonly fail?
Not on the technology, but on governance and on decisions that are made too late or not at all. The three most common patterns are a decision vacuum, multiple contradictory master data truths, and a new system on old processes.
How high is the overrun rate for ERP projects?
Cross-industry analyses, including from McKinsey, put the share of ERP programmes that overrun budget or time at 65 to 80 percent.
What is more important, the system or the data foundation?
The data foundation. Software interfaces change, the rules and processes underneath stay. They are the foundation every system and every AI runs on. Getting them right prepares you for any change of technology.
How do I find out whether my project is at risk?
With an honest assessment. An assessment examines a running project along four dimensions and, in a few days, delivers a robust diagnosis of which decisions are due.
