What constitutes an ERP implementation "success"?

The question of ERP success is non-trivial to determine.

Simplistically, we could say a project is successful if it meet three criteria:

1. Delivered on-time
2. Delivered within budget
3. Meets original project expectation or plan

However, what about those projects that are meet the criteria yet provided no value to users? I've heard end users complain that an IT project served no business purpose, even though IT believed the project was a stunning success. In this situation, I do not believe the project should be considered a success. Just because a project proceeds from start to finish on time doesn't mean it serves a useful function for the company.

Then, there are projects where requirements evolved, adding substantial additional genuine business value, and therefore finished over-budget or late. In those cases, the project might be considered a great success. Sure, it was more expensive than planned, but it accomplished a tremendous amount for the organization.

Simplistic definitions of success or failure don't always work in this context. It's far better to have a clear picture of your business goals and anticipated budget, so you can adapt expectations as required. However, I am definitely not saying be undisciplined or lax in planning!

In the end, success or failure is determined by the consensus inside the organization. If everyone believes the project is successful, then it actually is.

I can imagine what you are asking, but have never seen it. Every successful ERP system implementation I have benn involved with delivered business improvement. I guess the one exception to that were implementations that were necessary because the older ERP would not run on current operating systems. We face that with the retirement of XP. But even then there were improvements relative to speed and security. If there is no business improvement their can be no ROI.

Peter, you say that "every SUCCESSFUL ERP system implementation" that you have been involved with has "delivered business improvement." (Emphasis added.) This raises three important questions:

1. What defines a "successful" ERP implementation?
2. How many UN-successful ERP implementations have you been involved with?
3. How many of the "successful" implementations actually provided METRICS before and AFTER? Or, was there just a general feeling of "business improvement" and the business was continuing to grow?

I'm not trying to be hard on you. I just want to understand your experience.

Thanks.

You know I don't know about calling it success. That word is completely based on the perspective of the integrator/business and the many other factors that would have been laid out in a proper implementation strategy.

I could only imagine that implementing an ERP in a situation that will net no immediate business improvement, is only being implemented to meet some form of certification requirement or long-term expansion strategy. No business improvements generally are met with no short-term ROI.

Michael:

You make a valid point. However, consider this: even the scenarios you paint as having "no immediate business improvement" can have a calculated ROI if executives and managers will take time to understand them and put rational numbers to their thinking.

1. Certification requirement case - The change in Throughput (T) would be how much T will we gain by adding this certification? Or, stated in the negative, how much T would be lose if we do NOT have this certification? Calculations for changes in OE (Operating Expenses) and I (Investment) should be self-evident.

2. Long-term expansion case - I would hope that a long-term expansion means an increase in T. If it does not, why would you do it? If it does, then sit down and figure out how much expansion in T there will be over the next year, two years, three years or five years and calculate it into your ROI formula along with your estimates for changes in OE and I.

This is not rocket science.

...

Michael:

One other comment about the subjectivity of "success." Yes, I have worked in the past with business owners in the highway, heavy and utility construction industry (for example), for whom "profit' was secondary to the satisfaction they got personally from just "handling" millions of dollars and from buying big yellow machines with big black tires.

However, for most for-profit enterprises, "success" is measured in making more money tomorrow than you are making today. If the implementation did not contribute directly and measurably to that improvement, then it may be measured by the IT staff as a "success," but for the stakeholders in the enterprise, it should not be counted as a "success" -- at least not in my book.

...

I think this statement sums up the whole discussion.

"...if executives and managers will take time to understand them and put rational numbers to their thinking."

It shouldn't surprise anyone here that many executives and managers don't take the time in the pre-phases of implementation (for whatever reason or another) to look at their numbers and understand their own metrics.

"This is not rocket science."
But it sure can look like an alien to the unsuspecting executive.

1. A satisfied Customer. - Both Internal and external
2. Reduction in cycle times
3. Improved Response to your end customers
4. Reduction in Inventories, Faster process flow

Michael Krigsman: You have hit the nail on the head, albeit obliquely. A "project" may be a success because all -- or virtually all -- associated with the project deem it to be "a success." It that "successful" project brings no measurable business benefit, then that is not a "project failure," it is a business management failure.

This distinction needs to be made because the executives that commission a project need to take responsibility of the monies they allocate to each improvement project. Those monies should bring measurable ROI -- and I believe there is a relatively simple way to calculate that ROI (see http://www.GeeWhiz2ROI.com articles).

CIOs, PMs and IT vendors should be held responsible for "project" success, but CFOs and CEOs should be held responsible for rationally selecting IT projects that deliver concrete ROI for the companies they manage. This also means that CIOs and IT vendors should refrain from trying to "sell", and CFOs and CEOs should refrain from "buying", IT projects on the nothing but "rule-of-thumb" or other meaningless estimates of ROI.

Agreed?

This is a really interesting and, I'd argue, controversial subject. In a way, given the horrible batting averages of most IT projects, success can be defined as a lack of failure.

To some extent, I tackled this subject in Why New Systems Fail.

I'm not going to rewrite that book here. Suffice it to say that not all projects can define success equally. There are many factors at play. An organization that believes that it will save $500,000/yr on administrative costs might not find "success" if it saves only $400,000/yr.

I will say this: we all know failure when we see it.

This is a really interesting and, I'd argue, controversial subject. In a way, given the horrible batting averages of most IT projects, success can be defined as a lack of failure.

To some extent, I tackled this subject in Why New Systems Fail.

http://www.philsimonsystems.com/books/why-new-systems-fail/

I'm not going to rewrite that book here. Suffice it to say that not all projects can define success equally. There are many factors at play. An organization that believes that it will save $500,000/yr on administrative costs might not find "success" if it saves only $400,000/yr.

I will say this: we all know failure when we see it.

I'm not sure I agree with you, Phil Simon. I rather concur with Mr. Krigsman (to paraphrase you both): We all know "success" when we see it; however, we might define it. We do NOT all know "failure" when we see it -- sometimes management is blind to it to the point of bringing down an entire division or firm through poor investments in "improvement" projects (IT or otherwise).

....