II.2 — Develop and Manage Project Scope

II.2 · Last updated: 11/10/2026

Scope has to be agreed as well as written

II.2 — Develop and Manage Project Scope is the second task in the Process domain of the 2026 ECO. That domain carries 41% of the exam, and with ten tasks it is the heaviest of the three. The ECO gives this task only three enablers:

• Define scope
• Obtain stakeholder agreement on project scope
• Break down scope

The middle one gets the least attention and generates the most work, because a scope that has been written down still needs everyone involved to accept it.

The task's name changed as well. In 2021 it read "plan and manage scope", and in 2026 it became "develop and manage". Replacing plan with develop nudges scope away from the idea of a document set up once at the start and then defended, and toward something that takes shape over the life of the project.

Scope and schedule traded numbers

Of all the renumbering in the 2026 ECO, the one in this task is the easiest to miss, because two topics swapped numbers with each other. In 2021, II.8 was scope, and that topic is now II.2. In 2026, II.8 is the schedule task.

A question tagged "II.8" can therefore belong to either of two topics, depending on which outline it was tagged against. Both tasks sit in the Process domain and both follow the "plan and manage" naming pattern, which makes a wrong match hard to spot. When mapping older material, go by the title. Other examples of the same trap are collected in what changed in the 2026 PMP exam.

Project scope is the work, product scope is the result

This is the first distinction the exam looks for in scope questions. Project scope is the work performed to deliver a product, service or result with specified features and functions. Product scope describes the features, functions and characteristics of that product, service or result, meaning what it should look like and what it should do (PMBOK® 8, Guide p.38).

The Guide adds a third element to the pair, saying that quality is an integral attribute of scope. Quality can cover both functional and nonfunctional requirements. In the book's example, the scope of a bridge project includes the bridge itself and also target thresholds for how sturdy, long-lasting and maintainable it should be (PMBOK® 8, Guide p.38). Answer options that force you to label a problem as either "quality" or "scope" are often building a false choice for that reason.

How the baseline behaves under each approach

In predictive environments the scope baseline is the approved version of the formal scope documents. It can be changed only through formal change control procedures, and it is the yardstick against which actual results are compared (PMBOK® 8, Guide p.38). It usually consists of the approved versions of the scope statement, the work breakdown structure (WBS) and the WBS dictionary, and it is a component of the project management plan (PMBOK® 8, Guide p.140).

The scope baseline doesn't stand alone either. Together with the schedule and cost baselines it forms the performance measurement baseline (PMB) (PMBOK® 8, Guide p.38), so an approved request that changes scope can be expected to touch all three. The change side is covered in III.3 — Manage and Control Changes.

Under an adaptive approach the same idea takes a different shape. The baseline is defined at the start of each iteration and aligned with requirements prioritized by expected value, and changes are usually approved by the product owner in a more flexible setting, without a formal change control procedure (PMBOK® 8, Guide p.38). The Guide also notes the naming. In adaptive approaches the scope baseline may be called the prioritized requirements or the sprint backlog (PMBOK® 8, Guide p.23).

That gives a clear exam rule. Whether a baseline change needs formal approval depends on the approach, since a predictive project looks for that approval while in an adaptive project the product owner's prioritization is enough.

The WBS process has a new name

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.9).

The fourth is easy to overlook 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. Where deliverables are complex or interdependent, a WBS dictionary may also be prepared, elaborating each WBS component's scope description, milestones, responsible parties, resource needs and acceptance criteria (PMBOK® 8, Guide p.42).

The bridge the Guide builds at this point matters. In agile projects the same effort corresponds to decomposing the product backlog, with work items broken down into epics, features and user stories (PMBOK® 8, Guide p.40). Two practices that are often treated as separate worlds, the WBS and the backlog, become two forms of a single process in PMBOK, and this is the process behind the ECO's "break down scope" enabler.

The value breakdown structure links scope to value

One of the tools in PMBOK® 8's scope material is the value breakdown structure (VBS), a hierarchical framework that connects the project scope and its intended value to the product scope that will generate that value (PMBOK® 8, Guide p.38).

At the top of the structure sit the major deliverables discussed with stakeholders. The value each one is expected to add is recorded either as a number, which depending on the project might be revenue, students taught to read or lives saved, or as a percentage of the project's total expected value, and a mandatory deliverable counts as 100%. These estimates are used to prioritize deliverables, and each top-level item breaks down into subdeliverables and from there, through a WBS, into project scope and activities (PMBOK® 8, Guide p.38).

The division of labor between the two structures is then easy to see, since the VBS describes value from the top while the WBS describes work from below. In questions about which deliverable should come first, that value estimate is usually the reasoning the exam expects.

Controlling scope and validating it

Two similar-sounding processes produce a frequently tested distinction. Monitor and Control Scope tracks the status of project and product scope, manages changes to the scope baseline and makes sure deliverables meet the required standards (PMBOK® 8, Guide p.40). The book describes its main purpose as keeping the product relevant and delivering value to stakeholders while meeting the requirements they stated (PMBOK® 8, Guide p.42). Validate Scope, for its part, formalizes acceptance of the completed deliverables (PMBOK® 8, Guide p.40).

The inputs show the difference most clearly. Validate Scope takes verified deliverables and quality control measurements among its inputs (PMBOK® 8, Guide p.44), so a deliverable first passes internal quality checks and only then goes to the customer for acceptance. When a question asks whether something passed internal checks, it is asking about quality, and when it asks whether the customer accepted it, it is asking about scope validation.

Scope creep and gold plating

Both describe scope growing without control, though they come from different places. Scope creep seeps in from outside through unapproved requests, while gold plating is what the team adds on its own initiative. The Standard states that meeting or exceeding value does not mean endorsing or accepting gold plating or scope creep, and that the emphasis is on value-driven decision-making (PMBOK® 8, Standard p.5). It adds that a focus on value requires continuous scope management to prevent both (PMBOK® 8, Standard p.42).

The Guide's practical advice concerns the scope document. Stating explicitly what is out of scope helps manage stakeholder expectations and can reduce scope creep (PMBOK® 8, Guide p.128).

An option that says "we added a small extra to keep the customer happy" is therefore not accepted as the right answer on the exam, however well-meant it looks.

About the citations

Every page number above refers to the PMBOK® Guide, Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked "ECO" separately.

⚠️ 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 describes the book; it does not replace it.