ACADEMIA Letters

Project Management and Systems Engineering. Two

Complementary Disciplines for Scope Management
jose fernandez, Universidad Politécnica de Madrid

First the article addresses the commonalities and the sources of unproductive tensions between
project management and systems engineering, and the professionals performing them. Later,
it describes how the two disciplines are critical for the Work Breakdown Structure (WBS)
delivery.

1. Systems Engineering and Project Management

Project Management Institute PMBoK Guide 6th edition [1], defines what is a program and a
project:

• “A program is defined as a group of related projects, subsidiary programs, and pro-

gram activities managed in a coordinated manner to obtain benefits not available from
managing them individually.”

• “A project is a temporary endeavor undertaken to create a unique product, service, or

result.”

The above PMI project definition is clear considering that a project is not only oriented
to a product development but a service or a result as well. Here, due to its intersection with
systems engineering, the article addresses product oriented projects.
The managing of product oriented project is a topic considered by both disciplines systems
engineering and project management. Both disciplines have commonalities in the product
or system development management. These commonalities are positive when the processes

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.

1
supported by both disciplines are integrated and the common responsibilities are shared by
the systems engineer and the project management.
To identify the commonalities of both disciplines systems engineering and project man-
agement two sources are used here, one is NASA System Engineering Handbook [2] and the
other is INCOSE SE Handbook [3]. The commonalities identified are stakeholder manage-
ment, requirements management, scope management, risk management and change manage-
ment.
The project manager is responsible for project outcomes as well as the time, cost and
resources required for the project. The systems engineer manages the technical baseline of
the product under development.
Stakeholder management, scope management and particularly requirements management
are shared by both disciplines. Systems engineers are critical for complex product oriented
projects since engineering better requirements reduce scope creep and unwanted surprises.
Risk management is shared, but project manager is the primary owner of the risk man-
agement process but the systems engineer provides significant inputs to all aspects of risk
management.
Change management is shared. Change management is part of configuration management.
But a seamless integration of systems engineering and project management is not always
the commonplace. As pointed out by Boswell [4], unproductive tensions between project
management and systems engineering are due to:

• Lack of integrated planning

• Unclear definition of roles and authority when the roles of systems engineer and project
manager are performed by different persons, as it is the case in large projects.

• Conflicting practices when performing both disciplines

To mitigate the unproductive tensions, first it is necessary a comprehensive approach to

product and project planning by thinking in terms of interdependencies of product and project
attributes [5]. The author collaborated to develop an approach where we identified a taxonomy
of dependencies in product development projects and applied it to an UAV system developed
by students at Clarkson University [6].
Kordova et al. [7] propose a people and process set of recommendations to resolve the
partnership between project managers and systems engineers. Below these recommendations
are summarized:

• Coordinate responsibilities and authority delegation before beginning the project

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.

2
 • Better a project manager with experience as systems engineer

• Resolve conflicts through dialog

• Enlarge the overlap between areas of responsibility

• Train project managers in the engineering processes

• Systems engineers should consider managerial aspects

• Discuss interfaces between project managers and systems engineers

• Mentor both professionals

• Assign the roles of project manager and systems engineer to the right people

• Provide technical supervision to the project manager

• Maximize the strengths of both professionals

• Be aware of the importance of decisions and their impact on either the system or project

2. Work Breakdown Structure

The Work Breakdown Structure (WBS) is one of the main deliverables of the collaboration of
both disciplines because project scope is determined by the product scope defined by systems
engineers.
The WBS is defined by the PMI PMBoK [1] as: “A hierarchical decomposition of the
total scope of work to be carried out by the project team to accomplish the project objectives
and create the required deliverables.”
Based on his experience, the author recommends WBS should be used in all projects
independently if they are product oriented, process oriented or results oriented. Unfortunately,
some project managers begin project planning activities from a chronogram, not using the
WBS at all, as it is the case in many software development projects.
Here it is explained how to build a WBS for a product or system. This WBS is a product
oriented WBS, where the main deliverable is the product or system. In other cases, such as an
industrial facility, the main deliverable is an industrial plant, not a product, so in this situation
a process oriented WBS is recommended except for the construction phase where engineers
may identify the work based on the physical plant elements to be built or installed. Examples

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.

3
of process oriented WBS can be found in the PMI Guide for WBS [8] and the US Department
of Energy [9].
The WBS for a very large and complex program or project is a hierarchy of multiple levels.
Kezner [10] recommends a six levels hierarchy for a large program where the hierarchy levels
represent: Total program, project, task, subtask, work package and level of effort activity.
For product oriented projects with systems engineering tasks, the intentionally incomplete
WBS presented in Figure 1 below is proposed here. The product breakdown, where subsys-
tems A and B, and still incomplete, is based on the decomposition of the physical architecture
of the product being developed, nowadays modeled by systems engineers using Model-Based
Systems Engineering approaches [11].

