Systems Engineering versus Project Management, a comparative study

Systems Engineering versus Project Management, a comparative study

Abstract

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
• Detailed comparison of practice for requirements management in the two domains
• The V-model, possible integration in project management practice

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,

Characteristic of Project Management is the focus on management processes and their integration. 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. 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. 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. (INCOSE) 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 /Faulconbrigde+Ryan ,,/ 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 Systems Engineering, 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 recognised 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 reflections on strenghts, shortcomings and possible new ideas for hands-on practitioners of everyday project management offered in the following section.

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.

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 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. It is tempting to argue that when it comes to the conception of life cycle management of projects, the systems engineering domain offers a framework that appeals to many project management practitioners.

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.

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

For example, within the SE domain 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 SE 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 SE processes 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 there is some evidence to be found in the authoritative descriptions of the two domains indicating that the Systems Engineering domain sees itself as primarily an “engineering” discipline that exist and lives by its own best practice standards within an overlaying project and program management framework created in the Project Management domain. The idea of recognising 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:

When comparing the emphasis on requirements management in the PMI and INCOSE handbooks respectively a difference in approach for the two domains emerges, as 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.

The System Engineering domain's appreciation of requirements definition and refining as crucial processes and keys to success 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 “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 ,

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 horizontal alignment is an important feature of the model which facilitates a constant internal refining of the understanding and definition of the requirements. Italso supports the tendering and commissioning processes by ensuring that the