📐 Scope Management
Study Notes — Page 2 | ClearPMPExam.com .
1. What is Scope Management?
Scope Management defines exactly what work is included in the project — and what is NOT. It ensures the team delivers what was agreed, nothing more, nothing less.
Think of scope as drawing a boundary around your project. Inside the boundary = work we do. Outside the boundary = not our job right now. Scope Management is about drawing that boundary clearly and defending it throughout the project.
🏢 Real Example — Website Redesign Project
IN scope: New homepage design, mobile responsiveness, SEO optimisation, contact form update.
OUT of scope: Server migration, new payment gateway, CRM integration.
👉 Without clear scope, the client will keep adding requests (“Can you also fix the payment page?”) and your project will never end — this is called scope creep.
2. The 6-Step Scope Process — In Order
Scope Management follows six steps, always in this sequence. The exam loves to test whether you know the correct order — and which step produces which output.
Plan Scope Management
Decide how scope will be defined, validated, and controlled throughout the project. Creates the Scope Management Plan — the rulebook for scope.
Output → Scope Management PlanCollect Requirements
Gather what stakeholders need from the project. Use interviews, surveys, workshops, focus groups, and the Delphi technique to gather input from everyone who matters.
Output → Requirements Documentation, Requirements Traceability MatrixDefine Scope
Take the collected requirements and write a detailed description of exactly what the project will deliver — and what it will NOT. Uses product analysis, expert judgment, and decision-making.
Output → Project Scope StatementCreate WBS (Work Breakdown Structure)
Break the entire project scope into smaller, manageable pieces called work packages. The WBS is a visual, hierarchical decomposition of all work. Lowest level = work package. No overlap allowed.
Output → WBS, WBS Dictionary, Scope BaselineValidate Scope
Get formal, written acceptance of deliverables from the customer or sponsor. This happens during Monitoring & Controlling. If the client says “approved” — scope is validated.
Output → Accepted DeliverablesControl Scope
Monitor the project scope throughout execution. Prevent and manage scope creep. Ensure only approved changes are implemented. Any new work must go through the change control process.
Output → Change Requests, Work Performance Information“Plan → Collect → Define → WBS → Validate → Control” = “People Can Do Very Cool Stuff”
Validate Scope = client accepts the deliverable (did we build the RIGHT thing?). Control Quality = PM inspects the deliverable (did we build it RIGHT?). Quality check happens BEFORE scope validation.
3. How to Collect Requirements — Tools the Exam Loves
Step 2 (Collect Requirements) has a set of specific tools and techniques. The exam gives you a scenario and asks which tool is being used. Know these cold.
Brainstorming
Group session to generate ideas quickly. No filtering — all ideas welcome. Good for early requirement gathering.
Interviews
One-on-one conversations with key stakeholders. Deep, detailed understanding. Time-consuming but thorough.
Focus Groups
Pre-qualified stakeholders discuss requirements in a group. Moderated discussion. Good for understanding attitudes.
Surveys / Questionnaires
Written questions sent to a large audience. Fast, scalable. Good when you can’t meet everyone in person.
Delphi Technique
Experts give opinions anonymously through multiple rounds until consensus is reached. No peer pressure or groupthink.
Nominal Group Technique
Structured group session — everyone writes ideas individually, shares, discusses, then votes to prioritise. Key word: voting.
Affinity Diagram
Group similar ideas into categories. You collect 50 ideas and organise them into: Technical / Financial / Risk. Key word: grouping.
Benchmarking
Compare your project practices or products against industry standards or competitors to identify improvements.
“Anonymous expert opinions” → Delphi. “Voting to prioritise ideas” → Nominal Group. “Grouping ideas into categories” → Affinity Diagram. “Large number of people” → Survey. “Deep one-on-one discussion” → Interview.
4. Work Breakdown Structure (WBS) — Explained Simply
The WBS is a visual, hierarchical breakdown of ALL project work into smaller, manageable pieces. It shows WHAT needs to be delivered — not how or when. The lowest level is called a Work Package.
Think of the WBS like a family tree — but for project work. The project is at the top, phases or major deliverables branch out next, and individual work packages sit at the bottom.
↑ These bottom-level boxes are Work Packages — the smallest unit in the WBS
WBS vs WBS Dictionary — What’s the Difference?
The WBS is the visual structure. The WBS Dictionary is the detail sheet for each work package. Together they form the foundation of the Scope Baseline.
| Document | What it contains | Simple analogy |
|---|---|---|
| WBS | Names of deliverables and work packages in a visual tree. No detailed numbers. | The building floor plan — shows what rooms exist |
| WBS Dictionary | For each work package: scope description, cost estimate, duration, resources needed, assumptions, constraints. | The room specification — dimensions, materials, purpose |
“WBS shows the structure. Dictionary shows the details.” — Structure first, details second.
1. WBS is deliverable-based, not activity-based. 2. Every piece of work must be in the WBS — no overlap, no gaps. 3. WBS is created in Planning. 4. The lowest level = Work Package — used for cost, time, and resource estimation.
5. Scope Baseline — The Most Tested Definition
The Scope Baseline is the approved, agreed version of the project scope. It is used as the reference point for all scope change decisions. If someone wants to add or remove work, you compare it against the baseline.
Scope Statement
Detailed description of what IS and IS NOT in the project. Includes deliverables, acceptance criteria, assumptions, and constraints.
WBS
Visual breakdown of all project work into work packages. The hierarchy of deliverables.
WBS Dictionary
Detailed description of each work package — cost, schedule, resources, and acceptance criteria per package.
✅ Scope Baseline = Scope Statement + WBS + WBS Dictionary (all three, always)
The Scope Baseline is the approved scope used to measure and control changes. The Project Management Plan is the overall plan that includes the scope baseline, schedule baseline, cost baseline, and all subsidiary plans. Baseline is a part of the plan — not the same thing.
6. Key Scope Documents — Know Which Comes When
Four documents appear in scope management. The exam confuses them on purpose — especially SOW vs Scope Statement. Know each one cold.
| Document | What it is | When created | Key content |
|---|---|---|---|
| SOW (Statement of Work) |
High-level description of what will be delivered. Written by the client/sponsor before the project starts. | Before project | Business need, product description, high-level requirements |
| Project Charter | Official document that starts the project and gives the PM formal authority to use resources. | Initiating | High-level scope, stakeholders, business case, PM authority |
| Scope Statement | Detailed description of what IS and IS NOT in the project scope. | Planning | Deliverables, acceptance criteria, exclusions, constraints, assumptions |
| WBS + WBS Dictionary | Visual work breakdown + detailed work package descriptions. | Planning | All project work, decomposed into manageable packages |
SOW = “Here’s what I want built” (client says, before project). Scope Statement = “Here is exactly what we will build and what we won’t” (PM writes, in Planning).
7. Product Scope vs Project Scope
This is a common exam trap. Both have the word “scope” — but they mean different things and are measured differently.
🟢 Product Scope
Features & functions of the product itselfMeasured against: Requirements
Example: The mobile app must have login, payment, and notifications. These are product features.
Question to ask: “Does the product have what we promised?”
🔵 Project Scope
All the work needed to deliver the productMeasured against: Scope Baseline
Example: Design, code, test, deploy, train users, write documentation — all the work to deliver the app.
Question to ask: “Did we complete all the planned work?”
“Features / functionality” → Product Scope. “Work / tasks / deliverables” → Project Scope. When question mentions requirements → Product Scope. When question mentions Scope Baseline → Project Scope.
8. Scope Creep — The Silent Project Killer
Scope creep is the uncontrolled expansion of project scope — when new work is added without going through the formal change control process.
⚠️ Classic Scope Creep Scenario
You are building a pharma company website. Scope is agreed: homepage, about page, product listing, contact form.
Halfway through the project, the client says: “Can you also add a blog, a video gallery, and a patient testimonials section? It won’t take long.”
👉 If you say yes without a formal change request — that is scope creep. The project will run over time and budget, and the client will still be unhappy because expectations keep shifting.
What the PM must do: Log a formal change request → analyse impact on time and cost → get Change Control Board approval → THEN implement if approved.
Never agree to “small” additions without going through change control. In the PMP world, there is no such thing as a free small request. Every change — big or small — must go through the formal process.
The Change Control Process — Step by Step
(time, cost, risk)
CCB = Change Control Board. In Agile, the Product Owner handles change decisions (no CCB). In Traditional / Waterfall, the CCB approves or rejects all changes. In Hybrid, it depends on the approach used for that part of the work.
9. Quick Summary — Everything on One Page
| Concept | One-line meaning | Exam trigger word |
|---|---|---|
| Scope Statement | Detailed description of what is IN and OUT of scope | “what is included” |
| WBS | Visual tree of all project work broken into packages | “work breakdown” / “decompose” |
| WBS Dictionary | Details for each work package | “details of work package” |
| Scope Baseline | Scope Statement + WBS + WBS Dictionary | “approved scope” / “baseline” |
| Validate Scope | Client formally accepts deliverables | “client acceptance” / “sign-off” |
| Control Scope | Monitor and prevent uncontrolled changes | “scope creep” / “change control” |
| Product Scope | Features and functions of the product | “features” / “functionality” |
| Project Scope | All the work needed to deliver the product | “work” / “tasks” / “deliverables” |
| Scope Creep | Uncontrolled expansion of scope without approval | “adding work without approval” |
| SOW | High-level work description before project starts | “before project” / “client requirement” |
🎯 Practice Q&A — Test Yourself
Read the question. Think of your answer first. Then click to reveal.
✅ Page 2 complete. Next up: Page 3 — Schedule Management — Critical Path, PERT, Float, Crashing, Fast Tracking, and Estimation Techniques. All explained simply.