Keep Lawyers in Loop

August 13, 2001 (Computerworld) A large majority of IT development projects end up as failures, in terms of missed deadlines, blown budgets and dissatisfied users. And while many of the IT projects carried out by external vendors do have the contractual equivalent of a prenuptial agreement that covers how the two sides would "divorce," neither party ever seems prepared for the messy legal aftermath of a failed project. When I tell project managers that litigation costs in large IT organizations will likely exceed the cost of coding, they're shocked. And well they should be, for while they have often devoted great care and attention to coding (along with all the other technical activities associated with systems development), they tend to ignore the legal issues until a lawsuit is staring them in the face. By that time, it's usually too late to prevent the
consequences of mistakes that occurred throughout the project.
Reasons for this include ignoring or excluding lawyers during the negotiating and contracting stages of an IT project; asking them to draft elaborate provisions for technical issues that they don't understand; or letting them create contracts whose terms and conditions turn out to be unworkable from the beginning and that both parties proceed to ignore without bothering to inform their legal advisers. While there are exceptions to this dismal assessment, the prevailing situation is that the conduct of the project takes place - often over a period of months or years - without any legal review, oversight or guidance. Then, when things blow up at the end, and the vendor and customer angrily blame each other for having caused the problem, it's often an entirely new set of attorneys who are brought in to serve as hired guns to help orchestrate a legal punishment on the other side.
Interestingly, the resulting lawsuits tend to focus on very esoteric, sophisticated technical issues, such as the question of whether the vendor succeeded in delivering a system whose "cyclomatic complexity" (the amount of decision logic in a single software module) exceeded industry norms, even though neither party had ever heard of this metric of software maintainability before the lawsuit was filed (see www.mccabe.com/products/qa_method. htm for more details, if you're curious). And while the lawyers, the jury and the judge are all grappling with the nuances of this technical buzzphrase, the real problem usually turns out to be far more basic: There was no contract at all; there were no tangible, objective acceptance criteria that described when the project could be considered finished; or the contract was emasculated and renegotiated during the course of the project, but without any written record of what was agreed to, and under what circumstances.
Ironically, the only time that most IT organizations decided to pay attention to their lawyers was during preparations for Y2k. As it turned out, there were very few Y2k problems that were serious enough to cause lawsuits. But I know from experience that many IT managers were pleasantly surprised by the pragmatic, common-sense advice they received from their lawyers: "Develop a process for doing your Y2k remediation work," the lawyers said. "Document the process, in case you need to explain it in a lawsuit. Make sure your project teams actually follow the process, and provide an audit trail to demonstrate that they did so."
Bottom line: If