Figure 1: The Modules of the H·I·T·S Engineering Training Curriculum.
Systems engineering may be taught as a collection of processes, methods, and sometimes even instructions how to utilise particular systems engineering tools. Trainings on systems thinking follow an opposite approach focussing on holistic views establishing a rudimentary philosophy of systems engineering. Unfortunately, the ends from both sides rarely match convincingly. Systems thinking provides no reliable framework for forecasting why some proposed processes and methods work in a particular context, and why they fail in another setting. Advocates of particular systems engineering processes, methods and tools tend to overemphasise the actual capabilities. Sometimes they make even unwarranted promises beyond the scope of the particular process or method.
The H·I·T·S Engineering Training Curriculum is different. It follows the saying of Immanuel Kant, Kurt Levin and others: There is nothing more practical than a good theory. And even more: Nothing is worse than taking an inappropriate theory for guidance. Theory in this sense means a network of causal dependencies serving as a framework for providing behavioural guidance to individuals and social groups how to cope with reality. A theory like that comprises more than what may be expressed by a single sequential narrative. A good theory supports not only an analysis of the past, but allows the generation of valid forecasts regarding an open future.
A good theory of systems engineering finds its grounding in the theme: Systems from humans for humans. Accordingly, all the social interactions of individuals within teams, of teams within enterprises, and of enterprises within a more and more global economy have their impact on systems engineering. They influence setting goals on a system, providing the appropriate resources, and taking the technical and societal risks for establishing, utilising, and coping with the remnants of innovative products and services. In addition to people, the theme above refers to systems as the target of systems engineering. The general nature of systems itself is a result of how humans anticipate the world. The concept of systems having a life cycle is a unique and innovative contribution of systems engineering to the understanding of systems.
Performing systems engineering means the generation of system concepts and system development. A regular theory of systems engineering provides comprehensive guidance on what has to be done when, and on the alternatives how individual systems engineering tasks may be accomplished. In addition, a good theory of systems engineering allows to consider the actual system and organisational context adequately, leading to more effective, more efficient, and more successful systems.
The H·I·T·S Engineering Training Curriculum provides a comprehensive systems engineering training fostering a good theory of systems engineering. The H·I·T·S Engineering Training Curriculum is designed in order to accomplish the following two goals:
As shown in Figure 1 above, the curriculum features three consecutive training modules:
Of course, training attendees should pass through the full H·I·T·S Engineering Training Curriculum in order to match both goals. In case of less demanding professional needs, you may prefer to attend consecutive training modules later, or not at all. The H·I·T·S Engineering Training Curriculum is designed accordingly. Training Module 1 concentrates on the first goal. It considers the complete systems engineering perimeter. Training Module 2 and Training Module 3 add further theoretical detail, and pave the way from the theory of systems engineering to the practice of systems engineering. Please, be aware, the attendance of Training Module 2 and Training Module 3 is possible only after attending the preceding training module before.
The sections below describe the content of each training module in further detail. The description of the Training Module always start with a table of content followed by a more elaborated discussion including the rationale for scoping the content. The tables of content are high-lighted by placing them in separate, coloured bounding boxes. All this information may aid your decision which training modules may serve your current or future interests and needs. The page on the intended audience provides further orientation. If you are just interested in a brief overview about the curriculum content, please refer to the H·I·T·S Engineering Training Flyer.
Systems engineering is a highly sophisticated social activity. Humans are able to accomplish tasks together with particular contributors even not knowing how other contributors generate their share of the solution. Some researchers argue that this level of common intentionality is a rather new innovation generated by the evolution. They further claim that advanced capabilities for collective intentionality made us humans the dominant species on Earth. The fundamental question is whether this capability that brought ecology out of balance is sufficient for recovering states that keep the Earth as a suitable living space, or not. However, what would be the alternatives from a human point of view?
Systems engineering did not evolve with these global issues in mind. But systems engineering pioneered processes, methods, and techniques how to utilise the advanced capabilities of common intentionality for the generation of complex and innovative products and services. The knowledge and experience gained with stakeholder orientation and multi-disciplinary engineering are assets of general importance.
However, evolution is as even a harmonic and symbiotic as a competitive and dissonant game. Humans inherit traits counteracting the activation of the potential arising from advanced capabilities of common intentionality. This leads to some confusion with a touch of fuzziness restricting a straightforward understanding of human attitudes and behaviours. Experienced systems engineers have learned to cope with challenging circumstances during long years of experience. When recording this experience, the impact on others is limited in two ways.
First, they report about tacit knowledge. They face the challenge to generate rationales about widely unconsciously perceived real-world patterns. Unfortunately, they refer to the knowledge gained by social sciences frequently, usually without diving deeply into the social sciences themselves. Without that, their findings take the character of sets of golden rules. The rudimentary semantics of golden rules do not lead to compelling narratives. Their convincing power is limited in general, and in especially regarding the intended audience.
This leads us seamlessly to the second challenge. Most practicing systems engineers are educated basically in engineering or natural sciences without learning about philosophy of science explicitly. But they adopt implicitly a rather simplified philosophy of science with the main ingredients positivism and reductionism. Many golden rules they hear from the systems engineering experts do not match with their basic believes. Due to the lacking convincing power of the rationales, they widely ignore those golden rules until they learn them again tacitly over long years of experience.
The H·I·T·S Engineering Training Curriculum is intended to break with this cycle. Previous generations of systems engineers grew their systems engineering knowledge and their skills to contribute to multi-disciplinary engineering teams in parallel to the increasing complexity of the systems they worked on. Newer generations of systems engineers are faced with the complexity of today’s systems and the demands for multi-disciplinary engineering from the onset of their professional careers. It would be inefficient and irresponsible to demand from systems engineers today to follow the same professional development path as previous generations of systems engineers did in the past.
Before we turn in more detail to the content of Training Module 1 of the H·I·T·S Engineering Training Curriculum, another traditional approach to cope with the human side of systems engineering needs some attention. In its extreme manifestation, this solution is rather simple and strict: Just try to ignore the human side. Most systems we deal with exploit physical natural laws. Systems engineering may be anticipated as a system by itself. As a system, systems engineering at its best should follow some sort of natural laws close to physical natural laws. Apologies apply that we are not there yet, but the advances in information technology will take us there in due time. In the past, it was hoped that salvation would come from requirements management. Today, model-based systems engineering is in focus. More and more, big data is claimed to bring the final relief.
Of course, the paragraph above exaggerates and simplifies what contains in fact the major portion of the impressive body of knowledge in systems engineering. But without a solid grounding within the social field, systems engineering debates run astray. Required are convincing forecasting capabilities for which processes, methods, and techniques excel in certain circumstances, and may fail under other conditions. Without that, frustration about actual misachievements let people not rarely bail out from systems engineering following even less substantiated and less comprehensive theories and their prophets.
Note, less knowledge about a field coincides with the tendency to see it simpler and in a more trivialised way because we lack the language capabilities for expressing the richness of detail, and the sophistication of distinctions in the particular field. Without being conscious about this principle limitation, we tend to trivialise reality beyond our own scope of knowledge and experience.
Systems engineering evolved around the system life cycle as the main narrative. Comprehensive textbooks exist trying to explain all facets of systems engineering following this single narrative. They provide impressive evidence of the mastery of their authors. On the other hand, they face two corresponding challenges. Where the narration is stringent, they miss essential distinctions and advices because important side stories are dropped. The brief and insufficient considerations on system interface engineering in almost all systems engineering textbooks provide ample evidence for such gaps. Where the authors strive for completeness, the number of side stories and repetitions adversely impact the convincing power of essential concepts and dependencies. The vague understanding of the essential role of system requirements in the advent of model-based systems engineering may serve as an illustrative example here. That system requirements express the commitments with respect to stakeholder satisfaction, liability, safety, and so forth, and that they are designated as the basis for a requirement-based demonstration of compliance, seems not really to be a commonplace insight all systems engineers are fully aware of today.
Further distortions were introduced when the system life cycle was not modelled anymore as a pure waterfall, and when incremental and evolutionary system development models were introduced for better coping with continuous improvement cycles in real-world scenarios. Unfortunately, system life cycle considerations became more and more development centric. The V-model introduced by Kevin Forsberg and others is over-interpreted many times as a system life cycle model albeit the rationale behind its shape emphasises the development of hierarchically organised system architectures.
From these findings, it becomes evident that teaching systems engineering following a single narrative may not be the most efficient and elegant didactic approach to provide comprehensive insight into the systems engineering domain. As any field of knowledge, systems engineering contains some major concepts and manifold single-sided and mutual dependencies between these concepts. Usually, the complexity applying systems engineering to a particular system exceeds the complexity of the system itself by far.
Narratives consist just of sequences following a “then … and then … and then …” pattern. Sociologists and psychologists discovered that a more causal meaning of the “and then” connectors are better memorised than pure time sequences. In the brain, the hippocampus plays an essential role in building up long term memory. Long term memory consists of episodic and semantic memories stored in separate regions of the cerebral cortex. While episodic memories tend to fade over time, semantic memories are more stable. The link to Daniel Kahnemann’s fast thinking model seems to be that our holistic situational awareness is fed primarily from semantic memories acquired consciously, or tacitly. Unfortunately, no final proof exists for this link so far. The social sciences are at least as fragmented and stove-piped as the numerous disciplines in the natural sciences and engineering.
What are now the basic narratives in systems engineering to start from for building up comprehensive systems engineering knowledge over time? Narrative by narrative, their causation needs to be convincing for the intended audience. Together, they have to cover the whole domain comprehensively. Basic dependencies between them should become clear. With further experience, the narratives become enriched further, and more intricate dependencies between them are discovered without the need to withdraw knowledge acquired previously.
My response to this question has evolved over decades of practice, especially with recovering sophisticated and challenging projects in trouble. I rarely found the receipts from the management and systems engineering literature really helpful in the actual situations. Not that I have not learnt a lot from these studies, but I have not gained much support when it came to the single question that really mattered always: Why do teams of individuals, each of them of impressive personality and with splendid knowledge in her or his particular field of expertise, fail together to accomplish their common goals? And even more bewildering, why my involvement made a difference to let the teams recover to a path of success? Some years ago, admittedly in a rather frustrated mood, I started a journey to refresh my theoretical knowledge about the social and cognitive sciences I had gained earlier during my life. In summary, my consolidated finding is that we lack a good theory of systems engineering, and ‒ even worse ‒ some inadequate theories are recommended for guidance. Furthermore, to improve the theory of systems engineering, and to provide a comprehensive and efficient systems engineering training curriculum, the following three narratives are essential:
In order to let you comprehend my reasoning, the three sub-sections below briefly describe each of the three essential systems engineering narratives, and provide rationales for their scoping. But before a few words on the didactical methods applied during Training Module 1. About two third of the training time in Training Module 1 consists of presentations and corresponding discussions due to the many different concepts to be introduced. The other third is filled with brainstorming sessions, exercises, and open discussions. Exercises are planned for all three essential narratives.
The Problem Processing Cycle focuses on individuals and teams. How do individuals cope with their environment? How do individuals generate common team views? How do they draw consequences from these views, and how do they decide together on further action? The Problem Processing Cycle is rather unspecific about the nature of the problem. A problem may represent an issue of any size. It could be a disagreement between team members about a tiny design feature, but also the system life cycle as a whole may be anticipated as one problem.
Obviously, an isolated single problem is just a theoretical construct. In reality, every problem may be decomposed into more detailed problems and is interlaced with other problems. Implementing solutions to a problem may be simple and informal on one side of the spectrum, or may demand huge investments with a high level of formalisation on the other. For this reason, the Problem Processing Cycle is not depicted in Figure 2 as a complete circle. The implementation of the solution is left out. By performing the Problem Processing Cycle for a particular problem, and especially during implementation of the problem solution, numerous new problems of various size and severity will pop up that are waiting then for being observed and further processed following the same scheme. It would provoke wrong associations to illustrate problem processing as a full circle.
Figure 2: The Problem Processing Cycle.
The Problem Processing Cycle shows five stages from problem finding to selecting a problem solution. Running through the five stages sequentially in the given order is a mandatory prerequisite for effective and efficient problem processing. If a team fails to run the Problem Processing Cycle well synchronised, or if a stage is omitted or just assumed to be accomplished, irritations among team members and immature decisions are likely.
Leaving the nature of the problem out of scope, it is clear that this narrative is centred on what is happening in the social field consisting of the individuals forming the team. The external influences on particular team members and on the team as a whole have to be considered as well. It deserves further considerations to identify which knowledge about the social field is important and supportive to systems engineers. Just piling up even more golden rules is no viable solution due to the reasons considered above. Similarly, a profound introduction into all affected social sciences exceeds the needs of systems engineers, and lies beyond the scope of any professional training. There exist neither blueprints for the intended training curriculum, nor a corresponding equivalence to systems engineering into the social sciences. No other problem regarding the definition of the H·I·T·S Engineering Training Curriculum has challenged me more than this issue. I ended up with a reasonable solution, but you should have the chance to make up your own mind. For this reason, the rationale is summarised below although it takes a fair amount of text to do so.
Organisational psychologists performed a lot of research to determine human personalities, and to construct successful teams by selecting particular personality types for particular team roles. Guided by well qualified psychologists, it can be an exciting experience to learn more about one’s own personal attitudes and behavioural preferences. Most people like it, and under controlled conditions it may be also a valuable team experience indeed. But in the given context, the search for certain personality types is of lower importance for a number of reasons: the adequacy of the selection scenarios, the inherent limitations of all personality testing methods, and the evidence provided by recent field studies.
Independent from the details of the approach taken, organisational psychologists agree on that diversity in teams, e.g. a mix of various personality types, is commonly an important success factor compared to rather homogeneous teams. In systems engineering teams, diversity is not only brought in from differences in personality, but also from the different views of the engineering disciplines involved. Furthermore, engineering expertise in particular domains is not a resource available for free and in unlimited quantity. Usually, the group of candidates you may choose from is rather small. Many times there may be no choice at all. Thus, you have to live with the people that are available, and you have to value them.
Second, the method of personality testing inherits a number of general limitations. Whether introspection, multiple-choice questionnaires, or a variety of specialist interview techniques are applied, the common denominator are archetypical narratives for characterising people. These narratives inherit cultural dependencies with respect to the evaluation axes. Questionnaires are based on typical everyday-life scenarios that are not fully comparable between different social communities. There are no particular personality tests tailored for international systems engineering team scenarios.
Furthermore, team members become labelled and categorised. Independent from the classification scheme, the number of personality categories will always be limited compared to the variety of individual human characters. A risk of promoting prejudices exists, instead of enriching the personal interaction within a team, and instead of increasing team performance. The validity of a particular personality test is based on statistics. If a high portion of a population is well described by the stereotypes offered by the categorisation scheme, the categorisation scheme and the corresponding questionnaires are deemed to be valid. When it comes to innovation, curious individuals capable of divergent thinking are commonly asked for, but these rather rare people may not match any of the offered stereotypes satisfactorily.
My personal experience with the Myers-Briggs Type Indicator Assessment may illustrate the issues. It is the only personality type test I have passed several times during my life so far. Its origin goes back to the research of C. G. Jung with the primary focus on extroversion and introversion. On this basis, Katherine C. Briggs and her daughter, Isabel Briggs Myers, developed their tool. In the basic version, four so called dichotomies generate bipolar axes leading to sixteen possible stereotypes. Since 1943, a lot of experience has been gained with this tool as it is widely in use. It has evolved further, and the questionnaires have been updated several times and validated against the US population. Whenever I have got the test results and read the corresponding descriptions, my first reaction was: That is not me! Of course, a lot fit to my person, but there were some statements where I think and act more the opposite way.
When I was invited the last time to a personal development training with a Myers-Briggs Type Indicator Assessment included, I was less than excited. But that time, the test was performed on a secondary level, and the results were really informative to me. Over time, each of the four dichotomies were amended by five facets that resemble the bipolar axes, but add a mid-zone rating in addition. From the twenty facets, I hit this mid-zone rating nine times. This could either mean that I am totally ignorant about these axes, or that I adopt my behaviour in these axes well in response to the actual situation. From the other eleven facets, I was six times in compliance with the primary rating. For five facets, the rating was opposite to the primary rating. For ten facets, my scores did not fall in the one-sigma standard deviation range typical for my primary type. In conclusion, I understand now better why many people judge me as a rather challenging character because they have to spend a lot of attention when dealing with me. You may conclude from this example to prefer the Step II testing, if you ever apply for a Myers-Briggs Type Indicator Assessment.
Third, recent field research performed by Julia Rozovsky at Google led to the conclusion: "Who is on a team matters less than how the team members interact, structure their work, and view their contributions." Initially, Google's human resource department was rather confident to create successful teams on the basis of the personality and professional characteristics of team member candidates. As we all know, Google is quite good in statistical analysis of big data samples. Thus, their results deserve some trust: No significant correlations between personality types and team role assignments with project success were found. They instead identified "five key dynamics that set successful teams apart from other teams at Google". All five items are directly associated with what is actually happening in the social field.
The whole story may be anticipated as a reasonable example for the limitations of reductionist world views. A prominent research agenda of high reputation followed over decades with huge resource investments loses its foundation. Some people may see it as a defeat, but it is opening up opportunities by accepting an open future less predetermined by initial conditions stemming from the past as some may have thought. This also adds further credibility to the work of people like Taiichi Ohno, or W. Edwards Deming who made essential contributions to the optimisation of organisational performance without relying on prejudices about individuals.
Nevertheless, this does not mean that the individual team members would not matter. A closer look at the five identified key dynamics reveals just the opposite:
All five topics express a team member perspective. It is important how team members assess their experiences within the team and the subject they are working on. The team members are the relevant observers. Humans are not the direct and simple measurement devices of reality as positivists would prefer. If positivists would be right, it would be sufficient to provide team members with comprehensive project and process descriptions, and to let them sign a commitment sheet to respond yes to the five questions above, perhaps after some social team building exercise. In too many occasions, I have experienced this initial approach leading to crisis and mishaps during project execution later.
Studying the common characteristics of team members as human observers opens a door to better predict and control project performance. We have to look for appropriate psychological models describing human attitudes and behaviours in the social field. The identified five key dynamics provide essential hints. Successful teams manage to stay theme-centred. Furthermore, every team member gets adequate satisfaction regarding the relevant motivational systems: belongingness, meaning, and self-control. The individual needs regarding each motivational system vary between team members. The same is true regarding the individual capabilities to stay theme-centred and to contribute to the subject. For being successful, teams have to find an appropriate balance within the social field.
Before we return to the content of the problem processing narrative eventually, the question why ordinary team members should be aware about the forces and mechanics in the social field deserves a response. To start with an example, let us talk about the weather. We talk about the weather quite frequently, for example when we make long distance calls to close friends and relatives, or when we become introduced to new people. Have you ever asked yourself why weather is such a prominent small talk subject?
A traditional experiment in social psychology, performed by Norbert Schwarz and Gerald L. Clore in the eighties of the last century, provides the answer. The weather has a significant impact on the basic mood of many people. When talking about the weather, people become aware about this impact on their current feelings. Surprisingly, the awareness does not increase the mood impact on interpersonal communication, but leads to a discount: “Yes, the weather is not so nice today, but in general …” Usually, the weather dependent mood impact on the conversation is well compensated after talking about the weather.
Generally, we cope with a situation more adequately, if we understand it better from multiple perspectives. At best, we achieve protection within a team from developing rather trivial views and blaming others, especially when project life becomes tough. In the end, team members feel better valued due to the experience to be an appreciated member of the team because they just are who they are. That is the reason why knowledge about what drives the social field should not be anticipated as an exquisite tool for leaders to execute dominant power on subordinates. This knowledge should be well distributed within a team instead.
When discussing the Problem Processing Cycle during the training, a wide range of topics from psychology, sociology, neuroscience, and philosophy are captured. This includes motivation, creativity, and professional believes as psychological characteristics of individuals. Perception, attention, appropriate situational awareness, and adequate action are explained with support from the neuro sciences. For capturing the overall social field, narration theory, group dynamics, and theme-centred interaction are considered. However, not all problem processing topics have their origin in the social sciences. When it comes to problem scoping, or selecting a solution, rational decision making on the basis of appropriate evaluation schemes is an important topic.
The Systems Engineering Value Stream is the central narrative of systems engineering as it considers what systems engineers do and how they may do it. The Systems Engineering Value Stream is applied for generating system concepts and developing systems. The Systems Engineering Value Stream is not fully covered by Training Module 1. In Training Module 1, the Overall Systems Engineering Value Stream gets all the attention. The major icon of the Overall Systems Engineering Value Stream is the V as shown by Figure 3.
Figure 3: The Overall Systems Engineering Value Stream.
The V is well suited to introduce major systems engineering principles, concepts, and processes. All explanations are provided to a depth allowing the illustration of the major interferences with the other two essential narratives. Training Module 2 and Training Module 3 provide further details about the systems engineering value stream in theory and practice.
The V concentrates on the systems engineering activities that are coordinated and controlled by a single authority. Therefore, the focus is set on several systems engineering teams interacting within an enterprise. In some cases, control may be partly extended beyond the boundaries of a single enterprise, and may include partner companies, or parts of the supply chain. But usually, the other enterprises have the ultimate managerial responsibility for their products and services.
The vertical axis of the V expresses the system architecture. At the top, the system environment is depicted in which the Overall System on the next lower level provides its operational benefits. The Overall System represents the product or service sold by the enterprise. Depending on various criteria the Overall System is decomposed recursively into elements that are subsumed themselves as systems again. They are identified as Abstract Systems as they may either have a unique physical representation, or not. The architectural layer at the bottom comprises all System Elements on the Implementation Level. These systems are procured from other enterprises. They also mask the supply chains behind them. It would be inappropriate to assume that the V is capable to map all supply chains at once. Economies are networks of enterprises with manifold relations and dependencies. The V is just a hierarchical expression of a tiny part centred on a particular product or service provided by a single enterprise.
The horizontal axis represents a logical sequence, not the timeline. If problems are found, and their causes have been identified, the horizontal axis shows how far to the left the Overall Systems Engineering Value Stream has to be re-entered again in order to cure the problem. If you are interested to read more about this interpretation of the V as a value stream in a strict sense, please, consult the paper V-Model Views co-authored by Kevin Forsberg, one of the inventors of the V as essential icon of system engineering. The content of that paper is rather close to the topics addressed by Training Module 1.
The System Life Cycle is a partial view on an economy. It extracts all economic activities around a particular product or service. The economic players are enterprises and consumers acting within a framework of laws, regulations, and cultural habits. Consequently, the narrative on the System Life Cycle describes another layer than the Systems Engineering Value Stream that is concerned with the interaction of teams within an enterprise. This narrative is concerned with how enterprises interact with a product or service over its system life cycle.
Figure 4: The System Life Cycle.
As shown in Figure 4, every technical system has one associated producing enterprise. Usually, the producer is also developing the system. However, legally responsible is the producer due to European law. For products imported from outside the EU, the trading company marketing the product in the EU becomes liable. For particular application domains, regulations demand appropriate process quality during development resulting in additional obligations and liabilities of development authorities. Producers are liable for the intended and foreseeable uses of their products in the boundaries of risks not accepted by society. Regarding services, the European legislation is a bit more relaxed, and delegates more responsibility and liability to the users.
Instead of viewing the economy from the perspective of relations between enterprises, we may change the primary focus to the interactions of systems that are produced by the enterprises involved. The system life cycle of a technical system may than be interpreted also as the interaction of systems in various roles. Some systems become parts of others, some systems are needed for supporting others over its system life cycle, and some systems rely on utilising the others. Therefore, the System Life Cycle is as well suited for considerations on enterprises as for considerations on interacting systems.
Originally, systems engineering has evolved in public procurement programmes for armament and nuclear technology. For the particular purposes, a bunch of important innovations regarding basic and application specific technologies had to be mastered. Central control and coordination were required to succeed. Eventually, governments respectively tax payers had to pay for all costs from system conception to retirement. Considerations on system life cycle costs and system life cycle efficiency were fostered. Here, system life cycle efficiency is defined as the ratio of system benefits to system life cycle costs. Successful systems show a system life cycle efficiency significantly greater than one.
This context has led to some neglection of the wider economic environment. The success of systems does not only depend on what can be controlled centrally. In order to sustain a system over its intended life cycle, it needs support from the wider economic environment. We have to keep in mind that systems engineering evolved and prospered in market economies based on the principles specialisation, workshare, and standardisation. Market opportunistic behaviour distinguishes market economies from planned economies. Consequently, a generally applicable systems engineering has to exploit benefits from market opportunistic behaviour. Unfortunately, this adds further complications to systems engineering. How to benefit from existing technologies, products, and services? How to calculate system life cycle efficiency in practice? How to cope in system conception and system development with future changes in the wider economic environment? Some of them may be better predictable than others.
The system life cycle is an inherent feature of every system. The breakdown of the system life cycle into system life cycle phases is not. System life cycle phases help to better structure the interactions of the system with other systems over its life cycle. An appropriate definition of system life cycle phases takes all interactions relevant for the system of interest into account, and groups them according to their mutual impact. As far as systems engineering itself is concerned, a system life cycle phase model is likely to define two distinct phases: system concept generation, and system development.
System concept generation is usually embedded in an enterprise’s business planning. System concepts populate an enterprise’s product portfolio strategy. System concepts describe the system environment comprehensively. They outline a principle system solution. They identify all technical and non-technical risks that may hamper to bring the system into being. Mature system concepts define how to cope with all the identified risks. Finally, they define all required technologies. As far as new technologies are concerned, the technology catalogues of all system concepts considered by the product portfolio strategy serve as the basis for an enterprise’s technology roadmap planning. For further information on system concept generation, you may refer to the paper The Role of Systems Engineering in Business Planning available from this website.
System concept generation is a mandatory internal enterprise activity. When needs become wants, and turn into demand later, more massive investments are justified. Leading enterprises are capable to enter system development on the basis of mature system concepts, and to start production and product delivery in due time. Striving for completeness distinguishes system development from system concept generation. The system needs to be completely defined and integrated with evidence supplied by comprehensive validation, verification, and process assurance.
The Systems Engineering Value Stream is at the centre of Training Module 2 and Training Module 3. Training Module 2 is concerned with what systems engineers do and how they may do it. Training Module 3 emphasises the corresponding systems engineering management viewpoint. Both Training Modules are a continuation of the considerations on the Overall Systems Engineering Value Stream as captured by Training Module 1. A lot of detail is amended to the topics addressed already by Training Module 1. Further topics like Work Product Generation Sequences, system interface engineering, and system integrity are added. Links to the other two essential systems engineering narratives ‒ The Problem Processing Cycle and The System Life Cycle ‒ are considered as appropriate in order to provide comprehensive systems engineering scenarios close to real-world conditions.
As the title Systems Engineering Value Stream suggests, the H·I·T·S Engineering Training Curriculum considers systems engineering strictly flow oriented. No other approach for modelling the systems engineering process is better suited to avoid circular dependencies and other blockages in process execution. If all systems engineering activities are adequately captured by the value stream description, ad-hoc work-arounds to overcome process definition shortfalls are avoided. The opportunity for optimum process quality is at its maximum since the likelihood to match the actual process with the defined process is high.
A well-defined value stream is also required in order to allow controlled iterations. In systems engineering, iterations are caused by the need to incorporate lessons learnt during current activities into previous results taken as input. Iterations are common, independent from the chosen development philosophy. In a waterfall model, all iterations following the first one deal with the incorporation of lessons learnt. In an incremental development approach, iterations consist of additional functionality, and corrective actions from lessons learnt. And in an evolutionary development philosophy, iterations contain improvements of existing functionalities, new functionality, and corrective actions from lessons learnt. Which development philosophy is the best choice in a particular scenario may vary, but success is always depending from a workable systems engineering value stream.
A well-documented and well-communicated systems engineering value stream establishes a solid foundation to provide satisfactory orientation to all people involved regarding their work. It is a valuable asset to enhance systems engineering management. The high likelihood that actual process and defined process match eliminates uncertainty with respect to all management tasks. Planning is more reliable. All status accounting, especially the exploitation of distantly linked information, is more trustworthy. In project coordination and control, decisions are better substantiated, and they more likely result in the intended effects.
If all the above about the advantages of strict flow orientation in systems engineering sounds too enthusiastically to your mind, please, consider the following in addition. When high-qualified production workers were taught and advised in their production value streams, a boost in quality, performance, and flexibility was the result. This started early at Toyota following the ideas and concepts of Taiichi Ohno, and gained momentum in the western hemisphere late in the eighties of the last century when the MIT propagated their lean approach. The MIT derived their theory mainly on the Toyota experience, but failed to leave the barriers from reductionist and positivistic thinking behind as far as it would have been necessary. Thus, it took nearly further twenty years before the MIT became aware about the important role of people, their attitudes, and their minds. Why should high-qualified engineers not write a similar success story when going strictly flow-oriented?
Throughout my professional life, I have been driven by the question why something works, and other things do not. When it comes to multi-disciplinary engineering, I found it rarely satisfying just to identify a single root cause of a problem, fix it, and to blame the particular discipline or a few people involved for the mishap. Even if such findings are well substantiated for the particular case, is this just an exceptional case, or are there technological boundaries, some flaws in the process or missing competence within the team that may let evolve similar scenarios again and again? As an auditor of many engineering projects, I had to examine the process definitions. Instead of then just looking for the deviations of the actual process from the defined process, I ended up regularly up with the question: When they follow this defined process, why have they achieved what they have achieved so far? I observed too many omissions, underrated process challenges, and conflicting process requirements.
This started my own journey to become more and more convinced about the advantages of strict flow orientation. Thus, I have fostered strict value stream thinking in all projects I have been involved in. When I became responsible for a development project by myself, I first applied strict value stream thinking on this small-scale project successfully. The paper A Standardisation Concept for Non-Standard Development Projects co-authored with my former colleague Andrea Schindler provides a status record when we started to transform an engineering project run by a team of more than hundred members. This became a full success as reported in the paper Managing Concurrency in Systems Engineering. My route to strict value stream thinking is characterised by a mix of learning by doing, and of consulting the corresponding literature. There are rich sources backing my preference for strict flow orientation. If I would be asked for introductory books that may have an impressive and convincing impact on a less convinced reader, I would end up with recommending the following three books:
The purpose of the systems engineering value stream is to provide teams within an enterprise, and individuals within teams with a common workable process model. The systems engineering value stream is less focussed on how particular disciplines and individual engineers have to do their work. Primarily, it provides a view how all development activities work and fit together. For maintaining the right level of detail, it is favourable to align the systems engineering value stream with configuration management. Configuration management is mainly concerned with establishing and maintaining configuration baselines. Configuration baselines are always related to a particular system. They comprise the information required for downstream activities. Following the value paradigm, they satisfy the conditions for modelling the information flow between the systems within a system architecture, see Figure 5.
Figure 5: Configuration Baselines in the Overall Systems Engineering Value Stream.
The quality of a system coincides with the quality of its corresponding configuration baselines. It is easily comprehensible that high-quality configuration baselines are fundamental for efficient collaboration between all the engineering teams in charge of the systems and system elements within a system architecture. In order to ensure high-quality configuration baselines, a value stream based approach is applied again. In the nomenclature that has emerged over time, such value streams are called Work Product Generation Sequences. Work Products contain the actual information that is needed by downstream activities. Configuration baselines refer to them. The paper Systems Engineering Value Stream Modelling describes how to construct and describe a Work Product Generation Sequence. It also compares a value stream based approach with document-centred and process-oriented approaches in order to substantiate the advantages of strict flow orientation.
Training Module 2 is designed as a continuous systems engineering programme capturing System Concept Generation as well as System Development. An exemplary system architecture with a System Environment, a Product or Service, and at least two Abstract Systems on the architectural layer below the Product/Service layer is established in order to capture the flow of configuration baselines, the refinement of interface requirements, and change control propagation within the system architecture. Generic Work Product Generation Sequences are defined for the various architectural system layers. This set-up will be explained before commencing work on the systems engineering programme exercise.
The basic problem will be selected following the preferences of the training attendees of the particular training course. At its best, working on the problem will be a creative experience for the training attendees as well as for the trainer. However, some general selection criteria apply for enabling a vivid and convincing systems engineering experience:
As in practice, the whole exercise starts in the first stage with the generation of a system concept including the analysis of the system environment, the setting of goals to be achieved with respect to the system environment, and the definition of a preferred technical solution. In the course of System Concept Generation, Stakeholder Requirement Definition and Stakeholder Requirement Validation are discussed exhaustively. As far as System Requirement Definition and System Design are concerned, the specific characteristics of this development sub-process during system concept generation are discussed. Equivalently, the considerations on System Design Validation are adopted to System Concept Generation. The system concept will be matured progressively by running multiple iterations. At the end of system concept generation, a life cycle phase review concludes this first stage of the exercise.
Although the engineering goals differ between system concept generation and system development, the systems engineering process follows the same general outline as expressed by Figure 6. Figure 6 shows the Overall Systems Engineering Value Stream with the indication of the four development sub-processes. These sub-processes are chosen in order to satisfy strict flow orientation. Compared with the process breakdown within ISO 15288:2015, two major differences occur. What is subsumed as a single System Requirement Definition and System Design Process is captured within ISO 15288:2015 by several distinct processes. The second difference is the establishment of a System Integration Preparation Process that joins all activities connecting the left leg of the V with the right leg of the V for each particular system or system element. The activities subsumed by the System Integration Preparation Process are distributed over several sub-processes in ISO 15288:2015. However, the ISO standard captures these activities with a marginal level of detail only. Their importance for efficiency in system engineering justifies a more prominent treatment here.
Figure 6: Development Sub-Processes.
The second stage of the exercise is mainly concerned with the System Requirement Definition and System Design Process applied to all systems within the system architecture. The corresponding assurance sub-processes ‒ Allocated Requirement Validation, and System Design Validation ‒ are captured in accordance with the system development flow. As far as necessary further stakeholder requirements will be elicited. Although System Development demands a complete system design, the exercise will be more selective in favour of covering all essential systems engineering process issues, and of executing multiple iterations over the systems engineering value stream.
The third stage sets the focus on System Integration Preparation and System Integration. Virtual system integration allowing Virtual System Validation, and Verification demonstrating compliance of the real integrated system with system requirements are considered. Considerations on Operational Validation, e.g. operating the product or service in the real system environment, concludes the system development activities. Again, the execution of iterations is part of the exercise. This may lead to a re-entry into the sub-processes Stakeholder Requirement Definition, and System Requirement Definition and System Design.
Throughout the exercise, process objectives for all the development and assurance sub-processes are introduced and set into context. All system development data generated by the training participants are recorded. The system development data is kept retrievable providing traceability of system evolution with all the iterations performed.
At the end of Training Module 2, training attendees should be capable to perform all systems engineering development and assurance activities in a consistent manner. Furthermore, they should have experienced the advantages of strictly controlling the flow by performing multiple iterations with the evolution of all engineering data becoming fully traceable.
Training Module 3 continues seamlessly where Training Module 2 has stopped. After being capable to perform all systems engineering development and assurance activities, Training Module 3 starts with a view behind the scenes how the engineering data are recorded and controlled. The considerations on Configuration and Data Management unfolds the data structures utilised throughout Training Module 2, and extends the data model for capturing systems engineering management data associated with the systems engineering management processes introduced by Training Module 3.
The further systems engineering management processes are aligned with the time sequence they need to be performed. Consequently, Programme and Project Set-Up marks the entry into systems engineering management. Project Execution comprises the internal day-by-day project planning, recording and controlling activities. Risk Management has also to be performed continuously during project execution oriented outbound towards the enterprise environment. Project Closure is concerned with concluding the systems engineering activities, releasing resources, and handing over the system including all the information required by downstream system life cycle processes to the appropriate stakeholders.
At the end of Training Module 3, training attendees should be capable to set-up, run, and conclude systems engineering programmes and projects in accordance with a strictly value stream based approach. However, the successful transition from theory into practice is also depending from the organisational environment as well as the knowledge and attitude of all other people involved. It would be presumptuous to expect from a single trained person alone a rapid conversion of an engineering team or an engineering organisation to adopt a strictly value stream based approach successfully. Spreading the knowledge and setting up appropriate systems engineering environments demand concerted actions within an engineering organisation.