Home » SyEN Newsjournal » PPI SyEN 64

PPI SyEN 64

Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 64

In This Edition

Quotations to Open On

Feature Article

MBSE Uptake in Engineering Practice by Dr. Bruce Cameron

Article

Integrating Program Management and Systems Engineering, by Dr. Ralph Young
Social and Ideological Challenges Faced by the Engineering Community
Do Engineers Lack Social Skills?

Systems Engineering News

Nature-based Inspirations for Systems Engineering, Georgia Tech News Center

Featured Organizations

Institute of System Architectures in Aeronautics
Norway Industrial Systems Engineering Research Group

Conferences and Meetings

Some Systems Engineering-Relevant Websites

Systems Engineering Publications

Strategy and Product Development for Complex Systems
A Complexity Primer for Systems Engineers
Systems Product Line Engineering Handbook
Megaproject Management: Lessons on Risk and Project Management from the Big Dig
Understanding the Front-end of Large Scale Engineering Programs
Journal of Systems Science and Systems Engineering
Sociotechnical System Safety: Hierarchical Control versus Mindfulness
Healthcare Information Challenges: The Cognitive Challenge

Systems Engineering Tools News

Scaled Agile Framework

Education and Academia

University of Technology, Sorbonne Universities

Standards and Guides

Systems Engineering Plan Preparation Guide

Definition to Close On

PPI and CTI News

Upcoming PPI and CTI Participation in Professional Conferences

PPI and CTI Events

QuotationS to Open On

“There is very little that must be done in systems engineering practice. There are things that we choose to do, or choose not to do, for exactly the same reason – producing the best result on the balance of probabilities.”

Robert John Halligan

“I believe that the fundamental difficulty is that we have all become so entranced with technique that we think entirely in terms of procedures, systems, milestone charts…reliability systems, configuration management, maintainability groups and other tools of the system engineer and manager. We have forgotten that someone must be in control and must exercise personal management, knowledge, and understanding to create a system…. Systems, even very large systems, are not developed by the tools of systems engineering, but only by engineers.”

1969 speech by Robert Frosch prior to the International Space Station and prior to becoming NASA Administrator

“The ultimate measure of a person is not where he or she stands in moments of comfort and convenience, but at times of challenge and controversy.”

Martin Luther King

Feature Article

MBSE Uptake in Engineering Practice

Dr. Bruce Cameron

Massachusetts Institute of Technology (MIT)

bcameron@mit.edu

Daniel Mark Adsit

Massachusetts Institute of Technology (MIT)

adsit@sdm.mit.edu

Abstract

The use of models is ubiquitous in engineering, but data on model use and user sophistication in engineering-driven firms is remarkably sparse. Furthermore, some predict a sea change in engineering workflow through model-based system engineering (MBSE). Despite benefits that modeling provides, the prevalence of effective modeling techniques in industry is an open question.

Emerging academic and educational experiences, including massive open online courses (MOOCs) and similar online offerings, are a new opportunity to learn about industry practices. In this paper, we draw on data from the “Architecture and Systems Engineering: Models and Methods to Manage Complex Systems” online program from the Massachusetts Institute of Technology (MIT), which has enrolled 4200 participants, to understand how models are used in practice. We use aggregated data from enrollment surveys and poll questions to investigate model use by participants and their organizations.

The results in this paper demonstrate that while modeling is widely recognized among course participants for its potential, the actual deployment of models against problems of interest is substantially lower than the participant-stated potential. We also find that in the practice of engineering, many participants reported low use of basic modeling best practices, such as documentation and specialized programs. Furthermore, we find that participants overstate the deployment of modeling practices within their organizations.

We believe that this research is a fresh use of descriptive analysis to report on actual modeling practices. Future research should target more detail about modeling practices in engineering-driven firms, and the reasons why modeling adoption is low or overstated.

The “Architecture and Systems Engineering: Models and Methods to Manage Complex Systems” certificate program is a series of four online courses offered by the Massachusetts Institute of Technology (MIT) for professional audiences covering models in engineering and model-based system engineering. For more information, visit https://sysengonline.mit.edu/.

Introduction

Throughout history, the use of models spans nearly all disciplines, including engineering. Early examples of models include dioramas of buildings and figurines to plan battlefield movements, while modern examples cover a variety of applications from equations through complex simulations. Beyond historical models, recent software, analytical, and technology advancements have positioned modeling in engineering with promises to reduce cost, improve performance, and make collaboration more effective. Madni and Sievers (2018) indicate that models are a mechanism to simplify complex information for a specific “purpose”. Furthermore, model-based system engineering (MBSE) has been trending over the last 5 years, arguing for a central model to serve as a means of coordinating system design.

While modeling holds a rich history, wide application in engineering, and profound potential benefits, the realization from advanced and innovative modeling techniques depends entirely on awareness, application, and adoption by engineering-driven firms. One of the challenges to MBSE is a reliance on network effects, the idea that the benefit to the team grows nonlinearly with the adoption by other users. Furthermore, there is little data about adoption of modeling by engineering-driven practitioners or firms. Obtaining and leveraging data in this area is important to assess whether engineers apply effective modeling techniques in practice.

Modern educational experiences include environments beyond the traditional classroom. Massive open online courses (MOOCs) assemble learners from around the world from different backgrounds. For example, edX.org lists over 1900 available courses in Introductory, Intermediate, and Advanced levels at the time of this writing. These programs extend the educational reach across geographies, industries, firms, and knowledge silos through interactive videos, surveys, and discussion boards. Beyond exposure to course content, MOOC participants engage in both individually-paced and community learning environments.

MOOCs provide access to large groups of participants simultaneously, orders of magnitude larger than is otherwise practical within traditional constraints. In a prior study of participant “subpopulations” in MOOCs, Kizilcec et al. (2013) concludes that effectively leveraging of participants’ “prior knowledge” enhances MOOC content effectiveness because it “mediates encounters with new information.” We propose that the overall MOOC environment and interactive mechanisms facilitate a practice-sharing role, in addition to the traditional content delivery style of online and video education.

The “Architecture and Systems Engineering: Models and Methods to Manage Complex Systems” certificate program offered by the Massachusetts Institute of Technology (MIT) is a series of four online courses with enrollment of 4200 participants with common interest in model-based systems engineering over the past two years. As career opportunity becomes increasingly chaotic and professionals endure a “life-long” state of “transition” (Vuolo et al., 2012), the participants who enroll in these courses for career training and growth represent a potential population sample to learn about engineering practices. While it is debatable whether this fee-for-service offering with fewer than 10,000 participants fits the definition of a MOOC (Jordan 2015), participants with experience in industry engage through both public and corporate-supported program enrollments.

During the “Architecture and Systems Engineering” program at MIT, participants complete an enrollment survey and respond to interactive polls about modeling in engineering. Responses reported by participants through these mechanisms is an opportunity to learn about the modeling use and sophistication in engineering-driven firms. This data is sufficiently anonymized to support useful learning about models in engineering without exposing participants or their organizations to privacy risk. In this paper, our research objective is to analyze survey and polls data from these courses to measure model use and user sophistication in engineering-driven firms. Through a descriptive analysis of participants and the firms they represent, this paper seeks to fill a perceived gap in the currently available research in this area.

This paper begins with a research outline and analysis of methods used on survey and polls data from the “Architecture and Systems Engineering” program at MIT. The results are then presented, followed by discussions about the implications about the use of models in industry, the future of MBSE, the use of MOOC data for research, and approaches for studies in engineering.

Research outline & analysis methods

The analysis in this paper leverages data from two sources in the “Architecture and Systems Engineering” program at MIT to measure model use and user sophistication in engineering-driven firms:

An enrollment survey submitted by all participants at the beginning of the program. A subset of survey questions is used to describe the participants based on relevance to the research objective.
Polls question responses submitted by participants throughout the courses in the program. Polls are similar to a multiple-choice quiz, and participants see all responses after submitting the poll. A subset of poll questions is selected based on relevancy to the research objective.

While this analysis provides access to potential insights about the underlying research objective, several important limitations are discussed that impact this and future research.

Survey and polls question analysis

The enrollment survey and poll questions enable participants to report details about themselves and their organizations. In order for an analysis of the survey and polls to effectively address the research objective, several key conditions about the population sample, question responses, and questions themselves must be met.

First, the participants in the course must reflect an appropriate population sample to address the research objective by responding to the polls. This means that the respondents must have some affinity with engineering-driven firms. Course participants have already self-identified with models in engineering based on the course subject matter. Additionally, course participants are analyzed based on age, educational, and career details reported through the enrollment survey. We believe that this detail sufficiently identifies these participants as an appropriate population sample to represent modeling use and user sophistication in engineering-driven firms.

