A project scope statement template provides a detailed description of the project scope, major deliverables, exclusions, constraints, and assumptions that define the project boundaries. According to the Project Management Institute (PMI), the project scope statement template is a key output of the Planning Performance Domain in PMBOK 8, serving as the baseline for evaluating all scope change requests throughout execution. A clearly written project scope statement template prevents scope creep by establishing an unambiguous record of what is — and critically, what is not — included in the project. This shared definition of boundaries is essential for managing stakeholder expectations and making consistent decisions about change requests during execution.

What is a Project Scope Statement?

A project scope statement template defines what is included in the project and what is explicitly excluded. It describes the product scope in sufficient detail to guide design and delivery decisions, lists deliverables with their acceptance criteria, documents constraints that limit the team's options, and records assumptions that were accepted as true during planning. The project scope statement is developed after requirements have been collected from stakeholders and is the primary input to WBS development. It differs from requirements documentation in that it synthesizes requirements into a high-level scope description rather than cataloguing every individual requirement. In PMBOK 8, the project scope statement template combined with the WBS and WBS dictionary constitutes the scope baseline against which all scope performance is measured. The project manager, business analyst, and project sponsor collaborate on this document to ensure all parties share a common understanding of the project's boundaries before execution begins.

What's Included in This Project Scope Statement Template?

• SMART Objectives — Specific, measurable project objectives with quantified success criteria that will be used at project closure to determine whether the project achieved its intended outcomes and delivered its promised value to the organization.
• Product Scope Description — Detailed description of the features, functions, and characteristics of the product, service, or result to be created, with sufficient specificity to guide design decisions and inform deliverable development throughout execution.
• Requirements with MoSCoW Prioritization — Categorized requirements table showing Must Have, Should Have, Could Have, and Won't Have requirements, enabling the team to make informed trade-off decisions when schedule or cost constraints are encountered during execution.
• Project Deliverables — Complete list of all deliverables the project will produce, each with a brief description and reference to the corresponding WBS work package where more detail can be found in the WBS dictionary.
• Project Exclusions — Explicit list of what is out of scope, documented with the same care as inclusions. This section is often more valuable than the inclusions list because it prevents the most damaging source of scope creep — assumed inclusions that were never explicitly discussed.
• Constraints — Documented limitations on the project team's options, including fixed deadlines, budget caps, regulatory requirements, technology mandates, and resource availability constraints that must be respected in all planning and execution decisions.
• Assumptions — Accepted premises treated as true during planning, each with an assessment of the risk if the assumption proves false and a reference to the assumption log where they are tracked for ongoing validation throughout the project.
• Delivery and Acceptance Criteria — The specific conditions that must be met for each deliverable to be formally accepted, including who performs the acceptance review, the inspection and testing process, and the timeframe for acceptance decisions.
• Sustainability Scope — ESG-related deliverables and activities included in the project boundary, ensuring sustainability commitments made in the business case are formally included in scope and cannot be removed without a formal change request process.

How to Use This Project Scope Statement Template (PMBOK 8)

1. Develop after completing requirements collection — The project scope statement template synthesizes stakeholder requirements into a coherent scope description. Do not draft it until requirements have been collected, analyzed, and prioritized with all key stakeholders to ensure completeness.
2. Use MoSCoW to rank requirements by value — Apply the MoSCoW framework to every significant requirement. This enables objective trade-off decisions when constraints are encountered during execution without triggering a change request for every minor adjustment to delivery approach.
3. Document exclusions as carefully as inclusions — For every major item stakeholders might assume is included, document it explicitly as an exclusion with the rationale. This section prevents the most common source of scope disputes and helps manage expectations proactively before they become problems.
4. Validate with all key stakeholders before baselining — Circulate the draft project scope statement template to all stakeholders who provided requirements for review and sign-off. Unresolved scope disagreements at this stage will become expensive disputes during execution.
5. Obtain formal sponsor approval — The project scope statement does not become the scope baseline until the sponsor formally approves it. This approval signals organizational commitment and authorizes the team to proceed with WBS development and schedule planning.
6. Reference when evaluating all change requests — During execution, every change request should be evaluated against the approved project scope statement template to determine whether it represents a scope addition, modification, or deletion requiring formal change control.

When to Create This Document (PMBOK 8)

The project scope statement template is created during the Planning Performance Domain, after requirements collection is complete and before WBS development begins. In PMBOK 8, the scope statement is part of the scope baseline and must be formally approved before execution activities commence. For agile projects, a high-level scope statement provides governance boundaries while detailed scope definition is managed adaptively through the product backlog and sprint planning process.

Related Templates

• Requirements Documentation Template
• Scope Baseline Template
• Scope Management Plan Template
• Change Request Template
• Deliverables Acceptance Checklist Template