Why ERP Implementations Fail: A Litigator's Perspective
Much ink has been spilled dissecting the root causes of the perennially high failure rate for ERP implementations and attempting to isolate the factors that send these projects off the rails. Despite the attention–and the billions of dollars paid annually to ERP consulting firms–it’s all too often the case that ERP projects fail to meet management’s expectations as to cost, timeline and functionality, let alone deliver the forecasted ROI and other efficiencies that drive ERP initiatives in the first place. That said, compared to some ERP train wrecks, it’s fair to characterize ballooning budgets, missed deadlines and limited functionality as par for the ERP course. As any number of unfortunate CIOs know only too well, “worst case” ERP scenarios involve projects that are so badly botched they can pose an existential threat to the companies.
When an implementation goes awry, CIOs and other executives are often shocked by their system integrator’s abrupt about-face. The same consulting firm that, during the sales cycle, touted itself as a “trusted implementation partner” reveals a different side when things go south, minimizing its own role as a mere bit player while blaming the client for the problems. This Jekyll and Hyde act can be profoundly frustrating for CIOs, who find themselves fending off attacks by their systems integrator for inadequate oversight, failing to define requirements, demanding too much customization, and so on.
Symbiotic relationships between ERP software providers and consulting firms can create compromised incentives and conflicts of interests that prejudice the client
Having litigated dozens of ERP implementation failure cases, we have seen this scenario play out time and again, with a remarkable degree of similarity from case to case. We have also had the opportunity to dive into the facts behind failed implementations with an extraordinary level of depth and access–the kind of access that is only afforded by the litigation discovery process. In our experience, the primary causes of ERP implementation failure include the following.
Root Causes of Failed Implementations
You Did Not Get the “A” Team. The primary reason implementations fail is not because the client resists change or lacks executive engagement or doesn’t know how to use the new system–it’s because the consultants had no idea what they were doing. While top firms might have some talented consultants on staff, that doesn’t necessarily mean they’ll be assigned to your project. This can pose serious project risk, because many firms, including Tier 1 firms, suffer from an extreme internal disparity in terms of skills and experience.
We repeatedly have seen that when the unforgiving light of litigation discovery is shined on consulting firms’ staffing practices, the picture that emerges can be one of mayhem. Despite assuring a client that it will get the A Team, the consulting firm simply engages in a mad scramble for bodies– skills and experience be damned. Some consulting firms acknowledge internally (but never, of course, to their clients) that their own lack of skills and experience is a primary contributor to implementation failure. Nor should large, blue chip companies take comfort that their size or market clout will ensure that they get the best team, even from a leading consulting firm. We have seen some of the world’s most influential companies fall victim to consulting firms’ bait and switch tactics, paying millions of dollars for an unqualified implementation team.
The bottom line is that there is simply no room on an implementation team for project management “generalists” or junior consultants armed with little more than a college degree. Accordingly, CIOs need to get commitments from their system integrators that the A Team that’s promised during the sales cycle is the precise team that shows up at project kick-off and that stays through go-live.
Your Systems Integrator Lacks The Appropriate Tools and Methodology for Your Project. Another frequent cause of implementation failure–design failures, testing failures, budget breakdowns and schedule delays–is a systems integrator’s lack of appropriate project management tools and failure to adhere to an implementation methodology. While it’s hard to believe that any reputable consulting firm would not have the required tools or follow the right methodology, we have seen it happen over and over.
It goes without saying that a system integrator’s methodology should reflect its expertise in the client’s industry and with the specific software and modules to be implemented. But it should also reflect experience with client-specific circumstances, e.g., the regulatory framework in which the client operates, whether the client has a unionized work force, unique regional demands and the client’s own experience undertaking similar projects. It’s imperative, too, that the CIO not only be familiar with the methodology purportedly being applied, but also be vigilant in demanding that appropriate Quality Assurance (QA) practices are in place to periodically confirm that the implementation team is adhering to the methodology. A firm with a well-developed methodology will be more efficient, less likely to make major mistakes, better able to estimate resource requirements and able to identify project risks before they arise–all of which are essential to successful ERP implementations.
Conflicting Loyalties Between Software Providers and Consulting Firms. Symbiotic relationships between ERP software providers and consulting firms can create compromised incentives and conflicts of interests that prejudice the client. For one thing, software vendors are often eager for companies to implement the latest products, and consulting firms, often recommended to clients by the software vendor, necessarily lack both the experience implementing newly released software and the incentive to advise clients of the potential risks involved. Project delays and cost overruns–and, yes, ERP disasters–can result from implementing new modules or bolt-ons that lack the stability and refinement of more established (and equally suitable) products. In such situations, even competent systems integrators can be at the mercy of the software provider to address the defects that might surface during an implementation. Ultimately, of course, it is the client that will bear the cost of fixing the defects or addressing the lack of functionality, as well as the risk of a failed go-live.
CIOs must undertake extensive due diligence to satisfy themselves that when their company decides to be an early adopter of new software, the “leading edge” does not become the “bleeding edge.” One rule of thumb for the prudent CIO is to demand answers to some critical questions, such as: How many other companies have gone live with this new product? Have those go-lives been successful? Are those other companies in a similar industry? Has the software provider been willing to quickly supply technical know-how to address the inevitable issues? Will my system integrator level with me when signs of trouble emerge?
Because we specialize in guiding clients through failed or troubled implementations (many of which have led to litigation), we have had a front row seat watching ERP disaster movies. Our core takeaway is that the three issues described above make their appearance, in some form, each and every time. CIOs are well advised to be on point looking out for these problems and nipping them in the bud with alacrity.