ISO/IEC 29110-5-1-1:2025

International
Standard
ISO/IEC
29110-5-1-1
First edition
Systems and software
2025-02
engineering — Life cycle profiles for
very small entities (VSEs) —
Part 5-1-1:
Software engineering guidelines for
the generic Entry profile
Reference number
© ISO/IEC 2025
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
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3  Terms and definitions . 1
4  Naming, diagramming and definitions conventions . 3
4.1 General .3
4.2 Naming, diagramming and definition conventions .3
4.3 Abbreviated terms .5
5 Overview . 5
5.1 General .5
5.2 Entry conditions to use the software Entry profile .5
5.3 Processes and activities of the software Entry profile .5
6 Project management (PM) process . 6
6.1 PM process purpose .6
6.2 PM process outcomes .7
6.3 PM roles involved .7
6.4 PM activities and tasks.7
6.4.1 Overview of the PM process .7
6.4.2 PM activities .8
6.4.3 Incorporation to project repository . 13
7 Software implementation (SI) process .13
7.1 SI process purpose . 13
7.2 SI process outcomes . 13
7.3 SI roles involved .14
7.4 SI activities and tasks .14
7.4.1 Overview of the SI process .14
7.4.2 SI activities . 15
7.4.3 Incorporation to the project repository .21
8 Description of roles .22
9 Description of work products .22
10 Software tools .32
10.1 General .32
10.2 Project management process tools.32
10.3 Software implementation process tools .32
Annex A (informative)  Deployment packages for the software Entry profile .34
Bibliography .36

© ISO/IEC 2025 – All rights reserved
iii
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 document 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).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity, or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
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 first edition cancels and replaces ISO/IEC TR 29110-5-1-1:2012, which has been technically revised.
The main changes are as follows:
— Many task statements have been reworded to facilitate their understanding. Some task statements are
deleted to make this Entry profile light-weighted and suitable for streamlining to the Basic profile.
— Conditional tasks have been added to develop optional work products (e.g. change requests) that have
been requested by a customer. This notation replaces the ‘Optional’ notation [e.g. *(optional) used in the
first edition that caused ambiguities].
— Terms have been added to Clause 3 such that this document is self-contained.
— A few terms have been modified to align this document with the updated version of standards such as
ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15289.
— NOTEs have been added for giving additional information intended to assist the understanding or use of
the text of the document.
A list of all parts in the ISO/IEC 29110 series can be found on the ISO website.
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 2025 – All rights reserved
iv
Introduction
0.1  Introduction to the ISO/IEC 29110 series
For the purpose of the ISO/IEC 29110 series, a very small entity (VSE) is an enterprise, organization (e.g.
government agency, non-profit organization), department or project having up to 25 people. Many VSEs
develop and/or maintain systems and the software components used in those systems, either as independent
products or incorporated into the larger system. Due to this, a recognition of VSEs as suppliers of high-
quality products is required.
VSEs around the world are creating valuable products and services. According to the World Bank, small and
medium enterprises (SMEs) account for about 90 % of enterprises worldwide. According to the Organisation
for Economic Co-operation and Development (OECD), SMEs represent 99 % of all businesses and generate
about 60 % of employment. Almost one person out of three is employed in a micro firm with less than 10
employees. The European Union reports that micro firms, with fewer than 10 persons, account for 93,5 % of
all enterprises and small firms, with 10 to 49 employees, account for 5,5 % of all enterprises. The challenge
facing OECD governments is to provide a business environment that supports the competitiveness of this
large heterogeneous business population and that promotes a vibrant entrepreneurial culture.
From studies and surveys conducted, it is clear that the majority of International Standards do not address
the needs of VSEs. Implementation of and conformity with these standards is difficult, if not impossible.
Consequently, VSEs have no, or very limited, ways to be recognized as entities that produce quality systems/
system elements, including software in their domain. Therefore, VSEs are excluded from some economic
activities.
It has been found that VSEs find it difficult to relate International Standards to their business needs and to
justify the effort required to apply standards to their business practices. Most VSEs can neither afford the
resources in terms of a number of employees, expertise, budget and time, nor do they see a net benefit in
establishing over-complex systems or software life cycle processes. To address some of these difficulties,
a set of guidelines has been developed based on a set of VSE characteristics. The guidelines are based on
subsets of appropriate standards processes, activities, tasks, and outcomes, referred to as Profiles. The
purpose of a profile is to define a subset of International Standards relevant to the VSEs' context; for example,
processes, activities, tasks, and outcomes of ISO/IEC/IEEE 12207 for software; and processes, activities,
tasks, and outcomes of ISO/IEC/IEEE 15288 for systems; and information products (documentation) of
ISO/IEC/IEEE 15289 for software and systems.
VSEs can achieve recognition through implementing a profile and by being audited against ISO/IEC 29110
specifications.
The ISO/IEC 29110 series can be applied at any phase of system or software development within a life
cycle. The ISO/IEC 29110 series is intended to be used by VSEs that do not have experience or expertise in
adapting/tailoring ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288 standards to the needs of a specific project.
VSEs that have expertise in adapting/tailoring ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288 are encouraged
to use those standards instead of the ISO/IEC 29110 series.
The ISO/IEC 29110 series is intended to be used with any life cycle, such as waterfall, iterative, incremental,
evolutionary or agile.
Systems, in the context of the ISO/IEC 29110 series, are typically composed of hardware and software
components.
The ISO/IEC 29110 series, targeted by audience, has been developed to improve system or software and/
or service quality, and process performance. Figure 1 describes the ISO/IEC 29110 series and positions the
parts within the framework of reference.

