What is the Problem we are trying to solve?

What is the problem we are trying to solve? The problem of ERP project failure.

But what is “ERP project failure”, anyway? Ask that question and you’ll get a lot of answers – we’ll be discussing the most common answers quite soon – but we’ve come to prefer a simple (and, some would say, smart-alecky) one: ERP project failure is anything that, when we encounter it, makes us say “This ERP project has failed.” Like obscenity, it may be impossible to pin down precisely, but we know it when we see it. And, also like obscenity, it is often subjective: one person’s unacceptable outcome may be another’s minor irritation.

The whole subject has been surveyed many times. A typical report says that 68% of all attempted ERP implementations are “challenged” to some extent . “Challenged” runs the gamut from “the project put the company out of business” to “the system had to be thrown out” to “we are or were really bothered by how it turned out.”

What we’ve noticed is that every kind of failure can be expressed as an unmet expectation, as in “it didn’t happen the way we expected.” And that is significant because, very often, the critical unmet expectation is never explicitly stated, right up to the terrible day when it is seen to have been missed.

If we try to pin “critical expectation” down in a general way, we’d say something like “any outcome that will be immediately seen, as soon as it occurs and without further study or analysis, as obviously unacceptable.” Seen by whom, though? Seen by the people who get to decide whether the system is a success, a failure, or a struggling mess somewhere in between the two. We don’t get to decide who those people are in your company, but you should be able to figure it out.

Is this a commonplace view? Actually, no. Most people who study ERP failure start deeper into the details. A very high level summary of what surveys tend to find shows that “challenged” ERP projects fall into four rough categories:

The project is abandoned with nothing accomplished (24%)
The project is over budget.
The project is late.
The system is implemented with reduced functionality.

Symptoms of failure as reported by users are most commonly:

Inadequate system performance

Throughput (response time)
Capacity

System doesn’t match requirements

Missing reports/queries
Incorrect process/work flow
“It doesn’t do it our way”

Missing functionality
System is too unwieldy

Too many steps
Ungraceful process

Project was late
Project was over budget
Users have poor access to system information
There are data integrity and/or data accuracy problems
There were data conversion problems
The system was too difficult to implement

Too much demand on internal resources
“They want us to shut the business down for how long?”

“It just doesn’t work!” Or similar statements of abject despair.

Overwhelming number of problems
Couldn’t pass critical test(s)

When asked for the causes of these symptoms, users and implementers typically list the following (of course the wording varies from survey to survey):

The wrong software was selected (usually users).
The software was configured incorrectly (usually users).
The requirements/specs were incomplete or incorrect (usually implementers but users sometimes confess to this).
Scope creep.

Implementers: “They kept adding requirements.” This is the implementer’s universal first response to complaints about budget and schedule overrun.
Users: “Then they said, ‘Oh, you want it to work? That changes everything.’”

Inexperienced/inept implementers (users).
“They lied” (both). “They” may be a third party!
Lack of management commitment/support (both). This is the single most commonly cited general cause of failure, but often it is offered without an explanation of exactly what management should have done differently.
Lack of user skill.

Implementers: Many flavors (some unprintable), among them:

“They wouldn’t let us train them.”
“They have nobody who understands anything [in that department].”
“They refuse to change how they work.”
“We showed them over and over again and they just didn’t get it.”
“5,000 companies use this module every day but they say it just doesn’t work.”

Users: “We’re accountants/planners/buyers/etc, not IT people.”

Resistance from users (usually implementers but not always).
Buggy package (both!).
Implementation task just underestimated or oversold (users).

This is how these risks are reported, and it is in these terms that they are commonly discussed; but note that almost any commonly reported symptom could be the effect of almost any commonly reported cause! That is, any symptom picked at random – say, “Users have poor access to system information” – has at one time or another been perceived as the effect of any cause on the list. Meaning, among other things, that studying the list of symptoms before a project starts isn’t likely to do much to prevent them from occurring.

To restate the usual perceptions of failure in terms that can lead to actually preventing them, we need to take an entirely different view, one that looks at the problem of preventing failure as an exercise in

Eliciting critical expectations,
Restating them as requirements, and
Embedding them thoroughly into the project itself.

Standish International Group, 2009 Chaos Report