For example, most standard contracts indicate that a vendor will fix problems if they crop up within a limited time period. But purchasers should estimate a worse-case implementation time frame, then ask for a warranty that covers it. It might even be worth offering to pay a little more to be protected for a longer period of time, essentially buying insurance against any problems. Companies can also try to negotiate a deal in which a greater portion of the payment goes to services for implementing the software, rather than the software license itself. That helps protect the customer against quality problems because more payment is tied to an ongoing business relationship, but it also lets the vendor recognize some revenue from the noncontingent sales part of the agreement. It's also important to negotiate the dollar amount of vendor liability. Often, the vendor's suggested amount is paltry compared with what the customer will spend on a failed implementation, including time and labor.

One of the best forms of leverage is patience, Klein says. A company should take the time to really investigate a product's capabilities and get to know the vendor. "When you see these deals go bad, it's because not enough time is spent up front," Klein says. "It depends on what time lines you have to meet, of course, but if the implementation doesn't work, then haste gets you nothing." Although it takes time and effort for a company to investigate and work with an alternative vendor as thoroughly as its first-choice supplier, it pays to have a backup. "Someone on the purchasing side gets it in their head that this is the way to go and then telegraphs that to the chosen vendor, at which point all that beautiful leverage disappears," says Paul Anawalt, an associate at Latham & Watkins.

Phased implementations play a much larger role in even short-term contracts lately, in part to guard against poor quality or performance and in part because it stretches the IT budget in tight times. Edward Hansen, a contract law attorney with Shaw Pittman in New York, suggests that companies try to get the vendor to split even a one-year deal into four phases, including software and implementation. That way, the vendor can record at least a portion of the revenue from the sale on a quarterly basis. But buyers have to plan carefully to ensure that a phased implementation helps quality and isn't just an installment payment plan. The contract needs to state that payment for each phase is tied to the customer's acceptance.

Dwyer, the acting CIO at Glatfelter Paper, wants a contract to spell out specific scenarios of how software should perform. If the software is supposed to help set prices, the purchase contract should include examples of how it handles complex models that factor in rebates and volume pricing. The process can be time-consuming, but Dwyer says it's sometimes worth the effort to commit to buying only one module at a time, giving the vendor incentive to quickly resolve any quality issues that arise.

QUICK TIPS: Quash Quality Problems
How to avoid losing time and money on poor-quality software Be patient: Don't rush anything, including vendor selection, review, and contract negotiations. Demand a realistic demonstration: You want to see the software handling the loads you'll have, and in a similarly networked environment. Ask for several customer references, both current ones and those the vendor lost. Negotiate, negotiate, negotiate: Ask for what you want in a contract to reduce your risk, and the vendor might just comply--or meet you halfway. Get to know the right people: Develop relationships with managers at the vendor company who will respond to software-quality issues. Collaborate on solving quality problems: Push long-term vendors to accept your feedback and involvement. If you've hired an outside company to develop your custom software, have an oversight plan in place. Use your company's influence and power: If you face a software-quality problem and are getting stonewalled by midlevel managers, have your CEO call the vendor's CEO. --Mary Hayes

As CIO at Great Lakes Chemical Corp. from 1995 until 2000, Dwyer employed some of these tactics during an implementation of SAP R/3 at more than 30 locations worldwide. She's particularly proud of a contract she negotiated that required senior managers from both SAP and its implementation partner to sit on Great Lakes' IT steering committee and attend meetings at the specialty chemical company's West Lafayette, Ind., headquarters every few months. "Make sure you have someone from the software company who is going to feel your pain," she says. "And make sure that person has a meaningful role. Your relationships with vendors are really important. It's knowing the right people and getting assistance out of them when you need it."

Still, many technology buyers say it's best to not put too much trust in a vendor. That's a lesson Jonathan Kass learned the hard way. Kass, director of application development and E-business at PacifiCare Behavioral Health Inc., a specialty health division of PacifiCare Health Systems Inc. in Laguna Hills, Calif., tapped an IT services firm 18 months ago to develop custom software to run the division's call centers and manage patient caseload. Kass talked to the vendor's references, who seemed happy with its work. Kass, whose background is in the quality-obsessed aerospace industry, even made sure that the deal included a quality-assurance plan. Problem is, Kass says, the vendor apparently had no intention of following it.

Kass says he kept asking to see the test scripts--which test the functionality of applications being developed--but the vendor wouldn't come through. "Finally--and this is as bad as it can get--one developer said, 'Don't worry about what we promised in the QA plan. I know what I'm doing.' The red flags don't get much redder than that," Kass says. After an unsatisfactory discussion with the vendor's VP of quality, Kass took the project in-house. Kass says he thought he was "being forward-thinking by putting QA language into the agreement."