The Biggest Problem with ERP Implementations…Money

January 17th, 2013

By Vince Benz

The Problem:

The ERP implementation field is covered with wrecked careers and businesses that did not survive.  In a recent Gartner report, 65% of all ERP projects fail and another 25% never meet the intended financial or functional goal of the company.  These failures are an accepted practice in the commercial software industry, keeping an arm’s length between the sale of the software and the numerous third parties that are available to implement the solution.  Not all System Integrators are created equal.  I in no way include all System Integration Companies in painting the industry with one brush.   The project outcome is based on the quality of people and processes that are brought to the table,not the name of the SI.

Most QA companies would tell you that the cost to deploy this type of software is roughly 5-8 times the money spent to purchase it.  The SI creates the SOW that includes all the components to how the project will be run as well as details the cost of the project across such elements as milestones, resources, both on and off shore, hours, and expenses.  Many projects I have evaluated lack the clarity and visibility of the work product against payments to the SI.   More important is the payments are really structured as a payment schedule rather than payment for services.  If the money was distributed based on performance, many projects would be stopped midpoint for the code and configuration to catch up with the plan.  A stagegate process for checks and balances are an important process that includes code reviews and interum testing practices.

It is the System Integrator who is responsible to bring the necessary subject matter experts or SME to the project in order to extract the value from the purchased software. The tier 1 ERP vendors SAP and Oracle enjoy an estimated combined market share of 42% worldwide, there are over 350 other products that fill out the sector.  The major System Integrators have found a need and have developed “proprietary processes” that are sold to guarantee the success of the project.  These processes have been developed over a number of years, using collateral that seemed to be useful in prior projects. So, if the SI has so much experience, “WHY IS IT WE HAVE SO MANY ERP AND MEGA PROJECT FAILURES?” In 2 recent ERP projects I have been involved with, the SI systematically collected the monthly fee, and in the end, both companies lost multi-millions of dollars due to the poor performance and never completed a successful go lives. Remember, the System Integrator was hired because they knew how to execute this type of project and knew the issues that would be most significant to close.  What happened to the partnership and collaboration between the SI and the companies that are in need of help?

When I say millions, I mean MILLIONS, like over nine digits.  In one case, over $100,000,000 was spent over 3 years on an ERP project that was driven over the cliff by the SI.  In the second case, the project was built completely in old technology and configured without the help or expertise of a solution architect.  The company never thought to bring in its own experts until it was too late and the money was spent.  This expertise is critical due to the level of integration within these types of systems; it is important to understand how the system integrates and impact other systems and uses the internal connection points.

Neither project ever had a chance to make it to go-live. The only saving point in the later project was the execution of the IV&V clause in the SOW and had an independent company review what was going on and was able to stop the project before it crippled their business.  Money aside, the only downside was the loss of money. Not that money is ok to throw away, but we have read about other companies that have closed their doors after a catastrophic ERP or badly executed project event.   The cost of the project, remember millions, now must be written off because no value could ever be had from the project.

The Solution:

Before I get into some of the corrective actions that I have used in putting these projects back on the rails, there are 4 things that happen during an ERP project that has gone badly.  Blame, Embarrassment, Accountability and Partnership / Teamwork breakdown.   Interestingly, blame is never a topic that companies or System Integrators what to talk about because it leads to litigation.  No one can admit fault because that will be used against them in a court of law.  The embarrassment is obvious in the company regardless of level of executive.  The senior executives and CEOs feel responsible for allowing this amount of money and time to be spent without clear accountability, and are very reluctant to share the failure with their board and shareholders.

Most companies that jump into the ERP space usually are unskilled in the methods of what it takes for a successful implementation, but why should they?  Most have thriving businesses and are focused on their core competency and are looking for the next technology platform by which to grow.   Executives I have interviewed did as much research asthey could on the products and partners before engaging the ERP vendors.  Many hours of research are usually done to validate the capability of the product and the benefits are defined early in the process to balance the cost to the shareholders.  This is where it starts to breakdown.  Once the company selects the software, the System Integrators are asked to propose their solution.  Without having any knowledge of the business or what is necessary, each company that ventures into this space becomes dependent on the System Integrator for planning, resources, status, cost, and configuration of the system.  Remember, I put a disclaimer earlier in the article that not all System Integrators treat their customers badly. There are SIs that are very customer focused.  There are many components in putting together an effective team that includes both consultants as well as key business stakeholders that need to support the system after it is up and operational.    Select the partner carefully, interviewing all consultants on the project and getting each person to produce a resume to show they have the necessary experience and background to be as effective as possible.  Even get the resumes of offshore resources. In most of the projects I was asked to evaluate, most lacked any visibility to who was actually on the project and even less of what each were doing to bring the project to fruition.

If the customer company lacks the skills or understanding of the new product, it is important to hire resources to be the sounding board to the SI and is there to protect the interest of the company.  There will also be a point in the project that Knowledge Transfer will occur only if the people have been brought into the company as full time employees.  Without these people being available, the company will remain dependent on the SI for the foreseeable future.  Those are incremental costs that are seldom included in the original estimate.   The SI is a business the same as any other and can make decisions that are not in the best interest of the company.  Training here is the answer.  The more the company employees know about the new tool, the better result can be deployed.

Finally, these projects can and occasionally do come out well.   The key is transparency and complete visibility of the status and risk of the project on a weekly basis.  That might seem like a tight schedule, but better to know everything is executing on schedule rather than find after a month or quarter, that issues or people or technology has caused a major challenge and cannot be recuperated.   Ensuring truthful communication up the chain of management as well as clear messaging across the organization will help alleviate rumors and keeping everyone on track.     Operation and Project metrics along with costs need to be highlighted on the status reporting to senior management.  References and checking on the resources within the industry can be a good way to show if the SI being considered is up to the work.

The examples I have used here are true, the names have been changed to protect the …well you get it, unfortunately, there are many other projects that are reminiscent of these examples.    I hope to give an update in a later blog.   Drop me a note on how you did executing an ERP project or mega project and the outcome, are you part of the top 10%?

Leave a Reply