© ISO/IEC 2025 – All rights reserved
v
Figure 1 — The ISO/IEC 29110 series
ISO/IEC 29110-1-1 introduces processes, life cycle and standardization concepts, the taxonomy (catalogue) of
ISO/IEC 29110 profiles, and the ISO/IEC 29110 series. ISO/IEC 29110-1-1 also introduces the characteristics
and needs of a VSE, and clarifies the rationale for specific profiles, documents, standards and guidelines.
ISO/IEC 29110-1-2 defines the terms common to the ISO/IEC 29110 series. ISO/IEC 29110-1-1 and
ISO/IEC 29110-1-2 are targeted at VSEs and their customers, assessors, standards producers, tool vendors
and methodology vendors.
ISO/IEC 29110-2 introduces the concepts for systems and software engineering profiles for VSEs. It
establishes the logic behind the definition and application of profiles. For standardized profiles, it specifies
the elements common to all profiles (structure, requirements, conformity, and assessment). For domain-
specific profiles (profiles that are not standardized and developed outside of the ISO process), it provides
general guidance adapted from the definition of standardized profiles. ISO/IEC 29110-2 is targeted at profile
producers, tool vendors and methodology vendors.
ISO/IEC 29110-3 defines certification schemes, assessment guidelines, and compliance requirements for
process capability assessment, conformity assessments, and self-assessments for process improvements.
ISO/IEC 29110-3 also contains information that can be useful to developers of certification and assessment
methods and developers of certification and assessment tools. ISO/IEC 29110-3 is addressed to people
who have direct involvement with the assessment process, for example, the auditor, certification and
accreditation bodies, and the sponsor of the audit, who need guidance on ensuring that the requirements
for performing an audit have been met. ISO/IEC 29110-3 is targeted at VSEs and their customers, assessors,
accreditation bodies.
ISO/IEC 29110-4 provides the specifications for all generic profiles of the generic profile group that are based
on subsets of appropriate standards elements. ISO/IEC 29110-4 is targeted at VSEs, customers, standards
producers, tool vendors and methodology vendors.

