SPECIAL EDITION

 

Systems engineering and project management - crossing the great divide

 

 

R. Oosthuizen^*; S.J. Benade

Department of Engineering and Technology Management, University of Pretoria, South Africa. R. Oosthuizen: https://orcid.org/0000-0002-2333-6995; S.J. Benade: https://orcid.org/0000-0002-6508-4407

 

 

---

ABSTRACT

Project management (PM) and systems engineering (SE) practitioners and academics experience various challenges regarding meaningful interaction while seeking project success. This situation exists despite sophisticated PM and SE software tools, the existing body of knowledge documents of different professional bodies, and numerous publications addressing this challenge. Generally, projects are fragmented from their initiation on the highest level into a 'technical' process and a project management process. This paper summarises the outcomes of several research projects undertaken from 2012 until recently to analyse the problem. The outputs of these studies are also compared with contemporary research to present an understanding of the problem and to suggest potential solutions to improve PM and SE interaction. The aim is to provide a starting point for future-focused research to evaluate the proposed improvements.

---

OPSOMMING

Projekbestuur en stelselingenieurswese praktisyns en akademici ervaar verskeie uitdagings rakende betekenisvolle interaksie om projeksukses te behaal. Hierdie probleem situasie bestaan ten spyte van gesofistikeerde sagteware, die groot hoeveelheid riglyne van verskillende professionele organisasies, en talle publikasies wat hierdie uitdaging aanspreek. Oor die algemeen word projekte gefragmenteer vanaf hul aanvang op die hoogste vlak in 'n 'tegniese' proses en 'n projekbestuursproses. Hierdie artikel som die uitkomste op van verskeie navorsingsprojekte wat vanaf 2012 tot onlangs onderneem is om die probleem te ontleed. Die uitsette van hierdie studies word ook vergelyk met kontemporêre navorsing om 'n begrip van die probleem te bied en om potensiële oplossings voor te stel om pojekbestuur en stelselingenieurswese interaksie te verbeter. Die doel is om 'n beginpunt te bied vir toekomsgerigte navorsing om die voorgestelde verbeterings te evalueer.

---

 

 

1 INTRODUCTION

Blanchard and Blyler [1] argue that a product designed and developed by the systems engineering (SE) process requires an organisation with an associated project structure and governance to bring the required solution into being. Project management (PM) focuses on the product creating phases, while SE is concerned with the product system's architecture, function, and behaviour over the whole life cycle. The project manager typically represents the customer and controls the project budget and schedule. The power base of the PM typically is 'money' to determine how the project activities are executed to produce the end- item [2], [3].

Nicholas and Steyn [4] agree that the SE team has the technical expertise to design and create a technical solution. SE defines what the end-item or product (project deliverable) must do to satisfy the user's requirements. Over time, systems became more extensive and more complicated in their constituent elements, processes, and technologies. This evolution has probably resulted in the specialisation of tasks such that certain people would focus on the technical aspects while others would manage the integration of various elements [4].

Henry et al. [5] note that PM and SE are inextricably linked. Still, they are viewed as separate disciplines by the literature, learning institutions, and organisations with independent PM and SE functional structures. PM and SE have independent societies, standards, bodies of knowledge (BoK), structures within organisations, and people with conflicting roles and responsibilities. The modern disciplines of PM and SE have developed separately, each with its methods, tools, and approaches. The different cultures, competencies, and accountabilities affect their interrelationship. As a result, significant overlaps and conflict areas between SE and PM exist [5], [6].

Langley et al. [7] found that the independent development of PM and SE also created a cultural barrier between practitioners and academics of the two domains, which causes friction and animosity when addressing the project's key stakeholders, work, planning, implementation, and control. The constant tug of war between the two roles and disciplines wastes emotional energy and negatively impacts performance. Therefore, a positive interrelationship between SE and PM is crucial to project success. Overlapping aspects between PM and SE can be on the business, technical, budgetary, and management aspects. These areas can be interlinked, interactive, and dynamic during various life cycle phases of a system [8].

