PPI SyEN 96

IN THIS EDITION

1. Quotations to Open On
Read More…
2. Feature Articles
2.1	Systems Engineers, or Systems Engineering? by Robert Halligan
2.2	The Need for a Paradigm Shift toward Integrating Multiple Disciplines with Practical Tools and Models by Raymond Jonkers and Kamran Eftekhari Shahroudi
2.3	Towards Systems Thinking – A Communication-Focused Learning Process by Erik Karlsson, Diana Malvius, Mats Lindberg
2.4	Digital Engineering Information Exchange (DEIX) Working Group – Digital Viewpoint Model (DVM) Concept and Development by Celia Tseng, Sean McGervey, Tamara Hanbrick
Read More…
3. Additional Articles
3.1	Presentation: A Model-based Approach to PM/SE Integration
3.2	Architecture Development Methodologies Presentation by John Lynch
3.3	The Impact of Human Factors Engineering, Systems Engineering, and Information/Communications Technology in Healthcare by George Grant
3.4	What’s Different about an Integrated Approach?
3.5	Resilient Hospital Reference Model (RHRM) MBSE Project
Read More…
4. Systems Engineering News
4.1	New Systems Engineering Roadmap to Improve Dutch High-Tech Manufacturing Power
4.2	Integrating Program Management and Systems Engineering book is available in Russia
4.3	INCOSE 2020 Election Results by Danielle DeRoche
4.4	INCOSE Certifications: Online Testing
4.5	Lincoln Laboratory establishes Biotechnology and Human Systems Division
4.6	Webinar: Renewable Energy Systems as an Example of Layered Systems of Systems
Read More…
5. Featured Organizations
5.1	American Institute of Aeronautics and Astronautics (AIAA)
5.2	Centre for Systems Engineering and Innovation (CSEI) Imperial College London
5.3	Swiss Society of Systems Engineering
5.4	IEEE Systems, Man and Cybernetics Society (SMCS)
Read More…
6. News on Software Tools Supporting Systems Engineering
6.1	Siemens expands software ecosystem for industrial additive manufacturing
6.2	Maplesoft releases MapleSim Insight
Read More…
7. Systems Engineering Publications
7.1	System Requirements Engineering: A SysML Supported Requirements Engineering Method
7.2	The Design and Engineering of Curiosity: How the Mars Rover Performs Its Job
7.3	Software Engineering at Google: Lessons Learned from Programming over Time
7.4	PPI Requirements Specification Development Guide
7.5	Journal of Systems and Soft
7.6	Performance-Based Earned Valueware
7.7	Practical Model-Based Systems Engineering
Read More…
8. Education and Academia
8.1	MSU (USA) Professor Wins National Award Recognizing Innovative Engineering Education
8.2	Master of Science in Systems Engineering at Virginia Polytechnic Institute and State University, United States
8.3	Master of Systems Engineering (MSysEng) at University of Pretoria, South Africa
Read More…
9. Some Systems Engineering Relevant Websites
Read More…
10. Standards and Guides
10.1	Standards Concerning the Aerospace Industry
10.2	ISO/IEC/IEEE 24765:2017, Systems and Software Engineering Vocabulary
10.3	Earned Value Management Systems Update
Read More…
11. A Definition to Close On
11.1	Systems Engineering
Read More…
12. Conferences and Meetings
Read More…
13. PPI and CTI News
13.1	PPI Reaches 50 Live-Online Courses This Year
13.2	PPI Welcomes Maika Back to the Team
13.3	A Record Week For PPI
Read More…
14. PPI and CTI Events
Read More…
15. Upcoming PPI Participation In Professional Conferences
Read More…

1. QUOTATIONS TO OPEN ON

Design (verb) is the act of solution decision-making. Design (noun) is the product of doing so. The same can be said of “plan”. “Design” and “plan” differ only by application of the words to solutions oriented towards different types of elements, technology versus human.

Robert John Halligan

♢

A lot of people have gone further than they thought because someone else thought they could.

Zig Ziglar

♢

A plan must not be considered a set of handcuffs. An adaptive approach is required to take advantage of evolving knowledge.

Stephen Townsend, Project Management Institute

FEATURE ARTICLES

• 1. Systems Engineers, or Systems Engineering?

By

Robert Halligan, Managing Director, Consultant & Systems Engineering Educator

Project Performance International, rhalligan@ppi-int.com

Abstract

Discussion frequently occurs concerning the question “what does a systems engineer do?” This paper looks at the nature of systems engineering and its relationship to the job title or role description “systems engineer”. This concept of a job title or role is contrasted with a view that systems engineering is (or should be) an integral part of the discipline of engineering. The latter view suggests that differentiation between systems engineers and other engineers is artificial. Is the use of the term “systems engineer” just a semantics issue, or does its use have a deeper significance? What are the options and their implications?

Introduction

The term “systems engineer” is widely used within a context of “systems engineering”. This usage contrasts with usage of the terms “systems engineer” and “system engineer” in the IT sector, often referring to somebody who implements or maintains IT systems. This paper will examine definitions of systems engineering, then expose sets of principles of systems engineering from two different sources. The applicability of each of these principles will be examined with respect to the engineering of systems of different complexities and technologies, and to what we will call “non-systems”, unitary objects. From the applicability analysis, the paper draws conclusions regarding the generality of the applicability of systems engineering practice within engineering practice. The paper concludes by discussing the positive and the potentially negative consequences of use of the terms “systems engineer” and “systems engineering” in some contexts, and recommends context of usage.

Systems Engineering

The International Council on Systems Engineering (INCOSE) is believed to be the largest professional society concerned solely with systems engineering. INCOSE defines systems engineering as:

“Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.” [1]

Significantly, the definition embraces only a statement of purpose (enablement – making possible), and is ambiguous as to whether the principles, concepts and methods used apply to the approach or to the realization, use and retirement. It is unclear whether, under this definition, systems engineering incorporates any practice of engineering at all. Unfortunately, this definition is not going to be useful for the purpose of this paper.

NASA has defined systems engineering as follows: “System engineering is a robust approach to the design, creation, and operation of systems. In simple terms, the approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance of design trades, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the system meets (or met) the goals.”[2]

In the experience of the author, this NASA definition aligns well with the use of the term “systems engineering” in industry worldwide. The definition also strongly aligns with the focus of the 50+ INCOSE Working Groups on aspects of systems engineering, and with the ISO/IEC/IEEE standard 15288:2015 on systems engineering. [3]

The author’s preferred definition of systems engineering aligns closely with the NASA definition: “Systems engineering is an interdisciplinary, collaborative approach to the engineering of systems (of any type) that aims to capture stakeholder needs and objectives and to transform these into a holistic, life-cycle balanced system solution that both satisfies the minimum requirements, and optimizes overall project and system effectiveness according to the values of the stakeholders. Systems engineering incorporates both technical and management processes. Systems engineering excludes construction, except for construction within development.” [4]

Another attractive, more concise definition is “Systems engineering is the problem-independent and solution technology-independent principles and methods for the successful engineering of systems, based on systems thinking”. [5]

These last three definitions of systems engineering provide the basis for the subsequent content of this paper.

Systems Engineering Principles And Their Applicability

The hypothesis that systems engineering is applicable to the conduct of engineering in general, irrespective of the system being engineered, may be tested against each of a set of representative systems engineering principles. In this paper, two sets of principles are considered. The first is a set of principles developed by the author in 2002 and slightly refined over subsequent years. The second set was developed by the INCOSE Principles Action Team and published by INCOSE in 2019. [6]

For each principle in each set, the principle is rated by the author “Yes/No” for applicability to the engineering of:

1. ST: a large socio-technical system, such as the country of Singapore.
2. CO: a complex technology item such as an aircraft.
3. SI: a simple technology item such as a pen.
4. SO: software of any size and complexity.
5. NS: a non-system such as a USA quarter coin, produced by forming a material into a shape and without plating.

NO.	PRINCIPLE	ST	CO	SI	SO	NS
1	Capture and understand the requirements, measures of effectiveness and goals (the problem) before committing to the solution.	Y	Y	Y	Y	Y
2	Try to ensure that the requirements are consistent with what is predicted to be possible in solutions, at the time of required supply, i.e., are feasible.	Y	Y	Y	Y	Y
3	Treat as goals desired characteristics that may not be feasible, but not at the expense of the requirements. Note: “treat as goal” means that effort will be expended to achieve the goal which is related to the importance of the goal, and the probability of success. Where conflicts between goals exist, the goals will be traded off to maximize overall effectiveness.	Y	Y	Y	Y	Y
4	Define system requirements, measures of effectiveness, goals and solutions having regard to the whole of the (remaining) life cycle of the system of interest.	Y	Y	Y	Y	Y
5	Maintain a distinction between the statement of the problem and the description of the solution to that problem, for the system of interest, and for each subsystem/component/system element of that system. “Note: “Maintain a distinction” means “ensure that each is separately identifiable.” identifiable”.	Y	Y	Y	Y	Y
6	Baseline each statement of the problem (requirements, measures of effectiveness and goals set) and description of the solution to that problem (design). Control changes to requirements and design.	Y	Y	Y	Y	Y
7	Identify and develop descriptions of solutions alternatives (designs) that are both feasible (i.e., can meet requirements) and potentially are the most effective. Put aside from further consideration, as potential solutions, all other alternatives (unless the assessment of that potential solution changes). Note: MOEs could include development cost, time to market or other measures unrelated to system capabilities.	Y	Y	Y	Y	Y
8	Develop solution descriptions for enabling systems concurrently and in balance with the solution description for the system of interest. Note: an “enabling system” is a system which enables some phase of the life cycle of the system of interest. The internal design of an enabling system must be related to the internal design of the system of interest.	Y	Y	Y	Y	Y
9	Except for simple solutions, develop logical solution descriptions (description of how the system solution is to meet requirements) as an aid to developing physical solution descriptions (description of how to build the system).	Y	Y	Y	Y	Y
10	Be prepared to iterate in design to drive up overall effectiveness, but not at the expense of the requirements.	Y	Y	Y	Y	Y
11	Decide between feasible solution alternatives based on evaluation of the overall effectiveness of each of these alternatives. Limit alternatives to be evaluated to those that have potential to be the most overall effective. Take risk and opportunity into consideration in the evaluation.	Y	Y	Y	Y	Y
12	Subject to level of risk, independently verify work products (is the job being done right?)	Y	Y	Y	Y	Y
13	Subject to level of risk, validate work products from the perspective of the stakeholders whom the work products serve (is the right job being done?)	Y	Y	Y	Y	Y
14	The act of managing is needed to plan and implement the effective and efficient transformation of requirements and goals into solutions.	Y	Y	Y	Y	Y
15	Decide early on development strategy, between waterfall, incremental, evolutionary and spiral, based on ability to define good, stable requirements up front; risk due to technology; risk due to complexity; and other sources and levels of risk and opportunity.	Y	Y	Y	Y	Y

Table 1: Applicability Mapping from PPI Systems Engineering Principles

NO.	PRINCIPLE	ST	CO	SI	SO	NS
1	Systems engineering in application is specific to stakeholder needs, solution space, resulting system solution(s), and context throughout the system life cycle.	Y	Y	Y	Y	Y
2	Systems engineering has a holistic system view that includes the system elements and the interactions amongst themselves, the enabling systems, and the system environment.	Y	Y	Y	Y	N
3	Systems engineering influences and is influenced by internal and external resources, and political, economic, social, technological, environmental, and legal factors.	Y	Y	Y	Y	Y
4	Both policy and law must be properly understood to not over-constrain or under-constrain the system implementation.	Y	Y	Y	Y	Y
5	The real physical system is the perfect model of the system.	?	?	?	?	?
6	A focus of systems engineering is a progressively deeper understanding of the interactions, sensitivities, and behaviors of the system, stakeholder needs, and its operational environment.	Y	Y	Y	Y	Y
7	Sub-Principle 6(a): Mission context is defined based on the understanding of the stakeholder needs and constraints.	Y	Y	Y	Y	Y
8	Sub-Principle 6(b): Requirements and models reflect the understanding of the system	Y	Y	Y	Y	Y
9	Sub-Principle 6(c): Requirements are specific, agreed to preferences within the developing organization.	Y	Y	Y	Y	Y
10	Sub-Principle 6(d): Requirements and system design are progressively elaborated as the development progresses.	Y	Y	Y	Y	Y
11	Sub-Principle 6(e): Modeling of systems must account for system interactions.	Y	Y	Y	Y	Y
12	Sub-Principle 6(f): Systems engineering achieves an understanding of all the system functions and interactions in the operational environment.	Y	Y	Y	Y	Y
13	Sub-Principle 6(g): Systems engineering achieves an understanding of the system’s value to the system stakeholders.	Y	Y	Y	Y	Y
14	Sub-Principle 6(h): Understanding of the system degrades during operations if system understanding is not maintained.	Y	Y	Y	Y	Y
15	Stakeholder needs can change and must be accounted for over the system life cycle.	Y	Y	Y	Y	Y
16	Systems engineering addresses stakeholder needs, taking into consideration budget, schedule, and technical needs, along with other expectations and constraints.	Y	Y	Y	Y	Y
17	Sub-Principle 8(a): Systems engineering seeks a best balance of functions and interactions within the system budget, schedule, technical and other expectations and constraints.	Y	Y	Y	Y	Y
18	Systems engineering decisions are made under uncertainty.	Y	Y	Y	Y	Y
19	Decision quality depends on knowledge of the system, enabling system(s), and interoperating system(s) present in the decision-making process.	Y	Y	Y	Y	Y
20	Systems engineering spans the entire system life cycle.	Y	Y	Y	Y	Y
21	Sub-Principle 11(a): Systems engineering obtains an understanding of the system.	Y	Y	Y	Y	Y
22	Sub-Principle 11(b): Systems engineering defines the mission context (system application).	Y	Y	Y	Y	Y
23	Sub-Principle 11(c): Systems engineering models the system.	Y	Y	Y	Y	N
24	Sub-Principle 11(d): Systems engineering designs and analyzes the system.	Y	Y	Y	Y	Y
25	Sub-Principle 11(e): Systems engineering tests the system.	Y	Y	Y	Y	Y
26	Sub-Principle 11(f): Systems engineering supports the production of the system.	Y	Y	Y	Y	Y
27	Sub-Principle 11(g): Systems engineering supports operations, maintenance, and retirement.	Y	Y	Y	Y	Y
28	Complex systems are engineered by complex organizations.	Y	Y	N	Y	N
29	Systems engineering integrates engineering disciplines in an effective manner.	Y	Y	Y	Y	Y
30	Systems engineering is responsible for managing the discipline interactions within the organization.	Y	Y	Y	Y	Y
31	Systems engineering is based on a middle range set of theories.	?	?	?	?	?
32	Sub-Principle 15(a): Systems engineering has a systems theory basis.	?	?	?	?	?
33	Sub-Principle 15(b): Systems engineering has a physical/logical basis specific to the system.	?	?	?	?	?
34	Sub-Principle 15(c): Systems engineering has a mathematical basis.	?	?	?	?	?
35	Sub-Principle 15(d): Systems engineering has a sociological basis specific to the organization.	?	?	?	?	?

