Systems Engineering, Part 1

From Principles to Strategies

Applying Principles, Practices, and Processes of Systems Engineering to solve complex technical, operational, and organizational problems

Start with the end in Mind

Systems engineering activities provide these guiding principles.

• Provide Technical Frameworks - Integrated, consistent, and repeatable processes to reduce risk; methodical and disciplined approach, integrative discipline; planning and execution of the program's technical approach; Implementing and maintaining disciplined SE processes.
• Manage Requirements - Identify user needs; manage the system baseline; report baseline changes; contribute to defining, establishing, and achieving affordability targets; Supports the development of realistic and achievable program performance, schedule, and cost goals; generate affordability targets, Tracking baseline changes; balance the conflicting design constraints of cost, schedule, and performance.
• Provide Integration - Provides the end-to-end, integrated perspective of the technical activities and processes across the system life cycle; integrate contributions across engineering disciplines; "Support contract award and execution”; “Track and manage the execution of the contract's SE-related tasks”, “ensure integrated and effective processes” [Moved from Put SE on contract]; Provide recommendations on the contract strategy.
• Identify and Mitigate Risk - Reduce technical risk; Resolve conflicting design constraints of cost, schedule, and performance; Manage root cause and corrective action (RCCA) efforts; Support the risk boards; Recommend path forward.
• Evaluate, Verify, and Validate – the program maturity of the system baseline; Measure and track program maturity using technical performance measures, requirements stability, and integrated schedules; Analyze and verify technical assumptions; Provide event-driven technical reviews and audits.

Systems Thinking

Before moving to Systems Engineering let’s talk about Systems Thinking. Systems Thinking is a popular word with weak definitions. Russell Ackhoff provides us with the best descriptions of the concept. These notions started with Peter Senge’s The Fifth Discipline, 1990. It was largely unnoticed and unappreciated and mostly misused, in part because the idea of Systems Thinking is practiced using too narrow a definition of the term system.

Another issue with Systems Thinking is assuming there is a grounding in Systems Engineering as the basis of discussion. Without this grounding, the thinking about systems has no foundation on which to stand.

Russell Ackhoff† tells us systems are defined by:

• Parts
• Relationships
• Purpose

Systems Thinking looks at:

• Relationships – rather than unrelated objects
• Connectedness – rather than structure
• The whole – rather than just its parts
• Patterns – rather than contents 

Thinking systematically … requires several shifts in perception, which lead in turn to different ways to teach, and different ways to organize society. Our perception needs to move away from …

• Taking the thing or event to be understood apart
• Explaining the behavior or properties of the parts taken separately
• Aggregating the explanations of the parts into an understanding of the whole, the thing to be explained.

Moving to Synthetic Think †

Managers should never accept the output of a technologically-based system unless they understand exactly what the system does and why. Systems must be understood in the context of what they can do and the world in which they will do it. It is not enough to see the system as a sum of the operations of the component parts. It must be seen as a functioning whole. This is the System Thinking Point of View.

A system starts with an idea that will be translated into reality. The idea of the system must be linked to the reality of the system through an engineering process. The system design must take into account the properties of the systems. This seems like a tautology, but the properties of the system are:

1. Entities – are the parts that make up the system
2. Attributes – are the characteristic of the entities that are measured.
3. Relationships – are the associations that occur between the entities and attributes. These associations are based on cause and effect.

For Systems Engineering to be effective in this Synthetic Thinking paradigm, the systems engineers need a language to express the design of the system.

This using this language, the system can be expressed in the form of a hierarchy of units.

• A system is composed of subsystems
• Subsystems are composed of assemblies
• Assemblies are composed of subassemblies
• Subassemblies are composed of parts

Systems Engineering is ...

“an interdisciplinary approach to translating users’ needs into the definition of a system, its architecture and design through an iterative process that results in an effective operational system. Systems engineering applies over the entire life cycle, from concept development to final disposal.”

Here are several key ideas about Systems Thinking applied to Systems Engineering

• Systems Engineering begins by identifying the needs of the user to assure that the right problem is being addressed by the system.
• The interdisciplinary means multiple disciplines are involved in engineering, use, and response to the systems.
• Systems are architecture. They are not just a pile of parts. They have formal relationships between the parts and this formality is defined in the architecture.
• Effective operational control is an outcome of engineering a system. The Measures of Effectiveness for our notional project will be defined by the architecture we will develop. Effectiveness is engineered.
• Lifecycle is a term we’ll use often. Systems Engineering is not a one-time process. It is applied across the entire life of the product or service. From inception to retirement.
• The systems engineer defines the functions needed to deliver an operational solution to the stakeholder. This is both a technical and managerial process. The technical aspects are addressed in the design and implementation efforts needed to transform a need into a capability for the stakeholder. The managerial process supports the technical process through planning, risk management, integration of the engineering specialties, maintaining the technical configuration, and continuously assuring cost, schedule, and technical performance objectives are being met.

Part 2 is Next

Part 2 will present the foundation of all project success, no matter the process or framework - Capabilities Based Planning.

Many projects provide a multitude of technical and operational features and functions. We’ve all experienced this. Software tools, automobiles with more features than we can remember, complex systems like aircraft with features so complex the pilots have trouble remembering how to operate then (one cause of the Asiana Air crash in SFO is attributed to the multiple features in a decent control system that created confusion).

One improved approach to engineering a system is to determine what capability is needed to accomplish the mission or provide a solution to the business problem.

Many approaches to developing systems start with requirements. PMI does this. All successful development and governance processes, instead start with capabilities based planning

• What capabilities can we provide our customers with that they are willing to give us money for?
• What capabilities do we need in our ERP system to remain or be more competitive in the marketplace?
• What capabilities are needed by the warfighter, school systems management, retail strategy makers
• Provide safe transport on public highways is a capability. No single failure in the braking system shall endanger life is a requirement.

It’s the needed capabilities that make or break a system. Are these capabilities present for the user? Can the user put the system to work to solve a problem?

Requirements come next, but they are not the starting point. Without knowing what capabilities are needed, the requirements have no home. We see this all the time why does this thing we just bought do or not do something. The designers may or may not have identified the needed capabilities first before they started building.