© ISO/IEC 2025 – All rights reserved
vi
ISO/IEC 29110-5 provides a management, engineering and service delivery guidelines for profiles of the
generic profile group. ISO/IEC 29110-5 is targeted at VSEs and their customers.
ISO/IEC 29110-6 provides the specifications for specific profiles that are based on subsets of appropriate
standards elements. ISO/IEC 29110-6 is targeted at VSEs, customers, standards producers, tool vendors and
methodology vendors.
ISO/IEC 29110-7 provides a guideline for each profile of the specific profile group. ISO/IEC 29110-7 is
targeted at VSEs and their customers.
If a new profile is needed, ISO/IEC 29110-4, ISO/IEC 29110-6, ISO/IEC 29110-7 or ISO/IEC 29110-5, or all, can
be developed with minimal impact to existing documents.
Since a VSE may be an enterprise, a project or a department of an organization, a customer of a VSE can be
internal or external to the organization.
0.2  Introduction to this document
This document is the first software profile of a four-profile software engineering roadmap (i.e. Entry, Basic,
Intermediate and Advanced).
This document is intended to be used with any processes, techniques and methods that enhance the VSE's
customer satisfaction and productivity.
The life cycle processes described in the ISO/IEC 29110 series are not intended to preclude or discourage
their use by organizations larger than VSEs.
For a start-up VSE that does not have customers yet, anybody who acts on behalf of customers can play the
role of the customer.
Using this document, a VSE can obtain the following benefits:
— an agreed set of project requirements and expected work products is delivered to the customer;
— a disciplined management process that provides project visibility and corrective actions of project
problems and deviations is performed;
— a systematic software implementation process that satisfies customer needs and ensures quality work
products is followed.
VSEs that develop systems that have software components are invited to use the systems engineering Entry
profile guidelines of the ISO/IEC 29110 series (i.e. ISO/IEC 29110-5-6-1).
In this document, Annex A describes the deployment packages for the software Entry profile.
Conformity requirements for implementations of this document can be found in ISO/IEC 29110-4-1.

© ISO/IEC 2025 – All rights reserved
vii
International Standard ISO/IEC 29110-5-1-1:2025(en)
Systems and software engineering — Life cycle profiles for
very small entities (VSEs) —
Part 5-1-1:
Software engineering guidelines for the generic Entry profile
1 Scope
This document provides the management and engineering guidelines to the software Entry profile specified
in ISO/IEC 29110-4-1 through project management and software implementation processes.
This document applies to VSEs that do not develop safety-critical software.
This document applies for software development projects, which can fulfil an external or internal agreement.
This document applies to start-up VSEs (e.g. VSEs that started their operation less than three years ago)
and/or VSEs working on small projects (e.g. projects with a size of less than six person-months).
2 Normative references
There are no normative references in this document.
3  Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
agreement
mutual acknowledgment of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.5]
3.2
baseline
formally approved version of a configuration item, regardless of media, formally designated and fixed at a
specific time during the configuration item’s life cycle
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.11]
3.3
defect
imperfection or deficiency in a work product (3.14) where that work product does not meet its requirements
(3.8) or specifications and needs to be either repaired or replaced
[SOURCE: IEEE 1044:2009]
© ISO/IEC 2025 – All rights reserved
3.4
Entry profile
profile (3.5) targeted at start-up VSEs (i.e. VSEs who started their operation fewer than three years ago)
and/or at VSEs working on a single small project (3.6) (e.g. project size of less than 6 person-months)
[SOURCE: ISO/IEC 29110-1-2:2024, 3.40]
3.5
profile
subset of appropriate standards’ processes and their outcomes, activities and tasks combined to accomplish
a particular function
Note 1 to entry: The base standards used to develop profiles for VSEs are ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288
and ISO/IEC/IEEE 15289.
[SOURCE: ISO/IEC 29110-1-2:2024, 3.70]
3.6
project
endeavour with defined start and finish dates undertaken to create a product or service in accordance with
specified resources and requirements (3.8)
Note 1 to entry: A project is sometimes viewed as a unique process comprising coordinated and controlled activities
and composed of activities from the Technical Management processes and Technical processes defined in this
document.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.37]
3.7
report
information item that describes the results of activities such as investigations, observations, assessments,
or tests
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.22]
3.8
requirement
statement that translates or expresses a need and its associated constraints and conditions
Note 1 to entry: A constraint is an externally imposed limitation on the software, its design, or implementation or on
the process used to develop or modify a software.
Note 2 to entry: A condition is a measurable qualitative or quantitative attribute that is stipulated for a requirement
and that indicates a circumstance or event under which a requirement applies.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.44, modified — Notes to entry have been added.]
3.9
small and medium enterprise
SME
enterprise with less than 250 persons employed
[SOURCE: ISO/IEC 29110-1-2:2024, 3.92]
3.10
software product
set of computer programs, procedures, and possibly associated documentation and data
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.45, modified — Note 1 to entry has been removed.]