Second, the total number of responses to each poll question used in this analysis ranges from 637 to 803. We believe that this is a sufficient number of qualified responses for the research objective.

Third, the poll questions must reveal the details concerning the effective use of models. In this research, the poll questions and responses already existed in the courses, and were not designed beforehand for this project. This presents several data challenges that are covered in the limitations section (provided in the following section). Nonetheless, poll responses from six poll questions that cover MBSE, documentation, languages, programs, and queries provide insight into model use and user sophistication in engineering-driven firms. Therefore, we argue that it is possible to extract meaningful conclusions about the research objective using data from the participants.

Limitations of the survey and polls analyses

The analysis methods used with the enrollment survey and polls data are subject to several important limitations that impact the research objective.

First, we assume that participants in this course reflect a broad population of engineering practice. This assumption relies on awareness about current practices inside organizations. However, some participants might have insufficient exposure within their organizations to accurately report in the polls. Other participants might not be familiar enough with modeling technology and tools to accurately answer the questions. While the results from the enrollment survey indicate that participants have enough exposure to accurately respond to the polls, this uncertainty poses a risk to the research objective.

Second, participants in the courses self-report answers to the survey and poll questions. Therefore, responses that do not represent the accurate or complete situation are possible for several related reasons. For example, participants might misunderstand the question. They may misrepresent information for personal or privacy reasons. Some participants might select random responses to quickly advance to the next screen or obtain a certificate as quickly as possible. Finally, reported results might be less accurate than results that are obtained through observation. Therefore, self-reported results pose a risk to the research objective.

Third, the poll questions were originally designed for an engaging course experience. Therefore, certain aspects of the data are inconvenient. For example, the respondents are not necessarily the same across all polls because some participants may have added or dropped between courses in the program. Additionally, there is no data linkage between enrollment survey and polls responses. This means that it is not possible to analyze polls responses about specific population subsets. Finally, there is no linkage in the data between some poll questions. These factors limit the possible analysis options and pose a risk to the research objectives.

Results

This section presents the analysis of model use and user sophistication in engineering-driven firms using enrollment survey and polls question data from the “Architecture and Systems Engineering” program at MIT.

Results about participants reported through enrollment survey

This section analyzes survey responses about the age, education, and careers. These responses provide insight into respondents for the poll questions about models.

Age details from survey

Participants indicate their age in the survey by providing their birth year. Age distribution is important because it may reflect whether participants are working-age, versus still in school or retired. It may also indicate whether participants are in early, mid, or late career stages. These factors could impact participant knowledge about practices in organizations or industries.

Figure 1 indicates the distribution of participant ages. Approximately 80 percent of participants reported ages younger than 50 years old. The largest fraction of participants reported ages in the 30s (33 percent), while approximately equal numbers reported ages in the 20s and 40s (23 and 22 percent, respectively). We conclude that this distribution likely reflects many mid-career professionals with multiple years of experience in their organizations and industries, and incorporates a significant number of younger professionals with possible exposure to recent modeling technology trends in academia.

Figure 1.

We believe that these participants reflect a suitable age distribution to provide useful answers to the poll questions about their organizations and industries.

Education details from survey

Participants indicate their highest level of education and enrollment reasons in the survey. These education details may reveal information about participant roles, responsibilities, and subject matter interests. For example, participants with advanced degrees may have more knowledge about modeling techniques in their organizations than other professionals, while enrollment might provide insight into individual knowledge gaps or organizational priorities.

Figure 2 indicates the highest degree attained by participants. Over 90 percent of course participants reported attaining a four-year college degree or higher. In this subset of participants, 57 percent reported a graduate degree and 43 percent reported a bachelor’s degree. These results reflect a highly educated participant enrollment, and align with the recommended prerequisites to enroll in the courses.

Figure 2.

Participants reported enrollment reasons in the survey using five qualitative levels ranging from “Extremely Important” to “Not Important”. Figure 3 reflects the top enrollment reasons reported by course participants. The reasons “Learn course content” and “Lifelong learning” were the most frequent reasons cited, based on the number of participants who selected “Extremely Important” or “Very Important” levels. These responses suggest that participants are interested in models, aspire to stay current about emerging model topics, and may consider models as an opportunity for themselves or their organizations.

Figure 3.

We believe that highly educated participants with a strong interest in models are appropriate to provide insight about modeling practices in their organizations through the poll questions.

Career details from survey

Participants provide their industry and number of years of experience in the survey. These career details may indicate whether participants are employed by engineering-driven firms, and whether participants are experienced engineers themselves.

Figure 4 indicates participants by industry. While participants reported affiliation with fifteen different industries, the “Manufacturing”, “Professional and Technical Services”, and “Other Services” industries accounted for 85 percent of enrollment. While “Other Services” is very vague, the other top industries are highly likely to include engineering-driven firms.

Figure 4.

Participants reported number of years of professional and engineering experience across six classifications ranging from “zero years” to “more than 15 years”. Figure 5 indicates general professional and engineering years of experience for participants. Overall, participants reported higher years of general professional experience and lower years of engineering experience. For example, almost 60 percent of participants reported more than ten years of professional experience, while over 50 percent of participants had three years or less of engineering experience.

Figure 5.

While not all participants are necessarily experienced engineers, we argue that this industry and experience distribution reflects sufficient association by participants with engineering-driven firms. Additionally, over 40 percent of participants received corporate sponsorship, which demonstrates commitment by organizations to develop organizational competence in engineering areas.

Results: Modeling use and sophistication

This section analyzes poll responses about model-based system engineering (MBSE), documentation, languages, programs, and queries. These responses provide insight into respondents’ modeling use and user sophistication in engineering-driven firms.

Model-based system engineering practices from polls

In the polls, participants provide details about organizational and individual MBSE approaches. Even though MBSE is a specific term, it is possible for participants to interpret the scope as modeling in general. We believe that these questions are an effective measurement for modeling practices using the polls data.

First, participants are asked “Does your organization use an MBSE approach?” Second, participants are asked “Have you ever been asked to formally evaluate or critique an MBSE approach?” Figure 6 indicates the participant responses about MBSE. Based on the responses submitted, 35 percent of participants reported an organization with an MBSE approach, while nine percent of participants reported being asked to perform or evaluate an MSBE approach.

Figure 6.

According to these results, approximately one quarter of participants who reported that their organizations used an MBSE approach had been asked to evaluate an MBSE approach. This difference is surprising considering that these questions were asked at the same time and received nearly identical total numbers of total responses. If program participants are highly educated and experienced professionals in their organizations, it is logical to assume that they would be involved with reviewing models if their organizations had adopted MBSE approaches, because effective MBSE and modeling implementations require collaboration. We propose that this discrepancy may reflect a disconnect between perceived and actual behaviors within organizations.

Documentation and data practices from polls

In the polls, participants provided details about individual and organizational documentation and data methods. While documentation and data are not necessarily models, these methods are crucial indicators about modeling practices. In particular, structured and interconnected data enables modeling because it can be quantitatively analyzed.

Regarding documentation, participants are asked for “documentation methods have you used.” Figure 7 indicates the documentation methods used by participants. Microsoft Word and PowerPoint-based methods were most commonly selected. Assuming that Microsoft Office suite is the standard general purpose application suite in many organizations, it makes intuitive sense that most participants would have used Word and PowerPoint. This result is not particularly useful because having used them at some point in the past does not indicate persistent or systematic use. However, some of the least used methods are the most closely associated with modeling, including SysML, UML, and DSM. We believe that lower use of these methods is more interesting for the research objective.

Figure 7.

Regarding data, participants are asked the “primary mode of capturing system data” in their organization. In contrast to the previous question about individual awareness, this question asks about organizational behavior. Figure 8 indicates the primary modes of data capture. Almost 90 percent of participants reported documents or predominantly documents as the primary mode to capture system data. Approximately 11 percent of respondents chose models or predominantly models. The number of participants that selected models appears surprisingly low, especially considering that it is roughly one third of the fraction of participants who indicated that their organization uses an MBSE approach.

Figure 8.

While the documentation and data are not the same as modeling, they are closely related. We conclude that the low familiarity with specific documentation methods combined with the dominance of documents further indicates low use of modeling.

Language, program, and query practices from polls

In the polls, participants provided details about the use of languages, programs, and queries that are related to modeling. As with documents and data, these applications are not models themselves. However, patterns about language, program, and query usage may reveal modeling practices.

Regarding languages and programs for modeling, participants are asked about “the extent to which you have used” any of 20 specific examples on a qualitative scale ranging from “No Use” to “High Use”. Figure 9 indicates the use of languages and programs by participants. Almost 93 percent of responses indicated “No Use” of a program or language, while over 96 percent indicated either “No Use” or “Low Use.” For a highly educated, mid-career participant profile reflected by the enrollment survey, we observe that the effective use of these languages and programs among this population sample is very close to zero.

