ISO 21502: ISO 21502 – Tutorial (about 60 minutes)

ISO 21502 is the international guidance standard on project management, published by the International Organization for Standardization (ISO). It describes, in a method-neutral way, the practices that tend to make projects succeed: how a project is justified, started, directed, controlled, delivered, closed and followed up until its benefits appear. Project managers, sponsors, PMO staff, procurement teams and auditors use it as a common reference that sits above specific methods such as PRINCE2, Scrum or a company's own playbook. After this tutorial you will be able to explain its structure, map your own project approach to it, and use it to spot gaps in how your organisation runs projects.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO 21502:2020, Project, programme and portfolio management – Guidance on project management, first edition, published in December 2020 by ISO technical committee ISO/TC 258. It replaced the project management guidance previously given in ISO 21500:2012; the number 21500 now belongs to a separate document on context and concepts (ISO 21500:2021). ISO 21502 has been through its five-yearly systematic review and was not simply confirmed: the ISO/TC 258 catalogue shows the 2020 edition at stage 90.92, "to be revised", and a second edition is under development as ISO/CD 21502 (committee draft stage). At its September 2026 plenary the committee approved a limited revision that will resolve review comments, update outdated references and refresh the context diagram and its explanation. Until the new edition is published, ISO 21502:2020 is the valid edition, and that is what this tutorial teaches. National standards bodies also publish adoptions, for example AS ISO 21502:2022 in Australia. Verified 2026-10-29 against the ISO/TC 258 committee pages and catalogue.

Who it is for: project managers and team leads who want a vendor-neutral foundation, sponsors and steering-group members who need to understand their own responsibilities, PMO and governance staff who design project methods, and quality, audit or procurement people who are asked whether an organisation or a supplier "follows ISO 21502".

Prerequisites: none. Some experience of working on a project helps, but every term is explained when it first appears.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then spend the remaining time on the reflection questions before you attempt the 25-question knowledge check.

Learning objectives:

You will be able to explain why ISO 21502 exists, what it covers and what it deliberately leaves out.
You will be able to use its key vocabulary correctly, including output, outcome, benefit, sponsoring organisation, project sponsor and project assurance.
You will be able to describe the structure of the standard: its concepts, prerequisites, eight integrated practices and seventeen management practices.
You will be able to describe who oversees, directs and manages a project, and how decision points connect the phases of a project life cycle.
You will be able to explain how alignment with ISO 21502 can be assessed, and why organisations cannot obtain accredited certification to it.
You will be able to apply the guidance to a realistic project, from the first idea to the review of benefits after closure.
You will be able to relate ISO 21502 to the rest of the ISO 21500 family, to PMI's PMBOK Guide and to PRINCE2.

Lesson 1 – Origins, purpose and scope

Why an international standard for project management?

Almost every organisation delivers change through projects: a new product, a building, a software platform, a merger, a regulatory change. Over the decades, several professional bodies produced their own descriptions of good project management. The Project Management Institute (PMI) in the United States publishes the PMBOK Guide; the UK government created PRINCE2, now owned by PeopleCert; the International Project Management Association (IPMA) publishes a competence baseline; and many countries had national standards. Each of these has its own vocabulary, its own structure and its own followers. When a German engineering firm works with an Indian software supplier for a client in Brazil, the three parties may use different words for the same thing and expect different documents at different moments.

An international standard gives everyone a neutral reference point. It does not replace the methods people already use; instead, it describes what good project management should include, in terms that any method can be mapped to. That is the role of ISO 21502. A client can ask a supplier to show how its method covers the practices in the standard; a PMO can check that its own playbook has no blind spots; a training provider can align its material with an agreed international view.

From ISO 21500:2012 to ISO 21502:2020