© ISO/IEC 2025 – All rights reserved
3.11
task
requirement (3.8), recommendation, or permissible action intended to contribute to the achievement of one
or more outcomes of a process
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.66]
3.12
validation
confirmation, through the provision of objective evidence, that the requirements (3.8) for a specific intended
use or application have been fulfilled
Note 1 to entry: A system is able to accomplish its intended use, goals, and objectives (i.e. meet stakeholder
requirements) in the intended operational environment. The right system was built.
Note 2 to entry: In a life cycle context, validation involves the set of activities for gaining confidence that a system is
able to accomplish its intended use, goals, and objectives in an environment like the operational environment.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.71]
3.13
verification
confirmation, through the provision of objective evidence, that specified requirements (3.8) have been
fulfilled
Note 1 to entry: Verification is a set of activities that compares a system or system element against the required
characteristics. This includes, but is not limited to specified requirements, design, descriptions, and the system itself.
The system was built right.
[SOURCE: ISO 9000:2015, 3.8.12, modified — Notes 1 to 3 to entry have been replaced by a new note 1 to entry.]
3.14
work product
artefact produced by a process
EXAMPLE Project (3.6) plan, requirements (3.8) specification, design documentation, source code, test plan, test
meeting minutes, schedules, budgets, and incident reports (3.7).
Note 1 to entry: A subset of the work products can be baselined to be used as the basis of further work, and some will
form the set of project deliverables.
[SOURCE: ISO/IEC 20246:2017, 3.20]
4  Naming, diagramming and definitions conventions
4.1 General
Conventions for naming, diagramming, describing, and defining profiles are defined in
ISO/IEC 29110-2-1:2015.
4.2  Naming, diagramming and definition conventions
The following process structure description and notation are used to describe the processes.
Process name – process identifier, followed by its abbreviation in parenthesis “( )”.
Process purpose – high-level objective of performing the process and the likely outcomes of effective
implementation of the process.
Process outcomes – observable result of the successful achievement of the process purpose. Outcomes are
identified by the abbreviation of the process name, followed by the letter “O” and a consecutive number, for
example, PM.O1, SI.O2.
© ISO/IEC 2025 – All rights reserved
Input work products – Work products that can be used to perform the process and its corresponding source,
which can be another process or an external entity to the project, such as the customer. They are identified
by the abbreviation of the process name.
Output work products – Work products generated by the process and its corresponding destination, which
can be another process or an external entity to the project, such as customer. They are identified by the
abbreviation of the process name.
All work products’ names are initiated with capital letters. Some work products have one or more statuses
attached to the work product name surrounded by square brackets “[ ]” and separated by ”,”. The work
product state may change during the process execution. See Clause 9 for the alphabetical list of the work
products, its descriptions, possible states, and the source of the work product. The source can be another
process or an external entity to the project, such as the customer.
Roles involved – Names and abbreviations of the functions to be performed by project team members.
Several roles may be played by a single person and one role may be assumed by several persons. Roles are
assigned to project participants based on the characteristics of the project. The role list is identified by the
abbreviation of the process name and shown as a two-column table. See Clause 8 for the alphabetical list of
the roles and the description of the required competencies.
Diagram – Graphical representation of the processes. The large round-edged rectangles indicate processes
or activities, and the smaller square-edged rectangles indicate the work products. The directional or
bidirectional thick arrows indicate the major flow of information between processes or activities. The thin
directional or bidirectional arrows indicate the input or output work products. The notation used in the
diagrams does not imply the use of any specific process life cycle.
Activity – A set of cohesive tasks of a process. The task statements in this document are not imperative. A
process activity is the first level of process workflow decomposition and the second one is a task. Activities
are identified by process name abbreviation followed by consecutive number and the activity name.
Activity description – Each activity description is identified by the activity name and the list of related
outcomes surrounded by parenthesis “( )”. For example, PM.01 project planning (PM.O1, PM.O5, PM.O6,
PM.O7) means that the activity PM.01 project planning contributes to the achievement of the listed outcomes:
PM.O1, PM.O5, PM.O6, and PM.O7.
Task description – Each task description begins with an active verb (e.g. assign, test) and is followed by an
object (e.g. review the project plan). To facilitate their implementation, a few tasks are broken down into
elementary tasks. The task description doesn’t impose any technique or method to perform it. The selection
of the techniques or methods is left to the VSE or project team.
Task description tables contain four columns corresponding to:
— Role - the abbreviation of roles involved in the task execution.
— Task - description of the task to be performed. Each task is identified by activity ID and consecutive
number, for example, PM.01.01, PM.01.02. A few numbered items are added to provide additional
information intended to assist the understanding or use of tasks.
— Input work products – work products needed to execute a task.
— Output work products – work products created or modified by the execution of a task.
NOTE 1 A conditional task is executed if its associated work product (e.g. software user documentation) is required
by the customer and listed in the delivery instructions. The conditional task statement is followed with this text:
"Conditional task".
Incorporation to project repository – list of work products to be saved in a project repository. A few work
products (e.g. requirements) are baselined, a change to a baselined work product can be done through an
approved change request.
NOTE 2 Tables used in process description are for presentation purpose only.

