HKSM

Define Scope converts approved requirements into a clear description of what will be delivered, what is out of scope, and how acceptance will be judged. It produces a detailed scope statement that supports estimating, scheduling, quality planning, and change control.

Purpose & When to Use

Define Scope creates a shared understanding of the product and project boundaries. It turns stakeholder needs into a detailed scope statement with deliverables, success criteria, and exclusions. Use this after requirements are collected and analyzed, and before breaking down work and building the schedule. Revisit it when approved changes affect scope.

Mini Flow (How It’s Done)

• Review inputs: project charter, approved requirements, business objectives, risks, assumptions, and constraints.
• Facilitate workshops or interviews to clarify needs, resolve conflicting requirements, and prioritize what matters most.
• Draft the product scope description: capabilities, features, and quality attributes the product must have.
• List project deliverables and completion criteria for each deliverable.
• Define boundaries: what is included and explicitly excluded.
• State acceptance criteria and the acceptance process (who approves and how evidence is collected).
• Document key assumptions, constraints, and dependencies that shape scope.
• Align requirements to scope using a traceability view to confirm coverage and avoid extras.
• Conduct a review with customer, sponsor, and core team; resolve open questions.
• Finalize and baseline the scope statement; communicate and store it where the team can access it.
• Establish how scope changes will be evaluated and approved through change control.

Quality & Acceptance Checklist

• Scope statement links back to the charter and business goals.
• Deliverables are specific, measurable, and testable.
• Acceptance criteria are clear, objective, and evidence-based.
• Inclusions and exclusions are explicitly listed to prevent misunderstanding.
• Nonfunctional needs (e.g., performance, security, usability) are addressed where relevant.
• Assumptions, constraints, and dependencies are documented and dated.
• Stakeholder roles for review and acceptance are named.
• Open items and decisions are tracked with owners and due dates.
• Requirements-to-scope traceability is verified; no extras added without approval.
• Scope statement is approved and baselined; version and date are recorded.

Common Mistakes & Exam Traps

• Mixing requirements collection with defining scope; collect and analyze first, then finalize scope.
• Leaving out exclusions; lack of boundaries invites scope creep.
• Writing vague or subjective acceptance criteria; use objective tests and measures.
• Over-prescribing solution details too early; describe outcomes and deliverables, not construction steps.
• Not involving the customer or operations in acceptance criteria; leads to rework at handover.
• Ignoring nonfunctional qualities; performance and compliance needs affect scope and effort.
• Confusing product scope (features/functions) with project scope (the work to deliver them).
• Skipping traceability; unlinked requirements become gold plating or are forgotten.
• Failing to baseline scope; without a baseline, change control is ineffective.
• Exam tip: Define Scope comes after requirements are gathered and before decomposing work (WBS) and detailed estimating.

PMP Example Question

After collecting and analyzing requirements, the team drafts a detailed description of deliverables, acceptance criteria, and explicit exclusions. What should the project manager do next?

1. Begin developing the schedule to identify the critical path.
2. Decompose deliverables into work packages and update the WBS and its dictionary.
3. Request additional requirements to ensure nothing is missed.
4. Implement change control to manage future scope requests.

Correct Answer: B — Decompose deliverables into work packages and update the WBS and its dictionary.

Explanation: Once scope is defined and agreed, the next planning step is to break it down into manageable work (WBS) to support estimating and scheduling.