ISO published its first project management guidance standard, ISO 21500, in 2012. It was organised around process groups and subject groups, a structure that looked familiar to readers of earlier PMBOK editions. As ISO/TC 258, the technical committee for project, programme and portfolio management, added separate standards for programmes, portfolios and governance, the committee decided to reorganise the family. The general context and concepts shared by projects, programmes and portfolios moved into a new ISO 21500 (published in 2021), and the guidance specific to projects was rewritten as ISO 21502, published at the end of 2020. The number 21501 was skipped because it was already used by an unrelated standard on particle size measurement.

The rewrite was not a renaming exercise. ISO 21502 moved away from a process catalogue towards a narrative description of practices. It puts much more weight on outcomes and benefits rather than just deliverables, on the organisational context around a project, on roles such as the sponsoring organisation and project assurance, and on tailoring the approach to the project, including predictive, iterative, agile and hybrid ways of producing the deliverables.

Scope: what the standard covers and what it does not

ISO 21502 is meant for any type of organisation, whether public, private or not-for-profit, and for any type of project, whatever its purpose, size, complexity, duration, cost or delivery approach. It is written as guidance: it uses "should" rather than "shall", and it describes practices that are generally considered to work well rather than mandatory requirements.

Three boundaries are worth remembering from the start:

It is about projects. It does not give guidance on managing programmes or portfolios; those topics belong to ISO 21503 and ISO 21504.
It addresses general management topics, such as finance or human resources, only where they touch project management.
It does not describe how to produce the deliverables themselves. Engineering a bridge, writing code or designing a training course are specialist activities; ISO 21502 covers how the project around that work is managed.

What "guidance" means in practice

Because the standard is guidance, there is no single correct way to "implement" it. An organisation uses it as a benchmark: it compares its own methods and habits with the practices described, decides which gaps matter, and tailors its approach. This flexibility is a strength, because a two-month marketing project and a ten-year infrastructure project need very different levels of formality. It is also a risk, because an organisation can claim alignment loosely without changing anything real. Later lessons show how to avoid that trap.

Lesson 2 – Key concepts and vocabulary

ISO 21502 relies on a precise vocabulary, and the vocabulary for the whole family is collected in ISO 21506. The descriptions below are explanations in plain words, not the official definitions.

Project – a temporary endeavour set up to achieve one or more defined objectives, with a start and an end, producing something unique rather than repeating routine operations.
Project management – the coordinated application of practices, methods, tools and competences to a project so that it achieves its objectives and enables its intended benefits.
Deliverable – a single, verifiable item that the project must produce, such as a design document, a trained group of users or a tested software release.
Output – the tangible or intangible result of the project as a whole, made up of its deliverables, for example a working warehouse system.
Outcome – the change that happens when the output is used, for example faster order picking because staff now use the new system.
Benefit – a measurable advantage or value that arises from an outcome and that someone in the organisation cares about, such as lower operating cost or higher customer satisfaction.
Sponsoring organisation – the part of the organisation (or the external body) that commissions the project, owns its justification and oversees it, often through a portfolio or programme function.
Project sponsor – the individual accountable for the project's success who directs it, makes key decisions, and represents the sponsoring organisation towards the project.
Project board – an optional decision-making group, sometimes called a steering committee, that supports or shares the sponsor's directing role, often including user and supplier representatives.
Project manager – the person who manages the project day to day within the authority and constraints set by the sponsor.
Project assurance – independent checking, on behalf of the sponsor or sponsoring organisation, that the project is being run properly and that its reports can be trusted.
Work package – a defined piece of project work assigned to a work package leader or team, with agreed scope, schedule and acceptance criteria.
Project life cycle – the sequence of phases a project passes through from start to finish, separated by decision points.
Decision point (gate) – a planned moment at which the sponsor or board reviews progress and the justification, and decides whether to continue, change direction or stop.
Baseline – an approved version of a plan (scope, schedule, cost) against which actual performance is measured and changes are controlled.
Tailoring – adapting practices, documents and level of formality to the needs, size, risk and context of a specific project.

From deliverables to benefits

