II.3 — Help Ensure Value-Based Delivery

II.3 · Last updated: 24/08/2026

Where this task sits

II.3 — Help Ensure Value-Based Delivery is the third task in the Process domain of the 2026 ECO. The domain carries 41% of the exam.

It has six enablers:

• Identify value components with key stakeholders
• Prioritize work based on value and stakeholder feedback
• Assess opportunities to deliver value incrementally
• Examine the business value throughout the project
• Verify a measurement system is in place to track benefits
• Evaluate delivery options to demonstrate value

Not one of the six says "produce value." All of them are about defining, measuring, prioritizing, and demonstrating it. That distinction decides answers on the exam.

🔴 Do not trust the number

II.3 is one of the two-way number traps in Domain II:

• In 2021, II.3 was assess and manage risks. In 2026 that topic is III.5 — Plan and Manage Risk, and it now lives in a different domain (Business Environment).
• In 2026, II.3 is value-based delivery. In 2021 this topic was II.1 (execute the project with the urgency required to deliver business value).

So an older question tagged "II.3" is most likely about risk. And risk did not only change number, it changed domain — if you build your study plan around domain weights, that second shift matters even more.

The old number of this page's topic, II.1, now belongs to II.1 — Develop an Integrated Project Management Plan and Plan Delivery. For the general shape of the trap, see what changed in the 2026 PMP exam.

What value is

PMBOK® 8 does not treat value as a by-product; it treats it as the measure of the project.

Under the Focus on Value principle, The Standard for Project Management defines it: value, also referred to as project value, is the ultimate success indicator and driver of projects. Value can be described and assessed using either measurable metrics, such as return on investment, or qualitative observations such as testimonials and societal benefits. Value represents the overall worth of the project outcomes and the net benefits to stakeholders, encompassing the deliverables and their related outcomes, particularly from the perspective of key stakeholders (PMBOK® 8, Standard p.40).

The Guide says the same thing more briefly: the fundamental objective of any project is to create positive value that justifies the investment and effort undertaken (PMBOK® 8, Guide p.10).

Translated for the exam: "the project finished on time and on budget" is not a statement of success on its own. The measure is value.

Value can be intangible — but never unmeasured

This is the most misread part of the task.

The book splits business value into two columns. The tangible side covers monetary assets, profitability, market share, and infrastructure capabilities. The intangible side covers productivity, environmental improvements, reputation, brand recognition, public benefit, acquired knowledge, compliance, and employee well-being (PMBOK® 8, Standard p.14).

Being intangible does not make it unmeasurable — the definition itself counts qualitative observations as a measure of value (PMBOK® 8, Standard p.40).

That is why the ECO carries a separate enabler: "verify a measurement system is in place." On the exam, the option saying "there is no number for this benefit, let us disregard it" runs directly against that enabler.

Who measures the benefits, and with what

The PMBOK counterpart of the ECO's measurement enabler is a specific document.

The benefits management plan is the documented explanation defining the processes for creating, maximizing, and sustaining the benefits provided by a program or project. It describes how and when the project's benefits will be delivered and the mechanisms that should be in place to measure those benefits (PMBOK® 8, Guide p.115).

This document arrives from outside the project. Business documents — the business case and the benefits management plan — are considered inputs to the project, and the sponsor is expected to provide the minimum information necessary for a project manager to start project activities (PMBOK® 8, Standard p.70). Both appear among the inputs to the Initiate Project or Phase process (PMBOK® 8, Guide p.17).

The practical consequence: the ECO does not say "build the measurement system," it says "verify it exists." If it exists you verify it; if it does not, you raise the gap — but this task is not asking you to invent it from scratch.

Incremental delivery and the minimum viable product

The enabler "assess opportunities to deliver value incrementally" has a precise counterpart in the book.

A minimum viable product (MVP) is a concept used to define the scope of the first release of a solution to customers by identifying the fewest number of features or requirements that would deliver value (PMBOK® 8, Guide p.269).

Two constraints in that definition have to be read together: fewest and would deliver value. A minimal release that delivers no value is not an MVP.

The book's example shows the mechanism: when limited information is available about customer preferences, adopting an iterative approach with a clear MVP, created with the minimum features collected in a backlog, could provide rapid feedback to the team and better support adaptation to changes (PMBOK® 8, Guide p.45).

That is where the second condition in "prioritize work based on value and stakeholder feedback" comes from: the point of incremental delivery is not only early delivery but early learning.

The value-focused approach versus the conventional one

The book places the two side by side, and the difference runs in a surprising direction.

Consider a company rolling out a new internal technology system. A conventional approach would focus on choosing the product with the most features for the price and then customizing it to meet all requested stakeholder requirements. A value-focused approach aligns the project with business outcomes like maximizing usage and adoption (PMBOK® 8, Standard p.42).

The result can run the other way: by reducing features and customizations, the more simplified solution might better match the culture and increase overall usage and satisfaction (PMBOK® 8, Standard p.42).

Translated for the exam: adding value is not always adding features. It is the same logic behind the book's rejection of gold plating and scope creep — see II.2 — Develop and Manage Project Scope.

Value does not live in one task

Finally, the boundaries of this task need drawing correctly: value may be one task in Domain II, but PMBOK does not confine it to one place.

The book says the Focus on Value principle is primarily addressed within the Governance, Scope, Risk, Schedule, Finance, and Stakeholders performance domains, ensuring the deliverables genuinely help drive realization of the project's target business objectives (PMBOK® 8, Standard p.38).

Six domains — nearly the whole project. The ECO's "examine the business value throughout the project" enabler reflects that spread: value assessment is not work you finish at the start.

Its concrete counterpart on the scope side is the value breakdown structure (VBS): a hierarchy that records each deliverable's expected value as a number or a percentage and makes it the basis for prioritization (PMBOK® 8, Guide p.38). Both the "identify value components" and "prioritize work based on value" enablers meet there.

About the citations

The page numbers above refer to the PMBOK® Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked as "ECO."

⚠️ PMBOK® 8 contains two separate books in one volume, and their page numbering is independent:

• The Standard for Project Management — cited as Standard p.X
• A Guide to the Project Management Body of Knowledge — cited as Guide p.X

This page cites both books; which number belongs to which book is stated in every citation. The numbers are the books' printed page numbers.

This page explains the book; it does not replace it.