Why are consultants usually to blame for failed ERP implementations?

After having written almost 1000 blog posts related to IT failures, I have developed a clear opinion on this topic.

I believe that we must view IT project failures as resulting from a combination of errors on the part of all three major participants: the customer, software vendor, and system integrator.

It's easy to paint enterprise customers as innocent victims, when that is rarely the case. It's more productive to ask what role did the customer play in creating the situation that caused the failure. Likewise, one should ask about software vendor's sales process -- did the sales person understand whether the software fit was right for the customer.

The role of consultants and system integrators can be notorious in creating failures. Consider this: when a project is over-budget, where does that extra money go? Often into the pocket of consultants. I am over-simplifying for dramatic effect, but there is some truth here as well.

I even coined a term for this triad of failure: the IT Devil's Triangle. You can read about it here: http://www.zdnet.com/blog/projectfailures/exploring-the-devils-triangle/5676

Todd,

I don't think the consultants are to blame unless there is some evidence of incompetence. Consultants only follow the rules of the ERP Implementation imposed by the architecture and functionality of the ERP itself.

The degree of fit that any ERP has to a customer's business is woeful. Sure they fit the Accounting department (very little variance between customers) and maybe even the Procurement department (since most of the "soft science" of buying is in the buyers mind/approach). But Operations, from manufacturing through distribution, delivery, sales, installation and service? Forget even pretending the ERP fits.

So the consultant, who may or may not have been involved in the selection of the ERP to begin with, has to start the process of reconciling the gaps. Requirements gathering, documentation, negotiation, etc. all protract their engagement and may make the customer feel like they are being bilked. In all honesty, often times they are...but not because the consultants could dramatically close the gap between standard functionality and customer needs. Bilking by the consultants occurs when resources are piled on that don't add value to the implementation and they are notorious for seeking scope creep/project extension. But again, they didn't set the rules for the ERP.

A version of your question has been asked in other forums, most notably LinkedIn, where the question related to more why does an ERP fail. In those instances, there is no customer input on the answwer but way too much input from Consultants and Software vendors where their reason is because the Customer doesn't know how to run their business, they are stupid, etc. This demonstrates the fact that the ERP systems simply don't fit. None of them do.

This inescapable fact puts all three parties, customer/vendor/consultant, in the unenviable position of unacceptably high project risk, cost and disruption. For two decades plus the finger pointing has indicated that the "model" is broken. ERP's were not meant to change. If you modify them in the slightest you forego budget, schedule and upgrade control. If you modify your business to fit the ERP, you forego control of your business.

There is a new approach in enterprise software that allows the current ERP to be left in place, unmodified and unintegrated. BabbleWare is a leading vendor in this new model. We have successfully delivered projects to Toyota and Owens & Minor where their ERP systems remained untouched. We leverage those systems and enhance the Operation so that new processes, data and technology can be adopted without any knowledge by the ERP. Toyota and O&M both took us up on our Innovate in a Week program where we delivered 292% gains in productivity for Toyota and avoided hiring 5 FTE's for O&M.

Our solution makes the question you've asked a thing of the past. Let's hope it becomes a distant memory sooner than later so that customers considering a replacement, upgrade or integration strategy can avoid the pain and cost of making the same old mistake time and time again.

Yes. I blame myself (the consultant) when implementation projects fail. Here is why I think it is this way.

The consultant or company offering the solution positions itself to the customer (or prospect) as an expert in the offered solution. Yet when the solution fails the consultant often blames the customer for being ill prepared and without the necessary resources to get the project done. While this might be true, the expert (consultant and the company represented) provides a path to customer success.

An interesting analogy for me is transportation. If one wishes to travel from Washington DC to New York, one simply chooses the method of transportation from the vendor that offers the method that ensures arrival at the preferred time. Regardless of the method chosen, there is a schedule arrival time and the majority of the time one reaches the destination on time.

Let us compare the transportation analogy to a large software project. The routes from DC to New York are certain. There is no need to blaze a new trail, calculate distance/time, or build a unique craft to get there. One simply chooses the best method that allows the customer to get to New York at the desired time. When a customer engages an ERP or other consultant and clearly states the destination, time, and budget to get there, it is up to the consultant to provide the type of information one would for the trip to New York. This is regardless of the variables for as a consultant, one possesses the experience and knowledge to suggest the best method. The challenge in systems is that the experts are not experts and lack the experience or knowledge to make a solid dependable recommendation to the customer.

The biggest reason I blame myself as the consultant is that in many instances the solution I recommend is one that no one on the team has ever seen. We have no idea if it works but it represents a combination of what closed the deal and what we convinced the prospect we do. Do you ever wonder why a tachometer exists in nearly every car today? Customers buy a package that addresses their needs based on what they see. In enterprise systems, customers buy an idea and hope the vendor delivers. The customer questions every element because there is no complete package for the customer to see.

Michael,

You are right, the customer does share the responsibility. Unfortunately for them, there are 2 companies motivated to get them to say yes and the seperation of software vendor v. implementation vendor makes the other a convenient scape goat. Money pours into the consultants pocket, the software vendor is too blame for over selling the capability of their application and the customer is squeezed in the middle. The biggest responsibility the customer seems to own is making a bad decision at the beginning of the process.

Consultants are easy to blame, which makes them more commonly blamed. But if you're a company whose attempts at change have failed, you better work through the Blame Game quickly and start spending time on the Success Game. Same goes for the vendor whose product never made it to the goal line.

The real challenge isn't in deciding who to blame - there are plenty of people for that distinction. The real challenge is in trying to figure out how and when it went wrong, what were the warning signs, how did we (yes, that means you too!) react to them, could or should we have reacted differently, etc. If you walk away safe in the knowledge it was someone else's fault, and never go through the exercise, you will be doomed to repeat.

Dana,

Good point. Any project, good or bad, requires a post mortem. At least the customer will know what killed them and hopefully avoid it in the future.