Figure 1. Generic and preliminary WBS of a product oriented project

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.

4
 Figure 1 is illustrative of the diverse tasks identified in the WBS: project management
tasks, such as 1.1.1, 1.1.2, 1.1.3 and 1.1.4, crosscutting tasks, such as 1.2.1 and 1.2.2, and
product tasks such as 1.4.1 and 1.4.2.
The more difficult to identify are the so called crosscutting elements that transect the peer
WBS elements at each level. Haugan [12], identifies four types of crosscutting tasks:

• Integrative: work element that integrates two or more peer WBS elements.

• Analytical: work element that spans the work elements of a common parent.

• Process: Work element that represents a next step in work progression.

• Project management: These work elements have common characteristics with the above
work elements of the classification.

When creating a WBS the following guidelines are very useful:

• All project deliverables are represented in the WBS

• The level 2 elements in a product oriented project include the product, any other major
deliverables and major crosscutting work elements necessary to support the product
work

• The level 3 work elements of the product reflect its physical hierarchy. So the contri-
bution of engineers and particularly systems engineers is very important.

• Cross cutting work elements of type integrative, analytical or process may appear at
diverse levels as needed

• Work in each work element is equivalent to the sum of the work in subordinate work
elements

• The lowest level is the level above the project activities and it is called work package

Figure 1 is complemented with the WBS dictionary where the work in each WBS element
is described in detail. Table 1 is a template for describing each work element in the WBS
dictionary.

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.

5
 Table 1. WBS Dictionary

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.

6
3. To conclude
Project management and systems engineering commonalities and intersections can result in
unproductive tensions that should be mitigated by collaboration and the integration of efforts.
The definition of the project scope using the WBS is an important contributors of a seamless
integration of systems engineering, project management and specialties engineering although
the human factor is still a main issue.

References
[1] PMI. A Guide to the Project Management Body of Knowledge, 6th Edition. Newtown
Square, PA: Project Management Institute, 2017.

[2] NASA. Systems Engineering Handbook. NASA SP-2016-6105 Rev2. Washington, DC:
NASA, 2016.

[3] Walden D.D., et al. Systems Engineering Handbook – A guide for system life cycle pro-
cesses and activities, INCOSE-TP-2003-02-04. Hoboken, NJ: John Wiley&Sons, 2015.

[4] Boswell J.W. Anbari, F.T. and Via J.W. “Systems Engineering and Project Management:
Points of Intersection, Overlaps and Tensions,” 2017 Proceedings of PICMET ́17: Tech-
nology Management for Interconnected World, 2017.

[5] Van Gemert, D. “Systems engineering the project.” Paper presented at PMI® Global
Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Man-
agement Institute, 2013.

[6] Martinez Leon, C., Fernandez J.L. and Cross, J.A.” Taxonomy on Product Dependencies
for Project Planning.” Proceedings of the 2018 IISE Annual Conference. K. Barker, D.
Berry, C. Rainwater, Eds., 2018.

[7] Kordova, S., Katz, E., Frank, M. “Managing development projects-The partnership be-
tween project managers and systems engineers.” Systems Engineering. Vol 22, Is 3, pp
227-242, doi:10.1002/sys.21474, 2019.

[8] PMI. Practice Standard for Work Breakdown Structures. Second Edition. Newton Square,
PA: Project Management Institute, 2006.

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.

7
[9] US DoE. Work Breakdown Structure Handbook., Washington, DC: Department of Energy,
August 16, 2012

[10] Kezner, H. Project Management a Systems Approach to Planning, Scheduling, and Con-
trolling. Hoboken, New Jersey: John Wiley & Sons, Inc., 2009.

[11] Fernandez J.L. and Hernandez, C. Practical Model-based Systems Engineering, Nor-
wood, MA: Artech House, 2019.

[12] Hagan, G. Effective Work Breakdown Structures. Vienna, VA: Management Concepts,
2002.

Academia Letters, July 2021 ©2021 by the author — Open Access — Distributed under CC BY 4.0

Corresponding Author: jose fernandez, joselfernandez@telefonica.net

Citation: Fernandez, J. (2021). Project Management and Systems Engineering. Two Complementary
Disciplines for Scope Management. Academia Letters, Article 2138. https://doi.org/10.20935/AL2138.