ISO/IEC/IEEE 16326:2019

INTERNATIONAL ISO/IEC/
STANDARD IEEE
Second edition
2019-12
Systems and software engineering —
Life cycle processes — Project
management
Ingénierie du logiciel — Processus de cycle de vie — Gestion de projet
Reference number
©
ISO/IEC 2019
©
IEEE 2019
© ISO/IEC 2019
© IEEE 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2019 – All rights reserved
ii © IEEE 2019 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
1.1 Purpose . 1
1.2 Field of application . 1
1.3 Limitations . 1
2 Normative References . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 2
4 Conformance . 2
4.1 General . 2
4.2 Conformance to the normative documentation content . 2
4.3 Conformance to processes . 2
4.4 Full conformance. 3
5 Application of this document . 3
6 Technical management processes . 3
6.1 General . 3
6.2 Project planning process . 5
6.2.1 General. 5
6.2.2 Guidance. 5
6.2.3 Software-specific guidance . 8
6.3 Project assessment and control process . 9
6.3.1 General. 9
6.3.2 Guidance. 9
6.4 Decision management process.11
6.4.1 General.11
6.4.2 Guidance.11
6.5 Risk management process .13
6.5.1 General.13
6.5.2 Guidance.13
6.6 Configuration management process .14
6.6.1 General.14
6.6.2 Guidance.14
6.7 Information management process .15
6.7.1 General.15
6.7.2 Guidance.15
6.8 Measurement process .16
6.8.1 General.16
6.8.2 Guidance.16
6.9 Quality assurance process .17
6.9.1 General.17
6.9.2 Guidance.17
7 Elements of the project management plan .18
7.1 General .18
7.2 Front matter .18
7.3 Project overview .18
7.3.1 Project summary .18
7.4 References .19
7.5 Definitions .19
7.6 Project context.20
7.6.1 Process model .20
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved iii

7.6.2 Process improvement .20
7.6.3 Infrastructure and enabling systems .20
7.6.4 Methods, tools and techniques .20
7.6.5 Product acceptance.20
7.6.6 Project organization .21
7.7 Project planning .21
7.7.1 General.21
7.7.2 Project initiation .21
7.7.3 Project work plans.22
7.8 Project assessment and control .23
7.8.1 General.23
7.8.2 Requirements management .23
7.8.3 Scope change control .24
7.8.4 Schedule control .24
7.8.5 Budget control .24
7.8.6 Quality assurance .24
7.8.7 Subcontractor management .24
7.8.8 Project closeout .24
7.9 Product delivery .25
7.10 Supporting processes .25
7.10.1 General.25
7.10.2 Project supervision and work environment .25
7.10.3 Decision management .25
7.10.4 Risk management .25
7.10.5 Configuration management .26
7.10.6 Information management .26
7.10.7 Quality assurance .27
7.10.8 Measurement .27
7.10.9 Reviews and audits .27
7.10.10 Verification and validation .27
7.11 Additional plans .28
7.12 End matter .28
Bibliography .29
IEEE notices and abstract .30
© ISO/IEC 2019 – All rights reserved
iv © IEEE 2019 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
rules given in the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of
the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see http:// patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Systems and software engineering, in cooperation with the Software & Systems
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards
Development Organization cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 16326:2009), which has been
technically revised.
The main changes compared to the previous edition are as follows:
a) re-ordered the original Clauses 2 and 4, and added a new Clause 2 to comply with the new
ISO document fixed structure requirements;
b) moved the process guidelines up in front of the project management plan content requirements to
put more emphasis on the process rather than the “product;”
c) changed the citation tables in the new Clause 6 to a single column so that the corresponding content
is identical to both ISO/IEC/IEEE 15288:2015 and ISO/IEC/IEEE 12207:2017;
d) added references in the applicable guidance portions of the new Clause 6 that point to
the more detailed process guidance information in ISO/IEC/IEEE 24748-4:2016 and
ISO/IEC/IEEE 24748-5:2017;
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved v

