Business Solutions with SAP

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:

The Consultant Certification Ruckus

October 4th, 2010 by

Training and CertificationHere we go again.

Jon Reed, Dennis Howlett, Martin Gillet, Michael Koch, and Leonardo Di Araujo, collectively known as the Certification 5, have posted a 55-page, somewhat discoordinated white paper exploring the need to vastly upgrade the SAP consultant certification process.

The article even got the attention of Larry Digby, Editor in Chief of ZDNet;post-33369

Given the prominence of all of the above, it is certain that this work will be seriously scrutinized by SAP as there is still a perception that too many of the SAP consultants in the field are short on the requisite skills. As it happens, the whole subject was kicked back into high gear about a year ago when (then) CEO Leo Apotheker had this outburst in front of reporters and bloggers:

“I don’t give a s**t if it’s Accenture or IBM. I care about the customer. I find it shocking people are walking around talking to customers and have no experience on [SAP]. [Consultants] get hired by people and have no clue. It’s annoying but that’s a fact. Let’s start by certifying people,” said Apotheker. “If we believe [a project] takes 500 days and another partner says it’s 5,000 days I’ll do it for 500 and a fixed fee.”

While I would welcome tighter certification of individual consultants, even the Certification 5 tend to focus on technical skills (DiAraujo elaborately argues against the viability of testing “soft” consulting skills.) All the same, I remain convinced that it’s the systems integration firms that require certification. We all know that even with a team of highly qualified consultants, a single crappy project manager can drive a project into the ground. This was my argument a year ago and it remains my argument today.

If certification is focused on SAP technical acumen alone (without business knowledge), the certified term should not be “consultant”. 

Engineers without business knowledge often build beautiful and efficient bridges to nowhere.


It’s long past time some of the lack of talent in the consulting world finally got real scrutiny.  And it is way overdue for SAP to offer an actual transcript service for any consultant who claims to have had training or certification.

For the current crop of high quality training companies out there that offer SAP training, maybe SAP can provide a “certification” or logo program for them and include their classes and training in its transcript service.  SOMETHING has got to be done to improve the quality of the consulting field because there are way too many snake oil salesmen out there with too much hype and not enough skill.


Republished from Michael Doane’s Web Site:

Related Posts:

Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1

June 24th, 2010 by

Change Management and Knowledge Transfer

Why SAP Process Understanding, Troubleshooting Ability, and Knowledge Transfer Techniques are Missing in SAP or ERP Projects

Because an ERP system like SAP has a single database or a single instance of data, a full process chain of dependencies is developed.  Every organizational function becomes dependent on the process steps before and after it no matter what department or area is responsible (Kallinikos, 2004).  Because of these dependencies, a data error is no longer contained in a single isolated system as in times past.  Each data error, or each problem that occurs has both upstream and downstream consequences and the corrections cannot be made in isolation. Improper configuration or system design can have huge impacts on the amount of effort to correct the data and to maintain the system in an ongoing fashion (Sia and Soh, 2002).

A good consultant’s role on an SAP or other ERP project is to guide the company through design decisions and make the system settings to support those design requirements.  This is usually called the “implementation” process.  During this process they should be focusing on knowledge transfer as well.  However, many of the “consultants” who implement SAP or other ERP systems have little process or troubleshooting understanding (see A Cautionary Tale About SAP Knowledge Transfer).  As a result of this lack of consulting experience, or of the number of fakes in the marketplace, knowledge transfer is usually not sufficient.

Speaking in technical terms may make a consultant SOUND smart or knowledgeable, but it does not mean they ARE smart or knowledgeable. The mark of experience, intelligence, and knowledge is the ability to make the complex or technical seem simple or at least understandable.

For long term business benefit and ROI your implementation vendor must provide consultants with solid overall process understanding.  Without this process understanding, as well as their module specialization, those consultants will not  be able to achieve a process oriented implementation.  If they do not have a process understanding how will they help you realize any process efficiencies or improvements during the design process?  Without the overall process understanding how can they guide your company through the change management process needed for competitive business transformation?

