There has been a lot of press surrounding the lawsuit that was filed by Bridgestone against IBM for $600M. Typically, situations like the one with Bridgestone and IBM do not make it to such a public forum because it usually ends up being bad PR for both companies.
There is reasonable probability that this suit will never make it to trial, as cooler heads will likely prevail before more dirty laundry is aired. With that in mind, I thought it would be interesting to position myself in a hypothetical jury box to evaluate each side of the argument. Not so much to determine who was right and who was wrong, but to discover the lessons that companies can learn from being in similar situations.
IBM and Bridgestone appear to have a long standing relationship that dates back to at least 2000. In 2009, IBM was contracted to provide a SAP based OTC (Order to Cash) solution for all of Bridgestone’s North American business units, replacing a Cobol based legacy system. The estimated cost of the system was to be less than $50 million dollars with an implementation time frame of approximately 17 months.
Bridgestone went live with the solution in January of 2012, $30 million dollars over budget and 5 months later than planned. In the law suit that was filed Bridgestone alleged that the implementation created a major disruption to its ability to serve customers and threw its logistics and supply chain operations into chaos. Bridgestone estimated that profits of $75 million were lost in the first 6 months of 2012 and that it incurred an additional $38 Million in additional expenses to bring the situation under control. At the foundation of Bridgestone’s complaint is the assertion that IBM did not apply talent that was consistent with contractual obligations and that IBM was fraudulent in its reports regarding the ongoing status of the program. Bridgestone claims that with sufficient information regarding the situation that different decisions would have been taken regarding the readiness for a go-live.
IBM shot back in a very public fashion, which is unusual in these types of situations. In its response, IBM contended that Bridgestone “lacked leadership” and that things were mixed up by previous computer consultants and IBM was called in to fix it. IBM alleged that Bridgestone refused to do the necessary testing and that IBM warned Bridgestone about bugs and recommended the go-live date be pushed back until those bugs were fixed.
In most scenarios like this there are lessons to be learned. So what lessons can be inferred from the information that has already been made public?
Lesson 1: Lack of executive engagement and accountability can create a death spiral.
IBM claims that Bridgestone changed its CIO 6 times over the course of the 2 year implementation. From my own research, I concluded that Bridgestone’s CIO position was filled 9 months prior to go-live with an individual from outside the Tire and Rubber industry. This individual lasted 1 year in the job before leaving. In the suit, Bridgestone states that IBM delivered risk warnings to the CIO, leading me to conclude that this individual was the sponsor. Frequent shifts in sponsorship, in particular to those that are not deeply familiar with the operations of the business, puts the project at risk as the sponsor’s ability to judge and decide will be tested by those in project leadership roles.
IBM is not clean on this issue either. In IBM’s pubic response to the suit, IBM stated that they made concessions to Bridgestone for some of the problems that arose on the project. In exchange, Bridgestone provided IBM a release from possible damages. Clearly, with this release, IBM’s overall accountability was reduced and therefore lessened their motivation to succeed.
Lesson 2: Utilize a 3rd party to assess the qualifications of those assigned to the program.
Bridgestone claims in the suit that IBM put less than qualified resources on the project. There is some merit to this claim as IBM removed one of the chief architects from the program following its own internal review. IBM claims that Bridgestone did not allocate the resources to test or sign-off on designs. While it is not apparent if these assertions were made early on in the program or not, it is clear that neither side believes that the other reacted in such a fashion to conclude that the problems were resolved. One technique to assure that the SI is applying the talent at the level required is to include staff on the clients team from a 3rd party that has the necessary qualifications to evaluate the talent assigned. See our blogs on staffing for more insights on building your team.
Lesson 3: High quality testing and issue remediation is not optional.
The documentation provided from both sides point toward a lack of testing. IBM states that Bridgestone did not adhere to its own standards for testing readiness and failed to conduct the required user testing necessary to understand how the system would work under real world conditions. Bridgestone claims that IBM did not fully test the system nor understand to the extent which the system would fail. In any case, it appears that testing was sacrificed for budget and schedule reasons. A reminder that you can either pay me now or pay me later – and later is going to be a lot more expensive.
Lesson 4: Pay close attention to program controls and governance effectiveness.
IBM claims that Bridgestone was slow to approve designs and provide the necessary resources for testing. Bridgestone suggests that the project tracking tools were inadequate and did not provide proper insight into how long problems had been open. Issue resolution response time as well as design validation/sign-off performance are a great early indicator of expected program performance. This is not to suggest that users should simply sign-off to stay on schedule, but clear identification of issues and resolution through the proper governance channels is an earlier predictor of program success or failure.
Lesson 5: Don’t ask the fox to watch the hen house.
Several references in the Bridgestone claim suggest that Bridgestone had requested program reviews from IBM. Bridgestone alleges in its suit that IBM repeatedly put forward that all of the problems and issues were the fault of Bridgestone. It does appear from the suit that IBM did find fault in some of their own practices and took action. Despite this, it does not appear that Bridgestone was ready to listen to what IBM might have said and was predisposed to what was wrong and assumed that IBM was biased in its review. An impartial risk review conducted by an unbiased 3rd party would have likely helped in this scenario. Program audits can be leveraged if applied appropriately to strengthen the project team and improve the probability of success.
Lesson 6: There is no room for hubris and brinksmanship when your business is at stake.
This program has all the earmarks of putting budget and schedule ahead of operational continuity and benefit capture. IBM had waited until 3 days before the go-live to state that the go-live was a bad idea and Bridgestone apparently was ignoring its own standards for making the go-live decision. Once the decision was made to go-live across all of Bridgestone North America in a big bang fashion, then there can be no compromises made in preserving operational integrity. It would appear in this case that the decision makers were obliviously unaware of the potential operational risks, or were incapable of properly making the tradeoffs between further delays vs. the impact of a poor go-live. Please reference our blog “Into Thin Air” to gain a greater understanding on how biases can have an impact on even the most experienced decision makers.
The final lesson to learn is that unfortunately sometimes parties that agree with the best intentions end up in court. To protect yourself, make sure that your contract terms are consistent with industry best practices, and then follow-up with diligent contract adherence practices to improve your chances of having the upper hand in a potential litigation situation.
If you would like to learn more about how UpperEdge has helped companies assess and avoid large IT transformation project risks, or if you have any questions or comments, please do not hesitate to contact [email protected].