Table 2: Applicability Mapping from INCOSE Systems Engineering Principles

Deductions From Applicability Of The Principles

If the mapping of applicability of systems engineering principles to various types and sizes of project is valid, one would have to conclude that systems engineering is not something different or special. Systems engineering is just about engineering things, any thing.

Intuitively, one would expect that the more novel, complex or critical a system were, the more valuable a systems engineering approach to its development would be. This intuition is substantiated by the conclusions of a 2012 joint study led by the Carnegie Mellon University (CMU) Software Engineering Institute (SEI) using data from 148 development projects. [7] The projects, ranging from small to very large, were divided into two nominally equal-sized sets, the less-challenging half and the more challenging half.

Correlation coefficients were developed between project performance, incorporating cost, schedule, and quality outcomes, and systems engineering practice. The correlation coefficients of +0.34 for the less challenging and +0.62 for more challenging projects indicate very significant benefit regardless of project challenge, but much greater benefit for the more-challenging projects. A more extensive summary of some results of the CMU study is provided in Figure 1.

For the study, the relationships between the variables were summarized using Goodman and Kruskal’s Gamma, a measure of association that expresses the strength of relationship between two ordinal variables. A description of Goodman and Kruskal’s Gamma appears in the book Elementary Applied Statistics by Linton Freeman. [8]

Figure 1: Correlation between SE Practices and Project Performance

The study also provides a useful benchmark for the group of practices defined, for the purpose of the study, to constitute systems engineering practice. Significantly, these are not enabling practices according to the current INCOSE definition of systems engineering, but are mostly “doing” practices are aligned with both sets of systems engineering principles (my set and the INCOSE set).

Personally, I rarely use the term “systems engineer”, but I have lived and breathed systems engineering since 1985, the year when I realized how incompetent I was as an engineer. I was a good technologist in my field – radio engineering – but I didn’t have a clue as to how to go about applying that expertise in a way that consistently produced great results.

My view has solidified over the years that every engineer is, or should be, a systems engineer within the scope of their assigned engineering role(s). Systems engineering is not something separate from engineering in general; it is a way of practicing engineering in general. The variables are the scope of the task, the degree of systems engineering formality that is appropriate to that scope, and the balance of technical versus social skills needed. The scope of the task has variables of the specific technology or technologies involved, the diversity of technologies involved, the degree of integration of different technologies needed, and the degree of integration needed of specialty disciplines such as safety or cyber-security.

I am not alone in this view of systems engineering as an integral part of the discipline of engineering, that is, the principles and process component that supports the technology, math and physics component of the discipline of engineering. Many companies implement the ethos of every engineer being a systems engineer. That affects their hiring, their engineering procedures, their learning culture, their learning strategy, and their reward systems. And their performance!

My colleague Paul Davies added some further thoughts, observing from 40 years of experience that there are two essentially different approaches that organizations utilize concerning systems engineering:

Type 1 is a “stove-piped” industry, where the executive power is in the hands of single-discipline engineering empires. [9] Systems engineering is recognised as a necessary annoyance to glue the designs together, but the practitioners are subservient to whichever single-discipline expert happens to be in charge of the particular project. Career prospects of the “systems engineer” are limited. I can relate to Type 1 easily, having had many engineers but few managers from “Type 1” organizations participate in my systems engineering training courses, and having consulted to such organizations. Thankfully I have never been an employee of a Type 1 organization!

Type 2 is an organization whereby systems engineering is firmly embedded and the lead engineers on all projects are recognised as experts in both the technologies involved and in the process and integrative discipline of systems engineering. Indeed, single-discipline engineers are allocated to projects, to have their work directed by the cross-discipline “systems engineers”, and systems engineering is seen as a desirable career aspiration.

I share Paul’s views in the sense of Type 1 and Type 2 organizations being common. I add a Type 3 organization which is also common, where engineers work mainly in multidisciplinary teams, making the more important decisions collaboratively, creating a learning environment in which engineers may start as single-discipline and ignorant of systems engineering, and evolve to become multi-disciplinary and competent in systems engineering, usually while maintaining their original discipline strength. Some change discipline in the process, for example from electronics to software. The further along this evolutionary path an engineer travels, the more suited that person becomes to a role of leading a multi-disciplinary team. But engineers at any point on this journey can be, should be, and often are practicing systems engineering. Enterprises in sectors that develop complex systems in competitive markets or complex environments tend towards Type 3.

Some systems are engineered to comprise a diversity of technologies, for example a car. Other systems are engineered to comprise essentially a single technology, examples being a mechanical Swiss watch, a drug, a consulting company, Sydney Harbour Bridge, and MS Word.

The principles of systems engineering described in this paper can easily be checked-off as applying to all of these engineered systems; the benefits accrue accordingly. It is intuitive that the more complex a system is, the greater the risk due to that complexity, and the more valuable systems engineering practices become. Also intuitive is that, everything else being equal, the greater the diversity of technologies involved, the more complex a system solution is likely to be, and therefore, the more valuable systems engineering practices will be.

All of these aspects are thoroughly discussed in the 2012 CMU study. [7] That study also looked at the proportion of projects that implemented systems engineering as a separate group of “systems engineers”, versus systems engineering skills and responsibilities being distributed throughout the organization. The study concluded that the percentages were roughly equal, and the project performances were not different to a statistically significant degree. The study hypothesized that while centralized systems engineering is more effective at performing SE tasks, those efforts are less integrated with the work of the project and therefore have less impact on project performance.

The study would seem to suggest that my advocacy of “systems engineering to be practiced by all engineers” is neither supported nor negated by the data. However, there is more to the story that is not investigated in the study. My experience is that there is a big difference between having a policy of “systems engineering to be practiced by all engineers”, and having an engineering workforce in which that practice is occurring at a significant level of competence. The main challenge is the cost of educating the whole workforce. As a consequence, the education tends to be superficial, at least initially. Training a small group of SE leaders and having them try to influence the work of others requires less investment than training of a whole engineering workforce, notwithstanding the high return on investment observed from doing the latter.

With implementation of a sound systems engineering socialization strategy, involving among other strategies genuinely expert leadership, systems engineering champions, and systems engineering focus groups, the growth of systems engineering competence increases towards a “way of life” level at a rewarding pace.

When systems engineering becomes omnipresent in undergraduate engineering degree programs, the need for industry to train an engineering workforce in systems engineering will disappear. This can be considered a desirable end state. The education does not need to be called systems engineering, and arguably, there may be benefit in avoiding use of the term. I am encouraged to see many initiatives to integrate systems engineering into undergraduate engineering education, at an increasing rate. I am excited to be involved in some of these initiatives.

Systems Engineers, Systems Engineering And Professional Societies

A number of professional societies and industry organizations are active in advancing the discipline of systems engineering. Among these are IEEE, Institute of Industrial and Systems Engineers (IISE), International Council on Systems Engineering (INCOSE), Korean Council on Systems Engineering (KCOSE), National Defense Industrial Association (NDIA), Object Management Group (OMG), and SAE International. The membership of INCOSE, the leading society devoted entirely to systems engineering, is dwarfed in numbers by the memberships of IEEE and SAE, and yet, the constituency of INCOSE, engineers who would benefit from systems engineering, and their employers, is hugely greater than the IEEE and SAE memberships combined.

The INCOSE website has reflected a slow shift in orientation from systems engineers to systems engineering over the years. Whilst there is absolutely nothing wrong with the term “systems engineer” as a title for a specific job – it can be accurate and carries some justified prestige – the term when used as a synonym for someone who practices systems engineering – a race apart – disenfranchises the millions of engineers who could and should be practicing systems engineering. That cannot be good for attracting new members to systems engineering societies such as INCOSE – see https://www.incose.org/about-systems-engineering/careers-in-se or the INCOSE Systems Engineering Handbook (SEH) 4^th Edition for examples. I believe that any orientation of professional society publicity towards systems engineers rather than systems engineering to be detrimental to attraction of new members. This is an issue for the Institute for Industrial and Systems Engineers, as well as INCOSE. On a positive note, I am encouraged to see that INCOSE is actively discouraging the use in education resources of the term “systems engineer”, by way of instructions to content contributors in drafting of the INCOSE SEH 5^th edition, currently in development. The pointer is shifting.

Conclusions

A case has been made for the applicability of systems engineering to all possible subjects of engineering, based on a mapping of the applicability of two sets of principles of systems engineering to the development of:

1. Socio-technical systems.
2. Large, complex technology products and systems.
3. Small, simple technology products and systems.
4. Software-only systems.
5. Non-systems – engineered unitary objects not meaningfully viewable as being constructed of interacting elements.

The case has been strengthened by study data that demonstrates the value of systems engineering for the engineering of small, simple systems as well as larger, more complex systems, the principal difference in application being the degree of benefit.

This demonstration of general applicability has led to a conclusion that systems engineering could be, and should be, practiced by all engineers regardless of job title, not only by “a race apart” small minority. A corollary is the need for systems engineering content in every undergraduate engineering degree worldwide, a pursuit that is gaining momentum.

The term “systems engineer” is widely used and is an accurate job title for many jobs. The term is appropriate for this use as a job title, often carrying justified prestige. However, the term is problematic when used in explaining and promoting systems engineering. The terms “systems engineering” and “systems engineering practitioners” are recommended for use in describing, promoting, explaining, advocating and communicating about systems engineering. In doing so, the present disenfranchisement of the millions of engineers without “systems engineer” in their job title who would benefit from the practice of systems engineering can be avoided. Based on the data presented in this paper, we conclude that society will benefit accordingly from better project outcomes.

References

[1] International Council on Systems Engineering Website, https://www.incose.org/systems-engineering, 1 November 2020.

[2] NASA Systems Engineering Handbook, 1995.

[3] ISO/IEC/IEEE 15288:2015 Systems Engineering – System life cycle processes.

[4] Halligan, Robert John, Published training courseware, 2002.

[5] Halligan, Robert John, Published training courseware, 2012.

[6] Watson, Michael D., “Systems Engineering Principles and Hypotheses”, INSIGHT, May 2O19 Volume 22 / Issue 1.

[7] Elm, Joseph P., and Dennis R. Goldenson, “The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey”, Carnegie Mellon University, Software Engineering Institute, Special Report CMU/SEI-2012-SR-009, 2012.

[8] Freeman, Linton C., “Elementary Applied Statistics: For Students in Behavior Science”. J. Wiley & Sons, 1965.

[9] Davies, Paul, personal correspondence, 2020.

Bibliography

Armstrong, James R., “Implementing Systems Engineering”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 2000.

Brill, James H., “Systems Engineering – A Retrospective View”, The Journal of The International Council on Systems Engineering, Vol. 1, No. 4, pp. 258-266, 1998.

Bruno, Michelle E. and Brian W. Mar, “Implementation of the Systems Engineering Discipline”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1997.

Carlson, Harry, “Systems Engineering Training Program”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1991.

Elm, J.; Goldenson, D.; El Emam, K.; Donatelli, & N.; Neisa, A. “A Survey of Systems Engineering Effectiveness – Initial Results” (CMU/SEI-2008-SR-034). Software Engineering Institute, Carnegie Mellon University, 2008. http://www.sei.cmu.edu/library/abstracts/reports/08sr034.cfm

Elm, J. “The Business Case for Systems Engineering Study: Assessing Project Performance from Sparse Data”. (CMU/SEI-2012-SR-010). Software Engineering Institute, Carnegie Mellon University, 2012. http://www.sei.cmu.edu/library/abstracts/reports/12sr010.cfm

Elm, J. & Goldenson, D. The Business Case for Systems Engineering Study: Detailed Response Data. (CMU/SEI-2012-SR-011). Software Engineering Institute, Carnegie Mellon University, 2013. https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=73582

Fogle, Frank R., and Don L. Woodruff, “Definition of and Training in the Systems Engineering Process – A NASA Perspective”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1992.

Frank, Moti, “Cognitive and Personality Characteristics of Successful Systems Engineers”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 2000.

Grady, Jeffrey O., “Local System Engineering Education Program Ignition and Sustenance”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1991.

Harris, Michael B., “Development of Systems Engineers: A Structured Approach Based Upon International Experience”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 2000.

Kaufman, Mark S., “Internal Development of Systems Engineers”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1997.

Lentz, V.A., “Five Realities for Systems Engineering in Commercial Enterprises”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 2000.

McAuley, James E., “What Should Systems Engineers Know and When Should They Know It?” Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1992.

Mengot, Roy, “Building Systems Engineering Training In Industry”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1992.

Might, Robert J. and Robert A. Foster, “Educating System Engineers: What Industry Needs and Expects Universities or Training Programs to Teach”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1993.

Newbern, David and Jerome Nolte, “Systems Engineering Process Implementation in the Real World (Or Where the Theory Gets Tested)”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 2000.

Sheard, Sarah A., “Twelve Systems Engineering Roles”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1996.

Sheard, Sarah A., “Three Types of Systems Engineering Implementation”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 2000.

Watts, Jerry G., and Brian W. Mar, “Important Skills and Knowledge to Include in Corporate Systems Engineering Training Programs”, Seminar Proceedings of the Annual International Council on Systems Engineering (INCOSE) on CD-ROM, 1997.

• 1. The Need for a Paradigm Shift toward Integrating Multiple Disciplines with Practical Tools and Models

By

Raymond Jonkers and Kamran Eftekhari Shahroudi , Colorado State University, Systems Engineering, https://merlantec.ca, ray.jonkers@merlantec.ca

Abstract

Despite the use of traditional systems engineering (SE) and project management (PM) models and tools, complex projects continue to experience cost overruns and delays. Major contributors to these failures include the lack of integration of multiple disciplines (especially program management and systems engineering) and their disparate models, tools, practices, and standards. Recent research has identified ‘Integration Factors’ and an ‘Integration Framework’ intended to facilitate the integration of program management and systems engineering for complex programs (Rebentisch et al, 2017).^[1] However, a practical approach and model does not exist. This article examines an integration of models that provide a Management Flight Simulator (MFS) that can enhance and augment existing project management practices. It also provides an examination of the return on investment in bringing multiple disciplines together for knowledge gain, design flexibility, and product and project success.

