Hello, my name is Robert Halligan. I am Managing Director and founder of Project Performance International. PPI consults and trains worldwide in systems engineering, having delivered training to 17,000 plus alumni in 41 countries over six continents. PPI is also a member of the INCOSE Corporate Advisory Board and has a MOU with INCOSE to work collaboratively towards the advancement of systems engineering practice. I hope that you find this short session on myths in systems engineering thought-provoking and useful. Here we go!
Myth number 1:
Systems engineering is a process. Well, no, not really. Systems engineering is best regarded as a set of principles, based on systems thinking and a set of systems building blocks with which we construct our own process. Now that process is dependent on variables such as the complexity of the problem and solution, the degree of novelty, and the value and importance of the system amongst other parameters together with a set of process elements that are used selectively, always driven by value on the balance of probabilities, and within the concepts of recursion and iteration.
The process elements are:
• requirements analysis: requirements capture and validation
• physical design: deciding and recording how we will build the system
• logical design; formalizing the logic of how the system is to work, typically in functional or state-based terms. Physical and logical design are obviously intimately related.
• effectiveness evaluation and decision making: the conduct of trade-off studies, evaluating and selecting between feasible design alternatives
• description or specification of system elements: outputting requirement specifications on subsystems or other system elements to drive acquisition or development of those elements
• system integration: building a system in development by creating aggregates, carrying out integration testing, adding more subsystems, bigger aggregates, more integration testing, and bringing the system to the point where the system seems to have come together correctly and to be working correctly, either as a prototype or as the end system
• verification of work products, any work product: have we created the work product right? Is it defective or otherwise?
• validation, again of a work product, any work product, requirements, design, subsystem, system: have we satisfied the need with our work product? Have we done the right job? Have we created the right work product? And then lastly:
• systems engineering management. The practice of managing the engineering where a systems approach is being used, with the usual aspects of managing anything, together with specific concerns, for example, requirements management, interface management, managing design complexity, configuration management, amongst others.
That is the nature of systems engineering, it is not a one size fits all activity.
These process elements are configured selectively, their configuration being driven by the objective of maximizing the value that we deliver from our engineering, on the balance of probabilities to allow for the inevitable uncertainties.
Myth number two:
Systems engineering is for systems engineers. Well yes, but certainly not only for those with “systems engineer” as a job title. When you look at it, the principles and methods of systems engineering have application across the practice of engineering in general. And that means about 15 million engineers in the world are candidate practitioners of systems engineering. To examine that point further, from the table you see reproduced, you will find a list of principles. These are the first five principles from a longer list. The table also shows an assessment of the applicability or otherwise of each principle to the engineering of a number of different types of systems: a large socio-technical system such as the country of Singapore; a complex system such as an aircraft or an air traffic control system; a simple system such as a pen; software, large, small, regardless; and even non-systems, for example, a 50 centavo Brazilian coin, which to my knowledge is simply a material formed into a shape, not constructed of two or more interacting elements. And the conclusion against each of the principles is one of applicability. One would reason and observe that the principles are more important when applied to larger, more complex systems, but that doesn’t mean that they’re not applicable, and do not have application, for engineering of things in general. The evidence in this direction is very strong.
Myth number three:
Process standards are icons of virtue. Well, they can be, but they can also be quite the opposite. The standard of process standards is highly variable. To use an example, ISO/IEC/IEEE 15288:2015, the current ISO systems engineering standard, I would describe as disappointing, and, well, certainly better than nothing, but not a great deal better. The table in the background is an extract of a 25-page publication by PPI, being an application guide to that standard, with the issues outlined and work-arounds, where appropriate, spelled out. The issues range from profound through to quite trivial and there are many of them.
Myth number four:
MBSE is SysML. Well, certainly SysML is a language used in Model-Based Systems Engineering, but there are many other languages and there are many methods of systems engineering that don’t involve SysML. There are techniques such as Object Process Methodology OPM, creating Object Process Diagrams used in OPM, developed by one very smart gentleman Dov Dori, and so significant that it has to become an ISO standard. Many very sound proprietary languages are used with proprietary tools like Core, Genesis, Cradle, Insolate, amongst others. System dynamics is very, very significant, very widely used for simulations, such as for COVID. Even basic mathematics constitutes a powerful modeling language. The Rand Corporation paper that first used the term Model-Based Systems Engineering, I believe, used mathematics as the instantiation of MBSE. So, there is a lot to Model-Based Systems Engineering that is not SysML.
Myth number five:
Functional design precedes physical design. No! Or, if it does, then we will just go around in circles and end up back at requirements, or engage in an exercise in fantasy, or have an unstated, unshared physical concept in mind, with all the risk associated with unstated assumptions. Functional design is intimately related to physical design, certainly not independent of it, and certainly does not precede it. As illustrated by the diagram, for a domestic intrusion detection system, we see a system breakdown structure top right-hand corner, and then some functional design to meet a couple of the requirements. Solution-level functions are shown in black. Functions like detect smell, prepare food, fix dog, and bark, all reflect the physical concept. The two forms of design are intimately related (only fragments of logic can exist in isolation, certainly not a complete logical design!) The sequence is actually physical concept, formalized logical design with iteration between logical and physical as we get physical right, adding detail, adding things we’ve missed, and correcting things. We complete the relationship by formalizing the implementation of the functional logic in all detail in the physical design.
Myth number six:
Work breakdown structure is breakdown of work. Well, no. It’s a breakdown of a project into product and service elements if it’s to be valuable to us. If we make it just a breakdown of work, we lose most of that value. Again, an illustration. The preparation of a WBS, or PBS Project Breakdown Structure as I like to call it, is again based on a set of principles and a set of rules with which to implement these principles. When we apply these principles and rules, we get a structure that is a framework for costing, for scheduling, for risk analysis, for measurement, for assignment of responsibility, for reporting, for definition by way of requirement specifications on deliverable and internal products and services, and a framework for organizational design, all of which are illustrated in various ways on the diagram that you see. If a breakdown of structure is just a breakdown of work almost all benefits are lost, and the others are compromised.
I hope you found this short session interesting. If you’d like to continue the conversation, then don’t hesitate to look me up on LinkedIn. If you or your organization would benefit from training or consulting in systems engineering, then we would love to help. Contact details and links to many free resources follow. Thank you for your interest.
Helping projects succeed …
http://www.ppi-int.com
PPI Free Resources
- Key downloads: https://www.ppi-int.com/keydownloads/
- Conferences: https://www.ppi-int.com/resources/conferences-and-meetings/
- Systems Engineering Goldmine: https://www.ppi-int.com/se-goldmine/
- PPI SyEN Newsjournal (a substantial monthly SE publication): https://www.ppi-int.com/systems-engineering-newsjournal/
- SE FAQ: https://www.ppi-int.com/resources/systems-engineering-faq/
- Systems Engineering Tools Database (V0.98): https://www.systemsengineeringtools.com
- Training Course List: https://www.ppi-int.com/course-schedule/