Figure 9.

Additionally, participants are asked “the most sophisticated query type” they had written. Figure 10 indicates the most sophisticated query types reported. Over 60% of respondents reported Microsoft Access databases, spreadsheets, or less sophisticated queries. While Access is a database, it is a basic database distributed with the Microsoft Office suite that includes Word and PowerPoint. We believe that Microsoft Access is not the optimal application for effective modeling. However, the level of SQL usage reported indicates higher penetration of sophisticated techniques than the language and program results.

Figure 10.

Languages and tools provide an indication of modeling practices. We conclude that extremely low penetration of languages and tools and unsophisticated use of queries indicates underdeveloped modeling practices by course participants and within their organizations.

Discussion

The results of this research are based on analysis of enrollment survey and poll data from the “Architecture and Systems Engineering” program at MIT. Based on the enrollment surveys, many participants in the program are highly educated, mid-career professionals with interest in the course content. While modeling and MBSE represent important interests, poll data indicates that model use is relatively low and unsophisticated by this population sample and the engineering-driven firms that it represents.

It seems logical that individuals or organizations who perceive themselves as unsophisticated modelers would enroll in a course to improve knowledge about modeling. If the program enrollment favors participants who perceive themselves or their organizations as unsophisticated modelers, then that could explain the lack of effective modeling practices observed in the polls data. However, there is an apparent deficiency in self-awareness about modeling practices based on contradictions between different polls results. Therefore, while this course may be attractive to individuals who perceive themselves as unsophisticated modelers, enrollment in the courses is broader.

However, we also acknowledge that this analysis is imperfect. In particular, the analyzed data covers a limited scope, retroactively repurposes questions, and relies on details that are self-reported by participants. Observation may provide a more accurate means to uncover actual behavior. Additionally, course participants might not be equipped or empowered to reveal practices that the analysis seeks. For example, participants who respond to polls might interpret the questions differently, might not be familiar enough with the modeling or MBSE approaches, or might not have full knowledge of their organizations. There are few, if any, approaches that could mitigate these challenges using the existing data.

While custom questions or data collection methods could have been designed from scratch, we argue that the existing data is sufficient to provide useful insights about model use and user sophistication in engineering-driven firms per the research objective. While it is entirely possible that modeling or MBSE initiatives are underway inside organizations without course participant knowledge, this seems unlikely based on the highly educated mid-career profile uncovered in the enrollment surveys. We believe that participants who enroll in this program are very likely to be familiar with modeling initiatives in their own organizations. Furthermore, any misinterpretation by different participants, such as the technical differences between MBSE and modeling in engineering, is inconsequential to this particular analysis because ultimately the results demonstrate very unsophisticated overall practices.

Therefore, we propose that this research is a useful first step to understand and diagnose modeling practices within organizations. In particular, unlike prescriptive engineering studies that may suggest theoretical frameworks or methods to accomplish modeling, this research is descriptive in that it reveals information about what happens in the current state. Descriptive studies are important for modeling and MBSE because sophisticated methods are inconsequential if there is no path to adoption by engineering-driven firms.

Based on the results, there is no evidence that documentation, language, and program practices are the reason for low model use or unsophisticated modeling practices. However, inertia bias and the status quo are potential challenges to any organization. Even if many people are trained in modeling practices, it could be difficult to transition an entire organization away from established practices and dominant software programs if every person who is involved or requires access to information depends on those tools. This might be especially challenging for non-technical stakeholders. Therefore, in addition to studies about advanced modeling methods and tools, we believe there is value in pursuing further descriptive research about modeling practices within engineering-driven firms.

Conclusions

The analysis of participant profiles and polls responses demonstrates an effective use of online course data to assess model use and user sophistication in engineering-driven firms. While the research exhibits some challenges with the underlying data, it is notable as a descriptive research paper in engineering that inspires further research into practices and behaviors in industry. The results yield three primary conclusions about modeling that are relevant to the highly educated, mid-career professional participants and organizations represented by the population sample.

First, modeling penetration is low. Less than ten percent of respondents reported being asked to evaluate an MBSE approach, and only 11 percent of respondents selected predominantly models as the primary mode of capturing systems data. Considering that these participants are likely among the most familiar with models within their organizations, these results indicate that modeling is not broadly used in the organizations. Future research should include more descriptive studies of modeling practices, including data obtained through observation.

Second, modeling is used less or in a less sophisticated way than claimed or presented externally. In particular, many more participants claimed an MBSE approach in their organizations than was corroborated through other responses. While there are many potential explanations, including misunderstanding or ignorance of actual practice within their organizations, this effect is still notable because it represents a disconnect in self-awareness. Furthermore, simple use of modeling tools or techniques does not necessarily imply effective use. Results about documentation, languages, programs, and queries suggests that participants only scratch the surface, model informally, work in silos, and/or rely on suboptimal resources such as general purpose office software. Besides more sophisticated modeling techniques, future research should examine the organizational reasons that inhibit the adoption of effective modeling practices.

Third, the analysis was an adventurous first step towards initial assessment of modeling practices that reflects a novel use of data from online courses. The ability to reach participants with a specific profile using online courses enabled this research. Other research in different subject areas could employ similar first-pass analyses to evaluate fields using data from educational programs.

References

Kizilcec, René F., Chris Piech, and Emily Schneider. “Deconstructing disengagement: analyzing learner subpopulations in massive open online courses.” In Proceedings of the third international conference on learning analytics and knowledge, pp. 170-179. ACM, 2013.

Madni, Azad M., and Michael Sievers. “Model-based systems engineering: motivation, current status, and needed advances.” Disciplinary Convergence in Systems Engineering Research (2018): 311-325.

Vuolo, Mike, Jeremy Staff, and Jeylan T. Mortimer. “Weathering the great recession: Psychological and behavioral trajectories in the transition from school to work.” Developmental psychology 48, no. 6 (2012): 1759.

Jordan, K. (2015). Massive open online course completion rates revisited: Assessment, length and attrition. International Review of Research in Open and Distributed Learning, 16(3), 341–358.

Scala, N. M., & Pazour, J. A. (2016). A Value Model for Asset Tracking Technology to Support Naval Sea-Based Resupply. Engineering Management Journal, 28(2), 120-130.

DiMario, M., Cloutier, R., & Verma, D. (2008). Applying frameworks to manage SoS architecture. Engineering Management Journal, 20(4), 18-23.

Fathian, M., Saei-Shahi, M., & Makui, A. (2017). A New Optimization Model for Reliable Team Formation Problem Considering Experts’ Collaboration Network. IEEE Transactions on Engineering Management, 64(4), 586-593.

Sharma, R. S., Conrath, D. W., & Dilts, D. M. (1991). A socio-technical model for deploying expert systems. I. The general theory. IEEE Transactions on Engineering Management, 38(1), 14-23.

Spangelo, S. C., Kaslow, D., Delp, C., Cole, B., Anderson, L., Fosse, E., & Cutler, J. (2012, March). Applying model based systems engineering (MBSE) to a standard CubeSat. In Aerospace Conference, 2012 IEEE (pp. 1-20). IEEE.

Fosse, E., & Delp, C. L. (2013, March). Systems engineering interfaces: A model based approach. In Aerospace Conference, 2013 IEEE (pp. 1-8). IEEE.

List of Acronyms used in this Article

Acronym Explanation

DSM Design Structure Matrix

MBSE Model-Based System Engineering

MOOC Massive Open Online Course

NASA National Aeronautics and Space Administration

SQL Structured Query Language

SysML Systems Modeling Language

UML Unified Modeling Language

Author Profiles

Bruce Cameron is the Director of the System Architecture Lab at MIT and a co-founder of Technology Strategy Partners (TSP), a boutique consulting firm. His research interests at MIT include technology strategy, system architecture, and the management of product platforms. Dr. Cameron has directed research projects for BP, Sikorsky, Nokia, Caterpillar, NSTAR, AMGEN, Verizon^[1], and NASA. Prior to MIT, Dr. Cameron worked as an engagement manager at a management consultancy and as a system engineer at MDA Space Systems, and has built hardware currently in orbit. Dr. Cameron received his undergraduate degree from the University of Toronto and graduate degrees from MIT. Dr. Cameron is an author, together with Edward Crawley and Daniel Selva, of Strategy and Product Development for Complex Systems. This book is featured in the Systems Engineering Publications section of this issue of SyEN.