The chain from deliverable to benefit is one of the most important ideas in ISO 21502. A project can deliver everything it promised on time and on budget, yet still fail if nobody uses the output or if using it does not create the expected change. The standard therefore asks project managers and sponsors to keep the whole chain in view: the project produces deliverables that together form its output; the organisation uses the output, which creates outcomes; and outcomes, when measured, show whether benefits are being realised. Benefits often appear after the project has closed, so responsibility for tracking them usually passes to the business owner and the sponsoring organisation.

Figure 1 – The value chain in ISO 21502: deliverables form an output, using the output creates outcomes, and outcomes yield benefits that serve strategy.

Context and environment

The standard stresses that a project never exists in isolation. The organisational context is the mix of internal and external factors, together with the organisation's strategy and objectives, that influences how a project creates value. The project environment includes the external environment (markets, regulation, technology, society), the organisational environment (culture, structures, systems, other projects competing for the same people) and the governance environment (policies, decision rights and reporting lines). A project manager who understands these layers can anticipate constraints and stakeholder reactions instead of being surprised by them.

Constraints and competences

Every project works under constraints, typically time, cost, scope, quality, resources, risk appetite and regulatory obligations. ISO 21502 treats balancing these constraints as a core management task rather than a failure: changing one usually affects the others. The standard also expects the people involved to have suitable competences, grouped broadly into technical project management skills, behavioural skills (leadership, communication, negotiation) and business or contextual skills (understanding the organisation and its environment). The IPMA competence baseline describes a similar split, and the two are often used together.

Lesson 3 – Structure of the standard

The clauses at a glance

ISO 21502:2020 has seven numbered clauses. The first three are the usual ISO opening: scope, normative references, and terms and definitions. The substance sits in clauses 4 to 7:

Clause 4 – Project management concepts – the ideas from Lesson 2 and Lesson 4: what project management is, the organisational context and project environment, project governance (including the business case), project organisation and roles, competences, the project life cycle and constraints.
Clause 5 – Prerequisites for formalizing project management – what an organisation should think about when it formalises project management: considerations for implementing it, continually improving the project management environment, and aligning project management with the organisation's other processes and systems.
Clause 6 – Integrated project management practices – eight practices that follow the life of a project and show who does what, from the first idea to the period after closure.
Clause 7 – Management practices for a project – seventeen subject-based practices, such as planning, risk or procurement, that are used throughout the life cycle.

Figure 2 – How ISO 21502:2020 is organised: concepts and prerequisites set the scene, then two complementary sets of practices describe what to do.

The eight integrated practices

The integrated practices answer the question "what has to happen, when, and who is responsible?" They are called integrated because each one draws on several of the subject-based management practices at once. In the order a project meets them, they are:

Pre-project activities – identifying a need or opportunity, outlining a justification (often a business case), appointing a sponsor and deciding whether to start a project at all.
Overseeing a project – the sponsoring organisation keeps an eye on the project through key decisions, periodic reports, audits and assurance reviews, and intervenes when needed.
Directing a project – the sponsor (alone or with a project board) gives direction, makes decisions at decision points, handles escalations and keeps the project aligned with its justification.
Initiating a project – setting up the project properly: confirming objectives and scope, planning the approach, establishing the organisation and controls, and creating baselines.
Controlling a project – the project manager monitors performance against the baselines, forecasts, takes corrective action, manages changes and prepares the information needed at decision points.
Managing delivery – work package leaders and teams produce the deliverables according to agreed plans, using whatever technical method suits the work.
Closing or terminating a project – handing over the output, confirming acceptance, releasing resources, closing contracts and capturing lessons; this also covers stopping a project early when its justification no longer holds.
Post-project activities – after closure, the sponsoring organisation or business owner checks whether outcomes and benefits are being realised and whether lessons are being applied.

Two of these practices sit before and after the project itself. This is a deliberate message: good project management starts before anyone writes a project plan and does not end when the team disbands. Overseeing and directing run across the whole life of the project, while initiating, controlling, managing delivery and closing are the practices most people think of as "project management".

The seventeen management practices

