IT Horror Stories & How to Avoid Them

In the last 10-15 years, IT has produced more than its fair share of horror stories – as this special report reminds us. There was the famous U.S. Navy-EDS debacle of several years ago, when EDS ended up writing off hundreds of millions of dollars. IBM has had its share of bumpy deals, including with Sprint Nextel and the State of Indiana.

Big ERP projects seem especially apt to turn into IT versions of Nightmare on Elm Street. Take the experience of Marin County, California. It hired Deloitte for a large-scale SAP implementation project, but the deal has simply not worked out, and the two parties are now in court. For its investment of $18.6 million, the client has received “a malfunctioning system, administrative lock-ups and headaches,” or so Marin’s suit alleges.

If you believe the client’s filings in the lawsuit, it’s all the vendor’s fault. Apparently, Deloitte “staffed the project with dozens of neophyte consultants, many of whom lacked even a basic understanding of SAP.” And given that Marin was unable to issue financial statements for two fiscal years, this does sound like a true horror story. Still, it’s clear that Marin’s IT and project leadership bears some responsibility. It needed to complete much greater due diligence and vet the specific consultants who were assigned to its project. As we point out here, talent is ultimately more important than cost as a difference maker between project success and project failure.

Then there’s the dispute between Oracle and Montclair State University. In this case, a $20 million project budget quickly snowballed up to $30 million, while milestones were missed and promised deliverables not produced. Here again, the underlying causes will not surprise anyone who has worked in IT– poor project management, wrong talent on the job, lack of agreement on toolsets and methodologies. And while it sounds like Oracle behaved badly, the issues in this particular horror story sound completely avoidable to us. Montclair State obviously needed a more rigorous and robust approach to initial project scoping, vendor evaluation and selection, and contract negotiation.

Specifically, Montclair State should not have allowed Oracle to begin project work without a comprehensive and detailed project plan that confirmed the implementation methodology and toolsets to be used, reporting and issue tracking protocols, and clear “go/no-go” milestones. There should have been contractual assurances that the project team would be trained and knowledgeable of the approach. Lastly, payments should have been clearly linked to performance milestones and/or specific deliverables. And it sounds like more definitive terms for ending the agreement would also have been useful.

In our experience, many clients skip over these critical details because they seem minor and it’s time consuming to finalize them – especially when there is real urgency to start implementing. But they simply cannot be overlooked. Consider how much time and heartache (not to mention legal fees) Montclair State and Marin County would have saved if they had nailed down these details with their vendors at the outset.

Not that the big IT suppliers make it easy to establish bulletproof contracts. They are happy to “just get started” and operate in gray areas. But that is all the more reason to insist on as much clarity as possible in contracts and project documents. In fact, vendors who are unwilling to work with you on finalizing these items are probably not going to be the best partners for you in the long run, especially when scope changes occur, as they invariably will.

Within ERP contracts, the trouble generally starts with the highly complex and frequently incomprehensible nature of pricing. In many cases, it’s impossible to know if a good deal is better for the client or the vendor. CIOs may not even know they’re starring in their own horror stories – until it’s too late. That’s why we believe senior IT leaders must arm themselves with knowledge.

While every IT project failure is a little different, they all serve as cautionary tales for large corporate clients. And industry veterans will recognize common subplots across these horror stories – lack of clarity in contracts, poorly aligned incentives and weak engagement between client and vendor. All of these factors prevent trust-based and mutually beneficial partnerships from forming. And when they are left unaddressed, you may face the very unpleasant surprise that you’ve hired Freddy Krueger & Associates as a key IT supplier.

2 thoughts on “IT Horror Stories & How to Avoid Them”

  1. Don't Become an ERP Horror Story Implement Solid Risk Management | UpperEdge

    […] do these examples of recent ERP horror stories teach us? ERP implementation disasters come in every shape and every size. They are not […]

Leave a Comment

Your email address will not be published.