A project's work must meet the system requirements and specifications. The system requirements and specifications must also conform to the project constraints (strategy, budget, work methods, technologies, capabilities, project-defined risk profiles, etc.). These interrelationships are concurrent and cyclical. The project team members must have clear roles, responsibilities, and accountability, with a common organisational culture for project success [8]. Research on the collaborative application of PM and SE only appeared around a decade ago when various initiatives were undertaken in the International Council on Systems Engineering (INCOSE) and the Project Management Institute (PMI) [9]. This research investigates the interrelationship between PM and SE through a largely exploratory approach to identify the overlap of critical elements between the two domains.

This paper concludes a longitudinal study based on the outcomes of several research projects between 2012 and 2019. These research projects used various survey and interview methodologies, with content analyses, to identify problems, shared areas of responsibility, and different views on improving the interaction between SE and PM. The paper first presents a literature review of SE and PM as well as their relationship and interactions. A description of the research methodology follows this before the findings and discussions are presented. The research in this paper then analyses the literature on SE and PM processes and problems to gain an in-depth understanding. Then, important SE and PM integration interfaces and some common or similar issues are identified as a gap analysis. The aim is to find solutions that bridge the gaps and improve integration. The objective of extracting a single set of elements that significantly impact both the PM and the SE domains is not intuitive. Therefore, the complex interrelationships between the two disciplines are presented in a systemigram at the end of the paper.

 

2 LITERATURE REVIEW

2.1 Systems engineering

INCOSE describes SE in their handbook as "an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early..." [10]. Eisner [11] defines SE as "an iterative process of top-down synthesis, development and operation of a real-world system that satisfies, in a near-optimal manner, the full range of requirements for the system". SE is also described as "an interdisciplinary collaborative approach to derive, evolve and verify a lifecycle balanced system solution that satisfies customer expectations and meets public acceptability" [12]. SE processes assist engineers to transform an operational need into a preferred system configuration and performance description. The solution design must integrate reliability, maintainability, usability, safety, producibility, and other aspects into the effort to meet all cost, schedule, and performance objectives. Thus SE is not a stand-alone discipline, but is fully interrelated with the supporting enterprise processes.

The SE technical processes primarily focus on system design. The emphasis is on the thorough analysis and definition of stakeholder requirements, the identification of required functions, and concept system identification and selection [13], [14]. In addition, the design process must address the total system over the whole life cycle, and consider the necessary technologies and potential suppliers for a make or buy decision.

Walden et al. [13] highlight how systems engineering management processes and other organisational processes enable the technical SE processes as the 'creating system', while the delivered output is the 'created system'. Some SE technical processes overlap with PM processes. For example, SE and PM typically address business and mission analysis and stakeholder management. PM focuses on integrating the processes during the execution part of the project, while SE focuses on integrating the system to be designed and delivered. The agreement and organisational project-enabling processes are administrative, and the same (or similar) goes for SE and PM.

Walden et al. [13] explain how SE is applicable over the system's total life cycle. Still, the real value lies in the early phases and development stages and later system upgrades. The customer's needs and associated analysis define both the project and the solution requirements. The SE process designs and develops the solution (the created system) to satisfy stakeholder needs and requirements. However, this process requires an enabling organisation with an associated project structure to bring the required solution into being (also referred to as the creating system). Therefore, it is essential to tailor the SE process to suit the specific project and organisation. The management processes constitute the creating system, while the delivered output is the created system [1], [12].

 

Figure 1

 

PM and SE are inextricably linked, and the two disciplines must be aligned for an organisation, programme, and project to be effective and efficient. Therefore, the correct integration and interrelationship between SE and PM must be established early [13]. An analysis of 209 interviews with open-ended questions identified some SE challenges in this context [15]:

1. Lack of SE capability and training. Team members often have only a superficial knowledge of SE (understanding, knowledge, skills, and training), leading to frustration, confusion, and the SE team's demotivation.

2. Inadequate requirements and stakeholder management. The lack of continuous stakeholder involvement prevents the meaningful definition of the project scope (performance, schedule, and cost) at the project's initiation, hampers requirements management, and causes scope creep.

