Defining Requirements

In effect, the days when a software development team at Kaiser could go off and do its own thing—assuming it knew what the business group wanted—are history. Instead, developers are now required to follow the new process to define project requirements, as well as use the new system to document and track the definition of requirements before a single line of code is put on the screen. "All new projects as of Jan. 1, 2006, are expected to adopt this process and this tool," Schleifer says.

Moreover, those software-building mavericks who would jump the gun and move right to the design phase will be corralled and broken of the habit, because as of the first of the year, all Kaiser development projects must toe the line by using this new process as their standard for development.

"We are making a clear distinction between requirements and design," Schleifer points out. "People tend to jump to the solution before they've defined the problem and the need. In the past, when we had a paper-based requirements process without much structure, there was a tendency to jump into the solution."

Whenever possible, Kaiser wants to reuse a set of requirements, rather start from scratch with each development project. The HMO redesigned the RDM process first, because all other activities depend on that effort for their success.

Most software development experts agree that "scope creep" is next to inevitable for large projects. "That's why we have a process for change control," Schleifer says. "This way, project managers can look at each change request and understand the impact it will have on cost and time line, as well as how far back in the process they need to go to implement the change."

Realistically, Schleifer accepts the fact that development projects will have late-in-the-game changes. "You will still have project managers pushing scope creep, but now we are able to show them why a project is two months late and half a million dollars over budget, and show who signed off on it," Schleifer says. "We can say, 'Midway through the development, you changed two-thirds of your requirements.'"

Consultant Wiegers concurs that scope creep—what he calls "the uncontrolled growth of requirements over time"—is a reality that must be part of an organization's plan. "The problem is that organizations often don't accept the reality of change, and that requirements will grow," he says. "They need to accommodate that change and have mechanisms to deal with it."

A project will occasionally suffer a last-minute hit below the water line when someone discovers that a key requirement has been omitted. "It's more than simply embarrassing if you find out the requirement that was left out was the one that, for instance, turned on a patient's respirator," Wiegers says.

At the heart of the Borland system is a requirements database. Because the system is event-driven, everyone involved in developing a requirement—coders, developers, testers and business representatives—is alerted via e-mail when there is a proposed change to that requirement. The system also indicates other requirements that would be affected by the change.

"People can post changes to the requirements, and everyone can see those changes," Schleifer says. "Members of the team can conduct their review directly in the tool, which saves time and reduces the chance of requirements getting lost." Adds Klassen, "This tool maps the process, enabling users to review different business scenarios, which helps in the validation process."

Developers Weigh In

Although it's too early for Kaiser to report any measurable results, the company received positive comments in an informal survey of business unit representatives who worked on requirements for one project that used the new process and technology. Kaiser shared those results with Baseline.

"Having predefined requirements helped reduce confusion during the specifications process," wrote a representative who helped define requirements for the company's new broker sales compensation application, which is used to compensate outside salespeople offering Kaiser health-care plans to new clients.

Added a developer, "It brought us a greater degree of confidence with our business customers." Wrote yet another, "Having a repository of business requirements that we all could access—both the I.T. team and the business people—was helpful." A core team ranging from six to 12 analysts and developers, working with business user representatives, created the requirements.

Unlike in the past, when Kaiser's software development projects would be held up at the eleventh hour because a business requirement had been omitted inadvertently, the new process ensures that all necessary business functions are included from the beginning. As Schleifer puts it: "We joke among ourselves about 'no requirement left behind' being our charge."

NEXT PAGE: Kaiser Permanente Base Case