Rediscovering Medical Device Systems Engineering, Part Three

The previous two columns in this series (Medical Product Outsourcing June and July/August issues) have explored the topics of system engineering’s disappearance from the medical device industry landscape as well as the critical roles and responsibilities fulfilled by systems engineering. This issue’s installment will discuss what the impact has been to project teams and organizations that do not incorporate systems engineering.

As a consultant working with numerous clients in the medical device industry over the years, I have had the unique opportunity to observe the significant impact the lack of systems engineering has had on organizational effectiveness, development schedule adherence, product quality and—ultimately—product development costs. From this unique vantage point, I have identified four significant recurring issues that directly are associated with a lack of systems engineering. To help organizations recognize the pitfalls that can be avoided if they embrace systems engineering, let’s look at these issues that affect organizations:

1. Technical Debt Resulting from Lack of or Poor Alignment of Stakeholder Needs
Despite all of the articles, papers and technical presentations published during the last few years regarding the importance of establishing effective requirements that span the needs of all product stakeholders, I am astonished by the number of companies that don’t do this at the beginning of the product-development life cycle. All too often, for example, I find that the needs of service, manufacturing and even regulatory affairs are not elicited early enough, or at all. The impact is significant as architectural design and implementation decisions are made that constrain the product and accumulate a level of “technical debt.” Stated another way, the longer these needs are not established or realized, the more costly it will become to incorporate them later.

With more than 80 percent of key product architectural and design decisions being made in the first 20 percent of the product realization process, the ability of development teams to incorporate late-breaking, fundamental needs such as manufacturability or serviceability increasingly becomes more difficult. At some point, due to the lack of architectural elements to support these needs, they cannot be addressed without significant refactoring of the architecture.

Additionally, even if such needs are identified, many organizations shy away from the difficult and somewhat “painful” process of prioritizing or aligning these needs. Systems engineering provides the architectural framework and glue among stakeholder needs while ensuring a holistic and systematic approach for ensuring that these needs are accounted for throughout the product realization process.

2. Evolutionary Design Falls Short
One of the more startling comments I hear from many product development leaders is, “I have really good engineers. They just know what to do.”  While it’s true that most engineering organizations have solid engineers, it’s also true that without a systems engineering framework and focus, engineers typically do not have sufficient context or visibility to ensure that design decisions and issue resolutions are aligned with the overall system’s architectural intent.

For many organizations developing less-complex products, the lack of alignment and systems perspective can be overcome by sheer effort and determination. However, medical products are becoming more complex, and must fit into systems of systems frameworks demanding higher levels of interconnectivity, interoperability and data management and accessibility. As a result, as customer demands for solution-focused—not product-focused—offerings increase, the resulting increased systems complexity cannot be organically or evolutionarily addressed without a systems engineering approach.

3. Identifying, Managing and Mitigating Fault Conditions is Reactionary
Hand in hand with the problems of evolutionary design is ensuring system designs account for and adequately address risk, error and fault conditions. It is widely recognized in the industry that the design and development activities associated with normal or “happy path” product execution account for only 30 to 40 percent of the overall development schedule.

This means that in order for a product to provide the level of quality and robustness required to meet marketplace demands, teams must focus a significant percent of their time on fault or error condition handling. As with all aspects of system design, if there is not a system-level focus provided by a systems engineering approach to identifying, managing and mitigating these fault conditions, the process of handling these situations becomes reactionary rather than planned.

For many organizations, this manifests in prolonged test and verification cycles—“testing in quality.” And, it is accompanied by late breaking architectural and design changes that tend to make the product less stable, more prone to reliability issues and directly impact product quality, development schedules and cost.

4. Limited or No Use of Simulation and Emulation Makes Development Virtually Impossible
As today’s medical devices become more complex and the number of interfaces and components increase, it increasingly is difficult to develop, test, integrate and verify the systems without the support of simulators and/or emulators. The “big bang” integration approach taken by many organizations today makes it difficult, if not impossible, to integrate and debug systems effectively without pre-testing system components within a simulation/emulation framework.

Thus, incorporating a systems engineering approach is critical because it provides:

• Clear identification of component interfaces including time-based control and data flows;
• Identification and development of simulators and emulators, based on these interfaces, which enable components to be encapsulated;
• Component encapsulation allowing development teams to thoroughly test and verify the proper operation of their components independent of the other components in the system; and
• Systematic and controlled means to integrate components incrementally, enabling issues and problems to be easily isolated and resolved.

* * *
The impact on companies not incorporating systems engineering is real, painful and significantly can impact the bottom line. For many readers, the issues explored here will resonate on some level with their own product development experiences—maybe resulting in decreased product quality, slipped schedules, increased development costs, and/or delayed revenue recognition. While the high level solution is straightforward, incorporating systems engineering into your development framework—its actual realization—is far more challenging. 

Editor’s note: The fourth and final article in this series will discuss the process of adopting and incorporating systems engineering into organizations, and the key steps and activities to facilitating a relatively painless and successful organizational transformation.

---

Christopher Miles serves as the vice president of the Consulting Services group at Foliage Inc., a product development company that partners with companies to address the business and technical challenges inherent in developing complex software intensive systems. With more than 25 years of experience in the research, design, development and management of complex medical and biotechnology products, Miles has contributed to numerous U.S. patents, and directly collaborated on the commercialization of more than 20 new medical and biotechnology products. Foliage leverages more than 20 years of experience partnering with leading companies in the medical and life-sciences, aerospace and defense, and industrial equipment industries. The company is based in Burlington, Mass. Foliage is part of Altran, a Paris, France-based innovation and high-tech engineering consulting firm.