No matter how integrated the system engineering process is, none of us have the opportunity to design and implement totally disconnected systems in our organizations. Even if we are starting from scratch or greenfield, we need to consider how our new system will interact with existing systems. John Blyler’s (Design News) Blog on Middle-out/Inside-out systems engineering reminded me about the realities of implementing systems engineering in real-world complex organizations. A real-world where most of the development work happens on existing products instead of new products (Sony says 80% of new products are improvements of existing products and Harvard Business Review says 80% of new product launches fail ). This makes the systems engineering mantra of “defining the problem before you solve it” even more important since you not only need to get the requirements, constraints, and interactions understood, but you also need to understand the “why’s” behind the existing product. Failure to do so means your exposed to the technical risk that will get expensive if you discover it late in the product life cycle (see earlier discussion on Murphy effects).
Systems Engineering Tools…
Good engineering schools and professional societies such as INCOSE teach the system engineering process AND give you tools, methods, and techniques to adapt to your complex work environments, which means systems engineering tools should help you capture and manage/deal with complex systems inside and outside of your product. One of those tools is analogs, i.e. look for existing systems and use them in design and managing product development. Biological mimicry/Biomimetics is one source of possible product problem solutions with the idea that nature has already developed many working complex systems and shook them out. For example, Human Anatomy and the interacting body systems can be an analog of how projects and development processes interact with each other:
This ‘anatomy of a project’ shows how various body systems can be compared to project systems and how their interactions can help understand/describe project/organization interactions. For example, if the brain/project management is cut off from the circulatory system/information systems poor decisions are made. I think systems engineering (SE) and the nervous system are analogous, SE is supposed to understand what’s going on in and around the project/body and react in a systemic way to avoid injury. I’m sure I’ll get comments from some of you on how other project illnesses align well with this analog.
I recently had the experience of participating in a transplant process for a relative dealing with organ failure and attended a transplant orientation meeting. It was an education in dealing with existing complex systems and how a systematic approach is required to improve your chances of success. The multi-hour seminar included many different presenters/disciplines each with their perspective to ensure a successful transplant:
- Transplant overview/process
- Medical ethics and priority
- Organ function and symptoms
- Social aspects with families, support groups, …
- Finances…cost, acquisition, maintenance, …
- Dietary…weight, nutrition, physical condition, …
- Pharmacology…anti-rejection, side effects, infections, …
- Caseworker…prequalification, tests, clearances from…
- Legal…living wills, etc.
- Surgeon…procedure, risks, etc.
…that’s right the surgeon was last on the list. With this anatomy of a project in my head, I started thinking how implementing MBSE into an existing organization/complex system is a transplant-like process (even start-ups like SpaceX, Uber, Hyperloop, and others must deal with existing interacting systems)—so ok, replacing existing critical legacy organization systems with models/tools is a transplant-like experience.
So how can medical’s transplant process/experience help us make MBSE organization transplants successful as well:
- Transplant overview/process—agreed on new product development process
- Medical/tool ethics and priority—agreement on when tools will/will not be used, buy-in from organization, …
- Organ/tool function and symptoms—understanding of what functions the tool will perform and what symptoms it addresses and definition of success
- Social aspects with the organization—support organization to support the tools, PR campaign, internal user group,…
- Finances…cost, acquisition, maintenance–financial budget to cover implementation/maintenance/support of tools
- Tool Dietitian…weight, nutrition, physical condition—training plan, deployment plans, maintenance, etc.
- Pharmacology…anti-rejection, side effects, infections–tool usage incentives, metrics, opportunities, etc.
- Caseworker…prequalification, tests—project management, on-site support, who will use it, etc.
- Surgeon…risks—Project, IT, and Engineering Design Center Mgmt
This is enough to scare any organization, but like transplant patients, there’s not much choice since there aren’t enough brains out there to scale to the complexity we are experiencing in today’s complex products; why we are implementing a system engineering process supported by MBSE.
Of course, there are examples of successful transplants and support groups out there, just as there are examples of organizations that have successfully completed MBSE transplants, one case study about Siemens Healthcare within my own company is available for downloading/reading. Siemens Healthcare successfully navigated the transplant process dealing with existing processes, in a highly regulated industry, with mergers and legacy practices/processes conflicts, all in a systematic way. Hopefully, it will help you with your own MBSE transplant implementation.