Business Solutions with SAP

SAP ERP Project Failures Lessons Learned and Mini Case Studies 3

December 27th, 2010 by
ERP Project Failure 3

ERP Project Failure 3

In this final installment on these lessons learned and mini case studies we will look at a few older SAP project failures. Even in these older SAP project failures it is still surprising that so many of the same problems continue to repeat themselves after all these years.

I’d like to point out once again that in the major SAP project failures the software application itself was not at the root of the failure. The project failures I focused on are the ones where there is plenty of published literature to evaluate. Obviously that does not mean that there aren’t projects with failures where the software itself was responsible, only that the available literature where you can do a fair analysis of the projects do not point to the software itself as the cause.

One of the interesting trends for several of the project failures was the SAP project was blamed for poor business results. For example,

SAP ERP Implementation Failure Overviews – part 3

Some of the reasons for these older SAP ERP project failures (and many of the modern ones) include:

  • insufficient or improper training,
  • lack of change management,
  • insufficient testing,
  • poor scoping,
  • bad go-live timing,
  • unreasonable timelines,
  • bad project management,
  • lack of senior management participation,
  • multiple simultaneous enterprise application projects,
  • too much or too complex custom development efforts (interfaces),
  • and inexperienced or incompetent consultants.

Hewlett-Packard Company – SAP ERP Project Failure? (2004)

  • Even though this was attributed to the SAP implementation there are other things to consider. At the time of this implementation HP was a fairly mature SAP shop. They had already done 4 prior rollouts of the application and this was number 5. The “hiccup” only prevented one week’s shipments and as an SAP consultant since 1994 I can all but guarantee you that this “hiccup” was at the beginning of a month, and probably the beginning of a quarter, and not at the end. As a result it could not have affected the financials to that extent.
  • CIO and Executive Vice President of Global Operations Gilles Bouchard didn’t think that… data modeling problems between the legacy and SAP systems was the source of the $160 million impact. He blamed HP’s inability to keep pace with orders in the supply chain once the problems were discovered. [FN1, pg. 26]
  • Although HP’s Industry Standard Servers (ISS) business woes were blamed on SAP because of a one week supply chain hiccup, the actions by HP hint at a different reason. If the SAP software were to blame then the division’s sales executives would not have been fired:

HP “announced that three major sales executives, including former server group head Peter Blackmore, had been fired in a management shake-up following the disappointing quarter in the company’s server division.” [FN2]

  • I do not believe this was an SAP software failure regardless of how it was reported.

Lessons Learned: This “hiccup” was most likely a result of insufficient testing. Otherwise this appears to be a case of blaming the enterprise software implementation for company or marketplace related issues.

Hershey Food Corporation – SAP ERP project failure overview (1999)

Hershey foods went live with their SAP implementation just before Halloween in 1999. For the candy company this was the beginning of their peak season and the go-live created a major business disruption at the worst time from a revenue and operations standpoint.

  • Insufficient training and user preparation
    • Users were not prepared to do their jobs, to manage day to day operations, or to clean up and correct data. Training and change management needed more emphasis.
  • Unrealistic implementation timeline
    • Original timeline for the entire project was 4 years, that timeline was cut down to 2.5 years. Scope management, project planning, project scheduling (including task and resource leveling) are critical for success.
  • Improper go-live schedule
    • Went “live” at peak sales season and did not allow enough time to “shake out” data and process issues. Formal project plan and schedule; the integrator bears this responsibility unless they notified the company of the risks and the company insisted on going live.
  • Additional large enterprise applications such as Siebel CRM and Manugistics went live at the same time.
  • Has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: Careful timing and planning of the project are important considerations, as well as sufficient time and resources for training, change management and user involvement. Major enterprise applications (ERP, CRM, Logistics, etc.) should be implemented one at a time and then at least modestly stabilized before undertaking additional enterprise applications. Attempt to schedule go-lives so that they coincide with the end of a busy season and a potential “lull” in business. This way there is some time to work through stabilization issues before busy seasons start.