3. Inadequate inter-departmental integration and communication. Communication between SE team members, especially across organisational boundaries, is often lacking. Managing technical and other system changes under these circumstances become complicated.

4. Negative and sceptical attitude towards SE. Often senior management, customers, and project managers doubt the value of SE, especially in non-traditional SE industries. People working in operations and maintenance environments (process plants, utilities, etc.) often ignore SE.

5. Lacking SE process, standards and practices. Companies find it challenging to implement and standardise suitable SE processes because they do not understand the underlying SE principles. Implementing different SE processes on various projects in an organisation confuses teams and makes it challenging to compare planning and execution.

6. Ineffective design process. Design processes are not sufficient or integrated. Not all stakeholders are involved, and concept selection stages are downplayed. Speciality engineering expertise (e.g., reliability, maintainability, ergonomics, safety) are usually not applied early in the design process, causing numerous unplanned redesigns, inadequate configuration control, cost overruns, etc.

7. Lack of project or technical resources. Real-world constraints on resources for projects limit the ability to perform the process tasks to the required level.

8. Ineffective technology management. Identifying appropriate technologies for the end-user environment during system design is often neglected, causing technology misfits during operation. New technologies also have higher risks and uncertainty than existing technologies.

These SE challenges are also dependent on and influenced by one another in various ways.

2.2 Project management

Nicholas and Steyn [4] describe how PM originated from civil engineering and construction endeavours throughout history. Examples include the Egyptian pyramids, and bridges, waterways, and agricultural systems of ancient times. However, as the size of the projects increased over time, engineers had to perform increasingly complicated design calculations while working with advanced construction techniques and materials. As a result, the management processes of projects became ever more separated from the scientific and technical methods.

Several PM professional bodies publish their own project management body of knowledge (PMBOK) and associated documents - for example, PMI, the International Project Management Association (IPMA), the Construction Industry Institute (CII), and PRINCE II. PM processes are defined in the PMI PMBOK as 'process groups' with associated 'knowledge areas' [6]. The PM knowledge areas include project scope, schedule, and cost, which are typically the project manager's critical challenges. Project stakeholder management was added to the list of knowledge areas in the latest version of PMBOK. PM and SE practitioners' different interpretations of PM knowledge areas are discussed in-depth as part of the results later in the paper. Research by Benade [15], and Cerpa and Verner [16] also identified PM challenges:

1. Organisational structure. Often the organisational structure does not support successful project management. Dependence on other business units in the organisation poses significant problems in executing projects effectively.

2. Resources and budget constraints. Project managers experience a lack of resourcing from customers and senior management, leading to work overload, high stress levels, and often demotivated work teams.

3. Inadequate requirements. The absence of an effective requirement management process causes an ill-defined project scope, and scope creep negatively impacts resource management.

4. Low project maturity in the company. An unacceptably low PM maturity is experienced in most companies owing to inadequate PM education and training.

5. Stakeholder management. Key stakeholders' identification, participation, and commitment is a serious problem because, in large organisations, project managers are not involved in all project phases/stages, causing frustration and integration problems.

6. Unrealistic cost and schedule expectations. Project managers have experienced unrealistic expectations and pressure from customers and senior management to meet project deliverables. Meeting technical (performance) requirements is perceived as a smaller problem than delivering within cost and time constraints.

7. Supplier management. Unreliable service providers and low-quality work cause project delays and overspending. Cumbersome, ineffective, and unsupportive internal company processes are inadequate, and can lead to legal problems.

8. Information and communication management. Communication within a project, across organisational boundaries, and among project team members remains challenging.

Shenhar and Dvir [17] noted that conventional PM methods for 'linear projects' cannot cope with non-linear project dynamics - and development projects are typically non-linear. The result is wrong estimations and unexpected iterations, causing long delays in the projects. Cerpa and Verner [16] noted that some of these factors would be improved when using an SE approach to these projects.

2.3 The relationships between systems engineering and project management

