Scope Management for PMP

Scope management defines and controls what's included in a project — and just as importantly, what's not. It's a core Process domain topic. This guide covers the WBS, scope baseline, and common pitfalls like gold plating.

The Scope Management Process

1. Plan Scope Management — define how scope will be defined and controlled
2. Collect Requirements — document stakeholder needs
3. Define Scope — create the project scope statement
4. Create WBS — break scope into manageable work packages
5. Validate Scope — formal acceptance with the customer
6. Control Scope — manage changes to the scope baseline

Product Scope vs. Project Scope

• Product scope: Features and functions of the deliverable
• Project scope: The work required to deliver the product scope

Collecting Requirements

Techniques:

• Interviews — one-on-one with stakeholders
• Focus groups — facilitated group discussions
• Workshops — joint application development (JAD)
• Surveys — large audiences
• Observation — watch users in context
• Prototyping — iterative refinement
• Benchmarking — compare to similar solutions

The Scope Statement

The project scope statement includes:

• Product scope description
• Acceptance criteria
• Deliverables
• Project exclusions (out of scope)
• Constraints
• Assumptions

The Work Breakdown Structure (WBS)

A hierarchical decomposition of the project scope into manageable work packages.

Key WBS Concepts

• Work package: Lowest level of the WBS (typically 8–80 hours of work)
• Control account: Management control point above work packages
• Planning package: Below a control account, work to be planned
• WBS dictionary: Detailed description of each WBS component

The 100% Rule

The WBS must include 100% of the work — no more, no less. Every level sums to the level above.

The Scope Baseline

The scope baseline consists of:

1. Project scope statement
2. WBS
3. WBS dictionary

Changes to the scope baseline go through integrated change control.

Validate Scope vs. Control Quality

• Validate Scope: Customer accepts deliverables (formal acceptance)
• Control Quality: Inspect deliverables for correctness (internal verification)

Validate scope usually happens after quality control.

Gold Plating

Gold plating is giving the customer more than they asked for — adding features without formal change approval. PMI considers this poor practice because:

• It adds cost without agreed value
• It sets wrong expectations for future projects
• It can introduce unexpected risks
• It's scope creep in disguise

PMI mindset: Deliver exactly what was agreed — no more, no less.

Scope Creep

Uncontrolled expansion of scope without change control. Causes:

• Poor requirements gathering
• Weak change control
• Stakeholder pressure
• Ambiguous scope statement

Prevention: clear scope statement, robust change control, stakeholder engagement.

The PMI Mindset for Scope

1. Define scope clearly — ambiguity breeds scope creep
2. Use the WBS — it's the foundation for all planning
3. Control changes — through integrated change control
4. Avoid gold plating — deliver what was agreed
5. Validate with the customer — formal acceptance matters

Common Scope Exam Traps

• Confusing product scope and project scope
• Mixing up Validate Scope (customer acceptance) and Control Quality (inspection)
• Picking gold plating as a positive — PMI considers it negative
• Forgetting the 100% rule for WBS

Final Thoughts

Scope management rewards discipline: define clearly, decompose with the WBS, control changes, and avoid gold plating. Master these principles and you'll handle scope scenarios with confidence on exam day.