Six lessons learned from six failed software implementations.

We’ve been working with a customer on a RapidResponse implementation. The customer is delighted to witness a successful implementation after six previous failed attempts with other solutions. That’s right, six attempts – three different solutions, each tried twice. Imagine the time and money lost. Here are the lessons learned from that experience – each applicable to both vendors and their customers:

• Long implementations are a recipe for disaster! You can expect management changes certainly within a two year time frame. If a project is not delivering value when management changes, it will likely be scrapped!
• The absolute key to managing duration is managing scope and expectations. Repeat after me…. “that can be done in phase two”.
• Don’t underestimate a user’s need to understand HOW a solution works. Users need visibility to see both what the solution recommends and why it made those recommendations. Without an understanding of the decision making path, users are more likely to lose confidence and reject the results.
• Planning optimizers are very difficult to keep “fed” with current data and to accommodate changes in products, production processes and the supply chain network. The broader the scope in terms of the planning horizon and the range for optimization, the harder it is to keep it producing useful results. In very many cases, the entire approach to using optimization may need to be re-thought.
• Real systems require high quality data. If the data is not great to start, tools and processes must be part of the solution to improve and maintain quality. A single, agreed-to, set of data is an absolute must.
• Going live doesn’t equal success. Despite many solutions “going live”, if they don’t deliver real value, they will inevitably be abandoned or scrapped and processes will returned to the previous status quo (in supply chain management, that usually means Excel)

While much of the above is not new, it’s amazing to me how often these pitfalls rear their ugly heads. Better implementation processes and practices can certainly help, but at the end of the day, if the solutions’ technology paradigm is inconsistent with the ultimate needs/wants of the user, then no “best practice” is going to rectify that.