Daniel Mark Adsit is a consultant specializing in data strategy for marketing departments and marketing agencies. During his career, he has completed projects in over 15 countries for organizations including Eaton Corporation, Altera, and HubSpot certified marketing agencies. Daniel is a graduate of the System Design and Management (SDM) Program at MIT and the College of Engineering at Cornell. He has analyzed student personas from massive online courses as part of professional projects, and is enthusiastic about innovative learning environments that enable both career development for students and organizational capabilities growth for companies. He enjoys horseback riding and traveling in his spare time.

Article

Integrating Program Management and Systems Engineering

Dr. Ralph R. Young, Editor, SyEN

This month we provide a summary of Chapter 9, The Organization Environment, 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 eleventh article in this series. Our objective in providing this series is to encourage subscribers to leverage the research base of this book that took place over a five-year period and provided new knowledge and valuable insights. The book is available to members of INCOSE at a discount.

Organizational structures, behaviors, and norms shape how program participants work and interact with each other and determine the nature of relationships. Much of the confusion encountered in problem- solving today results from misconceptions about the nature of change in organizations, social systems, and their environments. Moreover, it has become evident that traditional hierarchical organizational forms, planning methodologies, and response strategies are inadequate for addressing complex problems. This is especially true when applied to emerging conditions having an increased rate of change, increased complexity, and increased uncertainty.

In an effort to understand how to develop better organizational environments for the integration of systems engineering and program management, this chapter analyzes the organizational structural dimensions of the “Integration Framework” (described in this column in SyEN 61, January 2018, and in more detail in Chapter 6 of “The Book”)^[2]. It also addresses the environmental elements influencing the programs within the organization including cultural factors, leadership, and team building; and the nature of the participants’ relationships.

Because organizations are evolving systems, the structures within the organization continue to grow and change as the strategic goals of the organization change. The difficulty of governing new structural paradigms leads to greater uncertainty and turbulence within the wider organization. According to Wikipedia, a complex system, from a systems engineering perspective, is composed of many components which interact with each other. The behavior of a complex system is intrinsically difficult to model due to the dependencies, relationships, or interactions between their parts or between a given system and its environment. Systems that are “complex” have distinct properties that arise from these relationships, such as nonlinearity, emergence, spontaneous order, adaptation, and feedback loops, among others.

This Chapter also reports on case studies and research that focus on the transformation of organizations to produce greater integration across functional barriers, specifically program management and systems engineering. We need to understand that the essence of transformation is a thorough, dramatic change in form. In this book, transformational change is implemented through programs that affect the way an organization conducts its business activities.

How do the Project or Program Manager (PM) and Chief Systems Engineer (CSE) create a culture that regularly identifies and solves new problems? The evidence provided in this chapter suggests that:

An organization that develops creative leaders, fosters team building, and merges the technical and the creative cultures will have far greater chances of success than one that exists in a traditional, rules-based, hierarchical structure.
Having the ability to share concerning work in progress with everyone and to receive valuable feedback along the way creates confidence in the individual, while enhancing the group’s creativity and advancing the organization’s mission.
Forward-looking organizations create an organizational climate that ensures that every voice is heard and one can communicate their perspective, needs, and ideas, and that no one individual or group dominates the process.
Recent analysis of program-shaping research calls for a broader, more inclusive perspective on what it takes to successfully manage projects and programs by reorienting our frame of reference away from the long-accepted execution-based program delivery model with its natural boundaries toward one that embraces a fuller and better understanding of the links between programs and strategy that successful programs require.
Organizations must ensure that the right programs are selected to leverage competitive advantage and to enhance stakeholder value^[3], and, most importantly, provide input to the potential change of strategic direction for the organization.
The sustainment of benefits is not just of concern to the program manager, but also a major deliverable of the systems engineer. INCOSE [5] describes the business or mission analysis of the systems engineer as “defining the problem domain, identifying major stakeholders, identifying environmental conditions and constraints that bound the solution domain…and developing the business requirements and validation criteria” (p. 51). The process of developing business mission requirements aligns with the program manager’s goals of identifying and analyzing benefits and opportunities, and ensuring product and program sustainability. Systems engineering and program management should support one another in defining what must be done and gathering the information, personnel, and analysis tools to elaborate the business requirements.
Experience teaches that creating a vision and then empowering others to achieve it is an approach that has worked [6].

Organizational Environmental Factors

Organizational environmental factors (everything outside the program’s boundary) may consist of corporate, environmental, and governmental variables that constrain the ability of a program to achieve its goals. External environmental factors may include the market and overall economic conditions, political climate, resources, health and safety, cultural diversity, technology, legislation and regulations, and quality and risk. Understanding environmental factors is critical to the program’s success. Three organizational environment factors – culture, leadership, and interdisciplinary teams – can be employed to encourage or discourage the team behaviors shown to be key to integration and program success.

Culture
- Culture is typically defined as the collective values, philosophy, and practices of the organization’s members.
- The development and fostering of mutual understanding of strengths and weaknesses for program managers and systems engineers creates an understanding of individual goals that can be valuable in moving the program forward.
- Superior program management is attained when the organizational culture is based on effective trust, communication, cooperation, and teamwork.
- Trust-building behaviors include: empower people, let them make mistakes, cooperatively iterate to perfection, and use relationships (not rules) to encourage behavior.
Leadership
- Individual leadership skills are essential to creating integrated, team-based organizations.
- When one considers that complex programs require the ability to achieve integration across disciplines, influence multiple governance structures, energize numerous stakeholders, empower program teams, and create the vision for innovation, the need for transformative leadership skills becomes more apparent [5]. To foster integration and teamwork, top management must be involved in promoting and supporting team behaviors and creating an environment that encourages team building and trust building at all levels of the organization.
- Programs that are surrounded with uncertainty and complexity need to explore new ways of delivery outside of the hierarchical, structured approach of most program management regimes. Improvisation (broadly defined as the practice of reacting and of making and creating) as a developing theory of program management is not universally adopted by the professional bodies; however, it fits within the program tailoring approach.
- Systems engineering requires the ability to work with uncertainties and assumptions – not just determine inputs – and to handle the distinct trade-offs that different sets of assumptions generate.
Interdisciplinary Teams to Solve Large Problems
- Interdisciplinary teams lie at the heart of systems engineering and program management integration, yet very little research focuses on the structure, role, and how teams are integrated.
- Team building has been defined as “the process of taking a collection of individuals with different needs, backgrounds, and expertise, and transferring them into an integrated, effective work unit” [2]. Integration is a reflection of the organization’s ability to combine program management and systems engineering practices, tools and techniques, experience, and knowledge in a collaborative and systematic approach in the face of different challenges to be more effective in achieving common goals and objectives in complex program environments.

The Challenges of Integration in Large Scale Programs

Lessons observed^[4] from the Hubble Space Telescope (HST) Program:
- The HST Program failure is attributed primarily to the fact that program management maintained an isolated focus on cost and schedule. The important lesson here is that when program managers and systems engineers are working together to solve problems, there is a greater likelihood that the systems engineer will have a better understanding of the technology, and the program manager will have a better understanding of the budget constraints. Once they are “speaking the same language,” they can better convince the sponsors why changes are needed to accommodate the challenges that evolve from technological complexity and shifting stakeholder expectations.
Lessons observed from the Heathrow Terminal 5 Program
- Integrative programs are essential in developing strategies for maintaining sustainability over the long term. Despite the extensive preparation, testing, and benchmarking, there was a disconnect between the program teams, including the systems engineering and the operations teams. Program sustainability requires an organizational environment that promotes integration to maintain operability, services, and benefits of the program, not just during the life of the program, but the life of the program’s assets as well.
Lessons observed from the International Space Station (ISS) Program. The International Space Station is perhaps the most famous of all systems engineering programs known for its convergence of science, technology, and human innovation. It demonstrates new technologies and makes available research break-trough’s not possible on Earth. The space station has been continuously occupied since November 2000, and during that time, more than 200 people from 15 countries have visited the space station. This program crosses cultural barriers and raises many issues relevant to an organizational environment that values and promotes integration of systems engineers and program managers, including organizational integration, knowledge sharing, leadership, and trust [9].
- An integrated organizational structure was critical.
- NASA had to learn how to operate as a “managing partner”, dealing with different perspectives on approaches, designs, and operational risk and safety.
- NASA had to figure out how to coordinate and integrate all of the international partners and their highly integrated modules.
- Interfaces must be simple.
- Coordinating the inclusion of the international partners whose systems engineering approaches differed significantly was a major challenge.
- Complex programs require leadership skills that encourage an environment of inclusivity, collective creativity, shared ownership, and large scale transformation.

Characteristics of Successful Program Integration