Copyright © 2020 by Raymond Jonkers. All rights reserved.

Introduction

For most industries managing complex projects, cost overruns and schedule delays persist despite the application of recent project management practices and techniques. Numerous government projects including infrastructure, satellite programs, and weapon systems have experienced cost overruns and schedule delays costing billions of dollars of unplanned expenditures (Johnson 2018). For the Type 45 warship design, increased risks and costs were attributed to integration issues and challenges with 80 percent of equipment being new to service (Lombardi and Rudd 2013). For the Air Warfare Destroyer (AWD) warship design, the number one cause for cost overruns and schedule delays was advancing new technology (Parker 2016). Cost overruns and delays can be explained by technical challenges, over-optimism, and strategic misrepresentations. Remedies include improved information sharing and forecasting techniques, yet there is reluctance to invest in these approaches. In many cases, the return on investment may be unclear; in other cases, stakeholders may prefer to obscure the frequency and magnitude of cost overruns to evade accountability for project failures (Siemiatycki 2015). In a survey of 400 construction leaders, 62 percent of respondents stated that the biggest cause of project delays was due to the lack of collaboration and digital transformation (Finalcad 2020). With increased complexity and change, traditional management tools have failed to solve persistent problems (Sterman 2000, Walworth 2016). This can lead to late awareness or warning of problems and poor program performance.

The use of traditional project management tools and techniques is insufficient to achieve product and project success. The integration of well-known systems engineering models and business and product management lifecycle management curves that include the elusive techno-socio-economic and cultural factors in an organization can provide a novel and holistic perspective concerning product and project management. This integration of models can provide a Management Flight Simulator (MFS) that can enhance and augment existing management practices. In addition, use of the MFS and the gaming of change scenarios in response to risks can help bring disciplines together and build early knowledge.

There is a need for greater integration of program and project management application of systems engineering, and consideration of stakeholders across the value chain. In complex design projects, these stakeholders include engineers, management, the supply chain, planning and scheduling, and production.

Problems Faced in the Development of Complex Systems

Among the problems faced in the development of complex systems are varying discipline practices, unproductive tension between program leaders, and reluctance to adopt an integrated model that results in resorting to quick irrational decisions.

Varying Discipline Practices

Best practices and standards for the different disciplines include the Engineering Management Body of Knowledge (EMBoK), the International Council on Systems Engineering (INCOSE) Systems Engineering Handbook, the Systems Engineering Body of Knowledge (SEBoK), the Project Management Body of Knowledge (PMBoK), the Business Analyst Body of Knowledge (BABOK), and the Business Architecture Body of Knowledge (BIZBOK). However, these disparate roles, respective standards, and discipline-specific tools and models create confusion in terms of what to integrate. Moreover, these disciplines can often work in isolation, leading to inconsistencies in product information, tracking of design changes, and challenges in decision-making.

Unproductive Tension between Program Leaders

As noted previously, results from one study showed that there is unproductive tension between project managers of complex projects and chief systems engineers, that organizational performance was unclear, but that the use of integration tools could be beneficial in bringing disciplines together (Rebentisch 2017).

Reluctance to Adopt an Integrated Model that Results in Resorting to Quick Irrational Decisions

Concerns have been raised with respect to the lack of interest and buy-in from high technology organizations in embracing and adopting systems engineering models and tools. It was found that a low percentage of these organizations use model-based systems to capture data; whereas a high percentage still rely on document-based systems (Cameron 2018). Of note, only three percent of high technology organizations use model-based systems engineering tools to capture data and only 29 percent use a Model-Based Systems Engineering (MBSE) approach.

When problems occur in complex systems, the intuitive response is to find quick and easy solutions rather than long term effective solutions. This dilemma is apparent in the struggle between the systems engineer, project manager, engineering disciplines, and other stakeholders in the project (INCOSE 2015). Resorting to quick solutions may be caused by a stressful environment with time pressures or reluctance to apply cognitive effort. Whatever the reason, when recurring similar problems arise, shifting-the-burden from finding a fundamental optimal solution to quick symptomatic solutions can occur (Bellinger 2020).

As shown in Figure 1, adapting from a symptomatic quick solution to a fundamental optimal solution involves two balancing (B) loops and one reinforcing (R) loop (Bellinger 2020). The time delay or resistance in avoiding the fundamental solution leads to pursuing the quick solution. With this, side effects reinforce the problem including design issues. This forms a vicious reinforcing loop making it difficult to solve symptomatic problems. This reinforcing loop can create rework, cost overruns, and delays.

Figure 1. Shifting the Burden (Adapted: Bellinger 2020)

Use of an MFS Can Help!

The MFS can support pursuit of the fundamental optimal solution to symptomatic problems. It can do this through the automation of information, accessibility, transparency in results and ease of use. The MFS provides a common language of non-dimensional measures on a common platform of integrated SE and PM sub-models.

Inputs into the Fundamental Management Flight Simulator

From an extensive literature review, common integration requirement themes include communication and collaboration, social networking and recognizing team characteristics, early knowledge and a learning culture, early design analysis, mental models, understanding different perspectives, product quality and continuous improvement, and integration and simulation of information (INCOSE 2015, Senge 1990, Lee 1999, Laverghetta 1999, Rebentisch 2017). In developing the MFS, key aspects of the MFS include knowledge management, design change management, and the gaming of what-if change scenarios. Details concerning development of the MFS were presented in earlier work (Jonkers and Shahroudi 2020).

The MFS can help visualize and understand the causal relationships affecting decision-making. It can provide a clear understanding of system and program attributes and the impact of certain policies and decisions under various conditions. The MFS provides intelligence augmentation through a multi-experience dynamic user interface for what-if design change strategies. This can enhance and improve collaboration, learning, knowledge, and team effectiveness. Moreover, it can reduce project cost overruns and schedule delays.

Additional effort is required to develop tools and manage knowledge to enhance the design change process and to improve quality in production (Inayat, Dunbing and Leilei 2016). If knowledge can be quantified and an approach developed to advance knowledge in the design cycle, then design costs and schedule delays may be reduced. After an extensive review of knowledge management theory and research, it is not apparent that there exists a quantitative measure for measuring knowledge; the MFS is an attempt to develop this measure.

Knowledge Acquisition, Use, and Transfer

In a Project Management Institute (PMI) report, how knowledge is acquired, used, and shared was recognized as key to productivity, economic growth, and ultimately project and program success (Prusak 2015). It was noted that organizations that are most effective at knowledge transfer improve project outcomes by nearly 35 percent. It was also noted that when organizations create environments where employees can effectively transfer their knowledge to others, strategic initiatives will be completed more successfully.

Challenges in knowledge transfer can include finding out who has knowledge in the organization and how to create a learning culture for sharing knowledge. Use of the MFS and its integral social network analysis sub-model can help address these challenges.

It has been reported that 85 percent of technology and product costs are committed prior to detailed design, when little is known about the impact of design changes (Kennedy 2013). The lack of knowledge and design flexibility early in the design can postpone design change decisions when it becomes more expensive and difficult to implement these changes. Costs and time could be saved if it were possible to make quick, yet accurate assessments about the impact of change prior to implementing change (Morkos, Shankar and Summers 2012).

Design Flexibility and What-If Change Scenarios

According to the U.S. Government Accountability Office (GAO), half of defense acquisition programs experience cost overruns with the causes attributed to budget pressure, schedule pressure, and changing requirements (Cantwell 2013). Other factors leading to cost overruns and schedule delays include numerous design changes, technical errors and challenges in technology advancement and system integration (Ramanathan 2012). Design change management is viewed as a key process in developing the MFS. Set-based attribute and component changeability measures are used within the MFS for enhancing design change management.

One area for consideration in developing decision tools includes the effects of uncertainty in information and quantification methods for understanding the impact of change on different variables during the design (Chalfant 2015). The MFS provides for early knowledge and can predict the impact of changes and new technology on an existing system design, the organization and the project. The MFS uses set-based goal-based design and engineering principles in working toward a robust design. Set-based design has been reported as effective in improving design robustness and in reducing rework (Kennedy 2013). In set-based design, requirements and system design attributes are represented as ranges (instead of point values), where there can be explicit views of trade-off values prior to decision making. In point design, teams inefficiently move from one alternative to the next in search of a solution.

Understanding Underlying Product, Organization, and Project Interrelationships

Several studies reveal that only 16 percent of organizations are fully integrated and that over 60 percent of complex projects fail in terms of cost overruns and delays. It has been also stated that organizational and project dynamics have not been understood until it is too late (Rebentisch 2017).

It has been stated that several design models fail to represent the interaction across domains and don’t capture the aspects of time and the social sciences (Bartolomel 2012). The need for analytical decision management tools is supported by project and product failures in the past where it has been difficult to decide what to change in product design development when everything seems to have an influence (Behdinan 2011).

The field of systems dynamics (SD) can help in understanding the social and project dynamics within an organization. SD is used to analyze the behavior in organizational or social systems over time by describing and evaluating causal relationships. It can provide for a better understanding of complex systems and their behavior (Sterman 2000). SD loops can describe how knowledge generation and transfer can be impeded or enhanced. Likewise, SD loops can describe the impact of design changes on the program.

The Management Flight Simulator as a Practical Integrated Model

The MFS integrates systems engineering and management models through a digital thread for data-driven risk-informed decision-making. This MFS provides immediate feedback on whether a change is going to help or disrupt design integrity through the monitoring of system attribute trends and cues. It also provides the impact on lifecycle management curves using a SD sub-model.

From this feedback, several system, policy, and process levers are available within the MFS for what-if scenarios, with the goal to improve product, organizational, and project performance. The value in the emergent properties of the MFS as a decision support system is viewed as greater than from the sum of its sub-models.

The MFS predicts the state of the physical system and its impact on management curves where teams can respond to risks and disturbances with design change strategies using interactive controls. The management of attributes and management curves may be thought of as a control system, as shown in Figure 2.

When systems work well, there can be harmony and resiliency in their functioning (Meadows 2008). Resilience is the ability of the system to bounce back after a disturbance. In terms of the SD model, this property may be achieved through a rich structure of feedback loops that work in different ways to restore and stabilize system behavior (Meadows 2008).

This rich structure is achieved within the MFS with elements related to cross-functional processes, stocks, causal relationships through feedback loops, techno-socio-economic factors, and levers that can help to restore and stabilize system behavior. Integrated MFS sub-models include a Decision-Support System (DSS), Multi-Attribute Trade Exploration (MATE), Standards Risk Model (SRM), Design Structure Matrices (DSM), System Readiness Level (SRL), Social Network Analysis (SNA), Process Maturity Model, and the SD sub-model.

Figure 2. The Management Flight Simulator as a High-Level Control System

Impact of Lifecycle Management Curves

Like the butterfly effect, a small change in initial conditions or levers can have a cascading and significant effect on the management curves. Through the application of key system, policy, and process levers, the knowledge curve may be brought forward in design and the ease-of-change curve moved up, as shown in Figure 3 (Adapted: Blanchard 1998). It is proposed that this will postpone commitments; reduce the knowledge gap, cost overruns, and schedule delays; and better accommodate design changes, technology insertion, and procurement options throughout the design cycle.

Figure 3. Typical Lifecycle Management Curves (Adapted: Blanchard 1998)

The SD sub-model is based on a continuous predictive system that consists of stocks, flows, and differential equations. The position of SD management curves is monitored where corrective action may be taken by adjustment to policy and process levers.

Return on Investment Achieved by Using the Flight Management Simulator

The return on investment from applying systems engineering efforts has been investigated in other research where 14.4 percent of program costs invested in systems engineering was assessed as optimal for project success (Honor 2013 and 2016). The effort expended in using the MFS and the gaming of design change scenarios is estimated at well below 14.4 percent.

Through the adjustment of key SD model policy and process levers, the return on investment may be realized in reduced design change costs and schedule delays, as well as in other benefits.

The MFS can be used as part of existing risk and change management practices, providing the advantage of economy of scale. The costs of unexpected overruns in large complex projects can easily be in the millions of dollars per year. From a purely economic perspective, this justifies the expense of remedial measures including implementation of practical integrated models such as the MFS.

Causal Loop Diagrams and Project Management

The influence of both project and engineering system information on design changes, work performance, design maturity, and risk management are addressed in development of causal loop diagrams (CLD’s). In SD model development, CLD’s consisting of influencing factors, flows and stocks are defined. Feedback loops can be either positive reinforcing (R) loops or negative balancing (B) loops. There can be many CLD’s developed as part of the MFS and its SD sub-models. Of interest is the work performance CLD as it affects both product and project performance.

In the work performance CLD depicted in Figure 4, tasks are executed in accordance with the balancing (B18) feedback loop. The error rate causes rework through the reinforcing (R8) feedback loop. As the tasks “to do” and the error discovery rate increase, a reinforcing loop (R10) is enabled. The increased planned tasks and pressure to work harder act to increase the error rate and tasks to do through the reinforcing (R9) feedback loop. As the tasks completed are increased, the balancing (B19) feedback loop acts to reduce pressure to work harder and the error rate, leading to fewer tasks to do. Similarly, as planned tasks are completed, the balancing (B20) feedback loop acts to reduce the planned tasks. The task completion rate is affected by factors such as knowledge use, organizational integration, and the system readiness level (SRL) where the higher the SRL; the higher the task completion rate.

Figure 4. Project Performance Causal Loop Diagram

Levers for Improved Product and Project Performance

As part of the MFS, policy levers include on-the-job training (OJT) effort, gaming intensity, learning effort, team colocation, applying engineering principles, paying for VFI, and relational contracting effort.

Process improvement levers include knowledge, change, risk, communication, integration, supply, and strategic management. For instance, with an improved knowledge management process and application of engineering principles for a robust design, knowledge can be gained early in design and system ease of change increased, leading to reduced design change costs and schedule delays. As shown in Figures 5 and 6, the improved position or optimal setting of the knowledge and ease of change management curves can result in decreased design change costs and increased schedule performance. This provides a different and holistic perspective on integrated design and project performance management.

Figure 5. Levers Influencing Knowledge and Ease-of-Change Management Curves

Figure 6. Positive Effects on Project Performance Curves

Conclusions