Whirlpool Corporation – SAP ERP project failure overview (1999)

Just before a Labor Day go live in 1999 several warning signs of serious problems appeared. Interfaces and batch jobs that fed external systems indicated serious performance problems but Whirlpool management and their SAP implementation vendor Deloitte decided to go live anyway. A decision was made to go with the known problems and the problems would be resolved within roughly a week after going live. However the interface problems created far more disruption to the external shipping and distribution systems than was anticipated. Shipments were delayed 6 – 8 weeks causing significant lost business because many customers cancelled orders and went elsewhere.

Lessons Learned: Red flags with enterprise applications should be carefully evaluated for a “go” or “no go” decision as you approach going live. Testing of interfaces cannot be ignored and serious performance problems or known interface problems should not be ignored.

Fox Meyer Drugs – SAP ERP project failure overview (1995)

  • Management failure
    • SAP was being used to automate and consolidate warehouse operations and layoffs were known to be coming. Labor sabotaged the efforts.
    • Warehouse consolidation was occurring just as the company captured a major new contract increasing the transaction and processing volume.
  • An additional large enterprise warehouse management system was implemented during the SAP implementation.
    • This is scope management and project planning and scheduling.
    • Multiple enterprise systems create significant project risks.
  • Insufficient training and user preparation
    • Users were not prepared to do their jobs, to manage day to day operations, or to clean up and correct data. More emphasis on training and change management was required.
  • The consulting company provided “trainees” to do the SAP implementation which turned out to be a disaster.
    • Project scope and cost were mismanaged because the consulting company drove the entire project.
    • Poor project planning and coordination.

Lessons Learned: Change management, training, and employee acceptance are critical. Avoid multiple enterprise wide software projects at the same time. Ensure that the SAP vendor partner doing the implementation does not staff the project with inexperienced, ineffective, or less than optimal consultants.


[FN1] Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School.

[FN2] SAP implementation contributed to HP shortfall. Computerworld, August 12, 2004.

Related Posts:

SAP ERP Project Failures Lessons Learned and Mini Case Studies 2

December 20th, 2010 by
SAP ERP Project Failures

SAP ERP Project Failures

The following SAP ERP project failures cover the importance of testing, change management, training, senior management involvement, scope management, and quality of the consultants provided by ERP implementation vendors.

With the exception of the inept, incompetent, or otherwise unqualified “con”sultants provided by some system integrators it is important to note that these failure overviews illustrate many of the points made by Steve Phillips in the post on Software Consulting Firms and Clients Myths and Half Truths .

There Mr. Phillips lays out pretty significant areas where the business must chart and then control their own project destiny.

For a table of the primary areas of responsibility for end customers to ensure project success please see SAP Success Factors for Vender Selection – Responsibility Matrix 2 .  The table developed there is derived from the academic literature and my own experience.  I have added my opinion on how the responsibility for those success factors is divided between the customer and the SAP implementation partner or vendor.

Continuing on the series of SAP ERP project failure overviews, here are three more.

SAP ERP Implementation Failure Overviews – part 2

Levi Strauss & Company – SAP Failure? (2008)

  • After go-live shipping was prevented for one week and there were legacy system integration issues.  Levi was an interesting case study because many industry experts believe the SAP implementation was used as an excuse for broader economic issues affecting Levi.
    • One week of delayed deliveries was insufficient to explain the overall drop in financial performance (approximately 98% decrease in revenue could not be sufficiently tied back to the SAP implementation).
  • Levi Strauss has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: Ensure that all legacy system interfaces are carefully tested before going live. Don’t use SAP or enterprise application implementations as an excuse for poor economic or poor overall market conditions.

