Project Scope Statement: Definition, Examples, and Template

A project scope statement is the document that turns a vague project idea into a shared, signed agreement about what the team will build, what it won't touch, and what "done" looks like. Without one, every new feature request or stakeholder wish feels perfectly reasonable, and your schedule quietly falls apart.

What is a project scope statement?

Key Facts

• Per PMBOK 7th edition, the scope statement is the basis for the project scope baseline and informs the WBS, schedule, and budget (PMI, 2021).
• 52% of projects experience scope creep, and the leading root cause is an unclear or missing scope statement at kickoff (PMI Pulse of the Profession, 2024).
• Projects with a signed scope statement at kickoff are 39% more likely to meet their original budget (Standish Group CHAOS Report, 2024).

A project scope statement is a formal document that defines the full boundaries of a project: what work is included, what is explicitly excluded, what deliverables will be produced, and the criteria that determine whether each deliverable has been completed acceptably. It is created during the planning phase and becomes the reference point for every scope-related decision throughout the project life cycle.

Think of it as the contract between the project team and its stakeholders. It answers three questions that, if left unanswered, guarantee trouble:

• What will this project produce?
• What will this project not produce?
• How will we know when each deliverable is finished?

The scope statement feeds directly into the work breakdown structure, which breaks deliverables into actionable tasks. It also anchors the schedule, the budget, and the change control process. Change anything about the scope and every downstream plan needs to be revisited.

Why a scope statement matters

Scope creep is the single most common reason projects run over budget and miss deadlines. It happens gradually: a stakeholder asks for "just one small addition," the team says yes, and six weeks later the project is 40% larger than originally planned and the team is exhausted.

A signed scope statement doesn't stop people from asking for changes. What it does is give the project manager a documented baseline to point to. When a new request arrives, the team can evaluate it against the statement and say clearly, "That's outside scope as agreed. We can add it, but here's the impact on the timeline and budget." That conversation is far easier than trying to remember what was informally agreed at kickoff.

Scope statements also serve stakeholder alignment. When executives, clients, and delivery teams all read and sign the same document before work starts, mismatched expectations get surfaced early, when they're cheap to fix, rather than late, when they're expensive.

This alignment is especially valuable on projects that use agile methodology, where backlogs shift frequently. Even agile teams benefit from a high-level scope boundary that prevents unbounded growth in the product backlog.

What's inside a scope statement (the 7 components)

A complete scope statement addresses seven areas. Skipping any one of them tends to create the exact gaps that scope creep crawls through.

1. Project objectives -- The measurable outcomes the project must achieve. Objectives should be specific and time-bound. "Launch a redesigned website by August 31 that reduces homepage bounce rate by 15%" is a project objective. "Improve the website" is not.

2. Deliverables -- The tangible outputs the project will produce. For a website redesign this might include a new homepage, five interior page templates, a style guide, and a CMS training document. List each deliverable by name so nothing is assumed.

3. Acceptance criteria -- The specific conditions each deliverable must meet to be considered complete and approved. Acceptance criteria remove subjectivity. "The homepage loads in under 2.5 seconds on a 4G connection" is acceptance criteria. "The homepage should feel fast" is not.

4. In-scope items -- The work, features, systems, and processes the project will address. This section prevents the team from accidentally ignoring things that should be included.

5. Out-of-scope items -- The work, features, and systems the project will explicitly not address. This is arguably the most important section. Documenting what you're not doing is what gives you the authority to say no later.

6. Constraints -- The known limitations the project must operate within: budget cap, fixed deadline, specific technology stack, regulatory requirements, team size. Constraints don't disappear by ignoring them; writing them down means everyone plans around the same reality.

7. Assumptions -- The conditions the team is assuming to be true when the scope was defined. If any assumption turns out to be wrong, the scope should be revisited. For example: "We are assuming the client will provide all brand assets by June 15." If those assets arrive two weeks late, the timeline changes.

Scope statement vs project charter vs WBS

These three documents are closely related and often confused with each other. Here's how they differ:

The charter comes first and is broad. The scope statement fills in the detail during project planning. The WBS then takes those deliverables and decomposes them into schedulable work.

None of these documents replaces the others. A charter without a scope statement leaves too much room for interpretation. A scope statement without a WBS stays too abstract for a team to execute against.