© ISO/IEC 2025 – All rights reserved
NOTE 3 The term ‘Entry’ is using a capital ‘E’ to indicate an ISO/IEC 29110 profile (e.g. the Entry profile) while
the term ‘entry’ is used when referring to the act of entering a place or something written or printed in a dictionary,
account book.
NOTE 4 A work product is baselined when it has been approved and uploaded in the repository.
4.3 Abbreviated terms
CUS customer
PM project management
PJM project manager
SI software implementation
WT work team
5 Overview
5.1 General
This document provides project management and software implementation processes which integrate
practices based on the selection of elements from ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15289.
This document is intended to be used by the VSE to establish processes to implement any approach or
methodology, e.g. waterfall, iterative, incremental, evolutionary or agile.
5.2  Entry conditions to use the software Entry profile
To use this document, a VSE should fulfil the following conditions:
— project team, including project manager, is assigned and trained;
— development cycle(s) has/have been documented (e.g. waterfall, iterative, incremental, evolutionary, agile).
5.3  Processes and activities of the software Entry profile
This document provides two processes: a project management (PM) process and a software implementation
(SI) process.
Both processes of the software Entry profile are interrelated (see Figure 2).
The processes illustrated in Figure 2 are intended to be used with any life cycle such as: waterfall, iterative,
incremental, evolutionary or agile.