The management practices answer the question "what topics must be managed well throughout the project?" They are used repeatedly and in combination by the integrated practices. In the order the standard presents them, they cover:

Planning – developing and maintaining an integrated plan that ties the other topics together.
Benefits management – identifying, planning, tracking and enabling the benefits the project is meant to make possible.
Scope management – defining what is in and out of the project and keeping that definition under control.
Resource management – obtaining, assigning and releasing people, equipment, facilities and materials.
Schedule management – sequencing activities, estimating durations and keeping the timetable realistic.
Cost management – estimating, budgeting, tracking and forecasting costs.
Risk management – identifying, assessing and treating uncertainties, both threats and opportunities.
Issues management – recording and resolving problems that have already happened and affect the project.
Change control – assessing, approving or rejecting and then implementing changes to baselines.
Quality management – planning, assuring and controlling the quality of deliverables and of project management itself.
Stakeholder engagement – identifying the people and groups affected and involving them appropriately.
Communication management – planning and delivering the right information to the right audiences.
Organisational change and social impacts management – helping people and the organisation adopt the output, and considering effects on society and the environment.
Reporting – giving decision-makers timely, reliable information on status and forecasts.
Information and documentation management – storing, versioning and protecting project records.
Procurement – acquiring goods and services from external suppliers and managing the contracts.
Lessons learned – capturing, sharing and applying experience during and after the project.

Readers who know ISO 21500:2012 will recognise the classic subjects such as scope, schedule, cost, risk and quality. The newer emphasis lies in benefits, issues, change control, organisational change and social impacts, reporting, information management and lessons learned. Notice also that ISO 21502 does not tell you which documents to produce or which technique to use for each topic. A Gantt chart, a product backlog and a Kanban board can all satisfy schedule management if they suit the project.

Reading the two sets of practices together

A useful mental model is a grid. The integrated practices form the rows, ordered along time; the management practices form the columns, which are topics. For example, risk management appears in pre-project activities (initial risk view for the justification), in initiating (risk plan and register), in controlling (regular review and treatment) and in closing (handing open risks to operations). Thinking in this grid helps you check whether every topic is handled at every stage where it matters.

Lesson 4 – How it works in practice

The project life cycle and decision points

ISO 21502 does not prescribe a fixed set of phases. It expects each project to have a life cycle made up of phases appropriate to the work, with decision points between them. A construction project might use feasibility, design, procurement, construction and commissioning; a software product might use discovery, a series of releases and a transition to live service. What matters is that the sponsor has planned moments at which to look at the evidence and decide whether to continue.

The standard recognises that the way deliverables are produced affects the life cycle. Predictive delivery plans most of the work up front; iterative, incremental and agile delivery plans in short cycles and refines the scope as the team learns. Many real projects are hybrid: they keep governance decision points at a few major moments but let teams work in sprints in between. ISO 21502 is compatible with all of these, provided the governance and control practices are still present.

Figure 3 – A tailored project life cycle in the spirit of ISO 21502: phases separated by decision points, with the option to stop, and a benefits review after closure.

Roles and who does what

One strength of ISO 21502 is the clear split between three levels of responsibility. Mixing them up is a common source of trouble, such as project managers being asked to make strategic choices or sponsors micromanaging tasks.

Overseeing sits with the sponsoring organisation, frequently represented by a portfolio board, a programme manager or an executive committee. It asks whether the project is still the right investment.
Directing sits with the project sponsor, possibly supported by a project board. The sponsor makes decisions at decision points, sets tolerances, resolves escalations and owns the justification.
Managing sits with the project manager, who initiates, controls and closes the project, and with work package leaders and team members, who manage delivery.

Alongside these, project assurance provides independent checks for the sponsor, and a project support function or PMO may provide planning, administration, tools and expertise. In small projects one person may hold several roles; the standard asks that responsibilities remain clear even when roles are combined. A sponsor who is also the project manager, for instance, loses independent challenge, so extra assurance may be needed.

