Why this matters. ERP projects rarely fail because of software — they fail through sponsor turnover, scope creep, and missing escalation discipline in the steering committee. The Bitkom guide on project failure names structural early-phase choices, not technology, as the dominant cause of IT-project failure.
When this approach fits — and when it does not
This approach fits when:
-
Executive leadership treats the ERP project as an organisational transformation, not an IT rollout;
-
The steering committee is willing to close phase gates, not only open them;
-
Project leadership and data migration have named owners inside the business.
This approach does not fit when:
-
The implementation partner also supplies the supposedly independent project leader;
-
Top-management sponsor turnover is on the horizon and the project sits politically unprotected;
-
Hypercare after go-live has not been planned and funded.
How to structure an ERP project — the four phases
A defensible ERP project moves through four phases with explicit gate decisions. The SCOReX methodology structures these phases so that each gate decision is documented, escalable, and reversible.
-
Phase 1 — Preparation and sponsorship: business objectives in writing, sponsor named, steering committee staffed. Output: project charter with escalation path and stop criteria.
-
Phase 2 — Blueprint and process accountability: target processes described by process owner, data-migration RACI agreed. Output: blueprint with named business accountability.
-
Phase 3 — Build with independent project leadership: the independent ERP project leadership negotiates scope changes against the implementation partner and documents every deviation. Output: integrated test plan with acceptance criteria.
-
Phase 4 — Cutover and hypercare: data migration tested, go-live decision against hard criteria, hypercare team funded for at least ninety days. Output: stable operations without an escalation wave.
A common mistake and how to avoid it
A machine-building company in southern Germany with around 320 employees lost its executive sponsor to a corporate move nine months into the project. The successor had not set up the project and had no political stake in it. Scope creep from the implementation partner went unchallenged, the steering committee kept meeting but made no stop decision. Sixteen months later the project cost 2.3 million more than planned.
In practice, three measures protect against this pattern: an independent project leader who does not work for the implementation partner; a steering committee with documented stop criteria (see also our top 7 ERP selection mistakes); and a written sponsorship-handover agreement covering the case where a sponsor leaves.
What to do next
If you want to test how politically stable your ERP project currently is:
-
Name the sponsor and two deputies in writing, with succession rules.
-
Document three stop criteria that, when triggered, formally pause the project at the next steering-committee meeting.
-
Check whether your project leadership sits with the implementation partner — if it does, you now know the risk.
When an ERP project starts drifting, a structured second view often prevents the next gate from being approved by default. We can run that scoping conversation with you in twenty minutes.
FAQ
Four to seven phases, depending on the methodology. What matters is not the count but the gate decisions defined between phases — and the willingness to close a gate when criteria are not met.
An independent project leader. When the implementation partner also supplies the project leadership, the political counterweight in scope negotiations and escalations is missing. This is the most common structural design flaw.
Six to eighteen months from kick-off to stable operations after hypercare. Shorter timelines require a clearly named sponsor, documented processes, and a steering committee able to make decisions.
