In This Edition
1. Quotations to Open On
2. Feature Article
- Keep Systems Engineering Simple to Get the Job Done by Sören Ulonska,
Cecilia Haskins, Oluf Tonning, Itxaso Yuguero-Garmendia
3. Additional Articles
- Human Systems Integration as a Path to Transformation of System Capability by Dr. Gavan Lintern
- Integrating Program Management and Systems Engineering by Dr. Ralph Young
- Challenges to Systems Thinking and How to Overcome Them by René King
4. Systems Engineering News
- Call for Papers: Diversity in Systems Engineering
- “Charter of Trust” Established to Strengthen Cybersecurity At SIEMENS Security Conference
- Call for Papers – Special Section on Formal Approaches Institute of Electronics, Information, and Communication Engineers
- Summary of the Executive Plenary Panel Systems Engineering for Complex Systems – Challenges and Issues
- Space and Naval Warfare Center (SSC) Develops Tailored Process for Development of Mobile Applications
5. Featured Organizations
- Accreditation Board for Engineering and Technology
- Centre for Systems Philosophy
- IEEE Technology and Engineering Management Society
6. Software Supporting Systems Engineering Tools News
- Professor Peter Jackson in Singapore Releases a Comprehensive Tutorial: Introduction to Arcadia with Capella
- GENESYS 6.0 Software for Systems Engineering Now Available
7. Systems Engineering Publications
- Systems Engineering Guidebook: A Guide for Developing, Implementing, Using and Improving Appropriate, Effective and Efficient Systems Engineering Capabilities
- Leading Complex Projects: A Data-driven Approach to Mastering the Human Side of Project Management
- The Strategic Management of Large Engineering Projects: Shaping Institutions, Risks, and Governance
- Turn the Ship Around! A True Story of Turning Followers into Leaders
- Journal of Multi-Criteria Decision Analysis Optimization, Learning, and Decision Support
- Understanding A3 Thinking
8. Education and Academia
- University of Engineering and Technology, Lahore Punjab
- Norwegian University of Science and Technology (NTNU)
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
- ISO-IEC-IEEE-42010 Survey: The Practical Use of UML for Different Architectural Viewpoints
- A Semantic Framework for Systems Engineering Standards
11. Some Definitions to Close On
- Occam’s Razor
- The Historical Roots of Concurrent Engineering Fundamentals
12. Conferences and Meetings
13. PPI and CTI News
14. PPI and CTI Events
15. Upcoming PPI and CTI Participation in Professional Conferences
1. Quotations to Open On
“The three imperatives for the successful engineering of systems are an ability to achieve an adequate understanding “the problem”, knowledge of solution technologies relevant to solving the problem, and the creativity to see how that technology knowledge can be applied to actually solve the problem. Without these, the other principles and methods of systems engineering are useless.”
Robert John Halligan
“Don’t ever settle for average. Average is where the best of the worst and the worst of the best meet.”
James L. Dunn
“Everything that irritates us about others can lead us to an understanding of ourselves.”
Carl Jung
2. Feature Article
Keep Systems Engineering Simple to Get the Job Done
by
Sören Ulonska, Cecilia Haskins, Oluf Tonning, Itxaso Yuguero-Garmendia
Department of Engineering Design and Materials
Norwegian University of Science and Technology (NTNU)
Sören Ulonska
Email: sören.ulonska@ntnu.no
Cecilia Haskins
Department of Production and Quality Engineering
Norwegian University of Science and Technology
Email: cecilia.haskins@iot.ntnu.no
Copyright © 2013 by Sören Ulonska and Cecilia Haskins. Published with permission.
Editor’s Note
Although this article was written five years ago, it incorporates several suggestions for systems engineering today, including improving communication amongst SE team members, capturing knowledge and passing it on to the next generation SE team, structuring knowledge using a clear and simple approach, and considering the extent to which SE is a discipline and an attitude. The article is innovative, thoughtful, a good teaching tool, well-written, and comprehensive. It describes the concept of “A3 Thinking” (Sobek and Smalley, 2008, a book that is described in the SE Publications section of this issue). The article describes how Model-based Systems Engineering (MBSE) was introduced to an SE team and then utilized successfully on a project. Importantly, the project manager describes how crucial and helpful it was for him to be able to rely on SEs, and that he came to appreciate that SE work is not restricted only to the technical efforts that are done within the team and for the project or program and the organization. Links to several interesting websites are provided. We look forward to providing another article authored by Dr. Haskins in the next few months.
Abstract
This paper is a continuation of the reporting on the result of the application of systems engineering and (lean) product development techniques in a student team. The project setting is Trondheim, where the multidisciplinary student team (their two systems engineers are co-authors) designed and produced a car to compete in Shell Eco-Marathon. The paper introduces approaches and discusses the effects of the student team applying SE in a simple way, using visual planning, modeling, and knowledge briefs of lean product development. The paper includes examples of work breakdown structure, A3 documentation, computer-based models, and visual planning, as well as experiences with effective knowledge capture and exchange based on knowledge briefs and the systems architecture. The conclusion is that keeping SE simple and visual helps to motivate team members and makes product development and knowledge exchange between team generations more efficient.
Introduction
Shell Eco-Marathon (SEM) is a worldwide competition that challenges student teams to design, build and test energy-efficient vehicles. The competitive element is the car’s energy consumption converted into gas mileage measured in petrol equivalents (km/l), where the winner in each class is the team that goes the furthest using the least amount of energy (Shell 2012). The competition is arranged once a year, always with slightly different requirements to make the teams improve and adjust their cars.
The Norwegian University of Science and Technology (NTNU) has participated in the urban-concept-class in SEM Europe since 2008. The student teams have experienced several high moments but also a few low ones. The 2009 team set a track record of 1246 km/l in the Urban Concepts class using a hydrogen-powered vehicle. Unfortunately, the following year (2010), the car did not make it to the starting line. Individual technical components all worked in 2010, but the system as a whole failed due to a lack of time for integration and testing. Technical problems were identified too late in development, causing design rework, corner cutting, reactive problem-solving and ultimately a less-than-optimal product that lacked the desired robustness. To avoid such situations for the future the team realized that they needed a systems engineer to ensure the car’s performance on a system level and to manage the technical development so that the car was ready accord to the time schedule. Benefits of using systems engineering were visibly apparent after a systems engineer was added to 2011’s team and the car finished second in the same class as before (Haskins and Welland 2012).
Each year, the development team is composed of a multidisciplinary group, including students with backgrounds in mechanical engineering, electrical engineering, cybernetics, and media. The team of master students is completely replaced by new students once a year. The student project is divided into two phases covering activities for the fall semester and spring semester. Typically, the fall semester is spent doing concept exploration, evaluation and design of solutions as a part of a mandatory project course at NTNU. The following spring semester is spent producing the car, followed by verification, validation and testing as a part of their MSc thesis. The subsystems are designed and developed concurrently. For example, the process of integrating body and motor involves numerous iterations to result in an overall good quality product. Production is also done in parallel, providing subsystems finishing at approximately the same time. The final activity is attending the race and delivering master theses.
In this way the project is nearly continuous, as the car and developed knowledge is transferred from one team generation to the next. Development cycles follow mainly the principle of continuous improvement (Morgan and Liker 2006). However, in 2012, the requirements changed so dramatically that the team moved from continuous improvement to new product development (NPD). They entered the competition with a car that was basically similar to former cars, but actually required new development and production of (nearly) all components, sub-systems, etc. This paper presents the results of the work done to field a car for the 2012 race, based on the final master’s thesis written by the two systems engineers on the project; Itxaso Yuguero-Garmendia (SE1) (Yuguero-Garmendia 2012) and Oluf Roar Tonning (SE2) (Tonning 2012). Figure 1 shows the team photo taken at the race site in Rotterdam, NL.
Figure 1: NTNU’s Shell Eco-Marathon team and car at the competition in 2012
Background
Since 2011 the NTNU SEM project team has included a systems engineer. Challenges for the first systems engineer in 2011 were mainly the need for careful planning to reduce the risk while modifying the car, by coordinating team efforts and organizing the integration testing (Haskins and Welland 2012).
For the 2012 competition, technical reasons motivated the NTNU team to change the category of class in which to compete. The so-called Battery-Electric class is more competitive and prestigious than the hydrogen-class (fuel cell) in which the previous teams had competed. They selected Lithium-ion batteries as the energy source. When the rules from Shell also changed the race from a track to road-based competition, the SEM2012 team faced the challenge of designing and building an-all new vehicle, dubbed the DNV Fuel Fighter 2 (DNVFF2).
Building a car from scratch was a challenge that no team after the SEM2008 team had attempted. This challenge incurred much higher technical risk as compared to improving an existing vehicle. In addition, extending the size of the team to 14 people (previously 6), from different engineering disciplines for the new concept, represented a considerable managerial risk. Fortunately, two students were willing to accept the role of systems engineer to help the team meet these challenges. They split the responsibility by SE1 focusing on verification, validation, and testing, and SE2 on implementation of lean systems engineering with particular focus on simplicity in documentation and use of visualization techniques, including computer-based modeling, both to provide the team a good project and product overview and for the upcoming knowledge transition from the 2012 team to future teams. From 2010, the subsequent teams had learned that knowledge transfer is important for continuous improvement and project success.
This paper is a report on the results of the application of lean principles and SE methodologies by the SEM2012 student team with some observations on its impact on the SEM2013 team. It illustrates how keeping to the basics and making SE simple, visible and effective for a multidisciplinary team delivered a result that everyone was proud of. The paper includes examples of artifacts produced by the SEM team, such as the A3 documentation, and the WBS white board. Topics are linked to the following research questions:
- How can team members ensure easy and effective communication?
- How can knowledge be captured effectively and (re)used in the next team generation?
- How can knowledge be structured ensuring a clear and simple overview?
- Is systems engineering a discipline or an attitude?
The Race and the Race Team SEM2012
The race team for SEM2012 benefitted from the good results of the prior year and eventually attracted 14 engineering students, two of whom took roles as systems engineers for the project. The SE work that was done during the first semester of the SEM project consisted of defining a new System Architecture based on the one used by SEM2011, developing a Trade-off analysis to facilitate all the decisions that were made, creating a requirement checklist in order to make sure that the solutions that were designed met the specifications and detailed attention to interfaces. The architecture from the prior year was used primarily to create a rough estimate of cost and schedule, and to allocate initial responsibilities for subsystems and interfaces that were known to exist. For the most part, a straightforward SE process was used that followed the SE V-model. Excerpts from the thesis illustrate the critical steps taken in the second semester (Tonning 2012).
Stakeholder Analysis
The view of the stakeholders changed over the year. Eventually, the team came to accept that the ultimate users of the DNVFF2 are the sponsors and subsequent SEM Teams. The driver of the car is also a special stakeholder, with real and immediate needs for safety. The sponsors of the DNVFF2 are looking for media attention that the project can give them. Thus, the team has made a huge effort in order to fulfill the stakeholder’s need for attention by participating in non-engineering PR activities. Only the systems engineers with their overall vision of the project understood that PR is value-adding and that it would enable future teams to attract sponsorship and much-needed funding.
Changes to the Car
For the first time in the Shell Eco-Marathon Europe race history the competition was held on a street-track in Rotterdam. The new track and associated requirements, such as stops between laps, made a new suspension necessary and there was no space in the original car body to implement this upgrade, therefore the development of a new body was necessary. Once in Rotterdam, the new suspension gave the car the ability to be the fastest car in the second half of the track where the turns were closer to each other. The car was also able to enter the turns faster than was anticipated when the track analysis was made. In the track analysis the speed that was defined for the turns was between 20-25 km/h but the car was able to enter the turns at up to 33 km/h. This speed increase gave the team freedom to design a better race strategy onsite.
Another major change from the previous year was the propulsion system; this year for the first time in NTNU’s history the SEM team entered the battery electric (BE) class. The decision to change from fuel-cell to BE was based on knowledge transfer from the previous year regarding the reliability and safety of the fuel-cell solution. After the decision was made it was uncovered that the competition in the BE class was much tougher than that for fuel-cell cars.
Decision Gates
The SE team also implemented a visual board where the work breakdown structure (WBS) of the subsystems could be seen; this board also defined the milestones, some of which were also defined as decision gates. The board was used to keep track of all subsystems (represented by the cars) and to address the risk related to schedule slips that could impact the number of days available to test the vehicle. Figure 2 illustrates the board 27 days before leaving for Rotterdam.
Figure 2: WBS schedule
One of the most challenging decision gates was encountered in deciding what to do with the new engine. The milestones for the engine were delayed, and the project reached a point where the decision had to be made. The engine is one of the critical subsystems as it has interfaces with the rear suspension, the control system and the engine wheel. The suspension and the rims were designed to fit in the new engine that was being built. But problems appeared when the team discovered, by testing the engine at test facilities provided by sponsor Smart Motors, that the new engine was not efficient enough. When that decision gate arrived, all the possibilities were studied but due to some production problems, the outcome was unacceptable. Luckily for the SEM team the engine of the prior year was available, which kept project on track. One of the main problems caused by reverting to the older engine was weight; the new engine was designed to be about 10 kilograms lighter. The changes that needed to be done were minor adjustments but the use of the old engine, on a car that was designed for the new engine, potentially could have jeopardized the car and the race results.
Ultimately, this decision was made by the cybernetic engineer, who dealt with control and mechatronic systems. He was the person whose work was delayed by the availability of the engine. The parameters of the engine needed to be defined in order to optimize the control system. As it happened, this deadline was postponed two days since the team thought that the characteristics of the new engine were better. Looking back to that moment, the SE reflected on this trade-off; if the original deadline had been maintained, the time to develop the control system would have been longer, but on the other hand if the new engine had performed as expected the decision of delaying the deadline could have been a winning decision.
Risk mitigation
There were different risk mitigation activities. Most of the risks were mitigated by producing spare parts or by following them up. An example of the mitigation plan can be found in Table 1: Risk Mitigation Plan. Each risk item contained a specific mitigation activity and a responsible engineer. Careful attention to these items was a critical factor for keeping on schedule.
Table 1: Risk Mitigation Plan
| Part | Risk | Mitigation plan | Responsible | Status |
| S.5.5 Tie rods | Misaligned | Realign | A.Q | |
| S.5.4 Hub | Lug threads wear out | Use 2nd set of lug threads on same component | A.Q | |
| S.5.1Linkages | Misalignment | Fine tune alignments | A.Q | |
| Rods may bend | Use spare | A.Q | ||
| S.5.4 Hub | Brake disc
threads wear out |
Use 2nd set of threads on same component | A.Q |
VVT activities
The focus of the VVT activities was on the implementation, integration and qualification activities, defined for four different test phases; unit testing, assembly/integration, performance and race test, all of which are related to the right side of the SE V-model.
As an example of unit testing, the complete drive train was tested on a test bench with different loadings at different speeds to measure efficiency for different operating points. The test bench was also used to study battery behavior for low battery voltage and over current. The outcome of these tests was used to discover that under voltage protection was needed to prevent coming
to a complete stop while racing, torque limitation to prevent under voltage, and over current to prevent stand still while racing. Measurements were used to find the most energy efficient velocity/torque profile for the given track. However, this was one of the more problematic subsystems under race conditions, a circumstance attributed to insufficient resources within the team.
The performance test is focused on testing the car under different environments and circumstances, while the race test was intended to simulate the race conditions in Rotterdam. The biggest problem for the systems engineers was the lack of time and resources to be able to perform better VVT activities. The time and resource problems are as pervasive in the SEM projects as they are in the real-world.
Once arriving at the Race Site, the Shell technical inspection is the first in a series of validation steps. The objective of this inspection is to make sure that cars fulfill the safety and size requirements and it is compulsory to pass in order to be able to compete. During the inspection, all Shell rules are checked by different marshals who use checklists and make a tick when a requirement is checked. They are able to do this because Shell has refined the requirements until they are expressed as pass/no pass requirement statements. The SEM2012 team also worked in this way with the requirements, which meant the car had no problems in passing the inspection, and this allowed the team to enter the track to test the car during all the test days and competition days. This was the first NTNU SEM car able to run on the first competition day.
Stakeholders revisited
Systems engineering is a life cycle approach to projects that covers all the stages from Definition to Disposal. However, each year the whole team changes and the time constraints do not allow the team to design a car that anticipates the whole life cycle. The SEM2012 changed that point of view by framing their project as a delivery to the teams of the following years as users of a prototype that has been designed and built by them. While the VVT activities of 2011-2012 are linked to definition, design, implementation, integration and qualification stages, ultimate Acceptance/Validation of the product will be done by the following SEM Teams.
Future SEM teams are seen as ultimate users as they are going to be the ones “inheriting” the vehicle. The DNVFF2 passed its qualification tests but it is the final users’ duty to accept the product and they will be responsible for conducting acceptance tests as they determine the strengths and weaknesses of the current car and make critical decisions about future modifications.
Lean Product Development and A3 Documentation
Challenges in SEM are to develop the car efficiently to be able to keep the project schedule. The source for what many consider as Lean Product Development (LPD) is the Toyota Product Development System (TPDS). The concept emerged in the mid-1990s and has its origin in lean manufacturing, starting with the Lean Automotive Factory and evolving into the Lean Factory with emphasis on cost reduction, quality improvement, and delivery (Morgan and Liker 2006) with a systems perspective. The primary objectives of LPD are to minimize waste, improve quality, reduce time-to-market and cost, all driven by the desire to pull value from the customer and up the value chain. Regarding SE, Oppenheim (Oppenheim 2011) introduces six principles for lean SE, as ‘lean enablers for SE’ (LEfSE). Those are customer value, value stream, continuous flow, pull of value by the customer, pursuit of perfection, and respect for people.
LPD it is not just a methodology for engineers, it is a way of working, organizing, and making the product development and SE processes more effective, considering both product engineering and product management problems at engineering and management levels. It is more a philosophy of working, rather than a methodology guiding engineers from step to step and proposing concrete working steps (Welo 2011).
Knowledge briefs and A3 Thinking
Knowledge capture and reuse is an important part of lean philosophy. It is also a major issue for SEM because the whole team shifts once a year, which means that knowledge from one team has to be captured, stored and transferred to the next team without the benefit of interpersonal contact. Knowledge is an important resource for product development and systems engineering, because it mitigates risks, and its reuse saves time and prevents repeated problem-solving and unnecessary design loops (Mascitelli 2007). One challenge is to make knowledge capture and reuse efficient. The knowledge brief (K-brief) is a collaborative problem-solving tool, providing a concrete documentation structure to implement PDCA (Plan-Do-Check-Act) management following the principle of continuous improvement (Kennedy 2010). A common type of K-brief is the so-called A3 report (Sobek and Smalley 2008) named by the paper size format used, aiming to visualize problem, goal, process, and solution, and risk elements in a standardized form, depending on the application and problem formulation. The mind-set of A3 thinking includes seven important elements (Sobek and Smalley 2008):
- Logical thinking process
- Objectivity
- Results and process
- Synthesis distillation and visualization
- Alignment
- Coherence within consistency across
- Systems viewpoint
Sobek and Smalley introduce different kinds of K-briefs, which capture information in a clear and visual manner. One is the ‘problem-solving-A3’, which documents challenges and results in product development in relation to the background and overall context. For a good K-brief, Sobek recommends following a certain layout to make it readable and understandable. Examples will be provided in the next section. Further, K-briefs should be reviewed to ensure a certain quality in knowledge storage. The K-brief becomes a mentoring tool, since the A3 report should make the author’s thoughts visible, and the documentation illuminates important targets of the whole organization or team.
When talking about knowledge documentation and reuse it should be kept in mind that there are two dimensions of knowledge: tacit and explicit (Nonaka 1994). Tacit knowledge includes an individual’s belief, viewpoint, paradigm, or concrete know-how, craft, and skill. Explicit knowledge, on the other hand is, articulated and communicated between individuals. A K-brief encourages the author to express the tacit knowledge in a visual manner, and turns it into explicit knowledge. In knowledge management, four basic processes are essential (Alavi and Leidner 2001): Knowledge creation (requiring an organizational culture), knowledge storage/retrieval (requiring dynamic and updated systems), knowledge transfer (requiring adequate searching functions), and knowledge application (requiring the ability to turn knowledge into effective action). A K-brief helps a team deal with all these processes.
In summary, two major points seem to be important in A3 thinking. First, writing a K-brief is important for the writer’s statement of the problem. When writing an A3 report, the author has to distil the essence of the described problem and fit it into a template. This requires an objective, logical thinking process and encourages the author to compress the problem – documenting processes from identifying the cause to presenting a better solution. Going through this documentation process, the author will have to rethink his/her work and get a deeper understanding (tacit knowledge). A second point is that the K-brief provides a standardized way of documenting knowledge making it easier and more effective for the reader to uncover important material. K-briefs speed up communication and improve transfer of explicit knowledge, letting the graphics ‘talk’ (Sobek and Smalley 2008).
Application of Knowledge Brief Documentation in SEM
When applying LPD it is important to know the stakeholder or customer, because customer value is a central element of lean philosophy. In SEM team knowledge transfer, the student teams themselves represent the stakeholders (not including sponsors and teachers). By this is meant not only the current team, but also the following team generations, who gain from the work of prior teams.
The student team works on the SEM project for one year and each student documents the results (knowledge) in the form of a master thesis where the primary goal is to please the supervisors over sharing knowledge with other team members or following team generations. Nevertheless, the team recognized that there exists the need for knowledge sharing both within the team and between team generations. SE2 interviewed the team members, using suggestions from Mascitelli (2007) for data on technical knowledge, and found that the following points represent the most important data for the team and added system level information and risks:
- Important design trade-offs and decisions
- Reusable design elements
- Raw material/component data
- Test results for common design elements
- Reliability data
- Supplier design rules/capability data
- Overview over the interfaces
- Overview over potential risks
Based on these results, SE2 developed a 3-page K-brief, consisting of a set of three A3 sheets, for the car’s subsystems with the intention to create documentation that was easy and fast to read and applied lean thinking. The three A3 pages are summarized in Table 2.
| A3 layout | Content | |||||||||||||||||
| Subsystem | Responsible | Date 1 |
|
|||||||||||||||
| Photo/ | Interfaces | |||||||||||||||||
| Figure | n2
diagram |
|||||||||||||||||
| Component
Table |
Trade-off analysis and design decisions | |||||||||||||||||
| Supplier
Data |
Details | |||||||||||||||||
|
|
|||||||||||||||||
|
|
|||||||||||||||||
Table 2: Three-page knowledge brief for subsystem report
First page
The first page introduces the sub-system, presenting its components, dependencies and interfaces. It is divided into three sections, beginning with a photo or illustration of the system, followed by a table that gives an overview over the sub-system’s components, including information such as material, important physical properties (e.g. weight), and information about whether the component is purchased or produced ‘in-house’ and whether it is a continuous improvement or NPD. The component table provides also a ‘ratio of satisfaction’ dependent on the component’s reliability, constructive weaknesses and the severity of the impact of possible failure. This table gives engineers in following team generations an overview over necessities and possibilities for improvements. Further, the first A3 page includes information about manufacturing methods. The mid-section is dedicated to important design trade-offs and decisions, encouraging visualization and simplicity, using illustrations, graphs or lists for explanations. In the right column, the first page includes an n2 interface diagram, which makes it possible to gain easy insight into dependencies of the sub-systems. Lastly, there is open space to add information on type of interfaces, tolerances, data exchange, etc.
Second page
The second A3 page is dedicated to the design process, focusing on analysis, product modeling and engineering design. The page is divided into two sections, the left-hand section containing textual information on important requirements, assumptions made, materials and software used. The right-hand side provides open space to present the design/analysis process as a graphical way, using sketches, screenshots, and photos.
Third page
The third page consists of two sections, presenting a table of potential risks on the left-hand side. Likelihood of risks are correlated to a simple rating (1, 3 or 5), which include both the likelihood of the risk’s occurrence and the impact of its consequences. On the right-hand side, the A3 sheet provides space to describe the sub-system’s performance, containing information on verification, validation, testing (procedures and history), and identified weaknesses. Finally, the engineers can give an outlook or suggestions for future work.
The body of A3 pages taken together provides a rough, but relatively complete overview over each of the car’s subsystems. Information is illustrated graphically or in tables where possible, and text is reduced to the core elements, which simplifies reading the K-brief. A discussion about impact will follow in a later section.
Model-based Systems Engineering
For the first time the SEM team included an engineer whose background included use of model-based systems engineering (MBSE) tools. Since leaving a strong legacy was important to this team, the following artifacts were modeled: requirements, functional analysis, architecture, interface and sub-system design, with traceability. The product used was Vitech Corporation’s CORE 8 University Edition. A few diagrams are presented here for illustration: the vehicle architecture hierarchy and the interface N-squared diagram (Figures 3 and 4, respectively). These and other representations were posted on the wall and in the workshop to help the team visualize the whole car, the interfaces and to track progress and issues.
Requirements
The requirements provided from Shell were used to propagate the first version of the database, but these were often expressed as run-on sentences, and needed careful review to be restated as individual statements. Eventually the team derived additional requirements to track the weight allocations to subsystems, and other design decisions and allocated each of these onto a component of the vehicle. The requirements included verification and testing criteria, and were used by the entire team.
Functional analysis
The team understood the mechanical functions of the car well enough that modeling this was not seen as adding value. What did need clarification was the competition itself; hence, the functional models dealt with the activities necessary to transport the car, prepare it for transport and participate in the race. The race FFBD (functional flow block diagram) is shown in Figure 5. However, notwithstanding the availability of sophisticated tools, SE2 still did most of the real thinking with brown paper, pens and post-it notes (Tonning 2012).
Figure 3. Vehicle architecture of DNVFF
Figure 4. Interface n-squared diagram for DNVFF2 front suspension 
Figure 5. FFBD for SEM2012 race competition
Discussion
This section is organized around the research questions proposed in the introduction.
How can team members ensure easy and effective communication?
An approach that SE2 introduced in the architecture is that he included not only the parts and assemblies that have been chosen in the final solution, but also principal solutions that have not been chosen for further development, as shown in Figure 6. Color coding of the boxes in the architecture differentiate between chosen designs and alternatives. This makes communication in terms of evaluation of design alternatives much easier and transparent. By including unselected design alternatives and adding reasons, it will be easier for following team generations to understand how the product has been developed, which choices have been made, and why they have been made. Other technical solutions might become better by technological progress, but might not be suitable to choose today. By visually showing those alternatives, design evaluations become easier.
Figure 6. Propulsion system trade-off options
How can knowledge be captured effectively and (re)used in the next team generation?
Due to frequent team changes (once a year) it is important for each SEM project to capture the team’s knowledge effectively and transfer it to the next team, so that the process of continuous improvement of the SEM car is secured. Before SEM2012, knowledge was documented mainly in master theses. SE2 introduced K-briefs to the SEM2012 team. At the end of the project they remain incomplete and do not cover all development issues related to the car. Nevertheless, they represent a starting point in direction of more effective, lean documentation.
To find out how well the knowledge exchange using master theses, K-briefs, and team meetings worked between the 2012 and 2013 team, the team members of 2013 team were asked to complete a questionnaire. Questions were related to the structure of information, clearness of development history, traceability of requirements, functions, principal solutions, and detail solutions, interfaces, clearness of dependencies, definition of the root cause, information about suppliers, countermeasures and follow-up actions, etc. The students rated their satisfaction with both master theses and K-briefs, which were their main sources for information from the former team generations.
In general, the students were satisfied with both the master theses and the K-briefs. The major disadvantage of the master theses is that it is time-consuming (up to 3 days) to read and understand the information. Information about development history is fragmentary and interfaces and dependencies on sub-system level are not well documented. It is an inefficient process because much information that is not essential for the actual task has to be read, while it is difficult to find the necessary, useful information for determining follow-up actions.
Even though the 3-page K-brief is not yet implemented completely, the most important advantages of the 3-page subsystem K-briefs are that they provide structured information, show interfaces and dependencies clearly, define specific alternatives, and have a clearly visible goal in documentation. The students like the idea of A3 documentation and see it as a useful tool for knowledge capture and transfer. Nevertheless, there still are some weak points such as missing information about suppliers, requirements, and evaluation of design alternatives. If the number of knowledge briefs was increased and information was complete, knowledge transfer would be simpler and faster. A complete knowledge-base consisting of K-briefs and A3s could eventually supersede time-consuming studying of master theses. One challenge in this context (since SEM team is a team of graduating students) is that they have to write a master thesis for graduation, while they do not get any credits for writing K-briefs. Accordingly, the motivation to write K-briefs is low and became the system engineer’s job in the SEM2012 team. Quality and number of K-briefs could probably be improved by establishing a suitable culture for capturing knowledge in the team. For establishing a knowledge culture, it will be necessary to keep ‘additional’ work simple to not demotivate the team members. Apparently, team members like to read K-briefs, but do not like to spend time on writing them.
In addition to reading reports, the 2013 student team met with the 2012 team for direct experience exchange. All team members stated that this was very helpful and made it easier to understand the written documentation. The SEM2012 team has much tacit knowledge, which is not documented, thus a meeting between the team members helped reduce the gap between tacit and explicit knowledge. Communication by email became easier after this meeting, because the communication barrier become smaller. Some team members even found that meeting the old team is the most powerful knowledge resource of all. Having one of the former team members in the new team for some days is an effective way of knowledge and experience exchange.
The systems engineers observed the importance of legacy. The DNVFF2 had inside the team a team member from the previous year and access to the prior cybernetic engineer during the fall semester. The knowledge transfer that those two engineers gave to the team was absolutely crucial and it helped the team to gain knowledge faster and thereby understand the characteristics of the old car and where improvements were possible.
In conclusion given the current state with the primary documentation in master theses and incomplete documentation on K-briefs, the following two issues are important. Documentation as in a master thesis is complete, but it takes a long time to find the relevant information. The K-briefs on the other hand are easy to understand and fast to read, but information is still incomplete. Team members agreed that product documentation in a K-brief is an effective tool, and will provide a better knowledge base, when K-briefs are complete. Expanding the number of K-briefs, such that they describe the entire vehicle’s information, will provide a powerful tool for knowledge transfer and (re)use. In addition to the K-briefs that describe the subsystems, other K-briefs might be considered. For instance, members of the SEM2013 team already wish to have ‘improvement A3s’ that describe current problems, give advice about concrete follow-up actions and further development.
How can knowledge be structured ensuring a clear and simple overview?
SE2 found out that the K-brief is an easy way of presenting information, but it will not serve its purpose without putting them into the right context. The K-briefs need to follow a template to save time for the users (both writers and readers) and to encourage filling them out, the organization needs to adopt a culture for making and using the K-briefs, and the users need to know where and how to access and store them.
This implies that structure is necessary on different levels. First, the K-brief itself needs to be structured on a micro-level, meaning a good structure of the information within the K-brief. The K-brief introduced in Table 2 shows a template for a subsystem K-brief, having a structure appropriate to the purpose. In further development, other types of K-briefs will need to be introduced. It is important that the K-briefs use templates to enable the team members to write them quickly and without forgetting important information. Lean literature recommends standardization to make the processes, in this case the knowledge capture, more efficient.
The second level of knowledge structure on the subsystem or system level is needed to store and share the K-briefs, so that it will be easy to find them when needed. Team members today complain over a diffuse file structure with inconsistent file names. SEM2013 team members complain that it is difficult to find desired information. An approach to solve this problem is to combine K-briefs with MBSE, where the K-briefs capture knowledge and computer-based models exist to structure it in a visual, clear way. The product architecture, illustrating functions and physical components and their interfaces can be used as a base for visual, simple knowledge structure, by linking the knowledge to the items in the architecture. SE2 started to build such a system, but unfortunately this requires some skills to be read by other team members. SE2 implemented this knowledge architecture, filled it with information and maintained it. This made the system consistent, but has the disadvantage, that knowledge capture always has to follow a detour through the systems engineer, which creates a bottleneck and means more work for the systems engineer and possible loss of information. Further the knowledge architecture is not intuitive to be understood by the new team members, so it needs to become simpler. Team members of the SEM2013 team state that a ‘knowledge wall’ might solve this problem of understanding and make knowledge more visible.
Further, SE2 recommends that capturing knowledge should be done at specific points, preferably at important deliverables (twice in a month), and enforced by a strong leader. This ensures that knowledge is not forgotten due to delays.
In summary, the combination of K-briefs and modeling promises to be an effective and fast method for structuring knowledge and maintaining a clear overview.
Is systems engineering a discipline or an attitude?
This interesting question was posed by SE1 in her closing reflections. By her own admission, she began with no knowledge or predispositions regarding systems engineering. Furthermore, she shared more in common with other mechanical engineers on the project than with systems engineers. She described this as a tendency to perfection and optimization of parts with less appreciation for the performance of the whole system and that applied engineers may not always seek the most elegant or simple solution to a problem. Only when she shifted her own attitudes toward holistic thinking and appreciated the value of Occam’s razor, could she really step into her new role. Her background helped her understand that some team members felt that engineering is related to the design and manufacturing of a part or something tangible, something physical, and that for some of them it was hard to value SE work at first.
This was the first time for a NTNU SEM project to have a systems engineer from the start of the project. Each Monday a SE meeting was held. During those meetings, the SE presented their contributions inside the team and new ideas were discussed and developed. It proved to be effective as it was used to foresee problems or to solve the ones that had already happened.
The Project Manager shared how crucial and helpful it has been for him to be able to rely on systems engineers. He appreciated the close interactions and cooperation that took place for the entire project, and appreciated that SE work is not just related to technical aspects of the project. SE are the ones that have a complete view of the project and of the different efforts that are done within the team, from mechanical or technical aspects to PR and management.
The systems engineers of the SEM team have discovered that the best way to derive information and involvement from the other team members is to talk to them directly and show interest about the work that they are doing. In addition, to be even more successful, it is important to be flexible. The SE team has been flexible to adapt their way of working to the team’s needs by tailoring already known Systems Engineering practice to the project. They observed that people really appreciate SE contributions when problems arise. Then the stress and workload are highest, and the duty of the SE is to try to make the effort as efficient as possible, using boards, visual signs etc. This year, when problems appeared the systems engineers became an important part of the solution, channeling efforts and coordinating actions.
Future Work
The new team for the next competition in 2013 just started its work. They will work with continuous improvement of DNVFF2, which means that they need to acquire knowledge from the former team generation. The new team appreciates the use of K-briefs, even though current versions are incomplete and sometimes hard to find. They also figured out that reports and long texts are not convenient, whereas visual information is much easier and faster to understand. Early problems that occurred in knowledge acquisition is that team members notice capacity problems, which constrain the reuse of former knowledge.
In further development the use of K-briefs as communication and documentation base should be extended, aiming to build a knowledge foundation based on K-briefs. A linkage of those K-briefs to the product architecture might be a simple way to make documentation easy to find. Today, the car’s product architecture consists mainly of a physical structure of the car’s subsystems and parts. An extension of the architecture to levels of requirements, technical functions, principal solutions, using methods of MBSE, might make it easier for the team members to understand and develop their product. One possibility could be to implement a knowledge wall, which shows the system architecture, and knowledge physically linked or attached to it by A3s, Post-It-notes or similar.
In conclusion, the use of K-brief documentation and MBSE promise to be helpful approaches that the team can implement further in the future to increase its effectiveness in knowledge use and transfer. Keeping the processes simple seems to be a good approach in this context. These findings are consistent with similar research results reported at the 2012 CSER (Muller 2012, Murphy and Collopy 2012, Flores et al. 2012). A challenge that needs to be solved in the future is to keep the SE and A3 documentation effort as low as possible for the engineering team members, while establishing a culture that includes routines for knowledge transfer at the same time. The students’ focus should not be detracted from engineering tasks or have a high impact on the student’s capacity. Following the SE and documentation tasks need to be kept as simple as possible to encourage the students to use them. SE2 proposes a knowledge manager for the team for quality control and maintenance of the documentation. Nevertheless, to make the team and team generations transition more efficient, a culture or attitude of SE and LPD has to be established to structure the work and to ensure continuous improvement.
References
Alavi, Maryam, and Dorothy E. Leidner. 2001. “Review: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues”. MIS Quarterly no. 25 (1):107-136. doi: 10.2307/3250961.
Flores, JA, OH Salcedo, R Pineda, and R Nava. 2012. “Senior project design success and Quality: A systems engineering approach”. Paper presented at CSER.
Haskins, Cecilia, and Alexander Welland. 2012. “Systems engineering saves the day!” Paper presented at Proceedings of the 22nd Annual INCOSE International Symposium, Rome.
Kennedy, Michael N. 2010. “Product Development for the Lean Enterprise: Why Toyota’s System is Four Times More Productive and How You Can Implement it”. Richmond, VA: The Oaklea Press.
Mascitelli, Ronald. 2007. “The Lean Product Development Guidebook”. Northridge, CA: Technology Perspectives.
Morgan, James, M., and Jeffrey Liker, K. 2006. “The Toyota Product Development System: Integrating People, Process, and Technology.” New York: Productivity Press.
Muller, G. 2012. “Validation of systems engineering methods and techniques in industry”. Paper presented at CSER.
Murphy, L, and P Collopy. 2012. “A work-centered perspective on research needs for systems engineering with models”. Paper presented at CSER.
Nonaka, Ikujiro. 1994. “A dynamic theory of organizational knowledge creation.” Organizational Science no. 5:14-37.
Oppenheim, Bohdan W. 2011. “Lean for Systems Engineering with Lean Enablers for Systems Engineering”. Edited by Andrew Sage, Wiley Series in Systems Engineering and Management. Hoboken, NJ: John Wiley & Sons.
Shell. About Shell Eco-Marathon 2012. Available from: http://www.shell.com/home/content/ecomarathon/about/.
Sobek, Durward K., and Smalley, Art. 2008. “Understanding A3 thinking”. New York: Productivity Press.
Tonning, Oluf, 2012. “Implementing lean systems engineering in the DNV Fuel Fighter 2 project”, Department of Engineering Design and Materials, Norwegian University of Science and Technology, Trondheim.
Welo, Torgeir. 2011. “On the application of lean principles in Product Development: a commentary on models and practices”. International Journal of Product Development no. 13 (4):316-343. doi: 10.1504/IJPD.2011.042027.
Yuguero-Garmendia, Itxaso. 2012. “Verification, Validation and Testing activities of the DNV Fuel Fighter 2”. Department of Engineering Design and Materials, Norwegian University of Science and Technology, Trondheim.
Biographies
Sören Ulonska
Sören Ulonska is a PhD student at NTNU in knowledge-based development project, combining methodologies of (lean) product development and systems engineering to improve (re)use of knowledge between and within new product development projects. His educational background includes a Master in mechanical engineering, product development, and engineering design from RWTH Aachen University in Germany.
Cecilia Haskins
Cecilia Haskins entered academia after more than thirty years in industry. 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. After earning her PhD in systems engineering from NTNU, she is a mentor and lecturer, and conducts research on innovative applications of systems engineering.
Article
Human Systems Integration as a Path to Transformation of System Capability
by
Gavan Lintern
Cognitive Systems Design and Instruction
Project Performance International
Email: glintern@cognitivesystemsdesign.net
Copyright © 2018 by Gavan Lintern
Human Systems Integration is most commonly viewed as a discipline that matches technological systems to human capabilities. The term, Human Systems Integration, implies that systems and humans are distinct entities and that we need to make them work together. In PPI’s 5-day Human Systems Integration course, I take a contrasting position; the human is a part of the system (Lintern, 2011) whereby human workers and technology together comprise the system (Lintern, 2012). According to this view, rather than optimizing the match between humans and technology, the primary challenge is to optimize system capability.
In this article, I assert that we can optimize system capability by using technology to support and leverage the innate power of human cognition. I will support this assertion with summaries of case studies that have shown gains in effectiveness and productivity for individuals, teams, and organizations by leveraging natural human cognitive strategies and capacities in analysis and design. These case studies suggest that we can achieve large gains in the productivity of our socio-technical systems by fully exploiting natural human cognitive capabilities. Following are three case studies that illuminate insight.
Individual Cognition: Landmine Detection
A landmine is an anti-personnel or anti-vehicle explosive device typically concealed under a thin layer of topsoil or debris, which detonates when stepped on or driven over. Injuries sustained by detonation of a land mine can be severe. Thus, the crucial challenge is to detect landmines before they are detonated. The primary enabling technology is the metal detector but working against successful detection is the trend towards development of landmines with minimal metal content. Staszewski (2004) reports a detection rate of approximately 20% for low-metal antipersonnel mines (Figure 1, left panel, before training).
Figure 1. Landmine Detection with and without Cognitive Training, Adapted from Figures 1 and 2 of Staszewski, 2004 (error bars show estimated 95% confidence intervals)
Staszewski (2004) interviewed two military experts whose detection rates exceeded 90% (well above the 20% norm). He elicited from these experts a description of how they achieved their exceptional performance, discovering that they used special strategies to enhance the sensitivity of their equipment and for information search and decision-making. He discovered that these two experts synthesized spatial patterns by attending to the onset and offset of auditory signals that accompanied sweeping motions of the detector head. These experts mentally compared these synthesized patterns to patterns they had learned previously. Staszewski developed a 20-hour program to teach these strategies to other soldiers, who were then able to detect low-metal, anti-personnel mines at the expert rate of over 90% (Figure 1, left panel, after training).
While this is a powerful demonstration of the potency of this sort of cognitive training, the work was seemingly made irrelevant by an independent engineering development of a new type of metal sensing device. The new device used two sensors in conjunction with improved algorithms. However, although it was developed to fix those abysmal detection rates for low-metal mines, detection rates with the new device were worse than with the old device (Figure 1, right panel, before training). To resolve this problem, Staszewski adapted the new training program for the old device to be suitable for the new device. Following training on this adapted program, detection rates again improved to over 90%.
Summary Comment:
Superior levels of human work tap subtle cognitive strategies. Those front-line operators who discover these strategies naturally become our experts. Such expert cognitive strategies are generally not difficult to master, if only we knew about them. Furthermore, going beyond the case study described above, if we know about them, we may be able to configure technological support to help operators use them even more effectively. A colleague and I have recently made this point in relation to computerized healthcare systems where current technologies, although supporting some important functions, increase workload and disrupt normal clinical strategies (Lintern & Motavalli, 2017). The discipline of Human Systems Integration has methods of cognitive analysis that can help us discover how experts go about their work and it has methods of cognitive design that can help us develop innovative ways of supporting that expertise (Lintern & Motavalli, 2018). This is the sort of approach we need to take if we are going to maximize the capabilities of the joint human-technology system.
Team Cognition: Emergency Response
As reported by Klinger and Klein (1999), a planning director at a nuclear power facility was concerned that his emergency response team was not performing well during certification exercises. It seemed that everyone was overloaded. Individual workloads had to be reduced, but senior management expressed the view that it was not possible to increase staffing because space was already limited. What was needed was labor-saving technology.
A cognitive design group observed an exercise and then interviewed several staff. They identified a high number of hand-offs and several information bottlenecks. The flow of information to key deciders was inefficient. Several staff had a poor appreciation of their own role, of who made key decisions, and how information was supposed to flow through the team.
The cognitive design group made several recommendations; reorganize room layout to put people who interacted with each other near each other, have team leaders clarify team member roles and explicitly identify those who would make key decisions, and employ after-action reviews. All recommendations were implemented. One key recommendation was to consolidate staff positions. This resulted in a substantial reduction in staff numbers from more than 80 to 35. Paradoxically, work load decreased despite the reduction in staff. The workload problem had been resolved not by adding staff or by inserting special technologies but by reallocating tasks into more efficient work packages.
The next exercise ran more smoothly with less noise and confusion. Staff asked fewer questions because their situation awareness had improved. Key decision makers were able to expand their time horizons and found themselves thinking ahead instead of reacting to problems. This rather straightforward work-focused analysis and design effort led to a dramatic improvement in the performance of an overworked team without the additional expense of more staff or more technology.
Summary Comment:
The theory of distributed cognition, as outlined by Hutchins (1995), is central to contemporary thinking in Human Systems Integration. Hutchins argues that a team is a cognitive entity that processes information, builds situation awareness, and makes decisions, and that the processes that underlie these cognitive acts are like those used by individuals for the same types of cognitive acts. Good coordination and collaboration, as supported by communication and information sharing, are essential for a team to be an effective cognitive entity. There is considerable potential for technology to enhance system performance by building on the coordinative and collaborative capabilities of the human participants in the system. Especially for teams in which members are widely dispersed, system capability can be optimized only if communication and information sharing tools are configured to be compatible with natural human cognitive strategies.
Organizational Cognition: Knowledge Management
The US 5th Fleet, while supporting the NATO offensive in Afghanistan during 2001 and 2002, implemented a web-based information system (Adkins & Kruse 2003). The use of this system evolved over several months, but its networking and collaboration tools eventually transformed the way information was used and shared for planning and executing missions within the US 5th Fleet.
Members of the Fleet at all levels of command reported that the new information system facilitated their work. Furthermore, the new system had several unanticipated benefits. It induced elevated levels of motivation and innovation in its users. Some of those developing web pages became very good at providing summary analyses that others found more informative than the summaries they would have generated on their own. Those web pages served as important knowledge archives for planners who had previously found it challenging and onerous to extract the meaningful implications from the raw information available to them.
Planning staff noticed a dramatic difference in the way they did their work. Previously, they had found themselves overloaded, formulating plans reactively with critical deadlines looming. They found it considerably easier under the new system to respond to planning requests because essential information was easier to find and to interpret. No longer were they struggling to meet critical deadlines. Rather, much of their time was now spent on contingency planning; preparing ideas and summaries they could later co-opt as needed to develop a plan under a tight time constraint. Staff at all levels found that the new system supported informal discussions because the required information was available at any work station in the Fleet. Those involved no longer had to run to a stateroom, ready room or operation center to access information critical to a discussion.
Much of the success of this system can be attributed to enlightened management. In developing the system, senior officers emphasized the use of conventional tools that could be mastered quickly. They promoted use of the system at all levels of the command hierarchy, they remained ready to dispense with legacy systems and practices that became redundant, they supported a transformation in the practices of information management, and they publicly acknowledged the efforts of those who used the system effectively. They facilitated the acquisition of resources and encouraged the development of effective practice. They remained engaged with operational activities and mindful of operational complexities, and they validated the new cultural norms but refrained from being intrusive as they did so. They demanded results but trusted their operational staff to develop their own procedures.
Summary Comment:
The theory of distributed cognition can be extended to organizations whereby an organization is viewed as a cognitive entity that processes information, builds situation awareness, and makes decisions. As with teams, the processes underlying these organizational cognitive acts are like those used by individuals. In applying the theory of distributed cognition, we should not assume that current work modes are optimum. Nor should we assume that systems developers, no matter how accomplished at Human Systems Integration, will understand how dedicated and competent workers will solve the challenges facing them. Support tools that allow workers to optimize their own work processes and to collaborate across the organization as they access to information, engage in sense making, and share information, will strengthen organizational cognition.
Discussion
The lesson here is not that we can do well enough with off-the-shelf or non-computerized technologies but rather, that if we are to exploit fully the capabilities of advanced technology to support cognitive work, we need to know how human cognitive capabilities are deployed and can be deployed in execution of that work. Over recent decades, information technology has transformed the way humans interact with systems. Those technological developments have allowed us to build systems with powerful capabilities. Unfortunately, the power of human cognition has been left behind. The human in the system has been viewed as the weak link; low-bandwidth and error prone, best consigned to a supervisory role in a system in which technology does the meaningful work. The case studies I have reviewed here suggest the opposite; that thoughtful consideration of the power of human cognition can take our information systems to a new level.
Human Systems Integration is not just about computerizing current work patterns, workflows or work tasks. Nor is it just about reducing human workload, automating repetitive tasks, or reducing human error. It is about developing a new form of joint human-technology system that is considerably more powerful than our current systems. The key strategy is to use technology to amplify and extend, not replace, human cognitive capabilities. Naturalistic displays of information, well integrated communication tools, and work-flow organizing structures will inevitably strengthen meaningful and productive human engagement with work.
For example, current healthcare information systems, although having many useful capabilities, disrupt crucial elements of the cognitive work of front-line healthcare workers (Holden, 2011). This has both desirable and undesirable implications for patient safety and for quality of care. We should not, however, conclude that this constitutes an unavoidable trade-off between the good and the bad. Systematic application of analytic and design tools available within the discipline of cognitive systems engineering will lead to even greater benefits from the use of technology while, at the same time, avoiding those negative effects that disrupt cognitive work and cognitive workflow (Lintern & Motavalli, 2017). The 5-day Human Systems Integration course offered by PPI provides a solid introduction to the analytic and design tools that are needed to accomplish this.
References
Adkins, Mark & Kruse, John (2003). Network Centric Warfare in the US Navy’s Fifth Fleet: Web Supported Operational Level Command and Control in Operation Enduring Freedom. The University of Arizona Center for the Management of Information, Tucson, AZ.
Holden, R. J. (2011). Cognitive performance-altering effects of electronic medical records: An application of the human factors paradigm for patient safety. Cognition, Technology & Work, 13(1): 11-29.
Hutchins, E. (1995). “Cognition in the wild”. Cambridge, MA: MIT Press.
Klinger, D. W. and Klein, G. (1999). Emergency response organizations: An accident waiting to happen. Ergonomics in Design, 7(3), 20-25.
Lintern, G. and Motavalli, A. (2018). Healthcare information systems: the cognitive challenge BMC Medical Informatics and Decision Making (2018) 18:3 DOI 10.1186/s12911-018-0584-z
Lintern, G. and Motavalli, A. (2017). Design of Cognitive Support for Healthcare. 22nd International Congress on Modelling and Simulation, Hobart, Tasmania, Australia, 3 to 8 December 2017 mssanz.org.au/modsim2017
Staszewski, J. (2004). Models of expertise as blueprints for cognitive engineering: Applications to landmine detection. Proceedings of the 48th Annual Meeting of the Human Factors and Ergonomics Society, 48, 458–462.
Article
Integrating Program Management and Systems Engineering
by
Dr. Ralph R. Young
Editor, SyEN
This month we provide a summary of Chapter 11, Integration Throughout the Program Life Cycle, in Integrating Program Management and Systems Engineering (IPMSE), a collaboration of the International Council on Systems Engineering (INCOSE), the Project Management Institute (PMI), and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts (USA) Institute of Technology (MIT). This is our thirteenth article in this series. Our objective in providing this series is to encourage subscribers to leverage the research base of this book that took place over a five-year period and has provided new knowledge and valuable insights that will serve to strengthen performance of complex programs. “The Book” is highly recommended as professional development for all systems engineers and is available to members of INCOSE at a discount.
Chapter 11 focuses on the distinguishing characteristics of the program management (PM) and systems engineering (SE) life cycles, the activities that occur during each life cycle, the optimal program management and systems engineering behaviors needed to achieve integration, and how the congruence of these life cycles might better enhance outcomes of complex programs in the future. The research performed during the five-year development of ‘The Book’ shows that integration of PM and SE throughout the life of a program supports its ultimate success. Integration of the PM and SE disciplines should be undertaken at all stages of a program, but, most importantly, at the inception of the program when the approach to program management is being developed, and also during the transition from the program development to operations, when integration will help to ensure successful delivery of benefits and long-term sustainability.
Therefore, a critical question for you to consider is: How can the strategic planning phase of your program be used to integrate the disciplines of SE and PM? The research indicates that greater integration between program management and systems engineering reduces unproductive tension – a cause of program delays, cost increases, and often, program failure.
Figure 11-1 in The Book shows the generic life cycle stages for a variety of projects and programs (by now, we trust that you have purchased The Book and are advancing your expertise and insight by digesting it thoughtfully). Programs typically consist of four stages: concept, development, production, and utilization.
Research found that almost no one uses systems engineering standards in parallel with program management standards.[1] How, then, can we assert that we are using “an integrated (PM and SE) approach”? And, even more importantly, what are we willing and committed to do about it?
As discussed in earlier chapters of The Book, program managers often have different roles, responsibilities, and governance structures within an organization than do systems engineers. While systems engineers focus on building the technological ingredients for the program, the program manager is concerned about the high-level interfaces between the projects they coordinate and the ultimate delivery of benefits. The management of benefits is by far the most important role of the program manager and it is integral to every aspect of a program manager’s responsibilities. To achieve integration of complex projects, systems engineers must proactively initiate and ensure effective collaboration with program managers.
An important finding of the research is that if a program delivers what is promised, the fact that the program is over budget or late is not determinative of the ultimate success of the program.[2]
The Book offers an example of the Heathrow Terminal 5 Case Study, a failure attributed to a lack of coordination (integration) between the program and the operating organizations – each operating separately. You should review and understand this case study (pp. 223-225 of The Book).
Section 11.5 provides insights concerning large-scale infrastructure programs (LIPs). INCOSE’s Guide for the Application of Systems Engineering in Large Infrastructure Projects provides a detailed overview of the unique framework and processes involved in the structure and management of these large-scale initiatives. For example, since LIPs are a part of an infrastructure system (e.g., rail systems, electricity distribution network, highway systems) the interrelationships between systems engineering, program management, and asset management are key factors for successful implementation (p. 37). When setting up a LIP, it is necessary to make sure these three fundamental disciplines work together to produce successful outcomes.
An important insight is that project management research as far back as the 1970’s shows that the ability to influence the outcome of a project is the greatest and the costs are least in the earliest phases.[3] Other research reflects the same dynamic for programs in that the front end of programs is very long – seven years on average – and often very expensive, representing up to 33% of the total budget.[4]
In complex programs, program managers and systems engineers need to work closely together, especially in defining the systems life cycle and planning key decision gates to meet their specific needs. Systems engineers may be guided by the Systems Engineering Handbook (INCOSE, 2015), while program managers may be guided by The Standard for Program Management (PMI, 2013). Though program management has overall accountability for the delivery of benefits, systems engineering has accountability for the technical and systems elements of the program. Program managers and systems engineers are both concerned with management issues, such as planning, assessment and control, meeting requirements, leading, and managing risk. The exact allocation of the systems engineering and program management duties depends on many factors, such as customer and stakeholder interactions, organizational structure of the parent organization, and relationships with affiliate contractors and subcontractors. A key finding emphasized earlier in The Book (pp. 72-73) is the need for written descriptions and defined roles for the program manager and the chief systems engineer – these are critical organizational enablers because they specify such things as:
- Areas of accountability specific to the role;
- Level of authority to make decisions, commit resources, and so on;
- Required competencies for the role; and
- Supervisory or personnel management and leadership responsibilities.
Chief systems engineers were significantly more likely to report experiencing unproductive tension than were program managers, attributing the tension to unclear expectations and authority associated with roles within the program. Decision theory states that in situations of uncertainty, decisions tend to be biased and referential.[5]
Table 11-3 in The Book identifies areas where integration may be possible, and, more importantly, where integration may make a contribution to the ultimate success of the program. Think of the potential value to you of assimilating and acting on the implications of this information!
Bottom Line
In developing complex systems, program management and systems engineering behaviors often operate in separate silos due to separate perceptions of roles, life cycles, standards, missions, goals, influences, cultures, and perspectives.
The optimal behaviors identified in this chapter are likely to enhance the probability of success on complex programs.
Food for Thought
- How can the strategic planning phase of your program be used to integrate the disciplines of systems engineering and program management?
- How can the benefits of program management and systems engineering integration be optimized throughout the program life cycle?
- What are the leadership qualities needed to achieve partnered program manager/chief systems engineer project leadership?
- What is meant by “discontinuity during the program life cycle”? How can discontinuity be prevented and overcome?
Final Note
You can expand your knowledge and insight concerning related topics by reading and reflecting on the references provided below.
References
Conforto, E., Eric Rebentisch, and M. Rossi. “Case Study Report: Improving Integration of Program Management and Systems Engineering”. Presented at PMI Global Congress North America, New Orleans, Louisiana USA, October 27-29, 2013.
Dasher, G. T. “The Interface between Systems Engineering and Program Management”. Engineering Management Journal 15(3), 11-14, 2003.
Faulconbridge, I. and M. Ryan. “Managing Complex Projects: A Systems Engineering Approach”. Norwood, Massachusetts USA: Artech House, 2011.
Greiman, V. A. “Evaluating Megaprojects: What Constitutes Success”. Rethinking Infrastructure: Voices from the Global Infrastructure Initiative, Vol. 2. London: McKinsey & Company, 2015.
Marquet, L. David. “Turn the Ship Around!” A True Story of Turning Followers into Leaders. New York: Penguin Group, 2013.
Miller, Roger and Donald R. Lessard. “The Strategic Management of Large Engineering Projects: Shaping Risks, Institutions, and Governance”. Cambridge, MA USA: MIT Press, 2001.
Miller, Roger and B. Hobbs. “Managing Risks and Uncertainty in Major Projects in the New Global Environment”. Global Project Management Handbook, pp.9-11, 2006.
Langley, M., S. Robitaille, and J. Thomas. “Towards a New Mindset: Bridging the Gap between Program Management and Systems Engineering”. INCOSE Insight, 14(3), 4-5, 2011.
Locatelli, G., M. Mancini, and E. Romano. “Systems Engineering to Improve the Governance in Complex Project Environments.” International Journal of Project Management, 32(8), 1395-1410, 2014.
Morris, P. W. G. and G. H. Hough. “The Anatomy of Major Projects: A Study of the Reality of Project Management”. Hoboken, NJ USA: John Wiley & Sons, 1987.
Paulson, B. “Designing to Reduce Construction Costs”. ASCE Journal of the Construction Division, Journal of Construction Engineering and Management. From a paper presented at the ASCE Conference, pp. 587-592, San Diego, CA USA, April 1976.
3. Article
Challenges to Systems Thinking and How to Overcome Them
by René King
Managing Editor, SyEN
Systems thinking is a holistic approach that embraces looking at a system in its entirety rather than just as a summation of its parts. Systems thinking appreciates the interrelationships between components and encourages the analysis, synthesis and understanding of the interconnections on multiple levels (e.g. social, technical and temporal). This way of thinking enhances personal and professional effectiveness and although systems thinking is not sufficient, it is necessary for every effective engineer. The benefits of systems thinking are vast, however, there are also several obstacles to the application of systems thinking due to the status quo in education, organizational structures and conditioned thinking.
As with many other issues that arise in engineering practice, systems thinking is thwarted by the education system. One of the biggest challenges is the fact that schools are organized into silos and students rarely get the opportunity to incorporate interdisciplinary thinking in undergraduate degrees. One way to combat this silo-based education paradigm is to integrate application of knowledge through guided multi-disciplinary projects and to educate students on interface management, both within a technical product and between engineering specialties.
A second challenge is overcoming the natural inclination of people to learn from experiences when there is minimal time delay between cause and effect. In real-word business and engineering, the results of decisions are sometimes observable only months or years after enforcing the change. In these cases, the effects resulting may not be intuitively linked to the cause, and if the structures to monitor results and performance are not adequate, accurate conclusions linking cause and effect may never be drawn. This means that lessons learned that contribute to our experiential knowledge may never be true to the situation that transpired. One way to address this issue is to introduce big data to deliver accurate information on parts and performance so that patterns of behavior can be accurately observed over any period of time. The utility of big data is dependent on the models that define the data. If the appropriate engineering models are not in place, the data that is monitored and obtained may not be of use in measuring the effects of an implemented change. As the world becomes more technologically inclined, it is essential for organizations to develop models that are acceptably accurate to capture the information needed to make good decisions regarding performance.
In a study conducted with 12 senior system leaders in INCOSE, each with over 20 years of experience in their companies, experiential learning was noted as having the biggest influence on systems thinking[6]. This attribute can counteract the conditioning of our mind to rely on immediate effects to draw conclusions in situations. Experiential learning can be realized through on-the-job training, working in cross-functional teams, training and education, looking at lessons learned and active mentorship. The survey participants emphasized the importance of on-the-job training in developing system engineering, especially in spending time with each component development team or as part of an Integrated Product Team (IPT). Although the human tendency to learn best through the immediacy of effect following cause is a hindrance to systems thinking, there are individual traits that have been shown to positively influence the ability to engage in systems thinking. In the same study, the senior system leaders noted the following traits as being advantageous:
- A tolerance for ambiguity
Systems are growing in complexity and there are a lot of unknown aspects involved in deciphering the problem. Being comfortable with the unknown when first analyzing a system is a highly beneficial characteristic.
- Strong interpersonal and communication skills
Communication and interpersonal skills are useful in gathering information from stakeholders when there is little known about the system.
- Curiosity and openness
This will drive a want for learning and will encourage a range of possibilities and options to be considered prior to drawing conclusions or making decisions.
A third challenge is that of limiting organizational strategies. Most companies currently provide recognition and rewards based on performances of departments within their silos. There seems to be little recognition for cross-functional performance that may be counteractive to systems thinking processes. In addition to recognition favoring segmented working and development, it is a common phenomenon observed by PPI that employees are sent for training but will never get the opportunity to put new techniques into practice. Training alone is not sufficient – support is needed throughout the process, and opportunities to apply systems thinking are necessary to embed the mindset. Organizations could reward individuals and teams that leverage the skills of other people in the organization, and cross-pollinate for integrated solutions to problems. In addition, it should be enforced that, when employees receive training they report findings to the team, department or organization as is reasonable, and that methods to integrate the techniques into company processes are devised, implemented and the results measured.
Systems thinking is beneficial not only for analyzing technology items and enterprise capabilities but also for dealing with organizations that are made up of several divisions, units and teams. Business leaders then need to demonstrate systems thinking in order to maximize organization performance. Although there are obstacles to putting systems thinking into practice, systems thinking should be embraced as a necessary competency and mindset for effective engineering and not as a tool that may or may not be used dependent on the time or resources available to do so.
Links to references and further reading may be found below:
Enablers and Barriers to Systems Thinking Development
Why do Leaders Need to be Systems Thinkers?
Even More Need for Systems Thinking
4. Systems Engineering News
Call for Papers: Diversity in Systems Engineering
From the INCOSE Website:
Empowering Women as Leaders in Systems Engineering (EWLSE) invites everyone to submit papers focusing on diversity in systems engineering and related systems areas for consideration for publication in INCOSE’s journals. We invite articles on any topic relevant to diversity, equity, and inclusion in systems related fields across industry, government, and academia.
We are especially interested in papers addressing topics that show the importance and value of diversity in enabling, promoting, and advancing systems engineering and systems approaches to address complex societal and technical challenges for a better world.
Possible topics include, but are not limited to:
- Effective techniques for overcoming the challenges of working across cultural boundaries
- Global diversity policies, best practices, and lessons learned in creating an inclusive systems engineering enabled workplace
- How building diverse systems’ teams produces optimal systems
- How diversity drives innovation and competitive advantage
- The role of diversity, equity, and inclusion in a well-prepared systems engineering workforce
- Institutional considerations or approaches for creating an open inviting systems focused culture
- Broad training in knowledge, skills, and ability that includes traditionally underserved groups
- Case studies demonstrating the importance and value of diversity in systems engineering
- Embracing diversity of thought or approach for resourceful problem-solving
EWLSE is working with INSIGHT (INCOSE’s journal on state of the practice of systems engineering) toward a dedicated Diversity in Systems Engineering themed volume in 2019. The EWLSE publications committee will also be assessing articles fit for the SE Journal. Please first send an abstract (up to 500 words) by July 31st, 2018 to receive an invitation to submit a paper, due by October 30th, 2018. Both should be sent to the EWLSE publications committee at ewlsepubs@incose.org. We welcome topics that fit within either journal.
Papers will be peer reviewed and judged on the degree of innovation, intellectual merit, described outcomes or impact, and relevance to diversity, equity and inclusion in systems engineering and related fields. EWLSE uses double-blind review for papers. Until final papers are uploaded all references to the author(s) and their institution should be redacted in some way. Citations that would identify the author(s) should state, “details withheld for review” in the bibliography. Other formatting and technical guidelines are found here. ALL authors must review the Style Guide and Citation Quick Guide before submission to ensure all requirements are met.
“Charter of Trust” Established to Strengthen Cybersecurity
At
SIEMENS Security Conference
From the SIEMENS Website:
The digital world is changing everything. Billions of devices are connected by the Internet of things. That holds great potential for everyone, but also great risk. The risk of exposure to cyber-attacks. The risk of losing control over the systems that run our infrastructures. Cybersecurity is therefore crucial to the success of our digital economy – because only if the security of data and networked systems is guaranteed will people actively support the digital transformation.
Cybersecurity is and has to be more than a seatbelt or an airbag here; it’s a factor that’s crucial to the success of the digital economy. People and organizations need to trust that their digital technologies are safe and secure; otherwise they won’t embrace the digital transformation. That’s why we are signing together a Charter of Trust bearing the principles that are fundamental to a secure digital world.
In order to keep pace with continuous advances in the market as well as threats from the criminal world, businesses and governments need to coordinate their actions in a targeted manner. We are therefore joining together to protect our democratic and economic values against cyber and hybrid threats. In this charter, the signing partners outline the key principles we consider essential for establishing a new charter of trust between society, politics, business partners, and customers.
Siemens, and the 11 Charter of Trust members, welcomed Cisco, Dell Technologies, Total and TÜV SÜD AG to its global cybersecurity initiative during National Infrastructure Week in Washington, D.C.
Joe Kaeser, President and CEO of Siemens AG, offered the following comment concerning cybersecurity:
“No company and no country is big enough or powerful enough to meet this challenge alone. That’s why all of us should work together to establish binding global rules and standards, with global leaders in their respective industries and key political representatives determined to make the digital world more secure. With the Charter of Trust, we’re off to a promising start. Now it’s time to act. Cybersecurity concerns all of us.”
Call for Papers – Special Section on Formal Approaches
Institute of Electronics, Information, and Communication Engineers
The Institute of Electronics, Information, and Communication Engineers (IEICE) Transactions on Information and Systems announces a forthcoming special section on Formal Approaches to be published in August 2019.
Formal methods and techniques play a key role in designing and developing highly reliable information systems and embedded systems. The last decades have seen various new techniques and profound theoretical results using formal methods in surprisingly many fields such as modeling, requirements analysis, specification, automatic generation of codes, testing, verification, and maintenance. They are rapidly extending their application domains as a result of the recent growth of information and communication technologies.
The Special Section on Formal Approaches aims at stimulating research on formal approaches to information systems and embedded systems, ranging from fundamental theory to practical applications. Our emphasis is put on the cross-fertilization of related research fields and encouragement of young researchers.
The major topics are listed below, but we solicit submissions in all areas of formal approaches, i.e., first to formalize information systems, embedded systems, and their environment, next to analyze their behavior and to derive their properties rigorously, and then to solve various problems in designing and managing the systems.
Theoretical foundations: all aspects of theory related to formal description and verification for structure and behavior of systems.
Formal techniques: techniques for mainly describing and analyzing systems, such as software, hardware and networks.
Formal tools: tools based on formal methods such as model checkers, theorem provers, and static and dynamic analyzers.
Applications: practical experiences of applying formal methods to information systems, embedded systems, circuits, security, AI systems, machine learning systems, automotive systems, etc.
Education: education on formal methods.
Submission Instructions:
The deadline for submission is Sep 25, 2018, 23:59 JST (GMT+9). Manuscripts should be carefully prepared according to the guideline in the “Information for Authors” (available at
http://www.ieice.org/eng/shiori/mokuji_iss.html). The preferred length of the manuscript is 8 pages. Only electronic submission through the web page will be accepted.
Submit a complete paper and transfer copyright of the paper using the IEICE Website
https://review.ieice.org/regist/regist_baseinfo_e.aspx. Authors should choose the [Special FO] Formal Approaches” as a “Journal/Section” on the online screen.
Editorial Committee:
Guest Editor-in-Chief:
Toshiaki Aoki (JAIST)
Guest Editors:
Ken Mano (NTT Communication Science Laboratories)
Hiroyuki Nakagawa (Osaka University)
Members:
Fuyuki Ishikawa (National Institute of Infomatics)
Hironobu Kuruma (Hitachi, Ltd.)
Koichi Kobayashi (Hokkaido University)
Takaaki Tateishi (IBM Japan)
Tatsuhiro Tsuchiya (Osaka University)
Shingo Yamaguchi (Yamaguchi University)
Tomoyuki Yokogawa (Okayama Prefectural University)
Further information may be obtained from the web page at:
http://www.jaist.ac.jp/~toshiaki/fa2018/
All inquiries should be sent to the guest editor-in-chief:
Toshiaki Aoki (JAIST) 1-1 Asahidai, Nomi-shi, Ishikawa, 923-1292, Japan
E-mail: toshiaki@jaist.ac.jp
Important Dates:
Submission Deadline: Sep 25, 2018 23:59 JST (GMT+9) [firm deadline]
First Notification: Nov 23, 2018
Revised Version Deadline: Jan 18, 2019
Final Notification: Mar 8, 2019
Important Notice.
(1) At least one of the authors must be an IEICE member when the manuscript is submitted for review. For the application of IEICE membership, visit
http://www.ieice.org/eng/member/OM-appli.html.
(2) When a paper has been accepted for publication, the authors are required to pay the page charges covering part of the cost of publication. Please carefully read the submission guideline at
http://www.ieice.org/eng/shiori/mokuji_iss.html.
(3) Upon acceptance for publication, all authors, including authors of invited papers, should pay the page charges covering partial cost of publication around April, 2019. If payment is not completed by May 15, 2019, your manuscript will be handled as rejection.
(4) The IEICE Transactions on Information and Systems is an open access journal from January, 2017. Open access to “IEICE Transactions on Information and Systems” is available via the J-STAGE (https://www.jstage.jst.go.jp/browse/transinf/).
Summary of the Executive Plenary Panel Systems Engineering for Complex Systems – Challenges and Issues
12th Annual IEEE International Systems Conference
23-26 April 2018 – Vancouver, Canada
provided by
John Blyler
Founder, JB Systems
Portland, Oregon USA
Figure 1. Photograph from conference panel
The changing shape of system complexity was the focus of the Executive Plenary Panel at this year’s IEEE SysCon 2018 event in Vancouver, BC. Prior to beginning the panel, the moderator and technical chair for the conference, Robert Rassa from the Raytheon Company, provided several examples of how customers influenced the systems engineering process.
“The more complex the system, the more difficult its development becomes,” observed Rassa. “The customer defines the way you’ll go about your system engineering effort. Being able to deal with this challenge is an important aspect of systems engineering.”
Following Rassa’s introduction to the topic, each panelist provided insights concerning what adds complexity to today’s systems.
The first panelist was Dr. Sidney Givigi from the Royal Military College of Canada. He observed that, in the past, most systems were developed in a model-based manner by combining different models, for example, a model of a vehicle combined with a model from sensors. A significant challenge was the manner in which different models would interact with each other. Compounding the complexity was the addition of the data component of the system.
“The models and the data driven systems must be interconnected,” explained Givigi. “The traditional way of accomplishing this was to treat the data driven part as a black box.” But this approach didn’t work in applications where the designer had to guarantee safety boundaries and/or operational limits, as in autonomous vehicles, for instance. For these situations, machine learning and other adaptive approaches must be combined with the data driven systems.
Givigi emphasized that systems engineering is required to determine the most effective way to put the components together, for example, black box data combined with rule-based systems, machine learning, and even artificial intelligence.
The next panelist added the human element to the discussion.
“In recent years, I’ve been looking more into the social-technical issues that surround the discipline of systems engineering,” explained Dr. Donna Rhodes from the Massachusetts Institute of Technology (MIT) and a past-president of INCOSE. “There are many technical issues, but we have some daunting issues that relate more to people.”
Her research indicated that social factors often dominate over technical factors when making decisions using models. For example, there are contentious situations in many organizations between very experienced senior people and far less experienced but model and technology savvy younger people. While the novices don’t particularly understand the foundations of the corporate decision making process, the senior members don’t fully understand the tools or technologies. Rhodes stressed the need to overcome these kind of culture issues in order to fully make good use of model-centric technologies.
The next panelist focused on the complexities added by cybersecurity issues. Speaking in his capacity as a private citizen (and not as a Lieutenant Colonel in the US Air Force), Logan Mailloux worried that today’s mission critical systems may not function as intended when subjected to a highly contested cybersecurity environment. His primary concern centered on globally developed and manufactured COTS technologies, uncertainties in the supply chain as to the origin of systems, and system inter-connections that obfuscate possible system states and vulnerabilities.
“Typically, we deal with complexity via standardization,” explained Mailloux. He identified three important DOD documents that help to address system-level, cybersecurity issues:
Department of Defense Instruction (DoDI) 5000.02 – Operation of the Defense Acquisition System, Enclosure 14: Cybersecurity in the Defense Acquisition System.
Defense Acquisition Guidebook (DAG); Chapter 3, Systems Engineering and Chapter 9, Program Protection Planning.
Department of Defense (DOD) Risk, Issue, Opportunity (RIO) Management Guide for Defense Acquisition Programs.
The next panelist focused on emergent systems.
“Originally, systems engineering didn’t include the word “complex,” noted Dr. Paul Hershey of Raytheon.” It’s important to remember that today’s complex systems engineering activities include complexity, systems, and engineering.”
He emphasized that complexity involves interconnected and interwoven components that can be defined in terms of emergence, a new behavior that develops as a result of the interactions among the component systems. Emergent behavior cannot be deduced from the behaviors of the individual systems themselves, whether considered individually or in subgroups.
Several examples of emergent behavior were provided in the area of big data analytics, where new forms of processing are needed to enable enhanced decision-making.
The last panelist, Dr. Vincenzo Piuri from the University of Milan, Italy, and technical conference chair, added that today’s complex systems often need to make decisions autonomously and resiliently, for example, to dynamically adjust a system to deal with degradation while aiming for maintenance. He emphasized the need for university education and continuing engineering education to deal with the complexity of today’s systems.
Space and Naval Warfare Center (SSC) Develop Tailored Process for Development of Mobile Applications
The Space and Naval Warfare Systems Center (SSC) Atlantic engineer designed a tailored mobile engineering process for the Sea Warrior Program mobility team that resulted in the development of 24 mobile applications. The SSC Atlantic provides systems engineering and acquisition to help in the delivery of information warfare to the naval, joint and national warfighter through the systems engineering life cycle to sustain interoperable command, control, communication, computers, intelligence and surveillance. One of the first roles of the team was to devise in developing this repeatable mobile engineering process was a way to take complex systems engineering and acquisition processes from the DoD Instruction 5000.02 to be more appropriate for smaller-scale mobile applications. Emily DiSalvo, the Sea Warrior Program mobility team assistant program manager, declared that the mobile apps do not need the same level of rigor that a larger acquisition program or tactical system requires. The result is a six-phase tailored mobile engineering process that includes technical reviews and a process to streamline large requirements so that apps can be put into production quickly and effectively. The DoD Acquisition process for larger systems have a typical life cycle of three to five years but the mobility team can develop an app in just a few months that has resulted in total downloads of more than 345 000 in the last three years. The apps developed include financial literacy information, general military training resources and physical fitness assessment calculators which are available on their personal devices.
5. Featured Organizations
Accreditation Board for Engineering and Technology
ABET, incorporated as the Accreditation Board for Engineering and Technology, Inc., is a non-governmental organization that accredits post-secondary education programs in applied and natural science, “computing, engineering, and engineering technology”.
ABET is a nonprofit agency for programs in applied and natural science, computing, engineering and engineering technology and is recognized as an accreditor by the Council for Higher Education Accreditation.
ABET accreditation provides assurance that a college or university program meets the quality standards of the profession for which that program prepares graduates.
ABET accredits programs, not institutions. It provides specialized accreditation for post-secondary programs within degree-granting institutions already recognized by national or regional institutional accreditation agencies or national education authorities worldwide.
Its accreditation is voluntary, and to date, over 3,800 programs at more than 770 colleges and universities in 31 countries have received ABET accreditation. Approximately 85,000 students graduate from ABET-accredited programs each year, and millions of graduates have received degrees from ABET-accredited programs since 1932.
Centre for Systems Philosophy
The Centre for Systems Philosophy (CSP), based in the U.S.A., is a not-for-profit organization funded by grants and private sponsors. The Founder and Managing Director of the Centre for Systems Philosophy is Dr David Rousseau. The Centre for Systems Philosophy was founded to support the development and promotion of Systems Philosophy as a component of General Systems Transdisciplinarity, and support the use of scientific philosophy and systems theory in addressing important problems in science, philosophy and society. Systems Philosophy is the philosophical component of Systemology, the transdisciplinary field concerned with the scientific study of all kinds of systems. In general terms Systems Philosophy arose out of the need to develop a scientific worldview that reflected the realization that everything in the concrete world is a system or part of one, with “system” being understood as “a whole that functions as a whole in virtue of the relationship between its parts”. The implication of this insight is that to properly understand something we have to understand not only its composition (as in the classical reductionistic approach), but also the relationships between its parts, between the parts and the whole, and between the whole and its environment. This calls for a change in perspective in how we conceptualize, study and engage with the concrete world. The central aim of Systems Philosophy is to articulate the systems worldview and find ways to use it to help solve important problems in science, philosophy and society.
Systems Philosophy arose specifically in the context of a search for a worldview that would appropriately reflect not only the physical complexity of the world but also the meaning, value and dignity of life and culture. The central ambition of systems philosophers from the outset has been to contribute in practical ways to scientific and humanistic efforts to build societies grounded in the values of justice, freedom, social welfare and environmental stewardship.
IEEE Technology and Engineering Management Society
The IEEE Technology and Engineering Management Society (TEMS) was formerly one of seven Councils of the Institute of Electrical and Electronics Engineers (IEEE). The Council became the IEEE Technology Engineering and Management Society (TEMS) as of 1 January 2015. Its history: The Professional Group on Engineering Management was established under the Institute of Radio Engineers in 1951. This group became the Engineering Management Society (EMS) of the IEEE in 1955. In 2007 this became the IEEE Technology Management Council (TMC) and in January 2015 the Technology Engineering and Management Society. The field of interest encompasses the management sciences and practices required for defining, implementing, and managing engineering and technology. The society publishes two peer-reviewed journals: the Transactions on Engineering Management and the Engineering Management Review. The society also publishes a popular newsletter and magazine, IEEE Leader. The society sponsors and co-sponsors a number of internationally-held conferences and events on subjects relevant to its field of interest (the flagship one being TEMSCON).
Source: Wikipedia
6. Software Supporting Systems Engineering Tools News
Professor Peter Jackson in Singapore Releases a Comprehensive Tutorial:
Introduction to Arcadia with Capella
Access tutorial here
GENESYS 6.0 Software for Systems Engineering Now Available
Vitech has just released GENESYS 6.0 systems engineering software offering a host of new capabilities and refinements specifically:
- More flexibility when filtering lists of entities
- Additional options for handling entities when folders are being deleted
- The ability to rename entities while as they are duplicated and transformed
GENESYS has been used widely in the systems engineering community to deliver integrated representation for users in developing, analyzing and communicating a system design. GENESYS 6.0 provides an interface within the Office environment which has native connectors within Excel, PowerPoint and Project to allow bidirectional transfer of data. The PowerPoint Connecter allows for presentation materials to be generated directly from the GENESYS repository. A native plug-in will allow Project to extract program management information from the GENESYS systems engineering environment into Microsoft Project directly. Furthermore, the MATLAB Connector allows for smooth interfacing of GENESYS (architectural model) and analytics (in MATLAB). Furthermore, GENESYS 6.0 allows modifications to the tracked at the level of entities and allows a textual logging of changes for auditing purposes.
There are several other features available in GENESYS 6.0. These features can be explored here.
7. Systems Engineering Publications
Systems Engineering Guidebook
A Guide for Developing, Implementing, Using and Improving Appropriate, Effective and Efficient Systems Engineering Capabilities
by
David C. Hall
Book Description:
Systems engineering, when performed optimally for your product(s), can significantly enhance your capabilities, enable your programs/projects to be completed on time and on budget, with all required functions. But we note that this is not happening in most cases. To correct this, the Systems Engineering Guidebook has been designed as a template describing “What” to do successfully in order to employ the Systems Engineering Process to implement and apply appropriate (effective and efficient) systems engineering processes and activities. The Appendices (provided in Section II) contain a description of the members of a systems engineering integrated product team (SEIPT), a suggested metrics spreadsheet, and a list of available reference documents. The objective of this Guide is to ensure that the Systems Engineering process and activities meet the needs of the Enterprise, Organization, Program, or Project while being scaled to the level of rigor that allows the system life cycle activities to be performed with an acceptable level of risk and to be measured. While all SE processes and activities apply to all life cycle stages, tailoring determines the process/activity level that applies to each stage (that level is never zero). There is always some effort in each process and activity in each stage. At the enterprise or organizational level, the tailoring process adapts external or internal standards in the context of the enterprise or organizational processes to meet the needs of the enterprise/organization. At the program level, the tailoring process should adapt enterprise or organizational SE processes and activities to the unique needs of the program. To accomplish this, the Guide describes the activities recommended for the Define, Implement, Sustain, Measure, Improve (DISMI) System Engineering Process Implementation Project.
Format: eBook
Publisher: ELSEVIER (November 22, 2017)
ISBN-13: 9780692091807
Library of Congress Control Number: 2018938448
Leading Complex Projects
A Data-driven Approach to Mastering the Human Side of Project Management
by
Edward W. Merrow and Neeraj Nandurdikar
Book Description (from the Amazon Store Website):
Leading Complex Projects takes a unique approach to post-mortem analysis to provide project managers with invaluable insight. For the first time, individual PM characteristics are quantitatively linked to project outcomes through a major study investigating the role of project leadership in the success and failure of complex industrial projects; hard data on the backgrounds, education, and personality characteristics of over 100 directors of complex projects is analyzed against the backdrop of project performance to provide insight into controllable determinants of outcomes. By placing these analyses alongside their own data, PMs will gain greater insight into areas of weakness and strength, locate recurring obstacles, and identify project components in need of greater planning, oversight, or control.
The role of leadership is to deliver results; in project management, this means taking responsibility for project outcomes. PMs are driven by continuous improvement, and this book provides a wealth of insight to help you achieve the next step forward.
- Understand why small, simple projects consistently outperform larger, more complex projects
- Delve into the project manager’s role in generating successful outcomes
- Examine the data from over 100 PMs of complex industrial projects
- Link PM characteristics to project outcome to find areas for improvement
Complex industrial projects from around the world provide a solid basis for quantitative analysis of outcomes -and the PMs who drive them. Although the majority of the data is taken from projects in the petroleum industry, the insights gleaned from analysis are widely applicable across industry lines for PMs who lead complex projects of any stripe. Leading Complex Projects provides clear, data-backed improvement guidance for anyone in a project management role.
Format: Kindle, hardcover
Publisher: Wiley; 1 edition (May 1, 2018)
ISBN:
ISBN-10: 111938219X
ISBN-13: 978-1119382195
The Strategic Management of Large Engineering Projects:
Shaping Institutions, Risks, and Governance
by
Roger Miller and Donald R. Lessard
Book Description (from the Amazon Store Website):
As the number, complexity, and scope of large engineering projects (LEPs) increase worldwide, the huge stakes may endanger the survival of corporations and threaten the stability of countries that approach these projects unprepared. According to the authors, the “front-end” engineering of institutional arrangements and strategic systems is a far greater determinant of an LEP’s success than are the more tangible aspects of project engineering and management. The book is based on an international research project that analyzed sixty LEPs, among them the Boston Harbor cleanup; the first phase of subway construction in Ankara, Turkey; a hydro dam on the Caroni River in Venezuela; and the construction of offshore oil platforms west of Flor, Norway. The authors use the research results to develop an experience-based theoretical framework that will allow managers to understand and respond to the complexity and uncertainty inherent in all LEPs. In addition to managers and scholars of large-scale projects, the book will be of interest to those studying the relationship between institutions and strategy, risk management, and corporate governance in general.
Contributors
Bjorn Andersen, Richard Brealey, Ian Cooper, Serghei Floricel, Michel Habib, Brian Hobbs, Donald R. Lessard, Pascale Michaud, Roger Miller, Xavier Olleros
Format: Kindle, paperback
Publisher: The MIT Press (March 12, 2001)
ISBN:
ISBN-10: 0262526980
ISBN-13: 978-0262526982
Turn the Ship Around!
A True Story of Turning Followers into Leaders
by
L. David Marquet
Book Description (from the Amazon Store Website):
“Leadership should mean giving control rather than taking control and creating leaders rather than forging followers.” David Marquet, an experienced Navy officer, was used to giving orders. As newly appointed captain of the USS Santa Fe, a nuclear-powered submarine, he was responsible for more than a hundred sailors, deep in the sea. In this high-stress environment, where there is no margin for error, it was crucial his men did their job and did it well. But the ship was dogged by poor morale, poor performance, and the worst retention in the fleet.
Marquet acted like any other captain until, one day, he unknowingly gave an impossible order, and his crew tried to follow it anyway. When he asked why the order wasn’t challenged, the answer was “Because you told me to.” Marquet realized he was leading in a culture of followers, and they were all in danger unless they fundamentally changed the way they did things. That’s when Marquet took matters into his own hands and pushed for leadership at every level.
Turn the Ship Around! is the true story of how the Santa Fe skyrocketed from worst to first in the fleet by challenging the U.S. Navy’s traditional leader-follower approach. Struggling against his own instincts to take control, he instead achieved the vastly more powerful model of giving control. Before long, each member of Marquet’s crew became a leader and assumed responsibility for everything he did, from clerical tasks to crucial combat decisions. The crew became fully engaged, contributing their full intellectual capacity every day, and the Santa Fe started winning awards and promoting a highly disproportionate number of officers to submarine command.
No matter your business or position, you can apply Marquet’s radical guidelines to turn your own ship around. The payoff: a workplace where everyone around you is taking responsibility for their actions, where people are healthier and happier, where everyone is a leader.
Format: Kindle, hardcover, paperback, Audiobook, Audio CD
Publisher: Portfolio; 1 edition (May 16, 2013)
ASIN: B00AFPVP0Y
Library of Congress Control Number: 2018938448
Journal of Multi-Criteria Decision Analysis
Optimization, Learning, and Decision Support
Description from Wiley Online Library
The Journal of Multi-Criteria Decision Analysis was launched in 1992, and from the outset has aimed to be the repository of choice for papers covering all aspects of Multi-Criteria Decision Analysis/Multi-Criteria Decision Making (MCDA/MCDM). The journal provides an international forum for the presentation and discussion of all aspects of research, application and evaluation of multi-criteria decision analysis, and publishes material from a variety of disciplines and all schools of thought. Papers addressing mathematical, theoretical, and behavioral aspects are welcome, as are case studies, applications and evaluation of techniques and methodologies.
The recent appointment of Theodor Stewart as Editor-in-Chief (following on from Simon French and Valerie Belton) is linked to a restructuring of the editorial processes. Nine topic areas within MCDA/MCDM/multi-objective optimization have been defined, and Area Editors have been appointed for each area:
- Analytic hierarchy/network processes
- Evolutionary multi-objective optimization
- Fuzzy sets and models for MCDA
- Integrated methods and philosophy of MCDA
- Multi-objective optimization and goal programming
- Outranking
- Risk and uncertainty in MCDA
- Rule-based methods and artificial intelligence
- Value and utility models
- The purpose of this restructuring is two-fold:
- To more formally involve representatives of different MCDA/MCDM/multi-objective groups into the editorial process
- To spread the editorial load more widely so as to achieve a more rapid turnaround in editorial decisions.
The broadened focus of the journal and the editorial changes above are also now reflected in the title and subtitle of the journal: Journal of Multi-Criteria Decision Analysis: Optimization, Learning and Decision Support.
The Editors and Publisher acknowledge the continued support of the International Society on Multiple Criteria Decision Making in helping to make the journal properly represent the importance of the field within the broader OR/MS context.
Understanding A3 Thinking
by
Durward K. Sobek II and Art Smalley
Book Description (from the Amazon Store Website):
Notably flexible and brief, the A3 report has proven to be a key tool In Toyota’s successful move toward organizational efficiency, effectiveness, and improvement, especially within its engineering and R&D organizations. The power of the A3 report, however, derives not from the report itself, but rather from the development of the culture and mindset required for the implementation of the A3 system. The authors first show that the A3 report is an effective tool when it is implemented in conjunction with a PDCA-based management philosophy. Toyota views A3 Reports as just one piece in their PDCA management approach. Second, the authors show that the process leading to the development and management of A3 reports is at least as important as the reports themselves, because of the deep learning and professional development that occurs in the process. And finally, the authors provide a number of examples as well as some very practical advice on how to write and review A3 reports.
Format: Kindle, hardcover, paperback
Publisher: Productivity Press; 1 edition (March 7, 2008)
ISBN:
ISBN-10: 1563273608
ISBN-13: 978-1563273605
8. Education and Academia
University of Engineering and Technology, Lahore
Punjab
The University of Engineering and Technology is located in the northern part of Lahore on the historical “Grand Trunk Road (G.T. Road)” near the magnificent Shalimar Gardens built during the great Mughal Empire. The institution was founded in 1921 as the ‘Mughalpura Technical College’. Later it became the ‘Maclagan Engineering College’, a name given to it in 1923 when Sir Edwards Maclagan, the then Governor of the Punjab who laid the foundation stone of the main building, now called the Main Block, which still retains its majesty despite the wear and tear of over eight decades. At that stage the institution offered courses of study in only two disciplines; Electrical Engineering and Mechanical Engineering. In the year 1932, the institution was affiliated with the University of the Punjab for award of a Bachelor’s Degree in Engineering. In 1947, at the time of independence, the Institution was offering well-established B.Sc. Degree Courses in Civil, Electrical and Mechanical Engineering. In 1954 it started a Bachelor’s Degree course in Mining Engineering, the first-ever of its kind in the country. However, the real expansion and development of the institution commenced in 1961 on its transformation into the ‘West Pakistan University of Engineering & Technology’, and within a few years Bachelor’s Degree Courses were started in Chemical Engineering, Petroleum & Gas Engineering, Metallurgical Engineering, Architecture, and City & Regional Planning. Later, the University started to develop its postgraduate programs, and by the 1970’s it was offering Master’s Degree Courses in various specializations of engineering, architecture, planning and allied disciplines. A Ph.D. Degree Program was instituted in a number of disciplines. With phenomenal increase in student enrollment in the seventies, the University established an Engineering College at Taxila in 1975.
Norwegian University of Science and Technology
(NTNU)
The Norwegian University of Science and Technology is a public research university with campuses in the cities of Trondheim, Gjøvik, and Ålesund in Norway, and has become the largest university in Norway, following the university merger in 2016. NTNU has the main national responsibility for education and research in engineering and technology, originated from Norwegian Institute of Technology. In addition to engineering and natural sciences, the university offers higher education in other academic disciplines ranging from social sciences, the arts, medical and life sciences, teacher education, architecture and fine art. NTNU is well known for its close collaboration with industry, and particularly with its R&D partner SINTEF, which provided it with the biggest industrial link among all the technical universities in the world.
9. Some Systems Engineering-Relevant Websites
Wicked Problems and Requirements Engineering
A blog capturing the debate about whether or not requirements engineering is to be considered a wicked problem as described by ‘Wikipedia’.
https://www.wickedse.com/single-post/2017/09/24/WPRE
Soft Systems Methodology Knowledge Center (Peter Checkland)
A site dedicated to applying systems thinking to non-systematic situations. The website gives a thorough explanation of Checkland’s Soft Systems Methodology. The page contains links to methods, models and theories related to communication, decision-making and valuation and ethics and responsibility.
https://www.12manage.com/methods_checkland_soft_systems_methodology.html
Soft Systems Methodology – A Report by Dale Couprie, Alan Goodbrand, Bin Li, and David Zhu, Department of Computer Science, University of Calgary
An online guide containing information on the soft systems methodology spanning a range of topics such as naming relevant systems, developing conceptual models, comparing conceptual models with reality and implementing desirable changes.
http://plaza.ufl.edu/jtruett/abe5643c/ssmfinal.html
Blog: Systems Thinking is an Engineering Habit of Mind by Engineering is Elementary (EIE)
A blog containing information about strategies for promoting systems thinking amongst children. The site describes methods for developing systems thinking in students in ways that move beyond remembering facts and include techniques such as invention and evaluation to develop engineering skills in a hands-on fashion.
http://blog.eie.org/systems-thinking-skills-in-the-engineering-classroom
10. Standards and Guides
ISO-IEC-IEEE-42010 Survey
The Practical Use of UML for Different Architectural Viewpoints
ISO/IEC/IEEE 42010 Systems and Software Engineering — Architecture Description is an international standard for architecture descriptions of systems and software. ISO/IEC/IEEE 42010:2011 defines requirements on the description of system, software, and enterprise architectures.
Unified Modeling Language (UML) is nowadays the top-used software modeling language that offers many different diagrams for specifying and designing software systems, such as class, object, component, package, deployment, activity, sequence, timing, and state diagrams. Many practitioners essentially use UML diagrams for modeling software architectures from different viewpoints (aka perspectives). In this survey, the goal is to understand practitioners’ choice of the UML diagram(s) for different architectural viewpoints. The survey focuses on six different architectural viewpoints, i.e., functional, information, concurrency, development, deployment, and operational.
Participation in this survey is voluntary. Participants may withdraw by not submitting the survey at any time. Depending on your answers, this survey takes approximately 5 to 15 minutes to complete (Almost all questions are radio buttons/checkboxes).
No identifying information will be collected and all participants shall remain anonymous. Collected data are planned to be published as a research article.
By clicking through the consent statement and submitting the completed survey, individuals are indicating their willingness to participate.
Your time and input are sincerely appreciated!
If you have any questions about the survey, please contact Dr. Mert Ozkaya (mert.ozkaya@kemerburgaz.edu.tr) or Ferhat Erata (ferhat.erata@unitbilisim.com).
The survey is accessible here.
A Semantic Framework for Systems Engineering Standards
by
David Price, Allison Barnard Feeney, and Dr. Albert Jones
Abstract
Systems engineers and asset managers create and maintain models of components and systems associated with long-lived, engineering assets. Component models come from many domains, disciplines and applications. System models typically require integration of these component models. This paper presents the results of an investigation into the convergence of three distinct themes: the growing numbers of standards for engineering data, the maturing of Semantic Web technology, and a framework for architecting and relating engineering vocabularies and data. This investigation sought to determine whether these themes, used together, could enable industry to make significant progress toward model-based systems engineering in the areas of collaboration, knowledge management, data integration and timely decision-making. This paper argues that semantic technologies have matured to the point where they should be the preferred choice for developing future standards and frameworks.
11. Some Definitions to Close On
Occam’s Razor
Occam’s razor is a problem-solving principle attributed to William of Ockham (c. 1287–1347), who was an English Franciscan friar and scholastic philosopher and theologian. The principle can be interpreted as stating that among competing hypotheses, the one with the fewest assumptions should be selected. Source: Wikipedia.
The Historical Roots of Concurrent Engineering Fundamentals
An Article by R. P. Smith that was published in IEEE Transactions on Engineering Volume 44 Issue 1
February 1997
Abstract
This paper explores the history of the ideas behind concurrent engineering from the end of the 19th Century until the 1960s. Concurrent engineering is the relatively recent term that is applied to the engineering design philosophy of cross-functional cooperation in order to create products that are better, cheaper, and more quickly brought to market. The principles of concurrent engineering that are traced by this paper are: manufacturing and functional design constraints need to be considered simultaneously; combining of people with different functional backgrounds into a design team is a useful way to combine the different knowledge bases; engineering designers must bear in mind customer preferences during the design process; and time to market is an important determinant of eventual success in the market. None of these principles is by itself surprising; concurrent engineering has led to their propagation to many people and firms in the engineering world. The author has examined the engineering literature in order to locate the existence of similar themes in published engineering thought. All of these themes have recurred often in the literature. Concurrent engineering can be seen therefore as a summary of best practice in product development, rather than the adoption of a radically new set of ideas. The paper suggests some reasons that concurrent engineering ideas may not have been adopted more widely.
Editor’s Note: Concurrent (simultaneous) engineering has very early origins and it is industry-wide. The article attributes to concurrent engineering concerns that are not usually associated with the term, specifically “engineering designers must bear in mind customer preferences during the design process” (critically important as that is, it actually has no direct relationship to concurrent engineering). Concurrent engineering doesn’t say that “time to market is an important determinant of eventual success in the market”. It may be, or it may not be. Concurrent engineering is promoted as, and has a history of, reducing development costs and timescales, and increasing product quality, irrespective of the purpose in doing so.
https://ieeexplore.ieee.org/document/552809/
12. Conferences and Meetings
For more information on systems engineering related conferences and meetings, please proceed to our website.
13. PPI and CTI News
Come say “G’Day” to PPI at the INCOSE International Symposium 2018 in Washington DC
PPI will be exhibiting at the upcoming INCOSE International Symposium over 07 to 12 July, 2018. PPI is particularly proud to have participated in every INCOSE Symposium since 1992. This year’s Symposium theme is “Delivering Systems in the Age of Globalization”. The Symposium provides a terrific opportunity for delegates to engage with others of the world systems engineering community, to learn and to improve the practice of engineering. For further details about this year’s Symposium or to see how the conference can benefit your professional development or your company, visit the IS website here. See you there!
14. PPI and CTI Events
For a full course schedule please visit https://www.ppi-int.com/training/
Systems Engineering 5-Day Courses
Upcoming locations include:
- London, United Kingdom
- Eindhoven, the Netherlands
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
- Melbourne, Australia
- Wellington, New Zealand
Systems Engineering Management 5-Day Courses
Upcoming locations include:
- Ankara, Turkey
- Münich, Germany
Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses
Upcoming locations include:
- Amsterdam, the Netherlands
- Washington, D.C., United States of America
Architectural Design 5-Day Course
Upcoming locations include:
- Stellenbosch, South Africa
- London, United Kingdom
Human Systems Integration Public 5-Day Courses
Upcoming locations include:
- Melbourne, Australia
CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)
Upcoming locations include:
- Laurel, MD, United States of America
- Madrid, Spain
Other training available for on-site only include the:
- Project Risk and Opportunity Management 3-Day Course
- Managing Technical Projects 2-Day Course
- Integrated Product Teams 2-Day Course
- Software Engineering 5-Day Course
15. Upcoming PPI AND CTI Participation in Professional Conferences
PPI will be participating in the following upcoming events.
(Exhibiting)
7 – 12 July 2018 Washington, D.C., USA
The International Symposium on Military Operational Research
(Sponsoring)
17 – 20 July 2018
Surrey, UK
(Sponsoring)
3 September 2018
Zurich, Switzerland
(Exhibiting)
4 – 6 September 2018
Adelaide, Australia
INCOSE Western States Regional Conference
(Sponsoring)
20 – 22 September 2018
Ogden, Utah, USA
(Exhibiting & Sponsoring)
3 – 5 October 2018
Pretoria, 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 USA: +1 888 772 5174
Web: www.ppi-int.com
Email: contact@ppi-int.com
Copyright 2012-2018 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.
- Conforto, Rebentisch, and Rossi, 2013. Systems engineers could, for example, familiarize themselves with The Standard for Program Management, published by the Project Management Institute (PMI), available here. ↑
- Greiman, 2015. ↑
- Paulson, 1976. ↑
- Miller and Hobbs, 2006. ↑
- Kahneman and Tversky, 1979. ↑
- The study is described in Enablers and barriers to systems thinking development: Results of a qualitative and quantitative study by Heidi L. Davidz, Deborah J. Nightingale and Donna H. Rhodes (see link at the end of the article) ↑