For most industries managing complex projects, cost overruns and schedule delays persist despite the application of conventional project management practices and techniques. Cost overruns and delays can be explained by technical challenges, over-optimism, and strategic misrepresentations. Suggested remedies include improved information sharing and forecasting techniques; yet there is reluctance to invest in these approaches. In a survey of 400 construction leaders, 62 percent of respondents stated that the biggest cause of project delays was due to the lack of collaboration and digital transformation.

The use of conventional project management tools and techniques is insufficient to achieve product and project success. There is a need for greater integration of program and project management with systems engineering, and for consideration of stakeholders across the value chain.

Disparate roles, varying standards for different disciplines, and discipline-specific tools and models create confusion. Moreover, the disciplines often work in isolation, leading to inconsistencies in product information, tracking of design changes, and challenges in decision-making.

The MFS can help visualize and understand the causal relationships affecting decision-making. It can provide a clear understanding of system and program attributes and the impact of certain policies and decisions under various conditions. Additional effort is required to develop tools and manage knowledge to enhance the design change process and to improve quality in production. After an extensive review of knowledge management theory and research, it is not apparent that there exists a quantitative measure for measuring knowledge; the MFS is an attempt to develop this measure.

How knowledge is acquired, used, and shared is recognized as key to productivity, economic growth, and ultimately, project and program success. Organizations that are most effective in knowledge transfer improve project outcomes by nearly 35 percent. When organizations create environments where employees can effectively transfer their knowledge to others, strategic initiatives will be completed more successfully.

85 percent of technology and product costs are committed prior to detailed design, when little is known about the impact of design changes. The lack of knowledge and design flexibility early in the design can postpone design change decisions when it becomes more expensive and difficult to implement these changes. Costs and time could be saved if it were possible to make quick, yet accurate assessments about the impact of change prior to implementing change.

Half of defense acquisition programs experience cost overruns with the causes attributed to budget pressure, schedule pressure, and changing requirements. Other factors leading to cost overruns and schedule delays include numerous design changes, technical errors, and challenges in technology advancement and system integration. Design change management is viewed as a key process in developing the MFS.

Only 16 percent of organizations are fully integrated and over 60 percent of complex projects fail as measured by cost overruns and delays. Organizational and project dynamics have not been understood until it is too late.

The return on investment from applying systems engineering efforts has been investigated and 14.4 percent of program costs invested in systems engineering was assessed as optimal for project success. The effort expended in using the MFS and the gaming of design change scenarios is estimated at well below 14.4 percent.

The MFS can be used to augment traditional project management tools, bring disciplines together, and provide early knowledge gain for product and project success. Development of the MFS offers a structured holistic approach to model integration that may be adopted in developing a suite of generic system models that may be reused and customized for specific product design and project applications. Showcasing practical integrated SE/PM generic models can help avoid the confusion concerning which models should be used for integration.

Demonstrating the value of changing mindsets and in SE/PM integrated methods, models, and tools includes continued efforts to reach out to those in the PMI organization who are involved in complex projects. In particular, it involves demonstration of integrated models that are built on a common platform using a common language that provides simplicity, transparency, automation of tasks, and an enjoyable user experience (UX).

Summary

Regardless of the approach taken, opportunities and partnerships with industry, academia, INCOSE, PMI, and other institutions will continue to be important in applying a PM/SE framework as well as practical integrated models that can work for everyone involved in developing and managing complex products and projects. It is encouraging to note the efforts of the members of the INCOSE PM/SE Integration Working Group (IPMSEIWG) who have adopted a charter in support of integration of systems engineering and program management and have established and are undertaking several ‘Initiatives’ to work toward strengthening and improving integration (see the article in the November issue of the Project Performance International Systems Engineering Newsletter (PPI SyEN 95) concerning the current efforts of the members of this Working Group).

List of Acronyms Used in this Paper

Acronym Explanation

CLD Causal Loop Diagrams

DSM Design Structure Matrices

DSS Decision Support System

INCOSE International Council on Systems Engineering

MATE Multi-Attribute Tradespace Exploration

MBSE Model-Based System Engineering

MFS Management Flight Simulator

OJT On-the-job Training

PM Project Management

PMI Project Management Institute

PMM Process Maturity Model

ROI Return on Investment

SD System Dynamics

SE Systems Engineering

SE/PM Systems Engineering and Program Management

SNA Social Network Analysis

SRL System Readiness Level

SRM Standard Risk Model

UX User Experience

References

Best Practices for the Various Disciplines

A Guide to the Business Analyst Body of Knowledge (BABOK), International Institute of Business Analysts, available here.

A Guide to the Business Architecture Body of Knowledge (BIZBOK), Version 6, Business Architecture Guild, available here.

Engineering Management Body of Knowledge (EMBoK), American Society of Mechanical Engineers, available here.

International Council on Systems Engineering (INCOSE) Systems Engineering Handbook (SEH), Version 4, available here.

International Council on Systems Engineering (INCOSE), Guide for the Application of Systems Engineering in Large Infrastructure Projects, available here.

International Council on Systems Engineering (INCOSE), System of Systems Standards, available here.

A Guide to the Project Management Body of Knowledge (PMBoK), Project Management Institute, available here.

Guide to the Systems Engineering Body of Knowledge (SEBoK), INCOSE, IEEE Systems Council, and the Stevens Institute of Technology, Stewards, available for downloading here.

Others

Bartolomel, J., et al., “Engineering Systems Multiple Domain Matrix: An Organizing Framework for Modeling Large-Scale Complex Systems,” Systems Engineering, vol.15, no.1, USA, 2012.

Behdinan, K., Ruben, P., and Liu, H., “Multidisciplinary Design Optimization of Aerospace Systems,” Proceedings of the Canadian Engineering Education Association, Canada, 2011.

Bellinger, G., “Shifting The Burden”, [Online]. Available here. [Accessed April 2020].

Blanchard, J.B.S., and Fabrycky, W.J., Systems Engineering and Analysis, 3^rd Ed., NJ, USA, Prentice Hall, 1998.

Cameron, B., “MBSE: The Next Revolution of Systems Engineering” (virtual classroom presentation), Massachusetts Institute of Technology, MA, USA, April 2018.

Cantwell, P.R., Sarkani, S., and Mazzuchi, T.A., “Dynamic Consequences of Cost, Schedule, and Performance within DoD Project Management,” Defense Acquisition University, Defense Acquisition Research Journal, vol.20, no.1, pp.89-116, VA, USA, 2013.

Chalfant, J., “Early Stage Design for Electric Ship,” Proceedings of the IEEE, vol.103, no.12, USA, 2015.

Finalcad, “62 Percent of Construction Leaders Say Lack of Collaboration is the Biggest Cause of Project Delays,” [Online]. Available here. May 5, 2020, [Accessed October 2020].

Honour, E., Executive Summary: Systems Engineering Return on Investment, PhD thesis, Defense and Systems Institute, School of Electrical and Information Engineering, University of South Australia, January 2013.

Honour, E, “Systems Engineering Return on Investment,” Webinar, [Online]. Available on YouTube^CA: https://www.youtube.com/watch?v=vJbvDwY3Ra8&t=27s, September 21, 2016, [Accessed October 2020].

Inayat, U., Dunbing, T., and Leilei, Y., “Engineering Product and Process Design Changes: A Literature Overview,” Procedia CIRP at ScienceDirect.com, vol.56, pp.25-33, 2016.

INCOSE, Systems Engineering Handbook, 4^th Ed., NJ, USA, John Wiley and Sons Inc., 2015.

Johnson, J., “Cost Overruns, Schedule Slips: The Norm, Not the Exception,” [Online]. Available here. January 5, 2018, [Accessed October 2020].

Jonkers, R., and Shahroudi, K.E., “A Design Change, Knowledge and Project Management Flight Simulator for Product and Project Success,” IEEE Systems Journal, USA, July 21, 2020.

Kennedy, B.M., Sobek, D.K., and Kennedy, M.N., “Reducing Rework by Applying Set-Based Practices Early in the Systems Engineering Process,” Systems Engineering, INCOSE, vol.17, pp.278-296, San Diego, CA, USA, 2013.

Laverghetta, T., and Brown, A., “Dynamics of Naval Ship Design: A Systems Approach,” USN Engineers Journal, vol.111, no.2, USA, 1999.

Lee, T.H., Shiba, S., and Wood, R.C., Integrated Management Systems: A Practical Approach to Transforming Organizations, NJ, USA, John Wiley and Sons, 1999.

Lombardi, B., and Rudd, D., “The Type 45 Daring-Class Destroyer: How Project Management Problems Led to Fewer Ships,” Naval War College Review, vol.66, no.3, USA, summer 2013.

Meadows, D., Thinking in Systems, Sustainability Institute, VT, USA, Chelsea Green Publishing, 2008.

Morkos, B., Shankar. P., and Summers, J.D., “Predicting Requirement Change Propagation Using Higher Order Design Structure Matrices: An Industry Case Study,” Clemson Engineering Design Applications and Research, no.2, TigerPrints, 2012.

Parker, J., “Why is it So Hard to Procure a Warship,” Frontline Defense Magazine, vol.13, no.3, Canada, 2016.

Prusak, L., “Capturing the Value of Project Management through Knowledge Transfer,” Pulse of the Profession ®, In-Depth Report, Project Management Institute, PA, USA, 2015.

Ramanathan, C., et al., “Construction Delays Causing Risks on Time and Cost – a Critical Review,” Australasian Journal of Construction Economics and Building, vol.12, no.1, Australasian, 2012.

Rebentisch, E., Integrating Program Management and Systems Engineering: Methods, Tools, and Organizational Systems for Improving Performance, NJ, USA, John Wiley and Sons, 2017.

Senge, P.M., The Fifth Discipline – The Art and Practice of the Learning Organization, NY, USA, Doubleday, 1990.

Siemiatycki, M., “Cost Overruns and Infrastructure Projects: Patterns, Causes and Cures,” [Online]. Available here. IMFG Perspectives, no.11, 2015, [Accessed October 2020].

Sterman, J.D., Business Dynamics: Systems Thinking and Modeling for a Complex World, Boston, MA, USA, Irwin McGraw-Hill Inc., 2000.

Walworth T.A., et al., “Estimating Project Performance through a System Dynamics Learning Model,” Systems Engineering, vol.19, no.4, pp. 334-350, 2016.

About the Authors

Raymond Jonkers served 22 years in various roles as a Marine Systems Engineer in the Canadian Navy and spent the last 15 years in the aerospace and marine industry in management and leadership positions.

Raymond is a professional engineer, project manager, and certified lean six-sigma master black belt. He has a PhD in Systems Engineering from Colorado State University.

Raymond currently provides services as the principal consultant at Merlantec Management and Engineering Inc. These consulting services include research, project management, strategic management, systems engineering, data analytics, modeling and visualization.

Since 1997, Kamran Eftekhari-Shahroudi has held the roles of Senior Technical Consultant, Lead Controls & Dynamics Analyst, Program Manager, Senior Engineering Manager and Principal Systems Engineer in Industrial Controls, Corporate Technology and Airframe Systems divisions at Woodward, Inc.

In 2008, Kamran became an industrial member of the founding committee tasked with kick starting the new Systems Engineering program at CSU. This involved understanding the needs of 40 companies in Northern Colorado. Industrial and Business affinity continues to be a major steering force behind the impressive success and growth of the Systems Engineering department to this day where Kamran currently serves as a Professor of Systems Engineering.

Kamran is actively researching, developing, or teaching Anomaly-Based Controls, Wildfire Detection, Aerospace Actuation Systems, Integration of Systems Engineering with Program Management and Real-World Applications of (Model-Based) Systems Thinking.

• 1. Towards Systems Thinking – A Communication-Focused Learning Process

By

Erik Karlsson, AFRY, erik.karlsson@afry.com

Diana Malvius, AcademIQ Consulting

Mats Lindberg, AnalytikerByrån

Version 1.0, November 25, 2020

Abstract

Many organizations that develop and manage large and complex socio-technical systems over the life cycle are in the need of a shift in mindset towards a complexity-oriented worldview, accepting the uncertainties and limits to planning and controlling that comes with complexity. This paper proposes a view of such a shift in mindset as an iterative and incremental process of organizational learning enabled by enhanced communication about the system and its context. Improved communication is supported by a toolbox of mechanisms. The presented approach has been explored in a traditional administration agency within the public transportation sector. Preliminary results indicate promising shifts in mindset on individual levels, with key knowledge carriers and ambassadors emerging with the potential of a self-sustaining shift. However, the long-term effects on the overall organizational capability remain uncertain.

Copyright © 2020 by Erik Karlsson, Diana Malvius, Mats Lindberg. All rights reserved.

Introduction

Many organizations and their life cycle management approaches are built on a mechanical view of the world (Boulton et al., 2015), where the system and its context are assumed to work like a machine, where facts can be analyzed, the future predicted, plans made and executed, and outcomes measured and controlled. A mechanical worldview provides a sense of order, purpose, and control. The nature of complex systems in an ever-changing context, however, is quite different. What is needed is a transformation to a more systems-oriented complexity worldview (Boulton et al., 2015), where the world is regarded as essentially interconnected, and where patterns and dependencies are shaped by history and context. A complexity worldview emphasizes the limits to certainty, that all things are continuously changing, and unexpected futures may emerge.

The capability of an enterprise to develop and manage large and complex socio-technical systems over the life cycle is dependent on both formal and informal structures within the enterprise. The formal structure is defined by organizational model, life cycle process framework, governance, and management policies. Roles and responsibilities, the intended flow of information between organizational units, and alignment, coordination and prioritization of work with respect to enterprise goals and objectives are all important aspects in the need of a systems perspective (Blanchard and Blyler, 2016). Informal structures are reflected by de facto communication patterns and information flows, organizational culture, and mindset. The mindset is the view of the enterprise and its constituent members of the system they manage. Mindset comprises mental models and assumptions regarding how to understand the system and its context and how to control or influence it towards an intended state.

Often, capability deficits or organizational problems are addressed by changes to the organization, governance models, or process frameworks, i.e. changes in the formal structures of the enterprise. This typically takes time and is difficult: and challenging when needs and problems are obvious. Furthermore, organizational changes tend to be ineffective, not providing solutions to the problems (By, 2005). The dysfunctions of traditional management systems tend to keep many organizations trapped in a constant “fire-fighting mode”, always dealing with the most urgent matters, with little time, energy, or insight to take a step back, re-think, and to learn (Senge, 2006).

Figure 1. Mindset and organizational culture as contributing factor to systems management capability.

