Ten Techniques for Trimming Time to Market

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

An MD&DI August 1997 Column

BOTTOM LINE

Savvy companies can keep up with rapidly changing regulatory requirements and still streamline processes in product development.

At the same time that FDA's new quality system regulation has heightened the emphasis on regulatory requirements in the medical device community, pressure to speed up the manufacturing process is also escalating. It may seem impossible to reduce the time to market with the numerous other demands on the engineering process. However, compliance with regulatory requirements does not preclude efficient development practices.

Relying on individuals to rescue lagging projects with hours of overtime is not a workable solution. A system-level strategy is needed to streamline the engineering process and achieve reduced development schedules. By effectively addressing the following 10 aspects of product development, medical device manufacturers can improve both regulatory compliance and time to market:

The extent to which the following strategies for dealing with these aspects apply to a given manufacturer will vary based on the specific device and personnel experience. Manufacturers may also find additional steps are necessary in certain processes.

DESIGN CONTROL REVIEWS

The cost benefits and quality improvements resulting from effective review practices can be substantial, such as a tenfold reduction in errors for some development efforts.¹ Although reviews are mandated by the new quality system regulation, they also benefit engineering by reducing development times. Moreover, specification reviews help identify errors early, when they are relatively inexpensive and easier to correct. Dunn has suggested that cost savings from error identification and correction can be as much as a factor of 25.²

Formal reviews also help ensure consistency and understanding of key project objectives and provide a forum for effective communication between engineering and other departments as well as among engineering subdisciplines concerned with hardware and software.

DOCUMENTATION DETAIL

The importance of documenting compliance with design control requirements is self-evident. But some companies have instituted documentation practices that go far beyond any requirements. These manufacturers falsely equate the weight of documentation produced with product quality. Their goal instead should be to shift the emphasis from documentation quantity to documentation that contributes to product quality.

One way to help achieve this goal is to determine the documentation requirements for each project, including only procedures and specifications that apply to that particular effort. In addition, the level of documentation detail should be based on the significance of the device requirements. For example, the design and development plan might specify that programmers should formally document and review unit and integration testing for safety-related requirements but document verification less formally for functions that do not affect safety.

To reduce the workload and simplify the training of new personnel on the appropriate documentation format required for each specification, try using automated templates. Encourage the use of tables and diagrams to reduce text and to make documents easier to understand.

INTEGRATED TEAM ENVIRONMENT

Historically, the emphasis in product development was on the productivity of individuals and individual engineering disciplines. Engineering departments tended to develop their own subsystems, resulting in significant problems later in the development process. It is now well established that team focus and discipline are essential to prevent such bottlenecks. To cope with the increased complexity of today's products, an integrated team is an imperative.

To ensure that customer requirements are correctly captured; that the target device can be efficiently manufactured, installed, and supported; and that process compliance and submission requirements are met, the teams must include a range of disciplines. This will minimize the risk of important requirements being forgotten in the haste to compress the development schedule. It will also satisfy FDA's expectations that such disciplines as marketing, servicing, and quality assurance are included in product development.

MANAGEMENT

Numerous studies have attempted to quantify the essence of successful project management, but no silver bullet has yet been identified.³ However, a risk-driven management style that continually tracks potential problems and tries to identify solutions can be highly effective.⁴ Early identification of ineffective approaches to a project allows adequate time to switch to more appropriate solutions.

Paying close attention to the schedule enables management to achieve ambitious deadlines. It's more common, however, to focus instead on the technical aspects of the development process and strict adherence to defined standard operating procedures (SOPs). The result of insufficient attention to tracking and monitoring progress is often the sudden realization that the project has fallen behind schedule, sometimes irreparably.

Many design and development teams believe that all requirements contribute equally to customer satisfaction, and marketing groups tend to believe that all requirements have the same cost and schedule implications. These assumptions are not necessarily true. Changes are often readily accepted without consideration of their impact on a project. An analysis should be done to assess any changes to see what effects they have on scheduling and costs. Decisions can then be made whether to implement specific changes and extend the project schedule or to maintain the schedule and postpone the change for a subsequent release.

PERSONNEL

Most regulatory requirements focus
on the process as the primary determinant of success and do not pay enough attention to personnel. Hiring qualified personnel is one of the most significant strategies to ensure productivity. The range of productivity among design engineers is perhaps most pronounced in software development. Studies have shown that one programmer may be up to 10 times more productive than another.⁵ Hiring practices, therefore, should address not only the educational background of potential employees but also include in-depth interviews and testing.⁶

Employee development must also be addressed. Training programs should include not only regulatory compliance, but also effective design practices that lead to reduced errors and higher productivity. Identifying the practices of the most efficient engineers in the company and sharing them with others is often effective in increasing overall productivity.

Finally, motivation is an essential element of efficient productivity. Individuals are more likely to perform at their peak when the work environment and compensation systems motivate them to meet schedules and quality objectives. When overtime is mandated as a solution to address tight schedules, the desired productivity gains are often overshadowed by the losses experienced as a result of reduced motivation.

PROCESS EVALUATION

Improving procedures is frequently suggested as a panacea for shortening development schedules. Published models such as the Software Engineering Institute (SEI) capability maturity model have been used by some companies hoping to develop more-efficient practices.⁷ However, these models often result in greater delays and costs before any real schedule savings are realized. Making improvements to the existing process rather than substituting a new one may sometimes yield more immediate improvement.

One way to proceed is to measure the effort associated with current procedures to determine their efficiency and the quality level they produce. Perform a Pareto analysis of the phases that require the greatest amount of time and find ways to reduce the schedule through concurrent development or increased automation. The quality level produced in each stage can be determined by examining errors in verification activities and final validation testing. This information can pinpoint the phase in which the most errors are introduced and help identify techniques to prevent future mistakes.