© ISO/IEC 2025 – All rights reserved
Figure 2 — Processes and activities of the software Entry profile
A customer can be external or internal to an organization (e.g. a client, a project, or department of an
organization that develops products composed of hardware and software components), therefore the
agreement may come from an external or internal customer.
The PM process uses the customer agreement to plan the project. As the project progresses, the PM project
assessment and control tasks compare the project progress against the project plan and actions are taken to
eliminate deviations or incorporate changes to the project plan. The PM project closure activity delivers the
software product, produced by the SI process, and gets the customer’s acceptance to formalise the end of the
project. A project repository is established to save the work products. and to control its versions during the
project.
The execution of the SI process is driven by the project plan. The SI process is initiated with a revision of
the project plan. Project plan will guide the execution of the software requirements analysis, software
components specification, software construction, software integration and test, and software product
assembly activities.
To remove work product’s defects, verification and validation by test tasks are included in the activity’s
workflow.
The customer provides an agreement as an input to project management process and receives a software
product as a result of software implementation process execution (see Figure 2).
6 Project management (PM) process
6.1 PM process purpose
The purpose of the project management process is to establish and carry out in a systematic way the tasks of
the software implementation project, which allows complying with the project’s objectives in the expected
quality, time, and costs.
This document is intended to be used by the VSE to establish processes to implement any development
approach or methodology including, for example, agile, evolutionary, incremental, test-driven development,
based on the VSE or project needs.

© ISO/IEC 2025 – All rights reserved
6.2 PM process outcomes
PM.O1. The project plan for the execution of the project is developed according to the agreement and
reviewed and approved by the customer. The tasks and resources necessary to complete the work are sized
and estimated.
PM.O2. Progress of the project is monitored against the project plan and recorded in the progress status record.
Closure of the project is performed to get the customer acceptance documented in the acceptance record.
PM.O3. The change requests are addressed, evaluated and tracked.
PM.O4. Review meetings with the work team and the customer are held. Agreements are registered and
tracked.
PM.O5. Items of software configuration are identified and controlled.
PM.O6. Software quality assurance is performed to provide assurance that delivered software products
comply with requirements specifications and customer requirements.
NOTE Software quality assurance is implemented through the performance of the verification and validation by
test tasks performed in software implementation processes.
6.3 PM roles involved
The roles involved in the PM process are:
— customer;
— project manager;
— work team.
6.4 PM activities and tasks
6.4.1 Overview of the PM process
Figure 3 shows the flow of information between the project management process activities including the
most relevant work products and their relationship.

