If you think Monday's court ruling that IBM owes the state of Indiana a whopping $128 million in damages is the end of a long and tired saga, think again.
To understand the longtime feud, we have to go back to 2006 and the early stages of the cloud-based digital transformation. With its welfare system in shambles, the state of Indiana contracted with the IT giant to overhaul and automate the processing of applications for state programs such as Medicaid and food stamps.
An August 2006 report showed that the Indiana Family and Social Services Administration (FSSA) ranked among the worst in the nation, with a full 35 percent of Medicaid long-term care applications approved by FSSA containing errors. In addition, there was a backlog of more than 13,000 people whose Medicaid applications essentially timed out and were stuck in limbo. The report also found that more than 15 employees had been arrested between 2003 and 2006 for fraud, with each case costing taxpayers about $50,000.
Then Governor Mitch Daniels, under intense pressure to reform Indiana's welfare system, demanded the FSSA find a vendor to help them modernize the eligibility process.
"The status quo is simply not acceptable. Indiana has the worst record of welfare reform in the entire country," said Daniels. "We have dedicated employees, but our welfare system is slow, cumbersome, inaccurate, inconsistent, and conducive to waste and fraud. It continually fails recipients and taxpayers alike and must be changed."
The $1.37 billion deal proposed privatizing and automating the system, with an IBM-led team of vendors working to process applications for food stamps, Medicaid, and other benefits that residents could submit through call centers, fax and the internet. At the time, it was an advanced concept--sort of a precursor to the solutions-first mindset of today.
Less than three years into the 10-year deal, the state pulled out of the contract citing lost documents, inaccurately processed applications and extensive wait times. In turn, IBM accused the state of mismanaging the program. Indiana had already paid Big Blue $437 million, and the two sides took the squabble to the courts.
In 2012, a Marion Superior Court judge awarded $52 billion in damages to IBM, only to have the Indiana Court of Appeals reverse the decision. The case headed to the Indiana Supreme Court, which ruled last year "that IBM was owed around $50 million for certain unpaid fees and equipment charges, but rejected over $53 million of IBM’s other claims, and held that IBM had breached its contract with the State as a matter of law."
On Monday, the court made a final determination of damages. IBM's $128 million judgment was offset by about $50 million in fees owed by the state. At the end of the day, IBM owes Indiana around $78 million. In theory, at least.
The tech behemoth said it will appeal the ruling and that it believes the decision "is contradicted by the facts and the law."
Not a one-off for Big Blue
This wasn't an isolated incident for IBM. The state of Pennsylvania similarly terminated a contract with the company in 2013 after an independent study of efforts to overhaul Pennsylvania's unemployment compensation system determined that there were "unsolvable" problems with IBM's solution. At the time of cancellation, the contract was an astounding 42 months behind schedule and on track to exceed its $106.9 million budget by $60 million. The state took IBM to court over the matter in March
The tiff was an echo of the Indiana case, with both sides claiming the other was to blame for the project's failure. The Carnegie Mellon report didn't help clarify things, stating that both sides had failed to execute. For example, it accused IBM of failing to adequately test its software, but said the state failed to apply appropriate standards and allowed software with known defects into production. In addition, while the state failed to apply adequate procurement specifications, the report also blamed IBM for accepting such a poorly-defined project in the first place. And both sides failed to establish success metrics and KPIs for the whole kit and caboodle.
Both the Indiana and Pennsylvania sagas might hold some important lessons for solution providers, even (especially?) those without IBM's deep resources.
Solving for a customer's business outcomes, rather than just providing a product, is a process that holds a great deal of room for error for undiscerning project managers. For channel firms trying to establish a solution provider practice while avoiding the costly mismanagement, Big Blue's $128 million mistake could prove invaluable.
- Understand your customers' business. Arguably the biggest goof IBM made in this whole mess was failing to really internalize the unique culture of Indiana's FSSA and Pennsylvania's Department of Labor and Industry. Both agencies were deemed to lack the experience necessary to guide massive system overhauls, a critical ingredient to a successful implementation. This lack of direction seems to have been compounded by the weight of government bureaucracy and legacy systems that were dependent on paper files and manual processes, putting a huge additional workload on top of an already complex project. Before entering into any implementation, make sure you understand your customer's unique culture and the roadblocks that are built into their businesses. In order to be a 'trusted advisor' to your clients, you have to assume responsibility for ensuring the project has the oversight and expert direction required to succeed.
- Know what you don't know. Don't wait until a project is four years and tens of millions of dollars out of scope before admitting you need help. At some point, the consequences for failing to acknowledge mismanagement or an inadequate understanding of the project begin to outweigh those before tipping your hat to the elephant in the room. It might hurt to admit you under or overestimated the project, but it's better to bring foundational issues to the forefront of conversations and, if necessary, solicit third-party help than bleed your and your clients' pocketbooks dry.
- Identify measures of success at the outset. How do you know you've accomplished your goal if you don't even know the goal you're working toward? It's one thing to have a productive iterative process, and other thing entirely to just wing it. Set KPIs not only for the entire project, but for regular milestones, as well. If you're off track, it's better to know it sooner than later.