Lang and Stratton [18] asserted that successful PM relies on understanding the relationships between unique elements of each discipline (including SE) and integrating them. Developing and fielding a product into operation requires business management, technical management, and contract management. SE is the technical management part of PM to resolve the dichotomy of customer or business needs, technology developments, and a calendar-driven budget. The role of the systems engineer includes the management activities of PM (initiating, planning, execution, monitoring/controlling, termination/closeout) applied to all the elements of SE. Thus PM focuses on the managerial aspects, while SE is all about the technical management elements. The project manager and the systems engineer/manager (project engineer) are also intrinsically connected. The interrelationship and dependency between PM and SE derived from INCOSE's handbook [13] and PMBOK [6] are based on the following:

1. PM involves planning, applying, and controlling funds, personnel, and physical resources to achieve a specific result.

2. SE is the process of managing stakeholder requirements (including end-user requirements), requirement analysis, solution selection, architectural design, implementation, system integration, verification, transition, validation, andlessons learned.

3. Requirements management, when shared between the two disciplines, is managing the business process, finances, and technical baselines. These also include the scope and quality management of the product (the system).

Different industries often use similar processes for PM and SE, but with other descriptions. Also, the life cycles of the integrator (mines, process plants, power generation, and construction projects) and manufacturer (material, component, product, and system manufacturers) companies differ significantly. Integrators would focus on high-level requirements, modelling the system, identifying suppliers, managing various contracts, and final integration. Manufacturers often have their design and development group. Integration between, for example, design, manufacturing, operations/maintenance, and marketing is more straightforward and quicker to respond to scope and requirement changes [11], [12].

The project manager defines the roles and responsibilities of the project team members. Dasher [19] highlighted that a clear definition of roles and responsibilities and how the teams effectively work together is vital to project success. However, the project manager and the chief engineer should be 'joined at the hip', with neither functioning without the other. A close and trusting relationship with open and honest communication between the project manager and the systems engineering manager will lead to project success.

Unfortunately, the interrelationship between PM and SE is not intuitive. A joint survey by PMI and INCOSE on improving the integration of PM and SE [9] revealed unproductive tension between the PM and SE roles. Sources of tension include the roles, responsibilities, and accountability between the project manager, the systems engineer, and the resident organisation caused by a lack of integrated planning of projects [8], [19]. In addition, PM tends to focus on isolating processes from the business, the life cycle, and SE [6].

Forsberg, Mooz and Cotterman [3] identified PM and SE roles to maintain interdependency while managing the project requirements. During the project, congruence between the business case, the budget, and the technical baselines is vital to success. The budget and schedule must enable the achievement of the technical requirements. Conversely, the technical specifications must be achievable within the budget and the schedule. Otherwise the project is usually doomed and unrecoverable - unless the inconsistencies are resolved early. Effective integration between PM and SE should increase performance [9].

 

3 RESEARCH METHODOLOGY

Shadish et al. [21] define a longitudinal study as making repeated observations of the same variables within a similar context over a short or long time. This methodology is often applied to study developmental trends across the life span of a setting or scenario in clinical psychology and other social fields. Longitudinal studies tend to track phenomena or problems across generations by observing the state of the world without any manipulation. Because this methodology performs repeated observations of a situation, a better understanding may be gained than from cross-sectional observational studies. The disadvantages of longitudinal research include the difficulty of maintaining focus, its expense, and its time-consuming nature. However, it may provide unique insights that are not otherwise achievable [22].

For this paper, the data had already been captured by a series of studies on the relationships between SE and PM that were performed by various students at the Graduate School of Technology Management at the University of Pretoria between 2012 and 2019. The outcomes of these research projects were integrated and compared with the contemporary literature on the research. Owing to the complex nature of the interactions, mapping them was not easy. For this reason, the systemigram, a systems thinking tool, was constructed, as may be seen in Section 4.3.

 

4 FINDINGS AND DISCUSSIONS

4.1 Problems between systems engineering and project management

Both INCOSE and PMI have recognised the gap, and have published a joint statement expressing their commitment to closing it [7]. Accordingly, they have investigated ways to improve PM and SE integration and reduce tension. The aim was to identify PM and SE best practices with the lean enablers for managing engineering programmes. The independent development of SE and PM and cultural barriers cause a disintegration of the two processes, resulting in a sub-optimal solution for customers that costs more and takes longer to deliver [9].