How to write a project scope statement: step by step

Step 1: Review the project charter

Start with what's already been approved. The charter contains the project's stated purpose, the sponsor's goals, and any known constraints. Your scope statement should be consistent with the charter, not contradictory to it. Pull out the objectives and use them verbatim or refine them into measurable form.

Step 2: List every deliverable

Work with the team and key stakeholders to enumerate everything the project will produce. Don't just list the final output; include intermediate deliverables like prototypes, test reports, and training materials. Use noun phrases ("Mobile-responsive homepage," "User acceptance testing report") rather than tasks ("Build homepage," "Run tests"). Deliverables are things, not activities.

Step 3: Define acceptance criteria for each deliverable

For each deliverable, write down what "approved" looks like. Involve the stakeholder who will sign off on that deliverable, because their definition of done may differ from yours. Getting this in writing now prevents rework later.

Step 4: Draw the out-of-scope boundary

This is the step most teams skip and later regret. Go through every deliverable and ask: what adjacent work might stakeholders assume is included? Write those things down explicitly as out-of-scope. If your project is a website redesign, it might be tempting for marketing to assume SEO auditing is included. If it's not, say so.

This section also pairs well with the RACI matrix process: you often discover out-of-scope items when you try to assign responsibility for work that wasn't formally in the plan.

Step 5: Capture constraints and assumptions

List every real constraint (budget, deadline, technology, headcount). Then list every assumption you're relying on. Be honest about both. Teams often avoid writing assumptions because it feels like admitting uncertainty. But an unwritten assumption is a hidden risk. Write it down and make a plan to validate it early.

Step 6: Get stakeholder sign-off

A scope statement that no one has signed is just a draft. Circulate it to the project sponsor, key stakeholders, and the delivery team. Resolve disagreements before signing, not after. Once it's signed, it becomes the baseline that change requests are measured against.

Project scope statement template

Copy and adapt this template for your project:

PROJECT SCOPE STATEMENT

Project name: [Project name] Project manager: [PM name] Date approved: [Date] Version: [1.0]

---

Project objectives [State 2-4 measurable outcomes the project must achieve, each tied to a metric and a deadline.]

Deliverables

1. [Deliverable name] -- [Brief description]
2. [Deliverable name] -- [Brief description]
3. [Deliverable name] -- [Brief description]

Acceptance criteria

• [Deliverable 1]: [Specific, measurable condition for approval]
• [Deliverable 2]: [Specific, measurable condition for approval]
• [Deliverable 3]: [Specific, measurable condition for approval]

In-scope

• [Work, feature, or system that is included]
• [Work, feature, or system that is included]

Out-of-scope

• [Work, feature, or system that is explicitly excluded]
• [Work, feature, or system that is explicitly excluded]

Constraints

• Budget: [Amount or cap]
• Timeline: [Fixed end date or constraint]
• Technology: [Required or prohibited tools/platforms]
• Resources: [Headcount or skill constraints]

Assumptions

• [Condition assumed to be true]
• [Condition assumed to be true]

Approvals

Role	Name	Signature	Date
Project sponsor
Project manager
Key stakeholder

Project scope statement examples

Here's how four common project types break down across deliverables, in-scope, and out-of-scope:

Notice how each "out-of-scope" column documents the adjacent work that stakeholders commonly assume is included. That specificity is the whole point. Vague exclusions don't protect anyone.

For projects using Scrum, the scope statement lives at the epic level. Individual sprint scope is managed through the backlog, but the high-level boundaries still apply.

How to prevent scope creep with a scope statement

A scope statement is only as powerful as the change control process that enforces it. Here are five ways to make it work in practice:

1. Reference it in every status meeting. Don't let the scope statement live in a folder and get forgotten. Open each weekly status call with a 60-second reminder of what's in scope and what's not. This keeps the baseline fresh in stakeholders' minds before they table new requests.

2. Use it as the filter for change requests. When a stakeholder requests new work, start by checking it against the approved scope. If it's outside scope, don't say no immediately. Say, "That's outside our current scope statement. Let's assess the impact." Then run a formal change request with revised estimates. This shows good faith without silently absorbing extra work.

