HKSM

The planning activity that defines how project and product scope will be identified, structured, validated, and controlled, including how requirements are gathered, prioritized, traced, and approved.

Purpose & When to Use

• Set clear rules for how scope and requirements will be handled from start to finish.
• Clarify what is in scope versus out of scope, how acceptance will work, and how changes will be evaluated.
• Use early in planning, then refine at phase gates, releases, or major backlog updates.
• Apply on all delivery approaches: predictive (WBS-focused), adaptive (backlog-focused), or hybrid.
• Align teams and stakeholders on definitions, roles, decision rights, and documentation standards.

Mini Flow (How It’s Done)

• Review context: charter, product goals, business case, constraints, and governance.
• Select delivery approach and tailoring: predictive, adaptive, or hybrid; note implications for WBS/backlog and change handling.
• Define scope concepts: product scope vs. project scope, definitions of Ready/Done, and what “acceptance” means.
• Plan requirements work: elicitation methods, sources, prioritization rules (e.g., MoSCoW, WSJF), and traceability approach.
• Plan structuring: WBS rules for decomposition or backlog hierarchy (epics, features, stories) and refinement cadence.
• Plan validation and acceptance: who reviews, acceptance criteria format, test/verification methods, and sign-off points.
• Plan scope control: baseline or guardrails, change evaluation steps, impact analysis, and integration with change control.
• Define roles and responsibilities: decision owners, approvers, and involvement of stakeholders and vendors.
• Document the scope and requirements approach; socialize and obtain agreement.
• Establish repositories and tooling: templates, traceability matrix or backlog tool, and versioning rules.

Quality & Acceptance Checklist

• Scope boundaries and out-of-scope items are listed and understandable.
• Product scope vs. project scope are distinguished and examples are provided.
• Elicitation techniques, prioritization rules, and approval criteria are defined.
• Acceptance criteria format and verification methods are clear and testable.
• Decomposition approach is stated: WBS guidance or backlog hierarchy and refinement cadence.
• Requirements traceability approach covers source, status, version, and links to deliverables or tests.
• Scope change process is integrated with overall change control and impact analysis steps.
• Roles, decision rights, and escalation path are documented.
• Non-functional requirements, constraints, and compliance needs are included.
• Templates, repositories, and tool conventions are identified.
• Alignment with schedule, cost, risk, and quality management approaches is shown.
• Review and approval of the plan by key stakeholders is recorded.

Common Mistakes & Exam Traps

• Jumping into detailed requirements or building a WBS/backlog before agreeing on how scope will be managed.
• Confusing product scope (features and characteristics) with project scope (work to deliver the product).
• Locking scope too rigidly on adaptive projects instead of using a prioritized backlog and cadence-based refinement.
• Vague or missing acceptance criteria, leading to disputes at validation time.
• Ignoring traceability, making it hard to prove coverage from requirement to deliverable and test.
• Not integrating scope changes with schedule, cost, and risk impacts.
• Excluding key stakeholders, leading to rework or late changes.
• Treating the WBS as a schedule rather than a deliverable-oriented decomposition.

PMP Example Question

A new project is starting. Stakeholders disagree on how detailed requirements should be and who will approve changes. What should the project manager do first?

1. Create the WBS to force clarity on deliverables.
2. Begin collecting detailed requirements from subject matter experts.
3. Develop and agree on the scope and requirements management approach.
4. Baseline the scope to prevent uncontrolled changes.

Correct Answer: C — Develop and agree on the scope and requirements management approach.

Explanation: Before detailing scope, establish how scope and requirements will be defined, approved, and changed. This alignment reduces conflict and rework.