It’s Not the Software ! Despite the headlines, human error is most responsible for ERP project failures. By John Ziegler I have been involved with packaged software implementations for the past 16 years. In all that time, I have never experienced a business application software package that didn’t work. That’s not to say they have been "bug" free, but bugs get caught and fixed. The software companies that stay in business fix their program errors fairly quickly. If they didn’t, they would not be in business today. I cannot think of a software company that went out of business because their application didn’t work. They usually close down because of internal management problems, corporate financial problems, decisions to sell out to larger firms, or decisions to not migrate to newer technology. Therefore, I contend it’s not the software that causes all the problems you read and hear about. Somehow, I guess, by human nature it’s just easier to blame the software company and their product. At least they seem to be the ones that receive all the bad press. Remember, it’s the job of the software sales and marketing organization to convince you that their product is exactly what you are looking for, weather it is or not. Once your company has made the decision to purchase a new application or an upgrade for your business systems, the last thing you want to do is create a monstrous, time-consuming and expensive project that only has less than a 50 percent chance for success. That’s why you must educate yourself and do your homework. One of the reasons many companies delay their decision to start a software project is because of the bad press and stories of recent project failures. Just last week, I talked to an investor who said his company made a decision not to acquire a business because of their massive cost overrun and ongoing expense of implementing a well-known ERP software system. You have to ask yourself, "What’s going on?" Post mortem After being involved in 18 full lifecycle implementations, several post implementation analysis reviews and a handful of clean-up engagements, I’ve found that the majority has been very successful, but some have not. In those that failed, the software package seemed to be the problem, but no one would really admit that it was the real problem. Why? I have asked that questions to everyone from shop floor supervisors to executive board members. These interviews have been mostly conducted as a "post mortem", or some time after the implementation is over. The overwhelming response is mixture of answers. One employee replied, "It wasn’t really the software. It does work, I admit, it was us, we didn’t know what we doing …but don’t tell the boss!" Another blamed their integrator. "The consulting firm I relied on didn’t work out. They just couldn’t deliver what they promised." Still others saw mistakes along the way. "We modified the software to meet our old business processes. Looking back now, we should have just used it as it was designed." There are many other reasons why these software projects go bad, these are the more popular ones. I have never heard anyone say the software product didn’t work and really mean it. It’s always the way they implemented and tried to use it. Just because the software seems to be getting bad press, don’t think it’s always the software. Every software package has its horror stories; no one system is immune. Education There are three main reasons why large software implementations have major time and cost overruns or even fail: * the wrong software is purchased for the business. * the software is modified too much or changed to replicate bad business processes. * the wrong implementation consultants were chosen. These problems can only be overcome with education. Educate yourself with a detailed requirements analysis and plan. Educate yourself with a Fit/Gap analysis of the standard capabilities within the software. Finally, learn the methods and capabilities of the implementation consultants.

Written by :

johnziegler