Good systems governance, which requires that individuals with oversight responsibility and authority provide guidance and decision-making for programs and projects [9].
Leadership.
Systems thinking – proactively enabling an understanding of how systems influence one another within the whole. Systems thinking is what distinguishes systems engineering from other types of engineering, and is the underlying skill required to perform systems engineering [1].
For complex programs, the governance needs to be transformed from a corporate/program perspective to a systems perspective. The most beneficial time to evolve a systems perspective occurs during the up-front planning, the earliest stages of the program planning [9].

The examples noted in this chapter suggest that program leaders and sponsors must focus on greater integration between the technical experts and the program managers to increase the likelihood for success.

Incentives as a Tactic for Systems Integration

Incentives are usually defined in terms of financial incentives, including rewards for early delivery and late delivery [5, p.144]. However, incentives have also been highlighted in terms of leadership and value propositions (p. 9).
Incentives must align with key business opportunities in order to ensure integration of systems engineering and program management.
Incentives play an important role in integration because they create opportunities for developing a more cooperative relationship between the various disciplines involved in a program and to strengthen the cultural divisions among the parties.
Incentives should reward both systems engineers and program managers so that there is a shared commitment to vital objectives, rather than to create disconnects between the two.

The Impact of Change Practices on Successful Outcomes in Program Organizations

Organizations that are prepared to change their products, processes, and delivery at a rapid pace likely will be the most successful.
Recent studies indicate that program management professionals are embracing change implementation practices, and that these practices can have a major impact on program success and outcomes [4].
There is a need for more knowledge of the differences in the skill sets of program managers, systems engineers, and change managers.

Summary

Complex programs require leadership skills that encourage an environment of inclusivity, collective creativity, shared ownership, large-scale transformation, systems thinking, and development of a systems perspective.

Creating an organizational environment that narrows the cultural divide, fosters team building, develops respect for each other’s views and opinions, and builds trust between executive management and program teams is central to developing a community where collective creativity can evolve. Involving program managers and systems engineers at the organizational level to influence and inform decisions about strategic direction is beneficial, especially as they are the managers who are more instrumental in ensuring effective implementation and execution of change initiatives. Moreover, as noted in the NASA Hubble Space Telescope program, leaders must possess “soft skills” to enhance team building and better identify managerial shortcomings before they result in broken team interfaces and technical mistakes.

The key learnings from this chapter for building a sustainable framework for integration include the importance of developing relationship competencies in participants throughout the program, creating a shared set of objectives, clear roles, respecting the value of the others’ role and contribution, and valuing and promoting “collaboration” over competition. However, these factors will only be relevant if the organization is able to develop people competencies as well. This chapter shows that if one creates an organizational environment for successful integration and effective implementation of change, successful outcomes are more likely because one will have integrated divided cultures and added value to the organization.

Key topics for your thoughtful consideration are:

What leadership qualities are required at the organizational level to facilitate integration?
Why is change management important to the integration of systems engineering and program management?
Why is interdisciplinary team building at the heart of integration and how can an organization create an environment where team building is the central focus of the organization’s strategy?
Why is the relationship among organizational strategy and program management important in developing integration among systems engineers and program managers?
If you don’t initiate continuous improvement actions on your project and in your organization, who will? How can you support continuous improvement activities? How can you help foster integration of systems engineering and program management?

References

[1] Beasley, R. and R. Partridge. The Three T’s of Systems Engineering: Trading, Tailoring, and Thinking. Paper presented at the 21^st Annual Symposium of the International Council on Systems Engineering. Denver, Colorado USA, June 230-23, 2011.

[2] Cleland, E. Project Management: Strategic Design and Implementation (5^th ed). New York: McGraw-Hill. Available here.

[3] Crawford, L., A. Aitken, and A. Hassner-Nahmias. Project Management and Organizational Change. Newton Square, PA: Project Management Institute, 2014. Available here.

[4] Greiman, V. Megaproject Management: Lessons on Risk and Project Management from the Big Dig. Hoboken, NJ: John Wiley & Sons, 2013. Available here.

[5] International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (4^th ed.). Hoboken, NJ: John Wiley & Sons, 2015. English, Chinese and German editions are available.

[6] Kotter, J. Leading Change. Cambridge, MA: Harvard Business Review Press, 2012. Available here.

[7] Locatelli, G., M. Mancini, and E. Romano. Systems Engineering to improve the Governance in Complex Project Environments. International Journal of Project Management, 32(8), pp. 1395-1410.

[8] Reiner. T. Determination of Factors to Measure the Effective Integration between program Management and Systems Engineering. Rheinisch-Westfalische Techische Hochschule (RWTH) Aachen Master’s thesis, 2015.

[9] Stockman, B. J. Boyle, and J. Bacon. International Space Station Systems Engineering Case Study. Air Force Center for Systems Engineering. Download here.

ARTICLE

Social and Ideological Challenges Faced by the Engineering Community

As the world moves towards more industrial-intensive technological processes and products, careers in science and engineering should be booming! In some respects, this is the case but in others, it is not. There are many hurdles that need to be addressed to change misconceptions and unfortunate realities so that we can increase the appeal of engineering and draw more attention, resources and skilled-workers into this pertinent field.

The reality of science education in developing countries

In Delhi, it has been stated to be impossible to find a physics teacher due to the education system deepening rather than bridging the imbalance of class in India. One of the reasons attributed to this is because it is not uncommon for public schools in developing countries to not pay their teachers as has been evidenced in countries like South Africa and India. This scenario forces teachers to stop teaching as they are unable to support their livelihoods due to not receiving a salary. Another deterrent for science teachers in India is the lack of working opportunities and seemingly absent recognition of service. Mr. Malik- a science teacher in India with over 28 years’ experience – has only recently received his first promotion as a science teacher after almost three decades of working. However, this may be because the jobs are simply not there. In Delhi, only 279 of 1030 government schools offer science to 11^th and 12^th grade students. It is a vicious cycle – as fewer schools offer science, fewer teachers want to become science teachers due to low job vacancies so schools struggle to replace teachers who retire. Thus, fewer schools offer science and the cycle continues.

One possible solution to this problem which has brought encouraging results in Delhi, is setting up community education centers to teach dedicated learners. People in communities can put their heads and resources together to find a venue in the area and professionals can volunteer to teach math and science to those seeking an education but not having the resources to do so. This requires an acknowledgement by all that education is a social responsibility and also requires a willingness of people to teach without receiving payment. On the other hand, organizations such as manufacturing, accounting and engineering firms could offer additional pay to workers who teach students since companies can receive tax concessions for community service.

Since it is sometimes the case that governments cannot be relied upon to provide adequate education to all, communities need to band together to provide other routes of education in formal and informal contexts for the sake of the future of our youth.

Proliferated misconceptions

Results of the Oklahoman reports showed that 51% of students showed zero or little interest in manufacturing but 61% have a desire for a professional career. This suggests that there is a poor correlation in the minds of students between manufacturing and a professional career. This may be linked to the old-fashioned but still maintained conception that manufacturing is strictly a dirty job where wearing white is completely out of the question. In reality, manufacturing in today’s world will almost certainly require operation of very advanced and sophisticated equipment which requires computer skills that students typically enjoy. In addition, manufacturing contributes to 12% of the US economy and two thirds of total exports of goods and services creating 20 million high-paying jobs. Manufacturing is a very pertinent sector in this technology-driven age of development. Clearly somewhere along the line, the message has been lost between attractiveness and importance of the role manufacturing plays in the world.

In a survey by the Vancouver Sun which reported that many of the respondents wanted a career that helped people, several students did not see the link between engineering and helping people. Truthfully, engineering as a whole reduces poverty by creating jobs and better equipping people to carry out tasks more easily and efficiently so that their lives may be improved. There are also many engineering organizations actively seeking solutions to be less destructive to the environment and to promote equal access to clean water and improve housing conditions.

So, what can be done to alter some of these views held by primary and high school students? Changing the misconception about engineering can be achieved at home. Parents will always encourage success in their children’s professional lives and thus should support their children in making informed choices about their careers. Parents can fill in the educational loop since they are a vital component of value and knowledge dissemination. This can be done through seeking information from practicing engineers or visiting universities to get more information on course content and career opportunities. In addition, more information can be given through meetings at high schools whereby invitations may be sent out to students and parents for meetings aimed at informing students about careers in science and engineering. This may require an outlay of resources initially but it must be noted that investments made in promoting engineering to students will pay dividends later as more students will see engineering as a viable option once misconceptions are cleared.

A career in STEM industries is perceived to be unattractive

Many students are not drawn to studying a career in the Science Technology Engineering or Mathematics (STEM) fields because of the general trends that have become apparent. Some of the reasons highlighted according to Ted Rall (2013):

