II.2 — Develop and Manage Project Scope

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

Where this task sits

II.2 — Develop and Manage Project Scope is a task in the Process domain of the 2026 ECO. The domain carries 41% of the exam and holds ten tasks — the heaviest of the three.

The ECO attaches three enablers to this task: define scope, obtain stakeholder agreement on project scope, and break down scope. The middle one is what most study material skips: scope is not only written, it is agreed.

The title changed too. In 2021 the task was "plan and manage scope"; in 2026 it is "develop and manage." Swapping plan for develop moves scope away from being a document you set up front and then defend, and toward something built out across the project.

🔴 Do not trust the number

Scope carries the sneakiest number trap in the 2026 ECO, because the collision is between scope and schedule:

• In 2021, II.8 was scope. In 2026 that topic is II.2.
• In 2026, II.8 is schedule.

So a question tagged "II.8" may belong to two completely different topics depending on which outline it was tagged against. Both sit in the Process domain, both follow the "plan and manage" pattern — which is why the mismatch slips past unnoticed. The same number carrying both topics is something you actually run into in off-the-shelf question banks.

Match on the title, never the number. For the general shape of this trap and its other instances, see what changed in the 2026 PMP exam.

Project scope and product scope are not the same

This is the first thing scope questions separate.

Project scope encompasses the work performed to deliver a product, service, or result with the specified features and functions (PMBOK® 8, Guide p.38). Product scope is a description of the features, functions, and characteristics of that product, service, or result — what the end result should look like and what it should do (PMBOK® 8, Guide p.38).

Short version: project scope is the work, product scope is the output.

The Guide puts a third thing between them: quality is an attribute of scope. The scope of a bridge project includes not just a bridge, but target thresholds for how sturdy, long-lasting, and maintainable it should be (PMBOK® 8, Guide p.38). So options that force you to choose between "a quality problem" and "a scope problem" are often a false dilemma.

What the scope baseline is made of — and what replaces it in adaptive

In predictive environments the scope baseline is the approved version of formal scope documents; it can only be changed through formal change control procedures and serves as the basis for comparison against actual results (PMBOK® 8, Guide p.38). It has three parts: the project scope statement, the WBS, and the WBS dictionary (PMBOK® 8, Guide p.140).

The scope baseline does not stand alone — together with the schedule and cost baselines it forms the performance measurement baseline (PMB) (PMBOK® 8, Guide p.38). Every approved request that changes scope therefore touches all three; for that side of it see III.3 — Manage and Control Changes.

In adaptive approaches the same idea takes another form: the baseline is defined at the start of each iteration and aligned with prioritized requirements based on expected value. Changes are usually approved dynamically by a product owner, without a formal change control procedure (PMBOK® 8, Guide p.38). The Guide notes the naming as well: in adaptive approaches the scope baseline may be called prioritized requirements or the sprint backlog (PMBOK® 8, Guide p.23).

That is where the exam distinction comes from: "has the baseline changed?" is answered differently by approach — formal approval in predictive, the product owner's prioritization in adaptive.

The WBS process under its new name: Develop Scope Structure

The Scope Performance Domain in PMBOK® 8 holds six processes: Plan Scope Management, Elicit and Analyze Requirements, Define Scope, Develop Scope Structure, Monitor and Control Scope, and Validate Scope (PMBOK® 8, Guide p.39).

The fourth goes unrecognized because older sources call it something else. Develop Scope Structure is the process of subdividing project deliverables and project work into smaller, more manageable components (PMBOK® 8, Guide p.40); in predictive projects it produces the WBS (PMBOK® 8, Guide p.42), and its outputs are the scope baseline, the WBS, and the WBS dictionary (PMBOK® 8, Guide p.43).

The bridge the Guide builds here matters: in agile projects this effort corresponds to decomposition of the product backlog — work items broken down into epics, features, and user stories (PMBOK® 8, Guide p.40). So "WBS or backlog," usually treated as two separate worlds, is one process in two forms.

The ECO's "break down scope" enabler points at exactly this process.

The value breakdown structure: tying scope to value

The tool PMBOK® 8 brings to the scope domain that older sources have no counterpart for is the value breakdown structure (VBS): a hierarchical structure connecting the project scope and its intended value to the product scope that will generate that value (PMBOK® 8, Guide p.38).

At the top sit the major deliverables discussed among stakeholders. The value each is expected to add is entered either as a value-based number (revenue, students taught to read, lives saved) or as a percentage of the project's total expected value — a mandatory deliverable is 100%. Those estimates are then used to prioritize deliverables; each top-level item decomposes into subdeliverables, which decompose through a WBS into project scope and activities (PMBOK® 8, Guide p.38).

In short, the VBS describes value from the top and the WBS describes work from the bottom. That is the reasoning "which deliverable first" questions are looking for.

Validating scope versus controlling it

The two processes look alike, but their difference is a fixed question pattern:

• Monitor and Control Scope: monitoring the status of project and product scope, managing changes to the scope baseline, measuring the quality of deliverables, and ensuring required standards are met (PMBOK® 8, Guide p.40). The aim is for the result to stay relevant and deliver value to stakeholders (PMBOK® 8, Guide p.42).
• Validate Scope: formalizing acceptance of the completed project deliverables (PMBOK® 8, Guide p.40).

What shows the split most clearly is the process input: Validate Scope takes verified deliverables and quality control measurements among its inputs (PMBOK® 8, Guide p.44). The deliverable passes through quality first, then goes to acceptance.

Translated for the exam: "did it pass internal checks" is a quality question; "did the customer accept it" is a scope validation question.

Scope creep and gold plating

Both are scope growing without control, but they come from different directions: scope creep leaks in from outside, gold plating is the team's own addition.

The Standard for Project Management says plainly that exceeding value does not mean endorsing or accepting gold plating or scope creep (PMBOK® 8, Standard p.5), and adds that a focus on value requires continuous scope management to prevent both (PMBOK® 8, Standard p.42).

The Guide's practical advice looks at the document: defining what is out of scope for the project helps manage stakeholder expectations and can reduce scope creep (PMBOK® 8, Guide p.128).

Translated for the exam: "we added something small to keep the customer happy" is not the right answer, however well-intentioned it looks.

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.