Vendor Management: Why Litigation Costs You

The Moral of This Story: Stay Out of Court

In March 2000, a $10 million software company called Triple Point Technology signed three contracts with Transammonia, then a $1.5 billion petrochemical company, promising to link all 27 Transammonia offices with a state-of-the-art commodities trading platform called Tempest 2000. Triple Point also agreed to design and develop six interfaces between Tempest and Transammonia’s existing PeopleSoft accounting system.

For Transammonia, it was the quintessential Internet-era "business transformation project" that would launch the old economy company into the 21st century of Internet-based, real-time, 24/7, free-flowing information. And the six interfaces between Tempest and Transammonia’s existing accounting software were the crux of the deal. No point in having a free flow of information if it didn’t freely flow into the general ledger.

Triple Point assured Transammonia the interfaces wouldn’t be a problem. In its business proposal to Transammonia from September 1999,

Triple Point said no fewer than three times that it had "experience" building "fully integrated solutions." Triple Point could "custom-build any interfaces required," the proposal also said. The sides talked about the interfaces shortly after the proposal, and a month later, too, when Triple Point again assured Transammonia that it was "very familiar with the nature of these interfaces, having built them for some of our existing clients." Triple Point said it had built a similar Tempest-to-PeopleSoft bridge for Mieco, another chemical company.

Transammonia was convinced. The company supplied a quote for Triple Point’s press release?something about working efficiently in fast-changing markets. It was a happy nuptial, but then, nuptials are never unhappy. Marriages sometimes are.

Failure Hits. Send in the Lawyers.

But Triple Point, it turned out, was rather liberal in representing its experience. In fact, it had never developed the interfaces. The company had only managed subcontractors that developed the interfaces, and it had done that just twice.

No one at Triple Point had mentioned subcontractors to anyone at Transammonia prior to the contract signing in March, but that was the plan. Triple Point hired PeopleSoft to develop the interfaces.

But by August, Triple Point still hadn’t provided PeopleSoft with a project plan and failed to monitor progress on the interfaces, other than through informal conversations. By the Dec. 31, 2000, deadline, zero of six interfaces was completed. In February 2001, Triple Point stopped paying PeopleSoft. A few days after that, Transammonia stopped paying Triple Point. Finally, Triple Point turned the screws on its subcontractor, setting a firm March 9, 2001, deadline for the interfaces to be completed.

That deadline wasn’t met. Nor were March 29th, April 24th or April 30th deadlines. Transammonia officially suspended the project on May 2, 2001. Within days, Triple Point executives were pleading with Transammonia to hang in there. Triple Point wrote letters to Transammonia claiming it was the subcontractor’s fault for not devoting the talent or resources necessary to the project?despite the fact that Triple Point was so tardy providing a development plan and wasn’t checking up on its subcontractor.

The contract stated that Transammonia would get the six interfaces in 230 days at a cost of $375,000. But after 400 days, having been billed $635,000, Transammonia had one interface.

So on July 11, 2001, Transammonia set a 30-day ultimatum: Make everything work or else. Triple Point could not do that. Transammonia refused to pay Triple Point any money it owed, so Triple Point sued its client for breach of contract, demanding $795,000 for services rendered. Transammonia then countersued for breach of the agreements and demanded its money back and then some.

Thus divorce proceedings began.

They didn’t end until Sept. 25, 2003, more than two years after lawyers commenced billable hours and a full four years after Triple Point submitted its sunny business proposal.

The New York Supreme Court’s Judge Herman Cahn, in a 4,408-word decision from which the above narrative was taken, recounted the significant?that is, the ugliest?details of the affair. He ruled in favor of Transammonia. (Both companies declined to comment for this story, including Transammonia’s CIO, Benjamin Tan. PeopleSoft also declined to comment.)

But as victories go, this one lacked marrow. Transammonia will get a refund (a court-appointed special referee is still deciding the amount), but four of Transammonia’s five counterclaims were thrown out. The one claim granted called for rescission?legalese for putting things back the way they were before the parties knew each other.

Or, as the final footnote in Cahn’s decision noted, "Transammonia asserts that it has paid over $1.5 million to Triple Point under the Agreements, ’and has nothing of value to show for it.’"

Save Millions with a Paragraph

Technology litigation?broadly defined as suing or threatening to sue over software project failures?is not new. The legal books are full of it. In one notable 1979 case, National Cash Register (NCR) was successfully sued by an electronics company called Chatlos Systems for breach of contract. Like Triple Point, NCR promised systems it didn’t deliver. In 1991, service staffers for Wang Laboratories (now Getronics Wang, a branch of Dutch company Getronics), attempted to fix a deployment of computers they had just sold to a sports injury clinic, but they accidentally destroyed five years of clinical and accounting data. Wang was found grossly negligent.

Like the Transammonia and Triple Point case, those cases occurred in down economies. Lawyers say litigiousness in the software project world (as in the world at large) is generally inversely proportional to the economy. And so, according to the experience of seven legal specialists interviewed for this article, the number of software disputes coinciding with the recent recession point to more IT project court battles:

"[Disputes] sprung back up aggressively in 2002, 2003."

"Our firm has seen about a 300 percent increase in cases in the last five years."

"The economy went down.... People started suing each other."

"As an arbitrator in these cases, I’ve seen a significant rise in disputes in the last three to four years."

"We’re getting more and more work as honest brokers [or mediators] in cases just like this."

"There’s no doubt there’s a rising tide of cases."

What’s different about software project disputes than other corporate lawsuits and what most shocks lawyers about this particular cottage industry is the utter avoidability of many, if not most, of the complaints. These suits are not about failure of projects so much as they are about the failure of CIOs and their executive brethren to legally prepare for failed projects.

When they fail to prepare, CIOs can expect to end up in one of three types of dramas:

Mediation is the least nasty and most likely to save the project, which it did for Sheleen Quish, vice president for marketing and global CIO of U.S. Can. "It’s like a marriage," she says. "You go to a counselor first, not divorce court."

Arbitration is a nastier genre where witnesses and evidence are used and in which there are losers and ostensible winners.

Litigation is the very center of software project dispute hell. Phrases you can expect to hear attached to this kind of action are "years of depositions and discovery" and "millions of dollars." (See "Dispute Resolution Pain Index," opposite page.)

In any of the three cases, these are mainly contract disputes. And while anticipating disagreements is one of the primary functions of a contract, the written agreements for software projects don’t seem to do that at all, says Hillard Sterling, a litigator and partner at Much, Shelist, Freed, Denenberg, Ament & Rubenstein in Chicago. In any other industry, many of these cases would never become cases because both sides would have signed a contract that accounted for what lawyers would consider easily foreseeable problems.

But contracts executed on software projects are often woefully inadequate, according to lawyers like Lee Gesmer. "I’m astounded by some of the [contracts]," says Gesmer, who is a partner at Lucash, Gesmer & Updegrove in Boston. He has also served as mediator and arbitrator in software disputes. He says he’s seen contracts signed by multibillion-dollar companies that are so one-sided in the vendor’s favor that "it appears the customer had no legal involvement in the contract. I walk around the office showing it to other lawyers saying, Look at this," says Gesmer.

In many cases, adding just a few words to a contract to specify who’s responsible for what and when would prevent multimillion-dollar disputes (see "A Crash Course on Avoiding Software Project Disputes," Page 45). True story: "Acme," a Fortune 500, deployed a system in which response time to database queries was a joke?a minute or more with several concurrent users. Simply unusable, according to a lawyer involved in the case. Acme told the vendor to fix it; the vendor told Acme to upgrade its hardware, which would cost Acme $1 million. Acme felt the vendor misrepresented its systems capabilities and that the vendor should pay for the upgrade. Acme sued.

The case is pending, but who wins is beside the point. Acme could have avoided all of this if its original contract had contained a simple performance clause: one paragraph that specified acceptable query response times and what hardware the vendor would be required to supply to make them possible.

Get Comfortable With Lawyers In The Room

Lawyers lay much of the blame for all of this at the feet of the CIO, whom they call an "underachieving, underinvolved" participant in software project contracts. "From what I’ve seen, it’s uncommon for an executive team, including the CIO, to have a solid game plan going into these projects," says Sterling, who started a full-time technology litigation practice a year ago after handling such cases for five years.

The lawyers attribute this lack of planning to three factors.

One, CIOs are inexperienced with contract law and either fear demonstrating that inexperience to other executives (each project is, in large part, the CIO’s baby). Or as Gesmer says, "They’d rather delegate that to someone else." Sterling says the IT executive’s ethic, born out of years of hustling his way into the executive circle by proving his worth, is to demonstrate accomplishment?not to avoid dispute. Being the one to prove you mitigated a potential lawsuit, he says, is difficult and often disregarded anyway.

The second factor that keeps CIOs from playing the key role in brokering good contracts is the emotional optimism that always accompanies the so-called BTP, business transformation project. Love and romance, says Bill Bierce of Bierce & Kenerson in New York City, probably explains why a billion-dollar company such as Transammonia, which had the resources to blanket the project with due diligence, didn’t do more of it. When you’re about to get married, no one wants to be the one to bring up prenups. "The human problem is, you want to trust each other, you really do," says Bierce.

The third factor, and the most self-serving for the lawyers, is that CIOs don’t cultivate legal experts outside of their own corporate lawyers, who themselves lack experience with software contracts. Take Charlie Talmadge’s experience as a lesson. Talmadge, the former CEO of Merchants & Businessmen’s Mutual Insurance, experienced a software dispute that eventually went through arbitration.

"I always say this now," says Talmadge, now retired. "If we would have hired expert lawyers up front and spent $20,000 having them argue with the software vendor as we were putting together the deal?instead of relying on our own lawyer, from Harvard, who also didn’t know anything about software?we would have never signed that contract. We would have been better off."

Winners In Court, Losers At The Bank

Abraham Lincoln once said that in court, "the nominal winner is often a real loser?in fees, expenses and waste of time." Talmadge knows this firsthand.

"I took over Merchants & Businessmen’s, and we were trying to install this new commercial policy software system that was supposed to be The Answer. It wasn’t. It wasn’t anything we thought it would be. It was beyond the pale. So the vendor [now out of business] says, ’Look we know we screwed the pooch on this, we’ll fix it. Just give us a quarter-million dollars.’ I said, ’That’s easy: No. Make it work.’ The president of the software company is in my office and asks me to think it over. I say, ’Do it or we’ll sue you.’ He said, ’The only people who will win then are the lawyers.’ That was the only thing he ever said that was right." He laughs.

"We went to arbitration. We had switched CIOs in the meantime [for unrelated reasons]. The old one came back as a witness, and he had documented the nonsense very well. We figured we’d kick the crap out of them. After three or four weeks, I’m paying lawyers and expert witnesses about 400 bucks an hour. It turns out we didn’t have strong enough language in our contract?and we totally missed the [terms contained in the] delivery and acceptance clause?it was that simple."

Related:
1 2 Page 1
Page 1 of 2
7 secrets of successful remote IT teams