ERP Gone Bad: Lessons from Real-World Failures

Spectacular flameouts have much to teach managers about the right way to run projects

Andrew Binstock Nov 17th 2010

Spectacular flameouts have much to teach managers about the right way to run projects

ERP projects are among the most critical efforts IT ever undertakes, as they touch almost every part of essential business operations and are complex technically. Not surprisingly, some fail -- spectacularly. Although ERP has been an enterprise focus for a decade, many companies are still embarking on such efforts, and even more are dealing with ERP redos because of mergers and business changes. Here's what you can learn from the failures of others and put to use on your own ERP projects.

I focus on failed SAP deployments because the details are more commonly available, thanks to SAP's huge presence in large publicly owned enterprises and government, where documents surrounding litigation and major cancelled projects must be made public. But the lessons apply to Oracle and other ERP deployments as well.

What is an ERP project failure? Not mere cost overruns, but an event whose effects are so large that they force a company to restate its earnings or a government entity to cancel a project that is substantially funded.

John F. Kennedy once said, "Victory has a thousand fathers, but failure is an orphan." In the world of ERP projects, the reverse is almost always true: Failure has a thousand causes. These causes almost invariably arise, says Michael Krigsman, CEO of the consultancy Asuret and a well-known analyst of ERP failure, because of a lack of alignment between the three key parties in a project: the customer, the software vendor, and the system integrator.

Customer failures
The lack of alignment often begins with problems on the customer's side of the equation. In its most common form, it consists of lack of proper planning. David Bergen, the former CIO at Levi Strauss & Co. who implemented several SAP projects at the apparel maker, says that most companies are not prepared for an ERP project because the basic steps have not been performed adequately. "Companies are generally not good at change. Additionally, many companies struggle in defining their business processes. Those that struggle with the process redesign will have a difficult time in achieving success and realizing the benefits."

A consistent theme in failed projects is overreaching on the part of the customer. This ambition is often fueled by salespeople from the integrator and the software vendor, who tend to create improbable success scenarios and encourage oversized projects.

A case in point occurred at Shane, a jeweler with $200 million (about Rs.900 Cr.) in sales. In 2006, the company undertook a $36 million (about Rs.162 Cr.) ERP project that was canned after three years. This was a hugely oversized project and likely far too large for the company, says ERP advisory firm Panorama Consulting. Its survey of 1,300 ERP implementations concludes that the average company spends 9 percent of its annual revenue on an ERP project -- Shane spent twice that. Shane filed for bankruptcy in 2009, blaming in part the cost overruns of its incomplete ERP implementation.

However, even once a project is properly scoped out and a validated plan put in place, customers frequently fail to manage the project correctly. Typically, this takes the form of poor decisions, pushing tasks the customer should undertake onto the staff of the integrator, and not holding the integrator to the project plan, timetables, and especially, budgets. When a company with weak project management is teamed with an integrator that doesn't deliver to spec, wholesale disaster can ensue.

One example of this is FoxMeyer, a $5 billion (about Rs.22,500 Cr.) drug distributor -- at the time, the fourth largest in the United States. The management team was an early and vocal supporter of an ERP project to streamline warehouse operations. Despite warnings that the implementation's schedule was too aggressive, the company went ahead and inked a huge drug distribution deal and slashed the price of its products in anticipation of the project's completion.

The project, however, steadily fell behind schedule. The delays were exacerbated by the changed requirements and business processes resulting from the new deal. As matters worsened, consultants to management suggested that the project be scaled back and implemented in phases. But the CEO and CIO, who both strongly supported the ERP conversion, said they had "bet the farm" on the project and instead opted to expand it. This decision accelerated the failure, and within two years, the company was forced into bankruptcy.

A study by Judy Scott (then at the University of Texas School of Business) concludes that FoxMeyer was a failure of management. The use of inexperienced consultants by the lead integrator, Andersen Consulting, was a contributing factor, she reports, but the factor that sealed the project's fate was management's inability to regain control of the project and make the indicated decisions. Successful projects require responsive, thoughtful management.