If you fail to demand that the SAP implementation vendor provides strong end to end process consultants your company will struggle with day to day operations after the consultants are gone.  Without those strong end to end process consultants your transition to proficiency with the system will take much longer and be more difficult.  In the end any increases in productivity, or in business value will take much longer to realize, if you ever realize them.

SAP systems are typically implemented for business transformation.  That transformation generally is related to process improvements, automation, and customer focus; to address competitive pressures and business value propositions.  One of the most important components of that business transformation effort is the change management and knowledge transfer (however you describe those activities).

Achieving SAP Maturity by Using the Correct Knowledge Transfer Techniques

Business transformation and change management techniques are often described by many different names:  knowledge transfer, learning organizations, sustainment, production support, knowledge management, agile enterprises, etc.

There are a number of quality change and training programs available for SAP projects but few of them achieve a level of competence needed for an SAP Center of Excellence.  As the next post lays out, Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2, change management and knowledge transfer for business transformation requires several activities.  A more complete list of knowledge transfer methods includes:

  1. Transactional processing (typical keyboard training).
  2. Business process understanding (some projects use this method with transaction flowcharts for showing dependencies).
  3. Master data dependencies (few projects do this level of end user training because it is generally the implementation consultants who have this level of understanding).
  4. Operational processing (fewer projects still do this type of training because this is the production support “troubleshooting” type of training that requires seasoned consultants to be on site long enough to help users work through the issues).
  5. Ongoing knowledge transfer activities such as ad hoc troubleshooting meetings with all affected users (work through problems as a group in a conference room).
  6. Continuing communication about tips and tricks after the system is live.

