IBM Counters ICL Lawsuit with Strong Defense

What it Means for ICL and What Can be Learned

Late in 2018, Israel Chemical Limited (ICL) filed a breach of contract lawsuit against IBM in a Tel Aviv district court.  UpperEdge provided a summary of this case in March informed by ICL’s lawsuit and other publically available materials.  Since that posting, IBM has submitted its proposed defense to ICL’s suit and countersued for additional fees owed by ICL to IBM.  UpperEdge has obtained copies of the lawsuits and translated from Hebrew to English.

In summary, ICL has presented a case that IBM misled them regarding the overall expected cost of the system and provided low-quality resources and a ‘buggy’ system.  ICL claims that IBM was in breach of contract due to these factors and that IBM directly benefited from the poor advice they provided.

IBM has presented the case that ICL proceeded through the project with eyes wide open signing off on process designs and change orders as business decisions were made.  IBM argues that the primary reasons for project failure were attributable to the company’s deviation from a global platform and the program no longer being viable given the change in ICL’s business strategy and direction.  It further states that ICL’s method for terminating the contract does not allow for claims of breach.

The remainder of this blog summarizes the major arguments made by ICL and IBM in the translated documents and provides our analysis of likely outcomes of this case and lessons that can be learned.

For even more details on this case, download the white paper, “A Hazardous Waste – Israel Chemical Limited’s SAP Implementation.”

Major Case Arguments

Project Cancellation

ICL Claim – The ICL Board of Directors canceled the project due to the system’s readiness and future costs.  The company had identified significant risks related to the suitability, complexity, and readiness of the system.

IBM Defense – The project was canceled due to the overall poor performance of the company citing that other projects were canceled at the same board meeting.  IBM argues that the overall direction of the company had changed with the ouster of the CEO and that the project was no longer in line with ICL’s strategic direction.

Method of Contract Cancellation

ICL Claim – The company terminated the series of agreements while maintaining its rights and claims.

IBM Defense – ICL did not cancel the contract under the terms of breach.  IBM cites that the contract stipulates that if ICL felt IBM was in breach, IBM would have been given the contractual time stipulated to remediate the identified breach.

Project Status Reporting

ICL Claim — IBM was hiding the true status of the project from ICL.  IBM was hired as an expert and should have known that the project schedule and budget initially identified were not realistic.

IBM Defense – ICL is not a small company and is well equipped to understand the status of the project.  ICL spent $37M on SAP, Deloitte, EY, KPMG, and PWC to provide independent validation services.  Their CFO provided an affidavit in defense of the shareholder’s lawsuit that the project was well controlled by ICL.

Project Accountability

ICL Claim – According to the RACI matrix which defines the division of labor and responsibilities between IBM and ICL, IBM was responsible for the vast majority of the work, including the professional aspects of implementing the system.

IBM Defense – According to the RACI matrix, ICL was accountable (also as the approver or final approving authority) and is the one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegated the work to those responsible.

Missing Requirements

ICL Claim – Many requirements were missed as a part of the global design that was not discovered until user acceptance testing.  This caused significant delays in the program.  IBM’s process for requirements identification was flawed.

IBM Defense – ICL’s business was unable to adhere to the global design that was agreed to as a part of the blueprint and signed off by more than 200 ICL associates that were identified as the verification committee.

Project Guidance and Advice

ICL Claim – IBM provided bad advice throughout the project and should have understood the complexities and challenges that ICL would be faced with.

IBM Defense – ICL understood the complexities and challenges as evidenced by their own reports to the board.  IBM informed ICL of the risks of each of the major decisions that were made on the project, and ICL signed off on change orders that were the result of ICL’s own decisions.

Quality of System Delivered

ICL Claim – The system delivered by IBM was of poor quality as evidenced by the poor testing results during integration and user acceptance testing.

IBM Defense – Four lines of defense are presented here:

1. The error rate identified by ICL is inflated by 300%
2. The contract does not specify an error rate expected
3. A large portion of the errors are related to the quality of the data (provided by ICL)
4. The criteria for acceptance had changed from global design to local acceptance

UpperEdge Analysis

Based upon our view, ICL’s goose is cooked.  What appears to be clear here is that ICL’s line management was not aligned with the CEO’s view of a global platform with common business processes throughout the organization.  With the number of 3^rd parties engaged, it is unlikely that ICL was not aware of the risks associated with change management, the quality of the data, and the decisions to restructure the business mid-project.

Statements made by ICL’s CFO in defense of a shareholder’s lawsuit illustrate that ICL was in complete control and that the decision to cancel the project appears to be directly linked to the performance of the business.

Key Takeaways for Our Clients

1. New IT systems are enablers — not the solution. ICL appears to have treated the Harmonization Project as purely a systems project rather than a component of a more comprehensive transformational effort.  The process redesign mandated by a change in overall business approach in Europe indicates that these were considered two independent efforts.  The lack of initial alignment clearly contributed to the project delays and likely, many of the design flaws identified with the pilot implementation.
2. Client project teams must own the design. The use of validation committees to confirm designs can be very ineffective if the initial design team is not 100% invested in design.  This project team investment does not typically happen unless the design team understands that they will be required to eat their own dog food.  ICL got this right only when they put an operating leader in charge of the project.
3. Every large business has complexities associated with local operations and markets. The concept of global designs being applicable at a local level are not achievable without significant alignment of management driven from the top down.  This miscalculation in local complexity often results in optimistically low initial budgets.
4. Accuracy and transparency in status reporting is critical to holding vendors accountable. There is a tendency of project teams to amplify the good news on projects and minimize the bad news.  SI’s tend to log issues that are related to client performance and often discourage clients from logging SI performance as issues.  ICL appears to have a history of rosy project reports to both the board and the shareholders.  These positive status reports will provide a powerful defense for IBM.
5. Contractual vendor performance standards matter. From the information presented in the lawsuits, there does not appear to be specific vendor performance standards that were established within the contract.  Vendor performance standards can take the form of phase exit criteria, productivity standards, and client enablement responsibilities.
6. Data readiness is always the long pole in the tent. Based upon the problems in integration testing, ICL appears to have been nowhere near ready to go-live.  ICL’s strategy for growth through acquisition likely resulted in a significant amount of effort dedicated to master data rationalization; this would have been a necessary component to achieve the planned synergies.
7. Establish readiness criteria across all aspects of the program through each phase of the program. It is not clear from the publically available documents on this program that there were tracking metrics on user readiness, data readiness, deployment readiness, technology readiness, etc.  These metrics help provide balance to project team priorities and can help companies avoid late call-offs of implementations, providing system integrators with more time to complete their activities on the client’s dime.

Comment below, follow me on Twitter @jmbelden98 find my other UpperEdge blogs and follow UpperEdge on Twitter and LinkedIn.

Related Posts

• A Hazardous Waste: An Overview of ICL’s Failed SAP Implementation
• Don’t Become an ERP Horror Story – Implement Solid Risk Management 
• Hertz Takes Accenture Out of the Driver’s Seat
• Dirty Little Secrets of your System Integrator: Why Companies Still Go Over Budget
• Exploring the “Unknown Unknowns” in IT-enabled Digital Transformation Estimates