According to the SEBoK, most failures that surface in projects are linked to schedule, cost, and performance [5]. Most projects' problems are also due to upstream issues at the beginning of the project or systems creation [8]. Project managers are generally responsible for the cost and schedule performance. However, the technical solutions are developed outside their control by systems engineers [3]. The perceived gaps and problem areas in the combined use of these two disciplines are [9], [11]:

1. Role. The differences in PM and SE roles cause misunderstandings and different work styles, leading to conflict and frustration. Systems engineers focus more on technical performance, while project managers are concerned about balancing quality, cost, and schedule to satisfy the client. As a result, project managers are under pressure to deliver results according to a schedule [9], [11], [23], [15].

2. Responsibility. The differences in responsibility and authority between project managers and systems engineers are not always apparent. Therefore, their expectations and duties need clarification to find a balance interdependently without causing friction. PM is primarily responsible for delivering the project to the stakeholders on time, on budget, and on brief, while SE is concerned with satisfying stakeholders' requirements [9], [20], [15].

3. Planning. Project managers are more optimistic in their planning than systems engineers, as they want to satisfy the clients and management. On the other hand, systems engineers are more in touch with technical complexities and the need for iterations, resulting in a lack of integrated planning that considers different views. However, the outcome might be worse if the project managers performed their planning in isolation. As a result, the planning objectives and responsibilities are unrealistic and are not validated by SE [8], [9], [11], [15].

4. Organisation. The organisation needs to provide corporate support that clarifies accountability, responsibility, and the interface between PM and SE. Often the job position is not clearly defined, and progress is insufficiently monitored [9], [11].

5. Knowledge. Inadequate technical skills hamper the combined performance of SE and PM [11]. The information gap between the two interdependent fields is a root cause of many project failures [8].

6. Management. The line managers affect the PM vs SE interface. Line management needs to clarify the reporting lines, authority, and responsibility for the PMs and SEs. However, the mismanagement of project culture, team competency, and knowledge may cause interrelationship problems between the two domains [9], [23].

7. Process. SE and PM practices and processes may conflict or not be sufficiently detailed [9], [23].

8. Interfaces. Systems engineers should continually interact with project managers; however, this does not often happen in practice. The interface between PM and SE may not be defined, leading to poor communication, coordination, and teamwork. The interface is required to exchange information for management and planning [8], [11], [13], [15].

9. Requirements management. Poor requirements management is often cited as a leading cause of project failure. This is because requirements tend to be wrong, incorrectly validated, and not managed. The stakeholder requirements also tend to change as the project progresses, placing a priority on management [8], [9], [12], [24]-[27].

10. Tools. Tools that jointly support PM and SE are lacking. The currently available tools are based only on PM standards [28].

4.2 Solutions to improve SE and PM integration

The role of systems engineering management has been identified as essential in managing the SE process or the project-product ensemble. However, the effective integration of the PM and SE domains remains a concern to practitioners. The interrelationship between PM and SE significantly affects the project's success. However, improving the interaction requires different approaches in addressing the key stakeholders, work, planning, implementation, and control [9]. The conceptual framework identified from the theory proposed the following solutions to improve the integration:

1. Integrated planning. The project manager plays a significant role in schedule compliance, and needs to drive it. Systems engineers support project managers with collaborative and detailed planning. Traceability between the project management plan (PMP) and the systems engineering management plan (SEMP) can improve interaction as translation tools. It is essential that the SEMP is consistent and evolves with the PMP using an ontology, a life-cycle model, and an integrated project plan [12], [15], [29].

2. Shared responsibility in critical areas. Project managers and systems engineers work as a team and complement each other. Therefore, it is essential to resolve the understanding of accountability with the project team. Clear roles and responsibilities provide a teamwork framework to achieve the project objectives with the necessary flexibility. In addition, roles and responsibilities can change during the project phases, and the transitions must be carefully planned and managed. Systems engineers take responsibility for all of the technical deliverables and associated risks [28]. Project managers handle non-technical risks. However, sharing responsibility for risk management, quality, life-cycle planning, and external suppliers will improve project execution [9].