System integrator failures

System integrator failures

Because integrators do the actual implementation work, they are frequently an integral part of all project failures. Their chief offenses tend to consist of using consultants who are insufficiently trained in the packages they're installing -- sometimes even in ERP basics -- and they tend to be poor at regulating themselves. Both factors derive directly from how integrators charge: by the hour. (Few contracts are fixed bids.) As a result, the cheapest staff that can do the job result in the greatest profit, while taking on additional tasks produces a more profitable engagement.

The inherent conflict of interests between the integrator and the customer is a frequent source of contention, not only between those two parties, but with the software vendor as well. In 2009, for example, Léo Apotheker, the then-CEO of SAP (and now CEO of Hewlett-Packard), decried in remarkably blunt terms how the self-interest of integrators (here, Accenture and IBM) led to failed projects that reflected badly on the software, rather than on the integrators: "I don't give a shit if it's Accenture or IBM. ... I find it remarkable that people [from integrators] are walking around talking to customers and have no experience. [They] have no clue. It's annoying, but that's a fact."

The practice of integrators sending out inexperienced consultants is so pervasive that almost every lawsuit in ERP projects claims this as a cause of action. Greg Hatch, managing director at Alvarez & Marsal Business Consulting, a firm that offers advisory services to clients on large ERP projects, states that this problem derives in part from a mistaken perception of integrators: "You can view it as engaging a company, but you should really view it as hiring a team of people. You should interview the senior staff, such as the project manager and team leads, and study the résumés of the rest. Make sure they not only have relevant ERP experience, but ideally have done ERP projects in your particular industry."

As a customer, you must address the problem of slipped deadlines through strong project management. You should actively resist the temptation to push out the schedule because of unexpected problems or misprojections of time and resources. Each delay is a symptom of a larger problem, and the project management team, with the integrator, has to figure out what's wrong and get it fixed.

Observes Hatch: "Projects never go south all of a sudden at the end. They invariably have been coming apart little by little. This 'death by a thousand cuts' has to be addressed promptly by the customer's project management team."

Software vendor failures
Software vendors, such as SAP and Oracle, tend to be blamed for the sins of their salespeople -- namely, promising features or software that do not exist or cannot be delivered. In many cases, this is simply stretched truth or an overambitious representation of benefits, but every once in a while, vendors can step off the cliff entirely.

Consider the case of trash-processing giant Waste Management [PDF], which sued SAP for fraud over a failed ERP project in 2008. It claimed in a statement that SAP had demonstrated software that was an "out of the box" solution for the company's needs. Instead the software, according to the company, was "a mock-up version of that software intended to deceive Waste Management." The "fake software" was used repeatedly in demonstrations to company executives. Waste Management's suit was settled earlier this year, with SAP paying a cash settlement.

Hatch comments that similar scenarios can be avoided in large part by getting commitments for features in writing. In addition, he says, "the demo should be done with scripts using client- and industry-specific data, not some generic application." And, he adds, with a Tier 1 ERP vendor (SAP and Oracle), you should be able to get references to other implementations the company has done in your industry segment. If a package exists for your industry, use it without customizing it to the point of making it unrecognizable.

Krigsman agrees: "One of the things you're paying a company like SAP is for its knowledge of the business processes in your industry. Its software typically embodies best practices, so to the extent possible, avoid writing custom code, and instead, where possible, change your business processes to align with the ERP package."

ERP's complex triad: Getting it right

ERP's complex triad: Getting it right

The alignment of the customer's need, the vendor's software, and the integrator's implementation is a remarkably complex triad, whose dynamic nature requires all parties -- the customer, especially -- to monitor activity carefully and respond immediately when problems occur.

But even managers who are well versed in ERP implementations can run into serious, unexpected problems. Consider Hewlett-Packard, a company that at the time of its internal SAP failure had a business unit that consulted on SAP projects. The botched implementation cost HP $400 million (about Rs.1800 Cr.) in third-quarter revenue. According to a article, "HP staffers were standing inside 18-wheelers [trucks] hand-labeling shipments of million-dollar Superdome servers and the like. High-ranking executives were being forced to spend their time approving rush orders of $50 (about Rs.2,250) parts to key customers."

As several analysts point out, no matter how good you are, ERP projects are hard. Still, there's some advice that consultants and analysts agree on.

Define the project completely. Understand what the business must do before, during, and after the projects. Some activities that precede a project include completing migrations to new systems, documenting business processes, and data cleaning.

Failure to provide clean data can be costly. In 2008, demonstrators took to the streets in Los Angeles to protest a failed payroll project that led some teachers to be overpaid, others underpaid, and others yet unpaid. One of several causes was, according to an investigation by the Los Angeles Times, "years of shoddy record-keeping and strangely complex union contracts [that] made answering basic questions -- including how much people should be paid and what jobs they worked -- almost impossible." As many consultants point out, those questions should have been answered before the project was undertaken. Preparation pays off well on ERP projects.

Choose the vendor with care. Bergen recommends that companies lacking extensive experience with ERP projects hire consultants unaffiliated with either the vendor or the potential integrator to advise the client with the planning and implementation. One key benefit of these advisers is they facilitate the dialog among client, integrators, and vendors and make sure the proposed solution fits the company's needs. Good advisers will know what is missing from a contract and be able to verify you are getting what you think you're getting. Krigsman stresses the need to get all promises about the software and implementation in writing.

Choose the integrator with greater care. Normally, the integrator brings in the software vendor, so the previous advice on selecting the vendor is even more critical when selecting the integrator. Interview the senior staff and go over the résumés of the other participants. Be sure they have experience in your industry segment.

Assemble a strong team to oversee the project. The team should include the CEO, the CIO, the heads of the affected lines of business, the project management officer (who is frequently an external advisor), and any primary project sponsors, advises Hatch. Integrating business executives in the team is crucial to success, observes Ross Wainright, executive VP of professional services for SAP North America. "An ERP implementation is a business process, not an IT project," he says.

Many of SAP's suggested practices (see sidebar) focus on this project team. The key is its authority to act in two important areas: rejecting (or approving) requests for scope creep and calling the integrator and IT staff to explain and solve delays, missed milestones, and budget overages. Without this authority, the project will surely veer off course.

Actively manage the project. ERP projects are nearly always lengthy, so it's tempting to not give them constant attention. But success lies in the details. Team members should be getting constant updates on progress and problems. If an important problem arises, available members of the oversight team should convene and make a decision. The entire team, according to Hatch, should meet at minimum once a month. Wainright adds that the swim lanes in the project should be clear and well understood, as this facilitates making corrections quickly.

Understand the impact on the business. ERP projects generally have profound impacts on many internal company functions. That's why the effects of large projects have to be understood and planned for from the very beginning, says Pam Daniels, who heads up Stylus Group, an organizational development consultancy. "Change management is a fundamental practice that must accompany ERP projects from the very start and all the way to through to the end. It continues even after the consultants have left the premises," she says. If change management is neglected, employees may resist the new software or use it minimally. Either way, the benefits of the project are undercut even if it is a technical success.

Don't shortchange training. One of the most dramatic ways of diminishing returns is insufficient training of the users of the new software. In the most common training model, the integrator writes up documentation on the various customized parts of the package, and then it trains the trainers, who ultimately train the users. But the train-the-trainer model breaks down when the client staff are not good trainers, says Jennifer Jackson of Elliott Jackson Communications, which specializes in SAP training rollouts. She prefers a method in which client staff members participate actively with external trainers in the briefings, so the training sessions can be be highly specific to the company while drawing on the external trainer's experience with SAP software.

Jackson says that all too often training is rushed and that companies don't run pilots or give trainers time to practice and perfect the training experience. Given that the ultimate benefit of the ERP project rests on employees' use of the software, she cautions against cutting corners on training or rushing the training schedule.

Even if you follow this advice, there's no guarantee of success, alas. But you can more likely avert failure by proper planning, active project oversight, and rigorous change management.