Where Have All the Systems Engineers Gone: Overview, History and Myths
As today’s medical devices and systems become increasingly more complex and interconnected it is crucial for organizations to reassess their development team structures and actively re-incorporate the function and role of the systems engineer. The upside potential for incorporating systems engineering is significant and goes right to the bottom line development costs for product realization.
So what is systems engineering? According to the NASA Systems Engineering Handbook, “Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system.” Furthermore, the International Council on Systems Engineering (INCOSE) defines systems engineering as, “An interdisciplinary approach and means to enable the realization of successful systems.” Ultimately, I think Sarah A. Sheard, Software Productivity Consortium, said it best, “The systems engineer is the Owner of ‘Glue’ among subsystems, the seeker of issues that fall ‘in the cracks,’ the ‘technical conscience of the program.’”
Systems engineering was first recognized as a critical role by Bell Telephone Labs in the early 1940s and by the end of that decade it was adopted and became a mainstay of the Department of Defense. Since then, systems engineering has become a cornerstone in the aerospace and defense industry. However, it wasn’t until the late 1980s that the medical device industry began to recognize and incorporate systems engineering as a critical part of their development teams; and by the late 1990s, the role had established a solid foothold.
However, this trend seems to be making a dramatic reversal as more and more companies appear to be relegating the systems engineer to system architecture, or abandoning the role all together. The reason behind this trend is not obvious. However, my work with many medical device and product manufacturers reveals a set of myths that may be driving the thinking in these organizations—ultimately contributing to this current trend.
Systems engineering myths
Myth #1: Systems engineering is all about requirements and architecture
While system architecting, the iterative process of translating user need into requirements and system structure, is an important role in the development of today’s ever complex, highly integrated systems, it is only a piece of the development puzzle. Like the foreman or prime contractor overseeing a new home construction project, it is the systems engineer who ensures that all the architectural pieces come together through the action of the various functional team members while confirming that the system is built in the right order to the specific plans established, and issues and risks are addressed in a timely manner.
Myth #2: Experienced teams don’t need systems engineering
While experienced teams are one of the critical cornerstones of effective product development, good engineers alone do not ensure effective product realization, especially as the products developed increase in scope and complexity. Experienced developers tend to focus on their part of the product and can often lose sight of the bigger picture. Thus systems-level issues such as error budgeting, interface management, and system integration and testing are often unattended and missed.
Myth #3: Good planning and procedures negate the need for systems engineering
Although solid planning, structured by a well-defined system architecture and an effective set of development processes, are certainly key components in product development, they tend to be static or contained activities. A key function of systems engineering is to attend to the dynamics that occur during development. No matter how good your planning is, it is guaranteed that some part of the overall system will change or run into roadblocks. The role of the systems engineer is to act as the “technical facilitator” to ensure that changes are systematically assessed and risks attended to. In many cases, engineers will make tradeoff decisions regarding component design or operation without taking into account the impacts of these changes on the larger system. It is the role of the systems engineer to assess these changes and insure the overall needs and architectural intent of the system remain aligned.
Myth #4: Only big companies can afford systems engineering
The need for systems engineering is not limited by company or development team size. While it may be true that on small projects, by sheer will and effort, development teams can overcome the obstacles of not having a systems engineer, the lack of having a person in this role comes at a cost. This cost is usually realized in slipped schedules, difficultly in integration activities, and ultimately increased development costs. For most organizations, the investment in systems engineering will more than pay for itself within the next product development lifecycle, regardless of the size of the organization.
Summary
Systems engineering is a challenging role that requires not only a broad diversity of cross-functional engineering skills, but the ability to effectively facilitate the “hard” and sometimes difficult discussions that must occur between members of the development team. At its core, the systems engineer must be a “technical facilitator” who has enough technical skill and domain knowledge to identify technical risk, challenge design decisions, and bridge the gap between the functional elements of the product development process.
The systems engineer is the “glue” between the functional elements of a system as well as the watchdog and gatekeeper of the architectural intent and subsequent product realization. Without a qualified person active in this role, development teams struggle and this struggle is only magnified as the size and complexity of the system grows. At some point, without systems engineering, large-scale systems simply become unrealizable.
As a whole, the medical device industry needs to introspectively assess the issues and challenges it has encountered during previous product realization efforts and tally the resulting costs incurred. In most cases, many of the challenges and issues identified could have been mitigated by a systems engineering approach. Thus, it can almost be guaranteed that by investing in a systems engineering approach most organizations will see an immediate return on their investment within the timeframe of their next product development lifecycle.
In my next post I will explore the critical roles and responsibilities of the systems engineer and why, in today’s product development landscape, manufacturers should reassess their need for systems engineering; and the significant impact this can have on their bottom line and overall business.
Related Articles
-
On the journey to full-scale production for medical devices incorporating optics, a series of steps early in the process can make all the difference for successfully launching new products and introducing next-generation upgrades. This article discusses four considerations for a…
-
You’d think there’s not much to the concept of an alarm. A warning sounds in a room, or a red light flashes, and it has your attention. You know something must be wrong. But in a setting where a cacophony…
-
Regulatory requirements for computer systems validation (CSV) have long been in place, but their compliance requires considerable time and resources. In the life sciences industry, traditional validation processes add to project timelines and costs, affecting time to market and preventing…
-
This year, the healthcare industry will step up its fight against cyberattacks because the costs and risks to patient care are becoming too great.