This paper focuses on the possible impact of incremental “informal changes”, communication-driven shifts in mindset, and organizational culture in an environment where formal organizational structures and process frameworks are rigid and not subject to short-term changes (see Figure 1). The well-known Conway’s law (Conway, 1968) states that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations”.

We have previously reported on a case study from a traditional administration and acquisition agency within the public transportation domain, a highly process-oriented and project-focused organization with fragmented systems and life cycle perspectives, where we explored different communication mechanisms aimed at shifting the mindset and improving systems thinking capabilities within the organization (Karlsson et al., 2020). We refer to that paper for a more in-depth description of the identification and characteristics of each mechanism. This paper expands on the findings from the case study, and presents a framework to define the transformation of organizational mindset as a process of organizational learning.

Mindset Shift as an Iterative Learning Process

Bloom (1956) defines a generic hierarchical model for the classification of learning objectives in increasing levels of complexity. The six levels are knowledge, comprehension, application, analysis, synthesis, and evaluation (see Table 1). Shifting the mindset within an organization from a predominantly mechanical, project-oriented one towards a more complexity-driven, systems-oriented situation can be viewed through the lens of such a learning process, at the individual as well as at the organizational level. The learning process can be viewed as an iterative one, where the different stages represent an incremental level of increasing insight.

The first stage is the recognition of facts, accepting the degree of complexity of the system, and what that means. The system continuously evolves and new facts may emerge over time. Based on facts and complexity acceptance, an increased level of understanding of the sources of complexity and behavioral patterns may be built up. New patterns may emerge and complexity may increase or decrease over time. An increased understanding enables the ability to employ the complexity insights into the design of or alterations in the system architecture or operational scenarios, analyze different alternatives, and aggregate information on higher system levels in continuous loops throughout the life cycle.

Table 1. Shift towards a systems-oriented mindset as a learning process in different levels.

Level	Characteristics of a systems-oriented mindset	Typical questions of improved learning
Knowledge	Recognition of facts, theories, or generalizations.	“What is a complex system?” “To what degree is the system complex?” “What does the level of complexity say about the system’s behavior and our ability to influence it?”
Comprehension	An increased level of understanding of the facts, achieved through organizing, interpreting, and describing characteristics.	“Why is the system complex?” “What interactions and dependencies give rise to the observed system effects?” “Is the system complexity increasing or decreasing, and why?”
Application	Understanding the context of the structures and rules and how to use the acquired knowledge of the system in new contexts.	“Why is the legacy system designed as it is, under what assumptions and constraints?” “Do the same principles apply today and in the current operational context, or do we have to revise and question guiding principles and axioms?”
Analysis	Examining information and information needs regarding the system and setting suggested system modifications or developments in a systems perspective.	“What are valid and feasible design alternatives or scenarios?”
Synthesis	The coming together of different paths of information and design alternatives, forming a new whole.	“How do deliverables, individually and as aggregates of change, contribute (or not) to overall system capabilities or objectives?”
Evaluation	The continuous judgement and defending of chosen alternatives in the light of new information, new knowledge, or new circumstances.	“The chosen alternative may have been right at the time, but is it still, knowing what we know now?”

The iterative nature of this model resembles the idea of the hermeneutic circle model (Coakes and Sugden, 2000), which expresses the dialectic principle that one must view and understand the parts in relation to the whole, as well as view and understand the whole in relation to the parts. Individual parts contribute new information that builds knowledge, and this learning process shifts the mindset of the observer. The shifted mindset then becomes the new context, in which the individual parts are viewed and understood in new light, perpetuating the learning process. The iterative nature of the process is captured in Figure 2.

Figure 2. Incremental stages and iterative loops of organizational learning.

Communication Support to Mindset Transformation

How does one bring about such a learning process within an enterprise? According to Conway, communication structures are a key to organizational output. Information flows, i.e. with whom different organizational units communicate, is important, as well as information content, i.e. what we say about the system. Thus, we developed a toolbox of support mechanisms for enhanced communication about the system (Karlsson et al., 2020). The mindset shift can be seen as going from a problem space, characterized by a process-oriented and project-focused organization with fragmented system perspectives, to a solution space where system complexity is accepted, different integrated system perspectives are visualized, inherent legacy design principles are understood and applied, and the development path of the system is continuously evaluated according to the current circumstances (see Figure 3).

The toolbox allows for different initial knowledge levels among individuals, yet still being able to adapt and make use of the toolbox. Also, more advanced people may be challenged and help out in the development of the next company generation of these mechanisms, as well as being mentors and ambassadors for less advanced colleagues.

Figure 3. A communication toolbox to support a learning process towards a systems-oriented mindset.

Summary and Conclusions

We present a framework to view the shift to systems thinking within an organization as an incremental and iterative learning process driven by changes in how the organization communicates about a system at hand and its characteristics. The incremental and iterative nature of the model emphasizes building and applying knowledge and understanding in a perpetual learning loop. Shifting mindsets and organizational culture may well take time, but once key knowledge carriers and ambassadors emerge, the potential of a self-sustaining shift can occur.

The learning process may occur at the management/executive level, the team level, as well as at the individual level. The presented framework may be of interest for project managers, developers, or team members identifying with the challenges described, who identified the need for a complexity-oriented worldview and seeking supporting ideas to shift the mindset of their organization. The insights presented may also be interesting for senior management looking for a path and examples to improve learning within their organization.

The case study resulted in creating desired pull effects. The need for a system’s perspective in the organization was articulated both by management, project managers, and team members. For further work, we aim at development of an organization self-assessment model, to gauge the maturity of systems thinking and suggest approaches for toolbox application.

References

Blanchard, B. S. and J. E. Blyler, System Engineering Management, 5th Ed, John Wiley & Sons, Inc., Hoboken, NJ, 2016.

Bloom, B. S., M. D. Engelhart, E. J. Furst, W. H. Hill, and D. R. Krathwohl, Taxonomy of Educational Objectives: The Classification of Educational Goals. Handbook I: Cognitive Domain, David McKay Company, New York, NY, 1956.

Boulton, J, P. M. Allen, and C. Bowman, Embracing Complexity. Oxford University Press, Oxford, 2015.

By, R. T., “Organizational Change Management: A Critical Review”, Journal of Change Management, vol. 5, no. 4, pp. 369 –380, 2005.

Conway, M., E. “How do Committees Invent?” Datamation Magazine, vol. 14, no. 5, pp. 28–31, 1968.

Coakes, E. and G. Sugden, “Knowledge Management in the University Sector: Some Empirical Results”, in Khosrowpour, M. (ed.) Challenges of information technology management in the 21st century, Idea Group Publishing, Hershey, PA, 2000.

Karlsson, E., D. Malvius, and M. Lindberg, “Mechanisms for a Systems-Oriented Mindset – Towards Organizational Systems Thinking”, INCOSE International Symposium 2020.

Senge, PM The Fifth Discipline: The Art and Practice of the Learning Organization. Crown Business, New York, N. Y., 2006.

About the Authors

Erik Karlsson is a Systems Engineering consultant and trainer at AFRY, with experience from the aviation, defense, and public transportation sectors. He is a CSEP and PMI PMP, and holds Master of Science degrees in vehicle and mechanical engineering from the Royal Institute of Technology in Stockholm and Technical University in Munich, respectively. He is active in INCOSE as secretary of the Sweden chapter.

Diana Malvius, Ph.D. (2009), the Royal Institute of Technology in Stockholm, and founder and CEO of AcademIQ Consulting, has more than 15 years of experience from working with systems development in government, industry, and academia. Her educational background in engineering and organizational studies, in combination with a long-term consultancy profile and role as a senior researcher has given her a broad base from which to approach organizations dealing with complex systems. Her skills and expertise are in systems engineering, systems modeling, and systems thinking

Mats Lindberg is an experienced developer in Systems Engineering with a history of working in the armed forces at both the strategic and operational levels, state agency, public administration, and as a re-searcher. Mats is skilled in crisis management, intelligence analysis, analytical methods, and the ability to see outside-the-box solutions paired with scientific methods. Mats holds a master’s degree in mechanical engineering specializing in calculus and vessels, is a doctoral student in industrial work science, and a trained officer up to a colonel degree.

• 1. Digital Engineering Information Exchange (DEIX) Working Group – Digital Viewpoint Model (DVM) Concept and Development

By

Celia Tseng, Raytheon Technologies

Sean McGervey, Johns Hopkins University Applied Physics Laboratory

Tamara Hanbrick, Northrop Grumman

Version 1.0 November 1, 2020

Web site: http://www.omgwiki.org/MBSE/doku.php?id=mbse:deix

Abstract

The Digital Engineering Information Exchange Working Group (DEIX WG) is a collaboration between the International Council on Systems Engineering (INCOSE), the National Defense Industry Association (NDIA) Modeling and Simulation (M&S) Subcommittee, and the Department of Defense, Office of the Under Secretary for Research and Engineering (DoD/OUSE (R&E)). The DEIX WG supports the strategic objective to accelerate the digital engineering transformation by evolving the characterization of the content and relationships involved in the exchange of digital artifacts between disciplines and stakeholders throughout the engineering lifecycle. The DEIX WG aspires to ensure that digital artifacts are transferable within industries with complex systems. To address the challenges of digital artifact exchange, the Digital Viewpoint Model (DVM) sub team has created a concept model to define key concepts of exchange.

Copyright © 2020 by Celia Tseng, Sean McGervey, and Tamara Hanbrick. All rights reserved.

Introduction

As more organizations and disciplines move toward a model-based engineering (MBE) approach, there is a growing need to share, cross-reference, integrate, reuse, and extend models to digitally represent a total system model. Industries and governments have a long history of using a document-based engineering exchange approach; they must now convert to model-based digital artifacts with their currently disjointed use of models. Industries have the added challenge of exchanging engineering information in a new digital environment, while addressing issues like tool interoperability, model language and standards, obsolescence, workforce development, and organization cultural change. The goal is to synthesize actionable knowledge from various sources of digital information and models.

DEIX WG DVM Background

The initial groundwork for the DVM sub team began in 2018. The NDIA Modeling and Simulation Committee sponsored a two-day Digital Artifacts Workshop where the focus was to define how digital models can interoperate to support data exchange between two parties, an acquirer and a provider. The participants divided into three teams to analyze the perspectives of an acquirer, provider, and the conceptual modeling of Digital artifacts for exchange. The outputs from the workshop were used to create the first draft of the DVM concept model during the 2019 INCOSE International Workshop (IW). The team gained consensus on the DVM concept model at the 2019 NDIA Systems and Mission Engineering Conference, and launched an open DVM challenge in July 2020 to seek proposed implementations and extensions of the DVM concept model.

DEIX DVM Concept Model

The DEIX DVM Concept Model captures high-level concepts needed to describe the definition and relationships for digital information exchange. It is divided into three categories of ontologies: product, process, and stakeholder. The three categories are related to each other and provide a common language for specifying the content of digital artifacts that is represented by a digital view for user consumption.

DEIX Challenge

The DEIX WG initiated the Digital Engineering Information Exchange Challenge (“the Challenge”) in July 2020, culminating in the “Challenge Results Out-brief” at the Virtual 2020 NDIA Systems and Mission Engineering Conference. The Challenge seeks user-specific extensions of the DVM concept model from participants. The Challenge is not a competition between participants, but an opportunity for individuals and organizations to help shape the future of Digital Engineering information exchange by proposing enhancements to current practice, based on use case scenarios that support real-world needs. The use case scenarios will provide context concerning why the information is exchanged, the authoritative source for exchanged information, and how the information inter-relates. The results of the DEIX Challenge will serve to identify where the gaps are in current practice, as well as a proposed path forward to provide mature tools, standards, infrastructure, and languages to address the identified gaps.

The DEIX challenge submissions build upon the DVM concept model and propose one or more digital views that could be used for providing and consuming digital information pulled from multiple digital artifacts. Examples of digital artifacts that could be synthesized from various sources include Systems Modeling Language (SysML) models for MBSE; MATLAB performance models; Mechanical and Electrical Computer-Aided Design (MCAD and ECAD) models; Finite Element Analysis (FEA) models; and many others. The content, form, and function of the proposed digital views are documented in a concept model provided by the Challenge participants as part of the submission.

DEIX Challenge Status and Path Forward

DEIX Challenge submissions were accepted through November 13, 2020. Submissions were presented by the participants at the DEIX WG Challenge Results out brief on November 20, 2020. The results will be analyzed to identify similarities and trends in the proposed digital views as well as gaps that have been identified. The DEIX WG will then develop a plan to address the identified needs by creating a catalog of Digital Views informed by the submissions, and refine the Digital Viewpoint Model (DVM) Concept Model to provide a common ontology for relating the concepts in them.

Summary and Conclusions

Despite advances in the digital era, there are significant inefficiencies when suppliers, acquirers, and internal team members exchange engineering information following a traditional document-based approach. The DEIX WG aspires to ensure that digital artifacts are transferable within industries with complex systems. The DVM model seeks to model the concepts of curating a set of digital artifacts for exchange in a digital engineering environment. The DEIX challenge seeks to refine the DVM concept for developing constructs for assembling digital artifacts, and identify standard gaps necessary for exchange.

List of Acronyms Used in this Paper

Acronym Explanation

DEIX WG Digital Engineering Information Exchange Working Group

Digital Artifacts Any combination of model data and meta-data that are exchanged within a digital ecosystem.

Digital View A visual presentation on an electronic display device consisting of one or more processed digital artifacts, enabling the consumption of digital artifact content according to stakeholders’ unique activities at any phase or step in the system life cycle.

Digital Viewpoint A digital view that uses conventions, formalisms, and standards to define the systematic procedures to select, compile, layout, and present digital artifacts in a digital ecosystem such that it meets stakeholders’ unique needs.

DVM Digital Viewpoint Model

DoD/OUSE (R&E) Department of Defense Office of the Under Secretary of Research and Engineering

INCOSE International Council on Systems Engineering

IW International Workshop

NDIA National Defense Industry Association

References

DEIX Working group website http://www.omgwiki.org/MBSE/doku.php?id=mbse:deix

Office of the Deputy Assistant Secretary of Defense for Systems Engineering, “Digital Engineering Strategy,” U.S. Department of Defense, Washington, DC, 2018.

C. Zins, “Conceptual approaches for defining data, information, and knowledge,” Journal of the Association for Information Science and Technology, vol. 58, no. 4, pp. 479 – 493, 2007.

D. L. Howell, “OMB MBSE Wiki: Digital Engineering Ecosystem,” Object Management Group (OMG), 7 December 2018. Available at http://www.omgwiki.org/MBSE/doku.php?id=mbse:digital_engineering_ecosystem.

