In This Edition
1. Quotations to Open On
2. Feature Article
2.1 Examining Organizational Culture for Enabling Effective Systems Engineering by Nicole Hutchison
3. Additional Articles
3.1 Complex Systems Working Group Update – Complex Systems Exemplars
3.2 Hands, Head, and Heart – Mastering the Three Critical Domains of PM-SE Integration by Randall C. Iliff
4. Systems Engineering News
4.1 INCOSE Working Group Information Is Available
4.2 Model-based Project Engineering (MPE)
4.3 Researchers will Explore Understanding of Complex Systems among Engineering Students and Professionals
4.4 The Need for Systems Engineering in K-12 Schools V-Model Approach to K-12 Learning
4.5 European Journal of Sustainable Development Call for Papers
5. Featured Organization
5.1 IISE/INCOSE University of Arizona Student Chapter
5.2 UCL Centre for Systems Engineering (UCLse)
6. News on Software Tools Supporting Systems Engineering
6.1 IDAES Process Systems Engineering Software Now Open Source
7. Systems Engineering Publications
7.1 Engineers’ Practical Databook: A Technical Reference Guide for Students and Professionals
7.2 System Architecture: Strategy and Product Development for Complex Systems
7.3 The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment
7.4 Design Teams: Requirements Management and Product Complexity
7.5 Parametric Cost and Schedule Modeling for Early Technology Development
8. Education and Academia
8.1 Industrial and Systems Engineering Department at the Cape Peninsula University of Technology
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
10.1 SAE1001 Integrated Project Processes for Engineering a System
11. Some Definitions to Close On
11.1 Context Analysis
11.2 Building Information Modelling (BIM)
12. Conferences and Meetings
12.1 The featured event for this edition is: CS IEEE 2nd International Conference on Industrial Cyber-Physical Systems
13. PPI and CTI News
14. PPI and CTI Events
15. PPI Upcoming Participation in Professional Conferences
1. Quotations to Open On
“Designing a solution doesn’t change the problem.”
Robert John Halligan
“Collaboration is a voyage from the known to the unknown, with people of common commitment, who both steer and follow.”
Donald Staff
“I think the teaching profession contributes more to the future of our society than any other single profession.”
John Wooden
2. Feature Article
2.1 Examining Organizational Culture for Enabling Effective
Systems Engineering
by
Nicole Hutchison
Email: nicole.hutchison@stevens.edu
Systems Engineering Research Center, Stevens Institute of Technology
Copyright © 2019 by Nicole Hutchison. All rights reserved.
Abstract
The Helix project, launched in 2012, is a longitudinal study that originally focused on understanding what makes individual systems engineers effective. As the project has grown and matured, this focus has shifted to include what makes organizations effective at systems engineering. The Helix dataset – which includes information from over 450 individuals across 29 organizations in both the US and the Netherlands – has been used to inform critical research findings. This data highlighted the critical importance of organizational culture in either inhibiting or fostering systems engineering. This article provides an overview of two cultural assessment approaches – the Competing Values Framework (CVF) and the Quality of Interaction Index (Qi Index) – and what the team has found to date using these tools.
- Introduction
The Helix Project (called ‘Helix’ throughout this article) is a multi-year research project that was initiated in 2012 by the US Department of Defense (DoD) at the Systems Engineering Research Center (SERC), to understand and define what makes systems engineers effective and the role of organizations in improving effectiveness. The major findings and products of the project were published in The Paradoxical Mindset of Systems Engineers, a book designed and written for use by individual systems engineers, managers of systems engineers, organizations that employ systems engineers, and other engineers and managers who perform some kind of systems engineering activity (Pyster et al, 2018).
- Atlas Overview
The findings concerning what makes systems engineers effective are summarized, at a high level, in Figure 1 (Hutchison et al. 2019). Read from upper left to lower right; the main message is that an individual systems engineer is effective when he or she delivers consistent value.
Figure 1: Relationship between Helix and Atlas (Hutchison et al., 2019)
The critical values that systems engineers provide include (Hutchison et al., 2018):
- Keeping and maintaining the system vision;
- Translating technical jargon into business or operational terms and vice versa;
- Enabling diverse teams to successfully develop systems;
- Managing emergence in both the project and the system;
- Enabling good technical decisions at the system level; and
- Supporting the business case for the system.
To fulfill these roles, critical knowledge, skills, abilities, behaviors, and cognitions – what we call “proficiencies”, are required. Atlas provides a tailorable proficiency model for assessing these systems engineering skillsets. There are three main forces that enable systems engineers to build these skills: experiences, mentoring, and education and training. Patterns in these forces over time provide insights in the career paths of systems engineers (Pyster et al. 2018). In addition to the skillsets required for systems engineers to be effective, there were critical personal characteristics that also better enabled systems engineers to grow, such as self-awareness and inquisitiveness.
All of these aspects about an individual systems engineer occur in a context of the organization in which he or she works. The organizational context is critical to the effectiveness of systems engineers. Organizations pair individuals with the roles and responsibilities identified in positions, set expectations for the proficiencies required for a given position and the values that position should provide, and help determine how to grow their systems engineering workforce.
Likewise, the characteristics of organizations also impact a systems engineer’s ability to be effective. Organizations that have an unclear definition of what systems engineering is or that do not value or reward systems engineering activities tend to make it more difficult for systems engineers to provide the values listed above. In addition, the culture of an organization, and how systems engineers are expected to integrate into it, are critical.
- Helix Evolution
With all of the insights developed concerning systems engineers as individuals through Atlas, in 2017, the Helix team, believing we had understood the elements that make systems engineers effective reasonably well, turned our focus to understanding what makes an organization successful at systems engineering. The primary research questions concerning effectiveness include:
- How can organizations improve the effectiveness of their systems engineering workforce?
- Why: How does the effectiveness of the systems engineering workforce impact the overall ability of an organization to successfully deploy increasingly complex systems and solutions (i.e., to have an effective systems engineering capability)?
- What: What critical factors, in addition to individual workforce effectiveness, are required to enable systems engineering capability? Factors include tools, practices, processes, policies and culture. Engineering is a social event, so the means of aggregating individual capabilities is critical.
- How: How do the variables that impact systems engineering effectiveness need to shift to enable different systems engineering approaches? Given a specific situation, how can one evolve to a preferred operational outcome? This is not starting point independent.
Primary data for this study was collected through in-depth interviews. To date, over 450 individuals have participated in Helix, 92% of whom are systems engineers and 8% of whom work directly with systems engineers in some capacity. These individuals come from organizations that recognize the importance of systems engineering as a discipline – whether they call it systems engineering, systems architecture, product engineering, or some other term. About a third of the individuals worked for government organizations at the time of their interviews, 10% at Federally-Funded Research and Development Centers (FFRDCs) in the US, and the rest were from commercial industry. To date, 29 organizations have participated, 24 in the US and 5 in the Netherlands; 45% of these organizations are in the defense space, with the rest being distributed across aerospace, healthcare, telecommunications, transportation, IT, and high tech organizations.
To improve the focus on organizational characteristics, we have also launched a survey, the preliminary results of which are incorporated below.
- Critical Organizational Characteristics
Atlas defines some organizational characteristics that can enable or inhibit systems engineers – and by extension systems engineering. In the current research, we have expanded these initial items to include:
- Culture – and specifically how systems engineers are expected to integrate into the culture, including their roles in multidisciplinary teams;
- Governance – specifically, how systems engineering is governed, including the processes, policies, formal roles and responsibilities expected of systems engineers, and the career paths of systems engineers; and
- Structure – how systems engineers are identified and integrated into the organization as well as the organizational infrastructure to support systems engineering, including tools and methods.
To understand these aspects of systems engineering organizations, we have leveraged some existing frameworks. In particular, we are using a tool called the Competing Values Framework (CVF) (Cameron and Quinn 2011) and the Qi Index (Reynolds and Lewis 2017). The CVF has been used by hundreds of organizations over two decades to understand and describe key cultural attributes that relate to overall organization success. Figure 2 shows the key dimensions and brief descriptions of the CVF, which include the clan, adhocracy, hierarchy, and market cultures (Cameron and Quinn 2011). The four different cultures described in the CVF classify organizations based on the orientation, leadership type, values, and the theory of effectiveness within the organizations.
The CVF is incorporated with permission in the surveys developed by the Helix team to investigate the culture types and how it impacts the organization’s ability to deliver systems engineering capabilities. Importantly, there is no one right type of culture to support systems engineering – the type of organization, vision, and the type of systems engineering work being performed all need to be appropriately aligned with the culture. It is important to note that this is not an “either/or” framework, where an organization can possess only one of these cultural types. Instead, it results in a profile showing the strongest and weakest cultural types in the organization.
Figure 2: Competing Values Framework adapted from Cameron and Quinn (2011) (Hutchison et al. 2019)
Figure 3 provides an example of what these profiles can look like. In this example, anonymized[1] from a high-tech company in the Netherlands, the cultural types are currently seen as relatively balanced both systems engineers and those who work with system engineers (labeled as “peers). An additional benefit of the Organizational Culture Assessment Instrument (OCAI) approach is that it also asks the same individuals how they believe the organization needs to change in the future to be successful. Again, in Figure 3, it is clear that systems engineers and their peers believe that to be successful, Example Organization A needs to move away from hierarchy and more towards adhocracy. (This is discussed further below.)
Figure 3: Anonymized Competing Values Framework Profile for “Example Organization A”
Likewise, the Qi Index is a culture assessment method that focuses on organization behaviors, emotions, and cultural traits that are associated with the ability to adapt and innovate (Reynolds and Lewis 2017). The Qi Index was built using data from over 100 organizations across twenty-five industries and 20 countries. It focuses on two key factors: cognitive diversity and psychological safety, which relate to organization adaptability and innovation. The Qi Index is assessed using 18 Likert-style[2] statements and three additional questions to assess 1) how individuals feel about the organization, 2) the behaviors they see in their organization, and 3) the current state of the organization. These results are used to create a profile of the organization that identifies the behaviors that do or do not support an organization’s generative capabilities –ideas, processes and learning, and which behaviors undermine or hinder innovation.
At a U.S. House of Representatives hearing “Promoting DOD’s Culture of Innovation” in 2018, Dr. Michael Griffin, currently the U.S. Undersecretary of Defense for Research and Engineering, argued that the increasingly global R&D landscape requires the DOD to place a premium on the speed at which it can develop and field new capabilities. (Ambrose 2018). The Helix team chose the Qi Index in part because it specifically incorporates assessment of teaming that fosters or inhibits innovation to facilitate the understanding of the systems engineering culture within the organization. The results of the Qi Index describe the predominant workforce behaviors and the level of agreement or alignment among employees.
- Initial Insights on Culture
The Helix team is still collecting data, but to date the biggest take away is that there is no one type of culture that fosters effectiveness in systems engineering. Instead, the type of systems engineering, the products and services, and the focus of the organization all need to be aligned. For example, in an organization that is doing what we’ll term “traditional acquisition” systems engineering for brevity – large-scale systems engineering efforts in an acquisition context that tend to be fairly heavy in process – a hierarchical culture is common. In this context “hierarchy” is a synonym for “control”. The hierarchical organization has a very formal structure and processes, which can be quite rigid. Leaders in hierarchical organizations tend to be valued for their organizational skills and they focus heavily on stability and efficiency. Organizations that have a focus on innovation, advancing the state of the art in technology tend to be less strong in “hierarchy”, though there is not a single trend so far as to whether clan, adhocracy, or market-driven cultures are best suited to innovation.
The types of systems engineering that can be effective – the overarching processes, methods, and approaches – are also inextricably linked with culture. For example, in Example Organization B, initial work on a major project was intended to be agile and, in the beginning, the organization’s dominant cultural characteristic was “adhocracy” – focus on being innovative and pioneering. The organization provided structure not through formal management chains, but much more through a consistent and exciting vision that guided a diverse team of engineers, military operators, policy makers, and even artists. The organization focused on rapid progress and developing new technologies to meet critical challenges. However, over time the organization became much more hierarchically-oriented and lost much of the flexibility that had formerly enabled innovation, thus stalling progress on several fronts.
In the Netherlands, the “clan” culture – a focus on an organization as “family”, teamwork, commitment, participation, and the value of individuals as team members – is quite strong. We were often told during interviews across an organization that this “is just Dutch culture”. However, in a defense-focused organization in the Netherlands, this was much less strong than in high-tech organizations. In fact, in the defense-focused Netherlands organization, the hierarchy characteristic was more prevalent – much more analogous to what we have seen in the U.S. And in this organization, the CVF results clearly showed that systems engineers and their peers agreed that to be successful, the organization must become somewhat less hierarchically focused and instead improve their focus on adhocracy, specifically enabling innovation. They similarly stated that their systems engineering processes – the traditional “Vee” model – were too rigid and some flexibility or tailorability needs to be incorporated to enable innovation. An overview of CVF profiles for the Netherlands organizations can be found in Figure 4. Clearly, though there is a strong national culture, there is still a great variety of organizations within that culture.
Figure 4: Overview Profiles of Netherlands Organizations in the Helix Sample
- What Does This Mean for Workforce Development?
Is it clear, then, that only one type of culture supports systems engineers? Not at all. The most important finding for workforce development so far is that an organization has to first understand and acknowledge its culture before it can help systems engineers learn how to work within it. For example, individuals who work in more innovative environments will find training programs that focus on rigid approaches to systems engineering – formal processes with no discussion on tailoring and adaptation – to be of little use. In fact, some individuals have reported that trying to use these formal approaches in a more adhocracy-focused culture can be seen as a major drawback. Likewise in a clan culture, lack of flexibility can be seen as not being a team player – something very valued in clans. In contrast, hierarchical organizations that teach their systems engineers about agile approaches, flexibility, and innovation can find that these programs backfire. Individuals try to implement these approaches that are counter-cultural and are seen as disruptive by peers. And the systems engineers themselves report struggling with wanting to use these approaches to drive innovation and being very frustrated with organizational rigidity.
The CVF provides a fairly easy to use and data-driven way to assess organizational culture – both today and as desired in future. This can become a critical input for training and career path development for systems engineers. The information on current culture can help an organization understand what interventions – training, education, mentoring, apprenticeships, etc. – might help systems engineers be more effective in their current organizational context. Likewise, the desired future culture information can help identify key gaps – for example, are systems engineers worried that the organization cannot keep pace with change? Do they believe they need more structure to move forward? And, importantly, do their peers, managers, and leaders agree with the desired changes. Workforce development cannot ensure that each of these things align – but understanding misalignments can help identify gaps and address them.
- Conclusions
Workforce development approaches that do not adequately reflect the organizational culture, governance, and structure are not likely to result in effective employees; this is particularly true of systems engineers. With a better understanding of culture paired with how systems engineering is expected to support strategy and operational goals, organizations can build more tailored workforce development programs. The CVF and the Qi Index are tools that can support building a consistent understanding of organizational culture and its role in supporting systems engineering. Likewise, these tools can help identify gaps in how systems engineering can work within, and help to evolve, organizational culture.
Acronyms
CVF Competing Values Framework
DoD US Department of Defense
FFRDC Federally Funded Research and Development Center
OCAI Organizational Culture Assessment Instrument
Qi Index Quality of Interaction Index
SERC Systems Engineering Research Center
References
Ambrose, M. 2018. “New DOD R&D Chief Outlines Vision for Jumpstarting Military Innovation.” FYI: Science Policy News Bulletin. Melville, NY: American Institute of Physics. 25 April 2018. https://www.aip.org/fyi/2018/new-dod-rd-chief-outlines-vision-jumpstarting-military-innovation
Cameron, K. S. and Quinn, R.E. 2011. Diagnosing and changing organization culture based on the competing values framework. Third Edition. San Francisco, CA. Jossey-Bass.
Hutchison, N., D. Verma, P. Burke, M. Clifford, R. Giffin, S. Luna, M. Partacz. 2018. Atlas 1.1: An Updated to the Theory of Effective Systems Engineers. Hoboken, NJ: Systems Engineering Research Center, Stevens Institute of Technology. SERC-2018-TR-101-A. 16 January 2018.
Hutchison, N., D. Verma, P. Burke, R. Giffin, S. Luna, D. Makwana, S. Kothari, B. Salgado, H.Y. See Tao, S. Soneji, A. Zavala. 2019. Helix: Developing an Understanding of Organizational Systems Engineering Effectiveness. Systems Engineering Research Center, Stevens Institute of Technology. SERC-2019-TR-001. February 28, 2019
Pyster, A., N. Hutchison, D. Henry. 2018. The Paradoxical Mindset of Systems Engineers: Uncommon Minds, Skills, and Careers. Hoboken: Wiley.
Reynolds, A. and Lewis, D. (2017). Teams solve problems faster when they are more cognitively diverse. Harvard Business Review, March 30, 2017. https://hbr.org/2017/03/teams-solve-problems-faster-when-theyre-more-cognitively-diverse
Acknowledgements
Dr. Art Pyster and Deva Henry co-authored The Paradoxical Mindset of Systems Engineers, which highlights the initial work on the importance of organizational culture. The current Helix team is continuing this investigation, and I would like to thank the current research team: Dr. Pamela Burke, Mr. Ralph Giffin, Dr. Yan See Tao, Dr. Dinesh Verma, Mr. Sergio Luna, Mr. Deep Mawakana, Ms. Araceli Zavala, Ms. Shikha Soneji, and Ms. Suchita Kothari. Pam and Ralph, in particular, have been critically important in guiding our analysis and insights concerning organizational culture.
About the Author
Dr. Nicole Hutchison is currently the Chief of Staff of the Systems Engineering Research Center (SERC) as well as the Principal Investigator for the Helix project. Additional research interests of Dr. Hutchison have included the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE), which resulted in the Systems Engineering Body of Knowledge (SEBoK), and projects on systems engineering technical leadership and mission engineering. Before coming to Stevens, Dr. Hutchison worked for Analytic Services Inc. as an analyst, working primarily on public health, biodefense, and full-scale disaster responses exercises for the US Departments of Defense, Homeland Security, and Health and Human Services. Dr. Hutchison holds an MS in Biohazardous Threat Agents and Emerging Infectious Disease from Georgetown University and a PhD in systems engineering from the Stevens Institute of Technology.
3. Additional Articles
3.1 Complex Systems Working Group Update – Complex Systems Exemplars
The INCOSE Complex Systems Working Group focuses on the challenges and opportunities presented by systems with rich interdependence among diverse components, non-linearity, open systems boundaries, networks of causality and influence (vice linear causal chains), emergence, varied and changing system goals, self-organization, and multi-level adaptation. These traits, increasingly the norm and not the exception, limit the utility of traditional systems engineering paradigms, which are generally centralized, goal oriented, requirements driven, and reductionist in approach. Complexity is a characteristic of more than just the technical system – the socio-technical ecosystem in which a system under development will be employed exhibits these attributes, as does the environment that gave rise to the challenge or opportunity to which the system was developed in response. Further, the design and development of technical systems is a complex endeavor itself. It is critical for systems engineers to understand the nature of the systems with which they are working, and of which they are a part, to be effective. The goals of the Complex Systems Working Group are to communicate complexity characteristics to systems engineering practitioners, provide knowledge and expertise on complex systems in support of other INCOSE working groups working in their systems engineering areas, facilitate the identification of tools and techniques to apply in the engineering of complex systems, and provide a map of the current, diverse literature on complex systems to those interested in gaining an understanding of complexity.
During the past year, the Complex Systems Working Group (CxSWG) has engaged in a collaborative effort to enhance understanding and dialog about what constitutes a complex system. To answer this question, the CxSWG formed a team to consider various systems as exemplars of simple, complicated, and complex systems and characterize how complexity manifests (or does not manifest) in each. The team assessed the U.S. Army steel pot helmet, the Shin Kansen bullet train, a space launch vehicle, a radar system, and an artificial intelligence-enabled satellite scheduler.
The team led by Dr. Michael Watson (NASA-Marshall Space Flight Center) began by developing definitions for each of the characteristics of complex systems identified in the INCOSE Complexity Primer for Systems Engineers. The team applied Appreciative Inquiry to assess these characteristics across the selected set of illustrative systems, which range from seemingly simple systems to complicated systems to complex systems. The results of the assessment were surprising, showing that complexity is not a simple ‘yes’ or ‘no’ binary. There are several confounding factors which can lead to complexity-related phenomena, including the application environment, social interaction with the systems, and the application of artificial intelligence. Systems have several different simultaneous valid perspectives and were found to be complicated from some perspectives and complex from others. Different tiers of complexity were identified as a result of the assessment. The effort also identified topics on managing complexity and the integrating system perspective that represent new directions for the engineering of complex systems. The Appreciative Inquiry approach provided a method for systems engineering practitioners to more readily identify complexity when they encounter it, and to deal more effectively with this complexity once it has been identified.
There are several new directions indicated in the process of defining the complex systems characteristics and assessing the complex systems. The CxSWG is planning to update the Complexity Primer for Systems Engineering with the complex systems characteristics definitions. The concept of complexity tiers observed in the assessment of the examples is a fruitful concept that may help explain sometimes-divergent opinions on what is or is not complex. In addition, there are subcategories of complexity indicated in the assessment of the systems in the paper which should be further defined, including ideas such as managed complexity, constrained complexity, expected or unexpected emergence, social application complexity, operational complexity, and others. Some of these topics may be related and research is needed to define these subcategories more clearly and what constitutes a complicated or complex system when there is a large mix of complicated and complex system characteristics. Also, research into the benefits which have been obtained from different systems engineering techniques when faced with complexity of a system or its confounding factors on each individual characteristic may yield useful guidance for dealing with complexity. The team’s findings will be published and presented at the 2019 INCOSE International Symposium in Orlando, FL, USA.
The Complex Systems Working Group co-chairs are Dr. Jimmie McEver and Dr. Michael Watson. Dr. McEver is the Program Manager for Cyber Capability Integration and a Principal Scientist at the Johns Hopkins University Applied Physics Laboratory. Dr. Watson is a practicing systems engineer at the NASA Marshall Space Flight Center. To learn more or inquire about participation in this working group, you can email the working group at cxswg@incose.org.
Integrating Program Management and Systems Engineering
3.2 Hands, Head, and Heart – Mastering the Three Critical Domains
of PM-SE Integration
by
Randall C. Iliff
Principal Consultant, Project Performance International
Email: riliff@ppi-int.com
Copyright © 2019 by Randall C. Iliff. All rights reserved.
Abstract
This is the first article in a five-part series devoted to the integration of Program Management (PM) and Systems Engineering (SE) conduct. In this series we share why PM and SE are both necessary on any development effort; make a case for integration as a very attractive investment opportunity; and propose an Integration Competency Index derived from the multiplicative product of skills in three primary dimensions of integration.
This installment sets up the discussion and introduces three dimensions we’ll call Hands, Head, and Heart. We also introduce the concept of an Integration Competency Index that can be used to assess program performance and identify opportunity for improvement.
The next three articles in the series discuss the Hands, Head, and Heart integration dimensions respectively, the final installment wraps it all up with information about the Integration Competency Index and a call to action.
Introduction
Engineering programs have created wealth, power, and societal consequences – good and bad – for thousands of years. Every region of the world can point to spectacular accomplishments throughout history. Civilization as we know it today can be attributed in large part to the cumulative history of those engineering programs.
Ironically, our collective survival has now become dependent upon the ability to successfully conduct engineering programs in response to increasingly complex societal needs brought on by prior engineering programs. The impact of failure is measured in lives as well as cost and schedule. Even when people are not directly harmed, wasting scarce resources imposes an inevitable penalty somewhere else.
When engineering and execution align effectively, great things can happen. When they don’t, the consequences can be catastrophic.
You may not think of Pixar as being in the engineering program business but consider this quote from Co-Founder and President Ed Catmull: “Most of our people have learned that it isn’t helpful to ask for absolute clarity. They know absolute clarity is damaging because it means that we aren’t responding to problems and that we will stop short of excellence. They also don’t want chaos; if it gets too messy, they can’t do their jobs.”1
Any System Engineer or Program Manager will immediately recognize the delicate balance involved in moving ideas towards reality. At first the idea exists by itself. To go anywhere, that idea needs execution. Execution requires direction, which in turn requires reduction of the original idea in some way towards specific practice.
Catmull’s comment nicely highlights the balance required for success – enough creative room to address genuine development needs and respond to issues, and enough structure that efficient progress can be made towards an intended outcome. By tying both to the single objective of delivering an excellent result, not the narrow and occasionally conflicting objectives of each area, the effectiveness of the overall program remains the measure of success.
What happens though when unproductive tension is present, or when these two critical functions are not operating in ways that match the actual needs of the task? Perhaps the most vivid example is that of the NASA Challenger and Columbia accidents.
Diane Vaughan writes in her book concerning the 1986 Challenger disaster: “According to the research of Romzek and Dubnick, during Apollo the space agency relied on professional accountability: control over organizational activity rested with the employees with technical expertise.”2 “During the Apollo era, according to space analyst Howard McCurdy, NASA had a “pure” technical culture appropriate for the engineering of unruly technical systems.”3 In the 1970s that culture began to shift, partly in response to declining budgets and changes in the view of government/contractor relationships, to a much more structured and bureaucratic one.
“Top NASA managers were absorbed with “myth managing”: attaining legitimacy (and thus resources) by projecting and living up to a cultural image of routine, economical spaceflight.”4 “And at the bottom of the launch decision chain, working engineers were making risk assessments in a transformed NASA culture in which bureaucratic rules and procedures were a major preoccupation; and cost, efficiency, and production deadlines were a taken-for-granted aspect of work.”5 “Project Managers and engineers alike were burdened with the procedural and paperwork demands of central clearance as they responded to the organization’s burgeoning nontechnical administrative apparatus.”6
The Challenger accident, and later the loss of Columbia, arose from a complex set of technical, social, and political circumstances, but an unmistakable sub-context to both is that the methods in use no longer were aligned to task reality. Two inexorably tied roles, project management and engineering, had been driven further and further apart by the movement towards bureaucracy.
Despite enormous success during the Apollo era, the NASA culture was gradually changed into one where cost and schedule were no longer subordinated to safety. That such a loss can occur in one of history’s preeminent intellectual bodies is clear warning that no company, market, or body should feel safe. It is far easier to disrupt an effective model like NASA or Pixar than it is to establish and protect one.
Integration as Investment
Clearly there is enormous untapped opportunity to improve the outcome, efficiency, and predictability of engineering programs. Further, this opportunity can be found anywhere development is required as part of the effort, regardless of market, region, or scale. Most of the insight needed to capitalize on this opportunity already exists, there are emerging pockets of excellence that demonstrate what is possible, yet most engineering programs struggle with avoidable issues.
That represents a stunning level of untapped opportunity, given that the ability to consistently deliver engineering program success has never been more vital. As a result, the integration of Program Management (PM) and Systems Engineering (SE) effort may well be the most attractive investment available to your organization.
When the definition (SE) and execution (PM) roles are aligned, the results can be orders of magnitude more effective than when the groups are in tension with each other. Even seemingly minor improvements to cost and cycle time during development are a good thing, particularly when that result is coupled with improved technical quality and reduced risk.
Let’s be honest here – this attractive opportunity isn’t free money, or something created as a result of integration.
The benefit arises instead from the simple act of repairing a fundamental defect in the development approach. When PM and SE are not operating as a single “system of systems” team, the cognitive disorder that results will inevitably harm the effort, and in some cases rises to a level that causes the effort to fail outright. PM-SE Integration savings result from the money and time that are no longer thrown away fighting self-inflicted issues.
That’s an important realization, since it means that unless you already have a well-integrated PM and SE team, you are currently paying a hidden penalty on all of your development effort. Once you realize that you are already paying, over and over again, the wisdom of investing in a solution becomes self-evident.
Three Domains
For this discussion we’ll slice the overall PM-SE integration task into three dimensions, each of which has a different set of needs and characteristics to manage. The terms “Hands, Head, and Heart” offer an easy way to remember the nature of, and distinctions between, these dimensions.
First, all development effort has at least some subset of “just do it” tasks that are well understood and simply a matter of executing efficiently. There is no upside to everyone reporting travel expenses in a different way, just pick something, standardize it, and refine it over time. Likewise, stressing over a standard 12-volt power supply has little upside value. These tasks require only supervision, and integrate the “Hands” of the organization.
Second, by definition all development effort has at least some subset of “figure out what to do” tasks. These tasks engage the “Head” and require management. For effort in this domain people aren’t told what to do and how to do it, instead they must be given an objective and the resources needed to reach that objective.
Our final dimension, “Heart” speaks to the alignment of motivations. It’s not enough to simply agree on tasks, there must be a common passion if your development effort is going to achieve great things. Since all of these dimensions interact as a single system, it is the multiplicative product of skill in each of these (not the sum!) that determines the organization’s degree of integration excellence.
It’s Time to Demand Better Development Results
We don’t think properly of the true potential that development excellence offers. It’s hard to imagine what development excellence looks like if you haven’t really seen it before. An excellent development project isn’t necessarily one with the lowest cost design cycle, nor the fastest one, nor the one that spins off the most intellectual property.
Like most systems, there is a composite figure of merit involving many competing dimensions of “success” that must be considered if comparisons are to have meaning. For this discussion excellence is defined as a function of Hands, Head, and Heart. For lack of a better term, I’ve called the resulting figure of merit for PM-SE integration an Integration Competency Index.
The Innovation Index doesn’t run from zero to thirty. Instead, when each of the three task dimensions we’ve mentioned is scored on a zero to ten basis and multiplied the best possible Integration Index score is 1,000. Using the multiplicative product scoring approach, a low score in even one category will immediately be seen as causing major damage to the entire development system. As an example, a ten on hands and head combined with only a two on heart gives a score of 200, implying that 80% of the value has been lost. (Adding the scores would result in 22 out of 30, implying a much less critical 25% loss.)
This balancing act among dependent variables explains why simple start-up companies appear to operate so efficiently at first and then fade. They bring strength in Heart and Mind that overcomes inefficiency of Hands (for a while), then fall prey to the increasing scale of effort that is required. This also explains why large, well-funded operations fail to deliver against potential. No amount of efficiency makes up for consistently doing the wrong things for the wrong reasons.
What is less obvious, however, is why such enormous opportunity has gone untapped for such an extended period of time. Regardless of the reasons, the resulting potential energy has built up to a point where industry change will propagate rapidly once benefit has been compellingly demonstrated.
The world of production has matured to the point where we expect perfection and come very close to achieving that level in practice. Who today would accept 5% rework on a production line?
The world of development is also maturing, but that maturity profile lags production by decades. Perfection in development cannot arise from absolute repeatability of output, instead it arises from the ability to repeatably identify an ideal solution to any problem set. No one ever quite reaches perfection, but it’s clear that there is a lot more room for improvement in the development arena!
Who tomorrow will be willing to burden their organization with only a 200 out of 1,000 Integration Competency Index?
What’s Next?
In the next installment we’ll focus on the Hands dimension. This is the simplest of the three domains, and each of these actions have a specific “ideal outcome” from which variance can be assessed and managed. Once rules are established – and known to all – independent supervision within each group is usually sufficient to ensure consistency. This dimension offers a good place to start making improvements, and we’ll share some ideas in the next installment that you may find useful.
Following that installment, we’ll address Head, then Heart. In the final segment, we’ll provide more information concerning how the Integration Competency Index is determined and how that information can help your organization optimize the return on integration investments!
List of Acronyms Used in this Paper
PM Program Management
SE Systems Engineering
Acknowledgements
The idea of “hands, head, and heart” originated in classroom conversations about the distinction between supervision, management, and leadership. During a course in Hong Kong many years ago, a student commented that her supervisors just talk to her hands, whereas a leader talks to her heart. That struck me as a profound observation worth sharing, and the idea of managers focusing on the mind arose as a natural extension of that evolving conversation.
Reference
McKinsey Quarterly Interview, March 2016, Staying one step ahead at Pixar: An interview with Ed Catmull
2 Vaughan, Challenger Launch Decision, p. 211
3 Vaughan, Challenger Launch Decision, p. 209
4 Vaughan, Challenger Launch Decision, p. 212
5 Vaughan, Challenger Launch Decision, p. 215
6 Vaughan, Challenger Launch Decision, p. 212
[The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA Author: Diane Vaughan Publisher: University of Chicago Press, Chicago and London Publication Year: 1996]
4. Systems Engineering News
4.1 INCOSE Working Group Information Is Available
The INCOSE Working Groups have established a Working Group Information Sheet (WIS) to help INCOSE Members learn more about the activities of the Working Groups and also to help members decide where to get involved. The WIS contains some basic information about the Working Group as well as a summary of their activities reported at IW2019, held in Torrance California USA January 26-29, 2019. The WIS included at the link provided below were displayed at the Market Place which took place at the end of IW2019: https://www.incose.org/iw2019/program/working-group-information-sheet.
There are files for each individual workgroup and a complete file with summaries of all workgroups to download.
4.2 Model-based Project Engineering (MPE)
Model-based systems engineering (MBSE) is becoming an increasingly important approach to the efficient development of complex systems. MBSE covers almost exclusively the technical aspects of system development. However, classic systems engineering according to ISO 15288 also defines non-technical, project management-relevant aspects. Model-based Project Engineering (MBPE) presents the attempt to close this gap. The MBPE was born out of considerations that deal with the linking of Building Information Modeling (BIM) and MBSE. BIM is a model-based approach from the construction industry that looks at building projects and buildings holistically and throughout the entire lifecycle, as the classic approach to systems engineering also envisages. The models in the BIM also contain project management-relevant information in addition to the technical information. MBPE translates this approach to the MBSE. The focus is on the aspects of cost and time planning, which conflict with each other and with the technical quality aspects of a system development. The aim is to achieve a model-based, simpler balance between cost, time, and quality within a development project by creating a model of the project in SysML that contains objects from the cost and time planning and can be linked to the technical system model. In this way, all of the information concerning a development project can be documented in a single model, so that all project participants – both technical and commercial background – have a common working basis. A webinar presented by Moritz von Ammon in early April discussed the current state of the MBPE approach.
To obtain more information, contact: office@gfse.de
4.3 Researchers will Explore Understanding of Complex Systems among Engineering Students and Professionals
According to a report by the National Academy of Engineering, engineers often lack the understanding of systems that have many interacting parts, otherwise recognized as the cognitive understanding of basic concepts of complex human-technical systems. This lack of comprehension has been connected to “man-made disasters,” such as the Fukushima Daiichi nuclear accident and the Deepwater Horizon oil spill in the Gulf of Mexico.
Engineers design, build, and manage human-technical systems throughout their careers, therefore it is imperative to study the effect of cognitive barriers during and after their education.
Virginia Tech researchers have been awarded a grant from the National Science Foundation to study cognitive reasoning and thinking skills for both engineering students and working professional engineers. The research will also address the need for industry and government agencies to educate and develop complex problem solvers for the U.S. workforce in order to maintain its position as a global leader in innovation and overall economic competitiveness.
4.4 The Need for Systems Engineering in K-12 Schools
V-Model Approach to K-12 Learning
On February 27, 2019, Becky McKinney provided a presentation for the San Diego Chapter of INCOSE in which she addressed the Next Generation Science Standards which call for science and engineering to be taught in every grade K through 12 and a shift away from memorizing facts to doing science and engineering.
Access the presentation in .ppt here
Access the presentation in .pdf here
4.5 European Journal of Sustainable Development Call for Papers
European Journal of Sustainable Development is a double blinded peer-reviewed open access journal, published under the supervision of the European Center of Sustainable Development (ECSDEV). EJSD was established as the official journal of ECSDEV, to provide an international forum for debates among diverse disciplines, such as human development, environmental and energy economics, health education studies, and related fields. The main purpose of the journal is twofold: to encourage (1) integration of theoretical studies and policy studies on sustainability issues and (2) interdisciplinary works of energy economics, environmental policy studies, educational studies, sustainable agricultural development, health and food education, urban planning and related fields on sustainability issues. The journal also welcomes contributions from any discipline as long as they are consistent with the above stated aims and purposes and encourages interaction beyond the traditional schools of thought.
Closing date for June issue is 30 April 2019. Manuscripts can be submitted electronically. to: ejsd@ecsdev.org
Access prior editions of the journal here.
5. Featured Organization
5.1 IISE/INCOSE University of Arizona Student Chapter
The mission of the University of Arizona student chapter of IISE and INCOSE is to provide systems and industrial engineering students the opportunity to enhance their experience through connecting with each other and professionals in their industry. This is done through providing opportunities such as: professional guest speakers, professional conferences, industry tours, and more! The organization also provides Systems and Industrial Engineering (SIE) students with tools to aid them in their academic career at the University of Arizona.
5.2 UCL Centre for Systems Engineering (UCLse)
University College London Centre for Systems Engineering (UCLse) was founded with the aim to share the knowledge and skills developed by the Mullard Space Science Laboratory from over two hundred successful rocket and space missions completed over the last fifty years with systems engineers in other sectors. The Engineering and Physical Sciences Research Council (EPSRC) sponsored the creation of a flexible/modular MSc program to be delivered with GEC Marconi (now BAE Systems).
Around the same time, Prof. Alan Smith of UCLse co-developed a Project Management training course accredited by the Association for Project Management (APM) and leading to the PMQ qualification.
This interest in both systems engineering and project management continues to this day, and UCLse offers courses in each of these areas, recognizing the importance of integrating the two disciplines. This is one of the five fundamental principles that UCLse believes contribute to the successful delivery of complex projects.
6. News on Software Tools Supporting Systems Engineering
6.1 IDAES Process Systems Engineering Software Now Open Source
The Institute for the Design of Advanced Energy Systems (IDAES) has released the first open-source version of its next-generation computational framework and model library, created to optimize the design of process systems engineering solutions used to model advanced energy systems.
The new framework can be accessed on the IDAES website.
Led by the U.S. Department of Energy’s (DOE) National Energy Technology Laboratory (NETL), IDAES was formed in 2016 to improve the efficiency and reliability of coal-fired power plants and to accelerate the development of advanced fossil energy systems. It builds on the research and partnerships formed during the Carbon Capture Simulation Initiative (also funded by DOE through the Department’s Office of Fossil Energy), to create an open-source, non-commercial framework specifically for process systems engineering.
7. Systems Engineering Publications
7.1 Engineers’ Practical Databook:
A Technical Reference Guide for Students and Professionals
by
Jay Smith
From the Amazon Website:
This databook is an essential handbook for every engineering student or professional. Engineers’ Practical Databook provides a concise and useful source of up-to-date essential formula, charts, and data for the student or practicing engineer, technologist, applied mathematician or undergraduate scientist. Unlike almost all other engineering handbooks out there, this one doesn’t package itself as a heavy, expensive or cumbersome textbook, and doesn’t contain any preamble or lengthy chapters of ‘filler’ material. You will find value cover-to-cover with all the essential formula, charts, and materials data. This handbook is suitable for use in support of Higher Education programs, including Higher National Diplomas and accredited engineering degrees. Topics include the essentials of aerospace, civil, electrical and electronic, mechanical and general engineering. Chapters include Mathematics, Materials, Mechanics, Structures, Machines and Mechanisms, Electrical and Electronics, Thermodynamics, Fluid Mechanics, Systems, and Project Management. First Edition is in SI Units. – Easy to use – Chapters organized by module/discipline topic – Physical, geometric, thermal, chemical and electrical properties – All variables and units clearly defined – Essential technical data.
Format:
Publisher: Independently published (August 2, 2018)
ISBN-10: 1980619344
ISBN-13: 978-1980619345
7.2 System Architecture: Strategy and Product Development for Complex Systems
by
Edward Crawley, Daniel Selva, and Bruce Cameron
From AbeBooks.com:
System architecture is the study of early decision making in complex systems. This text teaches how to capture experience and analysis about early system decisions, and how to choose architectures that meet stakeholder needs, integrate easily, and evolve flexibly. With case studies written by leading practitioners, from hybrid cars to communications networks to aircraft, this text showcases the science and art of system architecture.
ISBN-10: 1292110848
ISBN-13: 978-1292110844
7.3 The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment
by
Svyatoslav Kotusev
Enterprise Architecture (EA) is a set of descriptions relevant to both business and IT intended to bridge the communication gap between business and IT stakeholders in organizations, facilitate information systems planning and improve business and IT alignment. Due to complex historical reasons, the notion of enterprise architecture was always surrounded by endless speculations, dangerous myths, non-existing best practices, unfulfilled promises, expensive failures and grave disappointments. Traditionally the entire discourse around enterprise architecture was dominated by shallow advice and faddish approaches, e.g. well-known EA frameworks, infinitely distant from the practical realities, but nonetheless aggressively promoted by commercially motivated consultancies and gurus. At the same time, realistic and trustworthy information on enterprise architecture is still incredibly hard to find in any available sources.
Based on an extensive study of the actual industry best practices and existing EA literature, this book provides a unique, systematic, end-to-end description of various aspects of an EA practice integrated into a consistent logical picture. In particular, this book offers clear, research-based, conceptually sound and practically actionable answers to the key questions related to enterprise architecture:
- What is the meaning of enterprise architecture and an EA practice?
- What processes constitute established EA practices and how do they work?
- What EA artifacts are used in successful EA practices and how?
- What is the best way to structure architecture roles and functions?
- What software tools and modeling languages are necessary for enterprise architecture?
- How to initiate an EA practice in organizations from scratch and evolve it?
- Where do current EA best practices originate from?
This book is organized in a highly structured, sequential manner and does not require any prior knowledge of enterprise architecture. The book is intended for a broad audience of people interested in enterprise architecture including practicing and aspiring architects, architecture managers, academic EA researchers, EA lecturers, and students in universities.
Format: Kindle, Hardcover, Paperback
Publisher: SK Publishing (June 5, 2018)
7.4 Design Teams: Requirements Management
and Product Complexity
In late 2018, engineering.com surveyed 246 design and engineering professionals to ask them about the changing complexity of their products, and how the requirements caused by those changes are being managed. An overwhelming portion (92%) reported their products had increased in complexity over the last five years. Leading causes of increased complexity were mechanical designs becoming more intricate (57%), more electronics (47%), and new materials (43%). Despite the increasing complexity, only 15% of respondents relied on a dedicated requirements management system. This was either causally linked or a likely factor in the following reported negative outcomes:
- Production outcome failures (83%)
- Reprimands by a regulatory agency (62%)
- A minority reporting they feel they effectively manage requirements (34%)
This report describes the ways in which products are becoming more complex, how they’re regulated, and what that means for product outcomes as it relates to requirement management systems.
Download the report here.
7.5 Parametric Cost and Schedule Modeling for Early Technology Development
by
Chuck Alexander
From the Johns Hopkins University Applied Physics Lab Website:
There is a need in the scientific, technology, and financial communities for economic forecast models that improve the ability to estimate new or immature technology developments. Engineering design or conceptual technical requirements with which to drive parametric estimates or translate analogous system costs are often unavailable in early life-cycle stages of technology development. The limited availability of comparable systems, design or performance parameters, and other objective bases makes it challenging to produce even rough-order-of-magnitude cost and schedule models. Often compounding the limited availability of information is the proprietary or protected nature of technology research and development efforts and related intellectual property. Consequently, executives, program managers, budget analysts, and other decision-makers must often rely on historical information from related yet often very dissimilar systems or the subjective opinion or “best guess” of subject-matter experts. This paper first investigates available industry modeling concepts, frameworks, models, and tools. A representative project data set is identified and selected for cost and schedule modeling, leveraging macro-parameters generally known or available in early technology development stages. Several model forms are then created and evaluated based on key performance criteria.
8. Education and Academia
8.1 Industrial and Systems Engineering Department at the Cape Peninsula University of Technology
Belville, South Africa
The Department of Industrial and Systems Engineering is a leader in offering industrial and systems engineering education in South Africa. This department is the only Engineering Department in the Western Cape province that offers ECSA (Engineering Council of South Africa) accredited Industrial Engineering technological education and a post diploma Quality practitioner’s degree.
The Department of Industrial and Systems Engineering boasts highly qualified and motivated academics that are committed to research and innovation. The department is internationally recognized, and engages in the highest quality teaching and research, benefiting the students, the Faculty, the Institution, the Western Cape and Southern Africa. The Department’s graduates are popular in finding employment opportunities within the production, commercial and services industries.
The Department’s competitive advantage is that they have the infrastructure to engage in commercially viable industry-related research projects. Their academics have the collective knowledge and experience to guide, motivate and direct their students through the students’ undergraduate and post graduate qualifications. The Department cites that it is, ‘fully aware of the current industry needs’, due to engaging with industry partners on a regular basis and that their staff are therefore encouraged to “sharpen” their skills and knowledge annually to stay abreast with challenging industry demands.
Contact the department
Department of Industrial and Systems Engineering
Mechanical and Industrial Engineering Building
Bellville Campus
PO Box 1906
Bellville
7535
Head of Department:
Mr A Bester
Tel: 021 959 6028
Departmental Secretary:
Mrs Shahida Ngonda
Tel: 021 959 6600
NgondaS@cput.ac.za
9. Some Systems Engineering-Relevant Websites
INCOSE Publications and Presentations Library
The Papers & Presentations library is a search engine for the paper presentations made at the annual INCOSE symposia since 2010. For your convenience links to the corresponding paper on the Wiley website are provided (INCOSE members have access to this library as part of their membership).
https://www.incose.org/products-and-publications/papers-presentations-library
BKCASE
INCOSE, the IEEE Computer Society, and the Systems Engineering Research Center have teamed up under BKCASE (Body of Knowledge and Curriculum to Advance Systems Engineering) project to produce a valuable guide to the Systems Engineering Body of Knowledge, the SEBoK, a wiki. You can use the wiki online or download the wiki in part or whole as a pdf.
Find a Job in Systems Engineering
An INCOSE website containing featured jobs in Systems Engineering and related fields, searchable by title and location. The site enables the option to submit an email address to be notified when jobs in specific industries or of specific functions become available.
https://incose.careerwebsite.com/
10. Standards and Guides
10.1 SAE1001 Integrated Project Processes for Engineering a System
SAE1001 Integrated Project Processes for Engineering a System was issued by SAE late in 2018. This standard is applicable to the engineering or the reengineering of:
- commercial or non-commercial systems, or portions thereof;
- any system, small or large, simple or complex, software-intensive or not, precedented or unprecedented;
- systems made up of hardware, software, firmware, personnel, facilities, data, materials, services, techniques, or processes (or combinations thereof);
- a new system or a legacy system, or portions thereof.
The requirements of the standard, or a designated subset, are intended to be applied by projects establishing policies and procedures for project implementation of the adopted process and process elements of the standard. The requirements of the standard may be tailored as follows:
- Processes – Processes may be tailored to be applicable for a given type of project or system. For example, the System Utilization Processes typically don’t apply for conceptual or prototype systems in the same manner as for full-volume production systems.
- Activities – Activities may be tailored to reflect the specific approach established by a project, where the modified Activities still achieve the intended Process Purpose and Process Outcomes.
- Tasks, Inputs, and Outputs – Tasks, Inputs, and Outputs may be tailored to reflect the specific approach or methods established by a project, including different life cycle approaches for a given project or system, where the modifications still achieve the intended purpose of the Activity.
SAE1001 will be reviewed in a subsequent edition of SyEN.
11. Some definitions to close on
11.1 Context Analysis
1. (noun) Context analysis is a method to analyze the environment in which an entity or body of knowledge operates. Context analysis considers the entire environment.
Source: Wikipedia
11.2 Building Information Modeling (BIM)
1. (noun) BIM is a model-based approach from the construction industry that looks at building projects and buildings holistically and throughout the entire lifecycle, as the classic approach to systems engineering also envisages.
Source: GFSE
12. Conferences and Meetings
For more information on systems engineering related conferences and meetings, please go to our website.
The featured event for this edition is:
IEEE International Conference on Industrial Cyber-Physical Systems
6 – 9 May 2019, Taipei (Taiwan)
The aim of the IEEE International Conference on Industrial Cyber-Physical Systems and IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems, is to provide a platform to exchange research and innovation results, lessons learned from industrial practices associated with new paradigms and technologies. IEEE ICPS 2019 and IEEE MFI 2019 are going to be the conference series presenting the state of the art and future perspectives of Industrial Cyber-Physical Systems and Multisensor Fusion and Integration for Intelligent Systems. The industry experts, researchers, and academics share ideas and experiences surrounding frontier technologies, breakthrough and innovative solutions and applications, pertaining to:
- How Industrial Cyber-Physical Components, Systems, and Services are designed, implemented, deployed and operated by the industry.
- How they communicate and cooperate with each other as well as humans in real time.
- How they are in conjunction with the Internet-of-Services and real-time analytics on Big Data, enhancing internal and cross-organizational engineering, management, control and automation functionalities for all stakeholders across a digitized value-chain.
Register for the conference here.
13. PPI and CTI News
13.1 Certification Training International Launches a New Website
Certification Training International (CTI), a wholly owned subsidiary company of Project Performance International, has just launched a new website. CTI was established to provide outstanding preparation training worldwide to engineering and other project professionals seeking to become certified under a recognized, relevant certification scheme. With this vision in mind, the website design has been revamped to include new content and a modern, easy-to-navigate interface. Visit the new website to view testimonials of clients and articles & resources, which includes the popular article: ‘10 Helpful Hints To Completing The INCOSE Application Form For CSEP’ at the following link: https://certificationtraining-int.com/
13.2 Promotion to Marketing Manager
It is with delight that we congratulate Benjamin Bryant on his promotion to Marketing Manager at PPI. Ever since his recruitment in January 2018, Benjamin has showcased diligence in all tasks and immense initiative in his role. We look forward to witnessing him flourish in his new role and welcome the continued positive contribution of the marketing team in enabling us to bring our systems engineering education and services to benefit the world.
13.3 A Momentous CSEP Course in
Jingdezhen, Jiangxi, China
The 45th delivery of the CSEP training by CTI to AVIC Helicopter Design Institute took place in March 2019. At the close of the course, Vice Chief Engineer – Hu Haihua, partook in the issuing of certificates to the delegates who participated in this on-site course.
The course was delivered by David Mason, shown below explaining how PPI’s Wedge Model™ may be used during development and testing within the AVIC company. The Wedge Model™ is a derivative of the original Vee Model and shows the verification and validation relationships of requirements, design, subsystems and system in single-build and multiple-build development environments.
Figures: AVIC Helicopter Vice Chief Engineer Hu Haihua (left) handing out certificates and discussing the PPI Wedge Model with PPI course presenter David Mason (right).
On-site systems engineering training is being delivered worldwide throughout the year. Below is an overview of public courses. For a full public training course schedule, please visit https://www.ppi-int.com/course-schedule/
Systems Engineering 5-Day Courses
Upcoming locations include:
- Zürich, Switzerland (P006-775)
03 Jun – 07 Jun 2019
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
- Sydney, New South Wales, Australia (P007-478)
20 May – 24 May 2019
Systems Engineering Management 5-Day Courses
Upcoming locations include:
- Melbourne, Victoria, Australia (P1135-169)
15 Jul – 19 Jul 2019
Systems Engineering Overview 3-Day Courses
Upcoming locations include:
- Chantilly, Virginia, United States of America (P884-15)
09 Dec – 11 Dec 2019
Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses
Upcoming locations include:
- Washington, D.C., United States of America (P958-59)
13 May – 17 May 2019
Engineering Successful Infrastructure Systems (ESIS5D)
Upcoming locations include:
- Amsterdam, the Netherlands (P2005-2)
23 Sep – 27 Sep 2019
Architectural Design 5-Day Course
Upcoming locations include:
- Pretoria, South Africa (P1768-19)
15 July – 19 July 2019
CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)
Upcoming locations include:
- Laurel, MD, United States of America (C002-92)
06 May – 10 May 2019
Medical Device Risk Management 3-Day Course
Upcoming locations include:
- San Francisco, California, United States of America (P1848-4)
26 Aug – 28 Aug 2019
Other training courses available on-site only include:
- Project Risk and Opportunity Management 3-Day
- Managing Technical Projects 2-Day
- Integrated Product Teams 2-Day
- Software Engineering 5-Day
15. Upcoming PPI Participation in Professional Conferences
PPI will be participating in the following upcoming events. We support the events that we are sponsoring and look forward to meeting old friends and making new friends at the events at which we will be exhibiting.
Systems Engineering Test and Evaluation (SETE) Conference (SETE19)
(Exhibiting)
Date: 29 April – 1 May, 2019
Location: Canberra, Australia
The INCOSE International Symposium 2019
(Exhibiting)
Date: 20 – 25 July, 2019
Location: Orlando, Florida, USA
(Exhibiting)
Date: 21 – 24 October, 2019
Location: Cleveland, Ohio, USA
The INCOSE International Symposium 2020
(Exhibiting)
Date: 18 – 23 July, 2020
Location: Cape Town, South Africa
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com
Ralph Young, Editor, email: ryoung@ppi-int.com
René King, Managing Editor, email: rking@ppi-int.com
Project Performance International
2 Parkgate Drive, Ringwood, Vic 3134 Australia
Tel: +61 3 9876 7345
Fax: +61 3 9876 2664
Tel Brasil: +55 12 9 9780 3490
Tel UK: +44 20 3608 6754
Tel USA: +1 888 772 5174
Tel China: +86 188 5117 2867
Web: www.ppi-int.com
Email: contact@ppi-int.com
Copyright 2012-2019 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.
- Anonymize: to remove identifying information so that the original source cannot be known; to make (something) anonymous. For Helix, each individual and organization is assigned a unique identifier which is used throughout the dataset. ↑
- A “Likert item” is a statement that the respondent is asked to evaluate in a survey. ↑