Figure 4 – The governance levels behind the integrated practices: overseeing, directing, managing and delivering, with assurance and support alongside; reports and escalations flow back up the same chain.

Authority, tolerances and escalation

Clear levels only work if everyone knows how much freedom they have. A practical way to express this is through tolerances: for example, the project manager may accept a schedule slip of up to two weeks or a cost overrun of up to five per cent without asking anyone, but anything beyond that must be escalated to the sponsor. The sponsor in turn may have tolerances set by the sponsoring organisation. ISO 21502 does not dictate figures; it expects the boundaries to be agreed and documented during initiation and used consistently in controlling and reporting.

Typical artefacts

The standard is not a document checklist, but practitioners usually produce a recognisable set of artefacts to support the practices:

A justification or business case created before the project and updated at each decision point.
A project charter or initiation document that records objectives, scope, organisation, approach and tolerances.
An integrated plan with scope, schedule, cost and resource baselines, sized to the project.
Registers for risks, issues, changes, stakeholders and lessons learned.
A benefits plan or profile that defines each benefit, how it will be measured and who owns it.
Regular progress reports and decision-point reports for the sponsor and board.
Acceptance records and a closure report, including handover of open risks and actions.

Implementing the guidance in an organisation

When an organisation decides to use ISO 21502 as its reference, it usually proceeds in a sequence of steps, reflecting the prerequisites in clause 5:

Clarify why it wants to formalise project management, for example repeated overruns, unclear accountability or a client requirement.
Assess current practice against the integrated and management practices, using interviews, document samples and project records.
Design or update its project management approach: life cycle options, role descriptions, decision rights, templates and tailoring rules.
Build competence through training, coaching and mentoring for sponsors as well as project managers.
Pilot the approach on a few projects of different sizes, collect feedback and refine.
Roll it out, embed it in governance (for example, portfolio decisions require a business case and decision-point reviews), and measure use.
Review and improve the approach periodically, feeding in lessons learned.

Tailoring in practice

Tailoring is where many organisations either succeed or fail. A good tailoring rule set defines a few project categories by size, risk and complexity, and states the minimum practices and artefacts for each. A small internal project might combine charter and plan in two pages, use a single decision point after initiation, and report monthly by email. A large regulated project might have formal assurance, several boards and detailed baselines. The point is that every practice is still considered; some are simply handled lightly.

Lesson 5 – Assessment, certification and compliance

No accredited certification of organisations

ISO 21502 is a guidance standard. It contains recommendations, not auditable requirements, so there is no accredited third-party certification scheme for organisations, comparable to ISO 9001 or ISO/IEC 27001 certification. An organisation cannot legitimately claim to be "certified to ISO 21502". It can say that its project management approach is aligned with, based on or consistent with ISO 21502, and it should be able to show evidence for that claim.

It is worth knowing that ISO/TC 258 has other work in progress, including a document on organisational requirements (ISO 21514, at committee draft stage when this tutorial was verified). How that work develops is not settled, so do not assume it will change the status of ISO 21502, which remains guidance.

Certificates for individuals

Some training and certification bodies offer personal courses and exams based on ISO 21502. For example, PECB offers an ISO 21502 Foundation course and an ISO 21502 Lead Project Manager certification. These credentials are issued by the provider, not by ISO, and they show that a person has learned the content of the standard. They do not certify the person's employer, and they are distinct from method-specific credentials such as PMI's PMP or PeopleCert's PRINCE2 certifications.

How alignment is assessed in practice

Even without certification, organisations regularly assess how well they follow the guidance. Common approaches include:

Gap assessment – a structured comparison of the organisation's method and actual practice with each integrated and management practice, resulting in a list of gaps ranked by impact.
Project health checks and assurance reviews – independent reviews of a live project, often just before a decision point, checking whether justification, plans, risks and controls are sound.
Internal audit – auditors use ISO 21502 as criteria for "good practice" when they audit project governance, often alongside internal policies.
Maturity assessment – maturity models such as P3M3 rate the organisation's capability across many projects; ISO 21502 can provide the content reference for what "good" looks like.
Supplier evaluation – a client may ask bidders to map their project method to ISO 21502 and to provide sample artefacts as evidence.

