To avoid ERP implementation failure, start with clearly defined requirements

It's no secret that ERP implementations are complex and costly projects that can often be plagued by problems. In rare cases, the problems are so extensive that they result in an ERP implementation failure, which can sometimes lead to litigation. In 2018, for example, brewing giant MillerCoors sued its implementation partner HCL over a failed SAP implementation. The case was resolved, but the costs were considerable for both companies.

So, what should companies do to avoid an implementation failure that could lead to litigation? That's what ERP business consultant Brooks Hilliard, principal at Business Automation Associates Inc., based in Phoenix, talked about in this Q&A.

Hilliard has served as an expert witness in ERP implementation failure lawsuits, including the MillerCoors case. While he couldn't discuss the details of that case, he did explain how ERP projects can get into trouble and how companies can avoid this.

What are some of the steps companies can take to avoid ERP implementation failures?

Brooks Hilliard: As a potential ERP acquirer or licensee, the first part of avoiding problems is to make sure that you've defined your requirements as well as possible. That involves getting the people within the organization that are most knowledgeable about all of the functions that the new system needs to perform to help in putting together those requirements. A top-down approach is not going to work.

What are the most important requirements companies need to define?

Brooks Hilliard

Hilliard: You need to identify the mission-critical functions -- those functions that are unique to the business, that differentiate the business and make it profitable. So, you have to define those critical functions as closely as possible, and then look at the supporting functions. You don't necessarily need to define those as specifically as you would the ones that are the primary competitive or differentiating functions of your business.

What are some of the ways to evaluate ERP vendors?

Hilliard: You need to get the people most knowledgeable about the critical functions involved in the evaluation and in the demonstrations. Where there are areas of difference between the solution that's being offered and the functionality that you need, make sure that you dive into those as deeply as possible with the most knowledgeable people. And whenever possible, before reaching a final decision, talk to other users and not just those users who the provider gives you.

As you're doing the reference checking, ask the references if they know other folks who you can talk to who are using the software. So, you get a broader base of folks who are using the system than just those who are recommended by the potential supplier.

What should companies consider after they have selected a vendor?

Hilliard: In the contracting process, you need to get written commitments in the contract for all those things that are promises that you haven't actually seen. That could be an incorporation of your requirements document, or it just could be specific addendums and promises on the functionality.

The most important thing is not to wait until the end to do this. As you're getting into the implementation process, typically, there will be a statement of work that defines what the provider is going to do and to make sure that those SOWs are followed, rather than shortcut.

How should you handle problems if they come up during the implementation process?

Hilliard: If issues start to come up, deal with them as quickly as you can. Don't let them fester. In some cases, it does help to have an outside consultant help you do that. This gets a third party involved -- engaged by the buyer -- to act as an intermediary to address issues if problems are coming up and sets remediation projects in place before they get out of hand.

Because problems do occur in just about every implementation, if they're dealt with quickly and effectively, you can get around them and get to a successful implementation. If you wait until things have gotten out of hand, then it's much more difficult.

What are some of the main causes of ERP implementation failures?

Hilliard: In my experience, problems can be the fault of the providers or the company. Very often in litigation, it's a mix, and there are issues on both sides. From the customer standpoint, the problem is what the providers call 'moving the goal posts,' essentially changing the requirements after the project has begun. Sometimes, you can't avoid that.

Things come up as the provider begins to implement. And when you start to see the implementation, you realize that maybe what you asked for initially isn't exactly what you need. Those types of things can be resolved if you address them quickly, and there's often extra costs, but sometimes not.

Sometimes, failures are primarily caused by the customer because of poorly defined requirements or not completely defined requirements upfront. These cause issues once you start to see how the systems are going to work before it goes live.

What are some characteristics of an ERP implementation project that indicate it's gone beyond making a few fixes and is headed toward failure?

Hilliard: In some ways, that's pretty obvious, as most companies reach a point where they no longer believe that the provider that they've selected has the ability to meet their requirements. The implementation project should have milestones, and it's when those milestones are consistently not met and you can't successfully remediate them.

Those milestones need to include demonstrations and testing before you go live, [but you should consider stopping] when those types of milestones begin to fail and you can't effectively remediate them.

When should companies consider resorting to litigation to resolve the issues?

Hilliard: When the provider makes promises about how and when they're going to be able to resolve the issues and then fails to meet those promises, that's usually the point where you may consider that litigation may be an option -- or at least some sort of a negotiation or rescinding of the contract.

From the client's side, you need to be able to determine that it's unlikely to be satisfactorily resolved at some point, and, hopefully, your contract included a clause that you can invoke to handle issues that come up. But even if it didn't, if you're a dissatisfied client, at some point, you have to put your foot down and say, 'Here are some deadlines to accomplish certain things. And if we can't accomplish these by the deadlines, then we're going to have to discontinue the implementation and get this resolved.' Hopefully, [it's resolved] by discussion, but also by legal means if it comes to it.