3. Point to the out-of-scope list by name. When someone asks for something explicitly listed as out-of-scope, reference the document: "We actually captured that in section 4 of the scope statement as out-of-scope, because adding it would require X. Do you want to open a change request?" Specificity removes ambiguity and keeps the conversation professional.

4. Treat assumption changes as scope triggers. If a stated assumption turns out to be wrong, reassess the scope immediately. Teams often absorb assumption failures silently, adjusting their work without revisiting the formal agreement. That's how scope creep sneaks in through the back door.

5. Pair it with a Gantt chart or critical path analysis. When stakeholders see the schedule impact of adding new scope, abstract objections become concrete. "If we add the CRM integration, the launch date moves from October 1 to November 14" is a far more persuasive argument than "that's out of scope."

6. Tie scope changes to budget approvals. Any change that adds work should trigger a budget review. When extra scope has a dollar amount attached, stakeholders weigh it more carefully. Small changes feel harmless in isolation; a budget line makes the cumulative cost visible.

Common mistakes

Best practices

• Write the out-of-scope section before you write in-scope. Starting with exclusions forces clarity about what the project is not, which makes the inclusions sharper.
• Keep deliverables at the right level of detail: specific enough to be unambiguous, but not so granular that they belong in the WBS. Aim for 5-15 deliverables per project.
• Version-control the document. When scope changes, update the version number and date. Keep prior versions so you can track what changed and why.
• Link the scope statement to the RACI matrix. Every deliverable should have a clear owner; if a deliverable has no owner, it's probably out of scope.
• For waterfall projects, freeze the scope statement before detailed planning begins. For agile projects, treat it as a living sprint-zero output that sets the outer boundary without locking the backlog.
• Use plain language. Scope statements fail when they're written in legalese that stakeholders skim rather than read. Write it so that a new team member could pick it up on day one and understand exactly what this project is.
• Attach the signed scope statement to every project status report so it stays visible throughout delivery.
• Review assumptions at each phase gate. If an assumption has been invalidated, surface it immediately rather than letting the team absorb the impact silently.

Frequently asked questions

What's the difference between a scope statement and a scope baseline? The scope statement is the written description of the project's boundaries: deliverables, exclusions, acceptance criteria, constraints, and assumptions. The scope baseline is the formally approved version of the scope statement plus the WBS and WBS dictionary. The baseline is what you measure performance against and what change control protects. You write the scope statement first; it becomes the baseline once it's approved.

Who writes the project scope statement? The project manager owns the scope statement, but it shouldn't be written alone. Effective scope statements are co-created with the project team (who know what's realistic to deliver), key stakeholders (who know what success looks like), and subject-matter experts (who know what's technically feasible). The PM's job is to facilitate that conversation and consolidate the outputs into a clean document.

Can the scope statement change mid-project? Yes, but only through a formal change control process. If a stakeholder identifies a legitimate need that changes the scope, the project manager evaluates the impact on cost, timeline, and resources, documents it in a change request, and gets approval before updating the scope statement. Informal scope changes are exactly how scope creep happens.

How detailed should a scope statement be? Detailed enough to eliminate ambiguity, but not so detailed that it reads like a technical specification. A good rule of thumb: if two different stakeholders could read a section and come away with different interpretations of what's included, it needs more detail. If the section is longer than two paragraphs and covers implementation specifics, it probably belongs in a separate technical document linked from the scope statement.

Is a scope statement the same as a statement of work (SOW)? No. A statement of work (SOW) is a legally binding contract between two organizations (typically a client and a vendor) that defines services to be delivered, timelines, payment terms, and obligations. A project scope statement is an internal planning document that defines what the project team will build. The SOW may inform the scope statement, but they serve different purposes and have different audiences.

Closing thoughts

The project scope statement isn't the most exciting document you'll write on a project. But it's probably the one that determines whether the project succeeds or slowly unravels. The half hour you spend writing a precise out-of-scope list at kickoff is worth far more than the hours you'll spend in scope-change negotiations six months in.

Write it early. Get it signed. Refer to it often. And when someone asks for "just one small addition," treat the scope statement as your ally, not a bureaucratic obstacle. That document is the reason the team can say yes to the right things and no to the rest.

For the next step after scope definition, build your work breakdown structure to decompose those deliverables into schedulable tasks. Then use project planning techniques to sequence and resource them before kickoff.