The ERP project is over budget. What now?

When the budget is in the red, the first step is not the next top-up but a scope freeze. Freeze the scope, run an honest cost review, and establish the cause before you put more money into the same pattern. Otherwise you are funding the next overrun along with it. The order is what matters: as long as new requirements keep flowing in, there is no honest way to calculate. A short freeze stops the creeping growth and creates a stable basis for the review. This is not a project stop, it is a deliberate pause on the accelerator until there is clarity. In practice a freeze does not mean standstill either: work in progress is finished, new requirements are collected rather than worked in. That costs nobody any progress and gives you a number that still holds two weeks later.

Why does the scope freeze come first?

A budget overrun is a symptom, not a coincidence. Before you decide on additional budget, you need clarity on where the money actually goes and why. The sequence decides.

As long as new requirements keep flowing in, you cannot calculate honestly. A short freeze stops the creeping growth and creates a stable basis for the review. This is not a project stop, but a deliberate pause on the accelerator until there is clarity.

In practice a freeze does not mean standstill: work in progress gets finished, new requirements get collected instead of built in. That costs nobody any progress and gives you a figure that still holds two weeks later.

The freeze has a second effect that is often underestimated: the collected list shows in black and white how much arrives in what time. That figure is the real finding, because it says more about the steering than any cost analysis.

What does the honest cost review deliver?

Separate cleanly what actually happened:

• What was included in the original scope?
• What was added unnoticed via change requests?
• What was simply estimated too optimistically?

The typical cost drivers are rarely the licence. They are underestimated data migration, interfaces that are small projects of their own, and scope that has grown via change requests without anyone seeing the total.

The three questions look banal and are not. In practice hardly any project can answer the second one, because change requests were approved individually and never totalled. That total is precisely the figure nobody knows and the one that explains the difference.

Take half a day for it with the original proposal, the change-request list and the actual invoicing. It takes no more than that, and afterwards both sides are discussing figures rather than impressions.

Why does the question of causes come only after that?

The question of cause is the most important. A budget overruns for two reasons: either the estimate was unrealistic, or no one keeps the scope in check. For the former, honest replanning helps, for the latter, only a governance that sets priorities bindingly. More budget without this clarification finances the same problem a second time.

Budget overruns are the rule rather than the exception in large IT projects. Why, is shown in the article Why ERP projects fail: the reason is rarely the software, but underestimated effort in exactly these blocks. That is no reason for reassurance, but for sobriety: the next top-up only carries if it sits on corrected steering . Control stays on your side, with Business Central as home.

Before you release the next top-up: let a first conversation reveal the cost blocks and the cause, so the additional budget holds this time.