T. Hambrick and J. Madsen, “OMG MBSE Wiki: Digital Thread,” Object Management Group (OMG), 1 November 2018. Available at http://www.omgwiki.org/MBSE/doku.php?id=mbse:digital_thread.

T. P. Alexander and J. H. Coleman III, “OMB MBSE Wiki: Authoritative Source of Truth,” Object Management Group (OMG), 4 December 2018. Available at http://www.omgwiki.org/MBSE/doku.php?id=mbse:authoritative_source_of_truth.

J. H. Coleman III, “OMG MBSE Wiki: Digital Viewpoint,” Object Management Group (OMG), 12 December 2018. Available at http://www.omgwiki.org/MBSE/doku.php?id=mbse:digital_viewpoint.

J. H. Coleman III, “OMB MBSE Wiki: Digital View,” Object Management Group (OMG), 8 November 2018. Available at http://www.omgwiki.org/MBSE/doku.php?id=mbse:digital_view.

J. H. Coleman, “MBSE Wiki: Digital Artifact,” Object Management Group (OMG), 7 January 2019. Available at http://www.omgwiki.org/MBSE/doku.php?id=mbse:digital_artifact.

About the Authors

Celia Tseng is a systems engineer with 16 years of experience in aerospace and defense, with a Master’s degree in systems engineering from Cornell University. She is a certified INCOSE systems engineering professional (CSEP), OMG certified model-based systems modeler (OCSMP) and SAFe certified Scrum Master. She is currently a systems engineer in Raytheon Technologies.

Sean McGervey is a Systems Engineer at the Johns Hopkins University Applied Physics Laboratory, where he was Architecture Lead on a Major Defense Acquisition Program (ACAT-1) for the US Navy and is a key contributor to efforts supporting the Digital Engineering Transformation of APL’s DoD Sponsors. Sean founded and leads the APL MBSE Community of Practice, teaches three courses in MBSE at APL, and teaches an “Applied Analytics for MBSE” course for JHU’s graduate program in Systems Engineering. Sean is also Chairperson of the INCOSE Digital Engineering Information Exchange Working Group (DEIXWG), a key element of the broader effort to drive forward OSD’s Digital Engineering initiative.

Prior to joining APL, Sean worked for 15 years in the Systems Engineering Department at Northrop Grumman Mission Systems in Baltimore, Maryland. While there, Sean practiced MBSE on multiple programs and founded the Northrop Grumman Corporate Model-Based Engineering (MBE) Community of Practice.

Tamara Hambrick serves as Systems Engineering Control director within the Systems Engineering and Integration Integrated Product Team of GBSD for the Strategic Deterrent Systems Division of Northrop Grumman Space Systems. In this role, Hambrick is responsible for leading engineers and managers in the implementation of model-based systems engineering for architecture models, integration approach, readiness assessments, and product quality metrics development and monitoring.

She previously served as the functional director of Systems Engineering and Electronics & Payloads, Palmdale Aircraft Integration (PAI) Center of Excellence (CoE) for Northrop Grumman Aeronautics Systems where she was responsible for technical performance through improvements in personnel staffing, tools, processes, and metrics.

Hambrick is a leader in driving technical innovation, influencing change, and developing the next generation of thought leaders, advocates, and practitioners in model based systems engineering for the last 15 years. She has held model-based advisory and IPT leadership roles for radar, open electronic warfare, avionics, cyber, space, and missile defense programs.

Hambrick holds a bachelor’s degree in engineering science from Pennsylvania State University, as well as a master’s certificate in systems engineering from Johns Hopkins University, and a graduate certificate in architecture and systems engineering from Massachusetts Institute of Technology.

NOTABLE ARTICLES AND PRESENTATIONS

• 1. Presentation: A Model-based Approach to PM/SE Integration

This presentation by Kamran Shahroudi and Ray Jonkers complements the Feature Article by the same authors in this issue. Kamran is a member of INCOSE’s Model Based Systems Engineering (MBSE) Working Group and also the INCOSE Program Management and Systems Engineering Integration Working Group (PM/SE Integration WG). The purposes of the authors’ efforts are 1) to advance the field of PM/SE Integration; 2) to describe and demonstrate a novel approach and practical integrated model for PM/SE integration, for which they have created a model-based PM/SE Integration Prototype called a “Management Flight Simulator”; 3) to describe linkages the within the prototype for effective PM/SE integration and collaboration; 4) to provide a glimpse into (the hopefully not too distant future) where MBSE philosophy and tools can mature to support PM/SE Integration; and 5) to obtain validation in the approach and ability of the prototype to enhance PM/SE Integration. This presentation includes a number of additional, attractive slides and provides an exciting path forward utilizing a model-based approach to help facilitate PM/SE integration.

View the Presentation

• 1. Architecture Development Methodologies Presentation

By

John Lynch, Enterprise Architect, SAIC

The purpose of this presentation is to report results concerning an investigation of Architectural Development Methodologies (ADM) and provide a recommended ADM for use in the development of Future Ground, the future of combat vehicles.

The goals of an ADM are 1) to fit within the existing U.S. Department of Defense (DoD) business practices; 2) cover the lifecycle; 3) be comprehensive; and 4) be easy to convey.

The presentation includes analysis of common ADMs used by the U.S. Government, namely: 1) the Open Group Architectural Framework (TOGAF); 2) the U.S. DoD Architectural Framework (DoDAF); and 3) the Joint Architecture Reference Model (JARM).