© ISO/IEC 2025 – All rights reserved
Figure 3 — Project management process
NOTE 1 The process illustrated in Figure 3 is intended to be used with any life cycle, such as waterfall, iterative,
incremental, evolutionary or agile.
NOTE 2 The agreement is provided by an internal or external customer.
6.4.2 PM activities
6.4.2.1 Overview
The project management process has the following activities:
— PM.01 Project planning
— PM.02 Project plan execution
— PM.03 Project assessment and control
— PM.04 Project closure
6.4.2.2 PM.01 Project planning (contributes to PM.O1, PM.O5, PM.O6)
The project planning activity documents the planning details needed to manage the project. The activity
provides:
— reviewed agreement and the tasks needed to provide the work products of the agreement and to satisfy
other customer requirements;
© ISO/IEC 2025 – All rights reserved
— product quality assurance strategy through verification and validation of work products/deliverables by
testing techniques;
— work team and customer roles and responsibilities;
— project resources and training needs;
— estimates of effort, cost, and schedule;
— project repository to store, handle, and deliver controlled work products and baselined work products.
The task list for PM.01 project planning is given in Table 1.
Table 1 — PM.01 task list
Roles Task list Input Output
Work products Work products
PJM PM.01.01 Review the agreement to select the devel- Agreement [approved] Project plan [initiated]
opment cycle of the project (e.g. waterfall, iterative,
WT
— Development cycle
incremental, evolutionary, agile).
1) The agreement is an entry condition to the use
of this document as listed in Clause 5.
2) The agreement had been approved and
baselined by the management of the VSE before
the start of the project.
3) ISO/IEC 20246 defines different types of work
product reviews.
PJM PM.01.02 Identify the tasks to produce the work Agreement [approved] Project plan [initiated]
products to be delivered to the customer.
WT
1) Tasks of the SI processes, with verification and Project plan [initiated] — Tasks
validation by testing with customer and work
— Delivery instructions
team, are added to assure the quality of work
products.
2) Tasks are identified according to the
development cycle selected.
PJM PM.01.03 Establish the estimated duration to per- Project plan [initiated] Project plan [initiated]
form each task.
WT
— Tasks — Estimated duration
PJM PM.01.04 Identify and document the resources to Agreement [approved, Project plan [initiated]
perform the project in the project plan. baselined]
WT
1) Resources include human, material, equipment — Resources
and tools, standards.
Project plan [initiated]
2) Schedule and dates when resources will be
needed are added to the project plan.
3) A work product is baselined when it has
been approved and uploaded in the project
repository.
PJM PM.01.05 Establish the composition of work team. Project plan [initiated] Project plan [initiated]
WT
1) Roles and responsibilities are assigned — Resources — Composition of work
according to the resources available. team
PJM PM.01.06 Create the schedule of the project tasks. Project plan [initiated] Project plan [initiated]
WT
© ISO/IEC 2025 – All rights reserved
TTabablele 1 1 ((ccoonnttiinnueuedd))
Roles Task list Input Output
Work products Work products
1) Estimated start and completion dates to each — Tasks — Schedule of the
task are assigned. project tasks
— Estimated duration
2) The assigned resources, sequence and
— Composition of work
dependency of the tasks are considered.
team
PJM PM.01.07 Calculate and document the project esti- Project plan [initiated] Project plan [initiated]
mated effort and cost.
— Schedule of the — Estimated effort and
project tasks cost
— Resources
PJM PM.01.08 Generate the project plan. Project plan [initiated] Project plan [initiated]
1) All the elements previously documented are — Tasks
integrated to the project plan.
— Estimated duration
— Resources
— Composition of work
team
— Schedule of the
project task
— Estimated effort and
cost
— Delivery instructions
PJM PM.01.09 Review and obtain approval of the project Project plan [initiated] Project plan [approved]
plan.
PJM PM.01.10 Establish the project repository. Project plan [approved] Project repository [es-
tablished]
WT
6.4.2.3 PM.02 Project plan execution (contributes to PM.O2, PM.O3, PM.O4, PM.O6)
The project plan execution activity implements the documented plan on the project.
The activity provides:
— progress status record of the project updated;
— analysed and evaluated change requests to the plan impacting cost, schedule and technical requirements;
— reviews and agreements with the work team (WT) and customer (CUS).
The task list for PM.02 project plan execution is given in Table 2.

© ISO/IEC 2025 – All rights reserved
Table 2 — PM.02 task list
Roles Task list Input Output
Work products Work products
PJM PM.02.01 Monitor the project plan execution. Project plan [approved] Progress status record
[published]
WT
1) Actual data are recorded in the progress status
record.
2) Actual project record data to monitor includes:
— Tasks
— Results
— Resources and effort
— Cost
— Elapsed time
— Defects
PJM PM.02.02 Conduct review meetings with the custom- Project plan [approved] Meeting record [pub-
er: lished]
CUS
WT Progress status record
— Initiate a change request if needed.
[published] Change request [ap-
— Record agreements between customer and
proved]
PJM and tracked them to closure.

Meeting record [pub-
1) A change request that affects the customer
lished] Project plan [updated]
needs to be negotiated to reach the acceptance
of the customer and PJM.
2) If a change request is initiated, update the
project plan according to the new agreement
between the customer and PJM.
6.4.2.4 PM.03 Project assessment and control (contributes to PM.O2)
The project assessment and control activity evaluates the performance of the plan against documented
commitments.
The activity provides:
— evaluation of actual plan performance and progress against targets;
— tracked change requests;
— documented change requests, appropriate corrective action defined, and changes tracked to closure.
The task list for PM.03 project assessment and control is given in Table 3.

© ISO/IEC 2025 – All rights reserved
Table 3 — PM.03 task list
Roles Task list Input Output
Work products Work products
PJM PM.03.01 Evaluate project progress with respect to Project plan [approved] Progress status record
the project plan, comparing: [evaluated]
WT
— Actual tasks against planned tasks Progress status record
[published]
— Actual resource allocation against planned
resources
— Actual cost against budget estimates
— Actual time aga
...