For this series, the Velentium blog welcomes back Principal Systems Architect Satyajit “Sat” Ketkar. Sat’s career encompasses nearly twenty years of electrical, firmware, software, and systems engineering experience, including seven in medical device design and two with a European Union notified body conducting device reviews and audits for safety, quality, performance, and security.
Sat’s insights will take us systematically through the product development lifecycle for medical devices. Our focus will be on technical ownership of the project. For each development phase, we’ll answer the question, “What is the role of the Systems Engineer during this phase?”
Before we dive in, we want to make clear what we mean by “Systems Engineer.” A Systems Engineer is not an engineer who designs systems infrastructure; rather, it is the engineer who has technical ownership of the entire project. His or her responsibility is to look at the details of every aspect of the project with respect not just to requirements and use profiles, but also with respect to every other subsystem and interface, as well as the project as a whole.
The International Council on Systems Engineering (INCOSE) defines Systems Engineering as “a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.”
In other words, Systems Engineering is the bonding agent that brings quality management, project management, and technical execution together into a final deliverable. At Velentium, we often call this “integrated systems design” or “whole-system thinking” and it is one of our nine realms of expertise.
Since the System Engineer’s foundational function is to guarantee deep technical continuity throughout the project, the role would ideally be fulfilled by the same person(s) throughout the entire product lifecycle… but that’s not practical or possible in every scenario. Part of the System Engineer’s responsibility, then, is to identify key deliverables from each project phase and keep them continuously maintained and archived for optimal handoff on short notice. He or she must be constantly vigilant against “tribal knowledge” throughout development. A good Quality Management System, such as Velentium’s ISO 13485-certified QMS, working in tandem with a well-chosen Configuration Management System, goes a long way toward helping with this. It’s the System Engineer’s job to make sure these systems are being followed properly, with appropriate workflows, and on a timely rhythm to prevent knowledge loss and facilitate the smoothest handoff possible if/when such a handoff becomes necessary.
Feasibility
In the Concept / Feasibility development phase, the Systems Engineer’s role is to help the company or project team answer two questions: Is this product a good idea? Is developing this product a good idea for our company/team at this time?
Is this product a good idea?
To help the client or company answer this question, the Systems Engineer’s first job is to ensure feasibility discussions include all relevant technical factors, making sure nothing is left out. To do that, he or she must identify all of the expertise the project will require and make sure persons who have the necessary expertise get brought into the conversation. In this first stage, the Systems Engineer is working against the principle “we don’t know what we don’t know” by identifying gaps in awareness and soliciting input from those who can identify and address those gaps.
Next, the Systems Engineer helps evaluate viable architectural paths for each element of the project, researching and scoring different architectures to present to decision makers. The Systems Engineer’s goal is to drive discussion of viable options and save the project from bending toward the “experience bias” brought to it from previous projects. We all have our preferred ways of developing solutions, but those aren’t necessarily best for this particular project. Similarly, there may be pathways that we like less, but that doesn’t necessarily mean they are wrong for this project. The Systems Engineer’s goal is to present options scored on an unbiased scoring metric, based on a user-assigned weighting system, which is capable of arbitrating between personal inclinations vs. the actual capabilities and cost-benefit of a particular solution or approach.
A classic method for modeling and weighing options is the Kepner-Tregoe approach, as detailed in their book The New Rational Manager: An Updated Edition for a New World. Kepner-Tregoe’s definitive work is an excellent resource for Systems Engineers seeking to correct “experience bias” and enable rational decision-making at this critical stage of project evaluation.
Is developing this product a good idea for us at this time?
Many factors come into play when answering this question, of which some – business considerations, resource availability, market timing, and so on – are outside the purview of Systems Engineering. However, the System Engineer’s preparatory work at this stage help inform discussion of these factors.
Based on the preceding determinations, the Systems Engineer will describe the project using a Technical Challenge Profile. This does not necessarily need to be exhaustive or dive into the nth level of detail; rather, it looks at each aspect of projected development and asks, “what is New, Unique, or Difficult (NUD) about this project?” For each aspect, the NUDs are evaluated relative to the specific experience and qualifications of your development team. The System Engineer’s goal is to identify potential pitfalls and roadblocks so that additional resources can be assigned or alternative approaches defined well in advance of the coming challenge.
