Christopher Miles, Foliage Inc.07.22.14
The first part of this series of articles (the June issue of Medical Product Outsourcing), explored the disappearance of systems engineers in the medical device industry and some of the myths and misconceptions that may be behind the trend. This installment will explore the question: What are the critical roles and responsibilities for systems engineers?
One of the challenges when discussing systems engineering is that the term itself has become so overloaded. Much like agile development, systems engineering has no clear unified meaning. Organizations, industries and individuals tailor the meaning to fit their needs. To frame the rest of this discussion, I will share my view of systems engineering and discuss the six critical roles and responsibilities it encompasses.
Architect
This is probably the most commonly understood and agreed upon role within systems engineering. Typically, this role is about the iterative and quantitative process of translating product stakeholder need into architectural design, including requirements definition and risk management. Long gone are the days of waterfall architecture (i.e., first detailed requirements then architecture).
Today’s architect must take a holistic view of stakeholder needs and actively ensure alignment of the architecture to those needs while providing a level of flexibility in the architectural process that accommodates and embraces changes as a normal course of development.
Most organizations have learned the hard way that the product architectural process is not only about translating end user needs into design, but it also must account for and align the needs of all the product stakeholders. This includes customers, sales, marketing, management, development, service, quality, regulatory and manufacturing.
The architectural process must critically attend to elements such as:
• Use of formal means of architectural assessment (e.g., architecture tradeoff analysis method or software architecture analysis method);
• Effective system functional decomposition with clear allocation of requirements to each subsystem including clear interface requirements and associated data, control and sequencing flows;
• Ensuring the system can accommodate not only happy path operation, but also error and fault conditions;
• Effective performance and error analysis, budgeting and allocation;
• Support elements such as test fixtures, simulators or emulators; or
• Approaches for unit, component, integration and system test and verification strategies.
Technical Facilitator
It is unrealistic to expect systems engineering to work in a vacuum. No matter how skilled a systems engineer is, ultimately he or she must work collaboratively with all stakeholders and players to successfully realize the products. Systems engineers must employ active listening skills while monitoring and adjusting their verbal communication to ensure that the message, not the delivery style, is understood. Ultimately, they facilitate and resolve technical and programmatic group problem-solving and decision-making activities.
Planning and Coordination
Ultimately, while the project schedule is owned by the project manager and team, its structure, sets of activities and interdependencies and phasing are heavily influenced, if not driven by, the fundamental architecture of the system. For this reason, systems engineering must play a significant role in the planning and execution coordination aspects of the project.
More specifically, systems engineering provides the critical input for planning such elements as:
• The system components and/or subsystems that need to be developed including both simulators and emulators;
• The approach for development sprints or iterations;
• The approach for integrating and testing each product component and component sets as the product is systematically developed and then assembled into the final configuration;
• The approach for verification and validation activities including strategies for automation;
• How the product is to be built, assembled and tested in manufacturing, including what test stands and support elements need to be developed; and
• The elements that need to be developed to support servicing the product in the field.
Planning and ultimate execution coordination needs to be dynamic and embrace change. For this reason, systems engineering needs to be highly integrated with project management activities in order to provide the necessary technical and architectural focus to ensure effective change management and dynamic re-scoping of project activities as the issues, risks or changes occur.
Risk Management
As with any medical device product development program, risk management is a cornerstone activity that spans the complete product life cycle. Because of the unique, holistic and system-level view provided by systems engineering, systems engineers must lead and facilitate the elements within this framework. Risk management encompasses two unique sets of activities centered on technical and programmatic risk.
Technical risk management encompasses the more traditional elements of IEC 14971, 62304 and 60601. Such activities include ownership of the risk management file, driving top-down and bottom-up risk identification and mitigation activities using approaches such as failure mode and effects analysis or fault-tree analysis. Additionally, technical risk management includes ensuring the identified mitigation strategies and requirements are met through the architecture, development and verification activities.
Conversely, programmatic risk is about the risks associated with actual product realization. Often the role of systems engineering is to articulate the impact of technical risks as they are identified in terms of schedule or project cost. The systems engineer is the initial technical representative who works with the project manager in identifying and ultimately mitigating these risks.
Troubleshooter
Because of their unique knowledge of the system architecture, systems engineers typically are the first line of defense as systems-level issues are identified. As issues are uncovered, their role is to drive the issue resolution process through a combination of hands-on or group problem-solving activities. The most significant product development issues typically occur at the interface layer between system components. While development teams are very adept at resolving issues within the framework of their component development activities, they often do not have the system-level perspective to fully understand how the changes they make can impact the overall system.
Systems engineering brings to bear not only the understanding of the internal construction of the system, but how it solves and meets the needs of all the stakeholders. Systems engineering plays a key role in supporting and providing first-level troubleshooting support for such activities as verification, validation, manufacturing pilot builds, and even clinical trials.
Keeper of the Architectural Vision
One of the most critical roles and areas of responsibility for systems engineering is to actively ensure throughout the entire product realization process that all activities maintain alignment with the product architecture. Therefore, it is crucial that systems engineers participate in all design, development and testing activities.
* * *
Systems engineering is a key critical component of the product development process. The cost to organizations that don’t embrace it is significant. As products become more complex and demand higher levels of interconnectivity, the impact of slipped schedules, increased development costs and delayed revenue recognition is real and substantial.
Fully embracing and incorporating systems engineering into a company’s product development process is not insignificant. In addition to the needed changes in organizational culture, the challenge of finding just the right individual with the necessary skills to satisfy the various roles and required activities can be daunting. Despite these challenges, the benefits to the bottom line are significant and well worth the effort to incorporate the systems engineering role.
Editor’s note: This is the second installment in a four-part series. The next article will explore the most significant and common issues or challenges organizations face when they don’t pay attention to, or fail to incorporate, systems engineering.
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.
One of the challenges when discussing systems engineering is that the term itself has become so overloaded. Much like agile development, systems engineering has no clear unified meaning. Organizations, industries and individuals tailor the meaning to fit their needs. To frame the rest of this discussion, I will share my view of systems engineering and discuss the six critical roles and responsibilities it encompasses.
Architect
This is probably the most commonly understood and agreed upon role within systems engineering. Typically, this role is about the iterative and quantitative process of translating product stakeholder need into architectural design, including requirements definition and risk management. Long gone are the days of waterfall architecture (i.e., first detailed requirements then architecture).
Today’s architect must take a holistic view of stakeholder needs and actively ensure alignment of the architecture to those needs while providing a level of flexibility in the architectural process that accommodates and embraces changes as a normal course of development.
Most organizations have learned the hard way that the product architectural process is not only about translating end user needs into design, but it also must account for and align the needs of all the product stakeholders. This includes customers, sales, marketing, management, development, service, quality, regulatory and manufacturing.
The architectural process must critically attend to elements such as:
• Use of formal means of architectural assessment (e.g., architecture tradeoff analysis method or software architecture analysis method);
• Effective system functional decomposition with clear allocation of requirements to each subsystem including clear interface requirements and associated data, control and sequencing flows;
• Ensuring the system can accommodate not only happy path operation, but also error and fault conditions;
• Effective performance and error analysis, budgeting and allocation;
• Support elements such as test fixtures, simulators or emulators; or
• Approaches for unit, component, integration and system test and verification strategies.
Technical Facilitator
It is unrealistic to expect systems engineering to work in a vacuum. No matter how skilled a systems engineer is, ultimately he or she must work collaboratively with all stakeholders and players to successfully realize the products. Systems engineers must employ active listening skills while monitoring and adjusting their verbal communication to ensure that the message, not the delivery style, is understood. Ultimately, they facilitate and resolve technical and programmatic group problem-solving and decision-making activities.
Planning and Coordination
Ultimately, while the project schedule is owned by the project manager and team, its structure, sets of activities and interdependencies and phasing are heavily influenced, if not driven by, the fundamental architecture of the system. For this reason, systems engineering must play a significant role in the planning and execution coordination aspects of the project.
More specifically, systems engineering provides the critical input for planning such elements as:
• The system components and/or subsystems that need to be developed including both simulators and emulators;
• The approach for development sprints or iterations;
• The approach for integrating and testing each product component and component sets as the product is systematically developed and then assembled into the final configuration;
• The approach for verification and validation activities including strategies for automation;
• How the product is to be built, assembled and tested in manufacturing, including what test stands and support elements need to be developed; and
• The elements that need to be developed to support servicing the product in the field.
Planning and ultimate execution coordination needs to be dynamic and embrace change. For this reason, systems engineering needs to be highly integrated with project management activities in order to provide the necessary technical and architectural focus to ensure effective change management and dynamic re-scoping of project activities as the issues, risks or changes occur.
Risk Management
As with any medical device product development program, risk management is a cornerstone activity that spans the complete product life cycle. Because of the unique, holistic and system-level view provided by systems engineering, systems engineers must lead and facilitate the elements within this framework. Risk management encompasses two unique sets of activities centered on technical and programmatic risk.
Technical risk management encompasses the more traditional elements of IEC 14971, 62304 and 60601. Such activities include ownership of the risk management file, driving top-down and bottom-up risk identification and mitigation activities using approaches such as failure mode and effects analysis or fault-tree analysis. Additionally, technical risk management includes ensuring the identified mitigation strategies and requirements are met through the architecture, development and verification activities.
Conversely, programmatic risk is about the risks associated with actual product realization. Often the role of systems engineering is to articulate the impact of technical risks as they are identified in terms of schedule or project cost. The systems engineer is the initial technical representative who works with the project manager in identifying and ultimately mitigating these risks.
Troubleshooter
Because of their unique knowledge of the system architecture, systems engineers typically are the first line of defense as systems-level issues are identified. As issues are uncovered, their role is to drive the issue resolution process through a combination of hands-on or group problem-solving activities. The most significant product development issues typically occur at the interface layer between system components. While development teams are very adept at resolving issues within the framework of their component development activities, they often do not have the system-level perspective to fully understand how the changes they make can impact the overall system.
Systems engineering brings to bear not only the understanding of the internal construction of the system, but how it solves and meets the needs of all the stakeholders. Systems engineering plays a key role in supporting and providing first-level troubleshooting support for such activities as verification, validation, manufacturing pilot builds, and even clinical trials.
Keeper of the Architectural Vision
One of the most critical roles and areas of responsibility for systems engineering is to actively ensure throughout the entire product realization process that all activities maintain alignment with the product architecture. Therefore, it is crucial that systems engineers participate in all design, development and testing activities.
* * *
Systems engineering is a key critical component of the product development process. The cost to organizations that don’t embrace it is significant. As products become more complex and demand higher levels of interconnectivity, the impact of slipped schedules, increased development costs and delayed revenue recognition is real and substantial.
Fully embracing and incorporating systems engineering into a company’s product development process is not insignificant. In addition to the needed changes in organizational culture, the challenge of finding just the right individual with the necessary skills to satisfy the various roles and required activities can be daunting. Despite these challenges, the benefits to the bottom line are significant and well worth the effort to incorporate the systems engineering role.
Editor’s note: This is the second installment in a four-part series. The next article will explore the most significant and common issues or challenges organizations face when they don’t pay attention to, or fail to incorporate, systems engineering.
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.