How to Ensure ERP Implementations Succeed

By:  Eric Kimberling

Over years of being an expert witness in cases involving enterprise resource planning (ERP) software, I’ve had the opportunity to examine, analyze, and testify in court on all types of implementation failures.

Eric Kimberling

Eric Kimberling

I’ve been an expert witness for SAP implementations, Oracle projects, and Microsoft Dynamics transformations, among others. In addition, we’ve helped many companies recover their failed implementations before they reached the lawsuit stage.

Having a front-row seat to ERP disasters provides a unique understanding of what makes projects fail. More importantly, it helps us better understand what it takes for an ERP implementation to succeed. Rather than focusing on the negative failure points, it is often more constructive to look at the things you should be doing to be successful.

Below are five best practices, culled from our expert-witness experience, that will help you be more successful in your digital transformations.

Begin with realistic expectations from the start. Many failed projects are caused by unattainable timelines, budgets, or both. Our most successful clients begin with realistic expectations and adjust them (as needed) during the project.

ERP software vendors may not have, and may not be incentivized to attain, a realistic view of all the resources, tasks, budgetary line items, and internal requirements to make a project successful. It’s important to create a realistic implementation plan, timeline, resource allocations, and budget based on your company’s needs.

Define and document your business processes and requirements as early as you can. Even though you may not yet have approval to move forward with your entire ERP project, it’s important to define and document your business processes in as much detail as you can, as early in the project as possible.

If you’re able to do so during your evaluation phase, it will only help ensure that you have a more complete picture of your evaluation criteria, while allowing you to begin implementing process improvements before the new system is implemented. At the very least, you should document in detail “future state” business processes before your functional and technical resources begin configuring software.

Invest heavily in organizational change management, training, and communications. Each organization with a project failure I’ve been consulted on failed to effectively manage and prioritize organizational change management. This is no coincidence. Successful project teams realize that there is no such thing as over-investing in people, communication, and training.

The technical components are probably the least likely reasons for failure. An effective change strategy should include organizational readiness assessments, change impact analyses, benefits realization, and a host of other best practices.

Don’t hesitate to postpone “go-live” until your organization is ready. For a successful project, don’t treat a go-live date as a “Hail Mary” pass at the end of a football game. Instead, be measured, deliberate, and focused on mitigating risk. Even with a realistic implementation strategy early on, you may still face a crucial decision: go-live before you’re ready, or delay until the organization is fully prepared.

The only way to get to the right answer is to conduct an agnostic go-live readiness assessment to determine the pros, cons, and risks of the pending go-live date. Too often the pressures of a predetermined go-live date or budget may cloud your judgment.

Remember: this is your company and your project. At the end of the day, you own the result. It’s not your software vendor’s or your system integrator’s responsibility. It’s also not realistic to completely outsource your project to an outside party without the appropriate oversight, input, and accountability.

Don’t be afraid to pivot if things aren’t going as planned.

Eric Kimberling is managing partner of Panorama Consulting, a provider of ERP consulting and digital transformation services.