ISO/IEC TS 33061:2021

TECHNICAL ISO/IEC TS
SPECIFICATION 33061
First edition
2021-04
Information technology — Process
assessment — Process assessment
model for software life cycle processes
Reference number
©
ISO/IEC 2021
© ISO/IEC 2021
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 at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2021 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 The process assessment model . 1
4.1 General . 1
4.2 Structure of the process assessment model . 3
4.2.1 General. 3
4.2.2 Processes . 3
4.2.3 Process dimension . 4
4.2.4 Quality dimension . 4
4.3 Assessment indicators . 4
5 The process dimension . 5
5.1 General . 5
5.2 Agreement processes (AGR). 6
5.2.1 General. 6
5.2.2 Acquisition process . 6
5.2.3 Supply process . 8
5.3 Organizational project-enabling processes (ORG) . 9
5.3.1 General. 9
5.3.2 Life cycle model management process . 9
5.3.3 Infrastructure management process .10
5.3.4 Portfolio management process .11
5.3.5 Human resource management process .12
5.3.6 Quality management process.13
5.3.7 Knowledge management process .14
5.4 Technical management processes (MAN) .15
5.4.1 General.15
5.4.2 Project planning process .16
5.4.3 Project assessment and control process .17
5.4.4 Decision management process .19
5.4.5 Risk management process .20
5.4.6 Configuration management process .22
5.4.7 Information management process .24
5.4.8 Measurement process .25
5.4.9 Quality assurance process .26
5.5 Technical processes (TEC) .28
5.5.1 General.28
5.5.2 Business or mission analysis process .28
5.5.3 Stakeholder needs and requirements definition process .30
5.5.4 System/software requirements definition process .33
5.5.5 Architecture definition process .35
5.5.6 Design definition process .38
5.5.7 System analysis process.40
5.5.8 Implementation process .42
5.5.9 Integration process .44
5.5.10 Verification process .45
5.5.11 Transition process .47
5.5.12 Validation process . . .49
5.5.13 Operation process .51
5.5.14 Maintenance process .53
© ISO/IEC 2021 – All rights reserved iii

5.5.15 Disposal process .55
6 The quality dimension.57
Annex A (informative) Process outputs .58
Bibliography .73
iv © ISO/IEC 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, 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
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives or www .iec .ch/ members
_experts/ refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO 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 IEClist 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. In the IEC, see www .iec .ch/ understanding -standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
This document cancels and replaces ISO/IEC 15504-5:2012, which has been technically revised.
The main changes compared to ISO/IEC 15504-5:2012 are as follows:
— all processes and their base practices are changed to reflect the ISO/IEC/IEEE 12207 processes;
— all process related process outputs and their descriptions are revised;
— this process assessment model includes a process quality attribute of process performance and can
be used with other models of process quality, for instance capability as described in ISO/IEC 33020.
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 and www .iec .ch/ national
-committees.
© ISO/IEC 2021 – All rights reserved v

