Implementing Design Controls

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

Originally Published February 2000

A step-by-step methodology for analyzing design practices and initiating process improvements creates a stable and supportive design process.

To varying degrees within every engineering organization, there are two parties in the process battle. The leader of the development side claims, "If we do it that way, we'll never get the product out the door!" The leader of the quality side replies, "If we don't conform to design controls, FDA will shut us down!" Both sides are right to a certain degree. Executive management needs a quality product that conforms to regulations, and it needs to have a product to sell. The best practice is to end the entrenchment of the quality and development sides by negotiating a solution acceptable to both parties; only when the effort wasted on argument is used to collaborate can the two sides begin taking steps toward producing a quality product within budget and on time.

STEPS TO DESIGN CONTROL

An organization's success at developing formal engineering practices begins with an evaluation of the current practices to identify opportunities for improvement. Overseeing such a project is the job of several process coordinators—each with his or her own unique area of expertise—collaborating to identify and implement process improvements. Once the process coordinators are assembled, the key to achieving process improvement becomes effective communication. It begins with the development of an understanding of the dynamics of the work environment, gained from those directly involved in it every day. Communication continues as process coordinators accurately capture the process, stabilize it, and listen for clues that suggest possible improvements. The following step-by-step methodology enables design coordinators to achieve these goals using formal methods that satisfy FDA 21 CFR 820.30 and CDRH's Design Control Guidance for Medical Device Manufacturers.^1,2

Understand the Organization's Cultural Behavior. To understand an organization's cultural behavior, process coordinators must identify how the organization's various levels of leadership define the value of process improvement. This understanding helps to reveal the cultural dynamics that dictate how and to what degree leadership will support process changes. In the goal-based system of any product development firm, resistance to change can be decreased by picking a strategy that ensures success for all parties involved.

To capture data for analysis, simple interview methods can be used to gather information on current practices. By establishing relationships with individuals who are involved in the process, coordinating teams can begin to understand why the organization behaves the way it does—what the current process is, why it is in place, etc.—and also learn about the success or failure of previous attempts to implement control over the development process.

For each component of success, an analysis should be performed to determine the gap between the perceived rating and the actual rating for the components at each organizational level. Figure 1 provides an example of a chart that can be used to establish the perceptions of success at each level of management. The analysis helps to determine if the current product development process meets the company's needs.

Anyone in the position of process coordinator must become adept at recognizing opportunities for change. Because such opportunities often occur during experiences that are painful to the developers, coordinators should develop skills to facilitate the developers' efforts. A realistic view of the process will help in making adjustments. As the developers place the coordinators in the role of helpers, gradual and successful culture changes will become common. During the period of evaluation, process coordinators must be careful and considerate; doing anything that causes anyone to lose face will erase the title of "helper" from the coordinator.

Negotiate a Consensus on Definitions of Important Terms. To begin communicating about sensitive issues, everyone involved must speak the same language. Differences of opinion on the correct use of terminology degrade a cooperative attitude quickly. In meetings, members often violently agree. Violent agreement occurs when communication breaks down and both sides of the discussion do not realize that they actually agree. In these situations, it is necessary for the process coordinators to identify the terms under debate and then defuse the conflict by coming to an understanding of how those terms will be used in future discussions.

Project coordinators must find ways of defining terms clearly. The following is an example of how the CDRH Design Control Guidance for Medical Device Manufacturers defines the application of design controls:

When the design input has been reviewed and the design input requirements are determined to be acceptable, an iterative process of translating those requirements into device designs begins. The first step is conversion of the requirements into system or high-level specifications. Thus, these specifications are a design output. Upon verification that the high-level specifications conform to the design input requirements, they become the design input for the next step in the design process, and so on.

In explaining a definition, a context should be established by referring to the related elements within the current process and explaining the definition at the level of granularity relevant to all present.

The term formal may be used to indicate a controlled document that is traceable; informal indicates that the document is not under control, not traceable, or both.

Add Visibility to the Completeness of the Formal Process. Understanding and capturing the formal process can be accomplished by determining the contents of the documents that the development team accepts as formal. The design inputs and outputs can then be mapped from concept information through to the finished product for everyone to see. Adding visibility to this process—under the premise of "This is how work gets done"—stimulates discussion as the informal elements of the process become apparent.

