Essay
The product, the integrator and the team take the blame. The decision that determined the outcome was made months earlier, and was never recorded as a decision at all.
The brief
- The question
- Why do ERP implementations fail before the software is chosen?
- The answer
- Because the outcome is largely settled by three definitions the organisation has never written down: what an approval actually commits, when a job is finished, and which entity carries the cost. None of them is a technology question. All three are answered during the implementation whether or not anyone senior takes part — and if nobody does, the configuration answers them, permanently and invisibly.
- Use this when
- Before a selection begins, while the shortlist does not yet exist. Also eighteen months in, when the customisation list is growing as a long tail of small, individually reasonable items — and when an organisation with no incumbent system is being told that makes it a clean slate.
- The decision
- Settle the three definitions on paper before a demo, and name the person with the authority to make a definition stick. The test: when the system and the organisation disagree about when a job is finished, who decides? A named person means the technology choice becomes a genuine technology choice. A committee, a process or an uncomfortable pause means the sequencing problem is still there, and no product on the shortlist will solve it.
By the time an ERP programme is visibly in trouble there is usually a consensus about the cause. The product was wrong. The integrator was weak. The business did not engage. Each of these is sometimes true, and all of them share a convenient property: they place the failure after the point at which anyone senior had to decide anything.
Author synthesis
The less comfortable account is that the outcome was largely settled before the shortlist existed. Not by a bad decision, but by a decision nobody recorded as one.
What is actually being decided
Every enterprise system forces a choice between two things. Either the organisation changes how it works to fit the system, or the system is bent to fit how the organisation already works. Both are legitimate. Both are expensive in different currencies. Only one of them is usually chosen deliberately.
The difficulty is that the second option assumes something that is rarely true: that the organisation knows how it works. Most do not, in the specific sense that matters here. They have practices, precedents and people who remember, but they have not written down the handful of definitions on which an enterprise system depends. A company in that position has not chosen to bend the system to its operating model. It has deferred the choice, and deferral is itself a choice with a delivery date.
Three definitions, on paper, before a demo
Framework
There are three questions that every implementation eventually asks, and that almost no organisation has answered before it starts. They look administrative. They are not.
What does an approval mean? Not who signs, which is usually documented somewhere, but what the signature commits. Whether approval of a requisition is approval of the spend, the supplier, the budget line, or merely the intent to proceed. Organisations run for years on the ambiguity because the ambiguity is useful: it lets people move without being fully accountable. A system removes it on day one, and whichever meaning the configuration encodes becomes the meaning, for everyone, permanently.
When is a job finished? When the technician leaves, when the requester confirms, when the invoice clears, or when the asset returns to service. Each answer produces a different backlog, a different cost profile and a different picture of performance. Every one of them can be defended. What cannot be defended is four departments each holding a different answer while reporting into the same number.
Which entity carries the cost? In a single company this is dull. In a group, a joint venture, or a development with mixed ownership it is the question that determines whether the financial statements mean anything. It is also the question most likely to be left to the implementation team, who will answer it in a configuration screen because someone has to.
None of these is a technology question. All three will be answered during the implementation whether or not anyone senior participates.
Three questions. Two moments.
Every implementation answers the same three definitions. The only variable is who answers them, and when.
- What does an approval commit?
- When is a job finished?
- Which entity carries the cost?
Answered before
By the business, on paper, before a demo.
- A named person can make a definition stick.
- The programme has a governance spine.
- The technology choice becomes a genuine technology choice.
Answered during
By the configuration, by whoever is in the room that afternoon, under schedule pressure.
- The answer is set permanently and invisibly.
- A long tail of small, individually reasonable customisations.
- Adoption stalls against a definition nobody agreed to.
If you do not answer them, the configuration will
This is the mechanism, and it is worth stating plainly because it is where the cost is created. An implementation surfaces every question the business has been avoiding. If nobody senior answers, the answer gets set in configuration, by whoever is in the room that afternoon, usually under schedule pressure, and it is set permanently and invisibly. Nobody experiences it as a decision. It arrives later as a reporting anomaly, an argument about whose number is right, or a customisation request that seems small and is not.
The asymmetry matters. Making these definitions explicit before selection costs weeks of uncomfortable meetings. Unwinding them after go-live costs a change programme, because by then they are embedded in configuration, in habit, and in the numbers the board has already seen.
The absence of a legacy system is not a clean slate
Counterpoint
It is tempting to assume that an organisation with no incumbent system has an advantage. No migration, no entrenched process, no sunk licence cost. In practice the opposite is closer to the truth, and it is one of the more reliable patterns I have seen.
An organisation that has never run an enterprise system has never been forced to agree on its definitions. It has functioned on reconciliation: finance holds one version, procurement another, operations a third, and people close the gap by talking to each other. That works, at a cost nobody books. When the first system arrives, the implementation becomes the first occasion in the company’s history on which anyone has asked what an approval means. That argument is not a delay before the project. It is the project.
Budget for it explicitly, or it will be taken out of the schedule that was reserved for something else.
A diagnostic that takes an afternoon
Framework
Before looking at the technology estate, I look at how a decision travels. Take one real, recent, medium-sized decision and trace four things about it: who raised it, who could have stopped it, how long it took, and where it is written down.
The fourth is the one that gives the answer. If a decision of consequence lives in a chat thread, in someone’s memory, or in an email nobody can find, then the organisation does not yet have an operating model that a system can be aligned to. It has a set of working relationships, which is a different thing, and which does not survive being encoded.
This tells you more about whether an implementation will succeed than any systems audit, and it can be done before a single vendor is contacted.
What it looks like eighteen months later
Field observation
Programmes that skipped this stage tend to present the same way. The customisation list grows in a particular manner: not a few large items agreed in advance, but a long accumulating tail of small ones, each individually reasonable. Read that list closely and it is an archaeology of the decisions that were never made. Each entry is a place where the configuration answered a question the business had not, and the business is now paying to change the answer.
Adoption stalls in the same pattern. People are not resisting the software. They are working around a definition they never agreed to and cannot appeal, because there is no forum in which to appeal it. The system is blamed for a governance vacuum that predates it.
The question that surfaces it early
If you are about to start, one question is worth more than a requirements workshop:
When the system and the organisation disagree about when a job is finished, who decides?
If the answer is a named person with the authority to make the definition stick, the programme has a governance spine and the technology choice becomes a genuine technology choice. If the answer is a committee, a process, or an uncomfortable pause, the sequencing problem is still there and no product on the shortlist will solve it.
This is also why feature comparison is the last question rather than the first. Which system suits a company of this size, in this sector, with this complexity, this budget, this timeline, this operating model, and this appetite for owning it afterwards — the feature grid answers the least important item on that list, and it is the only one most buyers are given help with, because the people producing selection material are overwhelmingly the people selling the systems.
If the decision is still open, that is the work. How I take it on, and on what terms, is set out under advisory.