In This Edition
1. Quotations to Open On
2. Feature Articles
2.1 Using Systems Thinking to Avoid Systems Engineering Failures by Thomas F. Gannon and Jamie
P. Monat
2.2 Becoming a Systems Engineer by Art Pyster
3. Additional Article
3.1 Integrating Program Management and Systems Engineering by Martin Griffin
4. Systems Engineering News
4.1 INCOSE 2018 Election Results
4.2 INCOSE Conducting 4th Study On the Current State of MBSE Adoption
4.3 7 Habits of Highly Effective NASA Systems Engineers
4.4 Pohl Inducted as Fellow of Engineering Management Society
4.5 Cyber Education Must Address Systems Engineering
4.6 Object Management Group Issues Request for Proposals for CubeSat System Reference Model
5. Featured Organizations
5.1 Systems Engineering Group – National Institute of Standards and Technology, (NIST) USA
5.2 System Dynamics Society Launches Autumn Issue of e-Newsletter
5.3 Body of Knowledge and Curriculum to Advance Systems Engineering
5.4 ABET
6. News on Software Tools Supporting Systems Engineering
6.1 Cradle 7.4.1
7. Systems Engineering Publications
7.1 The Paradoxical Mindset of Systems Engineers: Uncommon Minds, Skills, and Careers
7.2 Career Architect Development Planner, 5th edition
7.3 Systems Research and Behavioral Science
7.4 Extreme Teaming
7.5 The Design and Engineering of Curiosity: How the Mars Rover Performs its Job
7.6 International Space Station: Architecture Beyond Earth
7.7 Discover Quality Requirements with the Mini-QAW
7.8 Requirements for Devices Around Us: Embedded Systems and the Internet of Things
7.9 Guidelines for Drawing Causal Loop Diagrams
8. Education and Academia
8.1 Online Engineering Programs at Pennsylvania State University USA
8.2 The Dassault Systèmes U.S. Foundation Expands Grant to Base 11 Autonomous Systems Engineering Academy
8.3 Stevens Institute of Technology: School of Systems and Enterprises
8.4 UVA Engineering Launches Department of Engineering Systems and Environment
8.5 Tufts to Offer Master’s Degree in Sustainability
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
10.1 Object Management Group Chairs Report on Future Standards Initiatives
11. A Definition to Close On
11.1 System Concept Diagrams
12. Conferences and Meetings
13. PPI and CTI News
Read More…
14. PPI and CTI Events
15. Upcoming PPI Participation in Professional Conferences
1. Quotations to Open On
“First principles, then processes, then software tools.”
Robert John Halligan
“For every complex problem, there is a solution that is clear, simple, and wrong.”
H. L. Mencken
“Teamwork makes the dream work.”
John C. Maxwell
2. Feature Articles
2.1 Using Systems Thinking to Avoid Systems Engineering Failures
by
Thomas F. Gannon[1]
Email: tgannon@wpi.edu
and
Jamie P. Monat
Email: jmonat@wpi.edu
Systems Engineering Program
Worcester Polytechnic Institute
Worcester, MA USA
Copyright © 2018 by Thomas F. Gannon and Jamie P. Monat. All rights reserved.
Abstract
Systems Thinking and Systems Engineering are synergistic, and applying Systems Thinking principles in the engineering and design of complex systems can result in superior systems, products, and designs. However, there is little information available in the literature[2] that describes how to apply Systems Thinking principles to that end. The authors analyzed 12 major Systems Engineering failures involving bridges, aircraft, submarines, water supplies, automobiles, skyscrapers, and corporations, and identified four common categories of failures due to a lack of Systems Thinking (Monat and Gannon, 2018). This paper provides a summary of that analysis and recommends several Systems Thinking principles, tools, and procedures that should be applied during the initial steps of the System Engineering design process to avoid similar catastrophic Systems Engineering failures in the future.
Introduction
Systems Thinking and Systems Engineering are very complementary, but they are not the same. Monat and Gannon (2015) have characterized Systems Thinking as a perspective, a language, and a set of tools. It is a holistic perspective that acknowledges that the relationships among system components and between the components and the environment are as important as the components themselves in terms of system behavior. It is a language of feedback loops, emergent properties, complexity, hierarchies, self-organization, dynamics, and unintended consequences. Systems Thinking tools include the Iceberg model which postulates that in systems, repeated observable events and patterns are caused by structure, such as stocks, flows, and feedback loops, which, in turn, are caused by underlying forces, such as mental models, gravity, and electromagnetism. Additional Systems Thinking tools include causal loop diagrams, behavior-over-time plots, stock-and-flow diagrams, systemic root cause analysis, dynamic modeling tools, and archetypes. See Monat and Gannon (2015) for a more comprehensive explanation of Systems Thinking.
Systems Engineering is an interdisciplinary approach and a means to enable the development of successful systems. It focuses on defining stakeholder needs and required functionality early in the development cycle, documenting stakeholder requirements, and then proceeding with the design, synthesis, validation, deployment, maintenance, evolution, and eventual disposal of a system. Systems Engineering orchestrates a wide range of engineering disciplines into a team effort, and it uses a structured development process that starts with an initial concept and then proceeds to production, deployment, operation, and maintenance of a system. It takes into account both the business and technical needs of all stakeholders with the goal of providing a quality product that meets the needs of all users. See Kossiakoff et al (2011) for a more comprehensive description of Systems Engineering and the structured processes used by Systems Engineers to develop systems.
Table 1 lists Systems Thinking Principles and indicates the extent to which they are applicable to systems engineering and design. The concepts were identified and described in a recent paper by the authors.[3]
Table 1. Systems Thinking Concepts Applicable to Systems Engineering and Design.
| Systems Thinking Principle | Applicable to Systems Engineering and Design? |
| Holistic Perspective/Proper Definition of System Boundaries | Yes |
| Focus on Relationships | Yes |
| Sensitivity to Feedback | Yes |
| Awareness that Events and Patterns are caused by Underlying Structures and Forces | To a Degree |
| Dynamic Modeling | Sometimes |
| Systemic Root Cause Analysis | Yes, when troubleshooting |
| Sensitivity to Emergent Properties | Yes |
| Sensitivity to Unintended Consequences | Yes |
Systems Thinking and Systems Engineering are related and synergistic, and the application of Systems Thinking Principles to Systems Engineering can result in superior systems. However, there is little information available in the literature that describes how to apply Systems Thinking principles to that end.
To address this need, the authors analyzed 12 major Systems Engineering failures involving bridges, aircraft, submarines, water supplies, automobiles, skyscrapers, and corporations, and identified the following four common categories of failures due to a lack of Systems Thinking (Monat and Gannon, 2018):
- Failure to identify relevant environmental factors such as wind, insolation, rain, and temperature.
- Failure to understand that most complex problems cannot be solved by purely technological means; they often involve organizational, political, economic, environmental, ethical, and sociological components.
- Failure to adequately address both planned and unplanned interactions among the system components themselves and between system components and the environment.
- Failure to recognize that many products are actually components of a User Experience System.[4]
The following sections provide a summary of that analysis and recommendations for several Systems Thinking principles, tools, and procedures that should be applied during the initial steps of the System Engineering design process to avoid similar catastrophic Systems Engineering failures in the future.
Major System Engineering Failures
Many examples of major Systems Engineering failures illustrate the need to apply Systems Thinking principles, which include appropriate “system” definition, system boundaries, identification of all relevant system and environmental components and relationships, and consideration of feedback mechanisms to Systems Engineering and design. The following provide examples of major System Engineering failures for each of four common categories of failures due to a lack of Systems Thinking.
- Failure to identify relevant environmental factors such as wind, insolation, rain, and temperature.
Failure to identify a system’s relevant environmental factors can result in disaster. Three examples of major Systems Engineering failures due to a lack of Systems Thinking in this category include the Vdara Hotel in Las Vegas, 20 Fenchurch Street in London, and Biodegradable German Car Wiring Insulation.
The Vdara Hotel, Las Vegas. Las Vegas’s Vdara hotel was built in 2008 and designed by Rafael Viñoly. The hotel has a curved façade which focuses the sun’s rays on a pool area at its base and heats that area to over 135 °F (Garfield, 2016; Maimon, 2010). Employees and visitors refer to the effect as the “Death Ray.” Although large umbrellas have been placed around the pool area and non-reflective film has been applied to the hotel’s windows, the pool area still gets hot. In fact, the area gets so hot that guests have reported burned skin and singed hair within minutes of lying near the focal point of the rays (Hodge, 2010).
20 Fenchurch Street, London. The building at 20 Fenchurch Street in London’s financial district is 34 stories tall, was also designed by Rafael Viñoly, and was completed in 2014. The highly-reflective upper story windows have a parabolic shape and focus the rays of the sun onto a small area at street level for several hours each day. As a result, storefront temperatures across the street exceed 200 °F. As a result, an automobile was partially melted (Smith-Spark, 2013; BBC, 2013) and a reporter fried an egg on the sidewalk (Raymon, 2013.). The intense heat negatively affected local businesses and the building was nicknamed the “Walkie-Scorchie” (Sherwin, 2013) and the “Fryscraper” (Mississauga.com, 2013) by local residents. A variety of remediation measures, such as louvers, shades and non-reflective glass have been considered.
In both of the above examples, relevant environmental factors, such as the sun and its interaction with other system components, were not considered in the design of the system.
Biodegradable German Car Wiring Insulation. In the early 1990’s, the Green Party in Germany passed a law requiring a certain percentage of the parts in an automobile to be bio-degradable. Bio-degradable wiring insulation was used by Mercedes-Benz to meet those requirements. Unfortunately, over time, bio-degradable wiring exposed to the environment will eventually decompose into a mass of short-circuiting copper wires (Cramer, 2010). In this example, relevant environmental factors including weather were not taken into account.
- Failure to understand that most complex problems cannot be solved by purely technological means; they often involve organizational, political, economic, environmental, ethical, and sociological components.
Two examples of major Systems Engineering failures due to a lack of Systems Thinking in this category include the Water of Ayolé and Stow Center School Aquarium.
The Water of Ayolé. Ayolé is a small rural village in the West African country of Togo. The Amou River was the water source for the village in the 1970’s-1980’s. That river was infested with the guinea worm Dracunculus medinensis, which is a parasite that infects human hosts and causes excruciating pain. The government and international aid organizations dug and installed wells in the village to address this issue. After several years the wells broke down due to normal wear and tear. Unfortunately, no spare parts were available, no technical expertise was available to fix or maintain the pumps, and no money was available to pay for repairs. As a result, the people of Ayolé were forced to use contaminated water from the river. Systems Thinking was subsequently used by local Togolese extension agents to address the broader systemic issues. They trained some of the villagers to maintain and repair the wells, they established a supply chain for parts through the local Togo hardware store, and the women of the village developed an agricultural product production and sales system to generate money to pay for the parts. What was thought to be a simple engineering problem turned out to be an engineering/socio-economic/logistics/psychological problem. In this example, the government engineers assumed that this issue could be solved by purely technical means, when in fact many other factors, such as economics, maintenance, support, people, and psychology also had to be considered.
Stow Center School Aquarium. In 2003, a local university donated a salt-water aquarium to the Stow Center School in Stow, Massachusetts (USA) which included filtration equipment, temperature regulation, and fish. The students enjoyed the aquarium for several years, but the components started to wear out and needed replacement. The aquarium also needed to be cleaned and maintained, and the fish required regular feeding and assessment. Unfortunately, no one was responsible for system maintenance, and the teachers did not feel that maintenance was their responsibility. Eventually, the wonderful, free aquarium was scrapped. Similar to the Water of Ayolé example, support and maintenance issues associated with the aquarium were not taken into account. This “gift” imposed an unanticipated burden on the recipients, which they did not address.
- Failure to adequately address both planned and unplanned interactions among the system components themselves and between system components and the environment.
Several examples of major Systems Engineering failures due to a lack of Systems Thinking in this category include Galloping Gertie, the Millennium Bridge, the Lockheed Electra airplane, the Kursk submarine, the Toyota Gas Pedal, and Bhopal.
Galloping Gertie. The infamous Tacoma Narrows Bridge spanned the Tacoma Narrows in Washington from 1938-1940. The bridge deck structure had been shortened from its original design which mandated 25-foot high stiffening trusses under the deck; these were replaced with 8-foot high steel plates to save money. This resulted in reduced stiffness and indeed, when one of the support cables snapped in high winds on 7 November 1940, the bridge began to oscillate torsionally due to aeroelastic flutter. The oscillations increased dramatically until the bridge collapsed. Sadly, aeroelastic flutter and wind-induced bridge failure had both been observed in the late 19th and early 20th centuries, but those incidents were either forgotten or ignored in this design. A good video of the collapse may be found at https://www.youtube.com/watch?v=j-zczJXSxnw.
Millennium Bridge, London. The Millennium pedestrian Bridge crosses the Thames River and was opened to foot traffic in 2000. The bridge design was unique: it is a suspension bridge with the support cables under the bridge deck instead of above the deck as with conventional suspension bridges. But soon after it opened, pedestrians noticed a side-to-side swaying motion that caused them to walk in synchronization with the sway. This synchronized pedestrian stride caused the bridge to sway even more, yielding a reinforcing feedback loop. The bridge was closed until vertical and horizontal dampers were installed (at a cost of $7 million) to minimize the lateral motion (Josephson, 2000; Dallad et al., 2001). As for Galloping Gertie, the amplified lateral sway had been noted in the literature, but was either ignored or forgotten in this case.
The Lockheed L-188 Electra Turboprop Airplane. The L-188 Electra suffered 2 fatal crashes in 1959, killing 97 people. The cause of these crashes was determined to be a reinforcing feedback loop involving the engines and the wings. When an engine mount had been weakened (for example, due to a hard landing,) normal wing flutter during flight would cause the engine to oscillate slightly on its mounts. This oscillation caused the wing to flutter more which, in turn, caused increased engine oscillation in a reinforcing feedback loop. In each of the 2 fatal crashes, this mechanism proceeded with ever-increasing amplitude until the wings sheared off the aircraft. The phenomenon was reproduced in subsequent wind tunnel tests; however the negative mechanical interactions between the engines and the wings had not been considered previously.
The Russian K-141 Kursk Submarine Disaster. In 2000, the Kursk exploded and sank in the Barents Sea, killing all 118 crewmen. The explosion was caused by a torpedo leaking hydrogen peroxide which subsequently reacted explosively with copper or brass in the torpedo tube. It was well-known that hydrogen peroxide reacts violently in the presence of metal catalysts, and this knowledge caused most navies to replace hydrogen peroxide with safer torpedo propellants such as Otto Fuel and Hydroxyl Ammonium Perchlorate (Duddu, 2014; Faulconbridge, 2004; Guardian, 2001). The risk of placing peroxide-bearing torpedoes in close proximity to metal catalysts was evidently either unknown or ignored by the Russian ship designers.
Toyota Gas Pedal/Floor Mat Entrapment. Toyota vehicles became infamous for “sudden acceleration” problems in 2007-2010, and several people were injured or killed. The problem was traced to interactions between the vehicles’ floor mats and accelerator pedals (Evans et al., 2010) in which the gas pedal would, under specific circumstances, adhere to the floor mat, resulting in loss of accelerator control. Over 4 million vehicles were recalled for corrective action (Rhee et al., 2011). In this case, the system components were correctly identified, but potential interactions were not.
The Bhopal Disaster. In 1984, a Union Carbide pesticide plant in Bhopal, India released a large volume of toxic gases to the surrounding town, killing over 13,000 people. Accidental contamination of methyl isocyanate with water in the plant had caused an exothermic reaction, yielding substantial overpressure. The emergency pressure relief valve worked perfectly, venting the toxic gases to the environment (The Engineer, 2013). If one narrowly defined the “system” as the pesticide plant in isolation, then the safety sub-system worked as designed. However, if one properly defined the “system” to include the surrounding town and environment, this was a humanitarian catastrophe and a spectacular failure of engineering design.
- Failure to recognize that many products are actually components of a User Experience System.
The Microsoft Zune. The Apple iPod was a fabulous technical and commercial success in the early 2000s. In response, Microsoft, Sony, Diamond, Tascam, and others released their own portable music players. However, none of these devices had the aesthetic appeal or “coolness” of the iPod (Jon, 2018). More importantly, Microsoft did not understand that portable music players are not stand-alone products, but are instead components of a User Experience System comprising the listener, the environment, the music download procedures, and the website, as well as the device itself. Steve Jobs and Apple were brilliant in recognizing this. Most of the non-Apple portable music players have not been commercial successes. Many other products (automobiles, clothes, coffee, home entertainment systems, homes) might also prove more successful if they were viewed as components of a User Experience System as opposed to stand-alone products.
Systems Engineering Process Considerations
Many of the engineering and design failures described earlier in this paper resulted from failures to bound the system properly, specifically interactions with environmental factors, and failures to adequately address planned and unplanned interactions among system components themselves and between system components and the environment. Those failures were the result of inadequate scoping of the problem at hand. If the boundaries and interactions of a system with its environment are not defined properly at the beginning of the Systems Engineering process, then each subsequent step in that process will be focused on incomplete or inaccurate requirements.
Consider the Systems Engineering process described by Blanchard and Fabrycki (2011) and by Kossiakoff et al. (2011), which includes the following steps:
- Regional Architecture/Scoping the Problem
- Feasibility Study/Concept Exploration
- Concept of Operations
- System Requirements
- High-Level design
- Detailed Design
- Software/Hardware Development/Field Installation
- Unit Device Testing
- Subsystem Validation
- System Verification and Deployment
- System Validation
- Operations and Maintenance
- Changes and Upgrades
- Retirement/Replacement
If the scope of the problem is not defined properly, the high-level and detailed design of the system will not include critical interactions of the system with its environment. In addition, System Verification and Validation will be incomplete and will not consider those critical interactions of the system with its environment, which could result in catastrophic failure of the system, as demonstrated by the examples described earlier in this paper.
To avoid similar failures from arising in the future, a holistic Systems Thinking perspective must be taken at the beginning of the Systems Engineering lifecycle and revisited often throughout that lifecycle. A wide range of relationships among many of the system components themselves and the environment in which the system is intended to operate must be considered. That range of relationships should also include organizational, political, economic, environmental, ethical, and sociological factors. The tools described in the following section of this paper can be instrumental in achieving that end.
In addition, many engineered products (automobiles, appliances, tools, entertainment devices, clothing, prepared foods, engineered homes, etc.) are merely components of a User Experience System. Engineers must take a holistic Systems Thinking perspective to address all aspects of that system when designing products.
Engineering and Designing Systems to Avoid Similar Failures
- Failure to identify relevant environmental factors such as wind, insolation, rain, and temperature.
As seen in several examples described earlier in this paper, failure to identify a system’s relevant environmental factors can result in disaster. Several Systems Thinking tools that can be applied during the initial steps of the System Engineering design process to address these failures include System Context Diagrams and a System Breakdown Structure (SBS).
Determining what is part of a system versus what is part of the system’s environment is difficult at times. Kossiakoff (2011) suggests four criteria that can be used to decide which components are part of a system versus its environment:
- Developmental Control: the ability of the system designer to control the component
- Operational Control: the ability of the system operator to control the component
- Functional Allocation: the ability of the system designer/operator to assign functions to the component
- Unity of Purpose: the degree to which the component is dedicated to the system’s successful performance
Components for which these four-criteria score low are defined as environmental components, rather than system components. Moreover, Kossiakoff suggests depicting system boundaries using a System Context Diagram, as shown in Figure 1.
Figure 1: System Context Diagram (adapted from Johns Hopkins, 2014)
The context diagram depicts additional entities (users, environment, power, maintainers, communications, and controllers) that must be considered in system design. For the purposes of this paper, we will focus on the environment. To identify environmental factors that may impact system performance, more detail and specificity are required for both system and environmental components. An excellent tool for this is the System Breakdown Structure or SBS.
A SBS is a hierarchical diagram that depicts the systems, environments, and user’s components as shown in Figure 2 for a suprasystem.[5] The top levels of the SBS correspond to the entities depicted in Figure 1, but the SBS contains much more detail and levels of specificity regarding the components. Additional sublevels may be added to whatever level of decomposition is needed. For example, Sub-system 1 may comprise several sub-sub-systems. Although Figure 2 represents a good starting point for a SBS, it needs to be tailored for each specific system design. For example, designers of offshore oil rigs would need to include additional environmental factors related to seas, the ocean floor, and underwater life. Lack of Systems Thinking results in consideration of only the tangible components of a system and neglects to consider the other components depicted in Figures 1 and 2, which can lead to the failures noted previously.
Figure 2: System Breakdown Structure (Monat and Gannon, 2018)
- Failure to understand that most complex problems cannot be solved by purely technological means; they often involve organizational, political, economic, environmental, ethical, and sociological components.
In the Water of Ayolé example, the government engineers assumed that this issue could be solved by purely technical means, when in fact many other factors, such as economics, maintenance, support, people, and psychology also needed to be considered. This was repeated in the Stow Center School Aquarium example. This is a very common oversight. Most technical issues also have human, environmental, economic, sociological, or emotional issues associated with them, but many engineers are uncomfortable dealing with these “softer” aspects of problems or needs being addressed.
The government engineers in Ayolé assumed that digging wells and installing pumps would solve the water problem. However, the pumps were no longer functional three years after installation. To really solve this problem several sub-systems needed to be created and installed:
- A water and pump operation training and education system
- A cultural sensitivity system
- A pump maintenance and repair system
- A supply chain for repair parts
- A money-generation and management system, including a farming sub-system
- A village/social organization to appropriately divide the labor and decision-making.
Causal Loop Diagrams (CLDs) are a tool that can be used to show cause-and-effect relationships among system and environmental components. They are especially useful in illustrating feedback processes, which are present in most systems. A CLD which illustrates the initial and final solutions for the Water of Ayolé example is shown in Figure 3. This CLD highlights the interactions among the water system and the sociological impacts of the system.
Figure 3: CLD for the Water of Ayolé Example.
In Figure 3, the solid arrows represent the initial solution; the dashed arrows represent the additional structure after the final solution. (Monat and Gannon, 2018)
While CLDs are useful, it is hard to determine if one has been comprehensive in capturing all interrelationships. More detailed explanations and applications of CLDs can be found in The Systems Thinker (2011) and in Kim (1999).
- Failure to adequately address both planned and unplanned interactions among the system components themselves and between system components and the environment.
Several of the examples described earlier in this paper (Galloping Gertie, Millennium Bridge, Lockheed Electra, Kursk, Toyota Gas Pedal, Bhopal, and Biodegradable German Car Wiring Insulation) resulted from a failure to identify potential interactions among system components, or between system components and the environment. One of the best tools that can be used to address that oversight is a System Interrelationship Matrix (SIM).
A SIM is constructed by listing all system and environmental components on both axes of a two-dimensional matrix, as shown in Figure 4. An X is placed in every cell that represents an interaction between the components. More detail can be added by noting the type of interaction in addition to the X: for example, command-control, mechanical, chemical, emotional/psychological, organizational, and frictional. A single matrix can be made for the entire suprasystem, or several smaller, more tractable SIMs can be made for sub-levels or components of the suprasystem.
Figure 4: SIM for the Highest Level of an Automobile (Monat and Gannon, 2018)
System Interrelationship Matrices can be very comprehensive, but they can also become unwieldy. Nevertheless, SIMs provide the opportunity to consider more carefully potential interactions among system components.
- Failure to recognize that many products are actually components of a User Experience System.
Steve Jobs was a great Systems Thinker. He recognized that most consumer products are part of experiential consumer use systems, rather than stand-alone products. Jobs structured Apple around the consumer’s experience, of which the product (such as an iPad) was just one component, while competitors like Sony, Tascam, Microsoft, and Diamond structured their companies around their products (such as portable music players). The device itself is simply one element of listening to music, while other elements include the means of acquiring the music, the user’s activities while listening, the environment while listening, and the prestige/coolness factor that may be associated with both the product and the listening experience (Norman, 2009) See Figures 5 and 6 for a comparison of the two approaches.
Figure 5: Sony, Tascam, Microsoft, Diamond Structure (from Monat and Gannon, 2017)
Figure 6: Apple Structure (from Monat and Gannon, 2017)
The iPad and most Apple products were developed using similar innovative Systems Thinking approaches that were focused on the user’s experience as opposed to the product itself.
Several other products that should be considered as user experience systems using this innovative Systems Thinking approach include the following:
- The automobile as a car buying and owning experience. Owning a car involves car purchase, registration, annual inspections, maintenance, use, and disposal or trade-in as well as insurance. Advances in technology make older models obsolete. Car dealers could provide all these services for a fixed monthly fee. In fact, some dealerships have already started down this path by providing service areas that include free meals, entertainment, and drop-off services. Several manufacturers (Volvo, Cadillac, and BMW) have adopted new “subscription services” in which a fixed monthly fee is paid by the user to cover lease, insurance, maintenance, and other expenses (Hyatt, 2018).
- Coffee as a coffee-drinking experience. Starbucks and others attract clients to not only buy and drink coffee, but also to enjoy the coffeehouse experience, with free Wi-Fi, comfortable seating, and fireplaces in some locations.
- Flat Panel TV as a home entertainment system experience. Selection, purchasing, matching, interconnection, and set up of home theater components can be a harrowing experience. Subscription TV service providers (Comcast, Verizon, DirecTV, DishTV, etc.) could use a Systems Thinking approach to include these services in the monthly subscription. They would ensure that their subscribers would always have the latest equipment configured and functioning properly to receive the provider’s streaming content. This approach is similar to a razor-blade or inkjet printer business model in which the asset is provided free or near-free to encourage the user to consume the razor blades or ink.
- Home Ownership as a home owning experience. Although many houses are rented today, home buyers must assume the responsibility for lawn and yard maintenance, utilities, snow removal, pool maintenance, insurance, and all the other onerous responsibilities that come with home ownership. A Systems Thinking approach to the home owning experience would bundle these items together with one monthly mortgage payment. The home owner would pay one monthly fee for all home owning tasks and services, which could be provided by the mortgage company or their representatives.
There are other examples for which close inspection (from a Systems Thinking perspective) reveals that the product is really just a part of a User Experience System.
Summary and Conclusions
In this paper, we analyzed 12 Systems Engineering failures and determined that the causes of the failures fell into four generic categories: overlooking relevant environmental factors, attempting to solve complex problems with purely technological means, inadequately addressing potential interactions among the system components and between system components and the environment, and misunderstanding the importance of User Experience Systems. Systems Thinking represents a paradigm that can be used by engineers and designers to avoid many of these problems. Several tools are available to facilitate the application of this paradigm. According to Monat and Gannon (2018):
- “Early in the design process, system engineers must ensure that they have captured all relevant components of the system, as well as the suprasystem in which the system of interest resides. Environmental factors such as wind, insolation, temperature, and the potential for dramatic incidents such as earthquakes, tsunamis, and hurricanes are notorious for being overlooked. The System Breakdown Structure (SBS) is an excellent tool to facilitate this need.
- Once the relevant components of the system of interest and its suprasystem have been properly identified, all relevant relationships must be identified. The System Interrelationship Matrix (SIM) is an excellent tool for this. Stock-and-Flow diagrams and Causal Loop diagrams may also be helpful.
- Having identified all relevant system components and interrelationships, systems engineers must then realize that very few complex problems have purely technological solutions. Engineers also must consider the sociological, psychological, ethical, political, cultural, and economic factors that may impact the success of a complex system.
- Finally, in designing complex systems, engineers must understand that “products” are very often not stand-alone devices or systems, but instead part of a user experience system that comprises the user, the environment, aesthetics, psychological factors, system acquisition, maintenance, upgrades, and disposal. Failure to address these factors may cause the system to fail, either technically or commercially.”
To avoid the types of systems engineering failures described in this paper, engineers and designers should apply these tools early in the design process as an integral component of the systems engineering process.
Epilogue
Systems Thinking: The Missing Engineering Paradigm. Experience alone does not ensure that we learn from our mistakes. Bridge failures due to wind, bridge failures due to sympathetic lateral vibration, focusing of the sun’s rays due to parabolic building shape, the dangers of hydrogen peroxide-metal interactions, and problems associated with purely technical solutions to complex problems have all been observed and documented, yet those errors are repeated. To be useful, experiences must be organized into some convenient, logical format that is easily accessible: a paradigm. The Merriam-Webster dictionary defines “paradigm” as “a philosophical and theoretical framework of a scientific school or discipline within which theories, laws, and generalizations and the experiments performed in support of them are formulated.” It would be much easier for systems engineers and designers to avoid these types of mistakes if there were a systems engineering paradigm that could be applied as an integral component of the systems engineering process. It is our hope that systems engineers will utilize Systems Thinking as an opportunity and means to minimize such errors in the future.
List of Acronyms Used in this Paper
Acronym Explanation
CLD Causal Loop Diagrams
SBS System Breakdown Structure
SIM System Interrelationship Matrix
References
BBC, “Who, What, Why: How Does a Skyscraper Melt a Car?” 3 September 2013, http://www.bbc.com/news/magazine-23944679.
Blanchard, Benjamin and Fabrycky, Wolter, Systems Engineering and Analysis, 5th Ed., Prentice Hall, Upper Saddle River, NJ, 2011.
Cramer, Matt, “11 Terrible Automotive Engineering Decisions,” Bangsift.com, 30 June 2010, https://jalopnik.com/5570865/11-terrible-automotive-engineering-decisions/5570865/11-terrible-automotive-engineering-decisions/
Dallard, P. et al. “The London Millennium Footbridge,” Structural Engineer, 79:22, 20 November 2001. pp.17–35.
Duddu, Praveen, “The World’s Deadliest Torpedoes,” Naval Technology, 8 June 2014, https://www.naval-technology.com/features/featurethe-worlds-deadliest-torpedoes-4286162/
Evans, Scott, and MacKenzie, Angus, “The Toyota Recall Crisis: A Chronology of How the World’s Largest and Most Profitable Automaker Drove into a PR Disaster,” Motor Trend, 27 January 2010.http://www.motortrend.com/news/toyota-recall-crisis/
Feldt, Allan G., 1986, Chapter 2: General Systems Theory, http://www.holisticwisdom.org/hwpages/chapt%202%20-%20GST.htm
Garfield, Leanna, “The ‘Death Ray Hotel’ Burning Las Vegas Visitors Came Up with a Simple Fix”, Business Insider, 30 June 2016, http://www.businessinsider.com/the-vdara-death-ray-hotel-is-still-burning-people-in-las-vegas-2016-6
Guardian, “What Really Happened to Russia’s ‘Unsinkable’ Sub”, 4 August 2001.
Hodge, Damon, “Reflective “Death Ray” Torments Vegas Sunbathers”, Reuters “Environment,” 1 October 2010, https://www.reuters.com/article/us-lasvegas-deathray-idUSTRE6904AR20101001
Hyatt, Kyle, “A Guide to Car Subscriptions, an Alternative to Buying and Leasing,” Road/Show by CNET, 14 June 2018, https://www.cnet.com/roadshow/news/new-car-subscription-service-guide-buying-leasing-2018/
Johns Hopkins Whiting School of Engineering, “System Context Diagrams”, 1 February 2014, https://ep.jhu.edu/about-us/news-and-media/systems-context-diagrams.
Jon, “R.I.P Microsoft Zune (2006-2011)”, Methodshop, https://www.methodshop.com/2011/03/microsoft-zune-rip.shtml, 2011.
Josephson, Brian, “Out of Step on the Bridge”, Guardian Letters, 14 Jun 2000, https://www.theguardian.com/theguardian/2000/jun/14/guardianletters3
Kossiakoff, Alexander, Sweet, William, Seymour, Samuel, and Biemer, Steven, “Systems Engineering: Principles and Practice”, 2nd Ed., Wiley, Hoboken, 2011.
Kim, Daniel H., “Introduction to Systems Thinking”, Pegasus Communications, Waltham, MA, 1999, 5-10.
Maimon, Alan, “Vdara Visitor: ‘Death Ray’ Scorched Hair”, Las Vegas Review-Journal, 24 September 2010, https://www.reviewjournal.com/news/vdara-visitor-death-ray-scorched-hair/
Monat, Jamie P. and Gannon, Thomas F., “Applying Systems Thinking to Engineering and Design, Systems, Special Issue Systems Thinking: Concepts, Issues, and Applications in Large Complex Systems,” Vol, 6, Issue 3, September 2018. http://www.mdpi.com/journal/systems/special_issues/systems_thinking_large_complex_systems
Monat, J. P., and Gannon, T.F., “Using Systems Thinking to Solve Real-World Problems”, College Publications, London, 2017, ISBN 978-1-84890-235-0.
Monat, J. P, and Gannon, T. F. “What is Systems Thinking? A Review of Selected Literature Plus Recommendations”, American Journal of Systems Science, 4:2, 2015. Available at http://article.sapub.org/10.5923.j.ajss.20150401.02.html
Norman, Don, “Designing for People–Systems Thinking: A Product is More than the Product”, Interactions 16 (5), Sept-Oct 2009.
Raymon, Noah, “London’s Tower Melts Cars, Fries Eggs”, Time, 4 September 2013, http://newsfeed.time.com/2013/09/04/londons-tower-melts-cars-fries-eggs/
Rhee, Joseph, Ross, Brian, Ferran, Lee, and Hosford, Matt, “Toyota Recalls 2.17 Million Vehicles over Pedal Entrapment”, ABC News, 24 February 2011, https://abcnews.go.com/Blotter/toyota-recalls-21-million-vehicles-floor-mats-pedals/story?id=12989254
Smith-Spark, Laura, “Reflected Light from London Skyscraper Melts Car”, CNN, 3 September 2013, http://edition.cnn.com/2013/09/03/world/europe/uk-london-building-melts-car/index.html
Sherwin, Adam, “Walkie Talkie City Skyscraper Renamed Walkie Scorchie after Beam of Light Melts Jaguar Car Parked Beneath It”, The Independent, 3 September 2013. https://www.independent.co.uk/arts-entertainment/architecture/walkie-talkie-city-skyscraper-renamed-walkie-scorchie-after-beam-of-light-melts-jaguar-car-parked-8794970.html
The Engineer, “Five Biggest Engineering Disasters”, 11 February 2013, https://www.engineering.com/Blogs/tabid/3207/ArticleID/5301/Five-Biggest-Engineering-Disasters.aspx
The Systems Thinker, “Guidelines for Drawing Causal Loop Diagrams”, 22 (1), Pegasus Communications, February 2011, https://thesystemsthinker.com/wp-content/uploads/pdfs/220109pk.pdf
Washington Post News Service, “London’s ‘Fryscraper’ Draws Crowd on Hottest Day, Mississauga News, 6 September 2013, https://www.mississauga.com/news-story/4067822-london-s-fryscaper-draws-crowd-on-hottest-day/
YouTube, “Man Fries Egg in London Skyscraper Heat,” TheNetFrancesco, 3 September 2013, https://www.youtube.com/watch?v=TGnZz8-PvdY
About the Authors
Dr. Thomas F. Gannon is a Professor of Practice in the Systems Engineering Program and Electrical and Computer Engineering Department at Worcester Polytechnic Institute, Worcester, MA, where he teaches and develops courses in Advanced Systems Architecture, Systems Architecture and Design, Systems Integration and Test, and Systems Thinking, as well as advanced graduate courses in Electrical and Computer Engineering. Dr. Gannon has both management and teaching experience in the defense, computer, telecommunications, and automated manufacturing industries, having served as Director of Information Systems Engineering at the MITRE Corporation, various senior management positions in research and development at Digital Equipment Corporation and technical leadership positions at Bell Laboratories. Dr. Gannon’s current research interests include applications of systems thinking, enterprise and system of systems modeling and simulation, high-reliability and fault tolerant systems, high-performance system architectures and Model-Based Systems Engineering (MBSE). He holds a multi-disciplinary Ph.D. in Electrical Engineering and Computer Science from Stevens Institute of Technology, as well as an M.S. from Purdue University and a B.S. from the Illinois Institute of Technology, both in Electrical Engineering. He is a member of the Academic Council of INCOSE and may be contacted at tgannon@wpi.edu.
Dr. Jamie P. Monat is a Professor of Practice in the Systems Engineering Program and Electrical and Computer Engineering Department, and the Foisie Business School at Worcester Polytechnic Institute, Worcester, MA, where he teaches and develops courses in Operations Risk Management, Project Management, System Optimization, Business Practices for Engineers, and Systems Thinking. Dr. Monat has both management and teaching experience in the business consulting, medical device, separations, food & beverage, and environmental industries, having served as President and founder of Business Growth Specialists, Inc., as President of Harvard Clinical Technology, as Sr. Vice-President of Pall Corporation, and in a variety of executive positions for Koch Membrane Systems, Inc. Dr. Monat’s current research interests include applications of systems thinking, business applications of logistic regression, emergence and self-organization, project risk management, operations risk analysis, and competency-based education. He has a B.S. in Aerospace and Mechanical Sciences from Princeton, and an M.S. and Ph.D. in Civil Engineering from Stanford. He is a member of INCOSE, the Project Management Institute, and INFORMS and may be contacted at jmonat@wpi.edu.
FEATURE ARTICLE
2.2 Becoming a Systems Engineer
by
Art Pyster
Email: apyster@gmu.edu
November 4, 2018
Editor’s note: One of the books highlighted in this issue’s SE Publications section is The Paradoxical Mindset of Systems Engineers: Uncommon Minds, Skills, and Careers. The team at PPI SyEN invited the three authors of this book to provide articles for the December 2018, January and February 2019 editions PPI SyEN. This month, we feature an article by Art Pyster.
Abstract
Systems engineers sit at the center of projects that create and evolve complex products, services, and enterprises. Somewhat anomalously, most systems engineers never actually have that title. They are called lead engineer, system architect, project engineer, or a myriad of other position titles, but they all perform the same fundamental systems engineering activities. Almost every systems engineer starts their career as a classic engineer (civil, electrical, mechanical, biomedical, software …), growing into a systems engineer over time. But how? What typical career paths do they follow? What education and training do they have? What do they experience? How are they mentored? Which personal characteristics help this growth, and which hinder it? This article, based largely on insights in the recently published book, The Paradoxical Mindset of Systems Engineers[6], first summarizes ways in which classic engineers evolve into full-time systems engineers and then explains how others secondarily become systems engineers; i.e. do some systems engineering, but maintain their primary identity in other professions such as classic engineering and project management.
Copyright © 2018 by Art Pyster. All rights reserved.
- Introduction
Great systems are created by great systems engineers. They see the “big picture”, have a spark of ingenuity and creativity, craft and convey a vision, maintain a drill sergeant’s discipline, write like a best-selling author, lead like a general, master key technologies and tools for the systems they build, and clearly convey the value a system delivers to its stakeholders. They embrace change and the challenges of uncertainty and emergence, and they know how to manage and leverage those challenges to deliver better products and services. As you can imagine, truly great systems engineers are rare – Steve Jobs, Walt Disney, and Elon Musk come to mind, although I suspect that they have never been called systems engineers.
Millions of professionals are systems engineers – often without the benefit of that title. They are more often called system architects, lead engineers, client architects, chief engineers, project engineers, and a myriad of other titles driven by custom in different business sectors, locations, and organizational culture. And some, of course, are called systems engineers. Only rarely does someone begin their career as a systems engineer. Rather, they grow into a systems engineer (no matter the title) through years of diverse experiences, wise mentoring, and targeted education and training – the three forces that shape a person’s proficiency at doing systems engineering.
The Helix Project, which I led from 2012 through 2016, and which is now led by Dr. Nicole Hutchison, has looked at which values systems engineers deliver, the roles they play to deliver those values, which proficiencies they master to do well in those roles, and typical career paths they follow to master those proficiencies. In-depth interviews with more than 300 systems engineers and their colleagues provided a rich dataset that is the foundation for our findings. That data was augmented by the lengthy applications of more than 2500 people who have been certified by INCOSE as Systems Engineering Professionals. Each application captures the career history of the applicant, including the positions they held, the lifecycle phases in which they worked, descriptions of the systems they had developed, their education, the roles they had performed, and the proficiencies they had mastered. The wealth of insights those applications offered provided details about the careers of relatively successful systems engineers at various points in their careers.
We have reported our findings and recommendations in a number of venues, most recently in The Paradoxical Mindset of Systems Engineers. The book title was chosen because one of the most important proficiencies that systems engineers master is paradoxical mindset – the ability to comfortably hold in your head and balance two seemingly contradictory or competing concepts. Many people are excellent at either understanding and explaining the big picture or tiny details, at either mastering a business perspective or a technical perspective, or at either being bold or sticking to the script. Few people deal well with both extremes simultaneously. Critically, systems engineers are masters at this.
All of this brings us to the question: How does someone become a systems engineer? The rest of this article offers a summary of our answer to that question.
- Values
As a group, systems engineers generally hold positions in which they deliver the same six values independently of business sector and company:
- Keep and maintain the system vision.
- Translate technical jargon into business or operational terms and vice versa.
- Enable diverse teams to successfully develop systems.
- Manage emergence in both the project and the system.
- Enable good technical decisions at the system level.
- Support the business case for the system.
These values emerged over and over in our interviews. Virtually everyone interviewed said that keeping and maintaining the system vision was an important value that every systems engineer must deliver. No other value was as dominant, but the other five stood out. Not every systems engineer delivers all six values in a single position, but over time they will generally deliver every one. Their focus in a single position will vary with the specific assignment and circumstances surrounding the systems on which they work.
As an example of the values delivered, when I was the Deputy Chief Information Officer (CIO) for the US Federal Aviation Administration (FAA) from 1999 to 2004, one of my responsibilities was overseeing how information security (which today would be called cybersecurity) was ensured for every major FAA air traffic control and business system. In this role, I was a systems engineer as well as a senior executive, although I never had the official title of systems engineer. Others did the implementation to ensure the systems were secure, but the CIO’s office wrote the overarching security policy that guided certification of approximately 150 air traffic control systems, reviewed and approved the plan for each certification effort, funded much of the project work, negotiated the certification process with the FAA executives who acquired, maintained, and operated each system as well as with the Department of Transportation, negotiated the priority for certifying each system, reviewed the results of the certification efforts, and reported the results to both the Department of Transportation and offices within the White House. In the Deputy CIO role, I tried to deliver all six values; e.g. one of my jobs was to keep and maintain the vision as to why information security of FAA systems was important (Value 1) and to communicate that importance to FAA executives at a time when information security was much less understood and appreciated than it is today (Value 2). I was also responsible for preparing the business case for funding information security (Value 6).
- Roles
Systems engineers occupy positions in which they perform 15 roles that deliver the 6 values described in Section II. There are three types of roles:
- Roles related to the systems being developed:
- Concept Creator (CC): Explore the problem or opportunity space and develop the overarching vision
- Requirements Owner (RO): Elicit, document, verify, and manage customer, system, and subsystem requirements
- System Architect (SAR): Develop and manage the architectures for the system, including both functional and physical architectures
- System Integrator (SI): Develop and manage systems interfaces and provide a holistic perspective of the system
- System Analyst (SAN): Model or analyze during system development to help ensure the system as designed meets the specification
- Detailed Designer: (DD) Provide technical designs that match the system architecture
- V&V Engineer (V&V): Plan, conduct, or oversee verification and validation activities
- Support Engineer (SE): Perform activities at the back end of the system lifecycle
- Roles related to the systems engineering process and organization:
- Systems Engineering Champion (SEC): Promote the value of systems engineering to individuals outside of the systems engineering community
- Process Engineer (PE): Define and maintain systems engineering processes
- Roles related to the teams that build the systems:
- Customer Interface (CI): Coordinate with the customer, particularly for ensuring that the customer understands critical technical detail and that a customer’s desires are, in turn, communicated to the technical team
- Technical Manager (TM): Control cost, schedule, and resources for the technical aspects of a system
- Information Manager (IM): Manage the flow of information during system development activities
- Coordinator (CO): Bring together and bring to agreement a broad set of individuals or groups who help resolve systems-related issues
- Instructor/Teacher (IT): Provide or oversee critical instruction on the systems engineering discipline, practices, processes, etc.
To illustrate the relationship between roles and positions, Table 1 shows the roles I played at Digital Sound Corporation, a commercial telecommunications company that developed voicemail products, where I was a multi-hatted Engineering Director.
- Proficiencies
To be effective in performing these 15 roles, systems engineers rely on proficiencies which are grouped into six areas composed from 33 categories, as shown in Figure 1. For a specific position and set of roles, a particular level of strength in these proficiency areas is required; e.g. suppose a systems engineer is part of a project that is developing an enterprise system for hospital care which will be used by doctors, nurses, technicians, administrators, and other professionals in different disciplines for the benefit of patients, insurance companies, government regulators, and other stakeholders. A strong proficiency in advanced psychology would be quite valuable. Consequently, a systems engineer would master basic psychology in the Social Science Foundations category under the Math/Science/General Engineering proficiency area. Additionally, that systems engineer would master advanced psychology in the Relevant Disciplines and Specialties category of the System’s Domain & Operational Context proficiency area. Each of the categories in this proficiency area is tailored to the specific systems and the operational context in which those systems reside.
At any given time, each systems engineer has a profile that reflects how strong they are in the six proficiency areas. An example Proficiency Profile is shown in Figure 2 below. That profile can be expanded to show strength in each of the underlying 33 proficiency categories as well. Figure 3 shows that expansion for two of the proficiency areas.
Figure 1: Proficiency Areas and Categories
Figure 2: An Example Proficiency Profile
Figure 3: Profiles for Two of the Areas at the Category Granularity Level
The profile can be created as a self-assessment or by peers or supervisors. The profile can be an exemplar from an organizational leader or a recommended profile by management for people occupying certain positions. The approach is very flexible. Scoring is performed using a 5-point scale developed by the National Institutes of Health (NIH) as shown in Table 2.
| Table 2. Proficiency Scale | ||
|---|---|---|
| # | Level | Level Description |
| 1 | Fundamental Awareness | You have common knowledge or an understanding of basic techniques and concepts. Your focus is on learning rather than doing. |
| 2 | Novice | You have the level of experience gained in a classroom or as a trainee on-the-job. You can discuss terminology, concepts, principles, and issues related to this proficiency, and use the full range of reference and resource materials in this proficiency. You routinely need help performing tasks that rely on this proficiency. |
| 3 | Intermediate | You can successfully complete tasks relying on this proficiency. Help from an expert may be required from time to time, but you can usually perform the task independently. You have applied this proficiency to situations occasionally while needing minimal guidance to perform it successfully. You understand and can discuss the application and implications of changes in tasks relying on the proficiency. |
| 4 | Advanced | You can perform the actions associated with this proficiency without assistance. You are certainly recognized within your immediate organization as “a person to ask” when difficult questions arise regarding the proficiency. You have consistently provided practical and relevant ideas and perspectives on ways to improve the proficiency and its application. You can coach others on this proficiency by translating complex nuances related to it into easy to understand terms. You participate in senior level discussions regarding this proficiency. You assist in the development of reference and resource materials in this proficiency. |
| 5 | Expert | You are known as an expert in this proficiency. You provide guidance, troubleshoot and answer questions related to this proficiency and the roles where the proficiency is used. Your focus is strategic. You have demonstrated consistent excellence in applying this proficiency across multiple projects and/or organizations. You are considered the “go to” person in this area within your own organization and perhaps externally. You create new applications for this proficiency or lead the development of new reference and resource materials on this proficiency. You can explain this proficiency to others in a commanding fashion, both inside and outside your organization. |
- Forces
Three forces drive change in someone’s proficiency profile: experiences, mentoring, and education & training. Experiences are, by far, the most important force as acknowledged by every person we interviewed. The literature on workforce development reinforces this view. Among the well-cited is the seminal work of Michael Lombardo and Robert Eichinger[7], who showed that 70% of professional growth results from experience, 20% from mentoring, and 10% from education & training. Interviewees also indicated that diversity in experiences is critical to growth of systems engineers. They must see different types of systems, different technologies, different lifecycle models, etc. to achieve their full potential. Personal and organizational characteristics serve as force multipliers, either throttling or accelerating proficiency growth. Figure 4 shows the most important personal and organizational characteristics.
Figure 4: Personal and Organizational Characteristics are Force Multipliers
- Successful Careers
We were able to identify numerous patterns and conclusions about the education and experiences of the many successful systems engineers we interviewed and those who were certified by INCOSE as Systems Engineering Professionals (SEPs). Four points stand out about the education of systems engineers:
- Systems engineers are highly educated. Virtually all have a bachelor’s degree. Most earn a master’s degree, and many have two master’s degrees.
- Few systems engineers earn a bachelor’s degree in systems engineering. Most earn a bachelor’s degree in a classic engineering discipline or, to a lesser extent, earn a science, math, or technology degree, giving them sufficient strength at graduation in Science/Math/General Engineering proficiencies.
- Younger systems engineers increasingly earn a master’s degree or a doctorate in systems engineering, significantly strengthening their Systems Engineering Discipline proficiencies.
- A master’s degree in some form of business or management is increasingly popular, strengthening Technical Leadership proficiencies.
Three points stand out with regard to the education and experiences of very senior systems engineers, which include the 35 Chief Systems Engineers (CSEs) we interviewed plus more than 200 INCOSE Expert Systems Engineering Professionals (ESEPs):
- In both lifecycles and roles, diversity of experiences is critical for growth and development of systems engineers. All CSEs that we interviewed have experiences across at least four lifecycle phases[8], and almost all CSEs have experienced System Definition, System Realization, and Systems Engineering Management. The most common lifecycle phase point of entry for CSEs is Systems Definition.
- The most common bachelor’s degree majors among CSEs were electrical engineering and mechanical engineering, covering more than two-thirds of the CSE dataset.
- At the master’s level, the Master of Business Administration (MBA) is the most popular major; almost 50% of CSEs hold an MBA. Systems engineering is the second most common master’s degree field among CSEs.
- Secondarily A Systems Engineer
Virtually every seasoned classic engineer does some systems engineering. Some do systems engineering for much of their day; e.g., helping to develop requirements for a subsystem on which they work or helping to develop the verification strategy for the software architecture they are developing. Increasingly, university engineering programs are expected to include aspects of systems engineering in their curricula. In fact, ABET[9], which accredits all bachelor’s degree engineering programs in the US and more than two dozen other countries, will soon require all programs to teach a systems perspective[10].
It is common to find systems engineering roles and proficiencies in advertisements for many classic engineering positions. For example, a job opening on indeed.com for a senior-level mechanical engineering job called out many tasks and proficiencies of systems engineers, such as “providing a very high level of technical leadership,” “establishing design standards, specifications, and criteria for projects,” and “generating] project requirements”. As classic engineers rise in organizations and advance their careers, they frequently move along a continuum from classic engineer towards systems engineer. How far they go along that continuum depends on their interests, abilities, and opportunities.
Program managers also frequently find themselves secondarily performing as systems engineers. Rebentisch[11] identifies four areas of responsibility shared between project/program managers and systems engineers: managing program/project risk, managing external supplier relations, managing quality, and planning the project/program lifecycle. It is common for systems engineers to become program/project managers and sometimes to move back to systems engineer. Several years ago, Ken Dahlberg, then CEO of SAIC, a Fortune 500 company, told me that the best program managers he knew had previously been systems engineers.
- Summary and Conclusions
Today’s systems engineers need to stay on top of the rapid changes in their profession. Technologies such as machine learning, additive manufacturing, and agile system development are sweeping away old ways in which systems engineers practice their profession. We offer a 6 step approach to staying on top of your game: (1) Know yourself, using proficiency profiles and other techniques to maintain self-awareness; (2) Lay out your aspirations for the next several years and decide how your proficiency profile needs to change to realize those aspirations; (3) Diversify your experiences, keeping in mind that diversity is a great force multiplier to change your proficiency profile; (4) Never stop learning; take courses, watch videos, take on assignments in which you have to master new technologies; (5) Expand and deepen your social network; systems engineers maintain their effectiveness, in part, by surrounding themselves with people who are stronger and smarter than they are in key technologies, understanding of the business, and other drivers of proficiency growth; and (6) Keep adapting; no plan will be right for long; it must change as new circumstances, opportunities, and challenges emerge.
List of Acronyms Used in this Paper
Acronym Explanation
CIO Chief Information Officer
CSE Chief Systems Engineer
ESEP Expert Systems Engineering Professional
FAA Federal Aviation Administration
INCOSE International Council on Systems Engineering
MBA Master of Business Administration
SEBoK Guide to the Systems Engineering Body of Knowledge
SEP Systems Engineering Professional
Acknowledgements
Drs. Nicole Hutchison and Deva Henry co-authored The Paradoxical Mindset of Systems Engineers, on which this article is based.
References
ABET Engineering Accreditation Commission: Criteria for Accrediting Engineering Programs. Available at https://www.abet.org/wp-content/uploads/2018/02/E001-18-19-EAC-Criteria-11-29-17.pdf.
Guide to the Systems Engineering Body of Knowledge (SEBoK). Available at https://www.sebokwiki.org. The SEBoK was created by the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) project. BKCASE is overseen by a Governing Board, consisting of the International Council on Systems Engineering (INCOSE), the Systems Engineering Research Center (SERC), and the IEEE Computer Society.
Lombardo, M. and Eichinger, R. (2010). Career Architect Development Planner, 5th Edition. New York: Korn/Ferry International. Available at https://www.amazon.com/Career-Architect-Development-Planner-5th/dp/193357822X/ref=sr_1_1?s=books&ie=UTF8&qid=1541947881&sr=1-1&keywords=Career+Architect+Development+Planner%2C. This book is highly recommended by Amazon reviewers as a career development tool. See an article concerning this book in the SE Books section of this issue of PPI SyEN.
Pyster, A., Hutchison, N., and Henry, D. The Paradoxical Mindset of Systems Engineers: Uncommon Minds, Skills, and Careers. Hoboken, NJ: John Wiley and Sons, 2018. ISBN 9781119412151. Available at https://www.amazon.com/Paradoxical-Mindset-Systems-Engineers-Engineering/dp/1119412145/ref=sr_1_1?s=books&ie=UTF8&qid=1541948072&sr=1-1&keywords=The+Paradoxical+Mindset+of+Systems+Engineers
Rebentisch, E. (ed.) (2017). Integrating Program Management and Systems Engineering. Hoboken, NJ: Wiley. Available at https://www.amazon.com/Integrating-Program-Management-Systems-Engineering/dp/1119258928/ref=sr_1_1?s=books&ie=UTF8&qid=1541948133&sr=1-1&keywords=Integrating+Program+Management+and+Systems+Engineering
About the Author
Dr. Art Pyster is the Associate Dean for Research and a Professor in the Volgenau School of Engineering at George Mason University, and the Director for Strategic Integration for the International Council on Systems Engineering (INCOSE). Dr. Pyster has more than 40 years of experience as a researcher, engineer, educator, executive, and manager in government, industry, and academia. Among his earlier positions, he was a Distinguished Research Professor at Stevens Institute of Technology, Chief Operating Officer of the Systems Engineering Research Center, INCOSE’s Director for Academic Matters, Senior Vice President and Director of Systems Engineering and Integration for SAIC, and Deputy Chief Information Officer for the US Federal Aviation Administration. He is an INCOSE Fellow, a member of the INCOSE Board of Directors, and a recipient of the INCOSE Founders Award.
3. Additional Article
3.1 Integrating Program Management and Systems Engineering
by
Martin Griffin
Leidos, Australia
Email: Martin.W.Griffin@Leidos.com
November 7th, 2018
Abstract
The benefits of integrating systems engineering principles with project management philosophies are well established [Langley, M., Robitaille, S., & Thomas, J. (2011)]. Why then is it so difficult to achieve an integrated approach? How can we further strengthen and improve project and program success rates, particularly for complex projects?
The root cause of this dilemma appears to lie in the historic evolution of two lifecycle-delivery methodologies (program/project management [PM] and systems engineering [SE]) – the representative industry bodies and the resulting suite of discipline standards and respective bodies of knowledge began diverging in the 1960’s and 1970’s. Even though both of these communities had a common mission and overall goal (and to this day still do), the evolutionary development of their processes and tool-sets have led to individuals within both communities not fully understanding the other’s domain and not creating a program environment that fosters success. Compounding this unfortunate development, a divergence concerning conflicting mindsets in organizational silos have created in many programs a barrier to cooperation, resulting in ‘unproductive tension’ as documented in PMI and INCOSE studies that were performed during the research phase of the book (2011 to 2014). There are well described in the book, Integrating Program Management and Systems Engineering [Eric Rebentisch, Editor-in-Chief (2017)].
This paper explores the history of both project management and systems engineering, in order to uncover the aspects causing continuing conflicts and to highlight where and why the elements of project delivery struggle to align and quite often cause friction. Based on this understanding, the various studies and research comparing these two disciplines is explored to understand why the integration of these methodologies is prerequisite to success.
Practical approaches are presented to resolve the barriers to integration and actions to achieve maximum value for all stakeholders are described.
Copyright © 2018 by Martin Griffin. All rights reserved.
Introduction
Since the inception of modern project management practices in the 1960’s (having origins in the Critical Path Method), the evolution and worldwide adoption of its underpinning theorems and processes have resulted in a standardized approach to project delivery within organizations across the globe. Its popularity and to a large extent necessity, through the 1970’s global recessions actually resulted in significant corporate restructures in the 1990’s to ensure maximum resource alignment into project-based teams to focus individual’s efforts to the realization of organizational benefit from its Project Portfolio. This has meant the formation of specific roles skilled in the various knowledge areas of project management even though these have not been formally recognized technical disciplines within academia. The current day project manager will have a broad range of technical skill sets ranging from technical trades to engineering and even business management. This evolutionary development has largely resulted in prescriptively defined role responsibilities with the accountability of financial or executive authority from the organization to deliver a defined scope within the constraints of time, cost, and quality.
Similarly, the ‘science’ and practice of systems engineering has evolved from the 1940’s where the principles were being deployed in early telecommunications development (Bell Laboratories) and then heavily utilized within NASA and the US Defense agencies in the 1950’s and 60’s, when these organizations developed their own detailed processes across the full life cycles of projects and programs. The resulting perceptions led to systems engineering being relegated to complex system development and being constrained to practitioners from technical disciplines. The principles did continue in most sectors including automotive, transportation, and mining; however, they were heavily customized and disassociated from the systems engineering origins. So, even though the two philosophies of Project Management and Systems Engineering have the same mission with the same underlying gated constructs, their respective evolutions diverged to such a magnitude that the practitioners in each do not understand the terminology and nomenclature of the other.
This was recognized by the representative Industry bodies PMI and INCOSE and in 2011 these groups came together to study and understand the ‘unproductive tension’ that was being associated with project failures. The research, which ran over multiple studies through to 2014, highlighted that a principle cause was the key roles of the Project Manager and the Chief Systems Engineer did not understand each other’s methodologies. This work was captured in the book ‘Integrating Project Management and Systems Engineering’, Eric Rebentisch of MIT Editor-in-Chief and published in 2017. This work surmises that further education of the key project roles to better understand the others lifecycle processes would improve the integration and therefore yield better collaboration leading to more positive project outcomes.
The research findings and recommendations of this industry body collaboration are symptomatic of the divergent evolution that these project delivery methodologies have experienced since the 1970’s. This paper will highlight the human nature aspects of this mindset divergence and provide some practical approaches to bridging the divide and maximizing the value inherent in aligning these lifecycle delivery frameworks.
Project Management Evolution
There are a plethora of texts and papers on the origins and the subsequent evolution of modern day project management, and anyone interested in the detailed breakdown of this history can refer to the Project Management Institutes (PMI) list of references or the 2004 PMI Research Conference paper by Aaron Shenhar [Shenhar, A. & Dvir, D. (2004). Project management evolution] which has a good breakdown of the underpinning concepts as they appeared and were further refined through the decades. As a comparative breakdown of the key turning points for Project Management as a philosophy and resulting methodology the Timeline in Figure 1 is sufficient to describe the evolution:
Figure 1 : Project Management Evolution Timeline
Some texts point to the late 1950’s as the origins when the efforts to develop complex weaponry and warfighting systems required detailed planning and business collaboration, but regardless of the driving influence, the predominant factor concerning the emergence of the current principles was in the release of the Critical Path Method (CPM) for activity scheduling and the subsequent Program Evaluation and Review Technique (PERT) charts. These techniques were readily adopted by the larger organizations such as NASA as a means to manage the complicated aspects of the internal and external organization activities needed to deliver their developmental programs. With the rapid uptake of these management techniques came a need to capture best practice and industry standards to enable the supporting organizations to deliver into these complicated programs; this resulted in the formation of the PMI in North America. This group formed a charter with a focus on collating and disseminating industry best practice and lessons learned, and this was captured within the PM Body of Knowledge (PMBOK) which was officially released as a published resource in 1969.
Through this same period, other organizations were developing and administering internal models based on similar application of tools. One which has risen to world-wide adoption is the PRINCE methodology which originated in the UK as the Project Resource Organization Management Planning Techniques (PROMPT) and was primarily adopted by the Central Computer and Telecommunications Agency (CCTA) who renamed it PRINCE, “PROMPT II IN the CCTA Environment” and which subsequently became known as “PRojects IN Controlled Environments”. The current version, PRINCE II, has become the pseudo-defacto methodology for most professional Project Managers and preferred by the majority of industries and organizations around the globe.
During the 1970’s, with the global recessions, the constraint of cost led to the project management principles becoming increasingly important in order to survive, and its popularity spread to most other industry sectors. With this came the need for better control, and as technology in the electronics space was making computers more accessible and reliable into the 80’s, tools such as Microsoft Project which embedded the scheduling techniques became the default for managing projects. In the 1990’s the industry bodies assumed a more prescriptive stance and driven by the desire to increase membership and the need for more auditable process (driven by ISO9001 Quality standards development), established “Competency Standards”, against which practitioners were measured to assess understanding of the underlying principles and technique application.
Into the 2000’s, the prescriptive standards-driven approach led to organizations restructuring to provide clarity between everyday project operations and the teams responsible for improvement of operations or establishment of a new product stream or development of solutions into other operational organizations. Several notable project failures, and a growing perception that ICT projects regularly exceeded planned schedules, identified a need for more flexibility within complicated programs running over multiple years and the Agile Manifesto was developed to enable breaking larger programs into smaller manageable but linked projects.
The period through the 2010’s has seen very little change to the fundamentals of Project Management as detailed within the standards PMBOK and PRINCE II and brought more refinement and more efficient tools with 2017 seeing the formal adoption of Agile within the PMBOK process set and the Earned Value Management aspects tightening up on Earned Schedule as a means to control project over-runs. The current embodiment of Project Management has seen an entire supporting resource construct evolve where individuals are purely skilled within one element of Project Management such as Project Controllers and Planners and Project Management Office (PMO) roles and responsibilities becoming standardized throughout industry.
Systems Engineering Evolution
Similar to the PM evolution, there is some variance in opinions as to the original surfacing of the systems engineering methodologies, and for those interested in exploring this you should refer to INCOSE for useful reference texts. However, the more common view is that the processes used in modern day systems engineering originated within Bell Laboratories during the 1940’s for development of complex telecommunications systems. The timeline below shows the parallel path of this lifecycle delivery methodology.
Figure 2: Systems Engineering Evolution Timeline
The first texts that introduced the concepts of ‘Systems Thinking’ were published approximately in 1960, and given the coincidence with the Space Race and the Cold War, rapid emergence of technologies remained dominant on the global stage. The Department of Defense and NASA were very early adopters of these techniques and principles. With limited documented information on how to apply this approach these two agencies established their own internal models and organizational rules and these progressively became the ‘standards’ adopted across businesses supporting these entities and then out to adjacent market sectors where strict control of research and development was needed to assure the validity of the original operating need or organizational goal.
From its very original introduction the intent of Systems Engineering was to establish robust planning of the various developmental stages of a product or systems lifecycle to show the traceability of an operational need through to the implemented system in operation with consideration of subsequent lifecycle phases including disposal/replacement. With the initial sectors that adopted and developed these techniques there was an early and persistent perception that it was expressly for the complex and complicated developmental environments and also the perception that these areas could afford the additional planning and administrative burden inherent in the Military Standards (MIL-STD) and NASA processes for high criticality software and safety critical applications.
In the 1970’s the tight cost controls required led to the reduced uptake of Systems Engineering and in the industries that had incorporated some of the principles such as automotive manufacturing the use of LEAN and Six Sigma cost minimization techniques refined the use of Systems Engineering to a point that it was no longer recognizable against the mainstream definitions. In 1979 a group of Engineering Managers, American Society of Engineering Managers (ASEM), formed to foster and promote the use of Systems Engineering. This led to a resurgence of the discipline and wider adoption where assurance for safety critical systems was needed and by the 1990’s the National Council of Systems Engineers (NCOSE) had formed as the industry body responsible for the discipline competency standards and owner of the SE Body Of Knowledge (SEBOK). By 1995 other similar industry associations around the world (including SESA) agreed to collaborate with NCOSE and the group was renamed as INCOSE (International). During this period the US Department of Defense decided to reduce their administration costs associated with maintaining the MIL-STD set of processes in preference to adopting the INCOSE managed suite of standards giving rise to the need for an International Standards Organization (ISO) release for the discipline which officially occurred in 2002.
With the advancement of technologies allowing more complex and complicated systems to be developed, streams of Systems Engineering emerged focused on Complex Systems and System of Systems with complimentary industry associations (CSSE, NCSOSE and SOSECE). This has further exacerbated the perception that the methodology is associated with high technology development programs and led to a universal belief that the discipline has high cost of implementation and it can only be warranted on these programs that can absorb this cost burden. In a self-actualization way the Systems Engineering processes and tools developed for application on high complexity programs tended to get deployed by practitioners engaged in the other industry sectors (e.g. defense processes being used within the transport sector) which acted to substantiate business leaders’ views of limited value in adopting the methodology on general system design work.
The Common Goal
Is there a fundamental difference between the methodologies of Project Management and Systems Engineering, or are these simply two approaches to achieving the same organizational goals? The answer exists in some of the research work undertaken by the PMI-INCOSE-MIT alliance [Conforto et al. (2013)] and can also be seen in the fundamental mission statement of the two approaches.
Project Management Mission:
The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.
Systems Engineering Mission:
Assure the fully integrated development and realization of solutions which meet stakeholders’ expectations within cost, schedule, and risk constraints.
The following table shows the comparison of the primary PM and SE standards.
Figure 3 : Comparison of the Objectives of PM and SE from the Respective Standards
From Figure 3 it is clear that both domains are based on a lifecycle delivery model that segments the activities into a time-phased breakdown of work scope needed to develop and implement the solution. The more significant difference observed within the industry body handbooks is that INCOSE has a focus on development whereas the PMI BOK provides more generic phase segregation. A further difference can be seen in the timeframe over which the processes get deployed with Systems Engineering clearly showing the decisions needing to consider the full lifecycle to retirement, but Project Management is more contractual in nature applying until the completion of the project scope.
So, at a fundamental level these two methodologies are attempting to achieve the same goal and even with a similar time-phased deconstruction of the constituent activity elements. The differences stem more from the areas of application and how the member communities and representative industry bodies have articulated the processes within guides and standards. Overlaying the phases and key activity gates between the two it becomes apparent that there is also an organizational perspective at play where PM assumes a contractual management responsibility and relegates the SE administration to the technical aspects of the contracted scope. When viewing the traditional PM and SE lifecycle phases as shown in Figure 4, it is clear that the Requirements Baseline is referring to technical requirements and the Functional Baseline is the required performance of the technical elements. The contractual and other project delivery requirements are not managed in the same way which regularly leads to issues of scope control and deviations to contract terms.
Figure 4: Traditional representation of phases and review gates
This ‘pigeon-holing’ of the respective methodologies driven by standards and organizational constructs is not constrained to these two methodologies as the same can be seen in the newer organizational management technique of Asset Management which has risen to cover an operational need to more effectively manage the resulting capabilities from projects.
Figure 5 : The IAM Asset Management Conceptual Model
The Asset Management (AM) methodology actually overlaps Project Management (or more often Portfolio Management) and Systems Engineering and introduces another suite of processes that need to be managed within an organization (refer Figure 6). With the increasing popularity of this more recent methodology another organizational construct is emerging and additional internal interfaces and commensurate duplication of process is emerging.
For the purposes of this paper it is important to recognize that methodologies and related processes must be viewed as enablers for project delivery and organizational value and not drivers to achieve compliance under a Quality Management regime. In the case of Asset Management, the ‘activity’ of Systems Engineering has been diminished in applicability to a sub-element of Lifecycle Delivery as can be seen highlighted in Figure 6 below. This has a subsequent connotation that to attain ISO55000 (AM) accreditation the scope of System Engineering will be constrained to initial or subsequent Asset creation and that Project Management is only required where the Lifecycle Delivery meets the organizations definition of a ‘Project’.
Figure 6 : The IAM Asset Management Process Elements
Research into the Value of adopting SE
For the last two decades the resurgence of Systems Engineering has attracted significant research effort into understanding the value of its adoption. Most of this research has centered on the industries that have historically adopted and implemented Systems Engineering such as Defense and NASA and a significant amount has been sponsored by the representative industry bodies such as INCOSE [Eric Honour – 2002 through to 2010]. However more recent activity is exploring the value gained across other industry sectors such as Health and Transport but the context tends to be related to the increasing complexity within the systems deployed in these sectors.
A study conducted by Carnegie Melon University in 2012 [Elm, J., Goldenson, D (2012)] and repeated in 2014 explored the relationship between successful project outcomes and the extent of Systems Engineering employed within the organizations. The first study was predominantly in the software domain and heavily Defense-centric but the results were quite conclusive and so the study was repeated extending out into other sectors and across a broader industry base with essentially the same results. Figure 7 below shows the outcome with organizations having higher SE usage showing significantly higher performance across their projects. This study further looked at project complexity and found a further correlation of high performance with high deployment of SE (Figure 8).
With the research undertaken by the PMI and INCOSE alliance there is compelling evidence to warrant serious consideration of integrating SE into any PM lifecycle delivery model. The challenge is how to do it within the current segregated discipline environments and the heavily engrained organization structures across most industry sectors.
Figure 7 : Carnegie Mellon University Study into Project performance and SE
Figure 8 : Carnegie Mellon University Study looking at Project Complexity
The Root Cause of Poor Integration
The PMI-INCOSE research identified a common theme of ‘Unproductive Tension’ within projects and organizations where there were performance issues. There were a number of potential causes identified from lack of understanding between the two domains to direct conflict of role objectives and obligations, but the end result was project churn and difficulty in delivering an acceptable outcome. One aspect of this research that was overlooked was that of domain boundaries and the resulting constrained thinking. A recent output of the research has been some integration guides produced in the UK (Figure 9) which demonstrate a view of responsibility boundaries within the two disciplines. Within current organization structures this view provides a means to enable integration conversations to occur and hopefully initiate some effective collaboration however it also perpetuates the present perception that SE is constrained to the technical aspects of the project.
Figure 9: Guide Z11 Issue 1.1, Jan 2018 – INCOSE UK & Project Management
If you explore the ten knowledge areas associated with PM as described within PMBOK and shown in the mind map of Figure 10 you find every element is addressed within the SE methodology and this approach actually permits the inter-relationships between each area to be assessed against the operational need or desired capability outcome. The same can also be said for the Asset Management aspects of Figure 6 within and outside of the Lifecycle Delivery aspect.
Figure 10: The Knowledge Areas of Project Management Responsibility
Therefore, the true root cause of poor integration is actually ‘constrained thinking’; the following list of integration issues give rise to this cause and need to be explored within any organization if an enduring integration is to be realized:
Human Nature: Conditioned or Local Mindsets
Communication: Speaking a different language
Culture: Process Compliance – Resistance to Change
Environment: Industry norms – e.g. Rail Standards
Societal: Business practices – Contracting methods
Organizational: Organization structure with Role definitions
The Organization Breakdown Structure (OBS) issue is actually a prevalent one that can readily bring rise to the other issues listed and one that gets influenced quite often by the single view-point of project management. This has evolved since the 1970’s and is quite evident in certain industry sectors but in reality exists across all industry sectors. The following representative organizational construct is often seen within the rail industry where a scope constrained view leads to a perception that Integrated Project Teams (IPT) based around the technical packages is an effective OBS. This approach regularly leads to silos where each technical group drives their solution in isolation to the other interdependent system aspects and inevitably the rolling stock arrives on schedule for testing, the infrastructure including signaling is delivered to schedule and the depot gets commissioned on time, but nothing actually integrates and each element becomes a constraint requiring compromise of the total capability.
Figure 11: Common Organization Structure in the Rail Industry
Actions Needed to Further Strengthen and Improve Integration of PM and SE
Chapter 16 of Integrating Program Management and Systems Engineering (IPMSE) provides calls to action for several groups of stakeholders: academia, enterprise, policymakers, industry and professional societies, and researchers. These calls to action identify specific actions that stakeholders in each group should take.
This Newsletter, Project Performance International Systems Engineering Newsletter (PPI SyEN), has provided a series of articles over the past eighteen months (PPI SyEN 54 [June 2017] through PPI SyEN 71 [November 2018]) (see https://www.ppi-int.com/syen-newsletter/ for copies of these issues of PPI SyEN) that provide an introduction to the critical concerns and a summary of each of the chapters of IPMSE as well as many specific recommendations, particularly for systems engineers.
From my own experience and perspective, following are several actions that need to be “worked” aggressively if we are to avoid continued failures of complex projects and programs:
- Professional Societies such as INCOSE and PMI need to actively engage with the Commonwealth of Australia and other end customer organizations to highlight the importance of not over-prescribing Standards compliance within their Contractual models.
- Academia needs to acknowledge the impact of societal business constructs on how projects get managed and delivered to ensure new graduates are equipped to enter industry and operate within any organization’s process frameworks.
- CEO’s and business leaders need to recognize the human nature aspects of the various disciplines required to effectively deliver on their company visions and strategies and ensure that delivery models seek to optimize the benefits from discipline tools rather than prescribing compliance to them.
- Practitioners of any given discipline or within any developed business process construct need to be consciously aware of the human characteristic of ‘conditioned thinking’ that inhibits innovation and artificially constrains our ability to reason. The processes and tools at our disposal were likely created by others for an outcome not suited to the current objective.
A summary note to all of the systems engineering practitioners: constraints and interfaces are what the systems engineering methodology is ideally structured to manage. It is critically important to understand that this not be limited to the technical elements of any project. In order to effectively deliver on the systems engineering mission, the full set of engaged disciplines on any given project need to be included, and the silos and barriers that exist at any stage within a lifecycle need to be understood and addressed in order to yield productive integration.
Transition to an Enduring Integrated Model
There is no ‘one size fits all’ answer, but wherever it is possible to change the organization structure or the business processes (even through tailoring), then this should be the starting point. The ‘Unproductive Tension’ identified by PMI-INCOSE and the ‘Constrained Thinking’ highlighted earlier both have significant foundation within the organization construct and the segregation of delivery streams (usually manifested in processes adopted). Utilizing SE principles to understand the operational (or organizational) need and then creating a process model that is optimized to deliver that need in an integrated team of multi-disciplined resources (including all required disciplines outside of the technical/engineering domain) all working under a common goal to deliver the capability required (not just the scope of work).
Concerning organizational restructuring, this needs to occur relative to the project or business outcome to be achieved and it is not simply forming a ‘line-management’ structure for grouping of disciplines. The structure needs to follow the Product Breakdown Structure (PBS) so that the Work Breakdown Structure (WBS) does not inherit artificial organizational interfaces caused by resource silos. There is usually resistance to significant re-arrangement of the ‘deck-chairs’ within a company; however, the businesses that can foster this adaptive and flexible culture can remain current, relevant, and innovative, which in today’s disruptive environment translates to growth.
Concerning the lifecycle delivery processes, the approach needs to follow a similar logic whereby a single coherent set of processes is adopted that matches the work to be undertaken. It is extremely important that the processes do not get associated with any discreet element of the organization; otherwise, responsibility and accountability become diluted and finger-pointing arises. A common example is the PM delegating responsibility for system reviews to the engineering team because they are associated with ‘engineering reviews’. Even if the entire scope of the system review is technical in nature, the intent of the review is to establish a project maturity level and residual risk to carry forward, so it will always require the entire team’s involvement and will impact every element of the PM Knowledge Areas.
Therefore, achieving a fully integrated approach requires breaking down the mindsets associated with decades of standards adoption, and establishing an integrated organization structured to optimally achieve the outcome, and working to a single cohesive lifecycle delivery process tailored to suit the level of complexity, as well as balancing the totality of risk in a collaborative manner with ownership specifically where the risk can be effectively controlled and mitigated. If working within constraints of large inflexible organization constructs and rigid customer contractual obligations, then the bare minimum is to ensure elimination of silos, an unwavering focus on the outcome (i.e., the capability required) and avoidance of compliance thinking to permit sufficient cross-pollination of the PM and SE principles to avoid ‘unproductive tension’.
References
Boehm, Barry, Ricardo. Valerdi, and Eric Honour. 2008. “The ROI of Systems Engineering: Some Quantitative Results for Software-Intensive Systems.” Systems Engineering, Volume 11, Issue 3 (Fall 2008), pp. 221-234. Available at https://onlinelibrary.wiley.com/doi/10.1002/sys.20096.
Conforto, Edivandro, Monica Rossi, Eric Rebentisch, Joseph Oehman, and Mari Pacenza. (2013). “Improving the Integration of Program Management and Systems Engineering”. Whitepaper presented at the 23rd INCOSE Annual International Symposium, Philadelphia, USA, June 2013. Available at https://dspace.mit.edu/bitstream/handle/1721.1/79681/Conforto%20et%20al%202013%20-%20PMI%20INCOSE%20MIT%20Survey%20on%20Integration%20of%20Program%20Management%20and%20Systems%20Engineering.pdf?sequence=1.
Elm, Joseph P. and Dennis R. Goldenson, “The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey”. Special Report, CMU/SEI-2012-SR-009 (November 2012). Available at https://resources.sei.cmu.edu/asset_files/SpecialReport/2012_003_001_34067.pdf.
Honour, Eric. 2003. “Toward An Understanding of the Value of Systems Engineering.” Proceedings of the First Annual Conference on Systems Integration, Stevens Institute of Technology, March 2003, Hoboken, NJ, USA. Available at https://www.bing.com/search?q=Honour,+E.C.+%E2%80%9CToward+Understanding+the+Value+of+Systems+Engineering&src=IE-SearchBox&FORM=IESR4A&pc=EUPP_UE04.
Honour, Eric. “Understanding the Value of Systems Engineering,” INCOSE International Symposium, Toulouse, France, June 20-24, 2004. Volume14, Issue1. Available at https://onlinelibrary.wiley.com/doi/pdf/10.1002/j.2334-5837.2004.tb00567.x.
Langley, Mark, Samantha Robitaille, and John Thomas. (2011). “Toward a new mindset: bridging the gap between program management and systems engineering”. Paper presented at PMI® Global Congress 2011—North America, Dallas, TX. Newtown Square, PA: Project Management Institute. Available at https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213.
Rebentisch, Eric, Editor-in-Chief. (2017). Integrating Program Management and Systems Engineering – Methods, Tools, and Organizational Systems for Improving Performance. Hoboken, New Jersey USA: John Wiley & Sons. Available at https://www.amazon.com/Integrating-Program-Management-Systems-Engineering/dp/1119258928/ref=sr_1_2?s=books&ie=UTF8&qid=1541851462&sr=1-2&keywords=rebentisch.
Shenhar, Aaron and Dov Dvir. (2004). Project management evolution: past history and future research directions. Paper presented at PMI® Research Conference: Innovations, London, England. Newtown Square, PA: Project Management Institute. Available at https://www.pmi.org/learning/library/project-management-evolution-research-directions-8348.
Steward, David (Parsons Brinckerhoff Ltd) 21st January 2009 INCOSE UK Rail Interest Group. Available at http://www.incoseonline.org.uk/Documents/Groups/Railway/RIG_0901_January.pdf.
About the Author
Martin has over 20 years’ experience in engineering design and management, with the recent 10 years specifically within the Maritime Defense sector. He has eight years’ experience as an Executive Engineering Manager and is a discipline specialist in Systems Integration Engineering, Maritime and Mechanical Engineering, RAM Analysis, Safety Cases, and Risk and Issue Management. Martin is experienced in the successful delivery of complex engineering systems and services within Technical Regulatory Frameworks in the defense sector.
Martin has worked in project management capacities as well as engineering management, and has led organizational change initiatives to maximize the effectiveness of delivery. Through the 2009 Defense Strategic Reform Program, he molded a functionally based engineering group into a LEAN project delivery team operating across individually tailored Systems Engineering upgrades, to halve the cost base of the organization. More recently, he led the restructuring of engineering disciplines into multi-domain delivery cells that are able to operate across multiple support contracts utilizing unique system engineering process models.
4. Systems Engineering News
4.1 INCOSE 2018 Election Results
The Nominations & Election Committee has announced the results of the 2018 election. These individuals will join the INCOSE Board of Directors on Saturday, 26 January 2019 when they are installed during the opening plenary of the 2019 International Workshop in Torrance, California.
Position (Term of Office)
- Secretary (2 years): Kayla Marshall
- Director for Marketing and Communication (3 years): Lisa Hoverman
- Director for Americas (3 years): Tony Williams
4.2 INCOSE Conducting 4th Study On
the
Current State of MBSE Adoption
In preparation for the upcoming INCOSE International Workshop in January 2019, the Model Based Systems Engineering (MBSE) community is asking for your support in providing information regarding the current state of MBSE adoption across systems engineering practitioners and companies performing systems engineering. The survey is the 4th occurrence of this longitudinal study meant to understand the adoption of “formal” modeling within the Industrial and Systems Engineering communities. The survey will be open for responses from December 6, 2018 – December 28, 2018.
The survey can be found at: https://www.surveymonkey.com/r/WV69WH2
This QR Code will also take you to the survey:
 |
There are 12 questions in the survey and it is expected to take less than 15 minutes to complete. Questions with an “*” next to the question number are required to be answered.
As in the past surveys, the sources and individual answers will be protected, and the raw data will ONLY be seen by Dr. R. Cloutier and his research assistant. The results of the survey will be presented as part of the MBSE Workshop to be held at the IW in January 2019. If you would like a copy of the report, be sure to complete Question 1 of the survey.
4.3 7 Habits of Highly Effective NASA Systems Engineers
On the 20th September 2018, NASA launched a pre-recorded 90-minute video as part of the Virtual Project Management Challenge that discusses the 7 Habits of Highly Effective (NASA) Systems Engineers. The habits were identified through an informal poll of the Virtual Project Management Challenge subscribers.
The habits discussed are:
- Communicates Effectively
- Thinks Broadly
- Builds Team Cohesion
- Stays Mission-Focused
- Asks Good Questions
- Remains Open-Minded
- Sees in Multiple Dimensions
For each habit, a presenter (who is a NASA systems engineer) discusses how they practice the habit in the course of doing their work, how they learned to become proficient in the habit, what engineers tend to get wrong regarding the habit and finally, general advice for engineers seeking to become system engineers.
The full video is available here.
4.4 Pohl Inducted as Fellow of Engineering Management Society
Ed Pohl, left, with Paul Kaufman, executive director of the
American Society for Engineering Management.
Ed Pohl, professor and head of the department of industrial engineering, has been awarded the title of Fellow by the American Society for Engineering Management. The award was presented at the society’s 2018 International Annual Conference in Coeur d’Alene, Idaho.
New Fellows are chosen by existing Society Fellows. Candidates must have eight years of continuous membership in ASEM with significant service, demonstrated engineering management success and continuing distinguished service and contributions to the Society. No more than five Fellows are elected in a year.
Pohl holds the Twenty-First Century Professorship in Engineering. He has served as the director of the Master of Science in Operations Management online degree program and has led several risk- and supply-chain-related research efforts at the University of Arkansas.
Before coming to Arkansas, Ed spent 21 years in the United States Air Force, where he served in a variety of engineering, operations analysis and academic positions during his career. Previous assignments include serving as deputy director of the Operations Research Center at the United States Military Academy, as an operations analyst in the Office of the Secretary of Defense, as a munitions logistics manager at the Air Force Operational Test Center, and as a B-2 training systems engineer.
Pohl earned his Ph.D. in systems and industrial engineering from the University of Arizona. He holds an M.S. in systems engineering from the Air Force Institute of Technology, an M.S. in reliability engineering from the University of Arizona, an M.S. in engineering management from the University of Dayton and a B.S. in electrical engineering from Boston University.
His primary research interests are in risk, reliability, engineering optimization, healthcare and supply chain risk analysis, decision making, and quality. Pohl is a Certified Professional Engineering Manager. He is a Fellow of the Institute of Industrial and Systems Engineers, ASEM, and the Society of Reliability Engineers. He is a Senior Member of the Institute of Electrical and Electronics Engineers, and the American Society for Quality. He is also a Diplomate in the Society of Health Systems, a member of the International Council on Systems Engineering, the Institute for Operations Research and the Management Sciences, and the Association for Health Care Resource & Materials Management.
4.5 Cyber Education Must Address Systems Engineering
Cybersecurity training and education programs need to emphasize systems engineering perspectives in order to fully understand system vulnerabilities, said leaders from the National Institute of Standards and Technology (NIST) during an October 10 webinar hosted by the agency’s National Initiative for Cybersecurity Education (NICE).
“One of our key problems is how do we build systems we can actually trust,” said Ron Ross, a NIST Fellow who focuses on cybersecurity, systems security engineering, security architecture, privacy, and risk management. “Our systems are literally being pushed to the edge today,” he said.
Ross discussed how computing has become more complex as more applications emerge and systems connect to physical systems. “One of the things we’re trying to deal with is, how do we understand what’s going on, and it could be your computer, your smartphone, your tablet, but in that black box,” he said, adding, “You can never deal with complexity unless you attack it from a systems engineering perspective.”
Ross illustrated the difference between the concepts with an analogy about how bridges and airplanes are built.
“The reason that bridges don’t collapse and airplanes don’t crash very often is because we start with good science and engineering, and then we bring in good materials, and we have good people that know how to put those things together,” he said. “In the world of bridge builders and airplane builders, it’s all about the keywords of equilibrium, static and dynamic loads, vibrations, and resonance. Those are all grounded in physics and mathematics, and we have to be able to do the same thing with our software and our systems.”
But, he added, “We really aren’t doing as much of that as we need to.”
Carol Woody, principal researcher at the Software Engineering Institute and technical manager of the US-CERT Cybersecurity Engineering Team, emphasized the need for software assurance education to improve cybersecurity, and she touted the free course materials developed by her organization on the topic.
4.6 Object Management Group Issues Request for Proposals for CubeSat System Reference Model
The Object Management Group® (OMG®), an international, open membership, not-for-profit technology standards consortium, has issued the CubeSat System Reference Model (CSRM) RFP. The RFP solicits proposals to standardize CubeSat development based on the OMG Systems Modeling Language™ (SysML®) to lower the cost of development and increase the quality of CubeSat spacecraft and ground system design.
5. Featured Organizations
5.1 Systems Engineering Group
National Institute of Standards and Technology, (NIST)
USA
The Systems Engineering Group at the National Institute of Standards and Technology (NIST) USA develops, advances, and deploys measurement science to address application of engineering information systems to complex cyber-physical systems; carries out mission-related measurement science research and services to advance application of systems integration and engineering to complex cyber-physical systems; develops systems requirements, traceability, optimization, trade-offs, and performs risk analysis.
5.2 System Dynamics Society Launches Autumn Issue of
e-Newsletter
On 8 November, the System Dynamics Society announced the launch of their Autumn Issue of the Society e-Newsletter including the following SD society-related topics:
- An Interview with the Executive Director: Q&A
- Did You Know? Presidential Thoughts
- Your Member Benefits
- Move Complete
The issue is available here.
5.3 Body of Knowledge and Curriculum to Advance Systems Engineering
The Body of Knowledge and Curriculum to Advance Systems Engineering Project (BKCASE), began in the fall of 2009. Its original vision was that, through its work “Systems engineering competency models, certification programs, textbooks, graduate programs, and related workforce development initiatives around the world align with BKCASE.”
By continuing to work towards aligning technical initiative and research, competency models, certification programs, textbooks, standards and guides, graduate programs, and related workforce development initiatives around the world to BKCASE our sponsors can enhance their ability to:
- Share, use, evolve and co-create value from that knowledge with their stakeholders.
- Providing a framework for the education, development and recognition of all those involved in the professional practice of Systems Engineering.
- Better describe the place Systems Engineering holds in complex problem resolution and thus shape and grow that role.
5.4 ABET
ABET is a nonprofit, non-governmental organization that accredits USA college and university programs in applied and natural science, computing, engineering, and engineering technology. ABET’s purpose is to assure confidence in USA university programs in STEM (science, technology, engineering and mathematics) disciplines. “Our approach, the standards we set and the quality we guarantee inspire confidence in those who aim to build a better world—one that is safer, more efficient, comfortable, and sustainable.”
6. News on Software Tools Supporting Systems Engineering
6.1 Cradle 7.4.1
by
Alwyn Smit
Principal Consultant & Course Presenter
Project Performance International (PPI)
Email: asmit@ppi-int.com
Cradle® is a requirements management and systems engineering software tool by 3SL in the UK.
Cradle version 7.4.1 has been released in October and is now also available as Software as a Service (SAAS) subscription where you choose the Cradle features required, the number of users to be supported, and how long you want to use Cradle.
Some of the product range highlights include:
- Applies to agile and phase projects
- Application life cycle management
- Requirements management
- Modelling / MBSE / SYSML / UML
- Full life cycle integration
- V&V
- Reporting
- Document publishing
- Metrics
- Dashboards
- Project plans
- User-defined UIS
- Custom web UIS
- Configuration management
- Single-user and Multi-user
7. Systems Engineering Publications
7.1 The Paradoxical Mindset of Systems Engineers:
Uncommon Minds, Skills, and Careers
(Wiley Series in Systems Engineering and Management)
by
Arthur Pyster, Nicole Hutchison and Devanandham Henry
From the Back Cover:
A guide that explores what enables systems engineers to be effective and reveals how organizations can help them be successful.
The Paradoxical Mindset of Systems Engineers offers an in-depth look at the proficiencies and personal qualities of effective systems engineers and the positions they should seek for successful careers. The book also gives employers practical strategies and tools to evaluate their systems engineers and improve their performance. The authors explore why systems engineers are uncommon and how they can assess, improve, and leverage their uncommon strengths. These insights for being an ever more effective systems engineer apply equally well to classic engineers and project managers who secondarily do some systems engineering.
The authors have written a guide to help systems engineers embrace the values that are most important to themselves and their organizations. Solidly based on interviews with over 350 systems engineers, classic engineers, and managers as well as detailed written career descriptions from 2500 systems engineers—The Paradoxical Mindset of Systems Engineers identifies behavioral patterns that effective systems engineers use to succeed. This important resource:
- Offers aspiring systems engineers practical methods for success that are built on extensive empirical evidence and underlying theory.
- Shows systems engineers how to visually document their relative strengths and weaknesses, map out their careers, and compare themselves to the best in their organizations – a rich set of tools for individuals, mentors, and organizations.
- Offers practical guidance to managers and executives who lead systems engineering workforce improvement initiatives.
Written for systems engineers and their managers, The Paradoxical Mindset of Systems Engineers offers the most comprehensive career guidance in the field that is available today.
Format: Kindle, Hardcover
Publisher: John Wiley & Sons; 1st edition (July 27, 2018)
ASIN: B07FZDKZNP
ISBN-13: 978-1119412144
ISBN-10: 1119412145
7.2 Career Architect Development Planner, 5th edition
by
Michael M. Lombardo and Robert W. Eichinger
From a review on Amazon.com:
This reference has been incredibly helpful to me both in charting my professional growth as well as in helping those working in my department with suggested actions for professional growth in specific areas.
The book identifies professional competences and defines what each skill ‘looks like’ when you are unskilled or skilled, and even defines overuse which is very helpful. I’ve used these definitions when preparing annual review evaluations because they are wonderfully descriptive.
This tool suggests multiple short and long-term strategies for development of each competency. Great book!
Format: Paperback
Publisher: Lominger; 5th edition (2010)
ISBN:
ISBN-10: 193357822X
ISBN-13: 978-1933578224
7.3 Systems Research and Behavioral Science
Systemic Innovation for a Thrivable Future: Selected papers from the 5th Behavioral Science Lab Symposium 2018, July/August 2018
Edited by
M. C. Jackson OBE
Online ISSN: 1099-1743
© John Wiley & Sons Ltd
Latest Issue: Volume 35, Issue 4
Included articles:
- “The Value Paradox of Problem Structuring Methods” by Patrick Tully, Leroy White, and Mike Yearworth
First published: 2 October 2018
- “The Unfolding and Resurfacing of Information Systems Knowledge over the Last 25 Years: A Systemic Perspective” by José‐Rodrigo, Córdoba‐Pachón and Alberto Paucar‐Caceres
First published: 2 October 2018
7.4 Extreme Training
by
Amy C. Edmondson and Jean-François Harvey
From the Amazon Website:
Today’s global enterprises increasingly involve collaborative work by teams of experts operating across different professions, organizations, and industries. Extreme Teaming provides new insights into the world of complex, cross industry projects and the ways they must be managed.
Leading experts Amy Edmondson and Jean-François Harvey analyze contemporary cases that expose the complex demands of cross-boundary collaboration on management, and inform our understanding of teams. Containing powerful insights and practical guidelines that allow managers to bridge professional divides and organizational boundaries in order to work together effectively, this is a new exploration of the challenges involved in today’s global enterprises.
The authors demonstrate that the work done in the modern organization is less and less about looking inward and creating strong teams inside the company, and more about teaming across boundaries – that often are in flux.
Extreme Teaming is a must-read book for all courses related to leading open innovation; teamwork and collaboration; project management; and cross-boundary work.
Format: Hardcover, Kindle
Publisher: Emerald Group Publishing Limited (September 26, 2017)
ISBN
ISBN-10: 1786354500
ISBN-13: 978-1786354501
7.5 The Design and Engineering of Curiosity:
How the Mars Rover Performs its Job
by
Emily Lakdawalla is an internationally admired science communicator and educator, passionate about advancing public understanding of space and sharing the wonder of scientific discovery.
She is Senior Editor and Planetary Evangelist for The Planetary Society. The Society was founded by Carl Sagan in 1980 and is currently run by Bill Nye. Emily has been writing and editing the Planetary Society Blog since 2005, reporting on space news, explaining planetary science, and sharing beautiful space photos. Emily has been an active supporter of the international community of space image processing enthusiasts as Administrator of the forum UnmannedSpaceflight.com since 2005. She is also a contributing editor to Sky & Telescope magazine.
From the Amazon Website:
This book describes the most complex machine ever sent to another planet: Curiosity. It is a one-ton robot with two brains, seventeen cameras, six wheels, nuclear power, and a laser beam on its head. No one human understands how all of its systems and instruments work. This essential reference to the Curiosity mission explains the engineering behind every system on the rover, from its rocket-powered jetpack to its radioisotope thermoelectric generator to its fiendishly complex sample handling system. Its lavishly illustrated text explains how all the instruments work — its cameras, spectrometers, sample-cooking oven, and weather station — and describes the instruments’ abilities and limitations. It tells you how the systems have functioned on Mars, and how scientists and engineers have worked around problems developed on a faraway planet: holey wheels and broken focus lasers. And it explains the grueling mission operations schedule that keeps the rover working day in and day out.
Format: Kindle, Paperback
Publisher: Springer; 1st ed. 2018 edition (March 28, 2018)
ISBN
ISBN-10: 3319681443
ISBN-13: 978-3319681443
7.6 International Space Station:
Architecture Beyond Earth
by
From the Amazon Website:
A history of the International Space Station, through the lens of its architectural design, perfect for space enthusiasts, as well as anyone with an interest in challenging architectural problem-solving. “If you are a space fan, fascinated by the kind of venture the International Space Station represents, this book is an absolute must, full of juicy details and intriguing insights.” – Popular Science, March 2016.
In 1984 President Ronald Reagan gave NASA the go-ahead to build a Space Station. A generation later, the International Space Station is an established and highly successful research center in Earth’s orbit. The history of this extraordinary project is a complex weave of powerful threads – political, diplomatic, financial and technological among them – but none is more fascinating than the story of its design. This book provides the first comprehensive account of the International Space Station s conception, development and assembly in space. As a highly accessible chronicle of a complex piece of design and engineering, it will appeal to readers far beyond the space field. NASA Astronaut Nicole Stott, a veteran of International Space Station Expeditions 20 and 21 and Shuttle Missions STS-128, STS-129 and STS-133, introduces the book with a personal memoir: A Home in Space.
Format: Hardcover
Publisher: Circa Press (April 1, 2017)
ISBN
ISBN-10: 0993072135
ISBN-13: 978-0993072130
7.7 Discover Quality Requirements with the Mini-QAW
by
Thijmen de Gooijer, Michael Keeling, and Will Chaparro
in
Requirements Engineering Magazine
The Magazine for RE Professionals from the International Requirements Engineering Board (IREB)
Abstract
Collecting requirements is not easy. The Quality Attribute Workshop (QAW) helps teams effectively gather quality requirements, but it can be costly and cumbersome to organize. The mini-QAW is a short (a few hours to a full day) workshop designed for inexperienced facilitators and is a great fit for Agile teams. The shortened agenda and visual tools that are used in the workshop mean that a fair number of quality requirements can be found in half a day or less. The mini-QAW webpage for materials to run a workshop can be found here.
About the Author
Thijmen works as IT architect at Kommuninvest, acting as technical lead for its digitalization initiative and growing CI/CD and Agile practice in the company. His work on the mini-QAW started in his role as researcher at ABB, where he worked on software architectures with colleagues around the globe. He authored publications at leading international software conferences, receiving two best paper awards. Thijmen graduated cum-laude in software engineering from VU University in the Netherlands and Malardalen University in Sweden.
7.8 Requirements for Devices Around Us: Embedded Systems and the Internet of Things
by
Karl Wiegers
“Internet of Things” refers to the network of such devices that are interconnected and integrated to exchange data and services. Embedded and other real-time systems contain sensors, controllers, motors, power supplies, integrated circuits, displays, and other mechanical, electrical, and electronic components that operate under software control. This article discusses some of the requirements issues that are especially important to embedded and other real-time systems.
More Information
7.9 Guidelines for Drawing Causal Loop Diagrams
by
Daniel H. Kim
The Systems Thinker, Vol 3, No 1, pp5-6 (Feb 1992).
Causal loops diagrams are used to display the behavior of cause and effect from systems standpoint. This guideline written by Daniel H. Kim outlines the steps for creating useful causal loop diagrams.
“Causal loop diagrams provide a language for articulating our understanding of the dynamic, interconnected nature of our world. We can think of them as sentences which are constructed by linking together key variables and indicating the causal relationships between them. By stringing together several loops, we can create a coherent story about a particular problem or issue.”
8. Education and Academia
8.1 Online Engineering Programs at Pennsylvania State University USA
Engineering and technology drive the changes and innovation taking place in every segment of society, including banking, manufacturing, medicine, aerospace, and defense. To be at the forefront of those changes and to have a competitive advantage over others, one needs the knowledge and skills that employers demand. Penn State now offers a set of online engineering programs so that obtaining an engineering degree, and demonstrating knowledge and skills sought after by employers, is more convenient and more accessible. The engineering programs offered online include:
- Electrical Engineering (Master of Engineering)
- Engineering Management (Master’s Degree)
- Engineering Leadership and Innovation Management (Graduate Certificate)
- Mechanical Engineering (Master of Science)
- Nuclear Engineering (Master of Engineering)
- Software Engineering (Master’s Degree)
- Software Engineering (Bachelor of Science)
- Systems Engineering (Master of Engineering)
8.2 The Dassault Systèmes U.S. Foundation Expands Grant to Base 11 Autonomous Systems Engineering Academy
Innovative STEM curriculum to be adapted as a full semester course during Academic Year 2018/19
COSTA MESA, Calif. & WALTHAM, Mass
October 11, 2018
Base 11 and the Dassault Systèmes (Paris: DSY) U.S. Foundation have announced the expansion of the workforce development initiative aimed at training the next generation of engineers with the skills to succeed in the aerospace, technology, transportation and mobility industries.
The nonprofit Base 11 will introduce the Autonomous Systems Engineering Academy (ASEA) as a full semester course comprised of 200 hours of lecture, lab and homework in the Academic Year 2018/19 at Skyline College in Northern California; Compton College and Cerritos College in Southern California; and South Mountain Community College in Phoenix, Arizona.
“Thanks to our partners at the Dassault Systems U.S. Foundation, community college students from three critical regions of the country will have access to hands-on, project-based learning experiences designed to develop both the mindset and the skills most in demand by industry,” said Landon Taylor, CEO of Base 11. “We’re bringing industry together in partnership with academia and philanthropy to develop a highly skilled, diverse workforce prepared for the jobs of the 21st Century.”
This pre-engineering, project-based learning program is geared towards high-potential, low-resource community college students. The targeted outcome of the program is an industry-sponsored drone design competition among teams of students from each college, which challenges the teams to learn and demonstrate the mindset, competencies, and teamwork that will make them highly attractive as both a prospective four-year engineering school transfer student and/or a prospective new hire with employers of their choice.
“The Dassault Systems U.S. Foundation is very pleased to support Base 11 as it expands into the classroom and gives more students the opportunity to participate in hands-on STEM learning initiatives,” said Al Bunshaft, President, the Dassault Systèmes U.S. Foundation.
The Autonomous Systems Engineering Academy began as highly successful freshman course at the Samueli School of Engineering at University of California, Irvine. Base 11 then collaborated with UCI to adapt the course into an intensive summer program for community college students, and later into a high school curriculum that was piloted in Philadelphia. The semester-long college course ASEA was successfully piloted as a summer course at UCI in 2017 and introduced at Skyline College as an experimental course in Spring 2018. Base 11 has plans to implement the course at six additional community colleges in California and Washington in 2019.
About Base 11
Base 11 is a nonprofit workforce development accelerator focused on solving the STEM talent pipeline crisis being fueled by the underrepresentation of women and minorities. Base 11 facilitates partnerships with industry, academia and philanthropy which deliver to employers a pre-recruitment pipeline of well-trained, highly skilled STEM talent. By establishing Innovation Centers integrated with hands-on project based learning and STEM entrepreneurship training, Base 11 and its partners set students on direct pathways to four-year STEM degrees, well paid STEM jobs, and the opportunity to launch their own STEM related business.
For more information: www.Base11.com. Base 11 is a DBA of the Center for Innovations in Education, a nonprofit 501(c) 3 – IRS exemption EIN# 26-4365936.
About La Fondation Dassault Systèmes
La Fondation Dassault Systèmes provides grants, training and expertise about 3D virtual universe technologies to help schools, universities, research centers, museums and associations in Europe, the U.S. and India to push the limits of knowledge. Its mission is to inspire young people with a passion for engineering, science and digital technology to create a better and more collaborative society. As part of this mission, it actively contributes to inventing new ways of sharing know-how and transforming learning practices that make it possible to detect new talents and help them achieve their dreams. For more information: lafondation3ds.org
8.3 Stevens Institute of Technology
School of Systems and Enterprises
The School of Systems and Enterprises (SSE) offers undergraduate and graduate degree programs that integrate education and research. SSE combines programs in software engineering, systems analytics, engineering management, and industrial and systems engineering with the extensive resources of a major research university. Stevens states that students receive an education that combines academic study and cutting-edge research with innovative opportunities, entrepreneurial thinking, and the support and intellectual stimulation of a diverse campus community.
The SSE learning experience embodies the spirit of an interdisciplinary approach. Stevens feels that the learning experience equips engineers with leadership skills and technical acumen, enabling them to contribute to effect transformative change. The School of Systems and Enterprises is also home to the Systems Engineering Research Center (SERC), a University-Affiliated Research Center of the U.S. Department of Defense. Led by Stevens Institute of Technology, SERC leverages the research and expertise of senior lead researchers from 22 collaborator universities throughout the United States.
8.4 UVA Engineering Launches Department of Engineering Systems and Environment
by
Email: emather@virginia.edu
Responding to a need for engineers trained to help solve the complex, global problems of the 21st century, the University of Virginia School of Engineering has launched a new department: Engineering Systems and Environment.
The new department unites students, faculty and staff from UVA’s civil, environmental and systems engineering disciplines – formerly split into two separate departments – for a collaborative and whole-system approach to modern challenges ranging from smart cities to environmental resilience to health care. The department is the new home for the existing graduate and undergraduate degree programs in civil and systems engineering.
The State Council of Higher Education for Virginia approved the new department earlier this month, the first for UVA Engineering in more than 40 years.
8.5 Tufts to Offer Master’s Degree in Sustainability
by
Laura Ferguson
Email: laura.ferguson@tufts.edu
Figure 1: The rooftop of Sophia Gordon Hall.
Photo: Tufts University
Sustainability is “about making decisions now that don’t compromise the ability of future generations to meet their own needs and wants,” said Ann Rappaport of Tufts University. Tufts University is a private research university in Medford, Massachusetts, USA.
Tufts has announced a new graduate program as part of its commitment to building a more sustainable and equitable planet. The Masters of Science in Sustainability, offered by the Department of Urban and Environmental Policy and Planning (UEP), will begin in fall 2019.
Ann Rappaport, EG92, UEP faculty member and co-chair of the university’s Sustainability Council, said the program recognizes the urgent and increasing need for sustainability experts to ensure a healthy, livable planet.
“More and more businesses, communities, and organizations recognize the importance of building resilience and sustainability—and a commitment to equity and social justice—into who they are and what they do,” she said. “Sustainability professionals can help them take that longer view.”
“We know that reactive responses to crises, or to resource scarcity, work only in the short-term,” she added. “The core ideas of sustainability guide actions with future generations in mind—and not simply thirty or forty years ahead. We need to get everybody engaged in this kind of long term thinking, and with programs emerging at Tufts and across the country, we can make progress.”
The multidisciplinary Tufts program can be completed in a year by full-time students and allows students to connect their sustainability studies to their interest in fields such as economics, biology, and public health.
The program differentiates itself through its commitment to social justice and by being housed within UEP, which was established 45 years ago and has graduates in government, nonprofit organizations, citizen advocacy groups, international NGOs, and the private sector.
Existing UEP programs, such as the interdisciplinary M.S. in Environmental Economics and Urban Planning, have long recognized the importance of quantitative and analytical skills to address complex environmental challenges, said Rappaport. Three new courses for the new master’s degree will include those perspectives: Socio-ecological Systems Thinking for Sustainability, Sustainability Analytics, and Sustainability Metrics and Decision Tools.
“You can define sustainability as a concept fairly easily. It’s about making decisions now that don’t compromise the ability of future generations to meet their own needs and wants,” said Rappaport. “But it’s much more difficult to operationalize. We need to give our students the tools and skills to be articulate and be knowledgeable about solutions that may not be popular, but that are grounded in solid research and metrics.”
The program comes about as sustainability becomes more important worldwide, with mounting awareness about the long-term ecological consequences of pollution and non-biodegradable waste, said Rappaport. She cited how, for instance, Lego is looking for new ways to design blocks without using plastic and how the United Nations is calling for a sustainability agenda.
The thirty-six-credit program is designed for full-time completion in twelve months, although students may also pursue the program part-time. Most core courses and electives build on extensive offerings within UEP, but the program will also encompass sustainability related courses throughout the School of Arts and Sciences and the School of Engineering.
Students can pursue a sustainability solutions approach or a natural systems emphasis or craft a program that includes elements of both.
The sustainability solutions model favors green design, governance and policy, humanities, natural resources, sustainability, business, project management, social research, public communication, anticipatory thinking, and literature research. The natural systems plan focuses on natural sciences, ecology, interdisciplinary communication, analysis, and field research.
The program complements other sustainability-related programs offered at Tufts. They include a Master of Science in Sustainable Water Management, offered through the Tufts Institute of the Environment; a Certificate of Advanced Graduate Study in Urban Justice and Sustainability (a post-master’s program for working professionals); an online graduate certificate in Sustainable Agriculture and Food Systems at the Friedman School of Nutrition Science and Policy, and a joint master’s degree offered by UEP and the Department of Civil and Environmental Engineering at the School of Engineering.
9. Some Systems Engineering-Relevant Websites
STEM on Station
This website provides STEM education content related to the International Space Station. The website contains ideas to bring space into the classroom with lesson plans, videos and up-to-the minute education news. The website contains opportunities to connect to the space station and highlight research conducted onboard in addition to other great resources.
https://www.nasa.gov/audience/foreducators/stem_on_station/index.html
Systems Engineering with System Models
A link to an hour-long introductory video on Model-Based Systems Engineering (MBSE) including industry definitions, the motivation for MBSE, what constitutes a system model and what the benefits are of maintaining a system model. The module briefly introduces SysML but only to convey the ideas underpinning MBSE.
https://www.youtube.com/watch?v=171blNCgpCo
Tech Career Profile: Systems Engineer – The Balance Careers
An in-depth look at what it takes to become a Systems Engineer, including job responsibilities, desired skills, and more.
https://www.thebalancecareers.com/tech-career-profile-systems-engineer-2071298
10. Standards and Guides
10.1 Object Management Group Chairs Report on Future
Standards Initiatives
NEEDHAM, Mass. (PRWEB) October 10, 2018
Chairs of the Object Management Group® (OMG®) Task Forces (TFs) and Special Interest Groups (SIGs) presented updates about their standards work during a plenary session on the last day of the OMG quarterly membership meeting, which took place from September 24-28 in Ottawa, Canada. At the meeting, the OMG board of directors adopted four new specifications and five updated specifications, while the Platform and Domain Task Forces issued six RFPs, two RFIs and one RFC. OMG is an international, open membership, not-for-profit technology standards consortium where members develop and maintain standards that influence the future direction of technology as well as industries including space, government, finance, manufacturing, robotics, retail and healthcare.
The following Chairs reported on their groups’ accomplishments:
- Claude Baudoin, co-chair of the Business Modeling & Integration Domain Task Force (BMI DTF) and owner and principal consultant at cébé IT and Knowledge Management: “The BMI DTF made significant progress toward enabling the joint modeling of BPMN™ (processes), CMMN™ (cases) and DMN™ (decisions) by users, through an upcoming white paper and an RFP for a metamodel of the common elements across those three complementary specifications.”
- Cory Casanave, co-chair of the Government Domain Task Force and president of Model Driven Solutions: “The OMG Government Domain Task Force planned a revision of NIEM™-UML® to comply with the NIEM PMO’s 4.1 release.”
- Tadashi Furuhata, co-chair of the WS-POS Version 1.3.1 Finalization Task Force and web application system architect at Seiko Epson Corporation: “The UPOSVer.1.16 Retail Communication Service Device RFP was issued, which seeks to define the interface between the UnifiedPOS standard and a robotic device.”
- Uwe Kaufmann, co-chair of the Manufacturing Technology and Industrial Systems Domain Task Force (ManTIS DTF) and CEO at Model Alchemy Consulting: “ManTIS DTF recommended the Simple Electronic Notation for Sensor Reporting (SENSR) RFP and voted Christian Muggeo (CONTACT Software) as new co-chair.”
- Brad Kizzort, co-chair of the Space Domain Task Force (DTF) and chief technologist at Harris Corporation: “The Space DTF published a Request for Proposals for a CubeSat System Reference Model in SysML® to provide a template for Model-Based Systems Engineering of CubeSat missions.”
- Jim Logan, co-chair of the Analysis and Design Platform Task Force (ADTF) and principal architect at No Magic, Inc.: “The ADTF recommended issuance of the MARTE 2.0 RFI. This RFI seek inputs from the community in which MARTE is used to account for new design and analysis techniques that have emerged since the inception of UML Profile for MARTE™ 12 years ago.”
- Bart McGlothin, chair of the Retail Domain Task Force and solution architect at Cisco: “Retail was rocking with another outstanding and productive meeting including two new RFPs issued: Fiscal API service and a Retail Communications Service Device (Robots in Retail) for Unified POS, and completing the FTF for Video Analytics!”
- Gerardo Pardo-Castellote, co-chair of the Data-Distribution Service™ (DDS™) Platform Special Interest Group (SIG) and CTO of Real-Time Innovations: “A new RFP to deploy DDS™ on Time-Sensitive Networks (TSN) was issued. The SIG also presented an overview of DDS at the special event “Standards for the Federal & Provincial Governments of Canada.”
- Charlotte Wales, co-chair of the Middleware and Related Services (MARS) PTF and Lead Software Engineer at The MITRE Corporation: “The MARS TF started a new technology process (issued an RFP) to extend the existing family of DDS specifications so DDS implementations can be deployed on and leverage Time Sensitive Network (TSN)-enabled networks and welcomed new member MicroFocus, who presented a solution for using CORBA® over web services.”
- Dennis E. Wisnosky, chair of the FIBO® Finalization Task Forces and EDMC, Senior Consultant – Head of FIBO Development: “The Financial Domain Task Force voted by “white ballot” to submit the Finance Industry Business Ontology® (FIBO) 2.0 spec to the OMG Architecture Board, which subsequently voted to release the spec for comment.”
To participate in OMG specifications, please visit https://www.omg.org/public_schedule/.
About OMG
The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium with representation from government, industry and academia. OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries. OMG modeling standards enable powerful visual design, execution and maintenance of software and other processes. Visit https://www.omg.org for more information.
11. Some Definitions to Close On
11.1 System Context Diagram
A System Context Diagram represents external entities that may interact with a system, via interfaces directly with the system, or indirectly with the system via an enveloping environment, and for which the interactions are relevant in some way. Such a diagram typically pictures the system at the center, with no details of its internal structure, surrounded by all its interacting entities. Items passing across a given interface in each direction (inputs and outputs) are associated with the interface via the context diagram.
The context diagram may alternatively be shown as an indented list. The system itself and interfacing entities may be tangible physical entities or may be abstractions such as software or databases. For the System Context Diagram to serve its purpose, the interfacing entities must not be functions, or attributes, or inputs/outputs, or stakeholders who simply have an interest in the system without interfacing with the system.
Source: Robert Halligan
12. Conferences and Meetings
For more information on systems engineering related conferences and meetings, please go to our website.
The featured conference for this edition is:
Annual Reliability and Maintainability Symposium
28 -31 January 2019, Orlando, FL
The Annual Reliability and Maintainability Symposium (RAMS®) is a yearly gathering of the product assurance disciplines where training, tutorials, and the latest technical practices, procedures, and results are presented in easy-to-utilize forums and proceedings. Now in its 63rd consecutive year, the RAMS® has consistently provided value for the “ilities” through published papers, informative tutorials, and excellent networking and product demonstrations. Coupled with the RAMS® Vendor trade show, RAMS® continues to be one of the most comprehensive gatherings of Product Assurance professionals available in today’s competitive business environment. The last day for getting the early registration rate for the conference is midnight (EST) December 23, 2018.
More information can be found on the conference website here.
13. PPI and CTI News
13.1 An Unconventional End of Year Party for PPI Melbourne Staff
What do PPI and street art have to do with each other? Nothing at all really except that our wonderful team at our Head Office in Melbourne was treated to a different kind of “End of Year Party”. They attended a walking tour in an edgy city fringe suburb of Melbourne, Fitzroy, where they were educated on the detail, skill and surprisingly high income to be earned in the art of…well…. “street art”. Some may view this as a form of vandalism and sure, as we saw, there was a lot of that. But around unexpected corners and up dingy alleys can be seen the loveliest and also the darkest kinds of art. This art is being viewed as iconic Melbourne more and more these days though most Melbournians drive past these elaborate paintings daily without taking much notice. The team thoroughly enjoyed exploring the weird and wonderful array of designs and streets and finished the day off with a very “American style burger” kind of dinner in a most unlikely setting, a decommissioned train carriage that was propped up amongst two other carriages on top of a building in Easey Street!
13.2 PPI Has a New INCOSE Corporate Advisory Rep
PPI’s René King has taken the baton from Alwyn Smit as PPI’s representative to the INCOSE Corporate Advisory Board. The INCOSE CAB is the Voice of the Customer to the INCOSE leadership. The CAB provides strategic guidance to INCOSE technical leadership, leading to the development of systems engineering products and standards to meet their needs. See https://www.incose.org/incose-member-resources/corporate-advisory-board
13.3 PPI Welcomes a New Systems Engineering Goldmine Assistance
PPI is pleased to welcome Kimberley Taylor as PPI’s new SE Goldmine Assistant. The role is to maintain and add content to the SE Goldmine. The Goldmine contains thousands of downloadable systems engineering-related documents that are searchable by description, title, date, source and keywords, together with definitions from various sources of 7,800+ defined terms. Kim will work alongside Senior Engineer, René King to ensure that documents and definitions added are valuable and easily searchable by Goldmine users.
Kim has a background in service and sales in the motor industry. Her interests include Brazilian Jiu-Jitsu and traveling. We look forward to having Kim onboard and to continuing the growth of the SE Goldmine in size and quality through her contribution.
All PPI and CTI course delegates receive unlimited access to the Goldmine. If you would like access to the Goldmine and have not taken a PPI or CTI course, you may apply for access here.
14. PPI and CTI Events
On-site systems engineering training is being delivered worldwide throughout the year. An overview of public courses is below. For a full public training course schedule, please visit https://www.ppi-int.com/course-schedule/
Systems Engineering 5-Day Courses
Upcoming locations include:
- Melbourne, Australia (P006-793)
11 Feb – 15 Feb 2019
- Stellenbosch, South Africa (P006-771)
1 – 5 Apr 2019
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
- Pretoria, South Africa (P007-474)
28 Jan – 01 Feb 2019
- London, United Kingdom (P007-491)
04 Mar – 08 Mar 2019
Systems Engineering Management 5-Day Courses
Upcoming locations include:
- Munich, Germany (P1135-159)
25 Feb – 1 Mar 2019
- Melbourne, Australia (P1135-169)
29 Apr – 3 May 2019
Note: Four more systems engineering management courses in the USA during 2019 are about to be announced. Watch for SyEN 73.
Systems Engineering Overview 3-Day Courses
Upcoming locations include:
- Pretoria, South Africa (P884-11)
23 Jan – 25 Jan 2019
Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses
Upcoming locations include:
- Melbourne, Australia (P958-57)
18 Feb – 22 Feb 2019
- Washington, D.C., United States of America (P958-59)
13 May – 17 May 2019
Engineering Successful Infrastructure Systems (ESIS5D)
Upcoming locations include:
- Detroit, MI, United States of America (P2005-1)
25 Mar – 29 Mar 2019
Architectural Design 5-Day Course
Upcoming locations include:
- Pretoria, South Africa (P1768-19)
06 May – 10 May 2019
CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)
Upcoming locations include:
San Francisco, CA, United States of America (C002-81)
11 Feb – 15 Feb 2019
Bristol, United Kingdom (C002-91)
04 Mar – 08 Mar 2019
Medical Device Risk Management 3-Day Course
Upcoming locations include:
- Boston, MA, United States of America
04 Feb- 06 Feb 2019
- Berlin, Germany
18 Mar – 20 Mar 2019
Other training courses available on-site only include:
- Project Risk and Opportunity Management 3-Day
- Managing Technical Projects 2-Day
- Integrated Product Teams 2-Day
- Software Engineering 5-Day.
15. Upcoming PPI Participation in Professional Conferences
PPI will be participating in the following upcoming events. We support the events that we are sponsoring and look forward to meeting old friends and making new friends at the events at which we will be exhibiting.
The INCOSE International Symposium 2019
(Exhibiting)
Date: 20-25 July, 2019
Location: Orlando, USA
(Exhibiting)
Date: 21-25 October, 2019
Location: Cleveland, USA
The INCOSE International Symposium 2020
(Exhibiting)
Date: 18-23 July, 2020
Location: Cape Town, South Africa
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com
Ralph Young, Editor, email: ryoung@ppi-int.com
René King, Managing Editor, email: rking@ppi-int.com
Project Performance International
2 Parkgate Drive, Ringwood, Vic 3134 Australia
Tel: +61 3 9876 7345
Fax: +61 3 9876 2664
Tel Brasil: +55 12 9 9780 3490
Tel UK: +44 20 3608 6754
Tel USA: +1 888 772 5174
Tel China: +86 188 5117 2867
Web: www.ppi-int.com
Email: contact@ppi-int.com
Copyright 2012-2018 Project Performance (Australia) Pty Ltd, trading as
Project Performance International.
Tell us what you think of PPI SyEN. Email us at syen@ppi-int.info.
- Corresponding author. ↑
- See Monat and Gannon, “What is Systems Thinking? A Review of Selected Literature plus Recommendations”. Available at http://article.sapub.org/10.5923.j.ajss.20150401.02.html. The authors point out that many systems engineers do not fully grasp Systems Thinking—many believe it is simply the fundamental concepts of Systems Engineering as articulated by Kossiakoff et al. and Blanchard and Fabrycky, comprising V-diagrams, risk management, needs analysis, architecture and design, integration and test, and project management. Systems engineers will be well served by digesting this article. The literature review includes 30 works considered to be key contributions to the understanding of systems thinking. The recommendations section identifies and integrates common themes of various definitions of systems thinking into a coherent definition: Systems thinking is 1) a perspective that recognizes systems as collections of components that are all interrelated and necessary, and whose inter–relationships are at least as important as the components themselves; 2) a language centered on the Iceberg Model, unintended consequences, causal loops, emergence, and system dynamics, and 3) a collection of tools comprising systemigrams, archetypes, causal loops with feedback and delays, stock and flow diagrams, behavior-over-time graphs, main chain infrastructures, system dynamics/computer modeling, interpretive structural modelling, and systemic root cause analysis. A set of definitions that comprise “The Systems Thinking Language” is provided. Criteria for Systems Thinking Tools are identified and such tools are described. The authors conclude that Systems Thinking provides a great deal of power and value. It can be used to solve complex problems that are not solvable using conventional reductionist (dissective) thinking, because it focuses on the relationships among system components, as well as on the components themselves; those relationships often dominate system performance. It focuses on the properties of the whole that are neither attributable to nor predictable from the properties of the components. ↑
- See Monat and Gannon, “Applying Systems Thinking to Engineering and Design,” Systems, Special Issue Systems Thinking: Concepts, Issues, and Applications in Large Complex Systems,” available at http://www.mdpi.com/journal/systems/special_issues/systems_thinking_large_complex_systems ↑
- User experience (UX) refers to a person’s emotions and attitudes about using a particular product, system, or service. User experience includes the practical, experiential, affective, meaningful, and valuable aspects of human–computer interaction and product ownership. Additionally, it includes a person’s perceptions of system aspects such as utility, ease of use, and efficiency. Source: Wikipedia. ↑
- A “suprasystem” is a larger system that integrates several smaller systems (Feldt, 1986). For the purposes of this paper, it means the system itself plus the environment, system users, system controllers and maintainers, communications to and from the system, and power to the system. ↑
- Pyster, A., Hutchison, N., and Henry, D. The Paradoxical Mindset of Systems Engineers: Uncommon Minds, Skills, and Careers. Hoboken, NJ: John Wiley and Sons, 2018. ISBN 9781119412151. ↑
- Lombardo, M. and Eichinger, R. (2010). Career Architect Development Planner, 5th Edition. New York: Korn/Ferry International. ↑
- The lifecycle phases used in our research come from the Guide to the Systems Engineering Body of Knowledge (SEBoK) found at http://ww.sebokwiki.org. ↑
- ABET is a nonprofit, non-governmental organization that accredits college and university programs in applied and natural science, computing, engineering, and engineering technology. See https://www.abet.org/. ↑
- ABET Engineering Accreditation Commission: Criteria for Accrediting Engineering Programs found at https://www.abet.org/wp-content/uploads/2018/02/E001-18-19-EAC-Criteria-11-29-17.pdf. ↑
- Rebentisch, E. (ed.) (2017). Integrating Program Management and Systems Engineering. Hoboken, NJ: Wiley. ↑
