Finding the root cause of ERP implementation failures

ERP implementation failures, caused more often than not by decision-making delays, are a major risk. Delays in decision-making are cumulative, they slow progress and gradually derail the ERP project.

That's part of the argument made in a paper, partially titled "Why Large Projects Fail," by Jim Johnson and Hans Mulder, who are both on the faculty of the University of Antwerp Management School. Johnson is also chair of the Standish Group, a research organization that studies software projects.

The paper looks at a major software project involving the Number Portability Administration Center, an example that sets the stage for a larger discussion. Very large software projects, costing over $10 million, face a failure rate as high as 41%, according to the paper's data. Only 4% can claim success; the rest are "challenged," meaning they are running overbudget or overtime.

Johnson further discussed project delays in this Q&A. His responses were edited for clarity and length.

Are ERP implementation failures common, and if so, why?

Jim Johnson: Most projects don't die from starvation. They die from indigestion. What ERP, especially, is trying to change is the whole landscape. It is trying to force-feed all these features, functions and changes on the organization down people's throats. That's where the real challenge is.

If you have a $1 million project, you have a thousand decisions to make. If you have a $100 million project, you have 100,000 decisions to make. Those are hard to swallow. They become bottlenecks. At some point, the decision latency becomes so long and convoluted you just choke on it.

What is decision latency?

Johnson: It's the time between when an issue is raised and when the decision is made -- that's called the interval. The longer the interval, the longer the decision latency. You measure latency by the length of the interval.

If decisions are delayed, what happens?

Johnson: People go off and do other things. They get demoralized.

Aren't some of these decisions leading to ERP implementation failures relatively minor? For instance, a configuration decision? Is that the kind of thing that can slow down a project?

Johnson: Yes -- you need to distribute the decision-making to the right level. We see this, especially, in government and highly regulated and controlled organizations. They don't give power to the people that actually know what they are doing, so those decisions get moved up [to people] that don't have the time to make the decisions, or they don't have enough information, or they're not equipped to make that decision. They need to move that decision down to people that can make a good decision and let them have the freedom to make those decisions.

How do you best avoid decision latency?

Johnson: The first thing you do is you become aware of it. We call it the 'root cause of all project performance problems.' It causes things to get screwed up. Secondly, you need to distribute decisions down to people that can make decisions and not be punitive if they make a mistake. The interval is more valuable than the quality of your decision. If you make a mistake, you reverse it; you fix it. You want to benchmark decision latency -- let's look at how long it takes for us to make a decision.

Is it costlier to delay a decision than it is to make a mistake in implementation?

Johnson: Yes.

What's the best way to manage a project?

Johnson: You want to have a competent executive sponsor. Committees are useless. The executive sponsor should have complete authority -- unfettered responsibility. He or she is totally responsible for the success of the project.

One of the things your paper discusses is downward trajectory of projects. Is that easy to recognize, and what typically is the response?

Working code is the real test of progress. Everything else is just window dressing.

Johnson: Usually, the response is the opposite of what should happen. You see projects that are green and green and green, and suddenly, they are red. No one wants to stand up and say the project is going south. It's an emotional thing. What you need to see is evidence of delivery. Working code is the real test of progress. Everything else is just window dressing.

The initial response is to cover up project delays?

Johnson: In the more Agile-type delivery, they don't. They are actually empowered to say things are going wrong.

You need to have a competent team that you can trust, that's talented but also has good emotional maturity. The relationship of the team is so important. When we see high-performance teams, we see people that like to work together. They have a good working rapport.

A lot of companies bring on systems integrators. How does that work in this model?

Johnson: The problem -- and this is my own opinion -- is the integrator is not working for the best interests of the client. They want to extend the time. They want to set high decision latency because that's billable hours.

How can you bring in a systems integrator and have a successful project?

Johnson: [One thing to require] is a firm deliverable every two weeks so there is no hiding. You want to give them freedom to deliver, but you want them to deliver.