Capture the "As-Is" Process. When a gap between formal steps is discovered, it is usually an indication of an informal step within the process. Using the process map, the project coordinators should walk through the gap with the process owners and allow them to define how this informal step is achieved. Establishing the value of this informal step brings the team to a point of awareness where they understand that the process will be incomplete or burdensome without this step. Because they are established as common-sense practices by the developers, these steps are easy to formalize. Furthermore, allowing the process owners to define the steps provides vital insight into the development process.

Establish the Process. To establish the as-is process, the coordinators should define the process requirements for engineering the medical device. The source of requirements may originate from regulatory documents, from corporate policies, or from the best practices defined in the project management plan. The process requirements establish the foundation for the process. Tailoring the process is valid if the improvements continue to meet the process requirements.

Using the as-is process, the project coordinators should create a process architecture by describing the procedures, plans, and documents. For each type of document, a list should be made that includes the owner, the person who approved it, when during the project the document was created, which documents preceded the document, the document's purpose, and a description of the information it contains. The project coordinators must ensure that the process requirements lead to the process architecture in order to establish that the as-is process is complete and correct.

Procedures define in detail how to perform a task or activity, and should be defined in a way that does not change from project to project. For example, a document review procedure may define how to prepare for a peer review of a project document, what roles are assigned in the review, how to capture issues found during the review, and how to ensure that the issues are resolved after the review.

For documents and plans that are project specific, coordinators should create templates that contain the desired structure of the documents with detailed guidelines for each section describing any information to be added by the engineer. Colors or annotations are used to inform the engineer when a section may or may not be tailored.

To verify that procedures and guidelines are followed, process coordinators should establish a quality assurance role in the review process to ensure that project plans are met and that documents follow the procedures and guidelines. To validate the process, findings from external audits will ensure that the procedures, plans, and documents meet the intent of the process requirements.

Keep the Engineers Informed. Engineers should be kept up-to-date with the results of their inputs. Presenting them with information relevant to their focus demonstrates the organization's awareness of the value of engineering inputs. This feedback allows the engineers to retain ownership of the process, and it allows project coordinators to maintain access to the engineers' crucial insights.

Train for Quality Ownership. In order to determine the right balance between quality and time to market, the process team must acquire a realistic understanding of the intent of the design control regulations. To be prepared to train or to determine if someone else is qualified to train developers, the following steps are useful:

With this knowledge in hand, design control training for the developers can focus on the regulations and guidelines relevant to their roles. Using the as-is process, the coordinators should present to the team a map of the design inputs, outputs, verification tasks, and process validation tasks. With this information, the coordinators can then demonstrate how the team will adjust to meet the intent of the regulations. The goals of this step are to enhance the team's understanding of its role in meeting the organization's quality goals, and to use the team's knowledge of how the work is done to determine effective adjustments that conform with the design control regulations.

Establish Management Support. No organization can sustain a process without support for resources and enforcement from middle and upper management. Once the team is comfortable that the captured process truly reflects how the members work together, executive management's support is needed to solidify conformance to the process.

Even after honest negotiations, however, there may be a faction that wishes not to comply with the as-is process or process improvements. Directly or indirectly, these groups answer to upper-level management, and the nonconformance by this faction may be an acceptable risk for the organization. These methods are only effective in helping developers who want to mature their process. Coordinators should be prepared to help the nonconforming groups when they begin to recognize the value of controlling design.

Perform a Process Maturity Assessment. Design issues in software development provide a useful guideline for assessing process maturity. With software design, the use of the Software Engineering Institute's Capability Maturity Model by a team of software developers and quality assurance engineers allows a careful assessment of the maturity of the process.³ In addition, it adds visibility to the perceived maturity of the process and to the gaps in perception that remain between the developers and quality assurance engineers. The Capability Maturity Model can be—and often is—made generic for use in any design field, not just software, to provide design teams the opportunity to arrive at a common understanding of the intent of terminology and the values of continuing to mature their process.

Plan for Improvement. At this point the process should be stable, so process improvement can begin. This is the time to create a process improvement plan (PIP). Developers should assess the value of each formal process element and see which informal steps can be integrated to improve the process without causing unacceptable disruptions. When establishing priorities, coordinators should negotiate the value of formalizing steps that fill design control gaps. Allowing everyone access to the PIP effectively communicates the plans for improvement to the process team members and allows them to maintain ownership of the process. The plan should identify the team members who are actively involved in the process improvement project so those not directly involved will have a conduit for inputting their ideas.

