InformationWeek

But as business shifts to Internet time, top executives are pressuring their application development teams to build big, top-notch systems faster. "They don't have that trade-off between time and quality anymore," Schurr says. "Today's paradox is: How do you build software faster and make it higher quality at the same time?"

The answer isn't simple. But companies trying to hasten the implementation of large, homegrown systems find that it helps to boil down complex tasks into smaller components. Carefully planned projects should proceed step-by-step, building demonstrable versions of software that can be reviewed and tested frequently. Constant testing confirms that developers are on the right track. Waiting too long to test components could cause long delays as developers need to backtrack to identify and fix problems found later in the process. In addition, project planners should learn from earlier successes and failures, incorporating best practices into the process.

From the outset, goals and requirements need to be defined as thoroughly as possible, and project leaders should actively involve users who have vested interests in the systems during the development and testing phases.

Last February, TIAA-CREF, a New York insurance and financial services company, completed a system to support a new short-term disability coverage policy. Since TIAA-CREF didn't have a similar product, development was done from scratch. The project took 19 months, which was considered rapid by Susanna Erlikh, a systems-development project manager. In the past, such a project could have taken years to complete. The project team included technical specialists as well as the manager of the claims department, claims analysts, an accounting manager, and medical advisers.

The initial planning sessions were broad discussions among technologists and users to estimate schedules and allocate personnel. In these sessions, users learned the complexity and limits of developing large systems. "It's give and take," says Erlikh. "Everybody understands budgeting. They will be willing to give up functionality in exchange for a reduced budget or speedier delivery. They have a feel for what they have to sacrifice to get something else. Wishful thinking should be suppressed."

Once the team defines the system's requirements, development efforts are broken into smaller, manageable tasks. "It's intuitive to understand that the larger the project gets, the more complex the interactivity gets," says Matt Hotle, a senior analyst at Gartner Group. "The job of a good project manager is to keep the actual work being done on a granular enough level to reduce the complexity as much as possible."

For the short-term disability coverage system, Erlikh identified the various components, or modules, of the project, such as customer eligibility, medical procedures history, claims adjudication, benefits calculation, and accounting, and assigned each module to experienced systems developers.

Developers reduced each module into its smallest tasks, estimating the time it would take to complete them. They also completed a design proposal and prototype, wrote program specifications, and supervised the coders.

A typical module, on average, took three months to complete. One of the more complex ones--claims adjudication--took six months. That module is used to determine if specific claims should be approved or denied, or remain pending awaiting more information. The designer met with a claims analyst, claims manager, accountant, and nurse 10 times during this phase of the project in sessions lasting two to three hours. The nurse, for instance, offered advice on establishing criteria for claims that require the approval of a medical professional.

During joint application design sessions, designers and users negotiated which requirements were worth supporting. Users without IT experience often came to these sessions armed with a long list of requirements; they quickly discovered the time and financial limitations of application development. The more automated a process becomes, they learned, the more costly the development process. "They go from a demanding mode to a thinking mode," Erlikh says. "They'll offer to give up one thing if we can give them something else. They will tell me, 'Don't concentrate on this; it's not as important to me as this other piece.'"

During a session for the benefits calculation module, users withdrew the request for a complex calculation used to compute weekly benefits, because the time and resources it required were prohibitive. Besides, the automated calculations would not be needed until a year after the initial rollout.

As programmers coded the applications, an integration team comprised of designers met several times a week to review the code to ensure that each module was properly integrated with the others.

continued...page 2, 3