Introduction
The set of International Standards ISO/IEC 33001 to ISO/IEC 33099, termed the ISO/IEC 330xx family,
defines the requirements and resources needed for process assessment. The overall architecture
and content of the ISO/IEC 330xx family is described in ISO/IEC 33001. Several standards in the
ISO/IEC 330xx family for process assessment are intended to replace and extend parts of the
ISO/IEC 15504 series. Abstracts and previews of the ISO/IEC 330xx family of standards can be found on
the ISO website.
This document defines a process assessment model for software life cycle processes, conformant with
the requirements of ISO/IEC 33004, for use in performing a conformant assessment in accordance with
the requirements of ISO/IEC 33002.
A process assessment model is related to one or more process reference models. The process reference
model defined in ISO/IEC/IEEE 12207 is used as the basis for the process assessment model in this
document.
A process assessment model incorporates a process measurement framework conformant with the
requirements of ISO/IEC 33003 and is expressed as a process quality characteristic with a defined set
of process attributes.
A process assessment model includes a set of assessment indicators. Process performance indicators
address the process purpose and outcomes of each process in the process assessment model. Process
quality indicators demonstrate the achievement of the process attributes in the process measurement
framework. These indicators may also provide a reference source of practices when implementing a
process improvement program.
The assessment indicators are used as a basis for collecting objective evidence to support an assessor’s
judgement in assigning ratings of the performance and quality of an implemented process. The set
of indicators defined in this document are not intended to be an all-inclusive set and applicable in
its entirety. Subsets appropriate to the context and scope of the assessment should be selected, and
potentially augmented with additional indicators.
A process assessment is conducted according to a documented assessment process. A documented
assessment process identifies the rating method to be used in rating process attributes and identifies
or defines the aggregation method to be used in determining ratings.
ISO/IEC 33020 provides a process measurement framework for the assessment of process
capability which may be incorporated as a process measurement framework in this document.
ISO/IEC 33020:2019, Annex B includes a set of process quality indicators for each process attribute in
the process measurement framework.
vi © ISO/IEC 2021 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 33061:2021(E)
Information technology — Process assessment — Process
assessment model for software life cycle processes
1 Scope
This document defines a process assessment model for software life cycle processes, conformant with
the requirements of ISO/IEC 33004, for use in performing a conformant assessment in accordance with
the requirements of ISO/IEC 33002.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes
ISO/IEC 33001, Information technology — Process assessment — Concepts and terminology
ISO/IEC 33003:2015, Information technology — Process assessment — Requirements for process
measurement frameworks
ISO/IEC 33004:2015, Information technology — Process assessment — Requirements for process reference,
process assessment and maturity models
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 33001 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
4 The process assessment model
4.1 General
This document provides a basis for a process assessment model that is two-dimensional. In one
dimension, the process dimension, the processes are defined and classified into process groups
together with the set of assessment indicators of process performance. In the other dimension, the
quality dimension, for each process attribute in the process measurement framework a set of process
quality indicators is defined for the selected process quality characteristic.
This document applies the software system concepts as defined in ISO/IEC/IEEE 12207. These concepts
include software systems, software system architecture and enabling systems.
NOTE 1 The software systems considered in this document are human-made, created and utilized to provide
products or services in defined environments for the benefit of users and other stakeholders. These software
systems can include the following system elements: hardware, software, data, humans, processes (e.g. processes
for providing service to users), procedures (e.g. operator instructions), facilities, services, materials and naturally
occurring entities. As viewed by the user, they are thought of as products or services. (ISO/IEC/IEEE 12207)
© ISO/IEC 2021 – All rights reserved 1

NOTE 2 This document applies to systems for which software is of primary importance to the stakeholders.
It is based upon the general principles of systems engineering and software engineering. It is a fundamental
premise of this document that software always exists in the context of a system. Since software does not
operate without hardware, the processor upon which the software is executed can be considered as part of
the system. Alternatively, hardware or services hosting the software system and handling communications
with other systems can also be viewed as enabling systems or external systems in the operating environment.
The perception and definition of a particular software system, its architecture, and its elements depend on a
stakeholder’s interests and responsibilities. One stakeholder’s system-of-interest can be viewed as a system
element in another stakeholder’s system-of-interest. Furthermore, a system-of-interest can be viewed as being
part of the environment for another stakeholder’s system-of-interest. (ISO/IEC/IEEE 12207)
NOTE 3 The life cycle processes in this document are described in relation to a software system that is
composed of interacting system elements (including software elements), each of which can be implemented to
fulfil its respective specified requirements. Responsibility for the implementation of any system element may
therefore be delegated to another party through an agreement. (ISO/IEC/IEEE 12207)
NOTE 4 Throughout the life cycle of a system-of-interest, essential services are required from systems that
are not directly a part of the operational environment of the system-of-interest, e.g. modelling system, training
system, maintenance system. Each of these systems enables a part, e.g. a stage of the life cycle of the system-
of-interest to be conducted. Termed "enabling systems", they facilitate progression of the system-of-interest
through its life cycle. (ISO/IEC/IEEE 12207)
Figure 1 — Structure of the process assessment model
Figure 1 shows the process assessment model as a two-dimensional model, the process dimension
with its relationship to ISO/IEC/IEEE 12207 software life cycle processes, and the quality dimension in
relationship to a process measurement framework.
Users of this document may freely reproduce the detailed descriptions contained in the assessment
model as part of any tool or other material to support the performance of process assessments, so that
it can be used for its intended purpose.
2 © ISO/IEC 2021 – All rights reserved

4.2 Structure of the process assessment model
4.2.1 General
This subclause describes the detailed structure of the process assessment model and its key
components.
The process dimension comprises the set of processes defined with process purpose and process
outcomes together with a set of assessment indicators of process performance.
Processes included in a process reference model shall be in accordance with ISO/IEC 33004:2015, 5.4.
The processes in this document are derived directly from ISO/IEC/IEEE 12207 and meet the
ISO/IEC 33004 requirements for process descriptions, process purposes and outcomes.
The quality dimension comprising a set of process attributes for a selected process quality characteristic
is incorporated as a process measurement framework together with a set of process quality indicators.
NOTE ISO/IEC 33020 provides a process measurement framework for the assessment of process capability
which can be incorporated into this document. ISO/IEC 33020 also includes a set of process quality indicators for
each process attribute in the process measurement framework.
4.2.2 Processes
The process assessment model is based upon the software life cycle processes defined in
ISO/IEC/IEEE 12207. The process reference model drawn from ISO/IEC/IEEE 12207 consists of the
process purpose and outcomes defined in that standard. The purpose and outcomes are a statement of
the goals of the performance of each process.
In this document, ISO/IEC/IEEE 12207 serves as the process reference model for process assessments;
any other use of the processes shall adhere to the requirements of ISO/IEC/IEEE 12207.
Figure 2 lists the processes from ISO/IEC/IEEE 12207 that are included in the process dimension of the
process assessment model and shows their classification into process groups.
The process groups and their associated processes are described in Clause 5. The description of each
process group includes a characterization of the processes it contains. In this process assessment
model, each process belonging to a group is identified with a process identifier (ID) consisting of the
group abbreviated name and the sequential number of the process in that group.
© ISO/IEC 2021 – All rights reserved 3

Figure 2 — Process groups
4.2.3 Process dimension
Each process has a process identifier (ID) consisting of the process group abbreviated name and
the sequential number of the process in that group. Each process is described by its name, purpose,
outcomes, base practices, and process outputs.
Each process is described in terms of a purpose statement. These statements contain the unique
functional objectives of the process when performed in a particular environment. A list of specific
process outcomes is associated with each of the process purpose statements, as a list of expected
positive results of the process performance.
4.2.4 Quality dimension
For the quality dimension, the minimum requirement is that the process is performed, i.e. the
implemented process achieves its process purpose and the expected outcomes are observable.
Process attributes are features of a process that can be evaluated on a scale of achievement, providing a
measure of the quality of the process and are applicable to all processes.
4.3 Assessment indicators
A process assessment model is based on the principle that the quality of a process can be assessed by
demonstrating the achievement of process attributes on the basis of evidences related to assessment
indicators.
There are two types of assessment indicators: process performance indicators and process quality
indicators. Process performance indicators address the process purpose and outcomes of each process
in the process dimension. Process quality indicators demonstrate the achievement of the process
attributes in the quality dimension.
4 © ISO/IEC 2021 – All rights reserved

The process performance indicators are:
— base practice (BP);
— process output (PO).
The performance of base practices (BPs) provides an indication of the extent of achievement of the
process purpose and process outcomes. The base practices correspond to ISO/IEC/IEEE 12207
activities and tasks. Process outputs (POs) are either used or produced (or both), when performing the
process. Information items that are the key outputs of the process, are primarily used as performance
indicators.
Annex A provides the list of process outputs associated with the processes in Clause 5. The process
outputs are identified by categories. The process outputs are indicated by the process IDs.
Process quality indicators depend on the process quality characteristic of interest. The minimum
requirement is that at least one of the process attributes shall comprise the achievement of the defined
process purpose and process outcomes for the process; this is termed the process performance attribute
(see ISO/IEC 33003:2015, 4.2.1). Other process quality attributes can be defined as needed.
The process performance and process quality indicators represent types of objective evidence that can
be found in an instantiation of a process and therefore can be used to judge achievement of quality.
Figure 3 shows how the assessment indicators are related to process performance and process quality.
Figure 3 — Assessment indicators
5 The process dimension
5.1 General
The process dimension comprises the set of processes defined with process purpose and process
outcomes together with a set of assessment indicators of process performance.
The individual processes each have a process identifier (ID) consisting of the process group abbreviated
name and the sequential number of the process in that group and are described in terms of process
© ISO/IEC 2021 – All rights reserved 5

name, process purpose, and process outcomes as defined in ISO/IEC/IEEE 12207. The process group
descriptions are compiled from ISO/IEC/IEEE 12207.
In addition, the process dimension of the process assessment model provides information in the form of
a set of:
a) base practices for the process providing a definition of the tasks and activities needed to accomplish
the process purpose and fulfil the process outcomes; each base practice is associated to one or
more process outcomes;
b) process outputs that are related to one or more process outcomes;
The process purposes, outcomes, base practices and process outputs associated with the processes
are included in this clause. The base practices and process outputs constitute the set of indicators of
process performance.
A documented assessment process and assessor judgment is needed to ensure that process context
(application domain, business purpose, development methodology, size of the organization, etc.) is
explicitly considered when using this information.
5.2 Agreement processes (AGR)
5.2.1 General
Organizations are producers and users of software systems. One organization (acting as an acquirer)
can task another (acting as a supplier) for products or services. This is achieved using agreements.
Agreements allow both acquirers and suppliers to realize value and support business strategies for
their organizations.
The agreement processes are organizational processes that apply outside of the span of a project’s life,
as well as for a project’s lifespan. Generally, organizations act simultaneously or successively as both
acquirers and suppliers of software systems. The agreement processes can be used with less formality
when the acquirer and the supplier are in the same organization. Similarly, they can be used within the
organization to agree on the respective responsibilities of organization, project and technical functions.
This subclause specifies the requirements for the establishment of agreements with organizational
entities external and internal to the organization.
The agreement processes consist of the following:
a) acquisition process – used by organizations for acquiring products or services;
b) supply process – used by organizations for supplying products or services.
These processes define the activities necessary to establish an agreement between two organizations.
If the acquisition process is invoked, it provides the means for conducting business with a supplier.
This may include products that are supplied for use as an operational software system, services in
support of operational activities, software elements of a system, or elements of a software system being
provided by a supplier. If the supply process is invoked, it provides the means for an agreement in which
the result is a product or service that is provided to the acquirer.
NOTE Security is an increasing concern in systems and software engineering. See ISO/IEC 27036 (all parts)
for requirements and guidance for suppliers and acquirers on how to secure information in supplier relationships.
Specific aspects of information security supplier relationships are addressed in ISO/IEC 27036-3:2013 and
ISO/IEC 27036-4. (ISO/IEC/IEEE 12207)
5.2.2 Acquisition process
Process ID AGR.1
Process name Acquisition process
6 © ISO/IEC 2021 – All rights reserved

Process purpose The purpose of the acquisition process is to obtain a product or service in ac-
cordance with the acquirer's requirements.
NOTE As part of this process, the agreement is modified when a change request
is agreed to by both the acquirer and supplier.
Process outcomes As a result of the successful implementation of the acquisition process:
a) A request for supply is prepared.
b) One or more suppliers are selected.
c) An agreement is established between the acquirer and supplier.
d) A product or service complying with the agreement is accepted.
e) Acquirer obligations defined in the agreement are satisfied.
Base practices AGR.1.BP1: Prepare for the acquisition. [Outcome: a]

1) Define a strategy for how the acquisition will be conducted.

2) Prepare a request for the supply of a product or service that includes the
requirements.
AGR.1.BP2: Advertise the acquisition and select the supplier. [Outcome: b]
1) Communicate the request for the supply of a product or service to potential
suppliers.
2) Select one or more suppliers.
AGR.1.BP3: Establish and maintain an agreement. [Outcome: c, d]
1) Develop an agreement with the supplier that includes acceptance criteria.
2) Identify necessary changes to the agreement.
3) Evaluate impact of changes on the agreement.
4) Negotiate the agreement with the supplier.
5) Update the agreement with the supplier, as necessary.
AGR.1.BP4: Monitor the agreement. [Outcome: d, e]
1) Assess the execution of the agreement.
2) Provide data needed by the supplier and resolve issues in a timely manner.
AGR.1.BP5: Accept the product or service. [Outcome: d, e]
1) Confirm that the delivered product or service complies with the agreement.
2) Provide payment or other agreed consideration.
3) Accept the product or service from the supplier, or other party, as directed
by the agreement.
4) Close the agreement.
Process outputs Acquisition approach [Outcome: a]
Request for supply [Outcome: a]
Acquisition agreement [Outcome: c]
Acquisition agreement change request [Outcome: c]
Accepted system or system element (e.g. software) [Outcome: d]
Acquisition report [Outcome: e]
Acquisition record [Outcome: e]
© ISO/IEC 2021 – All rights reserved 7

5.2.3 Supply process
Process ID AGR.2
Process name Supply process
Process purpose The purpose of the Supply process is to provide an acquirer with a product or
service that meets agreed requirements.
Process outcomes As a result of the successful implementation of the Supply process:
a) An acquirer for a product or service is identified.
b) A response to the acquirer's request is produced.
c) An agreement is established between the acquirer and supplier.
d) A product or service is provided.
e) Supplier obligations defined in the agreement are satisfied.
f) Responsibility for the acquired product or service, as directed by the agree-
ment, is transferred.
Base practices AGR.2.BP1: Prepare for the supply. [Outcome: a]

1) Determine the existence and identity of an acquirer who has a need for a
product or service.
2) Define a supply strategy.
AGR.2.BP2: Respond to a request for supply of products or services. [Out-
come: b]
1) Evaluate a request for the supply of a product or service to determine feasi-
bility and how to respond.
2) Prepare a response that satisfies the solicitation.
AGR.2.BP3: Establish and maintain an agreement. [Outcome: c]
1) Negotiate an agreement with the acquirer that includes acceptance criteria.
2) Identify necessary changes to the agreement.
3) Evaluate impact of changes on the agreement.
4) Negotiate the agreement with the acquirer, as necessary.
5) Update the agreement with the acquirer, as necessary.
AGR.2.BP4: Execute the agreement. [Outcome: d, e]
1) Execute the agreement according to the established project plans.
2) Assess the execution of the agreement.
AGR.2.BP5: Deliver and support the product or service. [Outcome: d, e, f]
1) Deliver the product or service in accordance with the agreement criteria.
2) Provide assistance to the acquirer in support of the delivered product or ser-
vice, per the agreement.
3) Accept and acknowledge payment or other agreed consideration.
4) Transfer the product or service to the acquirer, or other party, as directed by
the agreement.
5) Close the agreement.
8 © ISO/IEC 2021 – All rights reserved

Process outputs Supply approach [Outcome: a]
Request for supply response [Outcome: b]
Supply agreement [Outcome: c]
Supply agreement change request [Outcome: c]
Supplied system [Outcome: d]
Supply report [Outcome: e, f]
Supply record [Outcome: e, f]
NOTE As part of this process, the agreement is modified when a change request affecting the terms of the
agreement is agreed to by both the acquirer and supplier. (ISO/IEC/IEEE 12207)
5.3 Organizational project-enabling processes (ORG)
5.3.1 General
The organizational project-enabling processes are concerned with providing the resources to enable
the project to meet the needs and expectations of the organization’s stakeholders. The organizational
project-enabling processes are typically concerned at a strategic level with the management and
improvement of the organization’s business or undertaking, with the provision and deployment of
resources and assets, and with its management of risks in competitive or uncertain situations. The
organizational project-enabling processes apply outside the span of a project’s life, as well as during a
project’s lifespan.
The organizational project-enabling processes establish the environment in which projects are
conducted. The organization establishes the processes and life cycle models to be used by projects;
establishes, redirects, or cancels projects; provides resources required, including human and financial;
and sets and monitors the quality measures for software systems and other deliverables that are
developed by projects for internal and external customers.
The organizational project-enabling processes create a strong business image for many organizations
and imply commercial and profit-making motives. Nevertheless, the organizational project-enabling
processes are equally relevant to non-profit organizations, since they are also accountable to
stakeholders, are responsible for resources, and encounter risk in their undertakings. This document
can be applied to non-profit organizations as well as to profit-making organizations.
The organizational project-enabling processes help ensure the organization’s capability to acquire and
supply products or services through the initiation, support and control of projects. These processes
provide resources and infrastructure necessary to support projects and help ensure the satisfaction of
organizational objectives and established agreements. They are not intended to be a comprehensive set
of business processes that enable strategic management of the organization’s business.
5.3.2 Life cycle model management process
Process ID ORG.1
Process name Life cycle model management process
Process purpose The purpose of the life cycle model management process is to define, maintain,
and assure availability of policies, life cycle processes, life cycle models, and pro-
cedures for use by the organization with respect to the scope of this document.
This process provides life cycle policies, processes, models, and procedures that
are consistent with the organization's objectives, that are defined, adapted, im-
proved and maintained to support individual project needs within the context
of the organization, and that are capable of being applied using effective, proven
methods and tools.
© ISO/IEC 2021 – All rights reserved 9

Process outcomes As a result of the successful implementation of the life cycle model management
process:
a) Organizational policies and procedures for the management and deployment
of life cycle models and processes are established.
b) Responsibility, accountability, and authority within life cycle policies, processes,
models, and procedures are defined.
c) Life cycle models and processes for use by the organization are assessed.
d) Prioritized process, model, and procedure improvements are implemented.
Base practices ORG.1.BP1: Establish the process. [Outcome: a, b]

1) Establish policies and procedures for process management and deployment
that are consistent with organizational strategies.

2) Establish the processes that implement the requirements of this document
and that are consistent with organizational strategies.
3) Define the roles, responsibilities, accountabilities, and authorities to facilitate
implementation of processes and the strategic management of life cycles.
4) Define business criteria that control progression through the life cycle.
5) Establish standard life cycle models for the organization that are comprised
of stages, and define the purpose and outcomes for each stage.
ORG.1.BP2: Assess the process. [Outcome: c]
1) Monitor process execution across the organization.
2) Conduct periodic reviews of the life cycle models used by the projects.
3) Identify improvement opportunities from assessment results.
ORG.1.BP3: Improve the process. [Outcome: d]
1) Prioritize and plan improvement opportunities.
2) Implement improvement opportunities and inform relevant stakeholders.
Process outputs Life cycle model management strategy [Outcome: a, c, d]
Organization policy [Outcome: a, b]
Organization procedure [Outcome: a, b]
Life cycle models [Outcome: a, b]
Organizational measurement needs [Outcome: c, d]
Organizational performance data [Outcome: c, d]
Life cycle model management report [Outcome: c, d]
Life cycle model management record [Outcome: c, d]
5.3.3 Infrastructure management process
Process ID ORG.2
Process name Infrastructure management process
Process purpose The purpose of the infrastructure management process is to provide the infra-
structure and services to projects to support organization and project objectives
throughout the life cycle.
This process defines, provides and maintains the facilities, tools, and communi-
cations and information technology assets needed for the organization’s business
with respect to the scope of this document.
10 © ISO/IEC 2021 – All rights reserved

Process outcomes As a result of the successful implementation of the infrastructure management
process:
a) The requirements for infrastructure are defined.
b) The infrastructure elements are identified and specified.
c) Infrastructure elements are developed or acquired.
d) The infrastructure is available.
Base practices ORG.2.BP1: Establish the infrastructure. [Outcome: a, b, c, d]
1) Define project infrastructure requirements.
2) Identify, obtain and provide infrastructure resources and services that are
needed to implement and support projects.
ORG.2.BP2: Maintain the infrastructure. [Outcome: a, b, c, d]
1) Evaluate the degree to which delivered infrastructure resources satisfy pro-
ject needs.
2) Identify and provide improvements or changes to the infrastructure resources
as the project
requirements change.
Process outputs Infrastructure management strategy [Outcome: b, c]
Infrastructure requirements [Outcome: a]
Organization infrastructure [Outcome: b, c, d]
Infrastructure change requests [Outcome: b, c]
Infrastructure management report [Outcome: d]
Infrastructure management record [Outcome: d]
5.3.4 Portfolio management process
Process ID ORG.3
Process name Portfolio management process
Process purpose The purpose of the portfolio management process is to initiate and sustain nec-
essary, sufficient and suitable projects in order to meet the strategic objectives
of the organization.
This process commits the investment of adequate organization funding and
resources, and sanctions the authorities needed to establish selected projects.
It performs continued assessment of projects to confirm they justify, or can be
redirected to justify, continued investment.
Process outcomes As a result of the successful implementation of the portfolio management process:

a) Business venture opportunities, investments or necessities are qualified and
prioritized.
b) Projects are identified.
c) Resources and budgets for each project are allocated.
d) Project management responsibilities, accountability, and authorities are defined.
e) Projects meeting agreement and stakeholder requirements are sustained.
f) Projects not meeting agreement or satisfying stakeholder requirements are
redirected or terminated.
g) Projects that have completed agreements and satisfied stakeholder require-
ments
...