Systems Engineering versus Project Management, a comparative study

Developed by Klaus Pallesen

Summary

The scope for this Wiki article is to investigate the similarities and differences between standard best practices of the two domains:

• Project Management, as described by the PMI and/or ISO 21500 standard practices
• Systems Engineering, as described by the INCOSE systems engineering handbook

and to reflect on how the holistic "requirements management" focus of systems engineering could contribute to improve project management practices.

Some of the inspiration for the article comes from the joint PMI/INCOSE survey on differences and similarities between program management and systems engineering, and possibilities for integrating the two However, in this article we go one step down from program to project level and look for particular aspects of system engineering worth integrating in basic project management practice.

The article covers:

• Cross-reference comparison of project management and systems engineering standards
• Detailed comparison of practice for requirements management in the two domains
• The V-model, possible integration in project management practice

The cross-comparison analysis identifies some significant differences in mindset and approach for the two domains which is reflected in their standard practice descriptions. The analysis also identifies the processes for Requirement Management as an important link between the two domains, and suggests that Project Management standard practice could benefit from integrating some of the requirement management practices well established in systems engineering.

Introduction to the mindsets and framework

The domain of Project management

The subject for Project management is the concept of a “project”, which is defined as follows: A project is a temporary endeavor undertaken to create a unique product, service, or result. ... Every project creates a unique product, service, or result...

By definition, a project can create all different kinds of results or outputs, such as:

• a specific product or item
• a system of ... engineering items working together
• an improvement of existing systems, services or products
• a service, organisational setup or business function
• a specific research outcome or documented knowledge

Any such different project endeavor involves it’s own specific knowledge base and skills, and will accordingly develop it’s own specific practices when it comes to executing the project. Today project management is considered a distinct profession, most often defined as follows:

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements ... Project management is accomplished through the appropriate application and integration of ... project management processes,

The professional literature and the internet are teeming with other definitions and interpretations on what project management is about, but the majority is mostly just rephrasing the abovementioned quote from the PMI. This author would offer the following elaborations on the definition:

• Characteristic of Project Management is the focus on management processes and their integration.
• Project management is considered both a profession and a generic discipline for managing projects, applicable for all kinds of organisations and all types of projects - not just for engineering projects.
• Project management as a discipline offers an integrated set of processes and methods which – if applied correctly and as intended – will support the project manager in his effort to control and manage the activities of his project, regardless of the specific field, scope or organisation involved.

The principles and methodology of Project Management as a discipline is described in e.g.: PMI Book Of Knowledge published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 and IPMA . In particular the PMI BOK comprises an extensive, elaborated and exemplified “Handbook” description at practioner's level. The international standard for Project Management ISO 21500:2012 somewhat summarizes the core principles of project management, but gives only a high level description with only minor elaboration of the topics, in accordance with its intended general applicability for “any type of project”.

The domain of Systems engineering

The subject for Systems Engineering is the “system”, which is defined as: an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.

The systems definition stated above covers all types of systems, technical as well as human and societal, but Systems engineering as a discipline is mostly developed and applied for taking on management of complex technical projects Systems engineering is defined as:

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal.

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner . However, the statement catches the distinct characteristic of the Systems Engineering domain, which is the systems thinking and the focus on defining and refining needs and requirements iteratively.

The principles and methodology of Systems Engineering as a discipline is described in INCOSE “Systems Engineering Handbook”, which is recognized as an authoritative framework. The INCOSE SE Handbook provides an elaborated description of methods and practices comparable with the PMI BOK on project management. The practice of Systems Engineering is management and process oriented in the same way as Project Management, but the processes and their contextualization are somewhat different in the two domains.

Similar to the ISO 21500:2012 standard for project management, an international standard for systems engineering ISO 15288:2008 is issued . The standard provides a high level (non-specific) description of the practices for system engineering, and the INCOSE handbook is consistent and aligned with this standard.

Comparing Project Management and Systems Engineering

Project Management and Systems Engineering has a lot in common, and many project management practioners – in particular the ones with less formal training or academic education - has probably picked up elements from both domains when forming their own practice. This section covers a high-level systematic comparison of the frameworks for the two domains. The basis for the comparative analysis is the ISO standards and selected “Handbook” descriptions of practices for the two domains, the latter being PMI BOK and INCOSE Handbook respectively.

The findings from the comparison will support some of the practioner's reflections given in the article's concluding section on the differences, similarities and common ground for the two standard practices approaches.

Project Lifecycle definition and concept

The concept of project lifecycle is fundamental to both domains. Ask any engineering practitioner to visualize what projects is about and they will probably draw up some kind of phase model and go on about the importance of a stepwise approach.

However, let’s look into the standard practices of the two domains for their general "authorized" view on life cycle and phase models.

]
Fig. 1: Comparison of lifecycle definitions