e) removed the PMP format requirements from the new Clause 7;
f) re-ordered the Bibliography to list the citations in numerical order.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO/IEC 2019 – All rights reserved
vi © IEEE 2019 – All rights reserved

Introduction
This document provides normative content specifications for project management plans concerned
with systems, and software systems.
This document also provides detailed discussion and advice on applying a set of technical
management processes that are common to both the system and software life cycles as covered by
ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 respectively. The discussion and advice are intended to
aid in the preparation of the normative content of project management plans.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC/IEEE 16326:2019(E)
Systems and software engineering — Life cycle processes
— Project management
1 Scope
1.1 Purpose
This document is intended to aid project managers in managing to successful conclusion those projects
concerned with systems, including software systems.
This document specifies the required content of the project management plan (PMP). This document
also quotes the extracted purpose and outcome statements from the technical management processes
of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, and adds detailed guidance for managing projects
that use these processes for systems, including software systems.
1.2 Field of application
This document is written for those who use or plan to use ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207
on projects dealing with systems, including software systems, regardless of project scope, products,
methodology, size or complexity. The field of application of this document spans the whole system or
software life cycle and addresses all project management roles, specifically:
— those responsible for establishing and continuously improving their organization’s policies for
implementing ISO/IEC/IEEE 15288 system life cycle processes and ISO/IEC/IEEE 12207 software
life cycle processes;
— those responsible for executing any ISO/IEC/IEEE 15288 system life cycle process or
ISO/IEC/IEEE 12207 software life cycle process at a project level.
— organizations or individuals subcontracting a project management effort.
In many organizations, the various responsibilities of project management are assigned to more
than one person. Where the term "project manager" is used in this document, the guidance, advice or
normative requirement is taken as applying to the applicable role within the organization.
This document is intended to provide guidance for two-party situations and can be equally applied
where the two parties are from the same organization. This document can also be used by a single
party as self-imposed tasks.
This document can also serve as guidance in multi-party situations, where high risks are inherent in
the supply and integration of complex software-based systems, and procurement can involve several
vendors, organizations or contracting parties.
1.3 Limitations
The normative content specifications for PMPs and the guidance for application of the technical
management processes have general application across the scope of ISO/IEC/IEEE 15288 and
ISO/IEC/IEEE 12207, but are developed with a focus on projects dealing with systems with a significant
software element, and software systems.
2 Normative References
There are no normative references in this document.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 1

3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
No terms and definitions are listed in this document.
ISO, IEC and IEEE maintain terminological databases for use in standardization at the following
addresses:
— ISO Online browsing platform: available at http:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
— IEEE Standards Dictionary Online: available at http:// ieeexplore .ieee .org/ xpls/ dictionary
3.2 Abbreviated terms
CDRL contract data requirements list
ICWG interface control working group
PERT program evaluation review technique
PM project management (or project manager)
PMP project management plan
PPL product parts list
SDP software development plan
SEE software engineering environment
SEMP systems engineering management plan
SWEBoK software engineering body of knowledge
WBS work breakdown structure
4 Conformance
4.1 General
This document provides normative definition of the content of the PMP and provides guidance for the
execution of the technical management processes of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207.
Users of this document can claim conformance to the normative documentation content, to the process
provisions, or both.
4.2 Conformance to the normative documentation content
A claim of conformance to the documentation provisions of this document means that the user
demonstrates that the content of a PMP conforms to the content requirements specified in Clause 7.
4.3 Conformance to processes
A claim of conformance to the process provisions of this document is equivalent to claiming conformance
to the technical management processes from ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 cited in
Clause 6.
© ISO/IEC 2019 – All rights reserved
2 © IEEE 2019 – All rights reserved