Waste Management Incorporated – SAP ERP Failure Overview (2008)

  • Waste Management claimed in its lawsuit that they “wanted an ERP package that could meet its business requirements without large amounts of custom development…” They also claimed “SAP used a ‘fake’ product demonstration” and “SAP’s technical team had ‘recommended that SAP deliver to Waste Management a later version of the software than the version SAP in fact delivered’.” They also claimed SAP knew the software was “unstable and lacking key functionality…” [FN1]
  • SAP claimed that its application could meet the company’s needs without modification.
  • SAP claimed in its legal counterclaims that “Waste Management didn’t ‘timely and accurately define its business requirements’ nor provide ‘sufficient, knowledgeable, decision-empowered users and managers’ to work on the project.” [FN1]

Lessons Learned: First and foremost any organization or company who implements SAP, ERP, or other enterprise software applications must ensure they are in control of their own project. This would generally fall under numerous critical success factors: business process engineering / change management, scope management, senior management support, formal project plan and schedule, consultant experience, implementation strategy, and amount of custom coding.  Delivering a project with standard system functionality, and on time / on budget requires strong leadership from both the customer and the integrator.  For additional insight and a somewhat different perspective please see the post where SAP and Waste Management Finally Settle .

Los Angeles Unified School District – SAP ERP-HR Failure Overview (2007)

  • Fake Consultants / Trainees / unqualified consulting resources on the project
    • “[I]t appears Deloitte (the implementation partner) brought unqualified resources (i.e., personnel) to the project.” [FN2, pg. 28].
    • I personally encountered one of these fakes as a project manager for another company looking for a workflow resource.  Their ABAP and SAP skills were horrible but they got a great reference from LAUSD.
  • Lack of cooperation with the Teacher’s Union and no user buy in.
    • This is a project planning and change management issue; the company and the integrator bear this responsibility.
  • Has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: SAP implementation vendors and partners may allow margin desires to override quality to the point of presenting significant project risks.  It is critical to evaluate every consultant any integrator brings onto your project.  There are just too many fakes in the marketplace that do not have proper background checks.


[FN1]  SAP, Waste Management settle lawsuit.  Business Week. May 3, 2010. (retrieved 5/11/2010)

[FN2]  Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School.

Popular Searches:

  • sap implementation failures
  • waste management erp sap case study first publication in 2008

Related Posts:

SAP ERP Project Failure Lessons Learned and Mini Case Studies 1

December 13th, 2010 by

ERP Project Failure 1

The following SAP project failures are the first three of nine or ten we will review over the next few weeks.  The SAP project failures we will review were high profile examples with significant lessons to be learned.  In nearly every case where the SAP implementation actually occurred, within 1 to 2 years after the troubled go-live the SAP software itself was reasonably well-received and the business was generally satisfied.

I apologize for the timing of these posts so close to the Christmas and New Years seasons but considering that a number of new SAP or other ERP projects are starting in the first quarter of next year I didn’t want to wait.


One interesting feature of the SAP project failure research is that none of them I could find can be attributed to the actual SAP software itself.  Although a few customers claimed it was the software when doing more thorough research I have only found structural problems with the project itself and not directly attributed to the software. After all, as of this post, SAP software has been installed or implemented over 100,000 times.  Careful research shows that none of the high profile SAP project failures were related to technical failures of the standard software, SAP architecture, application depth, or the breadth of the application.

Problems with SAP projects from the published literature usually involves:

  • poor project management and control,
  • little or no change management,
  • poor training,
  • significant custom coding, or
  • poor consultants from the SAP system implementation partners or vendors.

This sampling of project failure issues will start from the most recent to some of the older ones.

SAP ERP Project Implementation Failure Overviews

Marin County California – SAP ERP project failure overview (2009)

Financial, HR, and Payroll systems were implemented by Deloitte.  This project led to a lawsuit filed by Marin County (the customer) in 2010 alleging fraud.  For example, from the introduction to the Marin County legal complaint Marin notes:

