What you can learn from IBM and SAP's legal imbroglios

A couple recent news items find SAP and IBM both in a bit of legal hot water.

U.S.-based über-trash-collector Waste Management Inc. is suing SAP for a whopping $100 million, alleging that the ERP vendor demo'ed some very convincing vaporware, covering up a fundamental inability to meet stated requirements.

Meanwhile, IBM has been suspended from any new federal contracts by the U.S. Environmental Protection Agency (EPA) -- an extraordinary, if likely temporary, measure -- after some alleged hanky-panky involving a failed contract bid and aggressive appeal. There's talk of potential criminal investigations of both EPA and IBM employees.

I don't know how either of these disputes will turn out, but from the news reports alone they raise several important issues for technology customers working with large (I mean really large) vendors.

In Waste Management's case, they might have saved themselves a world of trouble by performing their pilot before they signed on with SAP (something we always recommend), but at least they caught the problem early on, when measured in ERP-years.

I don't know what IBM did, but it seems like EPA thought Big Blue really crossed a line in their appeal of a failed contract bid. Federal contracting -- like so many things in Washington -- is a bare-knuckles sport. Threats of appeals and possible litigation by losing bidders can keep federal contracts officers awake at night. In this case, it appears EPA struck back.

Sure, small vendors can get difficult too. Customers frequently tell us that -- whatever the benefits of working with a smaller, more agile supplier -- their smaller vendors also tend to be more erratic and less predictable.

But big vendors can present some tough challenges. They frequently seek to make themselves a permanent part of your infrastructure, and then throw their weight around. Recently I've been accumulating anecdotes of Stellent customers unexpectedly encountering a much tougher crop of account reps at Oracle, after Oracle's acquisition of that Minnesota-based ECM vendor known for its friendly employees. I also find big vendors more likely to threaten "up the chain" -- all the way to C levels if necessary -- to appeal a lost bid or to suggest that a particular problem wasn't theirs, but rather stemmed from the customer's low-level employees failing to follow the vendor's prescribed best practices. Sometimes they're right, but often not.

Again, I have no reason to know whether IBM and SAP actually did anything wrong in these two cases, but you should remember that the larger the project and the bigger the supplier, if things go bad, the greater your likelihood of having to resolve problems using extra-normal means. Larger projects tend to beget longer vendor selection cycles and a tendency for customers to rush unduly through the final and sometimes grueling test and contracts phases in an understandable desire to "just get it over with," so they can start the real project in earnest. In actuality, this is where you need to take your time to make sure you've tied up as many loose ends as possible.

At the end of the day, you need to make sure you have the same kind of strong project leadership and accountability on your side that you expect your vendors to bring. That keeps you in control, keeps your suppliers' respect, and could well keep both of you out of court...

Other ECM & Cloud File Sharing posts

ECM Standards in Perspective

In real life I don't see ECM standards proving particularly meaningful, and you should see them as a relative benefit rather than absolute must-have.