4.4 Full conformance
A claim of full conformance to this document is equivalent to claiming conformance to the PMP content
requirements cited in Clause 7 and the technical management processes of ISO/IEC/IEEE 15288 and
ISO/IEC/IEEE 12207 cited in Clause 6.
5 Application of this document
This document specifies the required content of the PMP such that the overall content of the plan, when
executed successfully, fulfils the purposes and desired outcomes which are specified by the technical
management processes of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207.
The technical management processes of ISO/IEC/IEEE 15288 and of ISO/IEC/IEEE 12207 contain the
generic activities and tasks, which can be employed by any party that has to manage a project dealing
with systems, including software systems. This document provides additional detailed guidance in
Clause 6 to assist managers of these projects as they prepare and execute the PMP for a specific project.
NOTE 1 In the general case, any specific project exists within an organization’s business program areas
and project portfolios. The organization can have additional processes that are not directly related to project
management, but that are essential to a project’s successful execution. The organizational project-enabling
processes in ISO/IEC/IEEE 15288 and the guidance in ISO 21500 provide useful information and guidance on
how a project’s technical management processes fit into the overall organization’s process structure.
NOTE 2 Reference [2] also provides important information about managing projects.
The responsible people listed as actors for which guidance applies are those most often tasked with
the listed preparation actions, but users of this document may agree to assign the actions to different
people or organizations depending on a given program’s organizational structure.
Project managers should also apply the guidance in this document in an iterative manner to consider
any systemic impact when undertaking an action; e.g., an action or failure to act in one area can affect
other areas.
6 Technical management processes
6.1 General
This clause examines the eight technical management processes of ISO/IEC/IEEE 15288 and
ISO/IEC/IEEE 12207 i.e.:
— Project planning process;
— Project assessment and control process;
— Decision management process;
— Risk management process;
— Configuration management process;
— Information management process;
— Measurement process;
— Quality assurance process.
NOTE ISO/IEC/IEEE 15288 uses the identical process model for process purposes and outcomes as
ISO/IEC/IEEE 12207, but its tasks and activities differ.
This clause provides detailed discussion and application advice as it applies to the management of
projects dealing with systems, including software systems. The discussion and advice are intended
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 3

to aid project managers in managing a specific project (e.g., direct management and control of
the work, management of the scope, management of the schedule, management of the budget and
costs, management of resources, management of stakeholders, risk management, and procurement
management).
Normative project process portions from both ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 are
contained in boxed text, with discussion and advice for that portion immediately following. The
purposes and outcomes from ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 are essentially the same,
but may have minor editorial differences in verb tense and punctuation.
The advice given for systems projects also applies to projects undertaken to produce software
systems. Any advice given specifically for software systems is further segregated below the advice
for systems. The guidance provided for each process section in this document is designed to treat
the combined purpose and outcome statements for that section from both ISO/IEC/IEEE 15288 and
ISO/IEC/IEEE 12207.
The processes and activities for a given project can require iterative action to accomplish the
requirements of a project. For instance, based upon the life cycle model being used, processes, activities
and tasks can be employed at the same time; they can be interdependent; or they can be coordinated in
an organized series of work breakdown structure (WBS) dependencies throughout a project life cycle.
In addition, other more modern project development processes such as agile development can combine
these processes and activities in different ways.
The project manager should communicate applicable project plans, deliverables and schedules to
the organization’s affected stakeholders. The project manager should enlist their commitment to
support the technical management processes with the organization’s project-enabling processes.
ISO/IEC/IEEE 15288:2015, 6.2 and ISO/IEC/IEEE 12207:2017, 6.2 provide guidance for the following
organizational project-enabling processes:
— Life Cycle Model Management process;
— Infrastructure Management process;
— Portfolio Management process;
— Human Resource management process;
— Quality Management process;
— Knowledge Management process.
© ISO/IEC 2019 – All rights reserved
4 © IEEE 2019 – All rights reserved

6.2 Project planning process
6.2.1 General
ISO/IEC/IEEE 15288:2015 and ISO/IEC/IEEE 12207:2017
6.3.1 Project planning process
6.3.1.1 Purpose
The purpose of the Project Planning process is to produce and coordinate effective and workable
plans.
This process determines the scope of the project management and technical activities, identifies
process outputs, tasks and deliverables, establishes schedules for task conduct, including
achievement criteria, and required resources to accomplish tasks. This is an on-going process that
continues throughout a project, with regular revisions to plans.
6.3.1.2 Outcomes
As a result of the successful implementation of the Project Planning process:
a) Objectives and plans are defined.
b) Roles, responsibilities, accountabilities, authorities are defined.
c) Resources and services necessary to achieve the objectives are formally requested and
committed.
d) Plans for the execution of the project are activated.
6.2.2 Guidance
NOTE 1 ISO/IEC/IEEE 24748-4 and ISO/IEC/IEEE 24748-5 provide detailed guidance on the processes
required for successful planning, execution and management of a project’s systems and software engineering
efforts, respectively.
a) The strategies defined in the guidance sections of each of the other Technical Management
processes in this clause provide inputs and are integrated in the Project Planning process. The
Project Assessment and Control process is used to assess whether the plans are integrated, aligned
and feasible.
b) The responsibility for preparing and approving plans should be assigned and documented.
c) The project manager should plan the management of project requirements including their
elicitation, documentation and analysis.
d) Project planning should include the following activities:
1. involving all stakeholders in the requirements definition of a project;
2. establishing a baseline of project requirements;
3. establishing a sequence of activities and events at a suitable level of detail that represents the
full scope of work for the project;
4. managing change to the scope and requirements throughout a project’s life cycle; all changes in
scope and requirements should be carefully evaluated and documented;
5. reviewing the selection of processes made from a previously successful project when the scope
and requirements are changed, to help ensure that the selected processes are still applicable
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 5

after the changes in scope and requirements; this review is iterative and occurs whenever
changes in scope and requirements occur;
6. defining who is responsible for obtaining stakeholder agreement on project requirements;
7. establishing and maintaining traceability between requirements, between requirements and
design, and between requirements and tests.
NOTE 2 "project requirements" can include process requirements (for the project activities) as well
as product requirements (for the product of interest or enabling products).
e) Systems engineering efforts should be conducted with the required systems engineering resources
and skills.
f) Software engineering efforts should be conducted with the required software engineering
resources and skills.
g) Project planning should identify and document the activities required to translate stakeholder
requirements into project deliverables and/or activities to be carried out that will ensure products
are delivered as specified in a contract, i.e., ensure a project includes all the work required, and
only the work required, to complete the project and product successfully.
h) Project planning should include all aspects of process tailoring to account for the type of project: a
new development, embedding in or integration with a larger system, modification of off-the-shelf
software product, porting to different operating systems, etc. Process tailoring is fundamental for
consistency of a project's activities within the organization and includes tailoring of various levels of
standardized processes from the organization's enterprise level down to the specific project level.
NOTE 3 Refer to ISO/IEC/IEEE 15288:2015, Annex A and/or ISO/IEC/IEEE 12207:2017, Annex A for
details of the tailoring process.
i) For iterative life cycle models, the scope of the project can be revised as understanding of
requirements evolves, with agreement of the acquirer and supplier. An initial scope statement is
usually based on stated or elicited customer/user requirements, but risks, changes in stakeholder
requirements, environment, project budget and schedule, and an evolving design make it necessary
to continually reassess and reaffirm agreements and commitments and make appropriate changes
to the project scope statement, as required. Project managers should also determine the feasibility
of the planned technical management processes to help ensure personnel, materials, facilities,
Systems/Software Engineering Environment and technology required to execute and manage a
project are available, adequate and appropriate; and the predetermined times for completion are
achievable, timely and economical. The results of this feasibility analysis could cause an adjustment
to the initial project scope statement. Multiple iterations can be required to achieve a good fit
between the project scope statement and the internal project plans and processes.
j) Planning the scope of the project can be difficult when a new project has unprecedented
elements. For such a project, care should be taken to ensure it is properly scoped and monitored.
The organization's risk management process should identify detailed mitigation plans, if it is
determined that additional risk exists due to the unfamiliar project.
NOTE 4 ISO 10006 provides guidelines for project management to help ensure proper quality of their
project’s products and services.
k) Project managers should select a life cycle model appropriate to the project being undertaken.
Incremental and evolutionary types of life cycle models typically have advantages over waterfall
or ‘Big Bang’ models and can be less risky than other life cycle models, particularly for software
systems.
l) The planning process should establish completion criteria for all project tasks. The intent,
as supported by ISO 21500, is to determine if a project, activity or task has been completed
successfully.
© ISO/IEC 2019 – All rights reserved
6 © IEEE 2019 – All rights reserved

