Task 22: Plan and Manage Scope
Scope is the boundary that defines what the project will deliver — and, just as importantly, what it won't. ECO Task 22 charges project managers with determining and prioritizing requirements, decomposing scope into manageable pieces, and continuously monitoring and validating scope throughout the project lifecycle. Scope management is the foundation upon which schedule, budget, and quality plans are built: if you don't know what you're building, you can't possibly know how long it will take or how much it will cost.
PMI treats scope management as a discipline that spans both predictive and agile environments, testing candidates on WBS decomposition, backlog refinement, requirements traceability, and scope validation. The exam's scope questions often pit scope against competing constraints — the sponsor wants more features, the schedule is fixed, and the budget is tight — and ask you to navigate the trade-offs with disciplined scope management practices.
ECO Enablers for Task 22
The PMP Exam Content Outline structures scope management around four enablers that together form a complete scope management lifecycle:
- Determine and prioritize requirements. Requirements are the raw material of scope. The PM must elicit, document, analyze, and prioritize requirements from all relevant stakeholders, distinguishing must-haves (mandatory) from nice-to-haves (desirable) and resolving conflicts when stakeholder needs compete.
- Break down scope (e.g., WBS, backlog). Scope must be decomposed into granular, estimable, and assignable units. In predictive projects, this means the Work Breakdown Structure (WBS). In agile projects, this means the product backlog with prioritized user stories. Both serve the same purpose: making scope manageable.
- Monitor and validate scope. Scope validation is the process of formally accepting completed deliverables with the customer or sponsor. The PM must ensure that what was built matches what was agreed upon — and that informal acceptance doesn't substitute for formal sign-off.
Determining and Prioritizing Requirements
Requirements are the foundation of scope. Every deliverable, every work package, every user story traces back to a requirement — an expression of what a stakeholder needs the project to produce. Requirements gathering (or elicitation) is the first discipline of scope management, and getting it wrong is the single most common cause of project failure.
PMI identifies several categories of requirements: business requirements (the high-level organizational need the project addresses), stakeholder requirements (what specific stakeholders need), solution requirements (functional requirements describing what the product must do and non-functional requirements describing quality attributes like performance, security, and usability), transition requirements (what is needed to move from the current state to the future state), and project requirements (constraints and conditions on how the project is executed).
The requirements traceability matrix (RTM) is the tool that links each requirement to its origin (who requested it), its deliverable (what satisfies it), and its test case (how we prove it was met). The RTM ensures that every requirement is delivered and that nothing is delivered that wasn't required. It is also the PM's primary defense against scope creep — if a requested change doesn't trace to an approved requirement, it's out of scope until formally approved.
PMI recognizes MoSCoW as a common requirements prioritization technique. Must have: non-negotiable requirements without which the project fails. Should have: important but not critical; can be deferred to a later phase if necessary. Could have: desirable but not necessary; included only if time and budget permit. Won't have: explicitly excluded from this phase/release, though may be considered later. When the exam presents competing stakeholder demands, the PM's first responsibility is to facilitate prioritization — not to decide unilaterally which requirements matter most.
Breaking Down Scope: The WBS
The Work Breakdown Structure (WBS) is the cornerstone of predictive scope management. It is a deliverable-oriented hierarchical decomposition of the total scope of work — not a task list, not an organizational chart, not a schedule. The WBS decomposes the project into progressively smaller pieces until the work is granular enough to estimate, assign, and control.
The lowest level of the WBS is the work package — a discrete, manageable unit of work that can be scheduled, cost-estimated, monitored, and controlled. PMI recommends the 8/80 rule: work packages should represent between 8 and 80 hours of effort. Anything larger than 80 hours is difficult to track accurately; anything smaller than 8 hours may create excessive administrative overhead.
Activities — the tasks performed to complete each work package — are one level below the WBS and belong to the activity list, not the WBS itself. The PMP exam tests this distinction explicitly: the WBS decomposes deliverables, not activities. A common trap answer is to place activities directly in the WBS.
WBS vs. Backlog: Predictive vs. Agile Decomposition
| Dimension | WBS (Predictive) | Product Backlog (Agile) |
|---|---|---|
| Structure | Hierarchical tree, deliverable-oriented, decomposed to work packages (~8–80 hours). Top-down decomposition planned upfront. | Flat or lightly structured list of user stories, epics, and features. Progressive elaboration throughout the project. |
| Granularity | Work packages at the leaf level. Consistent granularity across all branches. | User stories at the sprint-ready level ("small enough to complete in a sprint"). Epics are larger and split later. Granularity varies. |
| Ownership | The project manager owns the WBS, with input from the team and subject matter experts. | The Product Owner owns the backlog content and prioritization. The team owns estimation and refinement. |
| Change Process | WBS changes require formal integrated change control. The scope baseline (WBS + WBS dictionary + scope statement) is under configuration control. | Backlog is inherently dynamic — reprioritized every sprint. New stories can be added at any time. The Product Owner controls what enters the sprint. |
| Completeness Rule | The 100% rule: the WBS must include 100% of the work defined by the project scope. Nothing omitted, nothing extra. | No formal 100% rule. The backlog represents the current understanding of needed work. Scope is discovered iteratively. |
| Dictionary / Details | The WBS dictionary provides detailed descriptions, acceptance criteria, responsible parties, and cost estimates for each work package. | User stories include acceptance criteria and, optionally, definition of ready/definition of done conditions. INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable). |
The WBS Dictionary and Scope Baseline
The WBS alone is insufficient — it is a visual hierarchy. The WBS dictionary provides the detailed information for each work package: a description of the work, acceptance criteria, responsible organization or individual, schedule milestones, cost estimates, quality requirements, and technical references. Together, the WBS and WBS dictionary provide a complete picture of what must be delivered and what "done" means.
The scope baseline is the approved version of the scope statement, WBS, and WBS dictionary. It is the reference point against which all scope performance is measured and is subject to formal change control. Any change to the scope baseline requires an approved change request through the integrated change control process — this is PMI's primary mechanism for controlling scope creep.
Scope creep is uncontrolled expansion of product or project scope without adjustments to time, cost, and resources — usually driven by stakeholders adding "just one more thing." Gold plating is the team adding extra features or functionality beyond the requirements on their own initiative. Both are scope management failures, but the causes differ. Scope creep is a stakeholder-driven problem solved by disciplined change control. Gold plating is a team-driven problem solved by reinforcing that meeting requirements is the goal — not exceeding them. The PMP exam expects you to recognize both and choose the appropriate corrective action for the scenario.
Monitoring and Validating Scope
Scope validation — formally accepting completed project deliverables — is one of the most misunderstood processes on the PMP exam. Validation is not the same as verification. Verification (Control Quality) asks: "Was the deliverable built correctly according to specifications?" Validation (Validate Scope) asks: "Does the customer or sponsor accept the deliverable?" A deliverable can pass verification but fail validation if it doesn't meet the customer's needs.
The Validate Scope process occurs periodically throughout the project — typically at phase gates or major deliverable milestones — and involves the customer or sponsor formally signing off that deliverables are acceptable. The output is accepted deliverables, which feed into the Close Project or Phase process. PMI emphasizes that informal acceptance ("the customer seems happy") is not a substitute for formal documented acceptance.
Scope Control and Change Management
Scope rarely remains static. Stakeholders learn more as the project progresses, market conditions shift, and new opportunities emerge. Scope management is not about preventing change — it is about ensuring that changes are intentional, evaluated, and approved through the right channels.
The Integrated Change Control process is the gatekeeper. When a scope change is requested, the PM must evaluate its impact on all competing constraints: schedule, cost, quality, risk, resources, and stakeholder satisfaction. The change request then goes to the Change Control Board (CCB) for approval, rejection, or deferral. Only after approval is the scope baseline updated, and only then does the team incorporate the change.
Scope Management Across Methodologies
In predictive projects, the scope is largely defined upfront. The scope statement, WBS, and WBS dictionary are baselined early, and changes flow through formal change control. The PM's role is to protect the scope baseline while remaining responsive to legitimate change needs.
In agile projects, scope is emergent. The Product Owner continuously refines and reprioritizes the backlog, and the team commits only to the work in the current sprint. Scope is controlled at the sprint boundary — the sprint backlog is frozen once the sprint begins, and any new requests go into the product backlog for future consideration. This provides a natural scope-control mechanism: the team focuses on the sprint commitment, and new work waits for the next sprint planning session.
Hybrid projects — increasingly common — may use a WBS for predictive workstreams (infrastructure, regulatory compliance) and a backlog for agile workstreams (software features, user-facing functionality). The PM must be fluent in both and know when each applies.
Study Checklist for Task 22
- ✅ Can you distinguish between business requirements, stakeholder requirements, solution requirements (functional and non-functional), transition requirements, and project requirements?
- ✅ Do you understand the WBS — that it is deliverable-oriented, not activity-oriented, and that the 100% rule applies?
- ✅ Can you explain the difference between the WBS (hierarchical decomposition of deliverables) and the activity list (tasks to complete those deliverables)?
- ✅ Do you know how the product backlog serves as the agile equivalent of the WBS, and how user stories, epics, and the INVEST criteria work?
- ✅ Can you distinguish Validate Scope (formal acceptance by customer/sponsor — "did we build the right thing?") from Control Quality (verification that the deliverable meets specifications — "did we build it right?")?
- ✅ Do you understand the requirements traceability matrix (RTM) and its role in linking requirements to deliverables, preventing scope creep, and ensuring nothing is missed?
- ✅ Can you explain how scope changes are managed differently in predictive (formal integrated change control, CCB approval) vs. agile (Product Owner reprioritization, sprint boundary control)?
- ✅ Are you able to identify scope creep and gold plating in exam scenarios and select the appropriate PM response?
Task 22 establishes the discipline that makes every other planning activity possible. A project without defined scope is a project adrift — schedule and budget become meaningless without knowing what you're building. Master these concepts, and you'll navigate the scope questions on the PMP exam with confidence. Return to the ECO Study Guide Index to review other tasks or practice Process Domain questions.
← Back to ECO Study Guide Index | Practice Process Domain Questions →