Why ERP projects fail — real reasons, not stated ones

The stated reason a project failed is almost always that the system did not suit the company.

Occasionally that is true. In the large majority of cases the product was capable of what was asked of it, and something else broke — usually something decided in a meeting room months before anyone logged in.

That is the useful part. Each of the seven causes below announces itself long before go-live, and anyone who recognises the sign is acting while there is still time to act.

The seven, and what gives each one away

The cause	The early sign
Nobody owns the project	The meetings are attended by people who cannot decide
Scope expands without a decision	Every session ends with new requests and no price
The data was never cleansed	Dates slip “until we get the files ready”
Customising instead of changing the work	“The system works this way” is met with “make it work our way”
Training on buttons rather than on the cycle	The user performs the step and cannot say why
One big-bang launch	Every module in one wave, on one date
No measure of success	Nobody can state what would make this a successful project

Four of the seven are purely management decisions with no software content at all.

One: the owner

The difference between a project with an owner and one without shows up at the first genuine conflict — one department wants something and another wants its opposite.

Without an owner the decision goes to deferral, and deferral has a default: the new system becomes a faithful copy of the existing disorder.

The owner is not the IT manager. It is somebody from operations with the authority to change how the work is done. Anyone without that authority does not own the project whatever the org chart says.

Two: scope that expands without a decision

Scope does not expand in a leap. It expands through small requests, each entirely reasonable on its own, none of them large enough to argue about.

One rule, announced in the first session, handles it: every new request is written down, estimated in time and cost, and signed — or deferred until after go-live.

Which of the three happens matters far less than the rule that nothing enters without one of them.

Three: the data

This is the single largest cause of delay and the least visible in any set of minutes, because it does not look like a problem until the load date arrives.

It is set out in full in data migration. The short version is that cleansing needs no software and no vendor, so a company that waits for the implementation partner to arrive before starting has bought a delay it did not have to pay for.

Four: customising instead of changing the work

The rule is not that customisation is wrong. Some of it is a genuine competitive necessity.

The rule is that every request gets one question asked of it: is this way of working an advantage for us, or a habit we inherited from a limitation of the old system?

Most fall into the second category. And every unnecessary customisation is paid for twice — once when it is written, and again at every upgrade for the life of the system. The second cost is the one that never appears in the budget.

Five: training

The difference between training that works and training that does not is not the number of hours. It is what was taught.

Someone trained on a sequence of clicks collapses at the first deviation — a return, a partial receipt, an error that needs correcting. Someone trained on the cycle knows where they are and why, and can therefore handle the case nobody trained them on.

The test takes thirty seconds: ask the user to explain what happens in the system after they press the button. Anyone who cannot was not trained. They were made to memorise.

Six: the big-bang launch

It looks cheaper on paper. Its actual effect is that a defect in any one module stops the entire launch.

Two waves instead: the essentials first, then the rest after two successfully closed months. Which modules belong in which wave is in ERP modules.

Seven: no measure of success

The question that exposes it: what would make this project a success a year from now?

The usual answer — “that the system works” — is not a measure. Nobody can prove or disprove it, so the verdict stays an impression and the outcome gets judged by the mood of the last meeting.

Measures that do work are written before the project starts and taken today: how long the month-end close takes, what proportion of invoices need correcting, the stock count variance, and the elapsed time from order to delivery. A company that records those four before the project has a comparison. A company that starts measuring afterwards has a number with nothing to compare it to.

What the seven have in common

Every one of them is a decision taken before the first screen is opened.

That is the encouraging part. A project failing for technical reasons needs a miracle. A project failing for these reasons needs four written decisions: an owner by name, a scope rule, a start date for data cleansing, and four measures taken today.

What to do today

• Write down the name of the project owner, and confirm they can change how the work is done rather than only describe it.
• Announce the scope rule in the first session, in writing.
• Start cleansing your data before anything else.
• Take the four measures today and keep them as a dated sheet of paper.

Where to go from here

Cause three is covered in data migration and cause six in ERP modules. Exposing a promise before you sign for it is in reading a demo, and the transition itself is in go-live night.

All four measures are read out of the cycles: procurement, order to cash, inventory and the ledger and the close. The reading order is on the learn ERP page, and each product’s limits are in the systems comparison.