PR finger pointing: IBM and Bridgestone wrangle over failed ERP

PR finger pointing: IBM and Bridgestone wrangle over failed ERP

Summary: In an unusual public relations strategy, IBM lashed out against Bridgestone over fault on an IT failure. Although one-sided claims on both sides lack credibility, there are important PR lessons to learn.

SHARE:

A legal dispute between tire company, Bridgestone, and system integrator, IBM, over a failed ERP implementation has escalated into a war of words between the companies. Instead of keeping quiet about the details, in accord with usual practice, IBM has taken a strident public position against its customer Bridgestone. This approach represents a break from how system integrators usually handle public relations when IT projects fail.

PR finger-pointing IBM and Bridgestone wrangle over failed ERP
Image from iStockphoto

Bridgestone Americas engaged IBM to install SAP software across the company. After spending $75 million for the system, Bridgestone claims it failed on going live, disrupting key processes such as inventory management and customer deliveries. Bridgestone says it was forced to hire SAP directly, to fix problems that IBM allegedly created, 

Ultimately, Bridgestone filed a lawsuit against IBM for $600 million, claiming $200 million in business losses and treble damages for fraud. You can download Bridgestone's legal complaint [pdf] here; much detail is redacted, which is surprising given how Acrobat handles such things.

It is extremely unusual for an integrator to wage a PR battle with its customer, regardless of how severe the situation. In typical IT failure lawsuit situations, the software vendor and system integrator respond with bland statements saying they always do whatever is best for the customer. Although customer actions lie at the heart of many IT failures, software vendors and integrators are reluctant to take an official stance disputing the customer's explanation of events. (It's worth noting that an individual IBM employee once took to Twitter to call a customer's claims blaming IBM for project failure "ridiculous.")

IBM's public response to the Bridgestone claims represents a significant departure from standard public relations practice in these matters. IBM's version of the story paints a harsh picture of Bridgestone:

Bridgestone filed a lawsuit claiming breach of contract and fraud against IBM regarding a recent SAP implementation. These claims against IBM are exaggerated, factually wrong and without merit. From the outset of this project, Bridgestone failed to meet critical commitments upon which the performance of IBM's obligations were predicated.

Ultimately, Bridgestone's repeated failures had a significant impact on the project's cost and schedule, and its decision to prematurely roll-out the implementation across its entire business negatively impacted its operations.

  • Bridgestone understood that this would be a challenging project. It had tried several times with other vendors and failed to upgrade its system. IBM was the only vendor to succeed in completing the upgrade to SAP.
  • Notwithstanding the complexity of the project and its negative history, Bridgestone failed to staff the project with people who sufficiently understood its own legacy systems and could assist IBM in designing and converting them into a new SAP system. Throughout, Bridgestone lacked the necessary leadership to effectively manage the project; it replaced its CIO on six occasions in a 2 year period during the project term.
  • Bridgestone failed to supply the necessary software, hardware and network infrastructure for the system to operate properly. In many instances, Bridgestone supplied inferior resources or no resources at all.
  • After insisting that it have control over the design and final approval of the system, Bridgestone failed to timely approve those designs, failed to provide the necessary design documents for IBM to complete its work, and failed to conduct the required user testing necessary to understand how the system would work under real world conditions.
  • IBM made concessions to Bridgestone for some problems that arose on the project and Bridgestone gave IBM a release. Bridgestone's suit reneges on its release
  • Bridgestone ignored the clear and repeated recommendations from both IBM and members of its own IT staff to implement a staggered roll-out of the new system to mitigate risks to its business operations. Instead, Bridgestone's management insisted on a "big bang" go-live in which all aspects of the SAP system were required to be implemented simultaneously, across all of its North American tire operations.
  • Bridgestone continued to demand that the system be implemented in this manner and on the scheduled go-live date, even after IBM had advised, for a period of at least six months prior, that the go-live date was premature and therefore fraught with business risk. As the go-live date drew near, IBM urged Bridgestone's management, in writing, to reconsider its decision. Bridgestone elected to proceed regardless of the identified risks, even after acknowledging that the system would fail to meet the go-live criteria that Bridgestone itself had set.
  • At go-live, the system did experience some of the errors that IBM had predicted. In response, IBM provided extra personnel and resources to quickly address those errors and operations returned to normal. Since the implementation, Bridgestone has achieved record-setting financial results.

IBM has implemented thousands of successful SAP projects and is consistently rated by Gartner and other independent analysts as the premier SAP implementation firm. IBM will vigorously defend itself in this matter.

The Business Insider article quoted above states that IBM's response offers "unusual internal insight" into a large IT failure. This point is actually wrong because almost every IT failures lawsuit, and the corresponding legal responses, includes detail and insight into the inner workings of the project. Even so, this detail is typically one-sided, making it almost impossible to discern what really happened from the lawsuit itself.

The article also quotes a McKinsey study stating that 45 percent of large IT projects run over-budget. The study also notes that approximately 56 percent of these projects do not deliver the entirety of their expected benefits, a critical dimension when evaluating any IT project.

Other research shows the range of failure to lie between 30 and 70 percent; depending on the particular study, the variability can be large. The difficulty defining common measures of success or failure on IT projects drives this broad range. Nonetheless, IT failures represent an enormous level of waste, which this blog has estimated at $3 trillion dollars per year worldwide.