STEM majors generally get lower grades than art majors do. At universities where expulsion is the consequence of poor performance, the chance of expulsion as a STEM student is higher compared to the arts-related majors. In Columbia, 75% of STEM students drop out or get expelled before getting their degree. Since most students have to take out loans to study, the possibility of incurring debt with nothing to show for it makes choosing to study a STEM major seem risky. To improve the attractiveness of a career in STEM the grading disparity needs to change. Harvard has embraced the policy of softer grading and it has not been to the detriment of its reputation.

STEM majors are also generally associated with having a poor social atmosphere throughout the period of study. Rall suggests that STEM students are politically disengaged and very focused on their careers and little else. This may be a misconception or may be true in some instances, but this is a common perception held. One approach to address this could be by closing the divide between arts and science and assigning language and social classes as part of the engineering curriculum to promote cross-pollination of ideas and attitudes.

Unemployment is prevalent in STEM fields as a result of the changing job market. STEM industries are very cyclical in nature and there is little predictability in the job market place. Universities could partner with organizations to help students find job placements straight out of university so that the percentage of graduates who find placements after studying increases.

Overall to increase the appeal of STEM careers, greater prestige could be created around STEM practitioners as is done with the military industry so that children will grow up to admire scientists, mathematicians and engineers. We need more educators, students and progressive thinkers in STEM in order to facilitate the growth and innovation required to sustain the changing demands of a growing population, sustainably.

Resources for this article and links for further reading:

Hindustan Times. 2018. THE CLASS OF 2018: Why fewer kids from poor families become engineers. [ONLINE] Available at: https://www.hindustantimes.com/class-of-2018/why-fewer-kids-from-poor-families-become-engineers.html [Accessed 05 March 2018]
IISE. 2018. Misconceptions Abound. [ONLINE]. Available at: http://www.iise.org/Details.aspx?id=18430 [Accessed 05 March 2018]

ARTICLE

Do Engineers Lack Social Skills?

There are many admirable attributes of engineers. Engineers are renowned for being great problem solvers and usually graduate with a versatile set of skills that transfer well to many other career paths. Biomedical engineering graduate Sretko Becarevic decided to pursue a business career upon completing his engineering degree (Becarevic was working towards his MBA at the time that the article appeared on Engineering Because in 2013). Becarevic states that many of his engineering classmates have gone on to enjoy fruitful careers in engineering and that he remains proud of them but concluded that the biggest weakness of engineers is their lack of social skills. Is this a valid sentiment or is it a misapprehension?

Firstly, the basic premise must be put into question – is it that engineers lack social skills or that they may generally be less inclined to engage in social activities due to their commitment and passion for their work? Secondly, even if it is the perception that engineers lack social skills, it is unlikely that this is true for all engineers. Of course, there are a wide range of people with different traits and characteristics that will embark on any career path and this is true for engineer, too.

One consideration is that perhaps it is not that studying engineering results in one lacking social skills but that people who generally do not enjoy social activity are more likely to study math and science-related subjects. Perhaps people who are more extroverted will tend to enjoy spending time nurturing and studying social connections in large social groups. Introverts will tend to enjoy fewer and smaller interactions and may be inclined to be more reflective. So perhaps one’s character and personality will drive the way one dedicates their cognitive energy which may influence the type of career they choose. Is it conceivable then that the majority of engineers are introverts and thus are more analytical and inquisitive thinkers which drew them to engineering as a field?

Although it may be difficult to measure the social aptitude of engineers, entry-level engineers have poor communication skills according to industry managers. In their research, Donell et al. revealed that there is a disparity in the form of oral and written communication that is accepted in the academic environment from what is accepted and commonly practiced in the working environment (2011). A study by American Society of Mechanical Engineers (ASME) showed that 52% of mechanical engineering department heads thought that the written and oral communication skills of their graduates were very strong while only 20% were weak but the industry feedback delivered opposing results stating that 9% had strong communication skills and 52% were weak with communication (ASME, 2010). This was based on a study comprising 68 mechanical engineering heads and 1000 engineers and managers.

Is it possible that increased social skills could provide another basis for comparison of expression and perhaps improve the communication skills of engineers? Particularly oral communication. Only a structured and longitudinal research study can answer this conclusively. Clearly there are many interesting viewpoints on this topic and it is impossible to draw a conclusion on such a subjective matter. One thing is certain, we are in the age where your network determines your net worth, it is a good investment to make to step outside one’s department or field of interest and develop connections across with people from all walks of life. Perhaps it is not the size of an engineer’s network that is in question but rather who comprises the network that creates a perception of lack of integration. Maybe engineers (and many other professionals) are guilty of not mingling enough with people outside of their field and this is where the stigma arises from. As engineers, we should all make more of an effort to engage with people in other fields and establish other grounds of mutual interest besides the technical content of our work. Meaningful connections made with people who have mutual interests will benefit both career prospects as well as improve the perception of our social skills.

References and further reading:

ASME, 2010. Creating the Future of Mechanical Engineering Education. New York, Vision 2030.
David Rickwood, 2011. Are engineers really socially inept? [Online]
Available at: https://www.engineering.com/Library/ArticlesPage/tabid/85/ArticleID/3036/Are-engineers-really-socially-inept.aspx
[Accessed 12 March 2018].
Donnell, J. A., Aller, B. M., Alley, M. & Kedrowicz, A. A., 2011. Why Industry Says that Engineering Graduates Have Poor Communication Skills: What Literature Says. American Society for Engineering Education, Issue AC 2011-1503.
Murray, S., 2013. The Biggest Weakness for Engineerings is a Lack of Social Skills. [Online]
Available at: http://www.engineeringbecause.com/news/engineer-mba/97/biggest-weakness-for-engineers-is-social-skills
[Accessed 12 March 2018].
Quora, 2011. Why are engineers more likely to be socially awkward? [Online]
Available at: https://www.quora.com/Why-are-engineers-more-likely-to-be-socially-awkward
[Accessed 12 March 2018].

Systems Engineering News

Nature-based Inspirations for Systems Engineering

Georgia Tech News Center

Nature offers excellent design inspirations in some information technology systems, according to recent research at Georgia Tech (USA). The Honey Bee Algorithm tamed web traffic instabilities on servers by mimicking the behavior of bee colonies, according to systems researcher Craig Tovey. He shared his learnings and insights in a talk on February 18, 2018 at the annual meeting of the American Association for the Advancement of Science in Austin, Texas. In 2016, the bee-inspired algorithm garnered Tovey and his collaborators a Golden Goose Award, which commends curiosity-driven research as it blossoms to palpably benefit society. The Honey Bee Algorithm, for example, has saved significant web hosting costs. “When you study swarming bees, you discover truths that are lasting. The algorithms that guide them evolved over millions of years, and will hopefully still be there for millions of years to come,” said Tovey, a co-director of Georgia Tech’s Center for Biologically Inspired Design. “Compare that with when you design a new microcircuit. Three years later it’s gone, forever lost; replaced by new designs.”

More information

Featured Organizations

Institute of System Architectures in Aeronautics

The Institute of System Architectures in Aeronautics models aeronautics as a system which spans over multiple levels from the transport system via the vehicle till the production of sub-components. Research aims at system architectures hence the interactions of all elements across this system-of-systems.

Targeting enhanced efficiency and safety, emphasis is placed on the integration of automation and energy technologies with the focus placed on cabin and fuselage applications.

The required competence portfolio is realized by a virtual supply chain integrating the competences of other DLR institutes as well as external partners.

Contained in the research portfolio are numeric measures for virtual product design and engineering methods for solving complex problems within a team of experts. Validation and demonstration employ both, detailed digital models and large scale hardware experiments.

More information

Norway Industrial Systems Engineering Research Group

The Norway Industrial Systems Engineering (NISE) Research Group strives to execute world-class industry-relevant research on systems engineering. The group collaborates with a number of different industries including: Automotive and mobility, Aerospace, Maritime, Oil and gas, Urbane and Med tech, and Defense. Drivers for the research are Autonomous Systems, Digital transformation, Continuous Innovation, Effective Manufacturing, Connected World, and Systems of Systems.

The group’s externally funded research projects and their current research applications are within the topics System Architecture & Design, Design Thinking & Human Centered Design, Requirements Management, Robust Engineering & Technical Safety, Life cycle Analysis, Knowledge Management & Lean Product Development, and System Integration. The group actively applies “industry as laboratory” as a research methodology.

More information

Conferences and Meetings

For more information on systems engineering related conferences and meetings, please proceed to the PPI website: www.ppi-int.com

Some Systems Engineering-Relevant Websites

Technical Leadership in Systems Engineering

A page dedicated to Technical Leadership in Systems Engineering which complements management in the quest for excellent performance, a supportive environment and for assuring that the project team and organization in general are resilient to challenges. The site looks at attributes and styles of leadership and is an interesting read which may give insight into the type of leadership structure that exists in your organization.