3. Organisational influence. Improving the interface between SE and PM will reduce conflict. Projects exist within organisational structures. PM and SE are governed depending on the organisational structure (functional, matrix, or project). This provides the project manager and the systems engineer with different levels of authority and control. In some cases, SE is subordinate to PM, and in other instances, PM provides support to SE. In all cases, the organisational and governance relationships must be clarified and clearly communicated to the project manager and the systems engineer who are working together. The interface with the organisation is also an important aspect to explore to improve project success.

4. Communication. The proximity of the offices of project managers and systems engineers may enable them to communicate and learn from each other. SE and PM require a common language and practice to be successful [23], [15].

5. Training. The project manager and the systems engineer must complement each other with training in their own role and the other's role. Benefits are derived from project managers having SE knowledge and technical background (experience) [3]. This may be achieved by implementing mentorship and training for SE and PM to cooperate [23].

6. Project team composition. The most significant factors impacting the project manager and the systems engineer/manager's relationship are their personalities and character, which need to enable them to work together on a project [23].

7. Integrative management. The framework defines managers, teams, plans, the systems approach, methods and standards, information management and systems, and the enterprise as contributors to integration [9], [11]. Current research focusing on standards and processes considers how the processes can be integrated and how standards can assist project managers and systems engineers. This can be addressed through process integration, formal decision-making processes, and traceability [28].

8. Using standards from both domains. The standards from both the SE and the PM domains can be applied to formalise integration, integrated programme assessments, and sharing responsibility in critical areas such as risk management, quality management, life-cycle planning, and supplier management [9].

Since these elements contain the characteristics of a complex system, systems thinking tools may support understanding and addressing them, as may be seen in the next section.

4.3 Systems thinking and systemigrams

Boardman [30] originally developed the systemigram (systemic diagram) in 1994 as a powerful graphical tool to help analyse systems to understand complex problems. Systemigrams help to translate a system problem from structured text into a storyboard-type diagram that describes the system's principal concepts, actors, events, patterns, and processes. Systemigrams are substantially more than causal loop diagrams, and their main thrust is to tell a story [31], [32]. The systemigram starts in the upper left-hand corner of the diagram, and flows to the lower right-hand node, representing the end purpose or mainstay of the system.

Reading through the structured text, the systemigram designer captures the main concepts and system artefacts in noun phrases. Verb phrases provide the relationships between these nodes, which include transforming, belonging, and being. These represent the system transformations in the form of a structure and a process [33]. In this paper, all of the key concepts from the theoretical discussion in the preceding sections were analysed to develop the systemigram seen in Figure 2. This model is the starting point for deeper systemic analysis of the problem to guide the planning of future research.

The analysis of the systemigram in Figure 2 may be performed by breaking it up into different scenes and storylines to identify the issues around possible courses of action. Each of these storylines or scenes may represent a unique research project. This framework will also assist in integrating the different research outputs.

 

5 CONCLUSION

There are significant overlaps and different perceptions among the disciplines analysed in this paper. SE is defined in terms of content and processes. A robust approach is the so-called model-based SE. SE focuses on the development of systems, but with a life-cycle perspective. The value of SE resides in modelling (complex) systems to design, change, and implement them. SE has a somewhat negative image as 'may be good for military and aerospace', and as expensive and time-consuming. However, this is not necessarily true, as long as the SE process is appropriately tailored for the specific project. Systems thinking and SE (notably system architecture) are also applied in organisational development and improvement endeavours, and realised in disciplines such as enterprise architecture and enterprise engineering.

Identifying clear roles, obligations, and accountability between the different roles, supported by competent and knowledgeable people with a common organisational culture, are enablers of project success.

The different perspectives discussed in this paper create a mental model and a point of departure, as can be seen in the systemigram. This improves the understanding of the problems and issues involved with the integration of SE and PM. Using this mental model, one could analyse and compare the disciplines in a more structured and thorough way. This could lead to a better understanding of the topics and sub-topics, the rationale behind defining content, areas of application, etc.