On the surface, IBM's strategy seems reasonable -- attack Bridgestone's credibility by disputing claims in the lawsuit. However, my analysis indicates potential culpability on both sides. For example, Bridgestone says that IBM did not supply qualified resources throughout the project; if so, then IBM bears at least partial responsibility for the failure.

In theory, IBM's PR strategy could have worked but the execution fell short because IBM's claims seem equally unrealistic and one-sided as Bridgestone's. Although IBM's comments may be grounded in truth, they come across as little more than disingenuous legal posturing. The IT Devil's Triangle principle makes clear that no single party bears complete fault in most IT failures, so dramatic and one-sided claims in these cases generally are not accurate.

Since IT failures almost always arise from shared causes and responsibilities, PR messaging to the contrary is just not credible.

Disclosure: SAP is a client and sponsor of CxOTalk

Topics: CXO, Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

9 comments
Log in or register to join the discussion
  • IBM V Bridgestone

    The issues raised by IBM are common: most people ultimately supervising large IT projects do not understand IT. These "experts" think they understand IT because they can turn on their laptops and connect to the Internet. When they make stupid decisions they do not take responsibility for their actions but blame the vendor for all the problems regardless of fault.

    I suspect it is 55% to 45% blame to be assigned with it being uncertain who gets more of it.
    Linux_Lurker
  • Leadership?

    "Throughout, Bridgestone lacked the necessary leadership to effectively manage the project; it replaced its CIO on six occasions in a 2 year period during the project term."

    Four months as the average CIO tenure during this project? What else was going on that caused this turnover?
    ajbowles
  • Big IT projects are usually problematic

    One of the more informative articles regarding the start-up issues with the federal healthcare exchange site is a Computerworld article from October 21st titled "Healthcare.gov website 'didn't have a chance in hell.'" To quote:

    "The Standish Group, which has a database of some 50,000 development projects, looked at the outcomes of multimillion dollar development projects and ran the numbers for Computerworld.

    "Of 3,555 projects from 2003 to 2012 that had labor costs of at least $10 million, only 6.4% were successful. The Standish data showed that 52% of the large projects were 'challenged,' meaning they were over budget, behind schedule or didn't meet user expectations. The remaining 41.4% were failures -- they were either abandoned or started anew from scratch."

    ZDNet itself has noted many problematic IT rollouts: Apple Maps, Microsoft Surface RT and Windows 8.x, any government project involving Deloitte, and so on. You either deal with it and get it done, or else go play dice with the drawn-out courtroom battle route.
    JustCallMeBC
    • Good to have past failed projects to excuse another failed project

      If you know big projects are destined to fail, why not propose smaller projects. IBM should have known that this will fail if they really believe big projects are most likely to fail. They were just for the money and not for the success of the project
      Little Gremlins
      • That's goofy logic

        If you apply that sort of logic universally, then there is no reason to ever undertake any ambitious, complex project, from landing on the moon to building a bridge like the Millau Viaduct. As far as ambitious software/IT projects go, you can expect snags and problems -- it's how they are dealt with is the real test.
        JustCallMeBC
  • Turnover may be bad

    One sentence saying that Bridgestone replaced their CIO 6 times in 2 years tells it all. I have never heard of that happening anywhere. Can you imagine any project successfully implemented in the middle of that turmoil? The politics alone would keep many employees from doing their job, and it would be interesting to know the overall turnover at Bridgestone. Many people try to take advantage of IBM's size, thinking that they can go cheap on hardware and people, and then blame IBM for any problem.
    MominTN
  • Totalling Relying on any Vendor is Like Being a Fish in Barrel, with

    A major issue is that Bridgestone basically abdicated all responsibility to the vendor – IBM. Companies should not outsource the oversight to the vendor who is doing the implementation – that is a major conflict of interest. And it’s also asking for big trouble.

    In addition, Bridgestone readily acknowledged they had no experience, or key people with knowledge of enterprise-level package software implementations. You may not necessarily have to have people with the exact experience, but people who are familiar with the nature of the beast – SAP, Dynamics, Oracle, Siebold, etc. The share many issues in common. If you have to use consultants to provide advise, use a third-party that has no relations to the vendor.
    elizab
    • Are you sure?

      Not because your IBM too suck??
      建宏 賴
  • Taiwan High Speed Rail road Corp.'s ticketing system failed, too!!!!

    The IBM Taiwan here failed, too! During the period Taiwan High Speed Rail road Corp. building ticketing system, the IBMer even can't finish it!

    Because Archer Hwang, Marty Hsu, Simon Chen especially, said : "They don't read the textbooks! They're IBMer, and they worked for Fu-Shin Air, their Hong-Ding Yu's father was the general commander of Taiwan Army."
    And, ORDER me to work for that :
    https://docs.google.com/file/d/0B4zJys3uKtnaeE50VVdkRVB0cU0/edit?usp=sharing
    https://docs.google.com/file/d/0B4zJys3uKtnaT2NROGlDZEx5eWs/edit?usp=sharing
    https://docs.google.com/file/d/0B4zJys3uKtnaN1d0eVc2RktqVEU/edit?usp=sharing
    https://docs.google.com/file/d/0B4zJys3uKtnaN0F4VlJXQWxYTXc/edit?usp=sharing

    Besides, it's too late to stop me if you want, I posted these included source code files on different website of countries, yours CIA also included :
    https://drive.google.com/folderview?id=0B4zJys3uKtnadVRvd3dpMWk0RXc&usp=sharing

    Why? Why you still can't handle your chinks!?
    建宏 賴