Define Project Scope Statements

This skill writes project scope statements that establish clear boundaries and measurable deliverables to prevent scope creep. The essential structure covers project justification (business need, strategic alignment, success metrics), product scope description (primary deliverable and key features), phased deliverables with acceptance criteria, overall acceptance criteria, explicit included/excluded boundaries, constraints (budget, timeline, resources, technical), and documented assumptions with their risk if incorrect.

Effective boundary-setting is shown with worked examples for both a software project (included: web app with auth, CRM integration, mobile-responsive design; excluded: native mobile apps, legacy data migration, maintenance beyond a 30-day warranty) and a marketing campaign (included: specific creative asset counts, media buying, landing pages; excluded: influencer partnerships, social community management, SEO of existing content) - demonstrating that boundaries need specific, itemized exclusions, not vague catch-alls.

EXCLUDED:
- Native mobile applications (iOS/Android)
- Data migration from legacy systems
- Ongoing maintenance beyond 30-day warranty

Advanced scope management uses a hierarchical breakdown from product scope (Level 1) through major components (Level 2) down to specific features (Level 3, e.g. shopping cart functions like add/remove, save for later, guest checkout, abandoned cart recovery) - a structure that maps directly onto a work breakdown structure. Stakeholder-driven validation tailors scope review by role (executive sponsor on business value, end users on usability, technical teams on constraints, operations on support requirements). Common anti-patterns are named explicitly: vague language ("improve performance" vs. a specific latency target), scope-creep-enabling phrases like "and other related tasks as needed," missing exclusions, and unmeasurable acceptance criteria ("user-friendly" vs. a specific task-completion rate). A quality checklist verifies acceptance criteria, explicit exclusions, quantifiable success metrics, risk-assessed assumptions, documented constraints, clear stakeholder roles, a referenced change-control process, identified external dependencies, and aligned resource estimates. Integration with project planning covers mapping deliverables to WBS work packages and validating resource estimates against scope complexity, and a scope-change impact template captures the requested change, affected deliverables, schedule/budget/resource impact, new risks, and an approve/reject/modify recommendation.

Use this skill when defining or documenting a project's scope - writing hierarchical deliverables with acceptance criteria, setting explicit in/out-of-scope boundaries, mapping scope to a work breakdown structure, or assessing the impact of a proposed scope change.

It is not the right fit for the broader project initiation document that also needs governance/authority structures and budget (that's a project charter, a related but distinct document), or for very small tasks where formal boundary documentation adds more overhead than value.

Input: the project's business need and the deliverables/features under consideration. Output: a structured scope statement with justification, phased deliverables and acceptance criteria, explicit included/excluded boundaries, a hierarchical scope breakdown mapping to a WBS, documented constraints and assumptions, and a scope-change impact template for evaluating future requests.

The scope statement is designed to feed directly into work breakdown structure development and schedule planning, and serves as the baseline reference for formal change-control processes.

Project managers and business analysts defining project boundaries - particularly those needing explicit, itemized in/out-of-scope statements and a hierarchical deliverable breakdown that maps cleanly to a work breakdown structure.