In this series we have explored the myths surrounding systems engineering, the critical roles and responsibilities of this function, and the impact on product realization efforts when the role is missing. It has been my intent, through this series, to lay the groundwork for convincing you of the absolute necessity of incorporating systems engineering into your product realization activities. For those who have bought into my argument, this last post will provide an overview of the key areas that form the basic framework for transforming your organization.

Fundamentally, the needed changes to incorporate this “new” role span three key areas – organization, process and execution. Each area warrants unique attention and if the required changes for each area are not embraced, the overall benefit and effectiveness of the system engineering role will be severely limited.

Organization

A successful transition to a systems engineering-centric organization must begin with the support of upper management. The lack of support from this level of the organization is one of the most common reasons that organizational change fails. Additionally, change leaders must get the organization involved in the change process itself. If not, the members of the organization will perceive the change as imposed on them and actively resist it.

Once the need for change has been recognized, many change leaders choose to engage outside support to guide and facilitate the change process. The use of outside support, although not critical, can help accelerate the transition timeline by leveraging the skills and experience of experts in this area. When selecting this level of support, I recommend developing selection criteria to include, at minimum, the following:

• A proven track record implementing the type of change you require in your organization;
• Clear engagement models to support the change; and
• Active mentoring and coaching during the first implementation. 

The next step in this process is to identify what systems engineering will mean for the organization, what elements it will embrace and what problems it must solve. Throughout this series we have identified many of these elements, but fundamentally, the role of systems engineering must enhance and support the organizational “DNA” for product realization. Key activities include establishment of the systems engineering role and areas of responsibilities, defining the relationship of this new role to the organization and project teams; and finally, identifying the necessary resources to support this new position.

Of all the areas identified, finding engineers to support this new role is the most challenging for most organizations. Effective systems engineers embody strong cross functional and interactive skills, have participated in multiple full product lifecycles, understand the fundamental tools and practices utilized and demonstrate systems and systems of systems thinking. It is the latter that truly denotes effective systems engineers and is also the most difficult to obtain. Systems and systems of systems thinking is something, based on my experience that cannot be taught. It is experientially learned by individuals who, through life’s experiences, have developed the ability to “see the forest through the trees.”

It should be noted that thanks to the long standing application of systems engineering within the aerospace and defense industries, many colleges and universities – MIT, Johns Hopkins and Worcester Polytechnic Institute – to name a few, now provide graduate level programs in systems engineering. Although these programs tend to focus on the aerospace and defense-related approaches, they do provide fundamental training in areas such as requirements definition and management, architectural formulation and evaluation, and systems integration and test.

Process

With the organization elements now solidified, the next step is to codify the organizational approach to systems engineer within the quality system, specifically the product development process and ancillary SOPs. The ultimate goal of these activities is to provide an operational framework that identifies the boundaries of the role and enforces the facilitative and participatory nature of the position. Overall it must be reinforced that the systems engineer is responsible for activities associated with translating customer need into product realization. Additionally it must be affirmed that the systems engineer provides the “glue” between the cross-functional elements of the project. They are responsible for ensuring all activities are organized, planned, and aligned with the overall architectural intent of the product, and risk is actively managed throughout all lifecycle activities.

Execution

The final and most crucial step in this transformation process is the application of this new role with its associated processes to an actual product realization effort. Of all the areas identified, this is the most difficult and challenging because change is not always “welcomed with open arms” in most organizations.  Again, upper management can play a key role in institutionalizing this transition by setting realistic expectations for the first project team including recognition that all the benefits of a systems engineering approach will not be achieved the first time through. The key for the organization as a whole is to stay focused, not give into old practices and actively learn from each experience within the development lifecycle. 

Conclusion

The healthcare industry ecosystem continues to evolve at a rapid pace with potentially radical implications for medical devices and systems. High levels of integration and interoperability, commoditization of medical device hardware, increased competition and cost containment pressures are among the myriad challenges facing the medical device industry today. While a systems engineering approach will not, in and of itself, resolve all these issues, it is the cornerstone and framework for allowing organizations to begin to address these challenges by adopting a more holistic, efficient and systematic approach to product realization.

For more on this topic, check out the first three posts: Where Have all the Systems Engineers Gone? Part One: Overview, History and Myths; Part Two: Roles and Responsibilities; and Part Three: What’s Missing?