When PMI describes what changed on the exam that launched on 9 July 2026, the same three words keep appearing: outcomes, value, and business impact. On its own that reads like marketing language, and it is easy to skim past. It is not marketing language. There is a specific task in the Examination Content Outline that carries it, with six enablers of its own, and most study plans do not have a session allocated to it.
The task is "Help ensure value-based delivery," and it sits in the Process domain. If your prep material predates the current outline, it probably folded this content into agile topics or treated it as background. That is no longer a safe assumption, because the enablers describe decisions a project manager makes, and decisions are what scenario questions test.
Where the task sits in the outline
The outline PMI published for the current exam splits the content into three domains: People at 33%, Process at 41%, and Business Environment at 26%. The exam itself is 180 questions — 170 scored and 10 unscored pretest items — over 240 minutes.
Value-based delivery is Task 3 inside the Process domain. That placement matters. It is not filed under Business Environment with governance and compliance, and it is not filed under People with the team and stakeholder tasks. PMI treats it as delivery work: something you do while running the project, not a strategic exercise you complete at the front and then set aside.
The six enablers
The outline lists six enablers under the task. Each one points at a different decision pattern.
| Enabler | What it asks of you |
|---|---|
| "Identify value components with key stakeholders." | Value is defined with people, not assumed. The stakeholders name what counts. |
| "Prioritize work based on value and stakeholder feedback." | Sequencing is driven by value and feedback, not by convenience or technical preference. |
| "Assess opportunities to deliver value incrementally." | Look for a way to release something useful earlier than the full scope allows. |
| "Examine the business value throughout the project." | Value is re-checked as conditions change, not fixed at the charter. |
| "Verify a measurement system is in place to track benefits." | Someone must be able to tell whether the benefit actually arrived. |
| "Evaluate delivery options to demonstrate value." | More than one delivery route usually exists; compare them against value. |
Read those together and a pattern emerges. Four of the six are about checking, examining, verifying, and evaluating. This task is mostly about not letting an assumption go unexamined.
Value is agreed, not calculated
The first enabler is the one that changes how you read answer options. "Identify value components with key stakeholders" means the project manager does not get to decide alone what value looks like.
In a scenario where a sponsor and a product owner disagree about which feature matters most, an option that has you analyzing the two features and picking the better one is usually wrong, however reasonable it sounds. An option that has you bringing the two of them into the same conversation to agree on the value criteria is usually right. The skill being tested is recognizing that value is a shared definition, and that a project manager who substitutes their own judgment has skipped a step.
This is the same instinct the People domain tests with stakeholder questions, applied to a different object. There, you engage stakeholders about their interests. Here, you engage them about what the project is for.
Incremental delivery gets asked about more than it used to
"Assess opportunities to deliver value incrementally" is a standing invitation to look for an earlier release. On a predictive project that does not mean converting to agile; it means asking whether a usable subset exists.
The trap in these questions is the option that defers everything to the end because the plan says so. The plan saying so is not a reason — it is the thing being questioned. But the opposite trap is also present: an option that starts releasing in pieces without talking to anyone. The enabler says assess opportunities, and assessment involves the people who have to receive, support, and use what you release.
Note also that this enabler says nothing about development approach. A question can place it inside a predictive, agile, or hybrid scenario, and the right answer is the same shape in all three.
The measurement enabler is the one candidates skip
"Verify a measurement system is in place to track benefits" is quietly the most testable of the six, because it is the one with an unambiguous right answer.
If a scenario describes a benefit that the project is supposed to produce — reduced processing time, higher retention, lower cost per transaction — and nobody has said how it will be measured or who will measure it, the gap is the answer. Options that proceed with delivery, or that promise to measure it later, are wrong. The project manager's job at that moment is to make sure the measurement exists before the thing being measured is delivered.
The word "verify" is doing work here. It does not say build the measurement system yourself. In many organizations the measurement belongs to an operations or business function, and benefits often land after the project closes. Verifying means confirming it exists and that someone owns it.
Where this overlaps other tasks, and where it does not
Three nearby tasks get confused with this one.
Prioritization techniques — MoSCoW, Kano, WSJF, and the rest — are tools you might use when applying the second enabler, but a question about how a technique works is a technique question. A question about why work was sequenced the way it was is a value-based delivery question.
Finance is a separate Process task with its own enablers, including quantifying risk and contingency allocations. Money questions about funding, reserves, and spend tracking belong there.
Governance is Domain III, Task 1, and it includes "Define success metrics." That sounds like the benefits measurement enabler and is not the same thing. Governance success metrics are about how the project will be judged and escalated. The benefits measurement system is about whether the outcome materialized. A scenario that turns on reporting lines and thresholds is governance; one that turns on whether anyone will know if the benefit arrived is this task.
A study approach
Take the six enablers and write a one-sentence situation for each where that enabler is being violated. A sponsor who defines value alone. A backlog ordered by technical ease. A twelve-month release when a three-month slice would help. A business case nobody has reopened since approval. A promised benefit with no metric. A single delivery plan nobody compared against alternatives.
Those six situations are, in practice, the question stems. If you can spot which one you are looking at, the correct option is usually the one that restores the missing step rather than the one that advances the schedule.