ERP projects: when the initial estimate becomes an untenable promise

The story often begins in a meeting room a few weeks before the contract is signed. Management has set go-live for 1 January, because the financial year starts that day and switching at the same time seems natural. The partner, competing with two others, submits a proposal that fits within the announced envelope. Nobody is really lying. Everyone simply keeps the most favorable assumption: clean data, available key users, requirements close to the Business Central standard.

Estimating an ERP project remains difficult. The cost depends on the state of the existing systems, the scale of business change, the availability of the teams and the organization's capacity to absorb change, variables that are mostly discovered along the way. An optimistic estimate does more than produce an overrun. It creates pressure to shorten whatever looks negotiable: testing, data migration and training. Those are precisely the phases that decide the quality of the go-live. Among the seven main risks of an ERP project, this one has a peculiarity: it is often in place before the first workshop.

Manifestations and symptoms in the field

The first signs appear during the design workshops. The fit-gap analysis reveals more development than planned, and consultants discover special cases nobody mentioned during pre-sales: pricing by delivery zone, progress billing, a three-level purchase approval process. Each discovery is modest. Their sum is not.

Halfway through, the days consumed exceed actual progress. The steering committee receives a first re-estimate, which it rarely approves in full. The preferred options are to cut scope quietly or to ask the team to "catch up". Decisions take longer, since every additional resource must now be justified line by line.

Key users, who often combine their usual job with the project, work evenings and weekends. Testing cycles are compressed, and data migration goes from three planned rehearsals to a single one. Then comes the postponement of go-live, rarely announced all at once. It slips by a month, then by a quarter, and each announcement erodes the project's credibility with the departments a little more.

Financial, operational and human impact

The final overrun often far exceeds the first one announced, but it is hard to see. Part of it is diluted in the overtime of internal teams, which appears in no project budget. Another part resurfaces after go-live as time-and-materials days to fix what was delivered too fast. An honest comparison between the approved budget and the full cost is rarely made.

The schedule has its own effects. A go-live pushed from January to April means migrating balances mid-year, keeping the old system running longer and sometimes extending a maintenance contract that was supposed to end. The improvements the business was waiting for stay on hold, since everything depends on the switchover.

The human cost is heavier still. An exhausted team loses its best people when it needs them most: a key user who resigns three months before go-live takes the knowledge of their area's setup with them. Employees who have heard several successive dates end up believing none of them, including the right one.

Root cause analysis and governance errors

The first cause is the optimism of the launch. Management sees the expected benefits, the partner wants to win the deal, and the estimate is built on a scope described in a few pages. Business Central has a reputation as an ERP that is quick to deploy. That holds for a scope close to the standard, and becomes misleading as soon as specific requirements pile up.

Effort is then poorly distributed. Setup and development are costed precisely, data migration, testing, training and post-go-live support much less so. Yet these activities account for a significant share of the total effort, and they rely largely on the client's teams, whose time is almost never budgeted.

The contract plays its part too. Under a fixed price, the partner has an interest in freezing a narrow scope, and every gap becomes a change order nobody dares to raise. Under time and materials, the initial budget is only an estimate, and the client discovers reality invoice by invoice. Finally, many budgets contain no contingency reserve at all. The slightest unexpected event then becomes a crisis, with no margin to absorb it.

Action plan, preventive and corrective measures

The estimate should first rest on serious scoping. A few days of workshops before signing, focused on the truly critical processes and on a sample of data, are worth more than a proposal written from a generic requirements document. This scoping also measures the gap with the Business Central standard, process by process.

The budget should then be broken down into work packages fine enough to be tracked: setup by area, each development, each migration cycle, each testing campaign, training and post-go-live support. The time of internal teams appears explicitly, with names and availability rates. A key user available 20% of the time cannot carry three testing cycles.

A contingency reserve, visible and managed by the steering committee, completes the arrangement. An envelope of around 15 to 20% of the budget is common practice. Its use is decided in committee, which keeps it from funding nice-to-have requests.

Finally, the go-live date is open to discussion. Nothing requires switching on 1 January: a mid-year go-live, with balances migrated at a month end, is common and often less risky than a switchover stacked on top of the year-end close. A re-estimate at each milestone, presented without window dressing, makes it possible to announce a delay early rather than suffer it late.

Conclusion

An underestimated budget is almost never an accident. It results from a tacit agreement between management that wants a reassuring figure and a partner that wants to sign, and both pay the price later. A company that accepts an optimistic estimate ends up settling the difference another way, with its teams' time, the quality of its data and the trust of its employees.

The main responsibility lies with the client, because the client lives with the result. In practice, that means demanding scoping before signing, costing its own time as a project resource, including a contingency reserve in the approved budget and treating the go-live date as a variable. A project that goes live a quarter later with reliable data costs less than one that holds the date and is repaired for a year.

The next risk follows directly from this one. When the schedule tightens, data migration is often the first casualty.