DTU ProjectLab - User contributions [en-gb]

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:35:14Z

MrP: /* The domain of Project management */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Project Management]]
[[Category:Systems Engineering]]
[[Category: Visual tools]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|600px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|600px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> – 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:

[[File:Fig Vmod_3.png|600px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:23:14Z

MrP: /* Systems Engineering versus Project Management, a comparative study */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Project Management]]
[[Category:Systems Engineering]]
[[Category: Visual tools]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|600px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|600px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> – 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:

[[File:Fig Vmod_3.png|600px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:22:45Z

MrP: /* Systems Engineering versus Project Management, a comparative study */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Project Management]]
[[Category:Systems Engineering]]
[[Category: Visual]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|600px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|600px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> – 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:

[[File:Fig Vmod_3.png|600px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:17:50Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|600px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|600px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> – 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:

[[File:Fig Vmod_3.png|600px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:16:17Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|600px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|600px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_3.png|600px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:15:13Z

MrP: /* The “Vee model” */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|600px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|600px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_3.png|600px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:14:49Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_3.png|600px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:14:28Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_3.png|500px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:14:11Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_3.png|500px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:13:28Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_3.png|500px]] '''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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:11:55Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_3.png|500px]] '''Fig.4''':The V-model

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

==References==
<references/>

File:Fig Vmod 3.png

2014-12-01T18:10:35Z

MrP:

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:08:33Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

[[File:Fig Vmod_1.png|500px]] '''Fig.4''':The V-model

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

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:06:37Z

MrP: /* What can the V-model give us? */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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 <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref>.

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 (ref) – 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:

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

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:04:15Z

MrP: /* The “Vee model” */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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. <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref> shows an example of the V-model being applied to 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 (ref) – 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:

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

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T18:03:28Z

MrP: /* The “Vee model” */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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. <ref>http://lab.sdm.keio.ac.jp/idc/yasui/papers/j10_2011incose_yasui.pdf </ref> shows an example of the V-model being applied to 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 (ref) – 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:

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

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T17:04:58Z

MrP: /* The “Vee model” */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]] '''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.

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T17:03:37Z

MrP: /* The “Vee model” */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]] '''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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T17:02:15Z

MrP: /* The “Vee model” */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

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

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:59:45Z

MrP: /* The “Vee model” */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 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 <ref>http://www.projectinsight.net/blogs/it-project-management-solutions/the-quot-v-quot-model-by-cameron-watson</ref>

Below is shown a "generic" graphic presentation of the V-model, clear of specific software development terminology:

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:53:42Z

MrP: /* Approach to managing the requirements */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:50:34Z

MrP: /* Approach to managing the requirements */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 idea of requirements manageement beein the link between the two domains is supported by Forsberg et al <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

===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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:49:37Z

MrP: /* Key project management processes in the two domains */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:49:18Z

MrP: /* Key project management processes in the two domains */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref> as well as in <ref="forsberg" /ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:44:38Z

MrP: /* Key project management processes in the two domains */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref> as well as in <ref="forsberg" />

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:31:50Z

MrP: /* Project Lifecycle definition and concept */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 <ref> http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-industry)</ref>

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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T16:25:08Z

MrP: /* Project Lifecycle definition and concept */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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 (ref http://www.ispe.org/ispe-good-practice-guides/project-management-pharmaceutical-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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T15:41:47Z

MrP: /* Summary */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-12-01T15:37:32Z

MrP: /* Abstract */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T18:13:50Z

MrP: /* Approach to managing the requirements */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|800px]] '''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.

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T18:10:50Z

MrP: /* Key project management processes in the two domains */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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.

[[File:Billed_skem_smlgn_proces.png|1000px]] '''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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T18:09:02Z

MrP: /* Project Lifecycle definition and concept */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]]]
 '''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.

[[File:Billed_skem_smlgn_proces.png|left|500px]|frame|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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T18:04:21Z

MrP: /* Key project management processes in the two domains */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|left|600px]|frame|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.

[[File:Billed_skem_smlgn_proces.png|left|500px]|frame|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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T18:03:37Z

MrP: /* Project Lifecycle definition and concept */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|left|600px]|frame|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.

[[File:Billed_skem_smlgn_proces.png|left|1000px]|frame|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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T18:02:51Z

MrP: /* Key project management processes in the two domains */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|left|750px]|frame|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.

[[File:Billed_skem_smlgn_proces.png|left|1000px]|frame|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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T17:59:48Z

MrP: /* Project Lifecycle definition and concept */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|left|750px]|frame|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.

[[File:Billed_skem_smlgn_proces.png|1000px]]

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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T17:45:02Z

MrP: /* Comparing Project Management and Systems Engineering */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]|frame|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.

[[File:Billed_skem_smlgn_proces.png|1000px]]

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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Systems Engineering versus Project Management, a comparative study

2014-11-29T17:44:10Z

MrP: /* Project Lifecycle definition and concept */

=Systems Engineering versus Project Management, a comparative study=
[[Category:Programme Management]]
[[Category:Anden kategori]]
==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
<ref name="LeanEnablers"> Oehmen, Josef (2012). "The guide to Lean enablers for managing enigineering programs", Joint MIT PMI INCOSE community of practice </ref> 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''... <ref name="pmbok">Project Management Institute (2013) "A guide to Project Management Book of Knowledge, 5th ed"</ref>

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,'' <ref name="pmbok" />

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 <ref name="pmbok" /> published first time in 1969, which is recognized as an authoritative basis for good project management practice, together with PRINCE2 <ref> Office of Government Commerce UK (2006) "Managing sucessful projects with PRINCE2"</ref> and IPMA <ref>International Project Management Association (2006) "IPMA Competence Baseline Ver. 3.0"</ref> . 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 <ref name="ISO21500"> ISO 21500:2012 "Guidance on project management" </ref> 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. <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref>

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 <ref name="faulc">Faulconbridge, I & Ryan, M (2003): "Managing complex projects: A systems engineering approach", 2003 Artech House</ref>
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.''<ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> 

The abovementioned definition may be a bit long-winded, and other shorter “authoritative” definitions can be found in the litterature, e.g. by Eisner <ref name="Eisner"> Eisner, H (2011) "Systems Engineering - Building Succesful Systems", Morgan&Claypool 2011 </ref>.
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”<ref name="INCOSE" />, 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 <ref name="ISO15288">ISO 15288:2008 Systems ans software engineering - Systems lifecycle processes" </ref>. 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.

[[File:testtabel.png|750px]|frame|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.

[[File:Billed_skem_smlgn_proces.png|1000px]]

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 <ref>Langley, M. Et al (2011) "Toward a new mindset - Bridging the gap between program management and systems engineering", PMI Network Sept. 2011</ref>

===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 <ref name="LeanEnablers" />. 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:

[[File:Skema samlign req man billed.png|750px]]

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 <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>
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 <ref> “System Engineering for Faster, Cheaper, Better”, Dr. Kevin Forsberg and Mr. Harold Mooz, Center for Systems Management ,1998 </ref> <ref name=”forsberg”>Forsberg. K. et al (2005) “Visualizing project management” 3rd ed. J. Wiley & Sons </ref>

[[File:Fig Vmod_1.png|500px]]

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 <ref name="INCOSE">International Council of Systems Engineering (201). "Systems engineering handbook", INCOSE-TP_2003-002-03.22, October 2011 </ref> in the sense that it also recognizes the development process as a “cascade” downwards from overall requirements over high-level design to detailed design.

[[File:Fig Vmod_2.png|500px]]

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.

==References==
<references/>

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T21:23:33Z

MrP: /* Response to feedback from Choko */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*You could refer to other WIKI articles like this: Project Management (Code: [[Project Management]])

''Exactly right - I will try to do this''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*The section contains very long statements like this one: "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." -And i can't really figure out where this is from, if you wrote it your self or which source you have it from. Could you add sources to statements and paragraphs like these?

''The statements are my own. I'm trying to express the essence of how PM is defined in the litterature. But on reading your comments and my own prose again, I see there is need for more clarity. Will seriously consider rephrasing''

*Should the following sentence be in italic as the other definitions?: "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. [6]"

''Clearly the italic coding has failed me (the other reviewer pointed out the same)''

Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

''I will consider it - But I'm not sure there is enough evidence for stating such a positive regularity, I think I maybe have stretched my speculations on who-prefers-what long enough already ''

*There is only one reference in the whole section, consider adding more.

''Will do that''

*The formulation: "When searching the internet" is in my opinion not very academic, maybe consider rewriting.

''You have a point, we must keep up our academic appearances. However, "searching the internet" is probably a relevant source in this case. I will consider rewriting, in combination with adding links to examples (your next comment)''

* Would it be an idea to give some examples after the following sentence: "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." Examples are 1, 2, 3 and 4, where ...

*(Comment on section Reflections on proactice) I miss some more direct links to particularly discussed subjects from the article.

''Do you mean Wiki links or references ? Not adding references is deliberate from my side as I wish the concluding section to stand out as the author's personal reflections, but I will consider adding Wiki links''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T21:21:28Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*You could refer to other WIKI articles like this: Project Management (Code: [[Project Management]])

''Exactly right - I will try to do this''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*The section contains very long statements like this one: "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." -And i can't really figure out where this is from, if you wrote it your self or which source you have it from. Could you add sources to statements and paragraphs like these?

''The statements are my own. I'm trying to express the essence of how PM is defined in the litterature. But on reading your comments and my own prose again, I see there is need for more clarity. Will seriously consider rephrasing''

*Should the following sentence be in italic as the other definitions?: "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. [6]"

''Clearly the italic coding has failed me (the other reviewer pointed out the same)''

Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

''I will consider it - But I'm not sure there is enough evidence for stating such a positive regularity, I think I maybe have stretched my speculations on who-prefers-what long enough already ''

*There is only one reference in the whole section, consider adding more.

''Will do that''

*The formulation: "When searching the internet" is in my opinion not very academic, maybe consider rewriting.

''You have a point, we must keep up our academic appearances. However, "searching the internet" is probably a relevant source in this case. I will consider rewriting, in combination with adding links to examples (your next comment)''

* Would it be an idea to give some examples after the following sentence: "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." Examples are 1, 2, 3 and 4, where ...

*(Comment on section Reflections on proactice) I miss some more direct links to particularly discussed subjects from the article.

''Do you mean Wiki links or references ? Not adding references is deliberate from my side as I wish the concluding section to stand out as the author's personal reflections, but I will consider adding Wiki links''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T21:19:31Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*You could refer to other WIKI articles like this: Project Management (Code: [[Project Management]])

''Exactly right - I will try to do this''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*The section contains very long statements like this one: "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." -And i can't really figure out where this is from, if you wrote it your self or which source you have it from. Could you add sources to statements and paragraphs like these?

''The statements are my own. I'm trying to express the essence of how PM is define in the litterature. But reading my own prose again, I see there is need for more clarity. Will seriously consider rephrasing''

*Should the following sentence be in italic as the other definitions?: "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. [6]"

''Clearly the italic coding has failed me (the other reviewer pointed out the same)''

Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

''I will consider it - But I'm not sure there is enough evidence for stating such a positive regularity, I think I maybe have stretched my speculations on who-prefers-what long enough already ''

*There is only one reference in the whole section, consider adding more.

''Will do that''

*The formulation: "When searching the internet" is in my opinion not very academic, maybe consider rewriting.

''You have a point, we must keep up our academic appearances. However, "searching the internet" is probably a relevant source in this case. I will consider rewriting, in combination with adding links to examples (your next comment)''

* Would it be an idea to give some examples after the following sentence: "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." Examples are 1, 2, 3 and 4, where ...

*(Comment on section Reflections on proactice) I miss some more direct links to particularly discussed subjects from the article.

''Do you mean Wiki links or references ? Not adding references is deliberate from my side as I wish the concluding section to stand out as the author's personal reflections, but I will consider adding Wiki links''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T21:12:33Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*You could refer to other WIKI articles like this: Project Management (Code: [[Project Management]])

''Exactly right - I will try to do this''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*The section contains very long statements like this one: "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." -And i can't really figure out where this is from, if you wrote it your self or which source you have it from. Could you add sources to statements and paragraphs like these?

''The statements are my own. I'm trying to express the essence of how PM is define in the litterature. But reading my own prose again, I see there is need for more clarity. Will seriously consider rephrasing''

*Should the following sentence be in italic as the other definitions?: "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. [6]"

''Clearly the italic coding has failed me (the other reviewer pointed out the same)''

Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

''I will consider it - But I'm not sure there is enough evidence for stating such a positive regularity, I think I maybe have stretched my speculations on who-prefers-what long enough already ''

*There is only one reference in the whole section, consider adding more.

''Will do that''

*The formulation: "When searching the internet" is in my opinion not very academic, maybe consider rewriting.

''You have a point, we must keep up our academic appearances. However, "searching the internet" is probably a relevant source in this case. I will consider rewriting, in combination with adding links to examples (your next comment)''

* Would it be an idea to give some examples after the following sentence: "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." Examples are 1, 2, 3 and 4, where ...

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T21:03:57Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*You could refer to other WIKI articles like this: Project Management (Code: [[Project Management]])

''Exactly right - I will try to do this''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*The section contains very long statements like this one: "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." -And i can't really figure out where this is from, if you wrote it your self or which source you have it from. Could you add sources to statements and paragraphs like these?

''The statements are my own. I'm trying to express the essence of how PM is define in the litterature. But reading my own prose again, I see there is need for more clarity. Will seriously consider rephrasing''

*Should the following sentence be in italic as the other definitions?: "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. [6]"

''Clearly the italic coding has failed me (the other reviewer pointed out the same)''

Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

''I will consider it - But I'm not sure there is enough evidence for stating such a positive regularity, I think I maybe have stretched my speculations on who-prefers-what long enough already ''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T20:53:01Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*You could refer to other WIKI articles like this: Project Management (Code: [[Project Management]])

''Exactly right - I will try to do this''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T20:51:09Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

* (Abstract) The sentences get very long. Consider some more "," and "."

''Will try ''

*You could refer to other WIKI articles like this: Project Management (Code: [[Project Management]])

''Exactly right - I will try to do this''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T20:43:05Z

MrP: /* Response to feedback from Choko */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: The graphics for the V-model presentation is "original reproductions" done by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T20:41:12Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: All tables and graphics, including the V-model presentation, is original work by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

*I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.

''I agree. Trouble is, easy-to-read-and-understand examples from the litterature are not abundant. I will consider constructing an example myself and add it to the section on the V-model ''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T20:37:10Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: All tables and graphics, including the V-model presentation, is original work by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

*Maybe include figure references, if the figures is not reproduced by the author of the article.

''The graphics are original reproductions, even also modified by the author''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T20:34:27Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: All tables and graphics, including the V-model presentation, is original work by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the missing figure text, same point as the other reviewer. I will try my luck with the coding for framing images ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.
Maybe include figure references, if the figures is not reproduced by the author of the article.

''I agree, I have actually been trying to do that, maybe learning from your code examples can help me''

Talk:Systems Engineering versus Project Management, a comparative study

2014-11-27T20:31:06Z

MrP: /* Response to review by Lasse Madsen */

= Feedback by Lasse Madsen =
'''Fist impression:''' 
* The article is very well structured, and invites the reader to read along.
* The grammar and spelling is very good, and the content is easy to understand due to the structure and grammar. I would though, suggest to add additional "," where sentences get long. Especially moving towards the end of the article.

==Formal aspects==
*I would put the introduction before the content to provide a read threat.
*I miss some more WIKI formatting, ie.
**Categories: <nowiki>[[Categories:Management]]</nowiki>
**References to other wiki sites: <nowiki>[[project management]]</nowiki>
**Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. '''Code:''' <nowiki>[[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]</nowiki>
** I miss figure text. Could be solved by the method above.
* I would consider to use the references more than once like: this <ref name="Example">Hasan, Helen, and Alanah Kazlauskas. "The Cynefin framework: putting complexity into perspective." (2014): 55. </ref>, then the same reference could be used here <ref name="Example"/> and here <ref name="Example"/> and even here <ref name="Example"/> as well :-). (look into the code of this to see how it could be done, if you are interested.
* Maybe include figure references, if the figures is not reproduced by the author of the article.

==Content aspects==
* The article clearly relates to the course, and provides a good overview of methods of systems enginnering vs. project management.
* I would have enjoyed to read examples of uses of the V-model and how this could help practioneers in relations to other models.
* I like that the author of the article finishes off with reflections of practise.

==Abstract==
* The sentences get very long. Consider some more "," and "."
* You could refer to other WIKI articles like this: [[Project Management]] (<nowiki>Code: [[Project Management]]</nowiki>)

==Introduction to mindset and framework==
* The section contains very long statements like this one: "''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.''" '''-And''' i can't really figure out where this is from, if you wrote it your self or which source you have it from. '''Could you add sources to statements and paragraphs like these?'''
* Should the following sentence be in italic as the other definitions?: "''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. [6]''"
* Is it possible to add a section where you state: Who uses what, (like: System enginering is mainly used by: x, y, and z and Project management ....)

==Comparing Project Management and Systems Engineering==
* There is only one reference in the whole section, consider adding more.
* The formulation: "''When searching the internet''" is in my opinion not very academic, maybe consider rewriting.
* Would it be an idea to give some examples after the following sentence: "''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''." '''Examples are''' 1, 2, 3 and 4, where ...

==Reflections on practice==
*I miss some more direct links to particularly discussed subjects from the article.
'''Used for reference example'''
<references/>

== Reviewed by Choko ==

== Formel aspects ==
* I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

* "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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

* There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.

* It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

== Content aspects ==
*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

* I will admit I do not know enough about this subject, to say if you are missing any important points - but all together it seems like a very good article to me.

:)

== Response to feedback from Choko ==
Thanks for your thorough review and proofreading. I will respond to your comments bullet by bullet:

*I am not certain what you are doing in this sentence - maybe it just isn't finished? "a system of ... engineering items working together" under The domain of Project management.

''I'm just trying to short the quotation by leaving out the less important words and sentences. Obviously it does'nt work for you as a reader, I will consider stating the complete citation instead''

*"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, [2]" This ones is written both in italic and normal text - does that mean you wrote some of it or is it all quotes ? (and why does it end with a , ?)

'' It was my intention to mark it all up as quotes was my intention, but the coding for text format in general and italic font in particular has been giving my at lot of trouble. ''

*There is only minor errors, that mostly seems like typos, so I am quite certain you can find them yourself when you re-read it before the final delivery.
''Thanks !''

*It might be a good idea to name the tables, so it is absolutely clear which one you are talking about in the text.

''Right, I will try to do that in my final version''

*From looking in the Week 13 - Wiki article peerview description I will have to ask; the V-figures you are using, did you make them yourself or did you borrow them from somewhere? In case of the latter, were you allowed to borrow them?

''Just for the sake of good order: All tables and graphics, including the V-model presentation, is original work by myself''

*It was mentioned today by Christian that he would prefer not to use the word abstract, but in stead summary - and that it would be a good idea to explain why this article is relevant to for example companies.

''I will look into the summary/abstract section again and consider renaming it as suggested''

== Response to review by Lasse Madsen ==

Thanks for your valuable feedback and advice, I will try to respond to your comments bullet by bullet:

*I would put the introduction before the content to provide a read threat.

''Probably a good idea - If I knew how to do the necessary HTML style editing :-) ''

*I miss some more WIKI formatting, ie.

**Categories: [[Categories:Management]]

**References to other wiki sites: [[project management]]

''Right, I will try to do better when refining the text, thanks for the examples''

*Figures could alternatively be in the right hand side in stead of as part of the text. The problem is, that if you have a small screen, the figures will go out of the screen. Code: [[File:FILENAME.png‎|200px|thumb|right|FIGURE TEXT]]

''I will probably stick to my current layout, I don't like the graphics beeing too small''

*I miss figure text. Could be solved by the method above.

''You are right about the figure text, same point as the other reviewer. I will try my luck with the coding for ''

*I would consider to use the references more than once like: this [1], then the same reference could be used here [1] and here [1] and even here [1] as well :-). (look into the code of this to see how it could be done, if you are interested.
Maybe include figure references, if the figures is not reproduced by the author of the article.