What good evidence looks like

Assessors look for evidence that practices are actually performed, not just described. Useful evidence includes approved business cases that were updated over time, decision-point records showing real choices (including projects that were stopped), risk and issue registers with recent dates and owners, change logs that link to updated baselines, closure reports and post-project benefit reviews. A method manual on the intranet without matching records from real projects is weak evidence. Interviews with sponsors are also revealing: if sponsors cannot describe their own decision rights, directing is probably not working as intended.

Contracts and regulation

Some public bodies and large clients refer to ISO 21502 in tenders, frameworks or internal policies, typically as a reference for how suppliers should manage projects. Where a contract does this, the contract wording defines the obligation, not the standard itself, because the standard uses "should". Teams should therefore read the contract carefully and agree with the client which practices and evidence are expected.

Lesson 6 – Worked example

This example follows a fictional mid-sized logistics company, NorthBay Logistics, through one project. It shows how the integrated practices unfold over time and how the management practices are woven into them.

Step 1 – Pre-project: is there a case?

NorthBay's operations director notices that order picking errors in its three warehouses are rising and that the old warehouse system cannot support same-day delivery, which competitors now offer. She raises the idea at the quarterly portfolio meeting. The portfolio board, acting as the sponsoring organisation, asks for an outline business case. A small team estimates costs, identifies two realistic options (upgrading the old system or adopting a cloud warehouse system) and describes the expected benefits: fewer picking errors, faster dispatch and the ability to offer same-day delivery in two cities. The board appoints the operations director as project sponsor and approves funding for initiation only. This is the first decision point.

Step 2 – Directing and initiating

The sponsor forms a project board with the head of IT (supplier side), a warehouse manager (user side) and a finance representative. She appoints an experienced project manager, Ravi, and asks internal audit to provide project assurance. During initiation Ravi and the team:

confirm objectives, scope and exclusions (the transport planning system is out of scope);
choose a hybrid life cycle: a selection and contracting phase, then three releases, one per warehouse, built and tested in two-week sprints;
create schedule and cost baselines for the first release and indicative figures for the rest;
agree tolerances: Ravi can absorb up to ten working days of slip and up to four per cent cost variance per release before escalating;
set up registers for risks, issues, changes, stakeholders and lessons;
write a benefits plan with a baseline error rate, target values and named benefit owners in each warehouse;
plan procurement of the software service through a competitive tender.

At the second decision point the board reviews this initiation work and the refined business case, and authorises the selection and contracting phase.

Step 3 – Controlling and managing delivery

After a supplier is chosen, delivery begins. Work packages are assigned to an integration team, a data migration team and a training team, each with a leader. Ravi holds weekly control meetings, updates forecasts and sends a short monthly report to the board. Three typical events show the management practices in action:

A risk becomes an issue. The risk register had flagged that product master data might be poor. During the first data load, twelve per cent of records fail validation. Ravi logs an issue, the data team adds a clean-up work package, and the schedule slips by eight days, within tolerance.
A change request. The warehouse manager asks to add handheld scanner support for returns, which was not in scope. Ravi analyses the impact on cost, schedule and benefits, and because it exceeds his tolerance he takes it to the board. The board approves it for release two only, and the baselines are updated through change control.
Stakeholder and organisational change. Night-shift staff resist the new system, fearing job losses. The sponsor and the warehouse manager hold briefings explaining that the aim is accuracy, not headcount reduction, and the training team adds hands-on sessions during night shifts.

Meanwhile, the portfolio board oversees the project through quarterly reviews, and internal audit performs an assurance review before release two, checking that registers are current and that the reported status matches reality.

Step 4 – Decision points along the way

