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,
- Here you can see the Hewlett-Packard example listed below (2004).
- In the first post of the series it was the Shane Company (2008) (SAP ERP Project Failure Lessons Learned and Mini Case Studies 1).
- And then finally in the second post it was Levi Strauss & Company (2008) (SAP ERP Project Failure Lessons Learned and Mini Case Studies 2)
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. http://www.r3now.com/literature/2009-Bhagwani-SAP-Project-Success.pdf
[FN2] SAP implementation contributed to HP shortfall. Computerworld, August 12, 2004. http://www.computerworld.com/s/article/95223/SAP_implementation_contributed_to_HP_shortfall