Every Problem is a Systems Problem

There are three classes of problems in our world of program management: [1]

• Top-Down problems
• Middle-Out problems
• Reverse-Engineering problems

Classic problems are top-down. The other two classes are rarely considered when discussing systems engineering solutions in the program management domain.

Let's start with what a system is ...

A system is a group of components that interact with one another. When the components start interacting, it affects the whole system's behavior, which directly depends on the components and how they interact with each other.

The interactions of the system elements usually have feedback and feedforward loops. If there is neither of these, the components of the system have no interaction and are considered de minimus systems.

In the Top-Down problem-solving domain, the solution providers are faced with designing an unprecedented solution to stakeholder problems. These solutions are many times labeled green field development. These systems have unknowns whose solutions involve research, development, new components, or new manufacturing processes.

The Middle-Out solution begins with modeling the existing solution to provide an understanding of the existing solution, processes, and technologies. This provides visibility to what can and cannot be changed and where opportunities for improvement or requirements can be identified. This approach is successful in process improvement and system-of-systems domains.

Bottom-up or Reverse-Engineering applies to upgrading or replacing an existing solution that has enhancements or fixes over the system's life. This approach is focused on recovering the original requirements that resulted in the as-built design.

Any solution process needs to support these three classes of problems.

Systems Thinking

Systems thinking is a disciplined approach for examining problems more completely and accurately before acting. It allows us to ask better questions before jumping to conclusions.

Systems thinking often involves moving from observing events or data, to identifying patterns of behavior overtime, to surfacing the underlying structures that drive those events and patterns. By understanding and changing structures that are not serving us well (including our mental models and perceptions), we can expand the choices available to us and create more satisfying, long-term solutions to chronic problems. — Michael Goodman

There are several approaches to modeling systems

Model-Based Systems Engineering (MBSE)

The idea that a system is more than the sum of its parts is defined by the International Council of Systems Engineering (INCOSE) as a system to construct or collect different entities that produce results not obtainable by the entity alone.

Modeling of systems starts with identifying:

• Entities of the system - the parts (things or substances) that make up the system.
• Attributes - the characteristics of the entities perceived and measured.
• Relationships - the associations between the entities and attributes

Models aid our understanding of the way the world works. Models span the spectrum between form and function, with tangible, visible models to equations or simulations implementing those equations.

There are four elements of the model:

• Language - that expresses and represents the model
• Structure - allows the model to capture system behaviors
• Argumentation - represents the design so that the design of the system can be demonstrated to accomplish its purpose
• Presentation - some mechanism showing the way the model can be seen and understood

Four Characteristics of a Model

1. Order allows the designers to address the problem coherently, leading to a viable solution.
2. The power to demonstrate the relevant behavior of the proper relationship between the system entities.
3. Integrity and Consistency of the credibility that the system meets the needs it was designed to meet.
4. Insight into the solution the system is designed to address.

Here is an example of Model Based Systems Engineering for the AWS Cloud Services

Design Structure Matrix

Design Structure Matrix (DSM, also known as Dependency and Structure Modelling ) techniques support complexity management by focusing on complex system elements and how they relate.

The DSM is a network model representing the elements of a system and their interactions., highlighting the architecture. The DSM is used to model the development of complex systems.

A DSM chart can create insights for system engineers and managers who must design, organize, implement, and maintain the system and its many interactions.

DSM‐based techniques have proven valuable in understanding, designing, and optimizing complex system architectures for products, organizations, and processes.

The DSM process includes:

• Development Process - which maps the activities and deliverables required to execute complex procedures such as engineering design. This allows system engineers and project managers to understand the design iterations required in the process, to smooth out the flow of information, and to get things done faster.
• Organizational Planning - which maps the people, teams, and departments working together to execute complex workflows. This allows managers to see how people communicate and which ones would benefit from greater alignment, physical co-location, or better connection to the system being developed or managed.
• System Design - which maps the components of a complex system about each other. This allows engineers to see the system architecture in a new and compelling way. It helps designers visualize the interaction among modular and integrative elements of a system, spot missing interfaces, and cluster components into more effective subsystems.

Value of this Approach to Problem Solving

When we hear about problems, be they engineering problems, social problems, or process problems, we need several things to be in place before suggesting a solution:

• What are the parts of the problem space?
• How do these parts interact?
• What needs to be added to the solution space?

And Most Important

• What are the root causes for these missing or misapplied processes?

Once we have a model of the system, it's dysfunction, misfunction, or malfunction, any proposed solution must address the root cause of this condition.

It is common to point out Symptoms and assume that is sufficient to solve the problem. Here's a short overview of Root Cause Analysis

References

[1] A Primer for Model-Based Systems Engineering, 2nd Edition, David Long and Zane Scott, Vitech 2011.

[2] Design Structure Matrix Methods and Applications, Steven D. Eppinger and Tyson R. Browing, The MIT Press, 2012.

[3] Apollo Root Cause Analysis: Effective Solutions to Everyday Problems Every Time, Dean L. Gano, Apollonian Publications, LLC, 3rd Edition, 2007