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 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.

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.Characteristic of Project Management is the focus on management processes and their integration.

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.

However you also find a number er of different companies and industries offers "their own" project management model, and at lot of them resembles the Systems Engineering lifecycle more than that of PMI. 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 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 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.

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 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.

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.

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 much simpler projects. This author would argue that the V-model is applicable in any project that initiates from a stakeholder requirement and ends up with a solution to be implemented. For instance, for the plan-driven design and build projects in the construction industry could relatively easily adopt the V-model for building more complex production or R&D facilities, in which the building structure and the mechanical, electrical and BMS systems should hopefully work together as a system, in accordance with the baseline user requirements.

For such projects the V-model offers e.g:

• An intuitive visualization of the concept, easy to communicate to stakeholders
• A framework for creating coherence from “user experience” based high level requirements down to tender dossier specifications
• An easy-to-understand coherence between the design and the testing activities at taking over
• A framework for facilitating high-level testing of the integrated facility, referring back to the user requirement baseline.

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.