After each release, the board holds a decision point. After release one, it reviews early results: picking errors in the first warehouse have dropped noticeably. It confirms that the business case remains valid and authorises release two. Had the supplier's service proved unreliable, the board could have decided to pause or terminate the project, which ISO 21502 treats as a legitimate and sometimes wise outcome rather than a failure of management.

Step 5 – Closing

When all three warehouses are live, Ravi leads closure. The operations team formally accepts the system; open risks, such as a planned upgrade of the scanners, are handed to the IT service owner; contracts move from project to service management; team members are released; and a lessons-learned session records what to repeat (early data profiling) and what to avoid (starting training too late on night shifts). The board confirms closure, and the lessons are sent to the PMO, which updates its tailoring guidance.

Step 6 – Post-project: were the benefits realised?

Six months later, the portfolio board receives the benefits review from the benefit owners. Picking errors have fallen close to target in two warehouses and partly in the third, where a layout problem remains. Same-day delivery is live in one city and planned for the second. The board assigns an improvement action for the third warehouse and records the actual benefits in its portfolio data, which will improve future business case estimates. The project ended months earlier, but the value chain from Figure 1 is only now fully visible.

What the example shows

Every integrated practice appeared: pre-project work, overseeing by the portfolio board, directing by the sponsor and board, initiating, controlling, managing delivery, closing and post-project review. Many management practices appeared too, not as separate procedures but as part of everyday decisions. The hybrid life cycle shows that agile delivery fits comfortably inside the governance that ISO 21502 describes.

Lesson 7 – Relationship to other standards and frameworks

The ISO 21500 family

ISO 21502 is one member of a family of standards developed by ISO/TC 258. ISO 21500:2021 provides the shared context and concepts for projects, programmes and portfolios and explains how they relate to an organisation's strategy and operations. ISO 21503 gives guidance on programme management, ISO 21504 on portfolio management, ISO 21505 on governance, and ISO 21506 collects the vocabulary. Further documents cover specific techniques, such as work breakdown structures (ISO 21511), earned value management (ISO 21508 and ISO 21512) and post-project and post-programme evaluation (ISO 21513). A useful way to remember the arrangement is that ISO 21500 is the umbrella, ISO 21502, 21503 and 21504 describe the three management levels, and the rest provide governance, vocabulary and techniques.

Comparison with other well-known references

Reference	Owner	Nature	Relationship to ISO 21502
ISO 21500:2021	ISO/TC 258	Context and concepts for projects, programmes and portfolios	The umbrella document; ISO 21502 applies its concepts to individual projects
ISO 21503 and ISO 21504	ISO/TC 258	Guidance on programme and on portfolio management	Cover the levels above a project; the overseeing practice in ISO 21502 is often performed by these functions
ISO 21505	ISO/TC 258	Guidance on governance of projects, programmes and portfolios	Describes the governing framework within which directing and overseeing take place
PMBOK Guide and The Standard for Project Management	Project Management Institute (PMI)	Widely used body of knowledge with principles and performance domains; closely linked to PMI's PMP credential	Covers similar ground in more depth and with different terms; teams often map PMI practices to ISO 21502 for neutral alignment
PRINCE2	PeopleCert (formerly AXELOS)	A prescriptive, process-based method with defined roles, themes and management products	A method that can implement the ISO 21502 guidance; its distinction between directing, managing and delivering is close to ISO 21502's levels
IPMA Individual Competence Baseline (ICB4)	International Project Management Association	Competence framework for individuals	Complements ISO 21502 by describing the competences people need to perform the practices
ISO 31000	ISO/TC 262	Guidelines for risk management in any organisation	Provides deeper guidance that can support the risk management practice in a project

Choosing and combining

ISO 21502 is not a competitor to PMBOK or PRINCE2 in the sense of "pick one". It is a neutral reference that a method should be able to map to. Typical combinations are: an organisation adopts PRINCE2 as its method and checks it against ISO 21502 for completeness, especially for benefits and post-project activities; a software company uses Scrum for delivery and adds the governance practices of ISO 21502 above it; or a public body writes its own method based on ISO 21502 and uses PMI or IPMA credentials for staff development. In all cases, the standard's value comes from its vocabulary and its clear picture of responsibilities, which make cooperation across organisations easier.