http://www.sebokwiki.org/wiki/Technical_Leadership_in_Systems_Engineering

Research Grand Challenges for Systems Engineering

This page offers a breakdown of topics of the Grand Challenges for Systems Engineering Research. These topics have been selected as the areas requiring research and further exploration to promote the systems engineering approach in solving complex problems. The topics have been selected to bridge the gap between academic knowledge and industrial applications of systems engineering. It is an interesting read and a good source of research topics for anyone looking to write a journal paper or conduct research in support of the systems engineering initiative.

http://www.lboro.ac.uk/research/systems-net/grandchallenges/researchgrandchallengesforsystemsengineering/

Systems Engineering Tools & Techniques

A site containing a list of systems engineering tools and techniques to assist with eliciting and managing information as part of the systems engineering approach. Each of the tools and techniques listen contains a .pdf explanatory document providing detailed information on how to use or apply the tool or technique. A very useful sight for someone looking for a quick access to information on using systems engineering tools and techniques.

https://www.burgehugheswalsh.co.uk/systems-engineering/tools.aspx

What is Model-Based Systems Engineering

This INCOSE site contains information on Model-Based Systems Engineering (MBSE) – a formalized application of modeling to support system requirements, analysis, design and verification and validation. The site describes MBSE concepts, benefits of using MBSE, fundamental enablers and common misconceptions of MBSE. A quick and informative read to get up to scratch with basic MBSE concepts.

https://incoseonline.org.uk/Program_Files/Publications/zGuides_9.aspx?CatID=Publications

Systems Engineering: Roles and Responsibilities

A link to a .pdf presentation that highlights the roles and responsibilities of a systems engineer. The presentation discusses the dangers of making assumptions, lessons learned about systems engineering, precepts to systems engineering, a comparison pf project management to systems engineering management and systems engineering management pitfalls. An informative read to discovering some of the ways in which we get it wrong in systems engineering and how to proliferate better practices in our companies.

https://www.nasa.gov/pdf/580677main_02_Steve_Jolly_Systems_Engineering.pdf

Systems Engineering Publications

Strategy and Product Development for Complex Systems

Edward Crawley, Bruce Cameron, and Daniel Selva

System architecture is the study of early decision-making in complex systems. This text teaches how to capture experience and analysis about early system decisions, and how to choose architectures that meet stakeholder needs, integrate easily, and evolve flexibly. With case studies written by leading practitioners, from hybrid cars to communications networks to aircraft, this text showcases the science and art of system architecture. This book has been given five stars by a dozen reviewers at Amazon: “Great book and it is a must-read for network architects and system engineers”; “This was the primary textbook in a course taught by two of the authors. Easily understood and explicitly clear with examples of how to apply the principles of system architecture to engineering programs. My copy is annotated and marked up with sections I found extremely relevant. This one is staying on my bookshelf!”

More information

A Complexity Primer for Systems Engineers

INCOSE White Paper

July 2015

From the Introduction:

Complexity is nothing new to systems engineers and managers. The discipline of systems engineering evolved to improve our ability to deal with scale, interdependency, and complexity in systems development. Few systems engineers would doubt that complexity is increasing every year. The rate of change, the increasing interdependence and adaptability of systems, and the increasing ambitions of our clients ensure that complexity keeps expanding to the limits of our capacity to cope with it.

Complex systems science provides a strong foundation for understanding, coping with, and even exploiting complexity. There is a large and rapidly expanding literature on networks, complexity, and complex adaptive systems that can guide systems engineering practice. But busy systems engineers rarely have the time to keep up with this literature, which is diffused across the many interdisciplinary applications of complex systems science. This paper is written for systems engineers and program/project managers who suspect they may encounter complexity-related challenges. This paper applies key concepts from complex systems science to systems engineering to suggest new methods that can handle complexity rather than assuming it away. It is not a complete or even extensive treatment, but is intended as an introduction to the subject for systems engineers as they encounter and work with complexity-related phenomena.

Section II of this paper defines complexity and describes how we can identify complexity in an environment, a problem space, or a solution space. We also address the extent and types of complexity that a system or situation may exhibit, so that systems engineers can seek approaches that can better address that kind of complexity.

Section III then discusses how engineers address the problem of complexity, in two sections. The first approach requires thinking differently about the environment, the problem, and the solution. The second approach involves implementation of specific tools and techniques.

Available to INCOSE members here.

Systems Product Line Engineering Handbook

Alain Le Put

Book description (from the Google Store website):

A Product Line is a set of products with common elements and variable features. Including Product Lines in an overall development strategy tailored to the commercial and/or industrial context delivers significant benefits: products that are more suitable, reduction in cost, shorter development timescales, and quality improvement, for example.

This work, Systems Product Line Engineering Handbook, brings together a summary of the state-of-the-art with lessons learned from industrial experience in implementing Product Lines of various kinds, in terms of marketplace, number of applications, and degree of variability. It is practical, and is intended to complement existing systems engineering manuals; indeed, it adopts the same process structures.

The book provides:

Definitions and examples: Product Line, Product Lines organizations, Product Line Engineering
Processes, from needs analysis through to disposal
Systems engineering methods, particularly Model-Based Product Line Systems Engineering
Organization: development in silos and development in platforms
Implementation strategies and management processes

The book is intended for practitioners: engineers, project managers, instructors, researchers, students and developers of systems that fit into this approach.

This book was elected INCOSE Product of the Year in 2015.

More Information

Megaproject Management: Lessons on Risk and Project Management from the Big Dig

Virginia A. Greiman

Book description (from the Amazon Store website):

In Megaproject Management, a central member of the Big Dig team reveals the numerous risks, challenges, and accomplishments of the most complex urban infrastructure project in the history of the United States. Drawing on personal experience and interviews with project engineers, executive oversight commission officials, and core managers, the author, a former deputy counsel and risk manager for the Big Dig, develops new insights as she describes the realities of day-to-day management of the project from a project manager’s perspective.

The book incorporates both theory and practice and is therefore highly recommended to policymakers, academics, and project management practitioners. Focusing on lessons learned, this insightful book presents the Big Dig as a massive case study in the management of risk, cost, and schedule, particularly the interrelation of technical, legal, political, and social factors. It provides an analysis of the difficulties in managing megaprojects during each phase and over the life span of the project, while delivering useful lessons on why projects go wrong and what can be done to prevent project failure. It also offers new ideas to enhance project management performance and innovation in our global society.

This unique guide:

Defines megaproject characteristics and frameworks
Reviews the Big Dig’s history, stakeholders, and governance
Examines the project’s management scope, scheduling, and cost management—including project delays and cost overruns
Analyzes the Big Dig’s risk management and quality management
Reveals how to build a sustainable project through integration and change introduction

More information

Understanding the Front-end of Large Scale Engineering Programs

Sebastian Lucae, Eric Rebentisch, and Josef Oehman

Abstract

Large engineering programs like sociotechnical infrastructure constructions of airports, plant constructions, or the development of radically innovative, high-tech industrial products such as electric vehicles or aircraft are affected by a number of serious risks, and subsequently commonly suffer from large cost overruns. Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program. The lack of sufficient and effective efforts in the early stages of a program can result in unstable, unclear and incomplete requirements, unclear roles and responsibilities within the program organization, insufficient planning, and unproductive tensions between program management and systems engineering.

This study intends to clarify the importance of up-front planning to improve program performance, to propose a model for the front-end of large-scale engineering programs based on a review of existing, suitable models in literature and to better understand the complexity drivers that are impeding reliable planning and common planning mistakes made in large-scale engineering programs.

Available online at ScienceDirect.

Journal of Systems Science and Systems Engineering

Journal of Systems Science and Systems Engineering is an international journal published quarterly. It aims to foster new thinking and research, to help the decision makers understand the mechanism and complexity of economic, engineering, management, social and technological systems, learn the new developments in the theory and practice to improve the performance of systems. The Journal publishes papers that are addressed to the theory, methodology and applications relating to systems science and systems engineering.

Journal of Systems Science and Systems Engineering will publish a selection of papers from the International Symposium of the Analytic Hierarchy Process (ISAHP) 2018 Conference, to be held in Hong Kong, HK, July 12-15, 2018.

Sociotechnical System Safety: Hierarchical Control versus Mindfulness

Gavan Lintern and Peter N. Kugler

glintern@ppi-int.com

Abstract