Deloitte [claimed to have] assembled a team of its ”best resources” who had “deep SAP and [business] knowledge.”  These representations were fraudulent. Indeed, at the time Deloitte made them, it knew that it did not have the ability or intention to provide the skilled resources necessary to deliver a successful SAP implementation… Deloitte also knew that because the County did not have any prior ERP implementation experience in general, or SAP experience in particular, it  would be depending on Deloitte to oversee, guide and manage the project.  Notwithstanding such knowledge, Deloitte made these false representations in order to obtain the contract for the County’s lucrative SAP project.  [R]ather than providing the County with SAP and public sector expertise, Deloitte used the County’s SAP project as a trial-and-error training ground to teach its consultants – many of them neophytes — about SAP… software, all at the County’s expense.

A number of significant problems were caused throughout the project and Marin County is in the process of abandoning its SAP software implementation.

  • Fake Consultants / Trainees / unqualified consulting resources on the project
  • Pay rates, payroll, and wage information were incorrect.
  • Huge amounts of custom coding to replace standard SAP functionality (which Marin County claims would have been sufficient).
  • Inability to easily make adjustments and resolve compensation issues (much of this because of custom ABAP programming).
  • Insufficient training and change management.
  • Lawsuit claims improper relationships and ethical problems with the Deloitte and Marin County employees involved in the project.
  • Has since announced they are abandoning the SAP project after working for a couple of years to resolve the underlying problems.
  • Lawsuit is still ongoing and proceeding slowly in Marin County, CA.

Lessons Learned: Throughout the legal complaint by Marin County against Deloitte Consulting there were allegations of fraud with the consultants they provided.  Taking the Marin County complaint at face value they knowingly provided inexperienced and incompetent consultants for the government project.  Worse still, at least according to the complaint, this was done knowingly and deliberately.

For more information on the required skills, as well as how to screen and interview good SAP consultants please see these posts:

Screening and Interview Methods to Find the Right SAP Consultant
Screening and Interview Methods to Find the Right Consultant – Part 2

Shane Company – SAP ERP project failure overview (2008)

  • Shane Company had 23 stores in 14 states and filed for bankruptcy in January of 2009.
  • Shane initially blamed their company bankruptcy on SAP as a software application suggesting that their bankruptcy was partly due to SAP project cost overruns and SAP project delays.
  • The initial project cost was budgeted or planned for $10 million but ended up costing approximately $36 million and was planned for 1 year but ended up taking approximately 3 years [FN1, pg. 26]
  • After initially blaming SAP, Shane later admitted that their (“low cost”) SAP system implementation vendor, Ciber Novasoft, was more responsible for the SAP project failure than the SAP ERP software.

To summarize Shane’s SAP ERP failure “Enterprise Matters” offers succinct insight:

[L]arge enterprise systems, that have been installed in thousands of companies, don’t cause customers to lose money due to implementation failure (This is true for SAP, Oracle, and everyone else). It takes the customer’s managers, usually aided and abetted by a company like Ciber, to get it really wrong. [FN2]

Lessons Learned from the Shane Company SAP ERP project failure [FN3]:

  • Poor SAP ERP management, both on the project management side and the Shane Company senior management.
  • An improper budget and implementation plan.
  • Scope and cost were not properly managed.
  • Poor or undefined processes along with poor or untested system functionality.

For more information on proper scope, management, and project oversight see the following posts:

Aligning SAP Scope to Meaningful Business Requirements
Effectively Scope Your SAP Project
SAP System Vendor Project Success Criteria & Factors 2

Select Comfort – SAP ERP project failure overview (2008)

Select Comfort is included as a recent example of an SAP project that was abandoned rather than actually failed.  As a brief summary: the entire project was improperly conceived from the beginning because there was no pressing business need to change systems; a new CIO initiated the project; the scope was massive (ERP, CRM, SCM, APO, etc.); and the project was performed only by internal employees.

I’m sure there are other factors but it is obvious this project was destined to fail from the beginning.

Lessons Learned: Enterprise applications should be implemented one at a time (or at least very limited), scope must be carefully managed, and there should be a proper justification or business case for enterprise applications.


[FN1]  Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School.

[FN2] Shane’s Blame Game: Management, Not SAP Retail, Sinks Jewelry Company

[FN3] Some of these were derived from: Shane Company: Lessons Learned From an ERP Implementation Failure

Related Posts: