Double Jeopardy

Spending a bundle on smart, hard-working consultants won't guarantee you'll get what you paid for. Just ask the Oklahoma City Water Utilities Trust.

Published: October 15, 1998

Ernie Aschermann is a good software salesman. He knows how to pitch and he knows how to write code—a rare combination of talents in the software industry. On Jan. 16, 1992, he had a rapt audience in the managers of the Oklahoma City Water Utilities Trust, the public corporation that sells water to the citizens and businesses of Oklahoma City.

Desperate to replace its antiquated customer-billing system, the Trust had invited Aschermann and his sales sidekick, Steven "Pax" Darlington, to give a demonstration of a utility-billing program developed by their company, Network Computing Corp. (NCC). In a small conference room at the Trust's headquarters, Aschermann delivered an impressive presentation. He practically finished the Trust people's sentences for them, showing off his knowledge of the water utility business and his software know-how.

After building up the Trust's expectations, Aschermann finally hit a button on his laptop and the screen filled with arcane references to utility-billing functions. "What I want to show you now is Affinity Revision One," he said. "I'm going to show you this because number one, I don't want you to go away with the impression that there's anything that doesn't exist—any smoke or mirrors." Then he drove the "trust me" point home with a bit of self-deprecating humor. "What's that joke about computer salesmen and car salesmen? At least the car salesmen know when they are lying?"

During the disastrous software project that followed, questions arose as to where Aschermann and Darlington fit in that sales spectrum. Allegations of misrepresentation and fraud would land NCC in court a few years later, where a jury decided that the two men might, in fact, have made great car salesmen. Even within the Charlotte, N.C.-based software company, Aschermann's colleagues had their doubts about his Affinity sales pitch, referring to it from the beginning as "smoke and mirrors." George Mackie, who was president and CEO of NCC at the time, charged that Aschermann "was stretching the truth to his favor."

Unstretched, the truth was that Affinity Revision Two (or Affinity 2.1), which the Trust would later buy from NCC for $1.3 million, was far from being fully developed, contrary to the impression left by Aschermann and Darlington that day. The Trust became an unwitting beta site for a desperate, financially troubled software company that needed a big sale to stay afloat.

Ironically, the ensuing catastrophe was not the first of its kind for the Trust. As the NCC salespeople spun their tale in the Trust's conference room, across town the Trust's hired-gun lawyers were busily preparing legal documents for the Trust's case against Peat Marwick Main & Co. (now known as KPMG Peat Marwick LLP), the accounting and consulting firm that had tried and failed to develop a custom-billing program just a few years prior. Like the NCC debacle, that case also involved an unproven software product encased in a sweet, candy-coated sales shell. The complex software overwhelmed Peat Marwick's well-meaning software developers and the Trust's expensive new computer system dissolved—like the project—leaving a bitter taste in everyone's mouth.

That's why Stacey Davis, utility customer services superintendent for the Trust and the lead business person on the utility-billing system project, decided to videotape (with the vendors' permission) the sales pitches from NCC and the three other vendors who came to the Trust in early 1992 offering to pick up where Peat Marwick had left off. Davis was prescient, it turned out. A five-minute "highlight tape" from NCC's presentation became one of the most powerful pieces of evidence during the Trust's second civil trial against the unfulfilled promises of software vendors and consultants.

The Trust's 10-year saga of failed software projects and legal wranglings is a cautionary tale for any company contemplating a large, complex software installation using consultants. The story of the Trust shows just how easy it can be for these projects to go horribly wrong and how bittersweet revenge can be when administered through the courts.

Even more disturbing is the fact that Davis and his colleagues at the Trust are not naive. Most had been through software implementations before the big troubles began. In both projects, the Trust took the standard precautions to avoid disaster: clear, detailed requests for proposals (RFPs); exacting contracts that outlined specific deliverables, milestones and dates; full-time project staffers from the business and technology sides of the Trust; and high-level project steering committees that met regularly with the consultants on both projects. Nor were the consultants evil charlatans. Most were dedicated, experienced, talented people. And still both projects ended with unworkable software and angry recriminations on both sides. The Trust's story is a shocking testament to the ravages of complexity and to the need for businesses to impose radical, almost irrational, levels of control over the management of these projects to avoid major delays, cost overruns and breakdowns.


The trust's painful saga began in 1987, when it resolved to find a replacement for its already obsolete '70s-era mainframe computer. The Honeywell-Bull system was an expensive technological antique that cost $30,000 or more per month to maintain, according to Davis, and cost Trust staffers precious hours of lost productivity. It was impossible to look up customers by name in the system, for example. Any problems not linked to an account number meant a walk to the research desk, where a massive printout of the Trust's 170,000 customers sat waiting to waste everyone's time.

That's why the Trust decided to bring in Peat Marwick to help figure out what to do with old Bessie. After scanning the software landscape for options, Peat came to the fascinating conclusion that the best software solution was its own. On the surface, Peat's proposal did indeed look good: a custom-developed software program that would have all the functionality the Trust needed and then some, as well as a fancy new Digital computer, all for $2.6 million. Even better, if Peat could sell the new software to other utilities around the country, the Trust would receive royalties to help defray project costs.

Yet behind the scenes, all was not well with the proposed project, says Ralph Shay, who would become Peat Marwick's first manager on the project. Shay had heard rumblings within Peat Marwick that the computer Digital had recommended for the project, the VAX 6220, would not be able to handle the large, complex application being proposed to the Trust. The computer choice was critical to the success of the project, because the software did not yet exist and therefore could not be tested to see how much processing power it would consume. But the Trust could not afford to wait before buying a new machine, says Davis, since it did not own a computer powerful enough to handle the software development project, let alone run the finished software. The computer and the software would need to run together seamlessly; the Trust was on a fixed budget and could not afford to swap out the computer for something more powerful (and expensive) once the project got going.

But the Trust had reason to believe that the 6220 was the right machine for the job. Before it became the project consultant, Peat had been hired to coordinate the Trust's formal search for new hardware and had recommended Digital, which proposed the 6220. Peat Marwick tried to distance itself from that recommendation during contract negotiations with the Trust, but things only got muddier when both sides' lawyers got involved and inserted a murky accountability clause in the heart of an otherwise clear contract. The Trust bought the 6220 at the same time it signed on with Peat in November 1988. Both parties forged ahead blindly, each assured that the other was legally responsible for any computer problems that arose.

But those who worked on the project for Peat Marwick say the company's project leadership was more aware of the potential for problems than it let on during contract negotiations. Shay says he made his concerns clear to Larry Lott and Thomas Gorley, his project superiors at Peat Marwick, in a series of meetings in Lott's Dallas office before the contract with the Trust was signed. "We discussed quite a bit the fact that only one of us on the project team had experience with the combination of hardware and software we were proposing," he says. "That combination represented an unknown and a risk."

The new technologies didn't bother him so much as the computer. "We could learn the new software, but there was a lot of risk in proposing a system that had already been locked into a processor," he explains. "We felt we could make it work, but there was still a lot of risk." In sworn depositions taken in 1993, both Lott and Gorley would deny that they had spoken with Shay about the ability—or lack thereof—of the 6220 to run the proposed software prior to signing the contract with the Trust.

Peat was also having problems with its new computer-aided software engineering (CASE) tool, Goldrun, that would generate the computer code for the Trust's software program. The lone Peat Marwick developer on the Trust project who had experience with Goldrun, Bill Blessing, claims that before the contract was signed, he warned Lott, Gorley and the Trust that Goldrun used bytes like a Sherman tank uses gasoline. During a prior project at an insurance company in Kansas City, Blessing says the application that he helped develop with Goldrun consumed so much processing power that the client had to trade in its Digital 6000 series computer for a 9000 series machine, which was roughly five times as powerful and almost three times as expensive as the 6220. "I knew [the application] would never run on the 6220, and I told many people on both the [Trust] and on the Peat Marwick side my concerns," says Blessing. Those concerns went unheeded.

To Davis, the hardware dance was irrelevant. He focused on the "acceptance testing" portion of the contract that bound Peat to explicit software The new software posted an absurdly long batch processing time of 91 hours. I told them batch processing would have to be done in Alaska because there they have nighttimes that last six months. -Stacey Davisperformance requirements. Peat was obligated to provide a software program capable of getting information from the 6220 to the terminals of his customer service representatives in two seconds or less, and the system needed to crunch through its load of daily transactions during nighttime batch processing in five hours or less. To Davis, it was Peat Marwick's responsibility to meet these promises, including buying the Trust a faster computer if that became necessary. Davis says that he confronted Lott and Gorley about Blessing's warnings but was told not to worry. "They would say the Kansas City system was that system and this is this system and they would reassure us that this was going to succeed," recalls Davis.

Those assurances became less frequent and less reassuring in April 1989, three months after work on the project began, when Larry Lott sent a letter to the Trust's MIS director, Jana Bagwell, expressing Peat's opinion that the 6220 was inadequate for the job. Davis went ballistic. "In steering committee meetings we'd have Gorley saying, 'That's a hardware problem, you need to talk to Digital.' We said, 'No, it's your problem. If you want to call Digital in you can, but you are the ringleader here so you are responsible.'"

While the computer issue became public knowledge fairly early in the project, Peat decided not to send a letter to the Trust about the problems with its Goldrun tool, problems highlighted in internal memos written by the project's technical lead Steward Nazzaro. "The Oklahoma City engagement has a number of requirements which we are finding impossible to meet with the features currently available in Goldrun," he wrote in February 1989. In December of that year he criticized the "inefficient code" being generated by Goldrun. Although he declined to be interviewed directly for this story, citing a confidentiality agreement signed by the Trust and Peat in their legal settlement, Lott stated in his court deposition that Gorley told him that Nazzaro was "overreacting."

Nazzaro may have been understating the problem as it turned out. During performance testing in December, the new software posted an absurdly long batch processing time of 91 hours with just one terminal attached to the system (the Trust would need 65 to 80 terminals) and typical information request response times of 11 to 17 seconds. "I told them batch processing would have to be done in Alaska because there they have nighttimes that last six months," deadpans Davis in his Oklahoma drawl.

1 2 Page 1
Page 1 of 2
Download CIO's Roadmap Report: Data and analytics at scale