5.2 Plan Scope Management
| 5.2 Plan Scope Management | ||
|---|---|---|
| Inputs | Tools & Techniques | Outputs |
The process of defining how project scope and requirements will be identified, documented, approved, traced, validated, and controlled. It produces the Scope Management Plan and the Requirements Management Plan.
Purpose & When to Use
This process sets the rules and methods for managing scope from start to finish. It tells the team how to define scope, how to accept deliverables, and how to control changes. Use it early in planning after the charter is approved, and update it when governance, lifecycle, or stakeholders change. It applies to predictive, agile, and hybrid projects.
Mini Flow (How It’s Done)
- Review the project charter, business case, and constraints to understand boundaries and success criteria.
- Identify key stakeholders and decision makers; involve experts to tailor approaches.
- Choose how requirements will be gathered, analyzed, documented, prioritized, and traced.
- Decide how scope will be structured and baselined, including scope statement format, WBS rules, and coding schemes.
- Define acceptance methods: who validates deliverables, when validation happens, and what evidence is needed.
- Set scope change control: request path, impact analysis steps, thresholds, tools, and approval levels.
- Tailor for lifecycle: backlog management, refinement cadence, Definition of Ready/Done (agile), or stage-gate approvals (predictive).
- Document the Scope Management Plan and the Requirements Management Plan; review and confirm stakeholder agreement.
Quality & Acceptance Checklist
- Requirements activities are defined: how to elicit, document, prioritize, and trace requirements.
- Roles and authorities for scope decisions and approvals are clearly assigned.
- Templates and tools are named: scope statement, WBS and WBS dictionary, requirements traceability matrix or backlog tool.
- Acceptance criteria are measurable, and validation timing, methods, and artifacts are specified.
- Scope change control steps and thresholds are clear and link to integrated change control.
- Scope baseline policy is defined: when it will be set, maintained, and updated.
- Lifecycle tailoring is addressed: backlog ownership, refinement cadence, Definition of Ready/Done, and acceptance workflow (for agile/hybrid).
- Key assumptions and constraints that affect scope are recorded and communicated.
Common Mistakes & Exam Traps
- Confusing planning the approach with doing the work: Collect Requirements and Create WBS happen later.
- Leaving out stakeholders, leading to missed needs and later scope creep.
- Vague acceptance criteria that cause disputes during deliverable validation.
- No traceability plan, making it hard to assess change impacts or confirm coverage.
- Ignoring lifecycle needs: not defining backlog practices, Definition of Ready/Done, or acceptance in agile/hybrid contexts.
- Mixing product features and project deliverables without clear boundaries.
- Exam trap: Validate Scope involves stakeholder acceptance; Control Quality is about technical correctness.
- Exam trap: The scope baseline is created in Create WBS, not in Plan Scope Management.
- Exam trap: Scope changes follow the process defined here and are approved through Integrated Change Control.
PMP Example Question
During early planning, the project manager wants to prevent scope creep and avoid disputes about who approves completed deliverables. What should the project manager develop first?
- The work breakdown structure (WBS).
- The Scope Management Plan.
- The requirements traceability matrix.
- A detailed project scope statement.
Correct Answer: B — The Scope Management Plan.
Explanation: Plan Scope Management defines how scope and requirements will be defined, validated, and controlled. The WBS and scope statement are created later, and the traceability matrix comes from Collect Requirements.
HKSM