m) Project plans should implement agreed-upon assignment of intellectual property ownership and
ensure agreements created or used in the project address this matter.
n) If not addressed as part of the terms and conditions of the agreement between the acquirer and
supplier, the project manager should include in the project planning a task to identify with the
acquirer at what point the acquirer gains ownership of the project’s deliverable products, or, if
ownership is not to be granted, what the licensing agreement will be. Source code escrow should
also be considered to ensure that the acquirer can continue to use the software in the event of the
supplier going out of business.
o) A project should have one master schedule and all subordinate schedules should be integrated and
consistent with the master schedule. A WBS should be used to define the total scope of work for the
project. The WBS should be constructed to allow a project to be managed at the appropriate level of
granularity consistent with the size, complexity, criticality and risk of the project. The WBS can be
used as a basis of measuring project progress and to provide visibility into subordinate processes
and products.
p) Project estimates used in planning should include:
1. costs associated with process execution;
2. nonrecurring costs to produce products;
3. recurring costs, per year, required of the organization as a result of project completion;
4. changes to or creation of infrastructure and enabling systems such as an SEE;
5. need for resources, including related management and control;
6. skill and experience level of personnel assigned to the project;
7. quality assurance and control;
8. risk management;
9. work to be performed in each process and/or activity;
10. configuration management;
11. technical performance measures (e.g., response time, throughput, memory utilization,
bandwidth).
q) Project managers should use existing organizational infrastructure whenever appropriate. When
existing infrastructure is inappropriate or insufficient to support a project, then adaptation
or additions to existing infrastructure should be identified, planned and implemented. This can
require the use of subcontracting to satisfy infrastructure deficiencies.
r) Project plans should describe the activities or tasks to facilitate re-planning and refinement of
estimates throughout a project life cycle. There are many interdependencies on every project and
several iterations of planning are usually required to obtain even an initial PMP. Re-estimation can
be done on a monthly basis and periodically as necessary. Re-estimation can also be required in a
stepwise manner at major project phase points such as customer reviews. For information needed
by a PMP but provided in other plans, the PMP may reference the other plans.
s) Plans should be updated and be consistent with Clause 7.
t) The project manager should place under project configuration management the PMP and all plans it
references. The PMP and subordinate plans should then be managed as a baseline set of documents,
with changes coordinated accordingly.
u) Project planning should describe a mechanism for conflict resolution or escalation so an
appropriately authorized level of organizational management can resolve disagreements between
the project manager and supporting process management.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 7

v) Whenever supporting processes are performed by organizations outside the direct organizational
control of the project manager, it is important to realize the existence of two sets of relationships
between: 1) the project manager and the supporting process management, and 2) the supported
and supporting organizational management. The project manager should recognize this when
considering aspects of planning, implementation, control and reporting through clearly specified
technical and management reporting, information flow and dispute resolution. Synchronization of
plans can be more difficult under subcontract agreements and tasking, but can be aided by having
one master plan.
w) The project should make use of historical project data when developing estimates and plans.
In the absence of historical data, project risks are much higher, and planning requires careful
considerations by all stakeholders. The project should plan for a mechanism to collect, analyze,
archive and retrieve project data. These historical data may be used to improve life cycle processes
and support planning and analysis for future projects.
x) When multiple teams from one or more organizations participate in a project, the project manager
should integrate these teams by requiring each team to es
...