A Blueprint for Quality

Originally Published MDDI January 2004

Systems Development

Guidant reveals its strategy for reengineering the 12 procedures that guide its business-software system development process.

Beth Crandall

Would you build a house without a blueprint? Would it make sense to pour the concrete without understanding how strong the foundation must be, or to build the frame without knowing how many rooms are needed? When building a large, tangible object like a house, the cost of getting it wrong and doing it over again is understood. These costs exist when building more-abstract structures, such as software systems, as well. They just aren't always as obvious or as easy to quantify. But the fact remains: when building anything at all, you must first create a blueprint if you want a quality end product. 

Despite this truth, two blueprints for the same type of house can be different. The safety rules and regulations for a house built in Minnesota are not the same as those for a house constructed in California. There are some commonalities and some justifiable differences. The same is true for software systems development. There are different best practices and different rules and regulations, depending on various factors. The more people involved in the system development efforts—and the more locations the systems cross—the more complicated understanding the rules and regulations, and agreeing upon best practices, becomes.

These very complications comprised a recent challenge faced by Guidant Corp. The processes to build the software embedded in the company's medical devices were defined and controlled very well, but the processes for the associated business systems were more diverse. There was agreement that certain processes were needed to build software systems for the business, but there weren't common best practices, or even a common set of regulations, because significant differences existed among the business units. 

A History of Growth

Guidant is made up of multiple business units, each with a different product focus. The product focus at the largest business unit, Cardiac Rhythm Management (CRM) in St. Paul, MN, is implantable defibrillators and pacemakers. The second-largest business unit is Vascular Intervention (VI), with locations in both Temecula and Santa Clara, CA. The product focus at VI is stents and dilation catheters. Each business unit had been effective at developing systems for its own use, but project teams encountered challenges when developing systems that crossed business units.

As the company expanded, and the demand for systems that could work across business units grew, the need for a standard system development process with shared terminology became apparent. Yet flexibility, too, was needed to incorporate different approaches and different rules and regulations, so a particular system development project team could select the process that might best fit its needs, while remaining compliant. The company also saw the need to prepare for expected regulatory changes, such as those for electronic records and signatures and the HIPAA regulations.

In 2001, Guidant expended significant effort to reengineer its Guidant System Development Methodologies (GSDM) for nonmedical device systems and software. The project's aim was to clearly identify and document the rules and regulations that applied to all business units and to provide effective procedures for complying with them. It also needed to provide a common framework for system development best practices that could be used by all business units. 

The reengineering project was sponsored by William McConnell, Guidant's vice president and chief information officer. The project involved creating and updating procedures, templates, and supporting documents, as well as computer-based and classroom training for the affected audience. People at all locations and business units, in multiple departments, were affected. 

The remainder of this article explains how Guidant approached this effort. Specific information is included, with lessons learned and tips for those who might undertake a similar project. This reengineering endeavor happened to be for system development processes at a large medical device company, but many of the same principles can apply to any process-overhaul effort at a company of smaller size. 

Define the Destination

Reengineering processes is really a journey. In order to make such a journey successful, you must have a destination in mind. Guidant's project team began by establishing a specific policy the reengineered GSDM would support. The policy states:

All nonmedical device system development meets the appropriate regulatory requirements and corporate requirements and follows clear and effective processes in order to produce high-quality and effective nonmedical device software products and systems in a timely manner.

The first project objective was to identify and clearly document the appropriate regulatory requirements. Guidant undertook a separate, year-long project to update the complete list of specific compliance requirements that pertained to the development of all regulated software. A subset of requirements for nonmedical device systems and software was then identified within that list. That subset of requirements provided the foundation for the reengineered GSDM, and it became a 30-page document titled Non-Medical Device System Development Policy and Requirements. The phrase nonmedical device system development was used to distinguish this methodology from the methodology used to create software systems for implantable medical devices, which are required to meet an even higher standard.

Practice What You Preach

Even though it was a project to reengineer a process rather than create software, the team decided to follow the same waterfall methodology typically used to conduct software development projects. In other words, the project team practiced what it preached and followed good process. Figure 1 shows the project phases and the key project deliverables produced.

