PacifiCare lost time, and now Kass has to swallow the cost of doing the project in-house. He vows that next time he contracts with an outside company to develop custom software, he'll budget more for oversight, even if it means sending one of his own developers to work part time at the vendor's site. Future contracts also may include more specific language, such as requiring that contracted developers complete a checklist for test scripts and follow certain standards, such as the Capability Maturity Model, a stringent quality process for software development that Carnegie Mellon University created. "Going into a deal, you can't have too high a level of trust," he says. "Trust needs to be developed over time with a vendor."

Mercier at Integrated Health Services says he, too, will spend more time looking at the actual code from now on. He wants his database administrators, for example, to be able to review a database application's design to check for quality problems. He also wants to know a vendor's standards for tracking code versions. One of the biggest problems the health-care provider had with its ERP vendor was related to conversion programs, which convert data from the older version of its system to the new one. From March to December 2001, none of the conversion programs the vendor provided worked properly, says Lisa Liedtke, director of enterprise systems. Finally, Integrated Health staff wrote 35 conversion scripts to get the programs to work, with each script taking anywhere from a day to a few weeks to complete. Liedtke says what's particularly exasperating is that the vendor will support the current version for only two years from when it was released, yet so much of that time is spent working out problems on software that was too immature to ship in the first place. The upgrade is costing close to $2 million--twice what was budgeted.

Mercier and Liedtke finally bypassed the account team assigned to their project and got the attention of a lead product developer by sending him an E-mail directly. They've since talked to the vendor's heads of consulting and sales, asking them to listen to their suggestions for a better customer-feedback loop and to look at the fixes Integrated Health's programmers developed for software problems.

Will Integrated Health's ERP vendor play its part in a healthy, long-term relationship? Mercier and Liedtke still hope so, but they're not convinced. Nor are they sure how many vendors will readily provide code for review, demo their software in real test environments, or accept more risk in software contracts. It's prompting a reconsideration of IT strategy--with the application service provider model looking increasingly attractive. "Going forward, in a number of systems, we're going to avoid the infrastructure and technical side and go with performance objectives," Mercier says. "If we sign an ASP contract with a patient-billing vendor and say, 'You're going to provide this list of functionality and this level of uptime,' then we're buying a service that must perform at a certain level, rather than buying the technology."

Regardless of how they do it, buyers are sending a clear signal that they'll no longer bear all the quality risk in a major software project. In the short term, such demands may increase costs for an already-beleaguered software industry. Vendors that survive will be those that prove they can build in quality from the start.