PPI SyEN 71 – September 21, 2018
brought to you by
Project Performance International (PPI)
systems engineering training for project success
PPI SyEN is an independent free newsletter containing informative reading for the technical project professional, with scores of news and other items summarizing developments in the field, including related industry, month by month. This newsletter and a newsletter archive are also available at www.ppi-int.com.
Systems engineering can be thought of as the problem-independent, solution technology- independent, life-cycle-oriented principles and methods, based on systems thinking, for defining, performing, and controlling the engineering effort within a technical project. The approach aims to maximize the benefit delivered to the enterprise, as influenced by the needs and values of the other applicable stakeholders.
If you are presently receiving this newsletter from an associate, you may wish to receive the newsletter directly in future by signing up for this free service of PPI, using the form at www.ppi-int.com. If you do not wish to receive future Systems Engineering Newsletters, please unsubscribe by clicking on the link at the bottom of this email.
We hope that you find this newsletter to be informative and useful. Please tell us what you think. Email us at firstname.lastname@example.org.
The views expressed in externally authored articles are those of the author(s), and not necessarily those of PPI or its professional staff.
In This Edition
1. Quotations to Open On
2. Feature Article
2.1 Divergent Thinking in Systems Engineering Practice: Is There a Shortfall?
3. Additional Articles
3.1 The Afsluitdijk as a Complex System
3.2 Avoiding Disruption from Disruptive Technologies
3.3 Integrating Program Management and Systems Engineering
4. Systems Engineering News
4.1 29th Annual INCOSE International Symposium 2019 Call for Submissions
4.2 The US Department of Defense Announces Digital Engineering Strategy
4.3 From Grassroots to Classroom in Australia: How one Humble Event Turned into a State-wide Curriculum Resource
4.4 Cadets Lead Workshop in Detroit, Michigan
4.5 Airbus and Georgia Tech Open the Center for Model-Based Systems Engineering (MBSE)-enabled Overall Aircraft Design (OAD)
5. Featured Organizations
5.1 Engineers Australia (EA)
5.2 Alpha Phi Mu
5.3 Macau Association of Systems Engineering (MASE)
6. News on Software Tools Supporting Systems Engineering
6.1 Cameo Systems Modeler
7. Systems Engineering Publications
7.1 IEEE Access
7.2 Industrial Dynamics
7.3 The Systems View of Life
7.4 Focusing Change Management Where It Counts
7.5 The Department of the Navy (USA) Systems Engineering Career Competency Model
7.6 Risk Management for Project Driven Organizations: A Strategic Guide to Portfolio, Program, and Project Management Organization Success
8. Education and Academia
8.1 Educating the Systems Engineers of the Future
8.2 Systems Engineering at Rochester Institute of Technology
8.3 Postdoctoral Fellowship: The Psychology of Decision Making in Systems Design
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
10.1 Best Practices for Using Systems Engineering Standards (ISO/IEC/IEEE 15288, IEEE 15288.1, and IEEE 15288.2) on Contracts for U.S. Department of Defense Acquisition Programs
11. A Definition to Close On
11.1 Introduction to System Dynamics
12. Conferences and Meetings
13. PPI and CTI News
14. PPI and CTI Events
15. Upcoming PPI Participation in Professional Conferences
“The principles of systems engineering apply almost identically to non-systems.
But their importance differs.”
Robert John Halligan
“Never express yourself more clearly than you are able to think.”
“The two forces that have done the most to shape who we are as human beings, both inside and out, and throughout history, are technology and revelation.”
Bill Viola, quoting Houston Smith in a 2009 interview
2.1 Divergent Thinking in Systems Engineering Practice: Is There a Shortfall?
Stevens Institute of Technology
Copyright © 2018 by Jim Armstrong. All rights reserved.
Divergent thinking expands both the definition of problem and solution space. Convergent thinking narrows the options and leads to a selected solution. A balance of the two is an essential element of effective systems engineering practice. A significant predominance of convergent thinkers and shortage of divergent thinkers has been noticed in a group of systems engineering students. A negative impact on exercise results was also noticed. If this is a valid observation of the general systems engineering field, there are serious implications that must be addressed in the education of systems engineers and in the workplace. This paper outlines the initial observations, impact, and potential for future research.
After 20-plus years of teaching systems engineering courses that use reasonably complex problems for the in-class exercises, considerable experience has been gathered on the amount of time it takes to do each exercise and the types of results that should be expected. It was a surprising development when one class repeatedly finished the exercises in a quarter to half of the time expected. The results reflected the lack of time spent in analysis. As a result, the approach to reviewing the exercises changed from a short discussion of the various findings and alternatives to an instructor led addition of depth and breadth to the analysis and consideration of alternatives that had been missed.
Near the end of the course is a lesson on personality impacts on systems engineering using Myers-Briggs personality types. One of the factors in MBTI is related to the preference for convergent thinking or divergent thinking. It was discovered that this particular class was absent of any members preferring divergent thinking. This was certainly a potential factor in class behavior worth looking at.
Over several additional classes, the data was reviewed for this anomaly. In fact, there was a significant trend of convergent thinking in the students that far exceeds the overall population and even the subpopulation of engineers. This has potential impact on systems engineering performance in the work place that we should be alert to and be prepared to address.
Convergence and Divergence
While this particular discussion addresses convergence and divergence as indicated by the fourth preference in Myers-Briggs, the general intent is more in line with the definition below (encyclopedia.com, 2008). This definition is based on the description of the terms by J. P. Guilford.
“convergence-divergence n. A cognitive style defined by two radically different modes of thinking. At one extreme is convergent thinking, characterized by a tendency to home in on a unique solution to a problem, usually involving the synthesis of information, typified by analytical, deductive thinking in which formal rules are followed, as in arithmetic. It is logical, consciously controlled, reality-oriented, and largely dependent on previously learnt knowledge and skills, and it is measured by conventional IQ tests. At the opposite extreme is divergent thinking, characterized by the fluent production of a variety of novel ideas relevant to the problem in hand. Divergent thinkers prefer, and perform better at, open-ended problems that do not have unique solutions.”
This source also continues by relating divergence to creativity. While creativity is certainly of value in the practice of systems engineering, as a minimum, divergent thinking should be considered as looking beyond the given. A basic element of systems engineering should be the ability to expand beyond what is given rather than accept it as the valid outer limit of problem and solution space.
Either extreme in the choice of convergent and divergent thinking can result in problems. Too much divergence results in a continually expanding description of the problem and list of alternatives without arriving at a solution. Too much convergence leads to a hasty decision that misses critical requirements and many possible solution alternatives. A combination of convergence and divergence is depicted in Figure 1 (Pugh, 1991). Although the diagram begins with the front-end design work having been completed, the flow depicted can be applied throughout the systems engineering process. One concern with the figure shown is that it leaves the impression that the final solution is within the bounds of the initial number of concepts. In reality, the biggest value of divergence is when it expands the problem and solution space outside the originally provided bounds to identify requirements and solutions not initially included.
Figure 1: Combining convergence and divergence
A balance between the two extremes has been shown to produce better results. The following are specific instances encountered in program management and systems engineering training and consulting. In some cases, balance led to effective performance. In others, imbalance became problematic.
An example of the impact of the convergence and divergence balance and imbalance occurred during a class exercise at the Defense Systems Management College. Three classes of 30 students were starting the first session of an extended exercise to apply their learning to a simulated major procurement.
One class had a strong convergence tendency in the leadership for this problem. The leaders had made their decisions on the correct path before class started and quickly laid out the plan and handed out assignments. Within 30 minutes, the room was almost empty as the assignees took off on their assigned tasks. There was a lack of buy in and several students felt that they had good suggestions that they had not been given the opportunity to air. The group was headed down the wrong path and had to do considerable rework later.
A second class had leadership dominated by divergent behavior. After six hours, the faculty had to intervene. Not only had no decision been made, but the discussion was whether or not the list of possible issues was complete enough. Decision oriented members of this group were growing extremely frustrated.
A third group had a balanced approach. They spent a couple of hours discussing the case and looking at alternatives. Then they selected a course of action and proceeded with an effective approach that the class supported.
One real-world example of the impact of balance occurred in a contract protest case based on the performance of the contractor in systems engineering. After six months of preparation, the diverger of two investigators of the systems engineering aspects of the case suggested rereading the specification. The converger argued for several minutes that it was not necessary since they had read the specification thoroughly several months earlier. When it became apparent that it would be faster to read the document than continue the argument, the converger consented. In doing so, the “smoking gun” jumped off the pages when read in context. Both participants agreed that the balance of their abilities and thinking styles was critical to this and other consulting efforts they worked on.
Impact on Systems Engineering
As is mentioned above, the need for divergent, creative thinking is probably most critical in the early stages when the problem and solution spaces are being defined. Missing requirements or creative solutions can lead a project down an incorrect path that is difficult or impossible to recover from later. One of the primary objectives of early validation should be to find where the requirements do not match the actual environment and uncover the hidden needs and situations. There is a tendency to accept the requirements provided as set in stone. In one exercise, the students were provided with a problem including a customer-provided satellite data link and basic technical information. Analysis should have revealed that the polar orbiting satellites would have a potentially significant time delay between event observation and eventual transmission of the data to the user in a time-critical operation. In other cases, some interesting logic was applied to explain how two conflicting requirements are both valid rather than simply inquiring about them.
There is some rationale behind the lack of divergent treatment of requirements in that it is not a good idea to promote scope growth, particularly in a tightly negotiated fixed price contract. It is true that we do want engineers to focus on meeting the requirements. As systems engineers, we need to work with management to discover and address missing requirements and novel architectures in an orderly manner.
On the solution side, there is a tendency to continue to do what has worked well before. This can provide short term success, but will eventually result in not being competitive. Examples abound in many industries of excellent products that are no longer available due to creative technologies. Computers and phones are classic examples. At a more abstract level, Eberhardt Rechtin has referred to an analysis of system development awards where the significant factor in not selecting the incumbent was that they used the same architecture while the winner came up with a new approach. Certainly, at the system architecture level, telephone communications are nothing like what existed even twenty years ago.
While it might seem that the divergent thinking can be put aside at this point in the systems engineering process, that isn’t the case. In integration, a common error is to stop the thought process at the boundary of what is being developed. The result is products that work well in isolation but do not fit well in the intended environment. Again, this should be a focus of early validation. One communications site in Italy placed a steel lattice tower on top of the highest mountain between Pisa and Milan. The locals didn’t think it was a good idea and the first three winters resulted in a series of redesigns to be able to withstand the wind, snow, and ice. In another example of not seeing past the system of interest boundary, a study was being presented for new technologies for a tactical air command and control system. At the end of the briefing, a pilot asked where the system output was, and the presenter said that the entire scenario was presented to the commander in the command center. The pilot was not happy with the response and things got tense. He wanted to know when the information the system was working with would get to him to perform the mission. The presenter had completely lost focus on that because it was external to the system of interest. And, for that matter, attention to all enabling systems is also a weakness that many products have, particularly the maintenance interface.
Treatment in Systems Engineering Standards and References
The sources of definition for the expected practices of systems engineering include standards, handbooks, maturity models, and textbooks. A review of EIA 632, IEEE 1220, ISO 15288, the CMMI, and the INCOSE SE Handbook results in similar findings. Although the idea of divergent thinking is implicit in each, there is little that is explicit. The best evidence is in references to identification of relevant stakeholders and an emphasis on multiple alternatives in architectures, technologies, and designs. This also shows in the consideration of multiple alternatives in trade studies. However, the focus in each of them is the convergent path to select and define a single solution. The INCOSE handbook does use the word “creative” in regard to the systems engineering effort, but only in the discussion of the pre-concept phase.
Competency models have been developed to more specifically identify the practitioner skills that are needed to perform systems engineering tasks. There are several competency models publicly available and many others that corporations hold close. We can start with the INCOSE Systems Engineering Core Competencies Model (INCOSE, 2005). Most of the competency statements relate to specific tasks that do not rely on divergent thinking. However, in the section on architectural design, the competencies included are “able to generate alternative architectural designs” and “assess a range of architectural solutions” as examples of statements that do.
The National Academy of Public Administration included a systems engineering competency model in an analysis for the FAA (NAPA, 2008). It similarly focuses on typical systems engineering tasks without specific reference to extent of divergence or convergence in performance. There are references that sound divergent such as the plural of designs.
The Systems and Software Consortium’s competency model (Wells, 2007) does add some additional features that address how the tasks are carried out more than just the task itself. One such competency is defined as “negative thinking”, or the consideration of what is missing. This is the aspect of divergence that is emphasized in this paper, particularly as applied to defining problem space, operational concepts, and requirements.
While most of these sources do not provide obvious statements supporting the need for divergent thinking, they all have subtler implications. For the various functions of systems engineering to be effective and provide value added, they must expand both problem and solution space beyond what is given to discover what is not given. They must also be performed in an atmosphere that is acceptant of change in direction when the evidence indicates it is necessary. While decisions are necessary, and programs cannot be constantly changing direction, being stuck on an original wrong path is also not the right approach. To balance the two extremes in conduct, a balance in the mental approach is also necessary. To do this, the program will be better served by a balance of convergent and divergent thinking rather than one extreme or the other.
Systems Engineering Course Exercises
The exercises in the classes mentioned previously are fairly complex. The original system being addressed is a weather and tsunami warning system for a fictitious island nation (Armstrong, 2003). The location is in the Pacific Ocean at the equator, due south of Los Angeles. The students are given a request for a system of 1,000 fully instrumented weather buoys to be deployed over 4,000,000 square nautical miles of ocean. The purpose is both for weather prediction in shipping lanes leading to the islands and data for research. A tsunami alert capability is also required. A target budget of $250 million for 10 years is also defined.
The problem has many interfaces that must be analyzed and conflicting requirements. The complexities begin with the analysis of the multiple missions in the concept of operations and continue as the students define requirements, develop functional analysis, select an architecture, and complete a system design. Additional issues include a customer provided satellite communications service that will work for weather data, but does not address the critical timing requirements of tsunami warnings. Also, the initial scope of the system with 1,000 buoys exceeds the cost constraints. These problems and more must be addressed with an open mind to challenge the customer data and develop alternative solutions that meet the core needs. Hence, the need exists for divergent thinking.
In recent years, the problem has been tailored for a system integration course to only address a tsunami warning system in the Indian Ocean. Similar issues with convergent and divergent thinking have been observed in this more focused application.
Convergent/Divergent and the MBTI
Personality. There are multiple approaches to addressing the differences in individual behavior. Some of the more popular are Herrmann Brain Dominance, Kolb Learning Styles, and the Myers-Briggs Type Indicator (MBTI). The MBTI has been used by the author in systems engineering training for 20 years as a means of teaching systems engineers how to work better with people in leading the technical aspect of the program.
The MBTI is based on Carl Jung’s analysis of personality. Jung identified three characteristics of individuals that he observed. Myers and Briggs added a fourth which includes the convergent/divergent dimension. Each preference is described below along with the distribution ratio in the general population and the potential impact of that preference on systems engineering
The first characteristic is a preference for introversion (I) or extraversion (E), Figure 2. While we tend to view this as people being outgoing or reclusive, that is only a symptom of the meaning. The actual definition relates to whether a person is energized or drained by either group activity or solitude. The general population is split 50/50 on this preference. The benefits of extraversion in a systems engineer is the comfort level in working with groups on a project. This helps in participation in dealing with multiple stakeholders and team meetings, particularly with Integrated Product Teams. The strength of introversion is the ability to sit down and do analysis without feeling the need to go talk to someone every few minutes. Of course, the weakness of each preference is the lessened ability to do the opposite when the need for that behavior arises.
Figure 2: Introversion/Extraversion
The second characteristic addresses the type of input a person is more comfortable receiving. The intuitor (N) has an input preference for concepts and big picture. The sensor (S) prefers hands-on inputs and details as shown in Figure 3. The general population is 30% intuitor and 70% sensor. At first glance, the role of systems engineer would appear to favor the intuitor due to the focus on the higher level of abstraction of the system view and the need to be able to deal with more uncertainty. However, big picture concepts that look very good at the surface are too often found not to work when the detail analysis is performed. This ability to work well with the details of a thorough analysis and interest in getting hands dirty with the actual system as fielded is a systems engineering strength of the sensor.
Figure 3: Intuition/Sensing
The third characteristic is an output preference for the basis of judgment in making decisions. The two options are feeling (F) and thinking (T), Figure 4. The conflict between these two options is the basis for the character Spock in the Star Trek series. He is torn between the emotionally based decisions of his human mother side and the pure logical decisions of his father’s Vulcan side. This is the one preference that is gender biased. Males show a preference for thinking by two to one and females prefer feeling by the same margin. However, it must be noted that this bias is far from enough of a difference to form stereotypes or jump to conclusions based on gender. The strength of making logical decisions in systems engineering should be obvious. However, we need to recognize the considerable value in being able to empathize with others in the performance of systems engineering tasks. This is true both in working with the project team and in dealing with the various stakeholders.
Figure 4: Feeling/Thinking
The fourth preference added by Myers and Briggs is whether a person is more comfortable with the input side or the output. Those preferring input are perceivers (P) and those preferring output are judgers (J), Figure 5. This is the preference that relates to divergent thinking or convergent thinking. In the extreme a perceiver never comes to a conclusion and the answer to every question is three more questions. This behavior is associated with laboratory scientists. At the other end of the spectrum is the total judger who has an answer before the question is even asked. A significantly high percentage of project managers exhibit this preference. In the general population, there is a slightly higher percentage of judgers than perceivers. This is the area in which an exceptional distribution was noticed in the students observed and is the focus of this analysis. The strength of the judging preference is the ability to make the decisions needed to execute the program in a timely fashion and not keep the rest of the technical team waiting for the decisions to be completed. The weakness is a tendency to rush to judgment and not look at enough alternatives. A particularly significant statement is made by (Kroeger, 1988) in discussing the judger, “Judgers, in contrast, have the tendency to judge – rather than to respond to new information, even (or perhaps especially) if that information might change their decision.” This tendency can be very dangerous in complex systems development. The value of the perceiver preference is the ability to identify multiple alternatives or issues that others have not recognized for consideration. The weakness is the lack of getting to a decision on time.
Figure 5: Perception/Judgement
The resulting four preference choices are Extraversion/Introversion, iNtuitor/Sensor, Feeling/Thinking, and Perception/Judgment. When each of the preferences is determined, the result is a four-letter preference type. The set of 16 combinations result in the 16 Myers-Briggs types. These are intended to be helpful in understanding differences in normal behavior and are not related to quality of performance or identification of psychological problems. The 16 types and the average percentage found in the general population are shown in Figure 6.
Figure 6: The 16 Types
The data from 109 students in a series of classes is shown in Table 1. The percentages for each preference, as compared to the general population are shown. The general population numbers for Feeling and Thinking are not included. As described above, this preference has a gender bias and the gender data for the classes was not retained. However, the numbers are consistent with a predominantly male population which is consistent with the overall class population.
Table 1: SE Student Preferences and General Population
The predominance of judgers is considerably different from the general population. Engineers generally tend to lean towards the judgment preference. Table 2 shows the preferences for several categories of engineers and engineers in general based on early MBTI scoring returned to the Center for Application of Psychological Type (Briggs. 1988). The group of students that is the basis of this analysis has a considerably higher percentage of judgers than even the highest group, chemical engineers.
Type of Engineer
Electrical and Electronic
Table 2: Judgment/Perception Preference of Engineers
One factor that may play in the classroom situation is the group of personality types that exhibit both sensor and perceiver preferences, xSxP, as indicated by the dark border in the middle left of Figure 6 above. These are described (Kroeger) as people who prefer to learn by hands-on rather than classroom. They also are less likely to be interested in what would be perceived as a theoretical discussion. The absence of this group in significant numbers will have an influence on classroom behavior but may be a compensating factor in the workplace. However, even doubling the number of perceivers in the classes would not explain the shortage experienced.
While the volume of the data collected is limited, it matches observations in practice and classrooms over several decades for both engineers and project managers. This should be considered a significant risk that needs to be addressed in the training and education of systems engineers. Identifying and addressing the issues should result in an improvement in the practice leading to better results for the customer from the broader understanding of the problem in the requirements phase, an improved set of alternatives in the architecture, and a more thorough integration, verification, and final validation.
Other Areas of Concern
While the focus of this discussion has been the distribution of divergent and convergent thinkers in the systems engineering population, there are other potential preferences to address. For instance, the distribution of big picture (intuition) and detail (sensing) thinking was significantly tilted towards the big picture side in this sample population. At first look, it would seem appropriate that systems engineers have this tendency since the primary value in systems engineering is to coordinate the detail views of specialist in multiple disciplines to achieve the higher order purpose. However, extremes can have negative consequences even when they appear to be the right extremes. Sometimes those with an extreme preference for the big picture are lacking in attention to details and head down paths that later are discovered to be dead ends. At the other end is the tendency to be too much into the details and get lost in them. Or, as one engineer put it, it is more than not seeing the forest for the trees; it’s not seeing the trees for the bark. In each of the preferences, there is value in each aspect and it helps to know where the strengths and weaknesses are to apply them appropriately.
In one small software development organization, the manager was having difficulty in promoting from within for first level managers. A sample of 30 of the employees, about 15% of the organization, taking part in a class was 85% introverted, sensing, thinking, perceivers (ISTP). This type is only about 5% of the general population. However, the characteristics are positive for software developers. They are comfortable working at a computer station developing detailed logic and coming up with creative solutions to the technically challenging problems this particular group faced. However, when they moved to take on management responsibilities, they needed to get away from their own screen and interact with those they managed, see the big picture, deal well with people, and make decisions. It is not a case of not being able to do these tasks, but rather needing to understand that they were out of the comfort zones of most of the employees. Special care needed to be taken to aid in the transition. Knowledge of the situation would allow management to address the previously unrecognized issues and more effectively develop the leaders they needed
The initial observations of a bias towards convergent thinking in a student population of practicing systems engineers have potential impact on the overall practice of systems engineering. If this holds to be true in the general population of the systems engineering community, the result is likely to be a less effective definition of both problem and solution space and a sub-optimal end product. Awareness of the circumstance can lead to corrective actions. A balance should be sought in the use of both styles of thinking. Where practical, this can be established by understanding the strengths of potential systems engineering practitioners and assuring that both styles are represented. Some organizations do use instruments such as the MBTI to address the strengths of the workforce. Should an unbalanced situation exist, as has been seen in some cases documented here, extra effort can be applied to stimulate additional divergence. However, this is not an easy task, particularly when attempted by someone who is a strong convergent thinker. Further research into the validity of the observations, extent of the condition, impact, and mitigations is warranted. Meanwhile, we can all be aware of this potential issue in the practice of systems engineering.
List of Acronyms Used in this Paper
CMMI Capability Maturity Model Integration
EIA Electronic Industries Alliance
FAA Federal Aviation Agency
IEEE Institute of Electrical and Electronics Engineers
INCOSE International Council on Systems Engineering
ISO International Organization for Standardization
MBTI Myers-Briggs Type Indicator
Armstrong and Bocast, The Integration of Systems Engineering and Software Development, Software Productivity Consortium, April 2003.
Bennet, E. A., What Jung Really Said, Schockten Books, New York, 1983.
Capability Maturity Model Integration, Development Version 1.2, Carnegie Mellon University, August, 2006.
EIA 632, Process for Engineering a System, Electronic Industries Alliance, Arlington, VA, January 1999.
Herrmann, The Theory behind the HBDI® and Whole Brain® Technology, August 1999.
IEEE 1220, IEEE Standard for Application and Management of the Systems Engineering Process, IEEE, 345 East 47th Street, New York, NY 10017, 1999. Available at https://standards.ieee.org/standard/1220-2005.html.
INCOSE, Systems Engineering Handbook, a Guide for System Life Cycle Processes and Activities, June 2006. Available through INCOSE at https://www.incose.org/products-and-publications/se-handbook.
ISO/IEC 15288, Systems engineering – System life cycle processes, ISO, 1 rue de Varembe, CH-1211 Geneva 20, Switzerland, 2002. Available through ISO at https://www.iso.org/standard/63711.html.
Kroeger and Thuesen, Type Talk, Delecorte Press, New York, 1988.
MIL-STD-499B, Systems Engineering, May 1, 1995.
Myers, Isabel Briggs and Mary H. McCaulley, Manual: A Guide to the Development and Use of the Meyers-Brigs Type Indicator, Consulting Psychology Press, Palo Alto, CA, 1988.
Naval Systems Engineering Guide, Naval Systems Engineering Steering Group, Washington, D.C., 2004. Available at http://www.dtic.mil/dtic/tr/fulltext/u2/a527494.pdf.
National Academy of Public Administration, Identifying the Workforce to Respond to a National Imperative – The Next Generation Air Transportation System (NextGen), 2008. Available at https://www.napawash.org/studies/academy-studies/identifying-the-workforce-to-respond-to-a-national-imperative-the-next-gene.
Pugh, Stuart, Total Design: Integrated Methods for Successful Product Engineering, Addison-Wesley Publishing Company, Wokingham England, 1991.
Wells, Systems Engineering Competency Model, Systems and Software Consortium, Inc., 2006.
About the Author
Jim Armstrong has practiced systems engineering for 51 years, performing various roles including configuration management, test, deployment, chief engineer, program manager, and program element monitor. For the last 30 years, he taught, consulted, and appraised systems engineering in industry and government. Also, he was on the author teams for several of the standards and models discussed in this paper. He is also certified in the use of the Myers-Briggs Type Indicator. He has a BS in Mechanical Engineering from Rensselaer Polytechnic Institute, an MS in Systems Management from the University of Southern California, and a PhD in Systems Engineering from Stevens Institute of Technology. He has an INCOSE Expert Systems Engineering Professional (ESEP) certification.
3.1 The Afsluitdijk as a Complex System
Berber de Liefde-Vogt
Systems and Integration Architect bij Rijkswaterstaat
Rotterdam Area, Netherlands
In 1891, a young engineer by the name of Lely developed the first plans for the Afsluitdijk (Enclosure Dam). In 1913, serving as the Dutch Minister of Water Management, he made sure that the project was placed on the Cabinet agenda. One of the purposes of the enclosure was to reclaim land to improve food supply. The plans were labelled financially unfeasible and shelved. However, the 1916 flood disaster and the growing need for farmland during the First World War caused the National Government to change their minds. In 1918, the Dutch Parliament agreed to adopt the Zuyder Zee Act, soon followed by the start of construction of the Afsluitdijk, which was completed in 1932.
As well as providing better protection of the hinterland against flooding as well as an opportunity to reclaim new land from the sea, the damming off of the Zuiderzee by the Afsluitdijk created a freshwater reservoir. Furthermore, the construction of the Afsluitdijk enabled a traffic connection between the provinces of North Holland and Friesland.
Figure 1: Location of the Afsluitdijk
Figure 1 represents the main system elements:
Purple arrow: Primary water-retaining structures
Grey arrow: Main water system
Orange arrow: Main waterway network
Red arrow: Trunk road network
Green arrow: Cycleway and footpath network
At the time, the Afsluitdijk was constructed using the then available knowledge and understanding. The design process took into account factors such as the tides in the Wadden Sea, while at the same time taking into account that it had to be possible to discharge water brought in by the River IJssel and the surrounding areas into the Wadden Sea. In the 21st century, these boundary conditions are still valid.
However, both the physical and the public environment of the Afsluitdijk have changed as a result of climate change. Over the years, as well as environmental protection and sustainability rising in importance the years are beginning to take their toll. These years of service life not only affect the physical design, but also the cultural experience. A system such as the Afsluitdijk should be adaptive and able to anticipate change. However, this has an impact on the original objectives, making it necessary to redefine these objectives. Not only will new objectives be added, such as contributing to environmental protection and sustainability, but also existing objectives, such as guaranteeing the safety of the hinterland, will be tightened.
In other words, this redefinition means that we need to make the Afsluitdijk system ‘Fit for the Future!’
The challenge to make the Afsluitdijk ‘Fit for the Future’ involves a large number of projects on and around the Afsluitdijk (www.deafsluitdijk.nl). One of them is the Afsluitdijk project, which was contracted out as a DBFM (design, build, finance, and maintain) contract. The most important theme within this project is to ensure effective flood management. An inspection in 2006 revealed that the Afsluitdijk no longer met the standards in terms of flood management, meaning it no longer complied with the function of ‘Defend high tide’. At the same time, the water discharge capacity, or the function of ‘Discharge water’ from the IJsselmeer, was not sufficient any more either.
This article addresses the manner in which systems engineering will make the Afsluitdijk future-resilient in a structured and controlled manner. As an example of this approach, we discuss the objective of ‘Guaranteeing the safety of the hinterland (keeping our feet dry)’. In order to achieve this objective, the Afsluitdijk as a system needs to have the necessary capabilities and the corresponding functions to be able to protect the hinterland.
In view of the large number of different projects that are taking place within the Afsluitdijk system – and, therefore, the large number of interactions between these projects – it is of the utmost importance to ensure that the various scopes and scope boundaries are properly monitored in order to ensure control over the complexity. This applies to geographical, organizational, process-related as well as technical influences (interfaces). The approach described below contributes to this goal by allowing future control of objectives, capabilities, and functions.
The Afsluitdijk System
The complexity of the Afsluitdijk system arises not only from diverse objectives, but also from the large number of stakeholders (over 250), each with their own needs. These stakeholders include members of national, local, and regional tiers of government; members of environmental protection groups; representatives of agriculture, fisheries, recreation, transport, et cetera. All of these stakeholders represent the interests of their respective fields, ranging from economic interests to environmental protection.
In order to bring the various stakeholders ‘on board’, we use a model known as SEM (Dutch: SOM), Strategic Environmental Management, as represented in the Figure 2. One of the elements of SEM is an issue monitor that will clearly outline the issues that need to be addressed. Another element of SEM is a regularly updated issue file. The position of a wind turbine, for instance, may be an issue in terms of whether it is located on or alongside the dike. A change of government at a regional level in itself may present an issue. Based on the issues, a strategy will be developed, as well as any measures necessary to tackle the issue.
Figure 2: SOM-Model (source: WesselinkVanZijst)
The stakeholders are involved at the outset of the project (plan development phase of the Multi-Year Program for Infrastructure, Space, and Transport; Dutch: MIRT), and a stakeholder/environmental analysis is performed to gather information about the various needs. Within the systems engineering procedure of Rijkswaterstaat (the Directorate-General for Public Works and Water Management), a prioritization process is carried out to determine which needs will and will not be addressed and included in the development of the system.
The interests of the various stakeholders are identified and laid down in several objectives, indicating the criteria that need to be met. Validation will take place based on these criteria. The law (Water Act) may be a criterion, for example, as can measures taken by the stakeholders.
Figure 3 provides a partial overview of the various objectives as well as their corresponding validation criteria.
During the various phases of the entire life cycle of the system, the objectives for the Afsluitdijk system may be inconsistent or contradictory. To name one example, at high tide in the Wadden Sea (Objective: Guaranteeing the safety of the hinterland), it is impossible to support the natural fish migration (Objective: Improving the natural environment, G.01.03). This means that at times of excessively high water levels, it is impossible to comply with both the ‘Guaranteeing the safety of the hinterland (G.01.01)’ and the ‘Improving the natural environment (G.01.02)’ objectives. In this situation, ‘Guaranteeing the safety of the hinterland’ will prevail over ‘Improving the natural environment’. In similar situations, the objectives will be prioritized based on the stakeholder analysis.
In order for the system to achieve the various objectives, the Afsluitdijk will need to have a number of capabilities.
Green are objectives
Blue are capabilities
Yellow are the functions that provide the above capability
Figure 3: Objectives and their validation criteria
Figure 4: A subset of objectives and capabilities of the Afsluitdijk
One of the most important capabilities that the Afsluitdijk system has to offer is protection of the hinterland. This requires a water defense structure for the exterior water of the Wadden Sea as well as a system to keep the inland water at the desired level.
Excessive water levels in the inland areas (IJsselmeer) may lead to floods in the provinces of North Holland, Friesland, and the IJsselmeer polders. A side effect of inadequate defense against the exterior Wadden Sea water is that salt intrusion prevents the intake of fresh water from the IJsselmeer. This has consequences for fields including agriculture, water distribution, and the ecology.
Figure 5: Capability ‘Protecting of the hinterland’ is provided by these two functions
Defense against exterior water requires dikes that are sufficiently strong and will not collapse under the (water) load, while at the same time they should prevent excessive (exterior) water from washing over the dike. Prevention of erosion both on the inside and the outside of the dike is a prerequisite. These are, in other words, the sub-functions of the function of ‘Exterior water defense’, for which a decomposition was made.
Figure 6: The function ‘Defense Water’ consists of Several Sub-functions
If we limited the system to retaining the water from the Wadden Sea, the IJsselmeer would fill up with fresh water carried in by the River IJssel. A simple solution for high water levels in the IJsselmeer would be to discharge the water into the Wadden Sea. However, the IJsselmeer is also a freshwater basin, which means that the water level must be kept above a certain minimum level. The desired level, therefore, will determine the quantity of water that needs to be discharged. In order to be able to determine this level, the water management department monitors the expected water levels in the river system. This is calculated based on factors including the quantity of river water entering our country from abroad, rainfall forecasts, and the wind. The measurement results are used to calculate a so-called discharge figure, which is communicated to the Afsluitdijk system as a ‘discharge set point’. Based on this figure, water is discharged into the Wadden Sea. Figure 7 below represents the sub-functions of the ‘Maintaining desired interior level’ function. This figure represents the information flow between the various functions.
Figure 7: ‘Maintaining desired interior level’ consists of several sub-functions
Figure 8: Information flow of the ‘Maintaining desired interior level’ function
In order to be able to deliver all of the desired functionality, a system architecture has been developed that contains the required system elements that can provide this functionality (Figure 8).
Figure 9 represents the various types of associations between the typical system elements. For example: one dike protects one or several areas, or the fish pass enables the actor Fish to pass through. This Architecture forms the basis for initiating changes.
The system architecture of a dike can be used as a basis for designing a system structure for the Afsluitdijk. In this process, each system element is an instance of an architectural element, and associations are translated into interfaces.
The Afsluitdijk has two Discharge sluices, Lorentz and Stevin, both instanced from the architectural element of the Discharge sluice.
The Afsluitdijk consists of several dike segments, which were instanced from the architectural element of the Dike segment.
Figure 9: System Architecture of a Dike
Figure 10: System Structure of the Afsluitdijk
What makes a system such as the Afsluitdijk a complex system? Besides the many stakeholders with their often very diverse and sometimes even conflicting interests, it is particularly the required adaptivity of the Afsluitdijk system to a changing physical environment that brings complexity to the system. The application of the method as outlined, in which objectives such as ‘G.01.01 Guaranteeing the safety of the hinterland’ are traceable, and capabilities such as ‘Protection of the hinterland’ and ‘Control water level’, and functions such as ‘F.1.1 Retaining exterior water’ and ‘F.1.2 Maintaining desired interior level’, and architecture such as ‘Discharge sluice’ and solutions derived from this such as ‘Lorentz’ and ‘Stevin’ are guaranteed, forms the basis to be able to perform impact analyses. The impact analyses on the basis of changing objectives may lead to modifications that are deemed necessary, while impact analyses for failure of functionality can shed light on which capabilities or even objectives cannot, or not entirely, be guaranteed. The outlined method, therefore, enables control of the outlined complexity today as well as in the future.
An additional complexity is that over the years, the Afsluitdijk has been subjected to several maintenance projects involving renovations and innovations. The complexity is caused by the fact that there is a difference between contract limits and system limits, leading to sub-optimization and complexity at the interface between the system elements. One example of this effect is ship traffic light control based on the position of the gates of the tide lock and the ship lock, which are governed by two different contracts.
The Afsluitdijk, https://www.theAfsluitdijk.com
SOM mode, http://somset.nl/over-som/
SE Leidraad, https://www.leidraadse.nl
INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4th Edition, https://connect.incose.org/Pages/Product-Details.aspx?ProductCode=TechSEHandbookDiscountCode
RWS internal – Ontwerpkader Keren Hoogwater Afsluitdijk (functionele Analyse) (Design Framework High Tide Defense Afsluitdijk, [functional analysis]), RWS-#2872234-v8
RWS internal – Afsluitdijk is een Icoon (Afsluitdijk is an Icon), Joost van Beek
RWS Internal – Functionele, aspect en raakvlakanalyse (Functional, aspect and interface analysis), RWS-#2749593-v5C-rapport
Editor’s note: The RWS Group provides intellectual property translation, filing and search services, and technical and commercial translation and localization. See https://www.rws.com/
About the Author
Berber de Liefde-Vogt is a member of INCOSE and she is Assistant Director of Communications of the EMEA Sector. She is working as a Systems and Integration Architect at Rijkswaterstaat. Her working fields are model-based systems engineering, technical management and value management as part of asset lifecycle management for the Dutch Water Management, highway infrastructure, and waterway structures. Since August 2017 she is working as Systems and Integration Architect at the project DBFM Afsluitdijk. Berber has obtained a Bachelor of Software Engineering and a Bachelor of Electrical Engineering.
3.2 Avoiding Disruption from Disruptive Technologies
This month’s theme revolves around disruptive influences and technologies, and that presents a bit of a problem for me. It’s a hugely topical area at the moment, with everything from 3D printing to cryptocurrencies impacting organizations in some small (or not-so-small) way. But that’s the core of my dilemma. With such a hugely significant topic to write about, the dilemma was finding something different to write about.
And that got me thinking, that’s really the situation a lot of project managers find themselves in when it comes to disruptive technologies. There’s so much focus on how to leverage those technologies that the organization wants to embrace—and how to minimize the disruption caused by those technologies that have the potential to damage organizations—that the peripheral things can get lost. And some of those peripheral items are hugely important—like the impact of all this disruption (and disruption management) on project managers.
So, how can PMs avoid being disrupted by disruptive technologies?
The Impact of Disruption
There are three reasons why disruptive technologies are receiving so much attention at the moment:
The impact they are having is significant, fundamentally redefining what is possible and permanently changing a number of industries as a result (just think of traditional retail as an example).
The huge diversity of technologies – I mentioned 3D printing and cryptocurrencies, but those are just two from of a huge list. Artificial intelligence, the internet of things and autonomous vehicles get a lot of press, but renewable energy and advanced robotics are going to be just as disruptive.
The difficulty in understanding the impact of these technologies – For most people, if you aren’t involved directly in adopting each of these technologies, there is a lot of uncertainty about how they will disrupt. People may fundamentally understand the idea of artificial intelligence, but they generally don’t know how it will change their job or employer.
These factors combine to create a lot of apprehension and uncertainty in organizations. Disruptive technology is always receiving mass media coverage, and such coverage is always focused on the significance of the impact. Even if you aren’t directly concerned that robots are coming to take your jobs, you have to be aware that things are going to be changing—a lot.
That creates a situation where it’s very difficult to remain focused on doing the work because of the fear of the unknown—and the inevitability that changes will be forced on virtually everyone in the organization. In that regard, the concept of disruptive technologies is not just the disruptive nature of the technological changes themselves, but also of the disruption to organizations that even the fear of such change causes.
For project teams, this disruption hits particularly hard. Not only are team members more aware of the specifics of the change impact (because they are working on the projects to implement or leverage disruptive technologies), they are also potentially working on initiatives that impact the livelihoods of their friends and colleagues. While disruptive technologies are not automatically a recipe for job losses, they will cause fundamental change in many positions—and not everyone in those positions will remain in the organization.
As if that weren’t enough, team members will be sought out by the people who are likely to be impacted and will be asked for details and information on what is going to happen (and when). That puts those team members in a difficult position, as they are likely not able to provide the complete picture to their colleagues. That heightens stress on both sides and can damage relationships for an extended period.
Managing Disruption as a PM
While organizational leadership and project sponsors have a role to play in managing this environment, it will fall on the project manager to control the day-to-day environment and ensure team members are as productive as possible. That means the team must be protected from disruption; it must remove uncertainty as far as possible and it must believe that it is working on an initiative that is beneficial to the organization.
For that to occur, the PM must ensure that all of the following happen:
The team is provided with comprehensive background on the project purpose. It needs to understand why the technology is being embraced and how it will help the organization succeed in the future. Unless the team understands the driving forces, it will be operating in a partial vacuum that not only impacts its ability to be effective, it may also cause team members to question their own futures.
There are dedicated communication resources focused on the impacted user groups. The project team should not be the source of information to end users or affected business areas. If team members are approached, they must be able to refer the person or group asking for information to an alternative person who can address their needs. This shouldn’t be the PM either; disruptive technologies require a degree of organizational change management, and those resources should control communications.
Solutions are continuously reviewed and validated. Because these disruptive technologies are revolutionary in nature, there is considerable uncertainty about how they will actually impact the organization. Even if an implementation strategy is developed and reviewed ahead of the project start, there will inevitably be new information that arises during the execution of work. The PM must ensure this is reviewed and that the project is adjusted to optimize the solution that is ultimately implemented.
It is this last piece that can be the most difficult, but it is also the most important element of managing disruption. While disruptive technologies are always going to have a significant impact, it’s up to the organization to ensure that the negative elements of that impact are minimized while the positive characteristics are maximized. That requires an adaptive project team capable of adjusting the “what” of the work in order to ensure that the desired end state for the organization post-adoption is as strong as possible.
That in turn requires the project manager to maintain a very strong relationship with the sponsor and other key stakeholders. Those individuals will be less certain about what the project needs to deliver when disruptive technologies are involved simply because there are so many unknowns.
The final solution is going to be impacted by the understanding of what’s possible, which will increase with familiarity and with the organizational readiness to absorb change (which will vary over time and across business areas). It will also be impacted by recommendations from the team, the actions of external competitors and the ongoing advancement of technology. These all combine to necessitate that the PM maintains many more balls in the air than on a normal project—and dropping any one of those balls can have a profound impact on the organization’s ability to succeed.
The project manager must also be aware that there will be situations where the project team (or individuals within it) is going to be adversely affected by the project that is being made. At the extreme, it may be that team members will be unemployed as soon as their project work is completed. Less dramatically, there will be individuals who prefer the “old” way of doing things to the new approaches; they will be moving to a completely different role as a result of the disruption (or will experience any one of innumerable other impacts). The PM must be sensitive to these individual needs while ensuring that the project continues without being impacted.
Everyone in an organization understands that the adoption of one or more disruptive technologies is a complex endeavor. The decision to commit to adopting AI or to move to autonomous vehicles is never taken lightly, and there is a lot of analysis of the potential impact made before the final decision is taken.
However, after that decision is made and the project to implement the work is approved, there is a tendency to treat the work as “just” another project. This is the biggest challenge for project managers—ensuring that the project is recognized as being different and is given the additional support required as a result.
The key stakeholders for the PM (sponsor, customer representative, etc.) will be more familiar with the technology than the project manager or team because they will have been involved with it for a longer period of time. That familiarity will result in a tendency to underplay the disruption and impact—and the PM must ensure that doesn’t happen.
Disruptive technology projects can be just as successful as any other initiative, but they are different—and must be treated that way if they are to have the greatest chance of success.
About the Author
Andy Jordan, PMP, President of Roffensian Consulting Inc., an Ontario, Canada based management consulting firm, is a well-known author and expert on project management and related topics. His literary works have been printed in industry and corporate publications worldwide. Andy is a prolific writer with new articles appearing weekly on projectmanagement.com with an audience of nearly 600,000 IT project managers and executives; and for projectsatwork.com with an audience of more than 120,000 program and portfolio managers. He is also a sought-after speaker and moderator of in-person and web-delivered events for private clients and industry associations, and is an accomplished instructor on project management, risk management, leadership and communication related subjects. Mr. Jordan has assisted organizations in all aspects of portfolio, program and project execution as well as PMO structure and process. His successful track record includes managing business-critical projects, programs and portfolios in Europe and North America, in industries as diverse as investment banking, software development, call centers, telecommunications and corporate education. He also developed an impressive reputation for turning around troubled project execution functions and delivering meaningful business results while maintaining and developing team performance and morale.
3.3 Integrating Program Management and Systems Engineering
Ralph R. Young
This month we provide a summary of Chapter 16, Calls to Action, in Integrating Program Management and Systems Engineering (IPMSE), a collaboration of the International Council on Systems Engineering (INCOSE), the Project Management Institute (PMI), and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts (USA) Institute of Technology (MIT). This is our sixteenth article in this series. Our objective in providing this series is to encourage subscribers to leverage the research base of this book that has provided new knowledge and valuable insights that will serve to strengthen the performance of complex programs. “The Book” is highly recommended as professional development for all systems engineers and is available to members of INCOSE at a discount.
A key message of the entire book is that the implementation of current systems engineering practice is not sustainable, which is to say that the state of systems engineering practice must improve or else we face dire consequences, such as a continued high rate of failures in developing and implementing complex systems. This situation is avoidable and it is unacceptable.
It’s reasonable to conclude that systems engineering practice is already in a state of transformational change (change implemented that affects the way an organization conducts its business activities) aimed at a future state in which program management and systems engineering are more fully integrated: projects, programs, and organizations are performing effectively and are largely successful. For an exceptional treatment of this subject, see Troy Peterson Systems Engineering Transformation, published in PPI SyEN 69, September 2018, accessible here.
Leaders have the opportunity to proactively drive positive change in engineering program performance. The chapter addresses five groups that must play a key role in driving program management and systems engineering integration: academia, enterprise leaders, policymakers, professional societies, and researchers. Members of each of these groups are already hard at work, but we must all step up the gain if the integration challenge is to be met. A requirement is that all must thrive on change, and work collaboratively to rise to the challenges of change.
Call to Action for Academia: Help Budding Professionals Learn to Adapt
Today’s systems engineering practice demands systems thinking: the process by which one attempts to look at the whole of the system, rather than the individual parts, in order to gain a better understanding of how the parts interact and to understand the interdependencies within the larger system. Today’s systems engineers must possess a “systems perspective” and use a “systems approach”. Systems engineering helps ensure that the system that is delivered is a coherent and effective solution to the system need.
We have learned that we must develop transversal skills and competencies, such as communication and languages, the ability to handle information, to solve problems, to work in teams, to excel in project management, and to lead social processes. We must anticipate a lifetime of continuous learning beyond the achievement of academic degrees, and an environment of continuous improvement in our organizations.
The challenge for colleges and universities is to figure out how to teach transversal skills and competencies and to provide interdisciplinary curricula. For example, the Department of Civil and Architectural Engineering at Tennessee State University has incorporated into its curriculum a project management course for civil engineers, architectural engineers, and construction engineers. The course focuses on the management and leadership capabilities required to successfully execute construction projects. A strong focus on management of stakeholders, costs, and schedule is balanced with addressing safety management, use of software tools, building and leading teams, and professional ethics (Banik, 2015).
The Electrical, Computer, Software, and Systems Engineering Department at Embry-Riddle Aeronautical University undertook efforts to integrate several graduate systems engineering and software engineering courses. The initiative also incorporated project management practices and software capabilities into the syllabus. Building an integrated program uncovered a key obstacle: there were no books presenting such an interdisciplinary approach. Babiceanu (2015) reported that faculty developed course materials by integrating components from various publications (see page 346 of The Book).
The Graduate Reference Curriculum for Systems Engineering (GRCSE™) Pyster et al., 2012) recognized the value of incorporating project management into engineering courses when they quote Pyster and Olwell (Eds.):
“Systems engineering incorporates skill sets from many disciplines, including traditional engineering as well as more management-focused disciplines (project management, program management, industrial engineering, etc.). It is important that systems engineers possess basic knowledge related to these disciplines and also understand how SE is related to other disciplines. A student should be able to articulate how SE could and should interact with these disciplines and what common pitfalls may occur when these relationships are not properly managed.”
Innovative engineering leadership education programs increasingly emphasize the introduction of more elements of life cycle processes and operations for engineered systems, including interpersonal skills and leadership. Yet they still may not address some of the important organizational and relational elements highlighted in The Book, particularly, integration across functional and organizational boundaries – an important element of engineering program success. Unproductive tension between the program management and systems engineering disciplines results when integration of the disciplines is informal, ad hoc, or just ineffective. The roots of unproductive tension may ultimately lie with poorly defined roles and relationships in the program and the organization. As engineering efforts become more integrated, and as relationship become more explicit and formally defined, the unproductive tension decreases. This suggests that organizational or program design may play a significant role in shaping the effectiveness of engineering efforts. While engineering students may learn a good deal about product design during the course of their education, they may not have much exposure to information about the design of organizations and the relationships they embody. These issues and topics should be considered for addition to future engineering leadership curricula.
Academia should also consider whether there are better approaches for achieving true interdisciplinary education (an educational approach in which two or more disciplines collaborate in the learning process with the goal of fostering interprofessional interactions that enhance the practice of each discipline). Such interdisciplinary education is based on mutual understanding and respect for the actual and potential contributions of the disciplines.
In their Web resource post, Interdisciplinary Approaches to Teaching, Goldsmith, Hornsby, and Wells propose that faculty lead the change by doing the hard work required to build a truly interprofessional and interdisciplinary program. They advocate a model proposed by Allen Remko and James Welsh that empowers their role as transformers. The transformation that Goldsmith and colleagues propose is not just of the degree program, but of the individual faculty members themselves. The model requires that faculty members become interprofessional and interdisciplinary through their research, engagements with academic colleagues, and outreach to industry and government. According to Goldsmith and colleagues, only by living and embodying the transformation can faculties demonstrate to students the criticality of being interprofessional and interdisciplinary.
Call to Action for Enterprise: Build the Right Engine for Strategy Implementation
Enterprise leaders care about outcomes – the achievement of a strategy or a mission. Achieving outcomes requires that organizations have an engine that is capable of effectively implementing strategic objectives. One such approach is an “engine” with five interlocking components:
- Culture – leaders must demonstrate the behaviors they expect their teams to emulate.
- Vision – members of the organization must understand the importance of the objective as well as their needed contribution.
- Talent – finding the right people; providing professional development and performance incentives.
- Capabilities – ensuring that the right people have or learn that which is needed to deliver their best performance.
- Leadership – leaders must energize people to provide their best efforts, empower them with the appropriate authority, and enable them to build collaborative networks that deliver results for the organization.
There are three interlocking mechanisms that must work together to effectively execute and sustain true organizational change: culture, commitment, and capacity (Combe, 2014).
Achieving the new mindset, to which systems engineering and program management must align practices in order to enable better collaboration and deliver greater value and customer satisfaction is at the heart of the cultural change described in The Book. Executive leaders must hold themselves accountable to lead by example, and make one of their primary jobs the mentoring of the next generation of enterprise leaders. Talent management activities help support the right mindset, empower individuals to do their part, and sustain critical changes. For new employees, the proper orientation, mentoring, and coaching helps them adapt to the organization’s environment, performance expectations, and cultural norms. Developing integrative training programs for team members from various disciplines helps them learn together, work together, and understand each other’s contributions to the program or project. Leveraging seasoned employees as coaches and mentors enables critical knowledge transfer about how.
Real work gets done.
Barriers can be overcome.
Insight from experience and lessons learned avoids repetition of past mistakes.
In the world of systems engineering and program management, there are good examples of talent management programs created within organizations that focus on creating and sustaining an integrative and collaborative mindset, for example, NASA’s Academy of Project/Program and Engineering Leadership (APPEL) is one example. See page 351 of The Book for a description of this Program and the rationale for it.
Another key capability that enables organizations to successfully execute their programs and projects is the establishment of methodologies. As described in Chapter 8 of The Book, a methodology and its related policies establish a system of practices, techniques, procedures, and rules used by a discipline to meet requirements and deliver value to stakeholders. Research shows that organizations using standardized practices, such as defined methodologies, perform better than those that do not, and that they have higher rates of achieving their original business goals. Despite their value, many organizations do not utilize documented, aligned, and integrated methodologies (PMI, 2016), instead relying on more ad hoc processes. Why? Because business process management and ongoing process improvement is not valued by organizational leaders. For commercial organizations, such activities are not viewed as generating direct revenue, and are considered as operational overhead that the organization must bear. For government organizations, the resources, time, and expertise may not be available within the agency to support process development and improvement.
Studies and examples clearly demonstrate that organizational leaders must embrace culture and capability development to effectively drive strategy and engagement. Organizational culture must value ongoing internal (continuous) improvement and put resources and support structures in place to build, assess, and improve required capabilities. If the company values it and enables it to happen, engineering program teams will commit to sustaining it.
Call to Action for Policymakers: Refocus Oversight and Accountability in the Right Ways
The continued poor performance of many government engineering programs and tightening budgets are pushing policymakers and government executives to transform their thinking, particularly related to program management capabilities. In the United Kingdom, the Major Projects Authority (MPA) was established in 2011 with a mandate to oversee the government’s portfolio of approximately 200 large programs and projects, totaling close to £500 billion in public funding. MPA manages a large number of engineering programs and projects covering transportation, infrastructure, technology systems and military defense with its largest programs and projects within the Ministries of Defense and Health (Cabinet Office, 2015). Since its establishment, MPA has advanced development of government program and project management capabilities and expertise as well as the accountability of major project business owners. MPA’s leadership reflected the type of interdisciplinary perspective needed to transform engineering program performance.
In January 2016, MPA merged with Infrastructure U. K. (IUK). The new organization, the Infrastructure and Projects Authority, combines “government expertise in the financing, delivery, and assurance of infrastructure projects. Expectations are high that program and project performance will continue to improve.
With regard to systems engineering, U.S. policymakers have received reports for over 16 years identifying opportunities to improve weapons systems acquisition programs through more effective use of system engineering practices, In March 2001, the Government Accountability Office (GAO) reported to the U. S. Congress that systems engineering, when applied to weapons systems before product development began, reduced cost and delivered better results. The GAO noted the Department of Defense policy did not allow systems engineering application until after requirements were set. In June 2015, the GAO completed an analysis of 78 major defense program requirements. Again, the GAO cited the need for application of systems engineering within the programs. But this time, chiefs within the Department of Defense acknowledged not only the need for systems engineering but also of stronger systems engineering program integration. The chief’s assessment suggests an opportunity for systems engineering accountability.
Call to Action for Industry and Professional Societies: Take an Interdisciplinary View
Trade and professional associations play a significant role in identifying and shaping effective practices that influence their organizational and practitioner members, particularly in the areas of standards and certifications.
In the field of systems engineering, the largest is the International Council on Systems Engineering (INCOSE). INCOSE is a not-for-profit membership founded in 1990 to share, promote, and advance systems engineering practice. INCOSE’s members fill roles that range from student to senior practitioner and technical engineer to program and corporate management. (Rebentisch, 2015). INCOSE currently has more than 16,000 members in 70 chapters and 35 countries. A recent addition is INCOSE Brazil – see the article by George Sousa provided in PPI SyEN 65. Within INCOSE, there are 43 Technical Operations Working Groups. The impact of INCOSE is described here. See also the Feature Article in this issue by Troy Peterson (mentioned previously in this article) that describes the transformation currently underway in the field of systems engineering. Many other engineering societies, such as IEEE, the American Society of Mechanical Engineers, the American Institute of Aeronautics and Astronautics, and many societies throughout the world also have communities within their membership focused on systems engineering.
An important role of professional discipline communities is to increase the depth and specialization of knowledge within the community. Professional certifications provide an objective method for evaluating an individual’s ability to apply knowledge and experience to real-life problems and challenges.
Another role of professional societies is to facilitate collaborative research programs within the academic and research community, organizational leaders, and practitioners to identify leading practices for managing complex engineering programs.
Call to Action for Researchers: Explore Interdisciplinary Systems
The critical need is to provide adequate systems, structures, culture, and practices to enable program management and technical leadership to effectively align their work and achieve performance objectives.
U.S. Air Force Major General Samuel C. Phillips established a “program management office” (PMO) that centralized authority over design, engineering, procurement, testing, construction, manufacturing, spare parts, logistics, training, and operations. NASA Administrator James E. Webb established
partnerships with 13 of the leading engineering universities across the United States and with funding from NASA, established management of technology (MOT) programs that targeted the education of future program leadership and academic research that focused on improving approaches for managing complex programs. Collectively, universities and NASA embarked on a relationship that spanned three decades and produced a broad range of research that is applied to today’s engineering programs. From MIT’s perspective, its MOT program has changed the way the world thinks about innovation – how innovation is taught, how innovation is best employed in the real world, and the power of innovation to propel the transformation of products and business. Vitally, the need for rigorous research and insight into critical areas of engineering program management still remains.
The great advantage that the research community offers is that it brings an objective viewpoint that helps to frame issues and opportunities in a way that does not get bogged down in interdisciplinary politics and turf battles. Coupling that objectivity within a multidisciplinary research team could produce groundbreaking insight and knowledge.
Food for Thought
You may want to give thought to how these “Calls to Action” can be energized. Who will lead them? How can we collectively engage people and organizations to take on critical leadership roles? Or are we doomed to just mire along with the status quo?
Who or which people or organizations have the power, authority, and influence to overcome factions and move integration forward?
Clearly INCOSE has major leadership responsibilities. How can INCOSE be further empowered to address the calls to action?
Babiceanu, Radu F. “Engineering Project Management Graduate Education in Integrated Software and Systems Engineering Environments.” Presented at the American Society of Engineering Education Annual Conference, Seattle, Washington, June, 2015. Paper available at https://www.asee.org/public/conferences/56/papers/13857/view
Banik, G. “Integration of Project Management Course to Satisfy ABET’s Requirements.” Presented at the American Society of Engineering Education Annual Conference, Seattle, Washington, June, 2015.
Cabinet Office, UK Government. Major Projects Authority Annual Report 2014-2015. Available at https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/438333/Major_Projects_Authority_Annual_Report_2015.pdf
Combe, Marge. Change Readiness: Focusing Change Management Where It Counts. Available at https://www.pmi.org/learning/library/change-readiness-11126
Conforto, E. C., M. Rossi, Eric Rebentisch, J. Oehmen, and M. Pacenza. Survey Report: Improving Integration of Program Management and Systems Engineering. Presented at the 23rd INCOSE Annual International Symposium, Philadelphia, Pennsylvania USA, June 2013. Available at https://www.pmi.org/learning/library?q=Survey+Report%3A+Improving+Integration+of+Program+Management+and+Systems+Engineering
Goldsmith, A.H., D. Hamilton, K. Hornsby, and D. Wells. Interdisciplinary Approaches to Teaching. Available at https://serc.carleton.edu/econ/interdisciplinary/how.html
IBM. Making Change Work: Continuing the Enterprise of the Future Conversation. Armonk, NY: IBM Corporation. Available at http://www-935.ibm.com/services/us/gbs/bus/pdf/gbe03100-usen-03-making-change-work.pdf
National Aeronautics and Space Administration (NASA). Academy of Project/Program and Engineering Leadership web site, http://appel.nasa.gov
Project Management Institute (PMI). Pulse of the Profession®, The High Cost of Low Performance: How will you Improve Business Results? Available at https://www.pmi.org/learning/thought-leadership/pulse
Pyster, A., D.H. Orwell, T.L.J. Ferris, N. Hutchinson, S. Enck, J. Anthony, D. Henry, and A. Squires (Eds.). Graduate Re3ference Curriculum for Systems Engineering (GRCSE™). Hoboken, New Jersey USA: Trustees of the4 Stevens Institute of Technology. Available at http://bkcase.org/wp-content/uploads/2014/04/GRCSEv10_Final.pdf
Rebentisch, Eric S. “Collaboration Across Linked Disciplines: Skills and Roles for Integrating Systems Engineering and Program Management.” Presented at the American Society for Engineering Education Annual Conference, Seattle, Washington USA, June, 2015. Available at TBD.
Whitcomb, C., J. Delgado, R. Kahn, J. Alexander, C. White, and P. Walter. The Department of the Navy Systems Engineering Career Competency Model. Available at http://www.dtic.mil/dtic/tr/fulltext/u2/a625688.pdf.
4.1 29th Annual INCOSE International Symposium 2019
Call for Submissions
The INCOSE International Symposium is the premier international forum for Systems Engineering. Participants network, share ideas, knowledge and practices, and learn more about the most recent innovations, trends, experiences and issues in Systems Engineering from world-class thought leaders in the field. The theme for the INCOSE International Symposium 2019 is:
System Applications for Global Challenges
INCOSE appreciates all submissions on Systems Engineering, with particular emphasis on:
Developing and Evolving Complex Sociotechnical Systems
Domains include but are not limited to:
Automation & Smart Cities
Healthcare and Biomedical
Aerospace and Defense
Transportation & Automotive
Energy & Environment
Emphasis Areas include but are not limited to:
System of Systems (SoS)
System Resilience, Reliability, Safety
Innovative Approaches: Agile, Iterative and Lean
System Security Engineering
Internet of Things (IoT)/ Cyberphysical systems
Paper, Panel, Tutorial Submission 16th November 2018
Notification of Acceptance 15th February 2019
Paperless Presentation Abstract Submission 15th February 2019
Paperless Presentation Acceptance 15th March 2019
Final Paper, Panel, Tutorial Submission 15th March 2019
4.2 The US Department of Defense Announces Digital Engineering Strategy
Dr Michael D. Griffin, U.S. DoD Secretary of Defense for Research and Engineering
Under Secretary of Defense for Research and Engineering Michael Griffin released the Department of Defense Digital Engineering Strategy on July 5.
The strategy promotes the use of digital representations of systems and components and the use of digital artifacts to design and sustain national defense systems.
The department’s five strategic goals for digital engineering are:
Formalize the development, integration, and use of models to inform enterprise and program decision making;
Provide an enduring, authoritative source of truth;
Incorporate technological innovation to improve the engineering practice;
Establish a supporting infrastructure and environment to perform activities, collaborate and communicate across stakeholders;
Transform the culture and workforce to adopt and support digital engineering across the lifecycle.
The DoD Digital Strategy is available in .pdf here.
4.3 From Grassroots to Classroom in Australia: How one Humble Event Turned into a State-wide Curriculum Resource
The first of its kind program helped teachers deliver STEM-related subjects and also foster an interest in engineering subjects
In what started as a fun way to engage local teachers in teaching engineering to their students in Newcastle has now turned into an accredited curriculum resource for educators across New South Wales (NSW).
Engineers Australia (EA) hosted an ‘Engineering Ingenuity’ workshop in Newcastle as a way for teachers to inspire their students to study STEM-related subjects.
The day was part of Engineering Week in Australia in 2014 and advertised as a way to “help your students achieve what’s needed to embark on a rewarding career in the engineering profession” with discussions and a site tour of electrical engineering firm Ampcontrol.
Engineers Australia Newcastle General Manager Helen Link says after the information day she was bombarded by teachers wanting more resources for their students. It didn’t take long for Ms. Link to realize her team was on to something great. She mobilized her small group of staff to speak to teachers to get to find out what they were missing in their STEM curriculums.
“After the discussions, we hosted a number of focus group meetings which found a real need for connecting our teachers in engineering Studies at our high schools with the engineering profession,” Ms. Link says.
Teachers not only needed help in delivering STEM-related subjects but also fostering an interest in subjects like engineering.
“What we found was that the teachers also needed help in contextualizing engineering theories and practice as a way to better explain the engineering studies syllabus,” Ms. Link says.
“They needed the resources to integrate the science and mathematics disciplines with the purpose of the science and practice of engineering.”
Volunteers and staff worked closely with engineering studies teachers to develop a pilot program where local EA volunteers hosted networking sessions focused on the modules in the current year 11 and 12 syllabus.
The program provided current industry information as well as practical application of aspects of engineering.
“Teachers attend one and a half hour sessions twice per school term, either face-to-face or by webinar, to develop an improved understanding and appreciation of the field of engineering.”
The content has been continuously improved over the years, with the number of schools taking part growing from six to 70 in just under three years.
“This year the course has been endorsed by NSW Education Standards Authority and we will start to deliver the program across NSW,” Ms. Link says.
The number of Year nine engineering studies classes at her school had “recently grown from one to three. The number of female students had grown from 20 per cent to 50 per cent“.
The amount of resources and modules is growing. Right now, teachers can start modules around learning the fundamentals of structures, driverless cars, and even how missiles are launched on Royal Australian Navy frigates.
Feedback from teachers has praised the practical nature of the course.
Teacher Michael Platt from Merewether High said that “being able to relate the content to real world practical situations and experiences (even anecdotal stories about different projects) helps to connect the students to the learning event. Helping us to broaden our experience can only improve the learning event.”
Speaking to the Newcastle Herald, teacher Lu Taylor said the program also “gave teachers who may not have received enough university-level training in engineering studies a deeper understanding of the field, which filtered down to students.”
Peter Cook from Kotara High School also only had good things to say.
“For teachers delivering the course in schools, the information presented is a critical component, and infinitely more useful when the discussion can be accessed later,” he said.
“It represents a wealth of experience and importantly a real-world wider perspective that resonates with students and that we otherwise can’t readily access.”
4.4 Cadets Lead Workshop in Detroit, Michigan
U.S. Military Academy cadets and staff joined the local area Army Reserve Officer Training Corps cadets to lead the 8th Annual West Point Leadership and Ethics in STEM Workshop on Friday, Oct. 26, at Marygrove College in Detroit, Michigan. The workshop featured a track for students and a track for educators, both focused on leadership, values and ethics, problem-solving, moral-reasoning and decision-making. The goals of the workshop were to provide participants with an opportunity to develop leadership and teambuilding skills; to reinforce the importance of ethical leadership in an increasingly technology-driven world; to promote ethics; to underscore the importance of competent and diverse leadership in the fields of science, technology, engineering and mathematics. Over 250 middle and high school students from the Detroit Metro Schools attended. Students were challenged to lead diverse groups, solve problems, and make values-based decisions in an atmosphere of friendly competition.
4.5 Airbus and Georgia Tech Open the Center for Model-Based Systems Engineering (MBSE)-enabled Overall Aircraft Design (OAD)
The Daniel Guggenheim School of Aerospace Engineering at Georgia Tech last week joined Airbus in officially opening the Airbus / Georgia Tech Center for Model-Based Systems Engineering (MBSE)-enabled Overall Aircraft Design (OAD).
This Center will contribute to the development and demonstration of a concurrent overall aircraft design process – taking full advantage of MBSE, interactive, parametric design space exploration and digital enablers with a team of 30 Georgia Tech researchers, doctoral students and Airbus experts.
Joining AE School Chair, Mark Costello at the opening ceremony were Dr. Marc Fischer, senior vice president flight physics at Airbus, and Amanda Simpson, the vice president of research and technology for Airbus Americas.
“We are proud to take the partnership with Georgia Tech to the next level,” said Fischer.
“Our future aircraft developments will benefit from much more integrated and interdisciplinary processes. Model Based Systems Engineering is at the foundation of this ambition and allows us to cover not just the conventional OAD disciplines, but also trade opportunities between engineering and manufacturing. This partnership aims to build a much larger ecosystem within and beyond Airbus, bringing our European and international partners on board.”
“This collaboration between Airbus and our Aerospace Systems Design Lab provides a unique opportunity for our students and faculty to work on research projects that are defining the next generation aircraft,” Costello said.
“Model-based Systems Engineering is a specific strength of the Aerospace Engineering School, and this collaboration with Airbus will enable us to help develop the next generation of aircraft design thinking.”
The collaboration has moved from a framing and ideation phase into project mode – delivering along a multi-year roadmap. Beyond contractual research work in the traditional sense, Airbus and Georgia Tech have engaged in a truly collaborative effort, where industrial experience and state-of-the-art research are combined.
“This Center is further demonstration of the value our American education institutions contribute to our entire global enterprise,” said Simpson.
5.1 Engineers Australia (EA)
Engineers Australia is the largest body of engineers in Australia. EA serves and represents around 100,000 professionals at every level, across all fields of practice. EA is committed to advancing engineering and the professional development of its members. Multiple organizations, institutions and government agencies engage with EA to leverage their expertise to create, accredit and assess engineering programs and practitioners.
EA has a rich history and has created awards programs to highlight the dedication and accomplishments of engineers. EA has a diverse group of members and hosts thousands of events each year. The EA website contains information on the organization’s governance, advocacy and regional facets.
5.2 Alpha Pi Mu
Alpha Pi Mu is an industrial engineering honor society that encourages any movement that advances the best interest of industrial engineering education. Alpha Pi Mu recognises industrial engineering students who show exceptional academic interests and abilities in their field. Part of Alpha Pi Mu’s mission is to unify the student body of Industrial Engineering departments and to cooperate with all organizations and persons working in the fields of industrial and systems engineering.
Goals of Alpha Pi Mu include increasing professional development among its members and promoting networking among faculty, graduate and undergraduate students.
5.3 Macau Association of Systems Engineering (MASE)
The Macau Association of Systems Engineering is a non-profit organization supervised and formed by Macau New Technologies Incubation Centre. It is a neutral platform to connect systems engineering and technical units from around the globe to promote collaborations and exchange based on the practice of ‘Probity, Fairness, Objectivity, Practicality, Science and Effectiveness’. MASE aims to introduce advanced system knowledge, techniques and experience to Macau and promotes local research and development of system applications. Objectives of MASE include:
Cooperating with systems engineering-related institutions in China, Taiwan, Hong Kong and Macau to provide information about technologies, resources, property and opportunities
Pre-analyzing new System Engineering-related products and projects by adhering to the ‘scientific, fair, pragmatic and efficient’ approaches and a ‘coordinating and responsible’ working spirit
Analyzing and assessing each project and recommending projects to its members
Cooperating with foreign Systems Engineering organizations to provide sustainable training programs
Assisting enterprises in Greater China to adopt Systems Engineering techniques and enhance Macau’s technological influence in the region
Studying the specifications, standards of practice and code of conduct of Systems Engineering, thereby providing value to the local government
6.1 Cameo Systems Modeler
No Magic Cross-platform Collaborative
Model-Based Systems Engineering (MBSE) Environment
Principal Consultant & Course Presenter, PPI
Cameo Systems Modeler provides tools to define, track, and visualise all aspects of systems in SysML models and diagrams. The environment provides an extensive set of features, the following list being a short summary:
Requirements Management including traceability, automatic numbering and versioning.
Implementing traceability between different levels of abstraction customizable to users’ needs.
Reports supporting standard text, RTF, HTML, Spreadsheet template (need to be saved as HTML format), XML template (DocBook or FO), Microsoft Word and Excel 2007 files.
Parametric Models and System MoEs can be solved using the built-in math solver as well as interfaces to well-known solvers such as Matlab, Mathematica and OpenModelica.
Distributed Use / Parallel Development.
Configuration Management with all designs stored in a single place and, module level versioning control and visual model differencing.
Security with different people in the project having different access levels to the projects stored in the MagicDraw Teamwork Server repository.
Interoperability – No Magic is an official member of the OMG Model Interchange Working Group (MIWG) and UML Diagram Interchange (UMLDI) Group both formed to demonstrate and facilitate interoperability between UML®-based modeling tools. The environment further provides extensive import/export options between No Magic products and other vendors tools.
Adjustments / Tailoring is possible, adapting the tool to a domain-specific profile modeling domain, adding Object Constraint Language expressions to any model element, providing a scripting engine to create a custom action for repetitive tasks and the Report Wizard with the customizable WYSIWYG reports.
Much more detailed information is available from the No Magic website.
7.1 IEEE Access
IEEE Access is an online only, open access journal of the Institute for Electrical and Electronics Engineers (IEEE). Established in May 2013, IEEE Access is a multidisciplinary journal that publishes original articles across all of the IEEE fields of interest. All IEEE Access published articles have a global reach via the IEEE Xplore digital library for free. The Editor-in-Chief is Michael Pecht, Ph.D.
Peer Review Process
Peer Review Process
IEEE Access has a rapid, binary peer review publishing system. The approximate time from submission to decision is 4–6 weeks. Articles are reviewed for technical substance and presentation quality by Associate Editors. The IEEE Access editors are responsible for adhering to the publication policies and procedures of IEEE and ensuring that the publication maintains the highest quality by selecting appropriate reviewers for each article in the peer review. After collecting all feedback from the reviewers, the final accept/reject decisions are made by the Associate Editor.
IEEE Access accepts the integration of multimedia within articles. Multimedia (video abstracts, graphics, and video demonstrations) is sent through peer review along with article submissions.
Interdisciplinary topics, or applications-oriented articles that do not fit in the scope of traditional journals.
Practical discussions of new experimental or measurement techniques, including negative results.
Practical articles that describe interesting solutions to engineering or information system design challenges.
Development of new or improved fabrication or manufacturing techniques.
Reviews of new or evolving fields oriented to assist others in understanding of these emerging topics.
IEEE Access hosts Special Sections that highlight a specific topic of general IEEE interest. Associate Editors propose a concentration area that emphasizes applications-oriented and interdisciplinary topics. The Associate Editor and the IEEE Access editorial staff then send out a “Call for Papers” to academic and industrial researchers to submit articles that identify and discuss technical challenges and recent results in the Special Section. Special Sections have a deadline for submission.
IEEE Access is supported by article processing charges (APC) that are paid by the authors. The APC is $1,750 (US) per article.
IEEE Access has been accepted into the Thomson Reuters Science Citation Index Expanded. Starting with Volume 1 of 2013, IEEE Access will be included in the Web of Science, Journal Citation Report, and Current Contents Engineering, Computing and Technology edition. According to IEEE Xplore, impact factor for IEEE Access in 2016 is 3.244.
Authors of published material have the ability to track usage metrics and citations of published articles. IEEE Access also allows readers and authors to comment on articles.
IEEE Access has a LinkedIn page, Facebook page, Twitter, and G+ page where newly published articles, upcoming conferences, popular article highlights, industry news, and engineering facts and tips are announced.
IEEE Access Website: https://en.wikipedia.org/wiki/IEEE_Access
7.2 Industrial Dynamics
Jay Wright Forrester
From the Amazon Website:
This is a 2013 Reprint of 1961 First Edition. It is a full facsimile of the original edition, now reproduced with Optical Recognition Software. This work has been cited as one of the most seminal works of the era. Forrester outlines industrial dynamics as an experimental, quantitative philosophy for designing corporate structure and policies that are compatible with an organization’s growth and stability objectives. Forrester believes that management systems possess an orderly and identifiable framework that determines the character of industrial and economic behavior. In this volume, he presents for the first time a methodology for detecting and exhibiting this structure for study.
Format: Hardcover, paperback
Publisher: Martino Fine Books (December 2, 2013)
7.3 The Systems View of Life
A Unifying Vision
Fritjof Capra and Luigi Luisi
From the Amazon Website
Over the past thirty years, a new systemic conception of life has emerged at the forefront of science. New emphasis has been given to complexity, networks, and patterns of organization, leading to a novel kind of ‘systemic’ thinking. This volume integrates the ideas, models, and theories underlying the systems view of life into a single coherent framework. Taking a broad sweep through history and across scientific disciplines, the authors examine the appearance of key concepts such as autopoiesis, dissipative structures, social networks, and a systemic understanding of evolution. The implications of the systems view of life for health care, management and our global ecological and economic crises are also discussed. Written primarily for undergraduates, it is also essential reading for graduate students and researchers interested in understanding the new systemic conception of life and its implications for a broad range of professions – from economics and politics to medicine, psychology and law.
Format: Hardcover, paperback, eTextbook
Publisher: Cambridge University Press; Reprint edition (September 29, 2016)
7.4 Focusing Change Management Where It Counts
PMI White Paper, July 2014
Change management is becoming a ubiquitous concept in the management literature, and has a natural home in project management literature. It is reasonably being viewed as a competency worthy of research, study, and mastery as part of leadership development. Change management concepts and practices are also increasingly being highlighted as integral parts of many disciplines, including portfolio, program and project management, as PMI has articulated (PMI, 2013). It is increasingly the subject of academic research and post-graduate degree programs.
And yet, the value of change management thinking and integration may be limited by insufficient attention to a single question: How successful can any change management approach be if the organization is not ready for the change? Examples abound:
Numerous health care organizations in the United States have had to make changes to comply with new health care laws. Though it’s been a challenge for all, for some it has been all but impossible. One health care organization, despite an admirable change management plan, cannot do required reporting because employees are mislabeling coded entries into new systems. Re-training efforts have not eradicated the errors. The problems have been traced to nursing directors who fear being held accountable for misjudging treatment decisions and are insisting on nonspecific treatment codes. Their lack of confidence in their nursing decisions limits the effectiveness of the change.
A corporation opted to expand globally for all the right strategic reasons. It planned the change carefully, with strong management sponsorship and commitment, and a well-vetted selection of partners in the new marketplace. But its decision-making process for getting operations up and running ran into hurdle after hurdle, causing near-doubling of both time and costs to implement. In retrospect, it understood that its inclusive, consensus decision-making model was incompatible with the top-down hierarchical model prevalent in the country culture of their new base of operations. Furthermore, with only lip service paid to inclusivity by its global partner, decisions that were made were often inaccurate, ultimately resulting in its inability to fully realize the benefits of the global alliance.
There are numerous models and processes put forward for managing change. But many of them, even those by highly respected gurus, begin with an assumption that bringing enough sponsorship, vision, communication and resources can overcome any obstacles and make an organization and its people ready to successfully adopt the change. That is likely a faulty assumption, as evidenced by the examples above.
There are, to be fair, models and processes that attempt to assess how ready an organization is for the change. But as Weiner (2009) notes, “Unlike individual readiness for change, organizational readiness for change has not been subject to extensive theoretical development or empirical study.”
In other words, there has not been a lot of substantiated direction on how to judge at a point in time whether an organization is ready for a change. Much of what has been offered is, at best, an overview of areas to consider. A few assessment vehicles have been formulated. They are often of limited focus, most often on employee readiness. The maturity of this type of organizational change readiness assessment is still young and incomplete.
What we do know, however, are the factors that contribute vitally to organizational change success. We know what aids change agility (Combe, 2014a). This area has been better researched and theorized. With this understanding of what makes organizations better able to absorb frequent and complex change, we can begin to identify, when faced with a need for change, a robust means to ask ourselves the critical question, “Are we ready for this change?” The answer to that question informs such decisions as:
Whether to proceed with the change.
How to address risks.
What resources will be most valuable?
Judging readiness for a change is a critical step in the Change Life Cycle Framework presented in PMI’s (2013) Managing Change in Organizations: A Practice Guide. It is shown in Figure 1 below as the second consideration of formulate change in the process of moving a strategic priority to a successfully implemented and well-sustained new operational reality. In this process, the assessment of change readiness is carried out in the management of the program and project portfolio even before the change is fully scoped.
Figure 1: Change Life Cycle Framework
Given the critical decisions that rest on the assessment of change readiness, this paper offers guidance to the portfolio, program and project management community for assessing readiness for a specific program or project. In doing so, it offers practical working knowledge for practitioners, and begins to add theoretical options to the scarcity identified by Weiner (2009).
7.5 The U.S. Department of the Navy Systems Engineering Career Competency Model
The U.S. Deputy Assistant Secretary of the Navy for Research, Development, Test and Evaluation is sponsoring a strategic initiative led by a team from the Naval Postgraduate School Systems Engineering Department to implement an overall approach to study and develop a systems engineering career competency model. The Naval Postgraduate School is working in collaboration with the U.S. Office of Personnel Management, Navy, Army, Air Force, Marine Corps, and the Missile Defense Agency to develop and verify the competencies used by defense systems engineers. Verification of the competency model is critical to allow it to be used as a basis for “high stakes” human resource functions for all of the U.S. Department of Defense. This paper presents the development of the systems engineering career competency model, and the subsequent efforts to have the systems engineering competencies verified.
7.6 Risk Management for Project Driven Organizations:
A Strategic Guide to Portfolio, Program, and Project Management Organization Success
Andy Jordan, PMP
From the Amazon Website:
Organizations invest a lot of time, money, and energy into developing and utilizing risk management practices as part of their project management disciplines. Yet, when you move beyond the project to the program, portfolio, PMO and even organizational level, that same level of risk command and control rarely exists. With this in mind, well-known subject matter expert and author Andy Jordan starts where most leave off. He explores risk management in detail at the portfolio, program, and PMO levels. Using an engaging and easy-to-read writing style, Mr. Jordan takes readers from concepts to a process model, and then to the application of that customizable model in the user’s unique environment, helping dramatically improve their risk command and control at the organizational level. He also provides a detailed discussion of some of the challenges involved in this process. Risk Management for Project Driven Organizations is designed to aid strategic C-level decision makers and those involved in the project, program, portfolio, and PMO levels of an organization.
Format: Kindle, hardcover, paperback
Publisher: J. Ross Publishing (May 1, 2013)
8.1 Educating the Systems Engineers of the Future
Dr. Cecilia Haskins, ESEP
Norwegian University of Science and Technology
Oli de Weck wrote in his final editorial for the 20th anniversary edition of Systems Engineering that
“Systems engineering is at the nexus of understanding real problems in society and in markets and clarifying what is needed, the channeling of creativity, the bundling of technical expertise, the expression of architecture, the emergence of inspiring and competitive design, the harmonization of humans and machines, and the sustainable transition to industrialization at scale. These are truly high stakes.”
I agree, the stakes are high and the consequences of failure will be felt in society as a whole. The challenge we face is that problem-solving at the societal scale is rarely thought of as ‘engineering’ and hence our discipline is rarely sought as an enabler for finding solutions. To be taken seriously, engineers need to come out of hiding behind the ‘introvert’ stereotype and assume positions of leadership.
Where do we teach systems engineering? Mostly we find our discipline in the engineering departments of major universities, which corresponds to the historical roots of systems engineering, but may exclude the talent we require to address de Weck’s analysis of what is needed.
It need not be so problematic if it were not for the single-minded tendency to fill engineering curriculum exclusively with engineering. The rare engineering student who takes philosophy, management, marketing and accounting is faced with very heavy workloads that may prepare them for the future but be difficult to achieve academically. Compounding this conundrum is the heavy emphasis on courses that teach only ‘hard engineering’ with a heavy reliance on optimization and ‘right’ answers. These students when faced with fuzzy requirements or the need to establish their own requirements are often frustrated, confused, and paralyzed. I speak from experience.
For the past seven years I have been teaching a course entitled Industrial System Design at NTNU with a laboratory component. I should set the stage by explaining that the course attracts Erasmus students who come to Norway from all over the world, bringing diverse academic and cultural backgrounds to the classroom. The laboratory is an exercise in serious play using Lego ™ bricks as the building medium. The students are only given two requirements, work in teams to build an agreed upon product, and do so by exclusively using the bricks, motors, and sensors from the Lego Mindstorms ™ series.
To accomplish this goal, students learn and practice a set of practical methods, such as scenario writing for ConOps, prototyping of preliminary design ideas, establishing requirements and interfaces that help the various teams coordinate their activities, and the importance of communication and frequent testing. The activities are time-boxed within a single semester – approximately 8 labs of 3 hours each – with a video recording made on the final day. Persons interested may view these videos online. While every year the students have succeeded, usually beyond any of my expectations, the path has been difficult for many of them. My one consolation is that I receive mails periodically from past students thanking me for their first introduction to an environment that gave some hints about their eventual real-world job experience.
Donaldson (2017) wrote on the importance of the ‘ologies, and I see a real need for students to apply non-engineering skills to requirements elicitation for their theses and capstone projects. A recent example involved designing an unprecedented virtual, fully digitized, air traffic monitoring and control system. Who are you going to call to describe a job that does not yet exist?
Rouse (2013) wrote eloquently on the importance of bringing systems engineering into healthcare and other public-private systems domains. The healthcare domain encompasses both the monitoring and control equipment for patients, as well as concurrently maintaining privacy and transparency for patient records – neither a trivial task.
Robotics specialist continue research to embed the machine with the human to address lost abilities, and to embed the human into the machine. Where are the systems engineers in these projects?
Piciaccia (2018) delved into the realms of artificial intelligence and machine learning to create a more efficient requirements elicitation method for projects that depend on digesting and extracting system needs from a mountain of standards, regulations, and other documentation. The oil and gas industry is a typical example of this situation. When training professionals in this domain, I often challenge them with the end-of-life scenario for oil well abandonment. This type of problem is the consequence when systems engineering fails to consider that all-important disposal phase of the system. Thankfully, young engineers seem to grasp the importance of this phase very quickly when faced with this scenario.
Returning to my Lego labs – in anticipation of the challenges facing the students upon graduation, recent labs have focused on recycling plants and Greenfield development of self-sufficient urban environments. Tomorrow’s engineers need to be able to understand societal needs for housing, transportation, medical and other services and be able to create innovative solutions that also respect a planet facing resource depletion and other shortages. In addition to Greenfield developments, engineers will also face the conundrum of aging infrastructures, brownfield developments, and resource recovery beyond simply collecting paper, plastics and glass. I probably do not even have a full handle on the scope of these issues, which are important topics within industrial ecology.
Students rise to the challenge of the unfamiliar, as I have experienced in a recent EU-supported Erasmus project entitle European Engineering Teams (EET). The project involved a transnational project-based learning course for students from four European universities. During this time, they tackled problems such as hospital-acquired illnesses, wind turbines as a source of electricity in developing nations, efficient refrigerated transportation, and recyclable pallets.
I believe it is essential that educators familiarize themselves with the INCOSE SE Vision 2025, loosely based on the 17 sustainable development goals from the UN (see Figure 1). These are the challenges your students must conquer as our generation retires. Some of these challenges may even be consequences of our own making, which is a sad reflection and renders it all the more compelling that we take on the perspective and the challenge of our colleague Oli de Weck to integrate a wider context for systems engineering into our education of systems engineers.
Figure 1: The 17 UN Sustainable Development Goals
About the Author
Cecilia Haskins is an industry Associate Professor of Systems Engineering at the Norwegian University of Science and Technology (NTNU) where she teaches courses in research methods, sustainable development, systems engineering, and project management. Cecilia entered academia after more than thirty years as an SE-professional. Her career spans large and small firms, commercial and government projects, as employee and entrepreneur. Her educational background includes a BSc in Chemistry from Chestnut Hill College, an MBA from Wharton, University of Pennsylvania, and a PhD in systems engineering from NTNU. This combination has contributed to her ability to understand issues with an insider’s view of both the business environments and the technical solution domains. She is recognized as a Certified Systems Engineering Professional (CSEP) since 2004. Her research focuses on improvements to engineering higher education, and innovative applications of systems engineering to socio-technical problems such as those encountered in software development, sustainable development, and global production systems. She is also owner of Global Sustainability Consulting.
8.2 Systems Engineering at Rochester Institute of Technology
Rochester Institute of Technology (RIT) is a private doctoral university within the town of Henrietta in the Rochester, New York metropolitan area. RIT is composed of nine academic colleges, including the National Technical Institute for the Deaf. The Institute is one of a few engineering institutes in the State of New York, including New York Institute of Technology, SUNY Polytechnic Institute, and Rensselaer Polytechnic Institute. It is most widely known for its fine arts, computing, engineering, and imaging science programs; several fine arts programs routinely rank in the national “Top 10” according to US News & World Report.
Edward C. Hensel is the Associate Dean for Research and Graduate Studies.
The RIT Industrial and Systems Engineering (ISE) Department is globally recognized for graduates who are highly sought after due to their ability to solve problems and transform organizations.
Provide ISE education that integrates experiential learning and applied research, with a student-centered approach, resulting in graduates who make immediate and long-lasting contributions in manufacturing, service, government, and academia.
The RIT ISE Department is globally recognized for graduates who are highly sought after due to their ability to solve problems and transform organizations. Our graduates, along with research performed by our students and faculty, positively impact the quality and competitiveness of manufacturing and logistics, the efficacy of health care, and the integration of sustainable practices into many settings.
In addition to the overarching values of the Kate Gleason College of Engineering (KGCOE) and RIT, ISE is founded on the following values:
Student Centered: The department makes decisions and behaves in a manner that demonstrates the primary importance of their students’ needs and interests.
Community: The department is a close-knit community characterized by respect for differences, inclusion of a diverse set of ideas and people, and friendly collaboration among the faculty, staff, and students.
Teaching Excellence: The department demonstrates continuous excellence and innovation in how they deliver classes to their students, and the support they provide to their students outside of class.
Experiential Learning: The department provides experiential learning throughout the undergraduate and graduate curricula via co-op, relevant projects, and practical experiences in their state-of-the-art labs.
Practical Research: The department’s innovative research makes an impact on the outside world, both directly through its application, and for their students via project opportunities and incorporation into the courses on offer within the department.
Innovation: The department’s teaching and research are characterized by new ideas and approaches, as well as a willingness to take risks.
A High-Tech Environment for Learning
The department has several specialized labs to aid students in their understanding of the fundamentals covered in lecture. These labs are made available to students in a variety of ways. First, during scheduled labs, the student has access to the lab and equipment with a faculty member present to answer any questions as well as observe demonstrations of assigned lab work. In addition, students have card-swipe access to the laboratories at posted times. The final form of lab access is for students in their final year working on their capstone design project, who have unlimited access to the real-time lab.
Figure 1: The Toyota Production Systems Lab at Rochester Institute of Technology, founded with support from Toyota Motor Engineering & Manufacturing in 2006
The Toyota Production Systems Lab, pictured in Figure 1 above, was founded in 2006 with support from the Toyota Motor Engineering & Manufacturing North America. The mission of this facility is to provide hands-on education in state-of-the-art production systems. Particular emphasis is placed on the concepts of teamwork, problem solving, and process improvement by studying the fundamental behavior of production lines. Residing in a 2,520 sq. ft. room in the Kate Gleason College of Engineering, this laboratory currently features two reconfigurable production lines with storage areas and kitting areas, conveyors, and conveyance operations. Over 25 activities have been designed to emphasize specific tools, concepts or techniques in an experiential way: line balancing, kanbans, heijunka, jidoka, takt time, among others.
This facility supports activities at varying levels for many different audiences, including: K-12 students, undergraduate students (both in engineering as well as other disciplines), and graduate students (both in engineering as well as other disciplines). The lab is an integral part of four courses in Industrial Engineering, integrated throughout the curriculum (one required freshman-level undergraduate course, one required senior-level undergraduate course, and two elective graduate courses).
8.3 Postdoctoral Fellowship: The Psychology of Decision Making in Systems Design
At the University of Toronto, a postdoctoral position is available. The successful applicant will join the research group led by Prof. Christoph Becker to explore how decision making actually happens in systems development project teams. The initial appointment will be for one year, with the possibility of extension based on funding and the direction of the research.
The desired start date is between now and January 1st, 2019. Information on how to apply as well as guidelines can be found at the University of Toronto page for Postdoctoral Fellows, here.
Instead of studying how designers and engineers should make decisions according to engineering methods, this project examines their actual practices while developing a psychological understanding of their decision-making and use it to design practical interventions for sustainability design in software systems with a focus on requirements, the key to sustainability. In leading this work, the applicant will establish themselves in the emerging area of sustainability design. Depending on the candidate’s interests, the focus can be on design and human computer interaction, requirements engineering, software engineering, information systems, or other disciplines. The applicant must have completed (or are about to complete) a PhD with relevance to the empirical focus of this project. Relevant fields include (but are not limited to) the collaborative and human aspects of software engineering, studies of requirements engineering or project management practice, design studies, behavioral software engineering, the psychology of judgment and decision making, and others. Knowledge of these areas is much more relevant to this project than classical ‘software engineering’ work such as modelling, the development of tools or modelling languages, method development or quantitative analysis.
8.4 University Degree on Systems Engineering in Switzerland
Lucerne University of Applied Sciences and Arts is the first institution in Switzerland to offer a Certificate of Advanced Study (CAS) degree on Systems Engineering for Smart Industries. The postgraduate CAS degree further educates engineers so that they can competently define, develop and test complex systems. In addition, the degree prepares engineers to manage increasingly complex, interdisciplinary system tasks typical in technologically-advanced projects.
Overview of the course content:
• Systems & Requirements Engineering Basics
• Model Based Systems Engineering
• Digital Transformation and Systems Engineering
• Project Management & Lean Methods for Systems Engineering
• Intellectual Property Basics
• Quality Assurance and Systems Engineering
• Systems Engineering Project
More information can be found (in German) here.
APPEL Knowledge Services, Academy of Project/Program and Engineering Leadership (APPEL), National Aeronautics and Space Administration (NASA)
APPEL Knowledge Services unites the award-winning curriculum and career development tools from the Academy of Program/Project & Engineering Leadership (APPEL) with the critical knowledge sharing and knowledge management capabilities of the Chief Knowledge Officer (CKO) to create a comprehensive, knowledge-dedicated resource for NASA. A key goal of the organization is to better meet the requirements for developing the NASA technical workforce while enhancing the ability to manage and share the different types of knowledge needed for mission success. The extensive online tools and materials from APPEL and CKO are featured on the unified APPEL Knowledge Services website, which combines critical aspects of both original websites in a single location.
The “How” of Transformation, by McKinsey & Company
A web page dedicated to helping organizations facilitate transformation. The web page explains the ‘what’ and ‘how’ of the McKinsey transformation approach and provides tips for leading companies out of a crisis as well as how to keep transformations on track. A valuable read for all companies seeking to execute a transformation process successfully by developing suitable ‘performance infrastructure’.
Infrastructure and Projects Authority: assurance review toolkit
This web page by The Infrastructure and Projects Authority (IPA) of the UK Government’s contains a collection of general guidance on reviews such as project validation review, strategic assessments, business justification reviews and delivery strategies for projects. As the IPA arranges and manages more than 200 independent assurance reviews of major government projects each year, the documents are useful in doing IPA reviews, and non-IPA reviews such as government or medium risk reviews.
10.1 Best Practices for Using Systems Engineering Standards (ISO/IEC/IEEE 15288, IEEE 15288.1, and IEEE 15288.2) on Contracts for U.S. Department of Defense Acquisition Programs
Office of the Deputy Assistant Secretary of Defense for Systems Engineering
Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics
The Department of Defense (DoD) and the defense industry have found that applying systems engineering (SE) processes and practices throughout the system life cycle improves project performance, as measured by the project’s ability to satisfy technical requirements within cost and schedule constraints. Simply put, projects that use effective SE processes perform better than those that do not. Given this knowledge, it is in the best interest of both acquirers and suppliers to ensure that defense acquisition projects use effective SE processes as the core of the technical management effort.
The purpose of this document is to assist:
Acquirers in tailoring the 15288 Standards to meet and communicate project needs.
Acquirers in incorporating appropriate language into a Request for Proposal (RFP) to invoke the standards and express relative importance of the standards in proposal evaluations.
Offerors in developing their proposals to leverage existing organizational processes, or propose alternative value-added tailoring, to support the RFP requirements and comply with the standards as tailored.
Acquirers in evaluating an offeror’s ability and commitment to effectively implement SE processes compliant with acquirer’s requirements based on the proposed Systems Engineering Management Plan (SEMP), project plan, master schedule, and past performance.
Acquirers in monitoring and enforcing a supplier’s compliance with the contract and delivery of the product/service/system.
15288 Standards Overview
Systems Engineering Planning Prior to Request for Proposal
Planning for Use of Systems Engineering Standards
Use of 15288 and 15288.1 on Contract
Use of 15288.2 on Contract
Request for Proposal and Source Selection
Development of the Request for Proposal
Suggested Request for Proposal Language
Offeror Response to Request for Proposal
Proposal Evaluation and Source Selection
Technical Review Compliance
Appendix A – How Project Characteristics May Drive Tailoring of the 15288 Standards
Appendix B – Work Aid for Definition of Outputs to Be Supplied
Appendix C – Example Tailoring Document Template
Appendix D – Definitions and Acronyms
Appendix E – References
Table 1: Systems Engineering Life Cycle Processes
Source: ISO/IEC/IEEE 15288, “Systems and Software Engineering–System Life Cycle Processes”
11.1 Introduction to System Dynamics
System Dynamics is a computer-aided approach to policy analysis and design. It applies to dynamic problems arising in complex social, managerial, economic, or ecological systems — literally any dynamic systems characterized by interdependence, mutual interaction, information feedback, and circular causality.
The field developed initially from the work of Jay W. Forrester. His seminal book Industrial Dynamics (Forrester, 1961) is still a significant statement of philosophy and methodology in the field. Within ten years of its publication, the span of applications grew from corporate and industrial problems to include the management of research and development, urban stagnation and decay, commodity cycles, and the dynamics of growth in a finite world. It is now applied in economics, public policy, environmental studies, defense, theory-building in social science, and other areas, as well as its home field, management. The name industrial dynamics no longer does justice to the breadth of the field, so it has become generalized to System Dynamics. The modern name suggests links to other systems methodologies, but the links are weak and misleading. System Dynamics emerges out of servomechanisms engineering, not general systems theory or cybernetics (Richardson 1991).
The System Dynamics Approach
The System Dynamics approach is founded on the scientific method. The goal of a system dynamics project is sometimes to build theoretical understanding, sometimes to implement policies for improvement, and often both. To do so, system dynamics modelers seek to: include a broad model boundary that captures important feedbacks relevant to the problem to be addressed; represent important structures in the system including accumulations and state variables, delays and nonlinearities; use behavioral decision rules for the actors and agents in the system that are grounded in first-hand study; and use the widest range of empirical data to formulate the model, estimate parameters, and build confidence in the conclusions.
Although the points below are presented as a list, modeling (and any scientific activity) is iterative – a continual process of formulating hypotheses, testing against data of all types, and revision of both formal and mental models.
The approach can be summarized as:
Beginning with a problem to focus systems thinking and modeling, involving the stakeholders whose understanding and action is required to implement change.
Defining problems dynamically, in terms of graphs over time (time series), employing actual data wherever possible.
Striving for an endogenous, behavioral view of the significant dynamics of a system, a focus inward on the structures and decision rules in a system that themselves generate or exacerbate the perceived problem.
Thinking of all concepts in the real system as quantities interconnected in loops of information feedback and circular causality, a consequence of the endogenous point of view.
Identifying the key variables essential to address the problem and deciding on an appropriate level of aggregation for them. System dynamics models range from highly disaggregate representations such as individual items or agents to highly aggregated representations, and can be deterministic or stochastic, as needed to address the purpose of the study.
Formulating a richly explanatory behavioral model capable of reproducing, by itself, the dynamic problem of concern, drawing on all relevant evidence, including qualitative and quantitative data. The model is usually a computer simulation model, but is occasionally left unquantified as a map capturing the important accumulations (stocks) in the system, the flows that alter them, and the causal feedback structure determining the flows.
Testing the structure and behavior of the model against all relevant evidence to deepen understanding and to build confidence in it, including the model’s ability to replicate historical data, ensuring the model is robust under extreme conditions, exploring the sensitivity of results to uncertainty in assumptions, and diagnosing the sources of unexpected model behavior.
Designing and testing policies to address the problem of concern, testing these against data and comparing to real-world policies that have been tried in the system or similar settings.
Documenting the model and its supporting sources so that it is as transparent as possible and enabling others to critique, use, and extend the work.
Working with stakeholders and others to help translate model-based insights into implementable policies, assist in implementation, assess the results, and improve both the model and policies.
Experiments conducted in the virtual world of the model inform the design and implementation of experiments in the real world. That experience then leads to changes and improvements in the virtual world, in participants’ mental models, and in actions taken in the real world, in an iterative process of continuous improvement.
Conceptually, the feedback concept is at the heart of the System Dynamics approach. Diagrams of loops of information feedback and circular causality are tools for conceptualizing the structure of a complex system and for communicating model-based insights. Intuitively, a feedback loop exists when information resulting from some action travels through a system and eventually returns in some form to its point of origin, potentially influencing future action. If the tendency in the loop is to reinforce the initial action, the loop is called a positive or reinforcing feedback loop; if the tendency is to oppose the initial action, the loop is called a negative or balancing feedback loop. The sign of the loop is called its polarity. Balancing loops can be variously characterized as goal-seeking, equilibrating, or stabilizing processes. They can sometimes generate oscillations, as when a pendulum seeking its equilibrium goal gathers momentum and overshoots it. Reinforcing loops are sources of growth or accelerating collapse; they are disequilibrating and destabilizing. Combined, reinforcing and balancing circular causal feedback processes can generate all manner of dynamic patterns.
The loop concept underlying feedback and circular causality by itself is not enough, however. The explanatory power and insightfulness of feedback understandings also rest on the notions of active structure and loop dominance. Complex systems change over time. A crucial requirement for a powerful view of a dynamic system is the ability of a mental or formal model to change the strengths of influences as conditions change, that is to say, the ability to shift active or dominant structure.
In a system of equations, this ability to shift loop dominance comes about endogenously from nonlinearities in the system. For example, the S-shaped dynamic behavior of the classic logistic growth model (dP/dt = aP – bP2) can be seen as the consequence of a shift in loop dominance from a positive, self-reinforcing feedback loop (aP) producing exponential-like growth to a negative balancing feedback loop (-bP2) that brings the system to its eventual goal. Only nonlinear models can endogenously alter their active or dominant structure and shift loop dominance. From a feedback perspective, the ability of nonlinearities to generate shifts in loop dominance and capture the shifting nature of reality is the fundamental reason for advocating nonlinear models of social system behavior.
The concept of endogenous change is fundamental to the System Dynamics approach. It dictates aspects of model formulation: exogenous disturbances are seen at most as triggers of system behavior (like displacing a pendulum); the causes are contained within the structure of the system itself (like the interaction of a pendulum’s position and momentum that produces oscillations). Corrective responses are also not modeled as functions of time, but are dependent on conditions within the system. Time by itself is not seen as a cause.
But more importantly, theory building and policy analysis are significantly affected by this endogenous perspective. Taking an endogenous view exposes the natural compensating tendencies in social systems that conspire to defeat many policy initiatives. Feedback and circular causality are delayed, devious, and deceptive. For understanding, System Dynamics practitioners strive for an endogenous point of view. The effort is to uncover the sources of system behavior that exist within the structure of the system itself.
These ideas are captured in Forrester’s (1969) organizing framework for system structure:
The closed boundary signals the endogenous point of view. The word closed here does not refer to open and closed systems in the general system sense, but rather refers to the effort to view a system as causally closed. The modeler’s goal is to assemble a formal structure that can, by itself, without exogenous explanations, reproduce the essential characteristics of a dynamic problem.
The causally closed system boundary at the head of this organizing framework identifies the endogenous point of view as the feedback view pressed to an extreme. Feedback thinking can be seen as a consequence of the effort to capture dynamics within a closed causal boundary. Without causal loops, all variables must trace the sources of their variation ultimately outside a system. Assuming instead that the causes of all significant behavior in the system are contained within some closed causal boundary forces causal influences to feed back upon themselves, forming causal loops. Feedback loops enable the endogenous point of view and give it structure.
Stocks (levels) and the flows (rates) that affect them are essential components of system structure. A map of causal influences and feedback loops is not enough to determine the dynamic behavior of a system. A constant inflow yields a linearly rising stock; a linearly rising inflow yields a stock rising along a parabolic path, and so on. Stocks (accumulations, state variables) are the memory of a dynamic system and are the sources of its disequilibrium and dynamic behavior.
Forrester (1961) placed the operating policies of a system among its rates (flows), many of which assume the classic structure of a balancing feedback loop striving to take action to reduce the discrepancy between the observed condition of the system and a goal. The simplest such rate structure results in an equation of the form NETFLOW = (GOAL – STOCK)/(ADJTIM), where ADJTIM is the time over which the level adjusts to reach the goal.
The importance of levels and rates appears most clearly when one takes a continuous view of structure and dynamics. Although a discrete view, focusing on separate events and decisions, is entirely compatible with an endogenous feedback perspective, the System Dynamics approach emphasizes a continuous view. The continuous view strives to look beyond events to see the dynamic patterns underlying them. Moreover, the continuous view focuses not on discrete decisions but on the policy structure underlying decisions. Events and decisions are seen as surface phenomena that ride on an underlying tide of system structure and behavior. It is that underlying tide of policy structure and continuous behavior that is the system dynamicist’s focus.
There is thus a distancing inherent in the System Dynamics approach — not so close as to be confused by discrete decisions and myriad operational details, but not so far away as to miss the critical elements of policy structure and behavior. Events are deliberately blurred into dynamic behavior. Decisions are deliberately blurred into perceived policy structures. Insights into the connections between system structure and dynamic behavior, which are the goal of the System Dynamics approach, come from this particular distance of perspective.
The System Dynamics Review, the journal of the System Dynamics Society, is the best source of current activity in the field, including methodological advances and applications. Other important journal sources include Management Science, the European Journal of Operational Research (EJOR), the Journal of the Operational Research Society (JORS), and Systems Research and Behavioral Science. For texts on the modeling process in System Dynamics, see Sterman (2000), Maani and Cavana (2007), Ford (2009), Morecroft, (2007), Wolstenholme (1990), and Richardson and Pugh (1981).
An early, interesting collection of applications is Roberts (1978); Richardson (1996) is a more recent two-volume edited collection in the same spirit, containing prize-winning work in philosophical background, dynamic decision making, applications in the private and public sectors, and techniques for modeling with management.
A current direction within the field is the use of model-based insights for organizational learning, represented most forcefully in Senge (1990) and Morecroft and Sterman (1994). The important new effort to build models with relatively large groups of experts and stakeholders, known as group model building, is described in Vennix (1996) and Richardson and Andersen (2010).
Richardson (1991/1999) puts the endogenous feedback perspective of the System Dynamics approach in its historical context and includes an extensive bibliography.
Ford, A. 2009. Modeling the Environment. Washington, DC: Island Press.
Forrester, J.W. 1961. Industrial Dynamics. Cambridge, MA: The MIT Press. Reprinted by Pegasus
Communications, Waltham, MA.
Forrester, J.W. 1969. Urban Dynamics. Cambridge, MA: The MIT Press. Reprinted by Pegasus Communications, Waltham, MA.
Maani, K. E. and R. Y. Cavana. 2007. Systems Thinking, System Dynamics: Understanding Change and Complexity. Aukland: Prentice Hall.
Morecroft, J. D. W. 2007. Strategic Modeling and Business Dynamics: a Feedback Systems Approach. Chichester: Wiley.
Morecroft, J. D. W. and J. D. Sterman, Eds. 1994. Modeling for Learning Organizations. System Dynamics Series. Cambridge, MA: Pegasus Communications.
Richardson, G.P. 1991/1999. Feedback Thought in Social Science and Systems Theory. Philadelphia: University of Pennsylvania Press; reprinted by Pegasus Communications, Waltham, MA.
Richardson, G.P., Ed. 1996. Modelling for Management: Simulation in Support of Systems Thinking. International Library of Management. Aldershot, UK: Dartmouth Publishing Company.
Richardson, G.P. and D. F. Andersen. 2010. “Systems Thinking, Mapping, and Modeling for Group Decision and Negotiation.” Handbook for Group Decision and Negotiation, C. Eden and D. N. Kilgour, Eds. Dordrecht: Springer, 2010, pp. 313-324.
Richardson, G.P. and A.L. Pugh III. 1981. Introduction to System Dynamics Modeling with DYNAMO. Cambridge, MA: The MIT Press. Reprinted by Pegasus Communications, Waltham, MA.
Roberts, E.B. 1978, Ed. Managerial Applications of System Dynamics. Cambridge, MA: The MIT Press. Reprinted by Pegasus Communications, Waltham, MA.
Senge, P.M. The Fifth Discipline: The Art and Practice of the Learning Organization. New York:
Sterman, J.D. 2000. Business Dynamics: Systems Thinking and Modeling for a Complex World. Boston: Irwin McGraw-Hill.
System Dynamics Review. 1985-present. Chichester, U.K.: Wiley, Ltd.
Vennix, J. A. M. 1996. Group Model Building: Facilitating Team Learning Using System Dynamics. Chichester: Wiley.
Wolstenholme, E.F. 1990. System Enquiry: a System Dynamics Approach. Chichester, U.K.: John Wiley & Sons, Ltd.
For more information on systems engineering related conferences and meetings, please proceed to our website.
PPI may be a small company, but our impact in improving enterprises worldwide, and the quality of life of their engineering workforce, is large. Clients have supported PPI with three new locations over the last two months: Aberdeen, MD and Portland, OR in the United States, and Krakow, Poland, with Doha in Qatar to be added next week and Jeddah in Saudi Arabia to be added in January. The map shown in Figure 1 below highlights the locations where PPI courses have been delivered.
Figure 1: World map showing locations where PPI courses have been delivered
13.2 PPI Participates in EnergyTech 2018
PPI team members, Robert Halligan (managing director) and René King (senior engineer) enjoyed a wonderful week in Cleveland, Ohio at the EnergyTech conference from 22-25 October 2018. The conference kicked off with a PPI-presented Fundamentals in Systems Engineering Workshop held on Monday followed by participation by Robert Halligan in a panel on Advancing the Systems Engineering Practice on Wednesday and a panel and presentation on Integrating Project Management and Systems Engineering on Thursday. The conference brought a wonderful opportunity for PPI to connect with great thinkers and learn from the most experienced and knowledgeable in the infrastructure, energy and technology industries, whilst sharing PPI’s systems engineering expertise. Notable topics in the conference included: cyber security in infrastructure, applying systems engineering to megaprojects and the move towards digital engineering. PPI looks forward eagerly to EnergyTech 2019 which will be held in Cleveland,Ohio. The organizers guarantee it to be bigger and better than ever!
Left to right: John Johasz (EnergyTech conference chair), Robert Halligan and René King
13.3 PPI Gears Up for First Delivery of Medical Device Risk Management (MDRM) Course
Next week is an exciting time for PPI as risk management and medical devices expert, Bijan Elahi, presents the first ever public PPI course on this prominent topic in the medical industry. Bijan is the winner of the Educator of the Year Award from the International System Safety Society and is passionate about elevating global knowledge and proficiency in medical device risk management for the benefit of companies and society.
The three-day course will take place in Eindhoven in the Netherlands from the 20-22 November and will cover a comprehensive range of topics including the systematic analysis, estimation, evaluation and control of safety risks associated with medical devices. The content of the course includes management of risk associated with product development as well as post-market risk. The course will equip participants with tools needed for successful management of risk in order to predict and prevent serious harm to patients and loss of business. For more information, please see the MDRM course on the PPI website, here.
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/
Upcoming locations include:
Adelaide, Australia (P006-749)
19 Nov – 23 Nov 2018
Eindhoven, the Netherlands (P006-750)
26 Nov – 30 Nov 2018
Upcoming locations include:
Pretoria, South Africa (P007-474)
28 Jan – 01 Feb 2019
Upcoming locations include:
London, United Kingdom (P1135-155)
10 Dec – 14 Dec 2018
Ankara, Turkey (P1135-158)
07 Jan – 11 Jan 2019
Upcoming locations include:
Amsterdam, the Netherlands (P958-56)
03 Dec – 07 Dec 2018
Melbourne, Australia (P958-57)
18 Feb – 22 Feb 2019
Washington, D.C., United States of America (P958-59)
13 May – 17 May 2019
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 (Presented by Bijan Elahi)
Upcoming locations include:
20 Nov – 22 Nov 2018 (P1848-1)
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.
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.
Date: 20-21 November, 2018
Location: Bedfordshire, United Kingdom
Date: 20-25 July, 2019
Location: Orlando, USA
Date: 21-25 October, 2019
Location: Cleveland, USA
Date: 18-23 July, 2020
Location: Cape Town, South Africa
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: email@example.com
Ralph Young, Editor, email: firstname.lastname@example.org
René King, Managing Editor, email: email@example.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
Copyright 2012-2018 Project Performance (Australia) Pty Ltd, trading as
Project Performance International.
Tell us what you think of PPI SyEN. Email us at firstname.lastname@example.org.