Each project deliverable was important to the quality of the overall end product. The first deliverable to be produced was the concept document, which was like a contract with the key stakeholders. The concept document provided the high-level definition of the problem, the description of the solution, an outline of the roles and responsibilities of the project team, and a rough estimate of the schedule and cost. To continue the analogy of building a house, it could be compared with asking all family members to stand on a plot of empty land and agree on a common vision of what they need, what will be built, who will be involved in building it, how long they will take, and how much the house should cost. 

The project plan and requirements specification were developed next. The project plan was a living, changing document throughout the project. It originated from the information in the concept document and provided more detail, evolving as the project itself evolved. It contained the detailed project scope and objectives; a list of the specific project outputs; the roles, responsibilities, and names of the team members; the detailed project schedule; and more-detailed cost information.

A detailed project plan can't be developed without knowing exactly what is required, which is why the requirements specification was needed at the same time. The project team held focus-group sessions, gathered information about the compliance issues, and evaluated the overall environment in order to develop the requirements. Again, the key stakeholders had to be gathered to obtain alignment and reach agreement on the requirements before further work could be done.

As the reengineering progressed, many individuals had different ideas about what could or should be done, and there were several points in the project where “scope creep” could have bogged it down. Having clear requirements that were endorsed by the top sponsors provided a means of settling disputes and managing the scope. 

These first three deliverables took a lot of time and generated many passionate discussions. For any project, whether it is a reengineering effort or system development endeavor, it is critical to create similar deliverables. They save time and effort in the end. Just like with a house-building project, the team needs common agreement on what is needed—in much detail—with clear plans on how to achieve it. Otherwise, the team will encounter issues later, when the house is being built, which will result in delays, rework, and waste.

In Guidant's case, once agreement on the requirements was reached, the team created a detailed design specification. The design showed the procedures that would be developed and how they would relate to each other, and it outlined the level of detail and the general format for each procedure. Figure 2 shows the overall document relationships defined in the design specification. 

A total of 12 procedures were identified as needing to be created or revised. The discussions generated in the design phase clarified that the project scope should focus on procedures using the waterfall method. Procedures used in other methods, such as the iterative approach, were deferred for future development. The team also decided to develop procedures for common processes that apply to all projects, regardless of the methodology used. These common procedures included items such as configuration management, hazard/risk assessments, and reviews.

The key stakeholders were brought together once again at the end of the design phase to agree on the design before the construction phase began. A sample procedure was also drafted in order to help the stakeholders envision how the procedures would look. In the design phase of any project it is common for some requirements to be revisited. Once people see the design and understand more about how things will come together and what is required to produce it, some additional changes are often suggested. Likewise, when a blueprint for a house is finally drafted, and the owners see the design clearly, they tend to make changes. It's much better to make the changes at this phase, even if it means multiple drafts of the blueprint, than to make them once construction has begun.

For example, at one point in the Guidant project, a requirement change was suggested in the design phase regarding the amount of detail to include in the procedures. The sample GSDM procedure that was drafted explained both what to do and how to do it. Some people wanted to omit the how to information, and healthy debates on this topic ensued. It was finally decided that there were too many variables and too many different ways to accomplish the tasks to effectively include how to information. The resulting requirement specified only the what to do information in the procedures. As a compromise, supporting documents were created to provide instructions on how to perform some activities. Because of time and resource constraints, the supporting documents were considered outside the scope of the project and were created as an extra effort. In fact, such documents continue to be developed by various subject matter experts (SMEs) and added to the suite of GSDM materials.

Divide and Conquer

Because there were so many procedures to be created and a limited amount of time budgeted for the project, the work was divided into teams of people working simultaneously. The process for creating and revising the 12 procedures included assembling core project teams, specific SMEs, and general reviewers.

Each procedure was assigned a technical writer and two or three SMEs. To achieve balanced representation, each team of SMEs included at least one member from each of the two largest business units. The technical writer created a first draft of the procedure, based on the list of requirements and, where possible, existing information. The technical writer then conducted working sessions with the SMEs to refine the procedure and include overall best practices for the topic (see sidebar). 