Agile frameworks

Agile frameworks such as Scrum focus on how a team produces value in short cycles. They say little about business cases, sponsors, portfolio oversight or closure. ISO 21502's managing delivery practice can be carried out with Scrum, while the other integrated practices provide the surrounding governance. The danger is to treat agile as a reason to skip justification, benefits management or decision points; the opposite danger is to load agile teams with heavy predictive documentation. Tailoring, guided by the standard, helps find the balance.

Common pitfalls and best practices

Common pitfalls

Claiming certification. Saying the company is "ISO 21502 certified" misrepresents a guidance standard and can damage credibility with informed clients.
Treating it as a document checklist. Producing every possible template without tailoring creates bureaucracy and frustrates teams, while the important decisions still go unmade.
Stopping at deliverables. Measuring success only by time, cost and scope ignores outcomes and benefits, so projects that deliver unused outputs are reported as successes.
Absent or overloaded sponsors. A sponsor who never attends decision points, or who also manages the detail, breaks the separation between directing and managing.
Decision points that never stop anything. If every gate review is a formality, the organisation loses its main mechanism for protecting investment.
No owner after closure. When nobody is responsible for benefits after the project ends, post-project activities quietly disappear.
Ignoring the people side. Neglecting organisational change, stakeholder engagement and social impacts leads to resistance and low adoption even when the technology works.

Best practices

Start with a gap assessment. Compare your real practice, not your manual, with the integrated and management practices, and fix the gaps that hurt most first.
Define decision rights and tolerances early. Record during initiation what the project manager, sponsor and sponsoring organisation may decide, and use those limits consistently.
Keep the business case alive. Update the justification at each decision point and be willing to stop a project that no longer makes sense.
Plan benefits with named owners. Define each benefit with a baseline, a measure, a target date and a business owner who will report on it after closure.
Tailor by category. Provide light, standard and heavy versions of your approach so that every practice is considered but effort matches risk and size.
Use independent assurance. Plan reviews before major decision points, especially when roles are combined or the project is high risk.
Close the learning loop. Turn lessons learned into changes in templates, training and tailoring rules, and check whether later projects apply them.

Summary and key takeaways

ISO 21502:2020 is ISO's guidance standard on project management; it replaced the project guidance of ISO 21500:2012 and is now under a limited revision, with a committee draft of the second edition in development.
It applies to any organisation and any project, whatever the delivery approach, and it describes good practice in "should" language rather than requirements.
Its core message is that projects exist to create value: deliverables form an output, the output enables outcomes, and outcomes produce benefits that must be tracked after closure.
Clause 6 describes eight integrated practices along the life of a project, from pre-project activities to post-project benefit review, and clause 7 describes seventeen subject-based management practices.
Responsibilities are split into overseeing (sponsoring organisation), directing (sponsor and board) and managing (project manager and work package leaders), supported by assurance and project support.
There is no accredited certification of organisations against ISO 21502; alignment is shown through evidence, gap assessments, assurance reviews and audits, while individuals can take provider-issued courses and exams.
ISO 21502 complements rather than replaces methods such as PRINCE2, PMI's guidance and agile frameworks, and it sits within the wider ISO 21500 family alongside programme, portfolio and governance guidance.

Reflection questions

Think of a recent project you know well. Which of the eight integrated practices were performed clearly, which were weak, and what was the effect on the result?
For one benefit your organisation expects from a current project, describe the chain from deliverable to benefit, the measure you would use, and who should own it after closure.
How are decision rights and tolerances defined for project managers and sponsors in your organisation, and what would you change after reading this tutorial?
If a client asked you to show that your project method is aligned with ISO 21502, which evidence from real projects would you present, and where do you expect gaps?
How would you tailor your approach for a small, low-risk internal project compared with a large, multi-supplier project, while still considering every management practice?