Future research will use the proposed model (the systemigram) to analyse the main themes more deeply. The aim is to improve the model and to start generating research ideas on this problem. One possible topic for research is to frame PM and SE synergy in the context of the digital age, including the Fourth Industrial Revolution.

 

REFERENCES

[1] B. S. Blanchard and J. E. Blyler, System engineering management, 5^th ed., Wiley, 2016.         [ Links ]

[2] A. Sharon, O. L. de Weck, and D. Dori, "Improving project-product lifecycle management with model-based design structure matrix: A joint project management and systems engineering approach," Systems Engineering, vol. 16, no. 4, pp. 413-426, 2012, doi: 10.1002/sys.         [ Links ]

[3] K. Forsberg, H. Mooz, and H. Cotterman, Visualising project management: Models and frameworks for mastering complex systems. John Wiley & Sons, 2005.         [ Links ]

[4] M. J. Nicholas and H. Steyn, Project management for engineering, business and technology, 5^th ed. 2017.         [ Links ]

[5] D. Henry, A. Pyster, D. H. Olwell, N. Hutchison, S. Enck, and J. F. Anthony, "Experiences from creating the guide to the Systems Engineering Body of Knowledge (SEBoK) V. 1.0," in Conference on Systems Engineering Research (CSER'13), vol. 16, pp. 990-999, 2013.         [ Links ]

[6] PMI, Project Management Body of Knowledge (the PMBOK guide), 6^th ed. Project Management Institute, 2017.         [ Links ]

[7] M. Langley, S. Robitaille, and J. Thomas, "Toward a new mindset: Bridging the gap between program management and systems engineering," Insight, vol. 14, no. 3, pp. 4- 8, 2011.         [ Links ]

[8] A. Sharon, V. Perelman, and D. Dori, "A project-product lifecycle management approach for improved systems engineering practices," 18th Annual International Symposium of the International Council on Systems Engineering, INCOSE 2008, vol. 4, pp. 1985-1999, 2008, doi: 10.1002/j.2334-5837.2008.tb00854.x.         [ Links ]

[9] E. Conforto, M. Rossi, E. Rebentisch, J. Oehmen, and M. Pacenza, "Survey report improving the integration of program management and systems engineering: Results of a joint survey by pMi and INCOSE," PMI White Paper, 2013.         [ Links ]

[10] D. D. Walden, G. J. Roedler, K. Forsberg, R. D. Hamelin, and T. M. Shortell, Systems engineering handbook: A guide for system life cycle processes and activities, 4^th ed. John Wiley & Sons, 2015.         [ Links ]

[11] H. Eisner, Essentials of project and systems engineering management, 3^rd ed. Wiley & Sons, 2008.         [ Links ]

[12] B. S. Blanchard and W. J. Fabrycky, Systems engineering and analysis, 5^th ed. Prentice Hall, 2010.         [ Links ]

[13] D. D. Walden, G. J. Roedler, K. Forsberg, R. D. Hamelin, and T. M. Shortell, Systems engineering handbook: A guide for system life cycle processes and activities, 4^th ed. John Wiley & Sons, 2015.         [ Links ]

[14] ISO 15288, "Systems and software engineering - System life cycle processes," 2015, Available at: https://www.iso.org/standard/63711.html.         [ Links ]

[15] S. J. Benade, "System engineering and project management: Towards a common practice," 26th International Association for Management of Technology Conference, IAMOT 2017, pp. 458-479, 2017.         [ Links ]

[16] N. Cerpa and J. M. Verner, "Why did your project fail?", Communications of the ACM, vol. 52, no. 12, pp. 130134, 2009, doi: 10.1145/1610252.1610286.         [ Links ]

[17] A. J. Shenhar and D. Dvir, Reinventing project management: The diamond approach to successful growth and innovation. Harvard Business School Publishers, 2007.         [ Links ]

[18] C. C. Lang and M. J. Stratton, "Project management, configuration management and systems engineering," 1997.         [ Links ]

[19] G. T. Dasher, "The interface between systems engineering and program management," Engineering Management Journal, vol. 15, no. 3, pp. 11-14, 2003, doi: 10.1080/10429247.2003.11415210.         [ Links ]

[20] A. Sharon, O. L. de Weck, and D. Dori, "Is there a complete project plan? A model-based project planning approach," 19th Annual International Symposium of the International Council on Systems Engineering, INCOSE 2009, vol. 1, pp. 96-109, 2009, doi: 10.1002/j.2334-5837.2009.tb00940.x.         [ Links ]

[21] W. R. Shadish, T. D. Cook, and D. T. Campbell, Experimental and quasi-experimental designs for generalised causal inference, 2^nd ed., Houghton Mifflin, 2002.         [ Links ]

[22] L. van der Krieke, F.J. Blaauw, A.C. Emerencia, H.M. Schenk, J.P. Slaets, E.H. Bos, P. de Jonge, and B.F. Jeronimus, "Temporal dynamics of health and well-being: A crowdsourcing approach to momentary assessments and automated generation of personalized feedback," Psychosomatic Medicine, vol. 79, no. 2, Feb. 2017, doi: 10.1097/PSY. 0000000000000378.         [ Links ]

[23] A. Sharon, O. L. de Weck, and D. Dori, "Project management vs. systems engineering management: A practitioners' view on integrating the project and product domains," Systems Engineering, vol. 14, no. 4, pp. 427-440, 2011, doi: 10.1002/sys.20187.         [ Links ]

[24] Z. Zivkovic, I. Mihajlovic, and A. Jovanovic, "Developing curriculum for the engineering management study module: Case study," Serbian Journal of Management, vol. 3, no. 1, pp. 17-27, 2008.         [ Links ]

[25] A. T. W. Yu and G. Q. P. Shen, "Problems and solutions of requirements management for construction projects under the traditional procurement systems," Facilities, vol. 31, no. 5, pp. 223-237, 2013, doi: 10.1108/02632771311307098.         [ Links ]

[26] J. H. Johnson, My life is failure: 100 things you should know to be a successful project leader, The Standish Group International, 2006.         [ Links ]

[27] J. S. C. Hsu, T. C. Lin, K. T. Cheng, and L. P. Linden, "Reducing requirement incorrectness and coping with its negative impact information system development projects," Decision Sciences, vol. 43, no. 5, pp. 929-955, 2012, doi: 10.1111/j.1540-5915.2012.00368.x.         [ Links ]

[28] R. Xue, C. Baron, P. Esteban, and D. Prun, "Integrating systems engineering with project management: A current challenge!", INCOSE International Symposium, vol. 24, no. 1, pp. 693-704, 2014, doi: 10.1002/j.2334-5837.2014.tb03176.x.         [ Links ]

[29] R. D. Adcock, Guide to the systems engineering body of knowledge (SEBoK), v. 1.4, INCOSE, 2014. [29]        [ Links ]

[30] J. T. Boardman, "A process model for unifying systems engineering and project management," Engineering Management Journal, vol. 4, no. 1, pp. 25-35, 1994.         [ Links ]

[31] J. P. Monat and T. F. Gannon, "What is systems thinking? A review of selected literature plus recommendations," American Journal of Systems Science, vol. 4, no. 1, pp. 11-26, 2015.         [ Links ]

[32] A. Squires, A. Pyster, B. Sauser, D. Olwell, S. Enck, D. Gelosh, and J. Anthony, "Applying systems thinking via Systemigrams^TM for defining the body of knowledge and curriculum to advance systems engineering (BKCASE) project," 20th Annual International Symposium of the International Council on Systems Engineering, INCOSE 2010, vol. 1, pp. 739-753, 2010, doi: 10.1002/j.2334-5837.2010.tb01101.x.         [ Links ]

[33] R. Cloutier, B. Sauser, M. Bone, and A. Taylor, "Transitioning systems thinking to model-based systems engineering: Systemigrams to SysML models," IEEE Transactions on Systems, Man, and Cybernetics: Systems, vol. 45, no. 4, pp. 662-674, 2015, doi: 10.1109/TSMC.2014.2379657.         [ Links ]

 

 

* Corresponding author: rudolph.oosthuizen@up.ac.za