Once the technical writer and SMEs were satisfied with their draft, they submitted it to the designated general reviewers, who tended to pick it apart. The technical writer and SMEs then revised the procedure to incorporate the general reviewers' input. Some of the more-complicated procedures required multiple review cycles. 

Each issue raised by a general reviewer was formally logged and tracked to resolution. This tracking process served as a valuable tool for managing the construction of the procedures overall, because some issues and changes applied to all procedures. Issue categories and severity codes were established to help distinguish “showstopper” issues from “nice to have” recommendations, and to identify issue trends. 

It took four months for all 12 of the procedures to go through the review cycle. Then, a two-week, end-to-end review was conducted to check for consistency and accuracy across all of the procedures. After those last updates were complete, the procedures were submitted for final approval and publication.

An important lesson learned was that clear, detailed standards must be established and enforced if multiple writers and SME teams are to work successfully in parallel. Some standards had been identified, but the team would have benefited from developing them earlier, in greater detail, and then freezing them. Some of the issues that caused frustration and rework could have been avoided if the standards had been more thorough.

Careful Planning Pays Off

When you move into a new house, multiple efforts must be planned and coordinated to make moving day successful. The same was true for planning and coordinating the implementation of the reengineered procedures. The implementation plan was carefully defined during the construction phase. It involved publishing the new procedures in the on-line procedure system, conducting special communication sessions at multiple locations, and developing a 30-minute computer-based training course. A 12-hour classroom training session was also planned for those who needed more-detailed information. Software quality assurance analysts were made available as well, to help project teams understand and use the new procedures for their projects. The implementation plan also called for developing a process for tracking change requests and maintaining the procedures. 

Careful planning allowed for a successful rollout across the multiple locations in April 2002. The chief information officer and chief compliance officer, who were the top-ranking project sponsors, spoke at the communication sessions in an auditorium. They articulated the business drivers and the compliance drivers behind the reengineered procedures and provided valuable executive-level support. The first of these sessions was videotaped, and the portions showing these top sponsors continue to be shown in the ongoing training classes to reinforce the importance of the procedures. The top sponsors also sent a memo and related e-mail announcing the new procedures and reinforcing their importance. Those whom the procedures would affect the most were identified and targeted for the communications effort, including project teams, management, internal business customers, and Guidant internal auditors. The locations affected the most were Minnesota and California, but employees in Puerto Rico, Europe, and Asia were affected as well.

About three months after the procedures were implemented and operations had stabilized, the company conducted special postproject reviews. Project team members were brought back together to collect lessons gleaned from the project. The information gathered from those sessions was consolidated and presented to management so the lessons could benefit other projects. 

Define Success

Unfortunately, no specific metrics on time and cost savings exist. Neither do bottom-line impact measures to quantify the success of the reengineered methodology. There are ways to define and collect metrics that show reduced rework and waste, but no such specific measures were used for this project. Instead, the company gained an intuitive understanding of its value. The definition of success for Guidant is that the procedures use common language, define common deliverables, and provide a common understanding of best practices—at least in terms of what to do, if not always how to do it. The common process with common terminology makes it easier for Guidant to assemble the right people with the right capabilities on a project team so that they can be productive from the start, regardless of their business unit.

The company has also seen a recognizable change in attitude regarding GSDM. Prior to the project's start, confusion and frustration about the required activities and deliverables existed. Since the project's completion, however, GSDM is recognized as necessary and helpful in conducting a project, because it clearly shows what is required within a best-practice process framework. It also allows flexibility to incorporate different approaches to system development, so that a particular project team can select the process that is best for that project.

Continue to Build

Guidant reached the original destination for its project, but the journey isn't over. The company continues to add to the foundation laid by the GSDM reengineering project. For example, the company has since developed supporting documents focused on architecture-related deliverables, and it has added many project management templates and tools. The company continues to create procedures for iterative development. A special Web site on the Guidant intranet provides easy access to the GSDM materials. 

In the special regulated world in which a medical device manufacturing company, such as Guidant, operates, quality is critical in all aspects of running the company. In the specific area of software system development, the reengineered GSDM provides a blueprint for quality. 

Copyright ©2004 Medical Device & Diagnostic Industry