Why Most ERP Programmes Fail Before They Begin

The governance decisions made in the first 90 days determine outcomes more than any technology choice.

Twelve months into an ERP programme, the RAG status is amber — it has been amber for three months — and nobody is quite sure who is authorised to turn it red. The programme director spends forty percent of her time drafting position papers for decisions that should have been made in week four. The programme has not failed. Not technically. But the conditions for failure were established before a single line of configuration was written. They were established in the governance model — or rather, in the absence of one.

The Governance Gap

Most organisations approach ERP governance as a compliance exercise. They appoint a steering committee because the methodology says so, schedule monthly meetings, and circulate a standard agenda. Then, when something substantive happens — a scope dispute, a budget overrun, an integration dependency nobody properly scoped — the committee discovers it has no real mandate, no decision rights, and no mechanism for resolving conflict quickly.

This is the governance gap: the distance between the structure that exists on paper and the one capable of running a programme. At inception, leadership attention is on vendor selection and budget approval. Governance feels administrative. The foundational questions — who makes which decisions, at what threshold, within what timeframe — go unasked until a crisis makes them unavoidable.

Three Structural Failure Modes

The first is a steering committee that lacks real authority. This happens when the committee is composed of the right titles but not the right people — executives who attend for fifteen minutes, or who delegate upward in a loop that produces delay rather than resolution. The steering committee must contain individuals who can commit resources, override functional objections, and absorb political risk on behalf of the programme. If nobody in the room can do those things, the committee is decorative.

The second is a programme sponsor who is too junior. The sponsor is not the person who signs the purchase order. They are the person who, when Finance says the chart of accounts is unacceptable and IT says the timeline is impossible, stands up and says: this is how we will proceed. That requires genuine organisational authority — the kind that comes from seniority and a track record of getting things done. A VP-level sponsor in a programme reshaping a business’s operating model is structurally insufficient.

The third is undefined decision rights. Every ERP programme generates a continuous stream of decisions: scope inclusions, configuration choices, change request approvals. In well-governed programmes, each category has a named owner, a defined process, and a target resolution time. In most programmes, decision rights are implicitly understood — until two parties disagree, and a dispute must be escalated to a committee that meets monthly and has no tiebreaker. Decisions that could be resolved in a day take three weeks.

“Every week of governance ambiguity costs more than the week it occupies. It mortgages the decision-making capacity of the programme long after the ambiguity is resolved — because the culture of deferral it creates is far harder to undo than any single missed deadline.”

The 90-Day Rule

There is a practical window at the start of every ERP programme — roughly ninety days — during which governance structures can be established with relatively low friction. After that, structural choices calcify. Three things must be in place within that window: a decision log, an escalation ladder, and a change control framework.

The decision log is a live record of every significant programme decision, who made it, and what the implications are. It creates accountability, preserves institutional memory across personnel changes, and accelerates future decisions. The escalation ladder defines in writing — naming individuals rather than roles — the path a decision takes when it cannot be resolved at the working level, including a default-forward rule so the ladder does not become a parking lot. Change control establishes the programme’s scope and budget as a governed asset, not a fluid negotiation: every change request goes through a defined process and receives a decision from a named authority.

What Good Governance Looks Like in Practice

The difference between an advisor who adds genuine value at programme inception and one who does not is largely a matter of what questions they ask in the first two weeks. A less experienced advisor focuses on the technical architecture and the resourcing plan. An experienced one asks the governance questions first: who has authority to approve a budget variance above five percent? What happens when Finance and Operations disagree on a configuration decision?

Well-governed ERP programmes have a recognisable quality: decisions get made, at the right level, by the right people, within a predictable timeframe. The programme team spends its energy on delivery rather than managing upward. The consultants are configuring and testing. The programme director is removing obstacles, not writing escalation memos for decisions that should have been delegated months ago. That condition does not require a sophisticated governance framework. It requires clarity, authority, and discipline applied early — before the programme has built up enough velocity to make structural gaps catastrophic.

Jacob C. Krogsgaard-Søndberg is the founder of Axcelerate Advisory, a Copenhagen-based consultancy specialising in ERP programme governance and digital transformation for mid-market and enterprise organisations.