For long term success in the marketplace, beyond the operational excellence proposition, a continuing change and transformation program needs to be undertaken after the system is live.  This requires post production support efforts to begin evaluating real areas of opportunity in the marketplace.  Organizational and business change is no longer an option, as Mike Myatt notes, it is an imperative in today’s global economy (see Leading Change and Change Management

Poor Knowledge Transfer Planning or Methods and Implications for Long Term System Support and Cost

One of the biggest workforce readiness problems with any SAP implementation is that the consultants who implement the system rarely have any significant production support experience.  Without that production support experience, and the end to end process understanding, it is impossible for meaningful knowledge transfer techniques you need for long term success.  Without the understanding of support they are unable to address items 4, 5 and 6 listed above.  And without that complete level of knowledge transfer organization maturity takes much longer.

That lack of production support experience (and I do not mean the month or two after go-live, but longer term support) means these consultants don’t know how to design a solution that avoids some of the “lessons learned” from the past.  They do not know how to prevent you from “driving off the road” with your solution after you go live because they have never had to live with the decisions and “solutions” they have provided.  Most of the consultants who come to these projects do not understand how to untangle, resolve, or fix problems that occur in the system when it is productive (cf. Scott and Sugar, 2004).  Because they aren’t even aware of what to expect in a live environment they don’t have any basis to transfer that knowledge of troubleshooting techniques or methods to you as the customer.  As a result your support pains may be far greater and last much longer than you anticipate.

This same lack of consultant experience with post-production issue resolution prevents them from being able to transmit operational understanding to you, the client.  In other words, consultants without deep and broad experience are not capable of ensuring you have a relatively smooth go-live.  So not only do they fail to design solutions that are more streamlined or automated, they have little ability to ensure you have a smooth go-live experience.  When you combine this lack of support experience with the number of outright fakes and frauds in the SAP consulting space it is no wonder there are so many unhappy ERP customers (see Screening Methods to Find the Right SAP Consultant Part 1).

My experience has been that consultants who lack this broad and deep experience with production support rarely know what needs to be tested before the system is live.  And without adequate testing you can expect to find ongoing data and system design or setup problems for some time after you go live.

How Do You Remedy the SAP or ERP Knowledge Transfer Plans and Methods to Support Change Management Processes?

  1. If the consultants speak in overly technical terms, have a language barrier, or if there is a lack of overall process understanding ask your SAP implementation vendor to replace them (see Screening Methods to Find the Right SAP Consultant Part 2).  Speaking in technical terms may make a consultant SOUND smart or knowledgeable but it does not mean they ARE smart or knowledgeable. Baffling the uninitiated with technical jargon is a classic smokescreen to mask inexperience and incompetence. The mark of experience, intelligence, and knowledge is the ability to make the complex or technical seem simple or at least understandable.
  2. Communicate to ALL internal company project members before the project begins that they will be responsible for long term support and training of end users.  Let them know that they must immediately notify project management if any consultant(s) have significant barriers to transferring knowledge or understanding.  This must be communicated early in the project because by the time the knowledge transfer for training begins it will likely be very disruptive and risky to make the needed resource changes.
  3. If you need to remove a consultant don’t wait until the timeline is so tight it would create a significant project risk. Include a contract provision that if a consultant is replaced for lack of skill, language barriers, or other reasons related to skill, performance, or ability to ensure knowledge transfer that a credit for at least the prior 4 week’s billing is due (four weeks is reasonable for you to discover the problems and is not unreasonable to insist on a credit).
  4. Avoid customized or technical solutions for anything except mission critical requirements or for solutions that directly address business goals and marketplace competitive pressures (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).
  5. Use the RFI and RFP process to solicit comments, methods, tools, and resource examples of how knowledge transfer will be handled.  Be sure to leverage a Request for Information process and the RFP process as an educational experience (see Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts).
  6. Use the RFI process to ask for sample consultant resumes, and the RFP process to insist that final resumes for the actual project must be submitted.  Note in the RFP that any non-response may disqualify the vendor.  SAP is mature enough that there is no reason an SAP implementation vendor should have problems providing key resources.
  7. Check with client references from the consultant’s resumes who are submitted (and not the sales pitch references) for application skill, ability to do knowledge transfer and for change management skills.  Learn about  Protecting Yourself from SAP Consulting Fraud.
  8. Construct your services contract with an expectation of knowledge transfer (which I define as “operational independence”) or with a penalty for failing to do so.    For some ideas on how to structure a contract agreement to cover this see the section titled “Operational Independence is the Key Success Criteria or Measure of SAP or ERP Knowledge Transfer” toward the bottom of the post  A Cautionary Tale About SAP Knowledge Transfer.
  9. Be ready for a drop in productivity right after the system goes live.  However this should be a temporary situation and the better the knowledge transfer and change management has been the less pronounced and shorter the duration will be.  If done successfully there should be an improvement in overall productivity after a short (and shallow) initial drop.
  10. As you move into support mode after going live then begin to document the transaction processing steps necessary for fixing, resolving, or troubleshooting problems that arise.  Conduct weekly or bi-weekly training and knowledge transfer sessions to internal employees and provide different tips, tricks, or techniques for problem solving.  During the production support period helpful fixes, reports, or tools will come up to resolve issues.  These should be more broadly communicated.
  11. Monitor progress within each process area and continue to keep the communication program going within the company after the system goes live.


Kallinikos, J. (2004), “Deconstructing Information Packages. Organizational and Behavioral Implications of ERP Systems.” Information Technology and People, Vol. 17, No. 1, pp. 8-30.

Scott, J. and Sugar, D. (2004), “Perceived Effectiveness of ERP Training Manuals.” Proceedings of the Tenth Americas Conference on Information Systems, New York, pp. 3211-3215.

Sia, S. and Soh, C. (2002), “Severity Assessment of ERP-Organization Misalignment.” Proceedings of the Twenty-Second International Conference on Information Systems, New Orleans, pp. 723-729.

Related Posts: