NOVEMBER 16, 2010

ERP gone bad: Lessons from real-world failuresSpectacular flameouts have much to teach managers about the right way to run projects

By Andrew Binstock | InfoWorld

Print | 1 comment

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 in sales. In 2006, the company undertook a

$36 million 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 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.

NOVEMBER 16, 2010

ERP gone bad: Lessons from real-world failuresSpectacular flameouts have much to teach managers about the right way to run projects

By Andrew Binstock | InfoWorld

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

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.

NOVEMBER 16, 2010

ERP gone bad: Lessons from real-world failures

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

By Andrew Binstock | InfoWorld

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

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 in third-quarter

revenue. According to a Register.co.uk 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 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.

This article, "ERP gone bad: Lessons from real-world failures," was originally published at

InfoWorld.com. Follow the latest developments in business software at InfoWorld.com.