The process should be refined in perpetual cycles. People and concepts come and go, and new team members must receive process training. At the same time, new ideas and concepts will flow into the process and work will become easier and more predictable. This maintenance cycle of the process should be supported using project post mortems, maturity assessments, and inputs from the quality engineers and developers. This step is essential to the team's continued ownership of the process.

Validate the Process through Useful Metrics. Metrics should be used to validate the efficiency of the process. Metric data can demonstrate that the exercise has been worth the organization's time and effort. Executive management took a risk by allowing this work, and the reward for doing so may be shown through charts with metrics demonstrating how maturing the process has resulted in a higher quality product and quicker time to market. Also, if the design outputs of process holdouts function as design inputs to team members, the process coordinators should capture the metrics to determine the effect of the holdouts' work quality on the development team.

HAZARDS TO IMPLEMENTING A PROCESS

Idealism. Many industrially accepted processes recommend the following flow: customer needs drive requirements and requirements drive the design. In reality, understanding the applications of a current and future technology may lead to a survey of customers to determine how these applications could be useful. An equally realistic approach is to use a customer need to drive the research of technologies to determine if a need can be met now or in the near future. A balance of these realistic approaches gives an organization an advantage over competitors. Thus, an idealistic process should never be allowed to hinder innovation.

Naysayers. Negotiating around the resistance of naysayers and having them share their expertise is a skill all process coordinators need to develop. Often, naysayers who eventually come around to the process turn out to be the strongest advocates for the process.

Firefighting. Some "firefighting" is normal, because taking project risks does not always produce a positive result. In other instances, motivation is required where procrastination is occurring. Prolonged firefighting occurs when a product's development flounders and deadlines are coming due. At this point, any formal processes are dropped under the premise that once the deadline is met, the documentation will be updated. Often, the results of prolonged firefighting include extensive overtime and a high turnover rate. Until management is a process champion and the process is visibly efficient, the best strategy is to plan a hurry-up process with a planned return to the as-is process once the crunch is over.

The continued maturity of the development process will be successful only if the teams that follow it also have ownership of it. Time will be wasted if a process is developed in a vacuum—even if a renowned consultant develops it—because the developers will not have ownership of the process.

When prioritizing process improvement opportunities by impact and changeability, process coordinators should initially focus improvements in areas that are high impact and easily changeable. The progress of implementing the improvements should be planned and tracked to protect the project from implementers who have difficulty keeping things simple and following the new procedures. To reduce the risk of a gradual letdown among the team members, coordinators should periodically reestablish the vision and goals. If this is unsuccessful, a change of leadership on the process improvement team may be necessary.

CONCLUSION

Upper-level support for a structured process comes as gradually as does grass roots support. Initially, turnover and reorganization are the greatest threats to maintaining and maturing a process. As ownership of the process grows, however, developers become aware of their control over the quality of the product; as awareness grows, pride in the team's work increases, and the rate of turnover will decrease.

An organization's acceptance of a new process comes with the knowledge that the process is flexible enough to bend with the dynamics of a product development life cycle. Detailed guidelines will ensure consistencies between project documents. In turn, this allows reasonable deviations and takes advantage of the creativity of the experts within the organization. To validate conformance to the process, coordinators should establish traceability between the documents that define the process and the documents that control it.

Once the process is stable, improvements should progress at increments proportional to the developers' capability to change, without the changes becoming a burden in themselves. Process obstructions will become visible to management as the complex relationships between project management, process management, requirements management, and change management are realized.

Maintenance of the process allows it to mature. Without a determined champion in place to keep the process current, it will fall back to its original level of maturity—with the exception of those stable processes that the development team accepts as common sense and value added.

REFERENCES

1. "Quality System Regulation, Medical Devices, Current Good Manufacturing Practices (cGMP) Final Rule," 21 CFR Part 820. October 7, 1996.

2. "Design Control Guidance for Medical Device Manufactures" (Rockville, MD: U.S. Department of Health and Human Services, Food and Drug Administration, Center for Devices and Radiological Health, March 11, 1997).

3. MC Paulk, B Curtis, and CV Weber, "The Capability Maturity Model for Software Version 1.1" (Pittsburgh: Software Engineering Institute, Carnegie Mellon University, 1993).

Michael A. Kuhn is the R&D process improvement team leader, the software engineering process group leader, and the software quality assurance leader for the Software Engineering Department at Siemens Medical Systems Inc. Ultrasound Group (Issaquah, WA).

Return to the MDDI February table of contents | Return to the MDDI home page

Copyright ©2000 Medical Device & Diagnostic Industry