Both Sides Always Lose: Litigation of Software-Intensive Contracts

     — Tom DeMarco and Tim Lister

A contract is a kind of specification. Instead of describing a new system, it describes a business agreement. A contract suffers from some of the same difficulties that plague a specification: neither is ever entirely clear, entirely "right," or entirely free from interpretation. None of these problems is fatal when there is good will and a commonality of interests between the parties. With these two essential ingredients, people work out their differences and come to a successful conclusion. But when the two essential ingredients are missing, that's when matters begin to go south....

GOING SOUTH TO THE TUNE OF MORE THAN $100 MILLION

     Take, for example, the case of a contract to build an ambitious reservation system a few years back. The disputants were the Fly-By Information Services Company and the Magnificent Hotel Corporation (fictitious names used here to protect the guilty parties as well as the authors). Fly-By was to build the system and Magnificent to specify the requirements and pay for the result.

     The first sign that all was not right was the extraordinary difficulty of coming up with a contract. As with a specification effort, when contract negotiations are particularly rough, that is a sign that there is conflict brewing beneath the surface. This negotiation was fierce. Everybody hated everybody. It was like one of those marriages you see every now and then that quickly dissolve in bitter acrimony -- you have to wonder, when the principals are so wrong for each other, why did they bother? So, too, the contract between Fly-By and Magnificent.

     One way to deal with conflict is to paper it over in ambiguity. You do that when you write a spec that conceals disagreement rather than pleasing one of the disagreeing parties at the expense of another. In an aggressively negotiated contract, the result is therefore not what you would at first expect, a contract with every i dotted and t crossed. Instead you tend to end up with ambiguities wherever there were truly unresolvable conflicts. That's just what happened in the Fly-By case.

     The rest of the story is especially grim. The case was litigated for years and finally settled, with nobody really winning. The settlement was $100 million plus, but not enough to make anyone whole. No system was built or delivered. Everybody wasted years of their lives. The legal fees were staggering. The opportunity costs (the useful things they could have been doing instead of litigation) were even worse. Both sides showed huge losses on the endeavor.

     Since the contract was weak, the case finally turned on a single incident: Fly-By had fired a succession of managers who tried to tell the big boss that the date was unworkable. Magnificent found out, brought in the fired managers as witnesses, and then pointed triumphantly to one clearly written contract provision that said Fly-By was obliged to inform its partner if it had credible reason to believe the delivery would be late. That cost Fly-By more than $100 million. Everybody ended up with enormous losses, but Fly-By's were enormouser than Magnificent's.

     Even told in such sketchy terms, the case of Magnificent v. Fly-By contained many of the patterns of a typical litigation where software is at the heart. The first of these is obvious to anyone who has ever been involved in software litigation:

  • Pattern One: Both sides always lose.

 

STEPPING BACK FOR A LOOK AT THE CONTEXT

     As impressive as growth of the software industry has been, it is outpaced by growth of software-related litigation. It is not unusual for a large software development organization today to have upwards of 50 active cases on its hands. Litigation costs are not usually charged against an IT budget, but if they were, they would be (when spread across unlitigated as well as litigated projects) a larger component than coding. We are experiencing an epidemic of litigation on software projects.

     This is different from the general litigiousness that has often been noted about our society. Yes, we Americans are all too prone to ask the courts to resolve our disagreements, but this has not in the past been particularly true of American corporations. Corporations understood that everybody loses in litigation and that the costs can be ruinous.

     The growth of software-related litigation has, we believe, been due to some factors that affect all corporations today, but that have been particularly strongly felt in the software sector. Briefly stated, the extensive layoffs in the early 1990s, together with the "lean and mean" attitude that they engendered, have led to the glut of litigation in the later nineties.

THE HEART OF THE MATTER

     There have been downsizings in our economy before, but the ones that struck us so hard in 1990-1995 were curiously vindictive. The people who were booted out were made to feel that they weren't just unlucky; they were somehow at fault. They were "fat" that needed to be trimmed. The people who were left were also made to feel bad and told in no uncertain terms that they would have to pick up all the work of their dismissed colleagues and then some or risk being booted out themselves.

     It often fell to IT management to carry out the downsizings and to convey upper management's attitude of righteous indignation about Fat on the payroll. The effect on the workers was either catastrophic (for those who were laid off) or merely depressing (for those who weren't). That much was obvious at the time. What wasn't so obvious was the effect on IT management itself. Our speculation is that the downsizing exercise made many IT managers more fearful and more insecure than ever and caused them to retreat into an attitude of embattled authoritarianism. This attitude has been bad for everyone (except Scott Adams, who has turned it into millions).

     What does this have to do with litigation? It is -- or at least we believe it is -- at the very heart of the flurry of litigation that we began to observe by 1995. Embattled IT managers, fearful and under the gun to show improved performance, fell back on lines like: "Don't tell me it can't be done in two years. I am the boss, for God's sake! It will be done in two years."

    Engineers, who knew that deadlines were unworkable or that quality would suffer, just shrugged in the face of such insistence. What the hell, they reasoned, management will learn in the long run that impossible is impossible. And so the impossible targets were accepted. They made their way into contracts. The contracts were signed. The projects tried their best and failed (impossible, after all, really is impossible). And then the parties went to court.

    This is almost exactly the story of the project that Fly-By conducted for Magnificent. Fly-By wanted the work and bid to win. It obligated itself to perform at a level that time would prove was unattainable. The voice of reason was drowned out by authoritative management, intent on using its force to impose its wishes. It succeeded ... briefly.

  • Pattern Two: When authority trumps reality, reality always wins in the end.

 

