IN THIS EDITION
1. Quotations to Open On
2. Feature Articles
2.1 Engineers in the Time of COVID-19 by Dr. Cecilia Haskins
2.2 Project Partnering and Systems Engineering by Charles D. Markert
3. Notable Papers, Webinars and Presentations
3.1 INCOSE Webinar: Human Systems Integration: From Virtual to Tangible
3.2 Presentation concerning Living and Working in Space: Lessons for the Systems Engineer
4. Systems Engineering News
4.1 Results of the SERC | INCOSE NDIA | MBSE Maturity Survey Are In
4.2 The Consortium for Information & Software Quality™ is Leading an Initiative to Develop Quality Measures for MBSE Specification
4.3 INCOSE Foundation Releases Five Year Report
4.4 Google Engineers ‘Mutate’ AI to Make It Evolve Systems Faster Than We Can Code Them
4.5 Closing the Engineering Skills Gap with Generative Design
4.6 INCOSE is Looking for an Assistant Director for Membership
4.7 Register as a Chartered Engineer with INCOSE UK
5. Featured Organizations
5.1 Object Management Group (OMG)
5.2 Consortium for Information & Software Quality™ (CISQ™)
5.3 New England (USA) Complex Systems Institute
5.4 Institute for Systems Engineering Research
6. News on Software Tools Supporting Systems Engineering
6.1 Siemens introduces workplace distancing solution to manage “next normal” manufacturing
6.2 Article: 13 Python Data Science and Machine Learning Libraries You Need to Know
6.3 Enterprise Architect v15.2 (Build 1551) BETA Released on 26 May 2020
7. Systems Engineering Publications
7.1 When Systems Engineering Fails – Toward Complex Systems Engineering
7.2 Complex Engineered Systems: Science Meets Technology (Understanding Complex Systems)
7.3 Exploring Engineering: An Introduction to Engineering and Design (5th Ed.)
7.5 GigaBit Magazine
7.6 Systems Engineering Body of Knowledge (SEBoK)
7.7 Institute of Industrial & Systems Engineers (IISE) Body of Knowledge
8. Education and Academia
8.1 Alejandro Salado Named 2020 Scholarship of Teaching and Learning Award Winner
8.2 Master of Engineering in Systems Engineering, Stevens Institute of Technology, USA
8.3 M.S. & PhD in Industrial and Systems Engineering at Mississippi State University, USA
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
10.1 IEEE P3141™ Standard for 3D Body Processing Being Developed
10.2 The Beginner’s Guide to Quality Management Systems
11. Some Definitions to Close On
11.1 Quality Management System
11.2 Quality Assurance and Quality Control
11.3 Machine Learning
12. Conferences and Meetings
12.1 The Featured Conference is: Virtual INCOSE IS, July 20th – 22nd 2020
12.2 Another Noteworthy Conference: The International Conference on Complex Systems (ICCS),
July 27 – 31st 2020
13. PPI and CTI News
14. PPI and CTI Events
15. Upcoming PPI Participation in Professional Conferences
“The only sensible answer to the question “what’s more important, attribute X or attribute Y” is “ask me a sensible question and I will answer you”. Weights are only meaningful with reference to explicit ranges of improvement (value A to value B).”
“Prediction is very difficult, especially if it is about the future.”
Niels Bohr, Nobel Prize-Physics 1922
“If I have seen further than others, it has been by standing on the shoulders of giants.”
Sir Isaac Newton
2.1 Engineers in the Time of COVID-19
Norwegian University of Science and Technology, University of Southeastern Norway
May 2, 2020
http://www.linkedin.com/in/ceciliahaskins
Abstract
I have taken out my crystal ball and delved into dusty literature on my bookshelves to peer forward and look backward into questions about the engineering workplace.
Copyright © 2020 by Cecilia Haskins. All rights reserved.
Introduction
I am sure, as I sit in my home office and contemplate the current world situation under the COVID-19 pandemic, that I am formulating the same questions as many readers. In writing this article, I do not presume to ‘answer’ these questions, but rather to accumulate relevant background to initiate a dialogue and research agenda toward investigating possible futures. A sampling of my questions follows:
- How does the bias implicit in the terms social versus physical distancing influence personal (dis)comfort with the concept of lockdown?
- As we maintain enforced distance, are we improving our connections?
- Have the pandemic emergency measures helped jump-start a path that organizations can follow to reverse unsustainable behaviors?
- How shall the work of engineers, and systems engineers in particular, be affected by changes introduced in the post-pandemic work environment?
Background
The word engineer is derived from the Latin words ingeniare (“to create, generate, contrive, devise”) and ingenium (“cleverness”). As practitioners we are professionals who invent, design, analyze, build and test machines, complex systems, structures, gadgets and materials to fulfill functional objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost. We also address society’s needs and problems on so many other levels as well (Wikipedia).
I began my inquiry by examining the range of activities performed by engineers. With a starting point in Sheard’s 1996 classic on the 12 roles of systems engineers, Table 1, below, summarizes a brief literature review on the topic. Newman (1999) describes the issues related to the partitioning and sharing of these roles. Sheard (1996) suggests that organizations define activities to achieve cohesion and low communication exchanges between task definitions, but cannot avoid the fact that significant interactions still occur. The need for open, honest communication is articulated frequently, but seldom as eloquently as in Dasher (2003). Hutchinson et al. (2017) revisited Sheard’s paper and described roles that focus on the teams that build systems as, “… an intensely social discipline.” The range of these communications is further elaborated in Hutchinson et al. (2018).
Table 1: Overview of Engineering Roles
| Role | Description | Author |
| Requirements manager | The formality of the process may vary significantly with project size, degree of customer-imposed formality, and company culture. | Sheard 1996, INCOSE 2015 |
| System designer | Creates the high-level system architecture and design and selects major components. Close coordination with RM | Sheard 1996, RSL 2009, INCOSE 2015 |
| System analyst | Confirm that the designed system will meet requirements, model the system. | Sheard 1996, INCOSE 2015 |
| V&V engineer | Plan and implement the system verification program to ensure the system meets the specified requirements. | Sheard 1996, INCOSE 2015 |
| Systems integrator |
Proactive troubleshooter, looking for problems and arranging to prevent them based on wide experience and domain knowledge. May represent the ‘voice of the customer’ in negotiations. | Sheard 1996,
RSL 2009, INCOSE 2015 |
| Technical manager |
Includes controlling cost, scheduling resources, and maintaining support groups. | Sheard 1996, Dasher 2003, INCOSE 2015 |
| Information manager |
Big-picture overview, including configuration management, data management, process asset management, and metrics | Sheard 1996, INCOSE 2015 |
| Process engineering |
Document, follow, own, and improve the project’s and the organization’s processes. Background may include additional training in Lean and Six Sigma methodologies. | Sheard 1996, Dasher 2003,
RSL 2009, Hernandez and Mustapha 2010, INCOSE 2015 |
A quick survey of the system engineer’s activities quickly reveals the high degree of negotiation and team collaboration that is required to execute a successful project. The geographic dispersion of project teams since the 1970’s has already inspired new and increasingly sophisticated groupware solutions, but these have never completely replaced face-to-face meetings or co-location. Cockburn (2003) explored the significance of communication distance as it is related to project complexity and the need for formal methodologies. He suggests that complex projects require more formality in the methodology used and more robust and effective communications, whereas a simple, well understood problem can tolerate less formality in both processes and communications. This conclusion is supported by research conducted in a joint study by PMI, MIT, and INCOSE. One case study reported that “Shared objectives across the entire government-contractor team were facilitated by the alignment in organizational structures and daily communication, as well as the existence of program-wide technical and management databases for effective information sharing.” (Rebentisch, 2017:77)
Ryschkewitsch et al. (RSL, 2009) recommend that organizations identify and develop ‘complete’ systems engineers who are highly competent in both technical leadership and systems management, who embody the art and science of systems engineering. These engineers possess a strong ability to learn new things, are comfortable with uncertainty, and are excellent two-way communicators. They profile the last characteristic as a willingness “to get out of the office and meet with others.”
Hernandez and Mustapha (2010) of the Mayo clinic laboratories assert that systems engineers are invaluable partners in redesigning health care systems to make them more efficient, effective, safer, and more cost-effective. This often means that the systems engineer tends to be more hands-on with the actual implementation of a project and s/he is invited to intervene to mentor and recommend approaches for resolving issues. After all, the ultimate goal of the systems engineer in process reengineering is to transfer knowledge and experience to frontline staff who will eventually perform the continuous improvement projects unaided.
The Engineering Workplace
Just as engineers employ the most suitable tool for any job, so must their workplace contain and reflect the tools of their trade. As the number of industrial revolutions keeps mounting, the sophistication of both the systems created and the tools required to create them has kept pace. Increases in system and product complexity are bounded only by the talent and imaginations of the engineers who make them.
Nearly since the advent of computers, the option to work at a distance from the physical location of the ‘factory’ has spurred both innovation and criticism. Earliest forms of ‘work-from-home’ (WFH) were known as telecommuting. Software engineers were among the first to work in this way, and many advancements, such as the internet and improved communication bandwidth, made this mode of working possible (Gilder 2000). Early pundits coined catch phrases such as ‘High Tech – High Touch’ to illustrate benefits from this way of working (Heffring et al. 1986). But, as recent lockdown reports have shown, the work-life balance can be upset by our perceptions of what it means to accomplish work, and when everyone stays home (Hislop and Axtell 2007, Bacharach et al. 1991).
I wish to share observations from two of my colleagues about the way the Norwegian lockdown has influenced the way they worked in March and April. The first colleague was exploring the introduction and use of MBSE into his organization and was amazed at the relative ease of assimilation.
In the beginning, most of my co-workers were furloughed, but that allowed me time to really work out the technical aspects of the tool in advance, and focus more on the process rather than the tool once we got started. I actually prefer using remote meetings because it made meetings more focused and disciplined. But, now that people are back, we have started doing more work on site, which does seem more conducive to creative problem solving. In the future, I’m thinking maybe in-person sessions for initial brainstorming, followed by frequent and shorter, more focused remote reviews, and less frequent end-of-iteration in-person sessions with prototypes.
A second colleague is working on a large project involving classified material, and has offered this observation.
Our experience in the … project is that working solely by video conferencing during a communication-intensive phase of the project is significantly slowing down the progress, and the need for face to face communication, especially during negotiations, is clearly evident. We see this because there has not been any option to meet physically for the past 2 months. One thing is the communication, the other aspect is sharing repositories and making them available online in suitable media. For sensitive / classified information, this is a major challenge. This is an area that would benefit from better tools in the future.
Based on feedback from practitioners concerning their working situations during the pandemic lockdown, it seems that enforced distance detracts from personal connections; that measures taken during the COVID-19 emergency appear to have jump-started more effective development approaches; and that the work of systems engineers seems to have improved through selective use of online meetings.
Revisiting the Questions
On one hand, lockdown has kept many of us out of our physical offices and away from collegial social interactions around the coffee machine. On the other hand, we have quickly gained proficiency in a whole range of established and newly popular communications channels such as Skype and Zoom. On a personal level, despite my frequent professional use of these media before the pandemic, it was only recently that I began using them to have contact with family and friends, and that has given me a sensation of being more highly connected to all of them. The optimistic view is that computers and telecommunications can create a society – but will we join together to achieve something more meaningful than appreciative clapping or sing-alongs?
News reports of cleaner rivers, unpolluted city skies, and changing patterns of consumption offer hopeful glimpses of the possibility of rectifying unsustainable behaviors on the part of engineers. An example of this is the proposed ‘virtual’ INCOSE symposium for our 30th anniversary, and a whole range of other conferences that have avoided postponement or cancellation in favor of online events. On a less positive note, thousands of summer jobs for engineering interns have been sacrificed at the altar of economic expediency, which does not bode well for the future of this profession.
As for ways our jobs as engineers may begin to change, initiatives within INCOSE are studying the use of MBSE and suggest that our organizations invest more resources into implementations that maintain and enhance our processes and communications using new technologies and updated methodologies. These investments need to be factored into a wider strategic perspective (Venkatraman, 1999) because all work arrangements, including the present WFH situation, have associated costs and benefits (Pyöriä 2009).
Educators have a responsibility to monitor societal and organizational changes and adjust the way they prepare their students to enter the workplace. Practitioners working toward creating effective work environments are advised to heed the advice of Sheard, Lykins, and Armstrong (2000) and other sources provided in the References section, below. Research organizations, such as the Systems Engineering Research Consortium (SERC), may need to revisit earlier findings and new opportunities for and funding needed to enhance and hasten the digital transformation of society.
Postscript – the SERC has since writing this generated a survey. I look forward to reading their results.
List of Acronyms Used in this Paper
Acronym Explanation
INCOSE International Council on Systems Engineering
IS INCOSE Annual International Symposium
IW INCOSE Annual International Workshop
MBSE Model Based Systems Engineering
RSL Ryschkewitsch, Schaible, and Larson (see the References section)
SERC Systems Engineering Research Consortium
Acknowledgements
My thanks to two anonymous sources who shared their personal experiences of the pandemic lockdown in Norway.
References
Bacharach, S. B., Bamberger, P., & Conley, S. (1991). Work‐home conflict among nurses and engineers: Mediating the impact of role stress on burnout and satisfaction at work. Journal of organizational Behavior, 12(1), 39-53.
Cockburn, A. (2003). People and methodologies in software development. Oslo Norway: Faculty of Mathematics and Natural Sciences.
Conforto et al. (2013). Improving the Integration of Program Management and Systems Engineering. Whitepaper presented at the 23rd INCOSE Annual International Symposium, Philadelphia, USA, June 2013.
Dasher, G. T. (2003). The interface between systems engineering and program management. Engineering Management Journal, 15(3), 11-14.
Gilder, G. (2000). Telecosm: How infinite bandwidth will revolutionize our world. Simon and Schuster.
Heffring, M. P., Neilsen, E. J., Szklarz, M. J., and Dobson, G. S. (1986). High tech, high touch: common denominators in patient satisfaction. Hospital & health services administration, 31(2), 81-93.
Hernandez, J. S., & Mustapha, M. (2010). Systems engineers working with physician leaders. Physician executive, 36(6), 44.
Hislop, D., & Axtell, C. (2007). The neglect of spatial mobility in contemporary studies of work: the case of telework. New Technology, Work and Employment, 22(1), 34-51.
Hutchison, N., Henry, D., and Pyster, A. (2016). Atlas: understanding what makes systems engineers effective in the US defense community. Systems Engineering, 19(6), 510-521.
Hutchison, N., Wade, J., & Luna, S. (2017, July). The Roles of Systems Engineers Revisited. In INCOSE International Symposium (Vol. 27, No. 1, pp. 200-213).
Hutchinson, N. A., Verma, D., Burke, P., Clifford, M., Giffin, R., Luna, S., & Partacz, M. (2018). Atlas 1.1: An Update to the Theory of Effective Systems Engineers (No. SERC-2018-TR-101-A). Stevens Institute of Technology Hoboken United States.
INCOSE (2015). Walden, D. D., Roedler, G. J., Forsberg, K., Hamelin, R. D., & Shortell, T. M. Systems Engineering Handbook: A guide for system life cycle processes and activities. John Wiley & Sons.
Newman, R. A. (1999). Issues in defining human roles and interactions in systems. Systems Engineering: The Journal of The International Council on Systems Engineering, 2(3), 143-155.
Pyöriä, P. (2009). Virtual collaboration in knowledge work: From vision to reality. Team Performance Management: An International Journal.
Rebentisch, E. (2017). UNLOCK THE POWER: Integrated Program Teams Deliver Value. INSIGHT, 20(3), 77-77.
RSL (2009). Ryschkewitsch, M., Schaible, D., & Larson, W. The art and science of systems engineering. In Systems Research Forum (Vol. 3, No. 02, pp. 81-100). World Scientific Publishing Company.
Sheard, S. A. (1996, July). Twelve systems engineering roles. In Proceedings of INCOSE International Symposium (Vol. 6, No. 1, pp. 478-485).
Sheard, S. A., Lykins, H., and Armstrong, J. R. (2000). Overcoming barriers to systems engineering process improvement. Systems Engineering, 3(2), 59-67.
Venkatraman, N., Tanriverdi, H., Stokke, P., Davenport, T., Sproull, L., & Storck, J. (1999). Is it working? Working from home at Statoil, Norway. European Management Journal, 17(5), 513-528.
Wikipedia (downloaded 2020-05-14). https://en.wikipedia.org/wiki/Engineer
About the Author
Cecilia Haskins entered academia after more than thirty years in industry. Her career spans large and small firms, commercial and government projects. Her educational background includes a BSc in Chemistry from Chestnut Hill College, and an MBA from Wharton, University of Pennsylvania. She has been recognized as a Certified Systems Engineering Professional since 2004 and earned her PhD from NTNU, Norway. Currently she is an Associate Professor in Systems Engineering where she conducts research on innovative applications of systems engineering to socio-technical problems such as those encountered in sustainable development and global production systems.
2.2 Project Partnering and Systems Engineering
by
May 5, 2020
Abstract
Partnering is a management process that helps people to work together better and achieve project success. In its essence, partnering is teambuilding. This article covers the “WHAT?”, “SO WHAT?”, and “NOW WHAT?” of project partnering. The concept of partnering is one of working in support of one another to achieve desired outcomes that are beneficial to all parties involved. It is a systematic approach wherein all parties to a contract come together and help each other succeed. Whereas the contract terms spell out what is to be done, when it is to be completed, for how much money, and with what level of quality, it does not delineate how to behave, cooperate, or collaborate. Partnering does this in a structured team-based approach to avoid disputes and litigation and to solve problems creatively, quickly, and effectively. It is all about People. This is a process that enables people to work together with a common purpose, thoughtful alignment, and personal collaboration to achieve the best outcomes. This is a process you should use.
Partnering and Systems Engineering
You can mostly avoid machine failure with proper preventative maintenance and attention. Is there any way to avoid human failure within a system with some sort of preventive maintenance and attention? Like regular oil and grease? Perhaps essential oils and delicious bacon grease? Maybe, but not likely.
What causes failure in a well-engineered, smoothly operating system? Little things like friction, elasticity, electrical surges, bugs, magnetic fields, corrosion, variation, and many other outside forces. Add humans to that long list of problems and you have a much higher risk of failure. Human nature disruptions come in many flavors. They include ego, attitude, boredom, anger, fear, maliciousness, envy, fear of missing out, financial need, bad habits, lack of knowledge skills and abilities, illnesses, etc. etc. Sounds daunting doesn’t it? Well, that’s why you participate in ‘Continuing Education’ so you learn how to deal with as much of this stuff as possible. Partnering is but one of those many tools available for dealing with the human elements.
W. Edwards Deming says it best when he states “People come to work not intending to do a bad job, rather the system causes them to do a bad job.” That is but part of the highly variable dimension of the human dilemma. I submit that partnering, a process designed initially for teambuilding on large construction projects, is one of the ways to empower people to do a good job. It seeks to better align the aim of the project with the aim of the workforce.
The “WHAT?” ……The purpose of partnering?
The aim or purpose of project partnering is to provide future and current leaders, executives, managers, and supervisors with tools to lead and to empower their employees and counterparts to work better in team and individual settings to consistently achieve an organization’s desired outcomes.
Partnering also seeks to provide a more functional environment for all participants to more effectively identify problems, collaborating on the solving of those problems, and to keep a Project moving forward effectively and successfully.
With a fundamental, systematic and understandable a mix of teambuilding, visioning, planning, collaborating, cooperating, and problem solving, the partnering framework includes the following concepts:
- Partnering is done among the parties to a contract to eliminate the “we/they” syndrome.
- A shared vision is developed through collaboration and consensus to help all to own the outcome.
- Guiding principles are developed and agreed-upon, and promises are made to ensure cooperation.
- Common goals are identified to help keep focus.
- Group dynamics are better understood to appreciate and engender patience.
- Strategies for this shared effort are discovered and deployed to educate and engage the team.
- Partnering is integrated with project management to ensure partnering survives.
- Problem-solving processes are instituted and used to find the best solution (which may not be the first solution).
- Issue resolution hierarchy and rules are established and agreed upon to avoid conflict.
- Evaluations and feedback are made part of the project to learn from experience and allow easy detection of issues.
- Partnering between the involved organizations is voluntary to avoid contractual disputes.
- Partnering is the alignment of people’s energy with the project’s desired outcomes to better ensure success.
Elements of Partnering
The illustration below, Figure 1, places these elements in context with the model of “learn – think – act”. I also like using the framework of “What?, So What?, Now What?”. This simply shows we first need to understand what’s going on, then we need to understand why something is happening and why we must do this, and then we need to do this and be accountable. Simple right? Well, this is virtually always left up to chance. We usually assume that management understands everyone’s needs and expectations, and that employees will understand what management is thinking, and that things will all work out in the end through the application of common sense. I would point out that there is nothing common about common sense, which itself is a scarce commodity when pitted against reality. Murphy’s Law states, “If it can go wrong, it will”. Therefore, a process that is reasonable, workable and successful is a welcome addition to any large project, whether it is construction, a complex systems engineering project, or any other endeavor with and among parties to a contract.
Figure 1: The Essence of Partnering
Link to Deming
I see another linkage of project partnering with W. Edwards Deming in his “System of Profound Knowledge” as described by Peter Scholtes in his paper “Profound Knowledge, Profound Trouble, Profound Problems”. His diagram, shown as Figure 2 below, represents such a system. Scholtes says: “This is Doctor Deming’s final contribution to our pursuit of wisdom. He identifies 4 interdependent disciplines needed to lead and develop organizations and approach the issues which challenge us.”
Figure 2: System of Profound Knowledge
Scholtes says that these 4 disciplines comprise a system wherein each affects the others and all of them interact with the organization’s other systems, including planning, problem-solving and decision-making. All of which pertains to project partnering. We in the technical world are woefully remiss in providing sufficient attention and gaining adequate understanding of that quadrant of the system dealing with human behavior. Looking back on life as an employee versus my life as a manager/executive, it seems so much easier when dealing with an inanimate problem than it did dealing with human beings. I have since become a believer in helping people improve their business interactions. Partnering has been my primary tool in helping that happen.
Our Approach
The approach to the partnering process is shown in Figure 3 below. Many of the above elements are integrated into this process as well as others.
Figure 3: Our Partnering Approach
It is helpful to remember that none of these elements are spelled out in the contract, yet they all contribute to our very human behavior, and by extension, to the success of the project.
Systems engineering and the human element
As in any system, the human element is one of the biggest unforeseen conditions, especially in major engineering projects. Behaviors are important. The terms and conditions of the contract do not spell-out how you are to behave toward one another. Partnering does it in a way that all can agree on how to treat one another as well as how to solve the inevitable problems. It ultimately comes to rest on personal relationships, human nature, understanding roles, and the alignment of expectations. Systems and processes are the’ Road’ on which people travel during a project.
People-centric team values of project partnering include giving everyone the chance to participate and to develop a mutually agreed-upon set of best practices/behaviors that include communication, cooperation, collaboration, all in a setting of trust and goodwill. As long as this survives, partnering will survive on any specific project.
Consensus
The facilitator needs to use some tools to ascertain consensus and not simply accept the head nod of a few people as agreement by the whole room. I use what I call a comfort check. When we have a statement or set of statements that we want everyone to agree on, I ask the question, how comfortable are you on a scale of 1 to 5 with this statement or set of statements? 1 means I hate it, 5 means I love it, and 3 means I can live with it and support it. I ask for a simple show of hands and ask how many fives, then how many fours, etc. My definition of consensus is when everyone votes 3 or above. If anyone votes one or two, I proceed to ask them what would need them to change their vote to a 3? Then a discussion ensues until everyone is at a 3 or higher. That is consensus.
True Teamwork
Partnering teamwork includes collaboration between people for their normal work plus a willingness to help each other find more possibilities and better ideas that benefit all concerned. It also includes communications to avoid misunderstanding in order to ascertain the facts, emotions, meaning, and actions needed for the issue at hand.
Fact or Fiction
Another crucial element is transparency or daylight. That is, clarity of facts which are either actual truth, personal opinions or simply guesses as well as having a willingness to share them in proper context.
Motivation
Partnering is an effort to draw out ‘the best’ in people in order to achieve a successful project outcome for all parties involved. Achieving ‘the best’ forces one to depend on other people. Brute force works for pile-driving but not motivating people to perform as desired, let alone occasionally performing ‘above and beyond’.
Valuable and usable wisdom is something that can be discovered by awareness and assessment when shared in a transparent way. This is only done when trust has been built by everyone being trustworthy.
With all of this coming together and providing more situational awareness, the results are better information and thereby better decisions being made. Remember, the source of many a problem is a solution. Ponder that.
The “WHAT”?… Systems thinking and the Genesis of Partnering
Well, what do we do when we have a multitude of moving parts that hopefully work together in a complex environment to achieve a desired outcome? We build the system. We formulate processes that take manpower and material and create services and products.
For many years before project partnering came along, and as with those today who do not consider partnering as necessary, systems were created that include the detection and correction of problems by mechanical or human intervention. There is generally no room for human attitudes, ignorance, and avarice which are generally dealt with through threatened punishment as the preferred and available consequences. This has been erroneously assumed to elicit extra personal effort and cause better alignment of effort and desired outcomes.
The typical motivational approach usually causes a person to do “just enough” to stay out of the range of the “whip”. In a world where plans, specifications, and statements of work are not spelled out in complete detail, there is often a need for people to read between the lines and produce some creativity through extra effort in order to get it done better. Or they could do “just enough”.
Genesis
Well, as it turns out, some wise people in the United States Army Corps of Engineers (USACE) and one of their larger construction corporations had an idea of a systematic way to build a better team than one which hopefully comes together by happenstance. Success depends on the inherent wisdom and willingness of the people on a project. They created a process they called a partnering model. See Figure 4 to understand the propagation of best practices in teamwork and project management.
Figure 4: Partnering Model
Voluntary Partnering
It is not a partnership in the legal sense of the word, nor is it simply the alignment of two organizations coming together. It had to be voluntary so as not to disrupt or change the terms and conditions of the contract previously agreed upon. It was clear that the mechanism had to be behavioral change in a collaborative way within a typically uncollaborative environment.
The “SO WHAT?”… Or why should I Care?
A construction contract clearly spells out what is to be done, when it must be done, which materials and subsystems are to be used, the quality that is to be assured, and the price that is to be paid. Nowhere in the specifications, whether project plans or the terms and conditions, is it spelled out how we must behave toward one another. This is true of most every system.
This systemic effort began in the late 1980s and that Partnering Process survives largely unchanged today. It is however not applicable everywhere. It appears to be best suited for situations where independent entities need to work together that are prohibited from dishing out rewards to their favorites and delivering financial punishment for nonperformance. That describes federal, state, and local governments and their contractors. In the rest of the world, the owner can coerce the contractor under threat of being precluded from future work, or being promised future work. When private funds are involved, there is nothing illegal with that approach. It just does not work when public funds are being used for the project.
What is the problem?
There exists, and has always existed, a typical mindset. Historically there has been significant litigation fueled by the adversarial nature of contract enforcement and the legal industry. The owner enforced the terms and conditions of the contract in a manner to ensure they received, at least, what the contractor promised to deliver. The owner assumed the contractor was dishonest and always cutting corners to get out of delivering what was promised. There were (and still are) some of those less than scrupulous contractors just as there are some owners who do what they can to squeeze more out of the contractor. This assumes the worst and encourages defensive documentation in preparation for the inevitable future litigation.
Figure 5: Cost of Issue Resolution beyond the Team Influence
That leaves the only source of recourse when public funds are involved, to be the court system. The motivation is typically for the contractor to bid low and make money on change orders where they see deficiencies in the plans and specifications for the project. While this is not always the case, it happens frequently enough that some contractors have learned how to manipulate the system for their maximum benefit. Figure 5 illustrates how disputes evolve into a more expensive resolution as time goes by and the decision-maker is further and further away from the field where the decision should have been made in the first place.
On the other hand, government entities rely on detailed inspections, ironclad specifications, and error-free plans and product sheets. The government also relies on the people in this system to be smart enough, tenacious enough, and observant enough to catch any shortcuts being made. The success of this system depends largely on people.
THEN WHAT? The Real World…
So, in reality we have people in the contractor side trying to get all they can out of the government and people in the government trying to get all they can out of the contractor as their motivations. What can go wrong with that? Well, some of it is entirely justified and such a system attempts to keep everyone as honest brokers. It just so happens that a portion of the change order requests are not justified and they result in claims where conflict resolution becomes expensive lawsuits.
This portion, perhaps in the range of 5%, turns out to be a big number when the multiplier is in the billions of dollars. So, partnering was created in order to reduce this resulting litigation between the parties to these large contracts. The thinking was that if we could get a team of people from top to bottom of all parties to the contract together it would help. They created a team approach of being willing to help one another succeed on any given project that would hopefully result in lower litigation costs.
Proof of Concept and Ultimate Acceptance
The US Army Corps of Engineers (USACE) began this new concept of partnering, (See Figure 4) on the construction of a huge navigation lock on the Mississippi River and saw excellent results. That project finished on time, under budget and with no claims. USACE then adopted it for all their larger projects and continued to show tremendous reduction in litigation over the next several years.
Shortly after the Corps of Engineers started this process, the Naval Facilities Engineering Command (NAVFAC) began using it with similar success. Since then many other agencies in the federal government, as well as state highway departments across the nation, universities, hospitals, public schools, jails, and all sorts of other projects have used the partnering process with success.
Of interest is the reluctance of schools and universities that teach project management to adopt and institutionalize partnering as part of ongoing project management practice. Some have said that the elements of partnering are already built into project management. That’s like saying the elements of quality improvement are built into normal management. That appears to be not so, if only proven empirically by the results of USACE.
Partnering was adopted by the Associated General Contractors of America (AGC) and codified for their members. The process they adopted was specifically that created by USACE and their contractor. AGC’s documents, videos and publications are used as the basis for many professional partnering facilitators to use for the design and facilitation of partnering workshops. Their seminal book on the subject is called Partnering: Changing Attitudes in Construction, published in 1995 and still completely valid today.
“It’s easy to get players! Getting them to play together… That’s the hard part!”
– Yogi Berra
Partnering Defined
It is crucial that we all have the same definition of partnering. Partnering, when done properly, causes people in the participating organizations to look out for everyone’s best interest and be happy to do it. They insist on working together, happily creating better solutions to the inevitable problems. ‘Management Best Practices’ actually work when they are launched in a culture where communications flow easily. Partnering is the framework within which tools, techniques, processes, and philosophy enable this to occur. The extent to which it occurs is up to the leadership. How long it lasts is also up to the leadership.
A wide variety of definitions exist for Partnering. The basic definition of generic Partnering used here is from the Construction Industry Institute, In Search of Partnering Excellence, 1991, which states:
“Partnering is a long-term commitment between two or more organizations for the purpose of achieving specific business objectives by maximizing the effectiveness of each participant’s resources.”
Partnering is not a panacea, but it has proven to produce better results, more goodwill and fewer frustrations than happens when it is not used. More importantly, it virtually eliminates litigation and greatly improves the speed of solving problems, thereby preserving the contractor’s and owner’s bottom line.
The process is straight-forward while its execution requires the commitment of all parties. Many government agencies include partnering workshops in their project specifications wherein typically the cost is shared between the 2 parties. The government typically pays 50 percent and the contractor pays 50 percent and it is not built into the contract as a bid item. Others simply require the contract to pay the cost of the workshop room rental and facilitator fee while all parties pay their own travel.
Invitees include the government hierarchy related to that project from the person who signs a check and the chain of command down to the field inspectors. On the contractor side, it is from the project’s financial decision maker on down to the field superintendents. It often includes key people from the contractor’s subcontractors as well as the governments design organization.
All these people are shown on an “organization chart” (Figure 6) for the project that depicts the chain of problem-solving approval from top to bottom with names and contact information of everyone. Additional instructions include the Five Rules of Issue Escalation for resolving an issue that cannot be solved at the level it was discovered.
Issue Escalation and Resolution
Resolving issues and solving problems before they become lawsuits is a fundamental tenet of partnering. It is important to know who the players are as well as those players need to see & agree how they fit into the process. A ladder is the mental model for this effort.
Figure 6: Escalation Ladder Framework
Those 5 Rules of Issue Escalation are:
1. Resolve Problems at the Lowest Level
2. If Necessary, Elevate Problems Quickly and Simultaneously
3. No Jumping Levels of Authority
4. Do Not Ignore the Problem
5. Make Only Decisions with Which You Are Comfortable, Elevate the Rest
The basic idea is that when a problem is discovered, it should be resolved at the level it was discovered by the cooperation of everybody at that level. If for any reason it can’t be solved at that level, it should be escalated simultaneously up both chains of decision-making to the next level. At each level a time-limit guideline is agreed upon to ensure quick and effective elevation of any issue to the next and so on. If it cannot be solved at the top run of the decision-making letter, it is expected to be resolved through mediation or litigation beyond the partnering team.
This initial partnering workshop is almost always the first opportunity that a project team has had to get together in the same room and spend some time putting a face with the name and getting to know one another to reduce the reluctance to reach out and solve the problem with your “opposite number”. This is where teambuilding happens. It is crucial to get to know one another beyond the speed dial button on your telephone.
The process generally includes some exercises in order to get to know one another better. In the technical industry people have generally a low tolerance for the “touchy – feely” exercises even though they are probably the ones that need it the most. (My personal observation as formerly being one of them). Therefore, the wise facilitator uses one or two exercises with a relatable reason for each and does not indulge in exercises for the sake of an exercise.
The Agenda
The agenda that I use for the initial partnering workshop to establish the team charter is shown below in figure 7. All of this can be done in one day with a professional facilitator and a team of 12 to 36 people in a conference room. Everyone agrees how important it is to make face-to-face personal contacts with other team members to build a sense of community that engenders cooperation and collaboration. The initial meeting, in today’s environment, can be done virtually with the right tools to brainstorm, and prioritize ideas and issues in real time. If a virtual meeting is used, I strongly urge the first follow-on partnering workshop to be face-to-face.
Figure 7: Initial Partnering Charter Workshop Agenda
What about the Charter?
Is it a Pledge of Allegiance? Yes, it sort of is. As mentioned earlier this is all voluntary and not contractually binding. Neither is the Pledge of Allegiance to America. This is simply a representation of the promises of these team members to one another regarding how they intend to behave on this project.
The Charter, Figure 8, is normally distributed and posted on the wall in whatever room the partnering team meets in their workspace. It merely memorializes what they agreed to and what they will address in each of their upcoming monthly, quarterly, or semiannual follow-up partnering workshops. The contents of the Charter are put into an evaluation form which is typically completed ahead of the follow-up meetings so that statistics can be compiled concerning how the team members think they are doing regarding each element. The idea is to celebrate the high-scoring items and figure out how to do better with the lowest scoring items.
Figure 8: Sample Partnering Charter with Signatures
The “Now What?
‘Just do it’. Because you have read this far in this article, you know more about project partnering then does most of the working population of this country. You now have an advantage. I encourage the use of this process because it produces results and causes enjoyment among team members. Figure 9 provides a sample of team photos of some of those who have done Partnering.
Figure 9: Typical Partnering Team Photo
As a professional facilitator, I have adapted and used this for contracts between government and large information technology (IT) contractors to develop teamwork between and within their organizations.
- Imagine, if you can, a world in which the players in your enterprise or your client’s enterprise are looking out for your best interest and are not only happy to do it, but insist on working together, happily creating better solutions to the inevitable problems.
- Imagine being immersed in a culture where communications flow easily and all the management ‘fads’ actually work.
- Imagine that you created and delivered an information technology (IT) system to your client on time, within budget that operates flawlessly to the relief and satisfaction of all concerned.
Imagine that you are not imagining this. There exists a tool, a methodology, a process, a subsystem, a philosophy that enables this to occur. The extent to which it works is up to you. How long it lasts is also up to you. I call it ‘Enterprise Partnering’ and it works well.
Enterprise Partnering
Curiously enough, the elements of Enterprise Partnering are neither new nor unique. The application of this formalized approach is in its infancy. Partnering in the construction industry has been widely adopted for federal and state construction projects. It has begun to be accepted in the information technology industry and in some others. It is touted as being practiced throughout the entire business sector, but is typically in the form of a “partnership” and not the project partnering process.
Enterprise Partnering is simply the confluence of the project partnering approach with the actual conduct of business between internal departments, divisions or branches. Enterprise Partnering tends to heal many ills that develop between these internal organizations.
The structure of this approach opens doors and promotes cooperation that might only have occurred through individual initiative in spite of the organization, not because of it.
You can unleash the vast untapped discretionary energy and potential of those who do the work, only by providing the opportunity for their self-motivation. The old adage that motivation is an inside job is true. All employees have the choice of doing just enough to get by or doing more than ever expected. Partnering unlocks this potential because there is something in it for them.
Use a Professional
I facilitate this process for my clients. However, even if I did not do this for a living, I would still suggest you use an independent third-party facilitator/consultant to conduct the major sessions on a regular basis. There is significant benefit from using a ‘professional’ facilitator. The facilitator can be internal to some other part of your organization or contracted for on retainer or other means. Without an independent facilitator, your meetings will be business as usual and may well be a BOPSAT (Bunch of People Sitting Around Talking). If the boss chooses to facilitate the workshops, the boss will get exactly what the team members think the boss wants to hear. It is only human nature.
The Launch
Enterprise Partnering works well at all levels of an organization from the boardroom to the branch, section or team level. An initial planning session of a few hours with the leadership team, including those who are tasked with championing the partnering process, is followed by a 1 to 3-day session (offsite) with the key players from all ‘sister’ organizations participating as appropriate.
The Partnering Team builds an agreement that they can sign and all commit to follow-up sessions. Real issues are then identified using surveys, card-storming and the ‘gets & gives’ approach. Teams are launched to deal with selected real or potential problems, a peer ladder is developed to resolve issues, and a feedback/assessment process is designed. The implementation plan is developed to include monthly or quarterly facilitated follow-up sessions. These sessions address both the progress on issues, problems, and goals as well as assessment of how well the Partnering Charter is being followed.
The process is complimented by whatever additional tools the facilitator can provide. The Leadership team and the facilitators tailor the sessions to focus on what is needed most by the team and the organization.
The best approach, and the one that is most attractive to managers, is for an organization to get its internal act together first with a few sessions and then to venture outward to conduct Partnering sessions with their primary stakeholders or customers. As an example, an Information Technology (IT) Department may do Partnering with the Operations Department or Procurement or Human Resources, all of whom can, and do, benefit from improved communications and better working relationships. Then do the same for your external stakeholders.
This is not a panacea but it has proven to produce better results, more goodwill and fewer frustrations than happens when it is not used. Just imagine your organization performing as well as all those management books say they could. Those books generally do not provide specific tools to use. You cannot build your home without the proper tool. Do yourself a favor and begin using the proper tools.
Summary and Conclusions
Partnering, when done properly, causes people in the participating organizations to look out for everyone’s best interest while insisting on working together, thus creating better solutions to the inevitable problems. Project Management’s best practices actually work when they are launched in a culture where trust exists and communications flow easily. It is the structured approach that enables it to be applied to any project. It also empowers the participants to cooperate as allies rather than the obligatory adversarial approach. While the main benefit is the virtual elimination of litigation, there are several intangible benefits. Participants have stated that they no longer dread coming to work on a project when the project is using partnering. I have been told by a project superintendent that his Maalox consumption has been reduced. Time is money to a contractor and with the project running smoother and problems solved faster, the contractor can finish on time (or better) and move on to the next project.
The Future of Partnering
A multitude of successes have proven Partnering works. Will it stay around? Will it be displaced by the next fad? Is this something of profound and lasting substance? The answer to all these questions is “yes”! This contradictory answer should make us think. Just how sustainable this version of Partnering is will depend on whether people actually choose to behave differently. There will always be a contractor that will cut every corner possible. There will always be an owner who will squeeze the maximum out of a contractor and not be concerned with who gets hurt or damaged. There will always be a designer who fears blame and higher Errors and Omissions insurance costs. The challenge is to turn this sometimes negative and adversarial approach into one of collaboration and teamwork.
Partnering has many roots in the philosophy and practice of quality improvement. It includes elements of strategic planning and systems thinking. Partnering is thus consistent with the quality-related teachings of many experts who regularly contribute to this body of knowledge, furthering our understanding and helping us to make improvements to our creativity, productivity and outcomes. Partnering give us the means to achieve higher levels of success for ourselves and our customers.
The Partnering process works in part because it provides a structured method. With Partnering we know where we are going, we all agree and we have a method to get to our goals faster, better and with less expense. This process provides a set of behaviors through which the contract is fulfilled. By creating a collaborative team-oriented environment, Partnering provides what the contract alone cannot provide: a striving for mutual success harnessed to the power of synergy that produces creative solutions and increased productivity.
List of Acronyms
BOPSAT Bunch of People Sitting Around Talking
FOMO Fear Of Missing Out
NAVFAC Naval Facilities Engineering Command
USACE United States Army Corps of Engineers
References
Carr, Frank, With Kim Hurtado, Charles Lancaster, Charles Markert, and Paul Tucker. “Partnering in Construction: A Practical Guide to Project Success”, American Bar Association, 1999, 281 pages. ISBN 1-57073-737-1.
The Associated General Contractors of America. “PARTNERING: Changing Attitudes in Construction” AGC Publication 1225, October 1995.
Construction Industry Institute, “In Search of Partnering Excellence”, Austin Texas, 1991.
Stephenson, Ralph J. “Project Partnering for the Design and Construction Industry”, John Wiley & Sons Inc., 1996, 441 pages, ISBN 0-471-10716-6.
Scholtes, Peter R. “The Leaders Handbook: A Guide to Inspiring Your People and Managing the Daily Workflow”, McGraw-Hill, 1998, ISBN 0-07-058028-6.1998.
Scholtes, Peter R. Profound Knowledge, Profound Trouble, Profound Problems, Deming Study Group paper, Scholtes Seminar & Consultng.1994.
About the Author
Charles Markert is an engineer, engineering & design manager, project manager, group process facilitator, author, consultant, trainer, speaker and entrepreneur.
As an engineer and professional facilitator, he has 30 years of public sector engineering management and civil engineering design experience involving all aspects of facility design, planning, engineering management, as well as organization leadership, process streamlining and quality improvement.
As a professional group process facilitator, he has 20+ years of facilitating process streamlining, business process redesign, process mapping, quality improvement strategic planning and construction project partnering. He has extensive experience in the partnering process. His full resume can be found on his website.
Education:
Contemporary Executive Program, GWU Graduate Program,
Master of Public Administration, American University
Master of Science, Ocean Engineering, University of Rhode Island
Bachelor of Science, Civil Engineering, Michigan State University
Registration:
Professional Engineer, Virginia (1974 to 2009)
Certified Professional Facilitator, International Association of Facilitators (2002 to 2014)
Certified Bottom Line Innovation Facilitator (1996-Present)
3. NOTABLE PAPERS, WEBINARS AND PRESENTATIONS
3.1 INCOSE Webinar: Human Systems Integration: From Virtual to Tangible
Guy Andre Boy
On April 15, 2020, Guy Andre Boy presented an INCOSE Webinar, Human Systems Integration: From Virtual to Tangible. Guy provided a contemporary formalization of a systemic approach to Human-Systems Integration (HSI). Good HSI is a matter of maturity… it takes time to mature. It takes time for a human being to become autonomous, and then mature! HSI is a matter of human-machine teaming, where human-machine cooperation and coordination are crucial. We cannot think engineering design without considering people and organizations that go with it. We also cannot think about new technology, new organizations, and new jobs without considering change management. This webinar provided a follow-up of previous contributions in Human-Centered Design and practice in the development of virtual prototypes that requires progressive operational tangibility toward HSI. Guy discussed flexibility in design and operations, tangibility of software-intensive systems, virtual human-centered design, increasingly-autonomous complex systems, Human-Factors and Ergonomics of sociotechnical systems, systems integration, and change management in digital organizations.
Access a Recording of this Webinar
3.2 Presentation Concerning Living and Working in Space: Lessons for the Systems Engineer
Dan Burbank
On April 22, 2020, Dan Burbank provided a presentation for the New England Chapter of INCOSE, “Living and Working in Space: Lessons for the Systems Engineer”. The lecture provided a systems engineering-focused tour of spacecraft systems and spaceflight operations as they have evolved over time. Over the six-decade history of the US space program, the missions, platforms, systems, and the crews themselves have evolved. Mission durations have grown longer and crew on-orbit activities now increasingly emphasize scientific research. A new generation of spacecraft is about to be fielded that is planned to return human launch capability to the USA after a 9-year hiatus. Spaceflight is increasingly an international and a commercial endeavor and that’s reflected in the character and culture of the spaceflight operations. International partners include the European Space Agency (ESA), the Japan Aerospace Exploration Agency (JAXA), Canadian Space Agency (CSA) and the Australian Space Agency (ASA). The size and complexity of spacecraft such as the International Space Station (ISS) require teams of flight controllers around the world to “fly” the vehicle, which has raised awareness of the need to incorporate autonomy into future spacecraft systems. NASA’s Artemis program is targeting a return to the Moon in 2024 with extensive reliance upon industry and international partners to enable permanent, sustained surface operations.
4.1 Results of the SERC | INCOSE NDIA | MBSE Maturity Survey Are In
Benchmarking the Benefits and Current Maturity of Model-Based Systems Engineering across the Enterprise
In 2019-2020, the National Defense Industrial Association Systems Engineering Division (NDIA-SED) and the International Council on Systems Engineering (INCOSE) collaborated with the Systems Engineering Research Center (SERC) at the Stevens Institute of Technology to benchmark the current state of Digital Engineering (DE) and Model-Based Systems Engineering (MBSE) across government, industry, and academia. The team developed and executed a survey of the systems engineering community to:
- broadly assess the maturity of system engineering’s “digital transformation”
- identify specific benefits of MBSE and associated metrics
- identify enablers and obstacles to DE and MBSE adoption across the enterprise
- and understand evolving and necessary shifts in the systems engineering (SE) workforce.
The SERC-2020-SR-001 report: “Benchmarking the Benefits and Current Maturity of Model-Based Systems Engineering across the Enterprise,” which indexes the findings drawn from the MBSE Maturity Survey, is now publicly available. The survey itself was released by the Systems Engineering Research Center, INCOSE and NDIA during late 2019, and closed on February 1, 2020.
From the Executive Summary
The most frequently reported obstacles to MBSE adoption, as shown in the figure, were organizational culture, workforce knowledge/skills, leadership support/commitment, awareness of MBSE benefits and value, MBSE tools, and change management process design. The most frequently-reported enablers also included leadership support/commitment and workforce knowledge/skills, as well as people willing to use MBSE tools, champions, and people in systems engineering roles, training, and demonstrating benefits and results. MBSE methods and processes, tools, training, resources, and leadership support and commitment were the most frequently reported changes necessary to improve MBSE implementation.
The most critical skills for DE/MBSE favored system architecture and systems thinking, along with requirements engineering, domain knowledge, and SE process skills. Added to these were “digital skills” relating to modeling, data science, simulation, data/tools environment, and model governance.
The most commonly cited challenges were creation of DE/MBSE processes and issues with tool integration, along with staffing. The survey reinforces that the critical skills for a good systems engineer are the same as those for a good model-based systems engineer. The critical differences are the addition of the utilization of specific tools, an understanding of modeling language, and the “digital engineering” skills, which in this survey focus around the skillsets of data management and utilization and general modeling and simulation skills. These were linked in the section to the HELIX Atlas systems engineering proficiency model.
View the Report
View the briefing on results of the MBSE Maturity Survey
Editor’s note:
PPI promotes use of the term practitioner of ‘systems engineering’ over ‘systems engineer’. See article 13.3 Systems Engineer, or Systems Engineering? for an article addressing this topic.
4.2 The Consortium for Information & Software Quality™ is Leading an Initiative to Develop Quality Measures for MBSE Specification
CISQ has launched a joint Working Group with OMG to create a specification for measuring model quality. The earlier that system engineers can detect vulnerabilities and weaknesses in a model, the less expensive and risky to repair. The objective of this Working Group is to define quality measures based on counting severe architectural and design weaknesses that can be detected through analyzing formal models developed in MBSE languages and technologies.
Recognizing that much of the focus on MBSE quality to date has been on the functional fit of the model, CISQ is aiming to build on other quality characteristics, such as vulnerabilities and weaknesses, system maintainability, and reliability.
The Quality Measures for MBSE Working Group started its research in March 2019 and continues to work on the specification in 2020. The Quality Measures for MBSE Working Group met on March 26, 2020 with guest speakers Philomena Zimmerman and Tom McDermott. Here are links to the presentations:
- Recap of Quality Measures for MBSE Project – David Norton, Executive Director, CISQ
- U.S. Department of Defense Digital Engineering Strategy and Vision – Philomena Zimmerman, Deputy Director for Engineering Tools and Environments
- Results of MBSE Benchmarking Survey led by SERC, NDIA, INCOSE – Tom McDermott, Deputy Director, Systems Engineering Research Center
Participants:
- Dr. Bill Curtis, CISQ
- David Norton, CISQ
- Paul Seay, Northrop Grumman
- Philippe-Emmanuel Douziech, CAST
- Joe Jarzombek, Synopsys
- Donald Davidson, Synopsys
- Paul Rainey, CGI
- Kavitha Sridhar, CGI
- Robert Martin, MITRE
- Bill Nichols, SEI
- Girish Seshagiri, ISHPI
- Nick Mansourov, KDM Analytics
- Dr. Barry Boehm, University of Southern California
CISQ is seeking Working Group members to contribute to this specification and our roadmap. To get involved, visit the CISQ Website for more information.
About CISQ
The Consortium for Information & Software Quality™ (CISQ™) is a group that develops international standards for automating the measurement of software size and structural quality from the source code. The standards written by CISQ enable organizations developing or acquiring software-intensive systems to measure the operational risk software poses to the business, as well as estimate the cost of ownership. CISQ was co-founded by the Object Management Group® (OMG®) and Software Engineering Institute (SEI) at Carnegie Mellon University.
4.3 INCOSE Foundation Releases Five Year Report
In April 2020, the INCOSE Foundation released its Five-Year Report that summarizes activities and accomplishments of 2015 – 2019. Donor support since the inception of The INCOSE Foundation has resulted in total contributions of 842,770 USD. The report informs concerning how these donations have supported the mission of advancing systems engineering. The goal of the Foundation is to support programs that help create a better world by advancing the development of systems engineering practice.
The INCOSE Foundation has offered five scholarships:
• ISEF, the International Science and Engineering Fair INCOSE Award to a pre-college student.
• The Chesapeake Chapter Award for undergraduates (Three $500 awards).
• The Johns Hopkins University (JHU) Alexander Kossiakoff Award to a student in a Masters or Doctoral program.
• The Stevens Doctoral Award for Promising Research in Systems Engineering to a Ph.D Candidate.
• The James E. Long Award for post-doctoral work.
ISEF is supported through the generosity of the INCOSE members – INCOSE Fellows – who donate their time and assets; and, through some financial assistance from The INCOSE Foundation. Our donors make this possible.
The Chesapeake Chapter Award for undergraduates is supported by donations through the Chesapeake Chapter and administered by The INCOSE Foundation.
The JHU Alexander Kossiakoff Award has been supported through a grant to the Foundation from Johns Hopkins University. That Award, at JHU’s decision, is being discontinued.
The Stevens Doctoral Award for Promising Research in Systems Engineering has been supported by a grant from The Stevens Institute. The Stevens Institute has renewed support for this Award.
The James E. Long Award for post-doctoral work was established by the Long family to honor James Long’s work in Systems Engineering. It, too, is supported by donations from individuals. A similar fund was set up after the untimely and tragic loss of David Wright. These funds have been used to support advancement of work in Systems Engineering by INCOSE members.
4.4 Google Engineers ‘Mutate’ AI to Make It Evolve Systems Faster Than We Can Code Them
Much of the work undertaken by artificial intelligence involves a training process known as machine learning, where AI gets better at a task such as recognizing a cat or mapping a route the more it does it. Now that same technique is being used to create new AI systems, without any human intervention.
For years, engineers at Google have been working on a smart machine learning system known as the AutoML system (or automatic machine learning system). Now, researchers have tweaked it to incorporate concepts of Darwinian evolution and have shown it can build AI programs that continue to improve upon themselves faster than they would if humans were doing the coding.
The new system is called AutoML-Zero and it could lead to the rapid development of smarter systems – for example, neural networked designed to more accurately mimic the human brain with multiple layers and weightings, something human coders have struggled with.
“It is possible today to automatically discover complete machine learning algorithms just using basic mathematical operations as building blocks,” write the researchers in their pre-print paper. “We demonstrate this by introducing a novel framework that significantly reduces human bias through a generic search space.”
The original AutoML system is intended to make it easier for apps to leverage machine learning, and already includes plenty of automated features itself, but AutoML-Zero takes the required amount of human input way down.
View the Research Paper
4.5 Closing the Engineering Skills Gap with Generative Design
The Forbes Technology Council advises that the way products are developed and manufactured is changing with advances in artificial intelligence (AI), automation, additive manufacturing, big data analytics, robotics, cloud computing, and the “internet of things.” The labor force is struggling to keep up with the fast pace of technological advancement.
Generative design works like this: engineers set parameters for what their design needs to accomplish, and AI generates designs optimized to meet those parameters. In the past, generative design was limited to a technology called topology optimization, where material was shaved away to create a design optimized for mass reduction.
However, to use topology optimization effectively, the engineer still has to know all of the engineering requirements of the design and understand the manufacturing processes needed to create the design.
More Information
4.6 INCOSE is Looking for an Assistant Director of Membership
INCOSE is looking for a member with a desire to help grow INCOSE. Applications are open for the volunteer position of Assistant Director for Membership.
Short description:
On a permanent or case by case basis, the Membership Engagement Ambassador will standup and run INCOSE booths and informational stations at local conferences, schools, SE fairs, etc. held by INCOSE or INCOSE associated organizations, engaging members and potential members on INCOSE membership offerings.
Find out more and apply at http://ow.ly/VfYy50A3kof
4.7 Register as a Chartered Engineer with INCOSE UK
Have you considered registering as a Chartered Engineer (CEng), Incorporated Engineer (IEng) or Engineering Technician (EngTech)? INCOSE UK offers a route to Professional Registration for Systems Engineers, and they are accepting both new applications and transfers now.
Dates: 15 July 2020
Time: 12:00 – 12:45
Location: Zoom – link will be provided to confirmed attendees.
In order to provide information and guidance, INCOSE UK has set up a series of interactive Professional Registration Zoom sessions. These sessions are open to all potential candidates and there is no requirement to be a member in order to attend.
The sessions are 45 minutes long and will include:
- An overview from Kirsty Akroyd-Wallis, President of INCOSE UK and experienced assessor, interviewer and mentor
- Practical information on the process and how to apply from Lynn Davis, Professional Development Manager
- An insight into the process from the applicant’s perspective from a recent INCOSE UK registrant
- Question and answer session
The session is designed to give applicants an overview on Professional Registration with INCOSE UK and equip them with information to begin a draft application.
To book a place for you or a colleague, please email profdev@incoseuk.org
5.1 Object Management Group (OMG)
The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium, founded in 1989. OMG standards are driven by vendors, end-users, academic institutions and government agencies. OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries. OMG’s modeling standards, including the Unified Modeling Language® (UML®) and Model Driven Architecture® (MDA®), enable powerful visual design, execution and maintenance of software and other processes. OMG also hosts organizations such as the Consortium for Information & Software Quality™ (CISQ™), the DDS Foundation and BPM+ Health. In addition, OMG manages the Industrial Internet Consortium® (IIC™), the Industry IoT Consortium®.
The mission of the Object Management Group (OMG) is to develop technology standards that provide real-world value for thousands of vertical industries. OMG is dedicated to bringing together its international membership of end-users, vendors, government agencies, universities and research institutions to develop and revise these standards as technologies change throughout the years.
OMG hosts four technical meetings throughout the year. These meetings give OMG members and interested nonmembers the opportunity to collaborate in a centralized location, learn about technology standards products and processes at tutorials, and attend special information day events on current trending hot topics. While technical meetings provide a centralized location for Task Forces and Working Groups to work together, they are merely checkpoints with the bulk of the work between members taking place electronically via email, teleconferences, and on wikis.
For more information about joining OMG, please visit Become a Member page.
5.2 Consortium for Information & Software Quality™ (CISQ™)
Editor’s Note: See also the article provided in the SE News section concerning CISQ’s leadership for the initiative to develop quality measures for MBSE specification.
The mission of the Consortium for Information & Software Quality™ (CISQ™) is to develop international standards to automate software quality measurement and to promote the development and sustainment of secure, reliable, and trustworthy software. Through the work of CISQ, industry-supported standards have been developed to measure software size, structural quality, and technical debt from source code. These standards are used by IT organizations, IT service providers, and software vendors in contracting, developing, testing, accepting, and deploying software applications.
- Software sizing is used to estimate development projects and measure productivity
- Structural quality refers to the software’s security, reliability, performance efficiency, and maintainability
- Technical debt is an estimate of corrective maintenance due to weaknesses in the code and architecture
Three new standards development initiatives are underway and CISQ is seeking participation from enterprises, government agencies, universities, suppliers, and vendors engaged in:
- Quality Measures for Model-Based Systems Engineering (MBSE) – see article 5.2 above
- Shift Left Requirements Sizing
- Software Bill of Materials (SBoM)
Members are IT executives from the Global 2000, system integrators, outsourced service providers, and software technology vendors. CISQ’s roadmap includes the development of new standards, certification programs, and deployment activities to advance the state of practice in software engineering. There are two membership levels: individual membership and corporate membership. A benefit of corporate membership is the ability to participate in standards development. More than 1500 software-intensive organizations have joined CISQ as members.
5.3 New England (USA) Complex Systems Institute
The New England Complex Systems Institute (NECSI) is an independent academic research and educational institution with students, postdoctoral fellows, and faculty. In addition to the in-house research team, NECSI has co-faculty, students, and affiliates from MIT, Harvard, Brandeis, and other universities nationally and internationally. NECSI has been actively involved in the development of complex systems science and its applications. NECSI studies how interactions within a system lead to its behavioral patterns, and how the system interacts with its environment.
NECSI research advances fundamental science and its applications to real world problems, including social policy matters. NECSI researchers study networks, agent-based modeling, multiscale analysis and complexity, chaos and predictability, evolution, ecology, biodiversity, altruism, systems biology, cellular response, health care, systems engineering, negotiation, military conflict, ethnic violence, and international development (see NECSI Research).
5.4 Institute for Systems Engineering Research
The Institute for Systems Engineering Research (ISER) is a collaborative effort between the U.S. Army Engineer Research and Development Center and Mississippi State University.
The goal of ISER’s efforts and products is to mitigate risk, reduce cost, and improve efficiency in Department of Defense (DoD) acquisition programs; serve as an additional asset for the state’s industrial base for systems engineering related tasks; and create an environment that draws DoD and civilian industry development to the state of Mississippi.
The ISER’s primary objectives include:
- To research systems engineering concepts and design of tools to facilitate DoD systems development and decision-making processes.
- To enhance strategic and operational analysis for ERDC and MSU programs and efforts.
- To leverage existing capabilities and expertise previously developed at MSU and ERDC to
- establish a national center of excellence in systems engineering.
Mission
Located at the Engineer Research and Development Center’s Information Technology Laboratory (ITL) in Vicksburg, Mississippi, the Institute for Systems Engineering Research’s mission is to improve engineering, design, and process systems by developing next-generation computational tools for new systems and products that will assist decision makers in selecting the most appropriate courses of action to resolve issues related to ERDC equities or projects and reduce risk of the U.S. industrial base.
Vision
The Institute’s research vision is to revolutionize system engineering processes and virtual prototyping through computational science and engineering leading to a dual use capacity that will enhance innovation in the DoD and the U.S. industrial base. ISER is a collaborative effort between Mississippi State University and ERDC.
6. News on Software ToolS Supporting
Systems Engineering
6.1 Siemens introduces workplace distancing solution to manage “next normal” manufacturing
Manufacturers are facing new challenges as they look to restart or maintain operations during the ongoing COVID-19 pandemic. As preparations are made for the “next normal”, manufacturers must consider additional dimensions of employee safety, including the establishment of production environments and workflows that address physical distancing requirements. Combining proven hardware and software, Siemens has created a new solution that enables companies to quickly and efficiently model how employees interact with each other, the production line and plant design. The new solution also enables organizations to build an end-to-end digital twin, in order to simulate worker safety, iterate on and optimize workspace layouts and validate safety and efficiency measures to help future-proof production lines.
With Siemens’ SIMATIC Real Time Locating Systems (RTLS), companies can continuously measure distances between workers, provide real time visual feedback to employees regarding their spacing from others and create a log of all movements and interactions over time. In this way the Siemens’ SIMATIC RTLS continuously facilitates safe distancing while providing numerous additional benefits.
Combining Siemens’ SIMATIC RTLS with a digital twin of the actual manufacturing environment permits companies to model and simulate how employees interact with the equipment and each other, enabling them to iterate and optimize safety and productivity in the short term, and validate a redesign of the entire operation before more costly physical changes are made.
“We are helping our customers create a safe work environment, which is extremely important as they look to produce efficiently and reliably under unprecedented circumstances,” said Tony Hemmelgarn, President and CEO of Siemens Digital Industries Software. “The combination of real time distancing management and digital simulations will help companies maintain safe work environments today and make educated decisions about ongoing and long-term optimization.”
For more information on how Siemens can help manufacturers during these times, please see here.
6.2 Article: 13 Python Data Science and Machine Learning Libraries You Need to Know
by
Python is almost always the best choice for data scientists. This is due to its versatility and simplicity, but above all else, it’s thanks to the open-source packages distributed by the community and important companies.
As it’s a general-purpose programming language, Python is used for web development (with Django and Flask), data science, machine learning, cybersecurity, and so on.
Today, we’re going to discuss the 13 data science and machine learning libraries that every data scientist must know and should be using.
Basic Libraries for Data Science
These basic libraries make Python a favorable language for data science and machine learning. The following packages will allow us to analyze and visualize data:
NumPy is the fundamental package for scientific computing with Python. Among other things, it contains a powerful N-dimensional array object, sophisticated (broadcasting) functions, tools for integrating C/C++, and Fortran code. And it is useful in linear algebra, Fourier transform, and random number capabilities. Besides its obvious scientific uses, NumPy can also be used as an efficient multi-dimensional container of generic data. Arbitrary data types can be defined. This allows NumPy to seamlessly and speedily integrate with a wide variety of databases.
SciPy builds on NumPy by adding a collection of algorithms and high-level commands for manipulating and visualizing data. This package includes functions for computing integrals numerically, solving differential equations, optimization, and more.
pandas is actually the best tool to visualize, read, and write data. I find myself using it often — especially while working with .csv files.
Matplotlib is the standard Python library for creating 2D plots and graphs. It’s very flexible to use but a bit low-level, so it’s a little tricky to plot more complex graphs or plots. However, it’s a library that I use often — especially when working with datasets that do not require to be visualized. So, just to plot my models’ scores.
Libraries for Machine Learning
Machine learning lies in the intersection of artificial intelligence and statistical analysis. The following libraries offer Python the ability to apply many machine learning activities, from running basic regressions to forming complex neural networks.
scikit-learn builds on NumPy and SciPy by adding a set of algorithms for common machine learning and data mining tasks, including clustering, regression, and classification. It contains lots of pre-trained machine learning models that data scientists use rather than creating their own models. Obviously, it depends on what ML model you need to use. If you are looking for something very specific for your intent, maybe it’s better to create your own model.
Theano uses NumPy’s syntax to optimize and evaluate mathematical expressions. It uses the GPU to speed up its processes. Theano’s speed makes it especially valuable for deep learning and other computationally complex tasks. I find it very useful to work with TensorFlow and Keras.
TensorFlow was developed by Google as an open-source successor to DistBelief, their previous framework for training neural networks. TensorFlow uses a system of multi-layered nodes that allow you to quickly set up, train, and deploy artificial neural networks with large datasets. It’s very practical and easy to use. It’s also used by its creator, Google, and there are tons of articles and tutorials that mention TensorFlow.
pickle is an open-source package that allows us to serialize our ML models. I choose pickle over many other model serializers because I find it very simple to use and efficient. This is one of the most efficient ways to share your model or use it from another program.
Libraries for Data Mining and Natural Language Processing
“Data mining is the process of discovering patterns in large data sets involving methods at the intersection of machine learning, statistics, and database systems. Data mining is an interdisciplinary subfield of computer science and statistics with an overall goal to extract information (with intelligent methods) from a data set and transform the information into a comprehensible structure for further use.” — Wikipedia
“Natural language processing (NLP) is a subfield of linguistics, computer science, information engineering, and artificial intelligence concerned with the interactions between computers and human (natural) languages, in particular how to program computers to process and analyze large amounts of natural language data.” — Wikipedia
Scrapy is a fast high-level web crawling and web scraping framework used to crawl websites and extract structured data from their pages. It can be used for a wide range of purposes, from data mining to monitoring and automated testing.
NLTK is a set of libraries designed for natural language processing. It’s often used with everything regarding text classification and analysis, from sentiment analysis to chatbots.
Pattern is a web mining module for the Python programming language. It has tools for data mining (Google, Twitter, and Wikipedia API, a web crawler, an HTML DOM parser), natural language processing (part-of-speech taggers, n-gram search, sentiment analysis, WordNet), machine learning (vector space model, clustering, SVM), network analysis, and <canvas> visualization.
seaborn is a popular visualization library that builds on Matplotlib’s foundation. Once you try it after using Matplotlib, it will be like being in Eden. It’s very sophisticated, and unlike Matplotilib, it’s a high-level package. This means we can easily plot more complex types of plots, such as heat maps and so on.
Bonus
Flask is a powerful Python-based web development framework. But why is it on the list of tools that data scientists need to know? And also, isn’t Django better for web development? Well, sometimes you may need to embed your ML model in a web app because that would mean that anyone could easily access your classification model from the internet. You could even create an online classification service! To answer the second question, yes, Django is actually better for web development and it’s also simple to use, but not as simple as Flask.
In general, I would definitely use Django to build a normal website. But if you just want your model to be embedded in a website, Flask is actually simpler and more intuitive.
All the libraries listed in this article are a small part of the open-source packages that can be found online. These were just basic data science and machine learning libraries that every data scientist must know.
6.3 Enterprise Architect v15.2 (Build 1551) BETA Released on 26 May 2020
The new features and updates of the latest version of Enterprise Architecture V15.2 are described below:
Element Reviews
- Manage Reviews window updates:
- Reviews locked by Element status now display a ‘!’ indicator on their icon
- Reviews locked by Element status but not approved by all approver now include an additional row indicating discrepancy
- Approvers are now sorted by name
- Review topics are now sorted to display newest first
- Now updates when properties of reviewed elements are changed
- Now included in Working Sets
- Creating an Approver for a Review on Firebird databases no longer fails
External Simulation Integration
- State Machine export to Simulink and Stateflow improved
- SysPhS technology updated with model library, patterns, and references to existing library blocks
Model Add-Ins
- Element Behavior editor no longer shows unused Operation Behavior and Class Imports code fields for model add-ins
- Element Behavior editor now allows reloading an active model add-in
- Model Add-ins now receive the EA_Connect broadcast during initialization to allow for creating workflow add-ins
Other
- Personal Journal editing restored
7. Systems Engineering Publications
7.1 When Systems Engineering Fails – Toward Complex Systems Engineering
by
Yaneer Bar-Yam
IEEE – 2003
In this document, lessons learned from problems with systems engineering over the past couple of decades (up to 2003) are reviewed and it is suggested that there are two effective strategies for overcoming them: (1) restricting the conventional systems engineering process to not-too-complex projects, and (2) adopting an evolutionary paradigm for complex systems engineering that involves rapid parallel exploration and a context designed to promote change through competition between design/implementation groups with field testing of multiple variants. The second approach is an extension of many of the increasingly popular variants of systems engineering today.
7.2 Complex Engineered Systems: Science Meets Technology (Understanding Complex Systems)
Softcover reprint of hardcover 1st ed. 2006 Edition
by
Dan Braha, Ali A. Minai, Yaneer Bar-Yam
From the Amazon.com Website:
This book sheds light on the large-scale engineering systems that shape and guide our everyday lives. It does this by bringing together the latest research and practice defining the emerging field of Complex Engineered Systems. Understanding, designing, building and controlling such complex systems is going to be a central challenge for engineers in the coming decades. This book is a step toward addressing that challenge.
Every time that we take money out of an ATM, surf the internet or simply turn on a light switch, we enjoy the benefits of complex engineered systems. Systems like power grids and global communication networks are so ubiquitous in our daily lives that we usually take them for granted, only noticing them when they break down. But how do such amazing technologies and infrastructures come to be what they are? How are these systems designed? How do distributed networks work? How are they made to respond rapidly in ‘real time’? And as the demands that we place on these systems become increasingly complex, are traditional systems-engineering practices still relevant?
This volume examines the difficulties that arise in creating highly complex engineered systems and new approaches that are being adopted. Topics addressed range from the formal representation and classification of distributed networked systems to revolutionary engineering practices inspired by biological evolution. By bringing together the latest research in Complex Engineered Systems, this book sheds light on the current state and future course of this emerging field.
Publisher: Springer; Softcover reprint of hardcover 1st ed. 2006 edition (November 19, 2010)
Format: Hardcover, Paperback
ISBN-10: 3642069371
ISBN-13: 978-3642069376
7.3 Exploring Engineering: An Introduction to Engineering and Design (5th Ed.)
by
Philip Kosky, Robert T. Balmer, William D. Keat, and George Wise
From the Amazon.com Website:
Engineers solve problems and work on emerging challenges in a wide range of areas important to improving quality of life; areas like sustainable energy, access to clean water, and improved communications and health care technologies. Kosky et al’s Exploring Engineering (5th Edition) explores the world of engineering by introducing the reader to what engineers do, the fundamental principles that form the basis of their work, and how they apply that knowledge within a structured design process. The three-part organization of the text reinforces these areas, making this an ideal introduction for anyone interested in exploring the various fields of engineering and learning how engineers work to solve problems. The 5th edition has been revised to better reflect the knowledge base of incoming freshmen, and new content has been added for several new and emerging engineering disciplines, such as environmental engineering, cybersecurity, additive manufacturing, and mechatronics, as well as new design projects.
Publisher: Academic Press; 5th edition (June 15, 2020)
Format: eTextbook, Paperback
ISBN-10: 0128150734
ISBN-13: 978-012815073z
by
Amira Sharon, Dov Dori, and Oliver deWeck
Systems Engineering Management (SEM) is being developed hand in hand with the maturation of systems engineering, emphasizing the management of the joint project‐product ensemble. Most SEM applications use traditional Project Management (PM) methods and tools, including Gantt chart, PERT, Critical Path Method, System Dynamics, Earned Value Method, and Design Structure Matrix. Object Process Methodology has also been recently studied as a vehicle for Project‐Product Lifecycle Management. We examine how systems engineers perceive the extent to which PM methods support SEM. We verified that project and product are viewed as two complementary facets of SEM, and that certain PM methods address both domains better than others with respect to particular examined factors.
7.5 GigaBit Magazine
GigaBit Magazine is a technology platform and community providing industry-leading insights, news, analysis, and reports for Digital and Technology Leaders dealing with the ‘Technology & Digital Transformation’ of the World’s largest companies and brands.
7.6 Systems Engineering Body of Knowledge (SEBoK)
The Systems Engineering Body of Knowledge (SEBoK) provides a compendium of the key knowledge sources and references of systems engineering.
The current version of the SEBoK was released on 31 October 2019 and reflects the continuing evolution of the document. For a summary of the changes made for v. 2.1 see the Letter from the Editor. See Acknowledgements and Release History for a full description of the current and all previous SEBoK versions. The BKCASE Governing Board includes representatives of the three SEBoK steward organizations – the International Council on Systems Engineering (INCOSE), the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS), and the Systems Engineering Research Center (SERC) which provide the funding and resources needed to sustain and evolve the SEBoK and make it available as a free and open resource to all. The stewards appoint the BKCASE Governing Board to be their primary agents to oversee and guide the SEBoK and its companion BKCASE product, Graduate Reference Curriculum for Systems Engineering (GRCSE).
The SEBoK is organized into 7 parts:
Part 1 SEBoK Introduction
Part 2 Foundations of Systems Engineering
Part 3 Systems Engineering and Management
Part 4 Applications of Systems Engineering
Part 5 Enabling Systems Engineering
Part 6 Related Disciplines
Part 7 Systems Engineering Implementation Examples
The SEBoK also includes a Glossary of Terms and a list of Primary References, to reflect this scope of systems engineering knowledge and its links into other bodies of knowledge.
SEBoK is a guide to the broad scope of SE related knowledge. The core of this is the well tried and tested knowledge which has been developed through practice, documented, reviewed and discussed by the SE community. In addition, SEBoK also covers some of the emerging aspects of SE practice, such as Systems of Systems, Agile Life Cycle approaches or Model Based Systems Engineering (MBSE). Part 1 also includes a discussion of SEBoK Users and Uses, including a number of use cases which give advice on how different groups of users might navigate and use the SEBoK. This is a good place to start if you are new to the SEBoK. Individuals who are new to systems engineering can start with Use Case 0: Systems Engineering Novices.
7.7 Institute of Industrial & Systems Engineers (IISE) Body of Knowledge
What is industrial engineering?
Industrial engineering is concerned with the design, improvement, and installation of integrated systems of people, materials, information, equipment, and energy. It draws upon specialized knowledge and skills in the mathematical, physical, and social sciences together with the principles and methods of engineering analysis and design, to specify, predict, and evaluate the results to be obtained from such systems.
What is the Industrial Engineering Body of Knowledge?
These documents represent a repository of essential information for industrial engineering (IE) and is made up of knowledge areas representing a taxonomy of relevant IE concepts. The Industrial Engineering Body of Knowledge (IEBoK) is composed of 12 knowledge areas. Each knowledge area is represented by an outline that defines what needs to be known to achieve a mastery in the field of IE. A list of references is included in each knowledge area providing the reader with a resource to the requisite detail necessary to obtain a mastery of the areas provided in the IEBoK. In addition, a section of Related Topics is provided that includes closely associated areas with which an IE should be familiar.
8.1 Alejandro Salado Named 2020 Scholarship of Teaching and Learning Award Winner
Alejandro Salado, an assistant professor in Virginia Tech’s Grado Department of Industrial and Systems Engineering in the College of Engineering, has been named the 2020 Scholarship of Teaching and Learning Award winner by Virginia Tech’s Center for Excellence in Teaching and Learning (CETL). The award is presented annually to recognize faculty members who have dedicated themselves to the pursuit of scholarship addressing teaching and learning in higher education. All Virginia Tech instructional and research faculty members (full-time and part-time) and graduate students are eligible for nomination for the award.
Salado began his career in academia after a decade developing satellites in industry and quickly realized that there was no reason for the significant difference in what students learned in academia and what engineers actually do in practice. “I felt that educational institutions were wasting potential learning opportunities that were readily available to them,” said Salado. “Thus, my educational research interests center on how to embed real-life aspects of engineering into the existing engineering education curriculum. I am interested in both the application of engineering methods and the acquisition of behavioral tenets to navigate through a messy world.”
Salado said he resolved early in his academic career to maintain a constant production of scholarship related to teaching and learning on top of his regular research. “Since I joined Virginia Tech, I have published teaching and learning scholarship every year, including two published journal papers, seven published peer-reviewed conference papers, and one journal paper currently under second review,” Salado said. “These publications collectively reflect my research interests.”
Two strategies in particular have allowed Salado to successfully pursue teaching and learning scholarship in parallel with his core research. “I have actively sought synergies with my instructional duties, both in terms of identifying opportunities for improving teaching and learning and in terms of trying out novel instructional approaches,” said Salado. “I believe that the classroom offers an excellent setting to test (and report on) educational innovation with just a little extra effort from the instructor.
“I have also consistently partnered with engineering education and math education doctoral students and professors to transform instructional ideas into scholarship by bringing in theoretical frameworks that I had never been exposed to before, curating the research methods and helping in assessing and understanding the results of the studies.”
Salado came to Virginia Tech in 2015 from OHB System AG in Munich, Germany where he worked as a systems engineer. He also served on the faculty of the University of South East Norway (Kongsberg) as an industry professor at the Norwegian Institute of Systems Engineering. Salado’s research is focused on the need to elucidate scientific foundations for systems engineering and the intention to produce work that can be transitioned to practice. In addition, he experiments with novel approaches to embed real-life aspects of engineering practice into the classroom. Salado earned a Ph.D. in systems engineering from the Stevens Institute of Technology in Hoboken, New Jersey. He also earned master degrees in electronics engineering and project management from Polytechnic University of Catalonia in Barcelona, Spain.
The Scholarship of Teaching and Learning Award is given to a maximum of two recipients per year with award winners receiving a $500 prize and a plaque. The scholarship of teaching and learning at Virginia Tech involves the rigorous examination and investigation of higher education teaching and learning. It uses a research-based, scientific, and scholarly lens to examine questions in higher education pedagogy, making the results public for examination and critique.
For more information on the Scholarship of Teaching and Learning Award and a list of past winners, visit the Center for Excellence in Teaching and Learning at teaching.vt.edu.
8.2 Master of Engineering in Systems Engineering
Stevens Institute of Technology, USA
The Master of Engineering (M.Eng.) in systems engineering graduate program offers a multidisciplinary approach to engineering education by providing a blend of engineering, systems and management subjects. M.Eng graduates manage engineering and technology, are able to address systems integration, life-cycle issues, and systems thinking at the system and enterprise levels, in a market where globalization, technology, quality, complexity and productivity are the key business drivers.
Completion of this program will result in the following Master of Engineering degree in systems engineering with a concentration in:
- Large-scale cyber-physical systems, or
- Embedded cyber-physical systems, or
- Space systems, or
- Software systems, or
- unspecified (if courses not taken in one concentration, as noted below)
Students satisfying the requirement for the space systems concentration, may alternatively receive a degree in Master of Engineering in space systems engineering. Students who, with their advisor’s approval, choose not to complete all of the courses in a single concentration will receive a Master of Engineering in systems engineering degree without a specified concentration.
Requirements Structure
The program consists of ten (10) courses (30 credits): six (6) required core courses, three (3) electives and a project or thesis. Three of these six required core courses are selected from one of four concentration areas (listed above).
Students without professional experience beyond the bachelor’s degree taking a master’s in systems engineering in a non-software systems concentration must take SYS 581 Introduction to Systems Engineering, preferably in the later stages of the senior design project. SYS 581 should be taken before the concept, architecture & design, implementation and sustainment area courses, if possible. Students without professional experience taking a concentration in software systems must take SSW 540 Fundamentals of Software Engineering. In addition, they must have competency in software programming. All exceptions require approval of the advisor and systems engineering program director.
Concentrations
One course must be taken from each of the three (3) areas: architecture & design, implementation and sustainment. To receive a concentration, these courses must be taken from a single concentration area. The following are the courses for large-scale systems, cyber-physical systems, space systems and software systems concentrations.
Electives
Three (3) advisor approved electives (9 credits) can be chosen from SSE academic course offerings in (SYS) systems engineering, (SSW) software engineering, (EM) engineering management, (ES) socio-technical systems, (SES) systems engineering security or advisor approved courses. SYS 611, SYS 660 and SYS645, if not already taken, are strongly recommended as electives.
Project or Thesis
At least three (3) credits and up to six (6) credits, must be applied towards a project (SYS 800 Special Problems in Systems Engineering), or a thesis (SYS 900 Thesis in Systems Engineering). If a thesis is chosen instead of a project, the completion of six (6) credits of SYS 900 is required, replacing SYS 800 and one elective course. The project or thesis should be in the concentration area.
For more information, visit the Stevens Institute M. Eng website
8.3 M.S. & PhD in Industrial and Systems Engineering at Mississippi State University, USA
The Department of Industrial and Systems Engineering offers graduate programs leading to the Master of Science (thesis and non-thesis option) degree in Industrial Engineering and a Doctor of Philosophy degree in Industrial and Systems Engineering.
Major areas of study include:
- industrial systems;
- operations research,
- manufacturing systems;
- management systems engineering; and
- ergonomics/human factors.
Research laboratories include facilities in Human Systems Engineering, Logistics and Transportation Engineering, Management Systems Engineering, and Optimization and Data Informatics.
9. Some Systems Engineering-Relevant Websites
College Scholarships in Engineering
Provides a set of Websites and articles relating to scholarships for engineering students.
College Engineering Scholarships for High-achieving Students
The Project on Student Debt reported that of the schools they surveyed, the average student loan debt for the Class of 2010 was $25,250 for those with debt; with 98 colleges reporting average debt of more than $35,000. Seventy-three colleges said more than 90% of the class of 2010 graduated with debt. Help is available. This Website provides information concerning scholarships for the high-achieving engineering students (including some for transfer students). If a student has the ability, know-how, and dedication to get top grades and SAT scores and they are involved in student leadership positions, student government, and community service, they should consider the top-paying scholarships.
30 Colleges with Free or Reduced Tuition
With college tuition costs reaching an all-time high and student loan debt continuing to climb, many colleges and universities now offer free or reduced tuition for students. Some scholarships are merit-based, while other grants are need-based. The goal is to provide increased access to higher education for students regardless of their financial profile, and to limit the amount of student loan debt that a student has to borrow.
10.1 IEEE P3141™ Standard for 3D Body Processing being
Developed
The IEEE Standards Association (IEEE SA) has initiated development of IEEE P3141™ Standard for 3D Body Processing. 3D body processing technologies are emerging as the next wave for how people interact and engage in a range of semi-to-fully immersive experiences to, for example, shop, play, and learn. However, due to market and technology fragmentation, there is a lack of agreement from across the ecosystem for how to align and deliver on quality of experiences as well as how to cope with gaps in interoperability, communication and security.
This standard will address the fundamental attributes that contribute to 3D body processing quality of experiences, as well as identifying and analyzing existing metrics and other useful information relating to these attributes. It defines a standardized suite of objective and subjective methods, tools and frameworks for assessing 3D body processing quality of experience attributes, and it specifies methods, tools and frameworks to facilitate standards-based interoperability, communication, security and comparison among 3D body processing technologies such as 3D/depth sensors, scanners, digitization, simulation and modeling, analytics and animation/visualization for solution providers as well as for consumer-facing companies such as in retail, health/wellness, sports/athletics, medical industries.
For additional information, contact the IEEE P3141™ Working Group Chair, Carol McDonald (carol@gneissconcept.com).
10.2 The Beginner’s Guide to Quality Management Systems
The CEBOS Beginner Guide to QMS is designed to provide you with the knowledge, tools and resources you need to fully understand what quality management systems are and how they can help improve your business functions in its day-to-day operations. This guide also provides you with tools and resources that can help you learn how to successfully implement a QMS into your business.
Each chapter outlines an essential element to understanding the QMS along with resource links that provide you with more information. You are encouraged to follow the chapters in order and peruse each section’s resources to ensure you fully understand the QMS.
Chapter 1 – What is a Quality Management System and Why Does it Matter?
Chapter 3 – How Companies are Using Quality Management Systems Today to Improve Profitability
Chapter 4 – The Different Methods to Managing Quality
Chapter 5 – The Biggest QMS Obstacles and How to Avoid Them
Chapter 6 – How to Avoid Automating a Mess
Bonus Chapter – Our List of Practical Problem Tools
11. Some definitions to close on
11.1 Quality Management System
A quality management system (QMS) is defined as a formalized system that documents processes, procedures, and responsibilities for achieving quality policies and objectives. A QMS helps coordinate and direct an organization’s activities to meet customer and regulatory requirements and improve its effectiveness and efficiency on a continuous basis.
Source: American Society for Quality
11.2 Quality Assurance and Quality Control
Quality assurance (QA) and quality control (QC) are two terms that are often used interchangeably. Although similar, there are distinct differences between the two concepts. This page will explain the differences between quality control and quality management, and provide definitions and examples of each.
Source: American Society for Quality
11.3 Machine Learning
Machine learning (ML) is the study of computer algorithms that improve automatically through experience. It is seen as a subset of artificial intelligence. Machine learning algorithms build a mathematical model based on sample data, known as “training data”, in order to make predictions or decisions without being explicitly programmed to do so. Machine learning algorithms are used in a wide variety of applications, such as email filtering and computer vision, where it is difficult or not feasible to develop conventional algorithms to perform the needed tasks.
Machine learning is closely related to computational statistics, which focuses on making predictions using computers. The study of mathematical optimization delivers methods, theory and application domains to the field of machine learning. Data mining is a related field of study, focusing on exploratory data analysis through unsupervised learning. In its application across business problems, machine learning is also referred to as predictive analytics.
Source: Wikipedia
For more information on systems engineering related conferences and meetings, please go to our website.
12.1 Featured Conference
The featured event for this edition is:
Virtual INCOSE IS 2020
July 20th – 22nd, 2020
Outlined below are some of the benefits you will receive when you register to participate in our virtual INCOSE IS 2020 event.
You will be able to –
- Participate in real time in any of the sessions.
- Access recorded sessions should the time of the session not be suitable for you.
- Interact with the presenters through chat rooms and follow-up discussions.
- Hear first hand our keynote speakers. We will schedule these sessions at a time where we have the greatest opportunity to support the majority of participants to “watch live.”
- Witness the honors and awards bestowed on fellow members, colleagues, and champions of Systems Engineering
- Network across virtual social functions.
- Interact with exhibitors and sponsors through virtual exhibit halls and chat rooms.
- Receive a copy of the proceedings.
To address some operational aspects –
- The registration fee for INCOSE IS 2020, the virtual event, will be discounted from the original fee.
- The program schedule will be based on South Africa’s time zone, where we originally intended to host the INCOSE IS 2020.
- In the coming days, we will contact everyone with an accepted paper, panel, presentation or tutorial to manage the specifics. INCOSE plans to publish all accepted papers for INCOSE IS 2020, even if they are not delivered virtually, unless the author indicates otherwise.
- Exhibitors and sponsors will be contacted directly to work the details.
Access the full schedule here.
Register here.
12.2 Another Noteworthy Conference
The International Conference on Complex Systems (ICCS) Virtual Conference
The International Conference on Complex Systems is a unique interdisciplinary forum that unifies and bridges the traditional domains of science and a multitude of real world systems. Participants will contribute and be exposed to mind expanding concepts and methods from across the diverse field of complex systems science.
ICCS Topics: Unifying Themes in Complex Systems
Sessions will be structured around both themes and systems.
The themes are:
- Emergence
- Complexity & Information
- Dynamics & Self-Organization
- Structures & Networks
- Methodology
And the system categories are:
- Mathematical, Physical & Chemical Systems
- Bio-Molecular & Cellular Systems
- Physiological & Psychological Systems
- Organisms & Populations
- Human Social & Economic Systems
- Engineered Systems and Systems of Systems
Find out more about the conference here
Register for the conference here
13.1 Robert Halligan to Co-Present at the INCOSE Virtual International Symposium on 22 July
PPI Managing Director Robert Halligan FIE Aust CPEng IntPE(Aus) will co-present “Developing the PPI-INCOSE Systems Engineering Tools Database using a Systems Engineering Approach”, as invited content during Session Number: 9.1 on Wednesday, 22 July from 17:50-18:30 UTC+2 (16:50-17:30 Central European Time) of the 30th INCOSE International Symposium. The Systems Engineering Tools Database (SETDB) is a large and sophisticated database of software tools supporting systems engineering practices.
- Features of the SETDB include an advanced taxonomy enabling the SETDB user to find software tools:
- in areas of tool capability, using an advanced taxonomy for easy navigation to tools of interest
- of specific vendors
- that have application to each of the process elements used and taught by PPI: requirements analysis, physical design, logical design, effectiveness evaluation and decision (trade-off studies), specification of system elements, system integration, verification of work products, validation of work products, and systems engineering management
- that have application to each of the life cycle processes defined by the INCOSE Systems Engineering Handbook – A Guide for System Life Cycle Processes and Activities, Fourth Edition.
The SETDB is being co-developed by the two organizations as one initiative under a MOU between PPI and INCOSE to collaborate towards the advancement of systems engineering practice. Robert’s co-presenter will be INCOSE’s John Nallon, Chair of the INCOSE SE Tools Database Working Group. PPI’s René King and Obeo’s Stephane Lacrampeare Co-Chairs to John.
The INCOSE International Symposium is taking place as a virtual conference over 20-22 July. See https://www.incose.org/symp2020/home/when-where3
13.2 PPI Launches SysML MBSE Training
We are delighted to announce the addition of SysML training to our portfolio of training in support of SysML-based Model-Based Systems Engineering (MBSE). This training complements the substantial MBSE content of our systems engineering, Requirements Analysis and Architectural Design 5-day and shorter courses with in-depth coverage of SysML-based MBSE. The training is in 5-day, 3-day and bespoke versions. And even better news is that the training will be delivered by Dr. Darren Kelly, one of the world’s experts in SysML and former development leader for the SysML Plugin for MagicDraw UML.
Dr. Darren R C Kelly was originally trained as a radio-telescope scientist, astrophysicist, and nuclear scientist specialising in computer simulations of scientific instruments. He was introduced to UML at the DESY particle accelerator institute in Hamburg, Germany from 1995 to 1998, where UML was being used for particle accelerator modeling and beam simulation. Dr Kelly established Webel IT Australia in 2000 to promote advanced technologies for model-based and graphical software engineering, systems engineering, and real-time synthesis technologies.
From 2007 to 2009, Dr. Kelly headed development of the SysML Plugin for MagicDraw UML. He tracked compliance against the SysML specifications, and contributed to the SysML RTF working groups. He created the first models of the SysML specification’s HSUV sample problem in a real SysML tool. He created online SysML tutorials and hands-on SysML workshops (that were MagicDraw-centric). He also delivered internal training and authored MagicDraw’s first UML/SysML online eSchool .
Since 2009 Dr. Kelly has developed and delivered training courses and seminars in UML, SysML, and OCL. In 2011 he participated in the OMG Certified Systems Modeling Professional™ (OCSMP) certification trials. He was a SysML Revision Task Force (RTF) member and has tracked changes in SysML specifications from the inception of SysML until now.
Dr. Kelly is a member of the OMG SysML1.7 Revision Task Force (RTF), and is also now working on the Requirements Working Group for the SysML Submission Team (SST) for SysML2.
Dr. Kelly has had an association with PPI for many years, having developed and managed PPI’s Systems Engineering Goldmine online resources portal amongst other associations. Dr. Kelly has prepared material and examples that map SysML 1.x modeling to the foundation concepts and diagrams of MBSE that are taught in PPI’s 5-day Systems Engineering training, with some corresponding SE5D and SysML diagrams side-by-side. Dr. Kelly is also working long term on a SysML “mapping”/model of the INCOSE Systems Engineering Handbook.
First delivery of PPI’s new SysML offering will be in July 2020 to a US client of PPI in the medical devices sector.
13.3 PPI’s Randall Iliff Co-delivers INCOSE Webinar: Three Years Later – Building the Mindset for PM/SE Integration
Randall Iliff (PPI Principal Consultant and Trainer) participated in a webinar on 15 June 2020 at the Massachusetts Institute of Technology (MIT) (USA) with Research Associate and Lecturer, Eric Rebentisch concerning this critical need. Every Systems Engineer knows how critical the relationship with Program Management can be; too few have experienced the magic that occurs when Program Management and Systems Engineering are in sync. This webinar explores how organizations continue to build a “New Mindset” for success with today’s engineering program challenges.
Watch the webinar on YouTube via this link.
Join in on the discussion via INCOSE’s LinkedIn post
13.4 PPI Wins Large Systems Engineering USA Consulting Contract
PPI has been awarded a large contract to assist a North American client in the energy sector to introduce systems engineering throughout the organization. PPI USA Inc. President René King said of the award “We recognize that it is a sobering responsibility to meet the energy needs of the citizens and industry of a country, and that even the most apparently trivial details can be critical to reliability, safety and security of the infrastructure. Decades of work supporting clients operating at similar levels of criticality in aerospace, medical and commercial markets has taught us to respect the challenge, while contributing to the solution.”
13.5 Resumption by PPI of F2F Training
COVID-19 has turned the world upside down in many ways, but projects continue, new projects ramp up, engineers continue to engineer, managers continue manage, and the need for excellence in these pursuits is even greater than pre-COVID, if anything. Applying the principles of systems engineering to our business (of course), PPI, and its subsidiary company CTI, have navigated these rough waters, maintaining unbroken employment of all staff, whilst increasing the capacity to deliver outstanding value to their clients (see the piece about launch of PPI’s SysML training). A demonstration of Agile in the extreme!
Many PPI and CTI clients have experienced, with some surprise, just how effective our PPI Live-Online training and CTI Live-Online training are, with very little difference in learning between physical (F2F) and online delivery. Demand for F2F training of course remains. We expect very limited resumption of our F2F training in Europe in the July to September timeframe, limited expansion to some countries in Oceania and Asia over October to December, and stabilization towards of the new normal – a mixture of F2F, live-online and on-demand online training in the first half of 2021.
Thank you to all of our clients and alumni whose support has allowed us to survive COVID-19 unscathed. Loyalty is a two-way street; we pledge ourselves to even greater effort to increase further the difference between the value of our services to our clients, and their cost.
Take care, looking towards a post COVID era of justice for all, not a few at the expense of the rest of mankind, an era in which all human beings are treated with respect and afforded dignity.
Robert Halligan FIE Aust CPEng IntPE(Aus)
Managing Director
Project Performance International
13.6 WEBINAR Tutorial by Bijan Elahi:
Risk-Based Decision Making During COVID-19 Crisis
Most of our decisions are made with incomplete information, which leads to uncertainty and anxiety about the outcomes. Risk-based decision making is a rational, explainable and defensible way of making decisions. The knowledge you will gain is applicable to all areas of work and life.
In this webinar presented by PPI’s Medical Device and Risk Management expert, Bijan Elahi, you can expect to leave with an understanding of risk and how to avoid cognitive traps that lead to erroneous decisions. You will learn how to characterize your decisions based on risk and make intelligent trade-offs that lead to confident, explainable and defensible decisions. In this webinar, you will deepen your learning by applying the presented techniques to a current problem: Covid-19 and the critical decisions that our policy makers face.
Areas Covered in the Webinar:
- What is risk?
- Why humans are inherently terrible at-risk assessment
- How our brains perceive and process risk
- What factors have the greatest impact on risk perception?
- How to incorporate risk in your decision-making
- Risk-characterization of your decisions
- Establishing risk acceptance boundaries
- Risk/benefit analysis
- Example of risk-based decision-making applied to Covid-19
Watch this video to find out more about the webinar
Register for the webinar here.
13.7 Robert Halligan Raises a Pertinent Question on LinkedIn:
Systems Engineer, or Systems Engineering?
Editor’s Note: On the 13th of June 2020, PPI’s Managing Director published an article about the concept of systems engineers versus systems engineering. This topic has received much attention in just a few days of its posting.
From LinkedIn:
Bethany Smythe asked me recently for a view on why the candidate pool of Systems Engineers in the market appears to be so tight – particularly SEs with in-depth hardware and software backgrounds.
My reply started with the premise that engineers who are educated in systems engineering (SE) and practice engineering using a SE approach perform much better than those who don’t. So they are eminently employable. The demand is there but the supply is limited (mainly because of our flawed engineering education systems). Hence the scarcity.
I went on to observe that, personally, I rarely use the term “systems engineer”, but I have lived and breathed SE 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). SE is not something different to engineering in general; it is a way of practicing engineering in general. The variables are the scope of the task, and degree of SE formality that is appropriate to that scope.
I am not alone in my view. 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 give to systems engineering:
Type 1 is a “stovepiped” industry, where the executive power is in the hands of single-discipline engineering empires. Systems engineering is recognized 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, and the career prospects are limited. I can relate to Type 1 easily, having had many engineers but few managers from “Type 1” organizations on my SE 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 chief engineers on all projects are recognized experts in the integrative discipline. Indeed, single-discipline engineers are allocated to projects, to have their work directed by the cross-discipline “systems engineers”; and SE is seen as a desirable career aspiration.
Paul observes that there are gradations in between, and one of the goals of a prospective employee, at interview and by background research, is to ascertain where on the continuum his or her prospective employer lies. And thereby hangs a key to the original question: a prospective employee will want to work for a Type 2 company, not for Type 1. Paul sees Defence employers as typically further towards Type 2; the construction and energy sectors tending to be towards Type 1. Which is why Type 1 organizations find it hard to recruit SEs.
I share Paul’s views in the sense of Type 1 and Type 2 organizations being common, but I add a Type 3 organization, where engineers work mainly in multidisciplinary teams, making the more important decisions collaboratively, creating a learning environment in which engineers may start single-discipline, but evolve to become multi-disciplinary, usually whilst 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, everything else being equal. But engineers at any point on this journey can be, should be, and often are practicing systems engineering. The leaders in sectors that develop complex products in competitive markets 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 apply to all of these engineered systems; the benefits accrue accordingly. We can agree, however, that the more complex a system is, the more risk there is due to that complexity, and the more valuable systems engineering practices become. We can also agree that, everything else being equal, the greater the diversity of technologies involved, the more complex a system solution is likely to be.
All of this shows up well in the excellent SEI/AESS/NDIA study “The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey”, CMU/SEI-2012-SR-009, November 2012. That study also looked at the proportion of projects that implemented systems engineering as described by Paul as Type 2, versus “systems engineering to be practiced by all engineers”. The study concluded that the percentages were roughly equal, and the project performances were not different to a statistically significant degree.
That conclusion would seem to suggest that my advocacy of “systems engineering to be practiced by all engineers” is neither supported nor negated by the data. But there is more to it than that, not investigated by 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. With a good implementation of SE involving amongst other things genuinely expert leadership, SE champions and SE focus groups, substantial growth of SE competence towards a “way of life” level occurs over time.
Sadly, training a small group of SE leaders and having them try to influence the work of others remains a lot cheaper than training a whole engineering workforce, notwithstanding the high return on investment (ROI) from doing the latter.
Only when SE appears in all undergraduate engineering degrees will the need to train an engineering workforce in systems engineering disappear. I see such initiatives appearing more frequently, and I am involved in some of them.
I have on my do-list a paper for my company’s systems engineering newsletter PPI SyEN, titled “Systems Engineers or Systems Engineering”, the content of which is already in my head. The paper will start with the principles of systems engineering, show that 13 out of the 14 main principles apply to the engineering of anything from a dollar coin to a new model commercial aircraft or the country of Singapore, and then we will look at ROI .
What do you think, systems engineers as a separate species, or systems engineering as a ubiquitous practice?
Join in on the conversation here
For a full public PPI Live-Online™ training course schedule, please visit 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/
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/
15. Upcoming PPI Participation in Professional Conferences
PPI will be participating physically in the following upcoming events. We support the events that we are sponsoring, and look forward to meeting old friends and making new friends at the events at which we will be exhibiting.
The INCOSE International Workshop 2021
Date: 29 – 31 January, 2021
Location: Seville, Spain
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com
Ralph Young, Editor, email: ryoung@ppi-int.com
René King, Managing Editor, email: rking@ppi-int.com
Project Performance International
2 Parkgate Drive, Ringwood, Vic 3134 Australia
Tel: +61 3 9876 7345
Tel Brasil: +55 12 9 9780 3490 (Breno Bacci)
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.
