InformationWeek

A year ago, Internet pricing service Priceline.com Inc., which lets customers bid their own prices for goods and services such as groceries, hotel stays, and airline tickets, initiated a development project to centralize its Oracle database and let the company focus more on customers than on products. The system lets Priceline.com's customers register personal information once, eliminating the need to re-enter it on every visit. The new system also allows Priceline.com, in Stamford, Conn., to gather information on customer purchases and share the data across product lines.

System designers rewrote the front-end screens, middleware, and back-end layer for each product line, one module at a time. Coding for each module was similar. Designers began with the modules that had the least impact on the business, saving those that are more intensively used until they had gained experience. "We started with the less-complex product modules and learned from them, then moved on," says project management director Farris Etterlee. "As we progressed, we got very good at what we were doing." Modules took seven weeks to three months to complete.

About 90 people were involved in 15 teams consisting of a project manager, a business analyst, a technical lead who organized the programmers, and programmers. In addition, support teams drawn from company engineers, quality analysts, and database administrators assisted the developers. To facilitate the management of all concurrent projects, Priceline.com used TeamPlay, a project-management tool from Primavera Systems Inc. running on a Sun Microsystems server with an Oracle database. About 200 people used the system: 30 project managers and 170 programmers. Project managers set up projects and created time sheets listing time spent on each activity. Company executives and Etterlee had access rights to the databases; project managers had access to their own projects.

Testing while developing an application is crucial. "The most expensive time to fix a problem is after everything is written," says Rational's Schurr. A best practice is to continuously verify quality at every incremental step. Team leaders should verify that one piece of code not only works as planned, but also works with code from the other developers.

To be sure that coding was consistent, Priceline.com's programmers attended training classes and coded according to a published coding standard. Weekly code reviews by a team of engineers checked the completed code to see if it met the standard. Each module went through unit testing that the developers performed, then three weeks of quality analysis, and another three weeks of stress and load testing.

At TIAA-CREF, testing was done at three levels: the programmer who coded the module, the designer who had a better idea of the users' needs, and users who tested the applications against extensive samples of specific business cases, or test beds, they had prepared. Completed modules were released to user-acceptance testing one after another. "It's a triple filter," Erlikh says. "We're able to weed out 90% to 95% of all substantial problems."

As important as consistency is in a development project, design and requirement changes and modifications are inevitable, and planning should include a means to control them. "You need a structured process so that the cost, schedule, and programmatic impact of changes can be quickly understood and evaluated," says Barry Calogero, executive VP for business development at Robbins-Gioia, a project-management consulting firm. "Key decision-makers can then decide whether or not to move forward with the change." Modification requests should be prioritized and assigned to team members, with a method for tracing changes, testing, and delivery in a uniform way.

Setbacks, even small ones, can have a big impact on a project with a relatively short development cycle. At TIAA-CREF, Erlikh discovered that a particular interface had been forgotten until the project had reached the coding phase. A delay was avoided because Erlikh included enough time in the schedule to cover it. "The only defense is to do your project analysis and design thoroughly so you can build in enough time to accommodate things that go wrong," she says.

Coordinating changes to systems that cross a number of departments is a challenge faced by Glaxo Wellcome Inc., a drugmaker with U.S. headquarters in Research Triangle Park, N.C. Glaxo Wellcome is developing an interactive voice-recognition component for its customer-relationship management system. The system serves the drugmaker's customer response center with the aim of improving customer relations by accurately directing incoming messages regardless of contact media. Glaxo Wellcome receives nearly 60,000 phone calls a month. In the past, callers would be transferred four or five times before reaching an employee who could help them. The company has developed applications that support inbound and outbound telephony, E-mail, fax, and video. Customer contact information from the response center is integrated with its sales, marketing, fulfillment, and distribution organizations, and with a companywide data warehouse.

In scope, the project encompasses the entire company. Building the different components of the system required crossing departmental boundaries and would frequently involve representatives from various business areas such as the marketing, human resources, legal, and distribution departments, as well as IT. One particularly complex component was fulfillment, which includes shipments from the distribution department following telephone requests.

The complexity lay in the integration of the distribution system with the customer response center. That was compounded by the departure of two key managers, who between them had most of the necessary knowledge and information to complete the integration. Their replacements brought different ideas about system requirements. "We ended up redesigning it completely," says Maurice Hagar, senior IS development manager.

Good requirements management and traceability of each requirement through system and integration testing is crucial. "A quick and early lesson for us was that developers had to be involved in the process from the start so that nothing was lost as requirements worked their way through the development life cycle," Hagar says.

continued...page 3
return to page 1