It is evident that from an ISO standard point of view no particular standard method for organising a project- or system lifecycle exists. Their focus is on the generic management processes to be applied during all stages. At “Handbook” level some indications of a general thinking and approach to life cycle organisation can be found. For example, the PMI handbook elaborates further on 3 examples of different approaches to project life cycles:

• Predictive lifecycles – Typically for plan driven projects such as building and infrastrucure projects
• Incremental, iterative lifecycles – For projects in which reducing the complexity or providing partial deliveries are crucial
• Adaptive, “agile” lifecycles. – Like e.g. the Scrum approach to stakeholder driven development.

The INCOSE handbook offers a number of examples on how their generic life cycles stages is applied in different industry practice models. Like PMI BOK the INCOSE handbook describes the Predictive (Plan-driven), Incremental and Agile life cycle approaches, and in addition also covers “Lean development” rather extensively.

All in all its appears that on a practice-oriented level the two domains shares more or less the same thinking on life cycle models of projects. When searching the internet for definitions of “project lifecycle phases” you come up with numerous of different examples from different industry practices, in which the PMI 4-phases or the INCOSE 9-stages or combinations thereof is clearly recognizable.

At the practical engineering level you often see industries or individual companies defining “their own” best practice for project lifecycles, e.g. in the pharmaceutical engineering industry

These often resembles the INCOSE 9-stages plan-driven model. Maybe the Systems Engineering approach applies notions and terminologies that appeals more to practitioners than the more generic ones from the Project Management domain.

Key project management processes in the two domains

When comparing the domains of Project Management and Systems Engineering you would by default expect a distinct management perspective in the first, and a distinct engineering perspective in the latter. However, when leafing through the PMI BOK and the INCOSE SE handbook your first impression is that the two covers more or less the same key issues, just organized differently. But on closer inspection some interesting differences appear, see cross-reference table below.

Fig.2:Project processes in the Project Management and Systems Engineering domains

It is remarkable how the Systems Engineering domain distinguish between “technical” and “project” processes.

For example, in the INCOSE Handbook on Systems Engineering the crucial tasks of defining and refining the scope and requirements for the work are regarded as technical processes rather than a project management process. We will look deeper into the particular issue of requirements management later in the article.

The INCOSE handbook also includes (as technical processes) a set of rather detailed guidelines on how to conduct particular engineering and design tasks, and a set of guidelines on how the organization or “enterprise” in itself should establish its organizational framework and infrastructure to support the systems engineering work. The latter is denoted as “project enabling” processes.

The cross reference matrix shows that apparently no Systems Engineering processes are dedicated to cost management. This does not mean that costs is disregarded in systems engineering - “cost” is a part of the whole definition of the systems engineering approach – but going over the INCOSE handbook you will not find specific project management processes for e.g. planning of cost management, cost estimation and budget resembling those of PMI. Instead you will find cost management covered as follows:

• As an item in the overall project planning process
• As activities described in e.g. stakeholder requirements and requirements analysis process, i.e. embedded in the “technical processes”.

All in all the authoritative descriptions of the two domains indicate that the Systems Engineering domain sees itself as primarily an “engineering” discipline that exist “within” an overlaying project and program management framework. This framework itself is created in the Project Management domain. The idea of recognizing the two domains as two different mindsets is supported by the joint studies of INCOSE and PMI on better integration of program management and systems engineering

Approach to managing the requirements

The joint PMI/INCOSE study on Program management versus systems engineering has identified “Unstable, unclear and incomplete requirements” as a top-10 challenge for managing engineering projects . Most project management practitioners involved in any kind of technical design work can probably go along with that, and you would therefore expect “requirements management” to be a core process in both domains. Let’s see how a simple quantitative comparison of the standard practices turns out for that issue:

Fig.3: Emphasis on requirements management in the two domains

When comparing numbers of sections and pages spent on requirements management in the PMI and INCOSE handbooks respectively a difference in approach for the two domains emerges: Much more effort is being put into requirements in the systems engineering domain.

When looking into the ISO standard for project management the difference in approach is further accentuated: The name “requirements” does not appear anywhere in the text. In the project management domain it seems that the requirements are considered as (just another) element in determining the overall “scope” for the project.

Clearly the System Engineering domain considers requirements definition and refining as crucial processes and keys to success. This is probably one of the reasons that many practitioners sometimes feels that this mindset is easier to connect to and apply in daily project work than the more management-oriented approach found in the Project Management domain. The idea of requirements management being the link between the two domains is supported by Forsberg et al

The “Vee model”

The idea of the “requirements management” beeing the link between the Project Management and Systems Engineering domains is also found in the book by Forsberg et al One particularly interesting approach to requirements management is the so called “Vee Model” for creating coherence and consistency of requirements management throughout the project lifecycle

Fig.4:The V-model