Both the hierarchical control model of organizational processes in a sociotechnical system and organizational mindfulness have been promoted, largely through independent lines of argument, as having potential to improve safety in large-scale sociotechnical systems. We review the arguments to assess the confidence we might place in these claims and to assess whether these views are necessarily incompatible or could be complementary. The analysis reveals a lack of consistency in the arguments for hierarchical control. It remains unclear whether application of this model to sociotechnical system design will enhance safety or will even degrade it by promoting micromanagement. We conclude that the type of mindfulness that bolsters important safety-related cognitive processes is just what is missing from the hierarchical control model. The safety of large-scale sociotechnical systems with catastrophic potential poses an enormous challenge. A functional model with some hierarchical properties, when complemented with insights relating to organizational mindfulness, offers an innovative way of working toward resolving that challenge.

Available at the Wiley Online Library.

Healthcare Information Challenges: The Cognitive Challenge

Gavan Lintern and Al Motavalli

Background: Healthcare work is, to a considerable extent, cognitive. Subsequently, the analysis and the design of supporting technology must be sensitive to the cognitive and adaptive demands of the work and to the cognitive strategies employed by healthcare practitioners. Despite the vital role that cognition plays in healthcare work, current techno centric design approaches for healthcare technology do not account for it, failing to observe it during analysis and failing to develop support for it during design.

Main body: By review and analysis of case studies, we are shown how healthcare systems developed without input from cognitive analysis and cognitive design fail to take account of important healthcare work processes and workflows. In contrast, systems developed with a cognitively-focused design strategy demonstrate how it is possible to introduce technology that supports and enhances the work strategies of those engaged in patient care.

Conclusion: Significant problems emerge when technological support systems are developed without any serious and comprehensive attempt to understand the cognitive capabilities and skills deployed by those involved in patient care. In contrast, significant benefits accrue from taking full account of those cognitive capabilities and skills. Subsequently, the design and development of supporting technology must be sensitive to the cognitive demands of the work and the cognitive strategies employed by healthcare practitioners.

Available at the Cognitive Systems Design website here.

Systems Engineering Tools News

Scaled Agile Framework

Have you been wondering what SAFe is all about? An extensive overview of the Scaled Agile Framework, including a short, informal video introduction to SAFe with Inbar Oren, is here.

The framework enables the application of an agile approach throughout the enterprise over 4 distinct levels namely: Portfolio, Large Solution, Program and Team.

At team level, it works much like a standard Scrum or Kanban approach.

Essential SAFe (Program and Team levels) is considered to be the most basic configuration of the framework required to succeed with SAFe.

Large Solution SAFe (Large Solution, Program and Team Levels) is for the development of large and complex solutions which do not require the constructs of the portfolio level.

Portfolio SAFe (Portfolio, Program and Team Levels) is for enterprises developing multiple solutions with minimal dependencies on one another, requiring a small number of Agile teams.

Full SAFe is the most comprehensive configuration and is for enterprises developing large, integrated solutions that typically require hundreds of people or more to develop and maintain.

Figure 1: The Scaled Agile Framework 4.5

More information

Education and Academia

University of Technology, Sorbonne Universities

With high international visibility and reputation, University of Technology of Compiègne (UTC) has the mission to train students capable of understanding and controlling the multiple interactions between Technology and Mankind, of evolving in a global environment, managing innovative projects in both industrial sectors and research settings. UTC trains engineers presenting the capacities of autonomy, initiative, taking responsibility, and team work in complex projects, in an international environment. The UTC core program corresponds to the first two years of the engineering diploma, comprising 4 semesters. It allows students to discover the corporate world, to confirm their motivations and aspirations, and to facilitate their choice of an elective major specialty. Tomorrow’s engineers in computer sciences, hardware, and software will be the actors of a technological mutation affecting all sectors of our national economies.

There are five elective specialty streams (which take into account the job market in computer sciences and engineering; a strong local level of skills with the active participation of several enterprises to define projects and specific topics throughout training at UTC):

Aids to logistic decisions (GI-ADEL) to design computer and a data processing systems used in a logistics chain
Decision Data Mining (GI-FDD) used to build computer systems, data warehouses and decision systems and to carry out the statistical analysis of data.
Knowledge engineering and information processing support systems (GI-ICSI)
Computer Systems and Networks (GI-SRI) used to build computer systems in corporate settings
Embedded and real-time computer systems (GI-STRIE) used to build real-time computer systems
… to which must be added the transverse specialty – Management of Innovative Projects (UTC-MPI)

Given the level of complexity encountered today in enterprises and the socio-economic world, the UTC Department of Technology and Social Sciences (TSH) focuses on the roles and commitments of tomorrow’s engineers.

More information

Standards and Guides

Systems Engineering Plan Preparation Guide

Office of the Deputy Under Secretary of Defense for Acquisition and Technology,

Systems and Software Engineering, Enterprise Development.

The purpose of the Systems Engineering Plan (SEP) is to help programs develop their systems engineering (SE) approach, providing a firm and well-documented technical foundation for the program. The SEP is a living document in which periodic updates capture the program’s current status and evolving SE implementation and its relationship with the overall program management effort.

Download a copy here.

Definition to Close On

Technology Readiness Levels

Technology readiness levels (TRL) are a method of estimating technology maturity of critical technology elements of a program during the acquisition process. The primary purpose of using technology readiness levels is to help management in making decisions concerning the development and transitioning of technology. It should be viewed as one of several tools that are needed to manage the progress of research and development activity within an organization. There are different definitions for TRLs and although they are conceptually similar, significant differences exist in terms of maturity at a given technology readiness level. More information can be found here

PPI and cti News

Updates to PPI Systems Engineering Training

We are excited to announce the latest updates to our flagship 5-day Systems Engineering training course., There are hundreds of improvements to the course in this new release, including major additional strategies for engagement, summarizing strategies and additional exercises to enhance retention.

Upcoming PPI and CTI Participation in Professional Conferences

PPI will be participating in the following upcoming events.

The 12th Annual IEEE International Systems Conference

(Sponsoring)

23 – 26 April 2018

Vancouver, Canada

Systems Engineering Test and Evaluation Conference (SETE)

(Sponsoring)

30 April – 2 May 2018

Sydney, Australia

INCOSE IS2018

(Exhibiting)

7 – 12 July 2018

Washington, DC, USA

Swiss Systems Engineering Day (SWISSED)

(Sponsoring)

3 September 2018

Zurich, Switzerland

INCOSE Western States Regional Conference

(Sponsoring)

20-22 September 2018

Ogden, Utah

INCOSE SA 2018

(Exhibiting & Sponsoring)

3 – 5 October 2018

Pretoria, South Africa

PPI and CTI Events

Systems Engineering 5-Day Courses

Upcoming locations include:

Bristol, United Kingdom
Utrecht, the Netherlands

Requirements Analysis and Specification Writing 5-Day Courses

Upcoming locations include:

London, United Kingdom
Sydney, Australia

Systems Engineering Management 5-Day Courses

Upcoming locations include:

Pretoria, South Africa
Las Vegas, Nevada, United States of America

Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses

Upcoming locations include:

Melbourne, Australia
Pretoria, South Africa

Architectural Design 5-Day Course

Upcoming locations include:

Pretoria, South Africa
Adelaide, Australia

Human Systems Integration Public 5-Day Courses

Upcoming locations include:

Melbourne, Australia

CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)

Upcoming locations include:

Amsterdam, the Netherlands
Austin, Texas, United States of America

Other training available for on-site delivery only includes:

Project Risk and Opportunity Management 3-Day
Managing Technical Projects 2-Day
Integrated Product Teams 2-Day.

Kind regards from the SyEN team:

Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com

Dr. Ralph Young, Editor, email: ryoung@ppi-int.com

Suja Joseph-Malherbe, Managing Editor, email: smalherbe@ppi-int.com

Project Performance International

2 Parkgate Drive, Ringwood, Vic 3134 Australia Tel: +61 3 9876 7345 Fax: +61 3 9876 2664

Tel Brasil: +55 12 9 9780 3490

Tel UK: +44 20 3608 6754

Tel USA: +1 888 772 5174

Web: www.ppi-int.com

Email: contact@ppi-int.com

Tell us what you think of SyEN. Email us at syen@ppi-int.info.

These are trade names for the organizations. ↑
See also [9]. Thomas Reiner’s Master’s thesis, “Determination of factors to measure the effective integration between Program Management and Systems Engineering”, aims at measuring the effective integration by means of the identified factors, and provides useful insights. ↑
“Stakeholder value” was addressed in some detail in the March 2018 issue of SyEN. ↑
In my experience, the term “Lessons Learned” really should be specified as “Lessons Observed”, because most often, we don’t incorporate the lessons in pursuing our future endeavors. ↑

Recent Editions

PPI SyEN 64

Subscribe to PPI SyEN

PPI SyEN 134

PPI SyEN 133

PPI SyEN 132

PPI SyEN 131

FREE Original SE Articles and Industry News?

MORE About Us