"GOLLY, HOW THE TRUTH WILL OUT"

     An invariant feature of such litigation is that all project records are subpoenaed. That means that each and every manager and worker has to provide the entire contents of his or her files to be copied and provided to the other side. No exceptions. You may be reluctant to provide a copy of that bothersome little memo where the true defect rates were discussed, for example, but as the court papers make very clear, if you don't provide it and you are found out, you go directly to jail. Not the company, and not just officers of the company, but you. For most employees, this is a fairly persuasive argument. And so, even the most incriminating evidence generally gets delivered.

    As litigation consultants and expert witnesses, we spend an inordinate amount of time poring over these project records. The surprising thing is that, in most of these cases, there is a great deal of what we might call, well, Lying. It's not at all unusual to find yourself with a memo from X to his boss stating that delivery will be delayed by at least six months and a memo from X to the client, dated the very same day, providing comforting assurances that the project is right on schedule.

     Outright lying is a direct sin of commission. Equally common in the litigations we have worked on are sins of omission -- situations where X knows something bad and simply neglects to tell it to the client. Omission is just a different flavor of lie. Both kinds are subject to the following invariant of legal cases:

  • Pattern Three: Lying to your contract partner is morally indefensible, generally illegal, and always gets found out in litigation.
  •  

         The old rule of honorable behavior (don't lie to the other guy) seems to have been replaced with a new rule: don't tell the other guy anything that isn't true unless he really has no possible way of knowing that it isn't true. Same with sins of omission (what the lawyers call "unfair surprise"): it's OK to neglect to mention an inconvenient fact that the other guy really has no way of hearing about on his own. All this subterfuge comes back to eat you alive during litigation (witness those fired Fly-By managers gleefully coming forth to testify against their ex-employer).

     

    THE OTHER SIDE OF THE COIN

         So far we've spoken mostly of cases where the software builder overcommits. But it's also possible for the other party to be at fault: a software buyer imposes "wishful thinking" deadlines on a builder, conceals real requirements to keep the price down and hopes to impose them on the builder as freebie changes, tries to get ambiguity into a contract to be exploited later, and so on. In general, buyers are every bit as likely as builders to try to trump reality with authority and to tell little white (and gray and black) lies. And they are just as subject to the three patterns presented above.

         Buyers are also prone to one of the worst fallacies of contracting: the idea that risk always moves with responsibility. It doesn't. When you are the buyer and another organization agrees to build a system for you, the signing of the contract moves primary responsibility for successful implementation from you to the builder, but the risks involved in attempting the project do not all move with that responsibility. No organization can completely buy its way out of risk. If the contractor fails to deliver, both parties will lose. Since this is a real risk from the buyer's point of view, it is incumbent on that buyer to manage that risk. Software is a risky business, and both sides of any software project need to do serious risk management. We believe that most organizations understand this, but our data indicates that those who get into litigation are disproportionately likely not to.

    • Pattern Four: Litigation is almost always a result of imperfect risk management by one or both parties.

     

    "Imperfect" here is perhaps overly kind; most of the litigations we've seen have involved organizations that failed to do any risk management at all.

         So far, everything we've discussed has to do with events that precede the actual court case, the causative factors. That's all very interesting in the abstract, but if you are now about to go to court, your mind is understandably occupied with other stuff: namely, what do you do to avoid losing your shirt?

     

    OK, SO YOU'RE IN A LITIGATION -- WHAT DO YOU DO NOW?

         Litigation may be a lose-lose business, but there are certain defensive strategies that may help to limit your losses. The most important one we know is to investigate and calibrate your project with respect to industry norms. For example, if the other side alleges that you have been fickle about the requirements and heaped an unreasonable number of change requests on the builder, then your best defense is to show that your performance in this respect is better than the industry norm. It helps to know that the industry norm for changeability of a specification is someplace between 1% and 2% per month of the original specified size (measured in function points). It helps to have a good source for such evidence, in this case The Condensed Guide to Software Acquisition Best Practices (Software Program Managers Network, 1997).

         As you may surmise from this example, a successful use of the norms implies a certain fluency with metrics. Organizations that can't or don't measure themselves in a fairly systematic way are always at a huge disadvantage in litigation. If you are deficient at measurement and other side is on top of it, the jig is up for you. Metrics is one of the three major subjects on which virtually all software litigations turn:

    • Pattern Five: Most litigations end up focused on measurement, management, or requirements practice, or some combination thereof.

     

    ("Combination thereof," by the way, illustrates an often overlooked hazard of litigation: hanging around lawyers can cause you to talk funny.)

         The things you do to win a litigation -- that is, to be the less damaged loser -- are: do careful measurements work, focus on good management practice, and conduct exhaustive and thoughtful analysis of requirements. These are also, coincidentally, three of the principal things you should do to avoid litigation.

    A FINAL WORD

         The more you think about litigation, the more you must think about the underlying contract. It's tempting to conclude that the lesson here is to get your lawyers involved early and often in order to come up with ironclad contracts that simply can't go wrong for you. While early legal work may be a good investment, it is not entirely realistic to think it can prevent all problems. If the basis of the understanding is flawed, no contract will make it much better.

         Therefore, rather than focusing on the contract as legal instrument, we choose instead to turn your attention to the understanding at the heart of it. When parties develop a real commonality of interest, all is possible. Litigation becomes less likely and success more likely. The project may not go smoothly from beginning to end, but it will tend to respond constructively to the problems it encounters and have the best chance of delivering a useful and effective system.

         How can you know whether you are forging a partnership as opposed to signing a deal that will come back to haunt you? The best rule we can think of is this: consider a contract bad if one party can win while the other loses. Win-lose situations are a precursor to litigation, since only the most saintly organization could accept lose-lose when it could, under the guarantees of the contract, slip itself instead into a win-lose situation. This is the kind of contract you must avoid, even if your organization is the putative winner.

         But this sounds crazy. Isn't the heart of successful contracting an attempt to place yourself in a position where you can win at the expense of the other party? Too often it is, but such contracts usually turn out badly. The only contract that is really healthy is one where you would feel good signing either side.

         So there it is: make contracts that you would be willing to sign as either party. That will start you out with the best chance of success. Then measure carefully, manage well, and pay attention to requirements.

         Oh yes, one more thing: do a little risk management, just in case.

     

    This article is copyright by Cutter Information Corp. and reproduced by permission. All rights reserved. No part of this document may be reproduced in any manner without express written permission from Cutter Information Corp.