Are IT malpractice suits around the corner?

Are IT malpractice suits around the corner?

Summary: Does Waste Management's lawsuit against SAP indicate the beginning of a bevy of IT malpractice suits?TechRepublic's Justin James makes that argument and it's worth noting.


Does Waste Management's lawsuit against SAP indicate the beginning of a bevy of IT malpractice suits?

TechRepublic's Justin James makes that argument and it's worth noting. Earlier this week I detailed and posted Waste Management's case against SAP. Much of it revolves around promises made by SAP and Waste Management's penchant to believe them.

But here's James' big point:

I think this case is the canary in the coal mine. Regardless of whether Waste Management wins the case, if the courts allow it to go to trial, programmers are in for a rough ride. Why? If the case is tossed out - particularly on a standard "no warranty implied" contract clause in the software End User License Agreement (EULA) - it means that these pieces of boilerplate legalese provide "cover" for our failures to deliver on a salesperson's promises. If the case makes it to trial, it means that any failed project is probably fair game for a lawsuit.

James, who says he will engage in a bit of CYA in his programming, continues:

Many doctors have to fend off baseless malpractice lawsuits from people hoping to make quick cash from a settlement, since these cases can be so expensive to defend. My fear is that we will soon see this type of environment in IT.

Suing for "programming malpractice" would be like suing an artist because your portrait isn't realistic or flattering or impressive enough for your taste. I hate to sound forgiving of the high failure rate in IT, but programming is not a cut-and-dried practice at this point. It's not like designing a light switch or a stepladder, where it is quite clear if the fault lies with the user, the designer, or the manufacturer.

Even when the project fully meets the specs, it rarely meets the user's needs, since it is so hard to write a perfect project specification and requirements document. In other words, even the most perfect project could be wide open to these kinds of lawsuits.

Even worse, "programming malpractice" suits could drive out what little innovation is left in IT. Programmers will not be willing to write new software unless their company has the deep pockets and slick lawyers to protect them. Open source projects will collapse, since the lack of incorporation will make the individual contributors legally responsible.

James got slapped around a bit on TR for overreacting, but his point is interesting food for thought.

More reading:

From ZDNet:

From TechRepublic:

Topics: SAP, CXO, Legal, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Merchantability is implied in any...

    product. It can not be written out in a contract or license. It is time for IT vendors, software or hardware or any combination, to be held financially accountable for their actions. Everyone else in the world is held accountable.
    • not cut and dry

      There are so many factors involved in the success/failure of a project, and rarely does any project depend solely on the IT group.

      Each case would have to go to court, the Requirements would be examined, and if the Customer/Plaintiff in any way contributed to the failure or extensions of a project (99% of the time), how do you hold the IT group responsible?

      There are deliverables and timelines for a reason - if they're not met, the pay is affected, or you fire them. A decent contract will address it.

      Your reputation in the field is what gets you business, and will be what loses business.

      If lawsuits become the norm, all IT will have to go in-house, because outsourced projects will need built-in legal costs, or else they'll have so many extensions/clauses in the contract that they'll be unmanageable.

      I'm sure, though, in our litigious society, that this will happen. Just means more jobs for IT people in-house, resulting in even poorer performance due to inexperience and lack of resources.
  • This is nothing new

    I spent a year at Andersen Consulting who through serendipity changed its name to Accenture years before Arthur Andersen became mired in the Enron accounting scandal dealing a fatal blow. AC was born from AA you see.

    If there is one thing I saw clearly it that AC was long on sales but short on delivering the goods. I left after about a year in 1995 and the experience stayed with me.

    If I could summarize things, it's the blind (Andersen largely incapable of following through) leading the blind (incompetent and bloated IT organizations).

    In the year after my departure there were several lawsuits against Andersen Consulting and the general charge was incompetence (and an awful lot of money drained).

    With my current employer IBM's consulting services were shown the door. This preceded my employment however.

    I have little respect for large consulting organizations. You create a genie. At some point it has little to do with delivery of solutions that truly change or empower your clients and more about having bodies at clients and billable hours.

    • Great insight

      I agree with much of that. And just as an aside the Accenture name change was probably the best business move of all time.
      Larry Dignan
  • RE: Are IT malpractice suits around the corner?

    This is a basic breach of contract dispute, if the contract says that a product is going to do X and it doesn't thats a contract breach. If you are a company selling a product you better make sure that your sales reps don't have the ability to setup a contract to deliver a product that you can't deliver.
  • in short, no.

    Malpractice relates to the doing of something that cannot be undone. Such as removing a leg and not being able to replace it with the exact same leg.
  • I don't think the SAP example is relevant

    I think the SAP example goes beyond simple failure to meet expectations; they may have conducted fraud:

    It appears as though SAP grossly misrepresented what they were selling to Waste Managament. They committed two sins: 1) The fraud part was in that they claimed that something existed that did not; they sold "vaporware" representing it as an already existing product. 2) They then couldn't produce what they had promised. If they had pulled of #2, WM would have forgiven #1. But clearly the sales team was more ambitious than the production team. (not unusual)
  • Agile to the rescue?

    I have been lucky enough to be able to participate in JAD sessions and I think that frequent (read: nearly daily) meetings between business analysts, users and software developers can keep expectations in line. Of course, this is for custom software development, not semi-packaged software like SAP.