An experienced auditor can be invaluable for assessing current practices and offering strategies for improvement based on lessons learned from other departments or companies. Audits that focus on optimizing development schedules are perhaps the quickest way to identify process improvements that can reduce time to market.

Postmortem evaluations of recently completed projects can also be helpful. Identify which activities were successful and which impeded productivity. Use this analysis to define possible strategies for improvement, such as staff training, using subcontractors for problematic components, emphasizing up-front reviews, and procuring new automated tools.

PROCESS PROCEDURES

Procedures for documenting the development process receive the most attention from auditors because they are the focus of regulatory standards (FDA and ISO). Nonetheless, SOPs should satisfy engineering needs first and regulatory requirements second.

Ensure that SOPs are flexible and can be individualized for any project. Most projects are a mix of new functions and existing code and hardware designs, plus integration of off-the-shelf components and subcontractor products. Flexible strategies should ensure that these subsystems are integrated and validated in a manner that achieves the desired quality levels. This objective cannot be satisfied through strict adherence to structured SOPs that place too great an emphasis on document-driven sequential models.

SOPs should be continually updated with methods taken from the most effective development teams. Process improvement teams should also be encouraged to go beyond SOP compliance and given resources to facilitate improved productivity. Many companies do this through use of an intranet system that provides libraries of sample SOPs and guidelines, automated tools, reusable software components, sample specifications, and recommendations on vendor products. Internal procedures should encourage the sharing of any resources that can contribute to process productivity improvements.

PROTOTYPES

Although development techniques based only on prototypes have historically been criticized as a source of low-quality devices, manufacturers can use prototypes effectively to help compress development time. Early prototypes can ensure that the user interface and functionality envisioned by engineering is consistent with the user needs and intended use requirements. Soliciting user input with prototypes is much more effective than providing users with a technical specification that may be difficult to read and understand.

Prototypes can also help personnel address technical questions. Early tests can discover whether additional processing capacity is required or whether certain algorithms need to be optimized. Identifying these problems early with high-level prototypes can avoid costly schedule delays during implementation.

Early prototypes can be used in clinical studies to gain data on device effectiveness. However, prototypes must be validated to ensure safety and performance requirements before any clinical use. Feedback may be required in order to determine which parameters are most significant in predicting desired outcomes. Prototype models can often clarify these unknowns.

TEST STRATEGY

Testing has been described as the most poorly scheduled part of the development process and perhaps also the most poorly managed.⁸ Testing should be performed periodically throughout development, not just during the last phase. Early design activities should incorporate testing at the unit or component level followed by structured integration testing prior to the formal validation test. Managing these early phases can reduce the number of errors and lessen the formal testing required at the final test phase, when schedule pressures are the greatest.

Many projects progress well during development only to encounter significant delays throughout the final test phase. Progress is frequently measured by the volume of test cases completed with no other criteria evaluated to determine testing adequacy or completeness. Measurable test completion criteria should include, at a minimum, tests to ensure coverage for all specified requirements. Manufacturers have significantly reduced the number of test cases by tracing test procedures to specified requirements. Large volumes of test procedures that exercise the same requirements in different combinations have little likelihood of identifying new errors.

TOOLS

There has been phenomenal growth of computer hardware capacity during the past 30 years. The expanding hardware capacity has been closely followed by increasingly powerful software tools, including those that support engineering development. Failure to harness the power and flexibility of these tools will hamper a company's ability to achieve optimum reduction in development schedules.

Automated tools can be useful in the support of design, from analysis of material dimensions for hardware to management of software changes and version control. These tools can perform the mundane but essential tasks of the design and development process in a far more efficient and reliable manner than humans can.

Automated tools are excellent for catching errors early in design stages. Tools used in support of hardware design can analyze the strength of materials and the consistent definition of interface signal levels. Software tools can catch common errors in typing, parameter passing, and initialization. Even the most structured design process can be significantly enhanced by tools that can catch errors that are difficult for the designer to identify.

CONCLUSION

FDA regulations, ISO standards, and associated guidelines continue to increase the requirements for product approval. Customers expect to receive more product capability and quality at reduced cost. In conjunction with these external pressures, device complexity continues to expand at an alarming rate. Designing and developing new products to meet these demands is challenging. By using the 10 steps described above, it is possible to minimize costs and reduce scheduling while producing a quality product that meets FDA regulations and ISO standards.

REFERENCES

1. Freedman DP, and Weinberg GM, Handbook of Walkthroughs, Inspections, and Technical Reviews, 3rd ed, New York, Dorset House,
p 12, 1990.

2. Dunn RH, Software Quality Concepts and Plans, Englewood Cliffs, NJ, Prentice-Hall, p 79, 1990.

3. Brooks FP Jr., "No Silver Bullet, Essence and Accidents of Software Engineering," IEEE Computer, August, pp 10­19, 1987.

4. Boehm BW, "A Spiral Model of Software Development and Enhancement," IEEE Computer, May, pp 61­72, 1988.

5. Keyes J, Software Engineering Productivity Handbook, New York, Windcrest/McGraw-Hill, p 513, 1993.

6. "Microsoft Software Development Procedures Test/Verification Procedures," Microsoft, Redmond, WA, Personnel Qualifications section, p 2, 1996.

7. Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24, Pittsburgh, Software Engineering Institute, February 1993.

8. Brooks FP Jr., The Mythical Man-Month, Reading, MA, Addison-Wesley, p 20, 1975.

Daniel P. Olivier is the president of Computer Applications Specialists, Inc. (San Diego), a software validation and development services company.

Copyright ©1997 Medical Device & Diagnostic Industry