The main principles of the V-model is that you keep tracking and checking your requirements refining and translation into specifications iteratively as you proceed vertically along the lifecycle, and for each level of detail in the design process you have to consider the horizontal alignment requirements and design with the final verification and validation processes.

The model resembles a refinement of the “waterfall” model for software development in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design. A simple, easy-to read description of the model can be found in

In figs 4 and 5 is shown a "generic" graphic presentation of the V-model, clear of specific software development terminology:

Fig.5:The horizontal verification processes in the V-model

The horizontal alignment is an important feature of the model which facilitates a constant internal refining of the understanding of and sharpening of the definition for the requirements. It also supports the tendering and commissioning processes by ensuring that the acceptance criteria for the individual components and deliveries are thoroughly thought out and aligned with the baseline user requirements.

What can the V-model give us?

First of all, models like the V-model provides the project management practitioner with i.e:(forsberg)

• Visualization: The deeper psychological and neurophysiological mechanisms behind “thinking” is far beyond the scope of this article, but it is recognized that visualization is a powerful tool to add creative thinking to the standard left-brain logical thinking
• Simplification: Models helps us to reduce complexity and to understand “the whole picture”
• Common language: Models provides a common framework and vocabulary helping us to discuss the same “whole picture”

Although the V model is borne within domain of complex software and hardware engineering there is no reason why it should not be applicable for other types of project, e.g. investigations of social systems .

This author would argue that the V-model is also applicable for any, plan-driven engineering/design projects that initiates from a stakeholder requirement and ends up with a solution to be implemented. Let’s look at a practical case, simplified from the author’s practical experience:

Consider a project for an underground automatic parking facility – A rather new technology where the customer leaves his car to be parked “automatically” applying mechanical high bay storage systems.

Obviously this is an “engineering system” in the INCOSE sense – and equally obviously you will expect a number of complex stakeholder expectations and user requirements for the facility (the overall combined system) to materialize very quickly, considering that the customers are only used to old fashioned parking garages.

A number of tools for managing particular types of requirements exists, see e.g. (ref http://apppm.man.dtu.dk/index.php/Requirements_engineering). What the V-model can do for us in this case is to help us manage and facilitate the defining and refining of these requirements constantly focusing on the final verification and customer satisfaction, see examples of steps in fig 6 below:

Fig.6:The V-model application example, see text for explanation

• Step 1: You state, define and refine the high level “user experience” requirements until they are consistent with a broken down list of more specific requirements.
• Steps 1-2: Before approval of the high-level requirements you validate them by making sure that you can transform these requirements into a set of unambiguous acceptance criteria to be tested and measured at the same overall systems level. And you prepare yourself for setting up conditions for all supplier’s participation in the end-user system test
• Step 3: When defining conceptual design for subsystems you make sure – before moving into detailed design - that you can define a set of coherent acceptance criteria for each subsystem that relates directly to the high-level user experience requirements. For example. if the customer expects to wait maximum x minutes for his car to be retrieved (high level user requirement), the transportation subsystem must have a minimum logistic performance of Y, to be verifiable before installation.
• Step 4: When entering into design of e.g. facility layout and building design the V-model urges you to consider if some of the crucial high-level “user experience” requirements for e.g. maneuverability and ergonomics can be tested and verified already in the design stage, e.g by applying mock-ups.

Reflections on practice

Many project management practitioners struggle everyday with projects which in neither size nor complexity are nowhere near the iconic mega projects from which the Project Management and the Systems Engineering professional standards and methods are developed. And many do not have the resources available to conduct textbook Project Management or Systems Engineering.

What the practitioners really need are advice on how to scale down the management task into something remotely accomplish-able, and how to pick the best concepts from both domains.

As shown in this article the two domains are in fact a bit different in their approach and mindset, and each of them would probably appeal to different kinds of project practitioners, depending on their professional upbringing and working context. For the project manager deeply engaged in developing new public administration workflows the Systems Engineering approach is probably just tonnes of meaningless engineer’s gibberish. For the devoted engineer in charge of integrating a new high bay storage system in an old building on a tight time schedule the Project Management approach may just be superficial management-speak creating little practical value.

A multi-purpose practitioner would argue that both views are wrong, of course. Those who argue that project management processes are "just waste of paper" are sometimes the ones who have not themselves been up to thinking through their own project !

And all projects can benefit from the mindset of Systems Engineering, in particular (a practitioner will argue) the commitment to requirements definition and refining found is this domain. Requirements Management is the field where engineering meets the human factor, and where the project manager realizes that all projects originates from basic needs and ideas of humans. And that in translating these requirements into engineering entities, the project management practitioner must never lose track of these baseline requirements for the system to function as a whole.

As a lot of the recurrent calamities in projects (e.g. cost overruns, unforeseen changes, redesign, delays, disputes etc.) can be traced back to unclear or unstable requirements, the Project Management domain might consider bringing in some of the requirement management practices from Systems Engineering. In particular the V-Model seems to be a good choice.