HKSM

The planning process that turns approved requirements into a clear, detailed scope statement describing deliverables, boundaries, exclusions, acceptance criteria, constraints, and assumptions. It sets the foundation for the WBS and the scope baseline.

Purpose & When to Use

Define Scope converts stakeholder needs into a precise description of what the project will and will not deliver. It aligns expectations, reduces ambiguity, and provides the basis for creating the WBS and managing scope changes. Use it during planning after requirements are gathered and before building the WBS. Revisit the scope statement when approved changes affect scope.

Mini Flow (How It’s Done)

• Confirm inputs: scope management plan, project charter, approved requirements, assumptions log, and lessons learned.
• Engage key stakeholders through workshops, interviews, and facilitated sessions to clarify needs and success criteria.
• Analyze and reconcile requirements, explore options, and resolve conflicts using decision-making techniques.
• Draft the scope statement covering product scope, deliverables, acceptance criteria, boundaries, exclusions, constraints, and assumptions.
• Model or visualize the product or service as needed using diagrams, mockups, or prototypes to remove ambiguity.
• Review the draft with stakeholders, refine wording, and confirm a shared understanding.
• Obtain formal approval of the scope statement and record who can accept deliverables.
• Update related documents such as the requirements traceability matrix, risk register, and assumptions log.
• List verified deliverables to prepare for Create WBS and later scope baseline approval.

Quality & Acceptance Checklist

• Deliverables are specific, measurable, and verifiable.
• Each deliverable has clear acceptance criteria and acceptance authority named.
• In-scope and out-of-scope items are explicitly listed.
• Boundaries, interfaces, and dependencies with other teams or systems are defined.
• Constraints and assumptions are documented and traceable to their sources.
• Nonfunctional qualities such as performance, security, and usability are addressed.
• Scope aligns with the project charter and business objectives.
• Requirements are traced to scope elements to ensure completeness.
• Terms and acronyms are defined to avoid misinterpretation.
• Risks arising from scope choices are recorded with response owners.
• Approval and change control expectations for scope are described.

Common Mistakes & Exam Traps

• Creating the WBS before finalizing the scope statement.
• Confusing Collect Requirements (gather needs) with Define Scope (state what will be delivered).
• Omitting exclusions, which invites scope creep.
• Writing vague or untestable statements without acceptance criteria.
• Embedding schedule or cost details inside the scope statement.
• Assuming the requirements list alone equals the scope statement.
• Failing to involve the right stakeholders in scope clarification and approval.
• Mixing up Validate Scope (customer acceptance) with Control Quality (conformance checks).
• Ignoring nonfunctional requirements that later become dispute points.
• Not routing scope changes through formal change control once the scope baseline is set.

PMP Example Question

After completing requirements documentation, the team wants to start building the WBS. What should the project manager do next?

1. Develop the detailed project schedule.
2. Facilitate a workshop to draft the detailed scope statement with deliverables, boundaries, and acceptance criteria.
3. Perform quality control on the requirements document.
4. Begin decomposing work into work packages.

Correct Answer: B — Facilitate a workshop to draft the detailed scope statement with deliverables, boundaries, and acceptance criteria.

Explanation: Define Scope comes after Collect Requirements and before Create WBS. Schedule development and quality control are not the correct next steps here.