Looking over the landscape of companies and clients that I have supported over the years, four issues arise repeatedly with organizations that do not embrace systems engineering. In sharing these issues, I want to help organizations recognize the pitfalls that can be avoided, if they embrace systems engineering. Without systems engineers, what is the impact to project teams and organizations

1. Lack of Effective Identification and Alignment of Product Stakeholder Needs
   In this day and age I am astonished at the number of companies that do not holistically assess the needs of all stakeholders at the beginning of the product development lifecycle. All too often, I find that the needs of service, manufacturing and even regulatory affairs are not elicited early enough, and as a result, these development teams accumulate a level of “technical debt” which is increasingly more costly to resolve as product development progresses.

   With over 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 becomes increasingly 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 the needs are identified, many organizations shy away from the difficult and somewhat “painful” process of prioritizing or aligning these needs. As previously discussed, systems engineering provides the architectural framework and glue among stakeholder needs and ensures a holistic and systematic approach for ensuring that these needs are accounted for throughout the product realization process.

2. Evolutionary Versus Planned System Design
   One of the more startling comments I hear too often from product development leadership 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, these engineers typically do not have sufficient context or visibility to ensure design decisions and issue resolutions are aligned with the overall architectural intent. While for less complex products this lack of alignment can be overcome by sheer effort and determination, most of today’s medical systems demand a level of complexity and interconnectivity that cannot be organically addressed.

3. Happy Path Focus
   Hand in hand with the problems of evolutionary design are the issues associated with 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% 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 as “testing in quality.”

4. Limited or No Use of Simulation and Emulation
   As today’s medical devices become more complex and the number of interfaces and components increases, it is increasingly difficult to develop, test, integrate and verify these systems without the support of simulators and/or emulators. For many large-scale systems, the “big bang” integration approach to development -just putting everything together and trying to make it work- becomes virtually impossible. Thus the framework of 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
   • A systematic and controlled means to integrate components incrementally, enabling issues and problems to be easily isolated and resolved.

Summary

For companies not incorporating systems engineering, the impact of this void is real, painful and packs a significant wallop to the bottom line. For many of you reading this I believe that the issues raised resonate on some level with your own product development experiences; and may have resulted in slipped schedules, increased development costs, and/or delayed revenue recognition.

So the final question remains, “How do organizations that recognize the criticality of this role effectively incorporate systems engineering?” In my final post, I will explore this question further and provide insight into the critical steps and key activities that can facilitate a relativity painless and successful organizational transformation.

For more on this topic, check out the first two posts: Where Have all the Systems Engineers Gone? Part One: Overview, History and Myths and Part Two: Roles and Responsibilities.