The recommended ADM (Visual DoDAF [vDoDAF] blends the best of TOGAF and JARM with DoDAF.

View the Presentation.

• 1. The Impact of Human Factors Engineering, Systems Engineering, and Information/Communications Technology in Healthcare

By

George Grant, CSEP

Abstract

The United States (U.S.) healthcare delivery system lacks efficiency, quality, coordination, safety, is costly, and does not sufficiently support physicians, nurses, administration, patients, etc. (Fowler et al., 2011). For years, the focus has been towards the innovation of life sciences, physical sciences, and engineering of medical devices, instruments, and equipment treating patients (Reid et al., 2005). The advancements in healthcare have improved the quality of care, but also at a cost. Additionally, the lack of attention paid to the healthcare delivery system is one of the driving factors for increased costs (Reid et al., 2005). The purpose of this article is to discuss the impact of Human Factors Engineering (HFE), Systems Engineering (SE), and Information/Communications Technology (IT) associated with the healthcare delivery systems.

Read the Article

• 1. What’s Different about an Integrated Approach?

Editor’s Note

As I began reading Integrating Program Management and Systems Engineering: Methods, Tools and Organizational Systems for Improving Performance shortly after its release in April 2017, it occurred to me that there must be a set of factors that differentiate a superior approach for development of complex systems from less successful approaches. Over the four weeks during which I digested “the book”, I evolved a list of factors, providing for each one a carefully articulated description of the factor and how it seems to present itself in each of the two approaches. This living document is in its eighth version. It identifies 32 factors with descriptions. I’ve shared the document with several colleagues over the past four years. As you have read in PPI SyEN, the “Integration Initiative” is gaining momentum.

I’m hopeful that this artifact will be useful to us as we continue to work toward the situation in which we are increasingly successful in developing, deploying, and maintaining complex systems.

Please let me know if you think of another factor or if you have suggestions concerning the current set!

You will see that there is unlimited opportunity to work toward continuous improvement on any program or project and in any organization, simply by identifying and describing the situation with respect to any factor and analyzing how it might be further strengthened and improved.

Let’s get better!

An approach that is used by several of the organizations for which I have worked (TRW, PRC, Litton-PRC, Northrop Grumman IT, and MITRE) is to have a small but effective process improvement group composed of several senior software and systems engineers. In the situation where this group is strongly supported by senior leaders, great things can happen. Once again, the critical factor is leadership.

View the list of factors that differentiate superior factors from less successful factors here.

• 1. What’s Resilient Hospital Reference Model (RHRM) MBSE Project

Abstract

This presentation gives an update to an ongoing project by a volunteer cross-domain team (INCOSE, IEEE, FBI/InfraGard, and Medical Experts) to apply model-based analysis, engineering, and evaluation methods to develop a Resilient Hospital Reference Model (RHRM). Outcomes from this project include a model-based decision support capability that hospitals can use to enhance catastrophic event preparedness (protection, prevention, response, mitigation, recovery, evaluation, and reporting). The initial scope of the project emphasizes developing a resilience reference framework for hospitals to use in preparing for, handling, and learning from a prolonged power outage.

Speaker

Mike Pafford, a 22-year INCOSE member, and past Chesapeake Chapter President, is giving this project update presentation as a member of the volunteer Resilient Hospital Systems Engineering Team (RHSET) that has been working together on this RHRM MBSE project since 2017. Team members include MBSE practitioners from INCOSE, IEEE, and FBI/ InfraGard, as well as domain experts from across the national, regional, state, and local healthcare communities. The project was recognized with a 2018 Collaboration Award at the 2019 INCOSE International Workshop.

Watch the Presentation

SYSTEMS ENGINEERING NEWS

• 1. New Systems Engineering Roadmap to Improve Dutch High-Tech Manufacturing Power

By

Bart Brouwers, Media52 BV

Co-founder and co-owner of Media52 BV, the publisher of innovationorigins.com:

“The goal is earning power for the Netherlands, a global top position for our

manufacturing industry, and a focused approach to our major societal challenges.”

In the Dutch high-tech manufacturing industry, brands such as ASML, Philips, VDL, Thermo Fisher Scientific, Vanderlande, Thales, and Lely have had a significant impact on worldwide engineering. Yet, there is also work to be done: how does the Dutch high-tech manufacturing industry secure the available knowledge, how do they ensure sufficient new staff, and, above all, how do they continue to develop the High-Tech Systems & Materials (HTSM) sector?

A new HTSM Systems Engineering Roadmap has been drawn to help achieve these goals. Based on broad societal challenges and with the aim of supporting the earning capacity of the Netherlands, the roadmap focuses on the structural collaboration between the Dutch industry, academia, and research institutions.

Read the Article

• 1. Integrating Program Management and Systems Engineering book is available in Russian

PPI SyEN Subscribers will recall a series of articles provided in PPI SyEN issues 56 (published in August 2017) through 73 (published in January 2019) reporting on new research concerning systems engineering in a book titled Integrating Program Management and Systems Engineering: Methods, Tools, and Organizational Systems, published by Wiley, INCOSE, and the Project Management Institute (PMI).

“The Book” is often referenced as Rebentisch et al, 2017; Eric Rebentisch of the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts Institute of Technology (MIT) (USA) was the Editor-in-Chief of the book and MIT lead for the book. However, many other researchers and practitioners contributed to the book, including Stephen Townsend (PMI lead for the book), Tina Srivastava (MIT and INCOSE), Alan Harding, David Long, and John Thomas (all past Presidents of INCOSE), Randall Iliff (PPI and INCOSE lead for the book), Eileen Arnold, Jim Armstrong, Cecilia Haskins, Jean-Claude Roussel, and Ken Zemrowski (all members of INCOSE), and MANY others.

On October 14^th, 2020, Victor Batovrin, Professor, Systems Engineering Department at the Russian Technological University (MIREA), announced that Integrating Program Management and Systems Engineering translated into Russian is available.

A simplified Chinese version is also planned.

• 1. INCOSE 2020 Election Results

By

Danielle DeRoche

The Nominations & Election Committee has announced the results of the 2020 election.  These individuals will join the INCOSE Board of Directors on Friday, 29 January 2021, when they are installed during the opening plenary of the Virtual 2021 International Workshop.

Position (Term of Office)

• Asia-Oceania (Sector III) Director (3 years): Serge Landry
• Chief Information Officer (3 years): Barclay Brown
• Director for Outreach (3 years): – Julia Taylor
• Secretary (2 Years): Kyle Lewis

Congratulations to INCOSE’s new officers and directors!

• 1. INCOSE Certifications: Online Testing

Since many candidates cannot take the INCOSE ASEP/CSEP exam at a Prometric Test Center, INCOSE is investigating the possibility of offering online tests. A task team is in place to offer online exams around the world with maximum security measures soon.

Also, in the Q4 INCOSE Board of Directors meeting, a proposal to allow an individual to take the exam prior to becoming a member was put forth and agreed to.

• 1. Lincoln Laboratory establishes Biotechnology and Human Systems Division

MIT Lincoln Laboratory has established a new research and development division, the Biotechnology and Human Systems Division. The division will address emerging threats to both national security and humanity. Research and development will encompass advanced technologies and systems for improving chemical and biological defense, human health and performance, and global resilience to climate change, conflict, and disasters.

“We strongly believe that research and development in biology, biomedical systems, biological defense, and human systems is a critically important part of national and global security. The new division will focus on improving human conditions on many fronts,” says Eric Evans, Lincoln Laboratory director.

• 1. Webinar: Renewable Energy Systems as an Example of Layered Systems of Systems

INCOSE Sveriges December 17th (9-10 am CET) webinar will host Gerrit Muller speaking on renewable energy systems.

Abstract: The energy transition required to achieve the Paris climate agreement impacts the entire energy system. The energy system consists of many systems and an infrastructure connecting these systems. How can (Systems of) Systems Engineering assist in this complex transition? In this presentation, we will use a number of concrete examples to explore the systems engineering role and methods for this complex and dynamic application.

Gerrit Muller, originally from the Netherlands, received his master’s degree in physics from the University of Amsterdam in 1979. He worked from 1980 until 1997 at Philips Medical Systems as a system architect, followed by two years at ASML as manager systems engineering, returning to Philips (Research) in 1999. Since 2003, he has worked as a senior research fellow at the Embedded Systems Institute in Eindhoven, focusing on developing system architecture methods and the education of new system architects, receiving his doctorate in 2004. In January 2008, he became a full professor of systems engineering at University of South-Eastern Norway in Kongsberg (USN), Norway. He continues to work as a senior research fellow at the Embedded Systems Innovations by TNO in Eindhoven in a part-time position. Since 2020, he is INCOSE fellow and Excellent Educator at USN.

There is no fee for attending the webinar. Zoom is used for the broadcasting the webinar. Connect using this link. The zoom passcode is 343242.

FEATURED ORGANIZATIONS

• 1. American Institute of Aeronautics and Astronautics (AIAA)

With nearly 30,000 individual members from 91 countries, and 95 corporate members, AIAA is the world’s largest technical society dedicated to the global aerospace profession. Created in 1963 by the merger of the two great aerospace societies of the day, the American Rocket Society (founded in 1930 as the American Interplanetary Society), and the Institute of the Aerospace Sciences (established in 1933 as the Institute of the Aeronautical Sciences), AIAA carries forth a proud tradition of more than 80 years of aerospace leadership.

AIAA has teamed up with INCOSE to provide scholarships to engineering colleges and on a joint effort to update the ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents.

AIAA’s Journal of Aerospace Information System has recently announced a Call for Papers on SE’s Top Space Challenges, submissions are due on 31 March 2021. Find out more about the submission here.

• 1. Centre for Systems Engineering and Innovation (CSEI) Imperial College London

The Centre for Systems Engineering and Innovation at Imperial College London was founded in 2010 with investment from Laing O’Rourke to bring systems engineering and innovation to the built environment. The Centre is in the Faculty of Engineering and is located in the Department of Civil and Environmental Engineering. In the first five years, the Centre developed ways in which to bring world class process systems engineering and innovative science into building services technology and provided a focus for innovative teaching and research programs, with a fully accredited part-time and full-time Master’s Program in Systems Engineering and Innovation from 2011-2015.

Since October 2015, the Centre has broadened its engagement with industry, working with industry partners and members to develop world-leading research.

More Information

• 1. Centre for Swiss Society of Systems Engineering (SSSE)

The Swiss Society of Systems Engineering (SSSE) is a non-profit organization formed in 2011 by a group of like-minded engineers, working across a broad range of industries, who share the passion of practicing, advancing, and promoting Systems Engineering (SE) principles.

The SSSE has been officially recognized as the Chartered Swiss Chapter of INCOSE (International Council on Systems Engineering).

To join us, to share relevant information with the SE community, or simply to know more about what we do, visit our Website.

More Information

IEEE Systems, Man and Cybernetics Society (SMCS)

This is a “society for the advancement of theory and application in systems science and engineering, human-machine systems, and cybernetics”.

About SMCS (from the SMCS website):

Vision

The vision of the Systems, Man, and Cybernetics Society is to be recognized as the world leading society for the advancement of theory and application in systems science and engineering, human-machine systems, and cybernetics.

Mission

The mission of the Systems, Man, and Cybernetics Society is to serve the interests of its members and the community at large by promoting the theory, practice, and interdisciplinary aspects of systems science and engineering, human-machine systems, and cybernetics. It is accomplished through conferences, publications, and other activities that contribute to the professional needs of its members.

Values

The following fundamental values provide the foundation for all SMC Society activities:

• Membership: Maximize the value of being a member.
• Professionalism: Advance knowledge and professional development.
• Excellence: Deliver high quality and relevant services and products.
• Integrity: Act with honesty and fairness.
• Collaboration: Achieve results and excellence through teamwork.
• Communication: Promote honest and transparent interactions.
• Diversity: Embrace diversity of members and their ideas.
• Empowerment: Empower volunteers and value their contributions.
• Equality: Provide equal opportunities to all members.
• Respect: Practice respectfulness in all relationships.

Field of Interest:

Development of systems engineering technology including problem definition methods, modeling, and simulation, methods of system experimentation, human factors engineering, data and methods, systems design techniques and test and evaluation methods.

Integration of the theories of communication, control, cybernetics, stochastics, optimization, and system structure towards the formulation of a general theory of systems.

Application at hardware and software levels to the analysis and design of biological, ecological, socio-economic, social service, computer information, and operational man-machine systems.

NEWS ON SOFTWARE TOOLS SUPPORTING SYSTEMS ENGINEERING

• 1. Siemens expands software ecosystem for industrial additive manufacturing

Siemens Digital Industries Software is expanding its ecosystem for industrial additive manufacturing (AM) through partnerships with Morf3D, Sintavia and Evolve Additive Solutions. Through these new partnerships, Siemens is adding support for new methods of AM production as part of its Xcelerator™ portfolio of software and services.

• 1. Maplesoft releases MapleSim Insight

Maplesoft announced the release of MapleSim Insight, a new software product that provides simulation-based debugging and 3-D visualization capabilities that directly connect to their automation tools. As a result, engineers can perform simulation-based testing of their controller. MapleSim Insight works with automation tools that supports compiled Function Mock-up Units (FMUs), such as Rockwell Automation Studio 5000® Environment or MathWorks® Simulink®. The machine model is first developed in MapleSim, the advanced system-level modeling tool from Maplesoft, and then exported as an FMU, an open standard format for sharing models. MapleSim Insight connects to the automation tool, and displays visual results in real-time to show how the model behaves as the controller is running. MapleSim Insight provides both 3-D visualizations for quick visual feedback, and 2-D plots to get precise answers for testing and debugging, so the engineer can always get the level of detail required.

Read more

SYSTEMS ENGINEERING PUBLICATIONS

• 1. System Requirements Engineering: A SysML Supported Requirements Engineering Method

By

Jean-Yves Bron

The book deals with requirements engineering in the context of systems engineering. He proposes a method to guide this activity. The method is supported by the SysML modeling language. A first chapter aims to present the context and the associated definitions, to position requirements engineering in the processes system engineering, to define the modeling and its contributions, and to make the link with the management of IS projects. The second chapter is devoted to the proposed method for implementing the requirements engineering subprocesses. Each of eight activities is described before specifying how the SysML language can be leveraged to achieve it effectively. The third chapter is an application of the method to define the needs of the stakeholders of a system. The example is built on the basis of the RobAFIS’2018 competition. The fourth chapter continues the application of the method in the continuity of the IS processes to define the requirements of the same system. The appendices present a toolbox to realize the engineering of the requirements and also the complete results of engineering in Chapters 3 and 4.

Publisher: Wiley-ISTE; 1st Edition (July 16, 2020)

Format: Kindle, Hardcover

ISBN-10: 1786305941

ISBN-13: 978-1-119-75154-0

More Information

• 1. The Design and Engineering of Curiosity: How the Mars Rover Performs Its Job

By

Emily Lakdawalla

From the Amazon.com Website:

This book describes the most complex machine ever sent to another planet: Curiosity. It is a one-ton robot with two brains, seventeen cameras, six wheels, nuclear power, and a laser beam on its head. No one human understands how all of its systems and instruments work. This essential reference to the Curiosity mission explains the engineering behind every system on the rover, from its rocket-powered jetpack to its radioisotope thermoelectric generator to its fiendishly complex sample handling system. Its lavishly illustrated text explains how all the instruments work — its cameras, spectrometers, sample-cooking oven, and weather station — and describes the instruments’ abilities and limitations. It tells you how the systems have functioned on Mars, and how scientists and engineers have worked around problems developed on a faraway planet: holey wheels and broken focus lasers. And it explains the grueling mission operations schedule that keeps the rover working day in and day out.

Publisher: Springer; 1st ed. 2018 Edition (April 10, 2018)

Format: Kindle, Paperback

ISBN-10: 3319681443

ISBN-13: 978-3319681443

More Information

• 1. Software Engineering at Google: Lessons Learned from Programming over Time

By

Titus Winters, Tom Manshreck, and Hyrum Wright

From the Amazon.com Website:

Today, software engineers need to know not only how to program effectively but also how to develop proper engineering practices to make their code base sustainable and healthy. This book emphasizes this difference between programming and software engineering.

How can software engineers manage a living codebase that evolves and responds to changing requirements and demands over the length of its life? Based on their experience at Google, software engineers Titus Winters and Hyrum Wright, along with technical writer Tom Manshreck, present a candid and insightful look at how some of the world’s leading practitioners construct and maintain software. This book covers Google’s unique engineering culture, processes, and tools and how these aspects contribute to the effectiveness of an engineering organization.

You’ll explore three fundamental principles that software organizations should keep in mind when designing, architecting, writing, and maintaining code:

• How time affects the sustainability of software and how to make your code resilient.
• How scale affects the viability of software practices within an engineering organization.
• What trade-offs a typical engineer needs to make when evaluating design and development decisions.

Publisher: O’Reilly Media; 1st Edition (February 28, 2020)

Format: Kindle, Paperback

ASIN: B0859PF5HB

More Information

• 1. PPI Requirements Specification Development Guide

This guide, in its 4^th Edition, is crammed full of good advice on writing requirements and the transformation of requirements information content into effective requirements specifications. A requirement is a required characteristic of something (anything). Requirements may apply to a capability system, a physical item, a software item, a database, an interface, or a service. Numerous studies worldwide have concluded that defective requirements are the single biggest cause of project problems – loss of capability, cost overruns and schedule slippages. These conclusions have been consistent across many sectors. Projects can be conducted without facing significant risk from requirements defects. The advice in this Guide will help.

Download the PPI Requirements Specification Development Guide here.

• 1. Journal or Systems and Software

Editors-in-Chief:

P. Avgeriou and D. Shepherd

The Journal of Systems and Software publishes papers covering all aspects of software engineering. All articles should provide evidence to support their claims, e.g. through empirical studies, simulation, formal proofs or other types of validation. Topics of interest include, but are not limited to:

• Methods and tools for software requirements, design, architecture, verification and validation, testing, maintenance and evolution.
• Agile, model-driven, service-oriented, open source and global software development.
• Approaches for cloud/fog/edge computing and virtualized systems.
• Human factors and management concerns of software development.
• Artificial Intelligence, data analytics and big data applied in software engineering.
• Metrics and evaluation of software development resources.
• DevOps, continuous integration, build and test automation.
• Business and economic aspects of software development processes.
• Software Engineering education.

The journal welcomes reports of practical experience for all of these topics, as well as replication studies and studies with negative results. The journal appreciates the submission of systematic literature reviews, mapping studies, and meta-analyses. However, these should report interesting and important results, rather than merely providing statistics on publication year, venue, etc.

In addition to regular papers, JSS features two special tracks (In Practice, New Ideas and Trends Papers), as well as special issues.

In Practice is exclusively focused on work that increases knowledge transfer from industry to research. It accepts:

1. Applied Research Reports where we invite submissions that report results (positive or negative) concerning the experience of applying/evaluating systems and software technologies (methods, techniques and tools) in real industrial settings. These comprise empirical studies conducted in industry (e.g., action research and case studies) or experience reports that may help understanding situations in which technologies really work and their impact. Submissions should include information on the industrial setting, provide motivation, explain the events leading to the outcomes, including the challenges faced, summarize the outcomes, and conclude with lessons learned, take-away messages, and practical advice based on the described experience. At least one contributing author must be from industry.
2. Practitioner Insights where we invite experience reports showing what actually happens in practical settings, illustrating the challenges (and pain) that practitioners face, and presenting lessons learned. Problem descriptions with significant details on the context, underlying causes and symptoms, and technical and organizational impact are also welcome. Practitioner insights papers may also comprise invited opinionated views on the evolution of chosen topic areas in practice. Submissions in this category are limited to four pages and the first author must be from industry. Finally, submissions to this track should be within scope of the Journal’s topics of interest and they will be evaluated through industry-appropriate criteria for their merit in reporting useful industrial experience rather than in terms of academic novelty of research results.

New Ideas and Trends Papers

New ideas, especially those related to new research trends, emerge quickly. To accommodate timely dissemination of them, JSS introduces the New Ideas and Trends Paper (NITP). NITPs should focus on the systems/software engineering aspects of new emerging areas, including: the internet of things, big data, cloud computing, software ecosystems, cyber-physical systems, green/sustainable systems, continuous software engineering, crowdsourcing, and similar areas. We distinguish two types of NITPs:

• A short paper that discusses a single contribution to a specific new trend or a new idea.
• A long paper that provides a survey of a specific trend, as well as a (possibly speculative) outline of a solution.

NITPs are not required to be fully validated, but preliminary results that endorse the merit of the proposed ideas are welcomed.

We anticipate revisiting specific new trends periodically, for instance through reflection or progress reports.

New Ideas and Trend Papers warrant speedy publication.

Special Issues proposals

To submit a proposal for a special issue, please contact the Special Issues Editor Prof. W.K. Chan

Journal First Initiative

Authors of JSS accepted papers have the opportunity to present their work in those conferences that offer a Journal First track. Using this track, researchers may take the best from two worlds: ensuring high quality in the JSS publication (thorough, multi-phase review process of a long manuscript), while getting feedback from a community of experts and fostering possible collaborations during a scientific event.

Details may vary from conference to conference, but generally speaking, JSS papers to be presented in a Journal First track must report completely new research results or present novel contributions that significantly extend previous work. The ultimate decision to include a paper in the conference program is up to the conference chairs, not JSS. A JSS paper may be presented only once through a Journal First track.

Currently, the list of conferences with which JSS is collaborating, or has collaborated, through a Journal First track, is: ASE, ICSME, SANER, RE, ESEM, PROFES, and APSEC.

• Most Downloaded
• Recent Articles
• Most Cited
• Open Access Articles
  1. Journal or Systems and Software

By

Paul Solomon and Ralph Young

From the Amazon.com Website:

A complete toolkit for implementation of Earned Value Management

Performance-Based Earned Value uniquely shows project managers how to effectively integrate technical, schedule, and cost objectives by improving earned value management (EVM) practices. Providing innovative guidelines, methods, examples, and templates consistent with capability models and standards, this book approaches EVM from a practical level with understandable techniques that are applicable to the management of any project.

Clear and unambiguous instructions explain how to incorporate EVM with key systems engineering, software engineering, and project management processes such as establishing the technical or quality baseline, requirements management, using product metrics, and meeting success criteria for technical reviews. Detailed information is included on linking product requirements, project work products, the project plan, and the Performance Measurement Baseline (PMB), as well as correlating technical performance measures (TPM) with EVM. With straightforward instructions on how to use EVM on a simple project, such as building a house, and on complex projects, such as high-risk IT and engineering development projects, it is the only book that includes excerpts from the PMI®’s Project Management Body of Knowledge (PMBOK®), CMMI, the EVM System standard, systems engineering standards, federal acquisition regulations, and Department of Defense guides.

Performance-Based Earned Value allows both novices and experienced project managers, including project manager of suppliers and customers in the commercial and government sectors; software and systems engineering process improvement leaders; CMMI appraisers; PMI members; and IEEE Computer Society members to:

• Incorporate product requirements and planned quality into the PMB
• Conduct an Integrated Baseline Review
• Analyze performance reports
• Perform independent assessments and predictive analysis
• Ensure that key TPMs are selected, monitored, and reported
• Identify the right success criteria for technical reviews
• Develop techniques for monitoring and controlling supplier performance
• Integrate risk management with EVM
• Comply with government acquisition policies and regulations

Written by Paul Solomon and Ralph Young, internationally recognized industry experts, Performance-Based Earned Value is constructed from guidance in standards and capability models for EVM, systems engineering, software engineering, and project management. It is the complete guide to EVM, invaluable in helping students prepare for the PMI®-PMP® exam with practical examples and templates to facilitate understanding, and in guiding project professionals in the private and public sectors to use EVM on complex projects.

(PMI, PMBOK, PMP, and Project Management Professional are registered marks of the Project Management Institute, Inc.)

Publisher: Wiley and the IEEE Computer Society (December 1, 2006)

Format: Paperback

ISBN-10: 0471721883

ISBN-13: 978-0471721888

More Information

EDUCATION AND ACADEMIA

• 1. MSU (USA) Professor Wins National Award Recognizing Innovative Engineering Education

Durward Sobek. MSU Photo by Kelly Gorham

A Montana State University professor has won national recognition for innovative education practices aimed at preparing engineering graduates to proactively solve problems and better society.

Durward Sobek, professor in the Department of Mechanical and Industrial Engineering in MSU’s Norm Asbjornson College of Engineering, was selected by the Kern Entrepreneurial Engineering Network as a 2020 Engineering Unleashed Fellow. The inaugural cohort for the award includes 43 engineering faculty nationwide.

“This is a really nice honor,” Sobek said. “I’m excited to continue exploring ways to bring innovation into the classroom to benefit our engineering students.”

Sobek restructured the class to focus more on open-ended, real-life case studies posed by a local manufacturing company. Students worked together in teams to conduct independent research and propose a range of potential solutions.

“It means the students need to ask a lot of questions and gather a lot of information about the context of the problem and who the stakeholders are,” Sobek said. “It’s a great indicator that these new approaches can be very impactful, both for students and faculty, as we work to prepare the future engineers and leaders that society needs”.

• 1. Master of Science in Systems Engineering at Virginia Polytechnic Institute and State University, United States

The online MS in Systems Engineering degree program from Virginia Polytechnic Institute and State University prepares students to integrate many different engineering specialties into a total engineering effort to ensure an efficient and effective product (system) output. Students learn to analyze the operational needs of industrial, business, and government enterprises and apply scientific and engineering technology to develop the integrated hardware and software required to meet those needs.

Find out more

Master of Systems Engineering (MSysEng) at University of Pretoria, South Africa

The Master of Systems Engineering program strives to develop professionals with advanced abilities in applying fundamental systems engineering sciences and related interdisciplinary principles enabling them to contribute as advanced Systems Engineers. The Master of Systems Engineering Program focus on the development of professionals for System Engineering leadership roles in engineering and related technology fields.

The outcomes of the program are to:

• Identify, assess, formulate, interpret, analyze and solve Systems Engineering problems creatively and innovatively by applying relevant fundamental knowledge of i.e. mathematics, science and engineering sciences.
• Plan and manage Systems Engineering research demonstrating an underlying fundamental knowledge, understanding and insight into the principles, methodologies and concepts that constitute socially responsible (to local and other communities) engineering research/development in the chosen field of research practice.
• Organize and manage him/herself and his/her activities responsibly, effectively, professionally and ethically and take responsibility within his/her own limits of competence and to exercise judgment commensurate with knowledge and expertise.
• Use and assess appropriate Systems Engineering research methods, skills, tools, technology and information technology effectively and critically in engineering research/development practice and show an understanding and a willingness to accept responsibility for the impact that engineering research/development practice have on society and the environment.
• Employ various learning strategies and skills to master outcomes required in preparing him/herself to engage in continuous learning to keep abreast of knowledge and skills required in the Systems Engineering field.
• Participate as a responsible citizen in the life of local, national, and global communities by acting professionally and ethically.

Find out more here

SOME SYSTEMS ENGINEERING RELEVANT WEBSITES

Curious Cat Science and Engineering

This site examines STEM education and the societal impact of science and technology. This blog provides insight into what is happening in the engine field and the other industries that might impact on engineering.

https://engineering.curiouscatblog.net/category/engineering/

The Engineer – UK

The Engineer provides in-depth articles and news updates on timely issues like COVID-19, new research findings and the latest technologies.

https://www.theengineer.co.uk/

Engineering Ethics Blog

This site covers a range of ethical case studies – a must read for engineering in decision-making roles.

http://engineeringethicsblog.blogspot.com/

STANDARDS AND GUIDES

• 1. Standards concerning the Aerospace Industry

The Aerospace Research Council provides standards in three categories:

• Aeronautics
• Modeling, Simulation and Testing, and
• Space Systems and Vehicles

The standards listed can be filtered by date.

• 1. ISO/IEC/IEEE 24765:2017, Systems and Software Engineering Vocabulary

ISO/IEC/IEEE 24765:2017 provides a common vocabulary applicable to all systems and software engineering work. It was prepared to collect and standardize terminology. ISO/IEC/IEEE 24765:2017 is intended to serve as a useful reference for those in the information technology field, and to encourage the use of systems and software engineering standards prepared by ISO and liaison organizations IEEE Computer Society and Project Management Institute. ISO/IEC/IEEE 24765:2017 includes references to the active source standards for definitions so that systems and software engineering concepts and requirements can be further explored. 522 pages.

Purchase this Standard

• 1. Earned Value Management Systems Update

Provided by

Paul Solomon, PMP

The following email was sent to DOD and the Biden-Harris DOD Transition Team. It is also applicable to civilian agencies, FAR, and OMB. It is recommended that you and your organization consider these issues and begin initial planning to migrate from EIA-748 to government-wide standards, policies, and guidelines for Program/Project Management (P/PM) that are “in accordance with standards accredited by the American National Standards Institute (ANSI).’’

To both the current DOD Administration and the Biden-Harris DOD Transition Team:

There is a material and grossly misleading error in DFARS 252.234-7001 and related DFARS clauses. The erroneous DFARS clauses refer to a document that is obsolete: “American National Standards Institute/Electronic Industries Alliance Standard 748, Earned Value Management Systems (ANSI/EIA-748) (current version at time of solicitation).”

The ANSI/EIA-748 standard was terminated in Jan. 2015, per the NDIA IPMD Earned Value Management Systems EIA-748-D Intent Guide. Per the Change History Log, EIA Version C “Changed all instances of ANSI/EIA-748 to EIA-748 and updated the copyright for the EVMS Standard on the first page to SAE International.”

The change in ownership of the standard is important for four reasons:

1. EIA-748 is not accredited by ANSI. Thus, its use will be nullified upon passage of the NDAA for FY2021. The House version, H. R. 6395, contains Section 1745-Requirements Relating to Program and Project Management (P/PM). It will revise the U.S. Code, Sec. 503(c)(1)(D), Standards for P/PM. The law, when passed, will require the Office of Management and Budget (OMB) to adopt government wide standards, policies, and guidelines for P/PM for executive agencies that are “in accordance with standards accredited by the American National Standards Institute (ANSI).’’
2. The DOD EVM System Integration Guide correctly states:

EVM is one of the DoD’s and industry’s most powerful program management tools. Government and industry program managers utilize EVM to assess cost, schedule, and technical progress on programs to support joint situational awareness and informed decision-making. To be effective, EVM practices and competencies must integrate into the program manager’s acquisition decision-making process. The data provided by the EVM System (EVMS) must be timely, accurate, reliable, and auditable. Industry must implement the EVMS in a disciplined manner consistent with the 32 Guidelines contained in the Electronic Industries Alliance Standard-748 EVMS (EIA-748), not ANSI/EIA-748.

3. As asserted in my letter to OMB Directory Russell Vought, dated Oct. 27, 2021:

GAO reported that Project Management Institute (PMI) documents for project management and EVM are approved by ANSI. In contrast, EIA- 748:

• Was approved by the Society of Automotive Engineers (SAE), not ANSI.

• Think about the SAE grade of your motor oil. Capital acquisitions that cost over $100 M should be governed by a higher standard. Taxpayers deserve a higher standard.

4. As argued in my white paper, DOD Acquisition Reform: EVMS-lite to Program/Project Management, Rev. 17, EIA-748 is not a Voluntary Consensus Standard.

It is requested that:

1. All pertinent DOD policies, instructions and guides, including DAU training and references, be amended to cite EIA-748 instead of ANSI/EIA-748.
2. DFARS be corrected to refer to EIA-748.
3. Planning be initiated to migrate DOD P/PM policy, instructions, guidance, and training, with regard to the use of EVM as a program management tool, from EIA-748 to the appropriate standards accredited by ANSI.

A DEFINITION TO CLOSE ON

• 1. Systems Engineering

1. Systems Engineering is an interdisciplinary, collaborative approach to the engineering of systems, of all types, that aims to capture stakeholder needs and objectives and to transform these into a holistic, life-cycle-balanced system solution that both satisfies the minimum requirements, and maximizes overall project and system effectiveness according to the values of the stakeholders.”

Source: PPI

1. “The art and science of creating effective systems, using whole system, whole life principles” OR “The art and science of creating optimal solution systems to complex issues and problems.”

Source: Derik Hitchins, Professor of Systems Engineering and Former president of INCOSE UK, 2007

1. “The systems engineering method recognizes that each system is an integrated whole even though composed of diverse, specialized structures and sub-functions. It further recognizes that any system has a number of objectives and that the balance between them may differ widely from system to system. The methods seek to optimize the overall system functions, according to the weighted objectives and to achieve maximum compatibility of its parts.”

Source: Harry H. Goode and Robert E. Machol, 1957

1. “Systems engineering is a robust approach to the design, creation, and operations of systems. In simple terms, the approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance of design trades, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the system meets (or met) the goals.”

Source: NASA Systems Engineering Handbook, 1995

1. “Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.

Source: INCOSE

CONFERENCES AND MEETINGS

The featured conference for this month is:

The INCOSE International Workshop

29 – 31 January 2020 (Virtual Event)

INCOSE’s International Workshop is the event of the year for systems engineers to contribute to the state of the art. Unlike INCOSE’s annual International Symposium and other conferences, there are no paper, panel or tutorial presentations. Instead, attendees spend 3 days working alongside fellow systems engineers who are there to make a difference. Systems Engineers at all levels and from all backgrounds are encouraged to engage in working sessions, and contribute their knowledge and experience to take the discipline forward.

There are two kinds of working group sessions at the IW:

• Working sessions, where the focus is on improving and completing working group products. Working sessions are ideal for contributing with and learning from the real experts in the field. Attendees planning to attend Working sessions are encouraged to contact the relevant session leaders before the event to facilitate planning.
• Outreach sessions, where the focus is on disseminating the current state of the art to Workshop attendees with no or little previous exposure to the working groups. Attending an Outreach session is also the ideal opportunity to influence the future direction of a working group and perhaps the entry point for deeper working group involvement.

This will be INCOSE’s first virtual International Workshop following the success of the virtual International Symposium and subsequent virtual chapter meetings.

Register and find out more here

CONFERENCES AND MEETINGS

• 1. PPI Reaches 50 Live-Online Courses This Year

With the huge changes that have occurred in the world because of the COVID 19 pandemic, PPI, like every other enterprise, has had to adjust greatly. PPI (and CTI) went from conducting in-person training and consulting until February 2020, to virtual delivery of training and consulting services since. In March it became clear that the world was changing dramatically, and the only way to continue was to become completely adept in conducting almost every aspect of our business by remote working. This was a huge shift for us. Thanks to a combination of tremendous team effort and resilience, including outstanding IT leadership by CIO Kevin Blazé, we emerge from 2020 with accolades from clients for the value they are getting from our outstanding virtual consulting and training services deliveries. In early December, we reached our goal of 50 live-online courses for the year. We are grateful to you, our clients, who put your faith in us. We promise to continue to deliver training to the same high standard you have come to expect, and more.

• 1. PPI Welcomes Maika Back to the Team

Maika Machado headed PPI’s Brazil office in Sao José dos Campos from 2004 to 2009, before returning to full time study. Now Maika, under her married name of Maika Bergmann, has returned to the PPI family in a role supporting the PPI/CTI leadership team. Maika holds a Bachelor’s degree in Tourism Administration, a Post-Graduate Degree in Business Management and a MBA in Marketing. Maika is based in Schaffhausen, Switzerland, close to Zurich.

• 1. A Record Week For PPI

PPI/CTI achieved a record-breaking delivery of six courses at once in various delivery locations around the world during the week of 7 December 2020. Well done to the team!

PPI & CTI EVENTS

https://www.ppi-int.com/ppi-live-online/

For a full public PPI training course schedule, please visit https://www.ppi-int.com/course-schedule/

To enquire about PPI Live-Online™ training for your organization, please visit https://www.ppi-int.com/corporate-training/

For a full public CTI Live-Online™ INCOSE SEP Exam Preparation course schedule, please visit https://certificationtraining-int.com/incose-sep-exam-prep-course/

To enquire about CTI Live-Online™ INCOSE SEP Exam Preparation Training for your organization, please visit https://certificationtraining-int.com/on-site-training/

UPCOMING PPI PARTICIPATION IN PROFESSIONAL CONFERENCES

PPI will be participating in the following upcoming events. We support many events, and look forward to meeting old friends and making new friends at the events at which we will be exhibiting.

The INCOSE International Workshop 2021

Date: 29 – 31 January 2021

Location: Virtual

The INCOSE International Conference 2021

Date: 17 – 22 July 2021

Location: Honolulu, USA

Kind regards from the PPI SyEN team:

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

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

René King, Managing Editor, email: rking@ppi-int.com

Project Performance International

2 Parkgate Drive, Ringwood, Vic 3134 Australia

Tel: +61 3 9876 7345

Tel Brasil: +55 12 9 9780 3490 (BrenoBacci)

Tel UK: +44 20 3608 6754

Tel USA: +1 888 772 5174

Tel China: +86 188 5117 2867 (Victoria Huang)

Web: www.ppi-int.com

Email: contact@ppi-int.com

Copyright 2012-2020 Project Performance (Australia) Pty Ltd, trading as
Project Performance International

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

1. See Eric Rebentisch et al, Integrating Program Management and Systems Engineering: Methods, Tools, and Organizational Systems for Improving Performance. Wiley, The Project Management Institute (PMI), The International Council on Systems Engineering (INCOSE), and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts Institute of Technology (MIT) (USA). Hoboken, New Jersey, 2017. This important book provides new research indicating that the mindsets of program and project managers and systems engineers are crucial. It also provides case studies of successful complex programs, including the F/A-18E/F Super Hornet Program, the International Space Station, and the Electronic Support Upgrade for the Royal Australian Navy’s Anzac Class Frigate, including identification of a set of integration factors and an Integration Framework (see page 141). ↑