Project disasters come with the territory in IT. Some observers (including me) pessimistically believe that the majority of IT projects fail to meet their original goals. All too often, "descope and declare victory" is the only possible way to end a project. Part of the problem is that, regardless of how badly the project goes, the customer does not have much recourse.
All of this changed last week.
Waste Management's SAP lawsuit
Waste Management has initiated a $100 million lawsuit against SAP for a failed ERP implementation. While the size of the Waste Management SAP project is much larger than the typical programming project, the problems it faced were not unusual. From FBI computer upgrades to Windows Vista, "behind schedule and over budget" is par for the course. Programming projects are just as problematic as large integrations, and they are often a key component of those floundering integrations.
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.
Are "programming malpractice" cases around the corner?
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.
What's a programmer to do?
I'm not a lawyer, so I obviously cannot offer any legal advice -- I'll just share what I plan to do. I will continue to make sure that I put forth my best efforts; I'll also be diligent about showing the customer that I am working in good faith. This is part and parcel for any relationship, but it's especially important to me now.
If you are an independent contractor or consultant, run your own company, or could otherwise be held personally liable in the case of a lawsuit, you may want to consult a lawyer to find out what your options are. And, if at all possible, make sure that your salespeople don't make wild promises.
At the end of the day, there is no need to panic. But the age of legal consequences for project failure may be upon us. Given the failure rate of IT projects, I fear that far too many developers are wide open to legal troubles.
Additional project management resources fromTechRepublic
- Gain project approvals from the right stakeholders
- Poor scope-management practices could precipitate project failure
- Project management responsibility can be elusive
- Outsourcing a project does not relieve you of responsibility
- 10 signs that your project is about to be cut
Justin James is the Lead Architect for Conigent.