Requirements Management: Kaiser Permanente's Rx for Better Projects

 
 
By Doug Bartholomew  |  Posted 2006-08-10
 
 
 

For most organizations, software development is seldom easy. Projects are often fraught with miscommunication between the information-technology department and the business units. Key requirements may get short shrift or be omitted altogether until the last minute, when both costs and tempers are likely to soar.

Now, one of the nation's largest health maintenance organizations is revamping the front end of its development process to ensure a tighter alignment with its business goals. As part of a sweeping overhaul of its software development setup, Kaiser Permanente, the $31.1 billion HMO, has installed new software and processes for defining the business requirements of new systems.

About 700 of the Oakland, Calif., company's 2,000 software developers will be using the development system, which is based on a requirements definition and management package from Borland Software.

Ultimately, Kaiser's initiative will tackle not only software design, testing and change management, but also how costs and project length are estimated and the process is measured.

"If there is a change in a project's scope, we want to know the impact down to the dollar," says Aaron Schleifer, project manager for requirements development management at the HMO.

The company's goal is to reduce errors and speed project development by standardizing the way the organization's developers outline corporate needs for new systems.

At Kaiser, which serves 8.4 million members through 30 medical centers staffed by 12,000 physicians, there are a few hundred development projects underway at any given time. It's no surprise, then, that the payoff of a streamlined process with fewer errors and reduced rework can be huge.

Kaiser won't say exactly how much it expects to save, but Schleifer points to an estimated reduction of 40% in project time lines, according to studies from Borland and the Software Engineering Institute. "It is obvious that the business case for a managed software life cycle will yield significant financial gain," he says.

How much is "significant"? Try eight figures. For a large organization with an information-technology budget of more than $1 billion, such as Kaiser, the savings could reach $60 million in reduced rework alone, estimates Matt Klassen, worldwide product marketing manager at Cupertino,Calif.-based Borland.

"By validating requirements early, companies like Kaiser can eliminate rework," Klassen explains. "The average development project has anywhere from 30% to 50% rework, and more than half of all rework is directly due to requirements errors."

"We like to say that $1 spent on getting the requirements right the first time can save $10 later when you're testing code," Schleifer says. Adds Kelly Cannon, vice president of applications delivery at the HMO, to whom Schleifer's business process management group reports, "How well we collect the requirements from the user is directly related to the quality of the software we develop."

But, he points out, "The real benefit will be a consistent requirements process with a repeatable result." In other words, when Kaiser developers attempt to put together a new system using the same process followed for a similar earlier system, they can be assured that by using the same process and tools, the project will conclude with an equally successful outcome.

NEXT PAGE: Defining App Requirements

Defining Requirements

In general, a software "requirement" is a capability needed by a user to accomplish something with a product. The requirements definition process encompasses all the activities that analysts and business representatives go through to identify the necessary requirements for a software application.

Historically, a business analyst performed the "requirements definition" step in the software building process by talking to users and finding out what they needed. Not surprisingly, the ad hoc nature of this procedure tended to yield mixed results. Some projects failed because of a lack of business knowledge and an inability or unawareness on the part of business users to adequately communicate their needs to analysts.

In many instances, large companies hired consultants who brought in their own analysts, who often knew a lot about software but not much about the specific business or its industry. "I'm not a fan of bringing in analysts for hire," cautions Karl Wiegers, principal consultant at Process Impact, a software process consulting and education firm in Portland, Ore., and the author of books on requirements development. "You need people who can ask the right questions. Business domain knowledge is very useful for this process."

Not all companies, though, have rigorous requirements definition and management processes. "Most organizations have come to understand that requirements are critical to a software development project's success, but don't do very well at it," says Wiegers, whose books include Software Requirements and More About Software Requirements. "They realize they have to get better at this."

Before adopting the new process last October, Kaiser tracked software development projects on paper. Projects were managed on an ad hoc basis. "The details of how developers gathered requirements were never that clear," Cannon says.

So, many projects suffered from late changes, cost overruns and missed completion dates. "With the scale of projects at Kaiser Permanente often being massive, discovering issues late in the life cycle has huge impacts on time and cost," Schleifer says.

Projects that came in late, for example, typically ran well over budget. "We knew we needed to increase the quality of our development process and reduce late charges," Schleifer says. Unfortunately, he adds, "There's always been this rush to get to coding, rather than spending the time up front to do the due diligence on requirements."

For Kaiser, a major pitfall in its former process was a lack of detailed review by the project team. "This was a hole in the process previously," Schleifer explains. "The requirements would be sent to managers to sign off on, but they did not look at the details. With our new system, both the developers and the testers can work off this detail."

To help improve its requirements definition and management (RDM) process, last fall Kaiser began using Borland's RDM system and today is using Borland's full suite of RDM products. These include CaliberRM, a database for requirements development and management; StarTeam, a software change and configuration management system to keep track of changes made to a system over time; and Caliber DefineIT, a requirements definition tool that allows analysts and business users to collaborate on creating and changing requirements. DefineIT also permits textual input to be automatically diagrammed into a business process model based on requirements.

Of course, Borland's RDM products can't specify the requirements. "Our developers and technical people determine the quality of the requirements," Schleifer says. "The tool isn't going to spit out a well-written requirement unless they put it in there."

Requirements development and management generally encompasses five sets of activities:

  • Elicitation. This includes not only collecting a list of business needs, but also what one consultant calls "invention and discovery" of requirements—i.e., delving deeper into the business to discern otherwise hidden or overlooked requirements.

  • Analysis. This involves deriving a detailed set of requirements and ranking them according to priority. Kaiser chose to include analysis as part of the specification step below.

  • Specification. In this step, each requirement should be written in a form that clearly communicates its meaning. The requirements analyst expresses each business need, capability or condition in writing and enters it into, say, CaliberRM, which becomes the hub of the RDM process.

  • Validation. This step ensures that developers have a good set of requirements that accurately meet customer needs. As a technique to improve validation, Kaiser is using Caliber DefineIT to visualize and validate elements of a system.

  • Requirements management. This step ensures that the organization has a process for dealing with requirements that change during a project, as well as a means to track its status over time. Kaiser uses the StarTeam SCCM tool to do this.

    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

    Kaiser Permanente Base Case

    Headquarters: 300 Lakeside Drive, Oakland, CA 94612
    Phone: (510) 271-5910
    Business: Health maintenance organization providing medical plans and comprehensive medical services.
    Vice President of Applications Delivery: Kelly Cannon
    Financials in 2005: $31.1 billion revenue; $1 billion profit.
    Challenge: Improve and standardize the software requirements development process.

    BASELINE GOALS:
  • Expand KP HealthConnect from an internal network used by 12,000 physicians, to allow 8.5 million members to obtain patient records, make appointments and check lab results online.
  • Build 7 new hospitals, in addition to 30 now in service, by 2012.
  • Expand 19 existing hospitals to accommodate growth, including 13 under the company's seismic replacement program, as part of a $20 billion construction campaign.

    THE PRICE OF POOR PRACTICES

    70% TO 85% OF ALL PROJECT REWORK COSTS are due to errors in requirements, says a 1997 article in American Programmer.
    30% TO 50% OF THE TOTAL EFFORT EXPENDED on a software project comes from rework, according to an estimate by Borland Software.
    ALMOST 50% OF DEFECTS IN SOFTWARE PROJECTS can be traced to errors in requirements, Borland says.
    71% OF FAILED SOFTWARE PROJECTS suffer from poor requirements management, according to a paper presented at the 1999 Applications of Software Measurement Conference.