By Ryan Kramer, founder of Wisegrid. Last updated August 2026.
A project scope statement is the internal document that defines what a project will and will not deliver: its objectives, its deliverables, its boundaries, and the criteria by which “done” will be judged. It is written for the project team and its stakeholders, not for a client contract, and its job is to get everyone agreeing on the same finish line before the work starts moving toward different ones.
This guide covers the six sections every scope statement needs, walks through a complete worked example, and separates the scope statement from the two documents it gets confused with, the scope of work and the project charter.
Key takeaways – A scope statement answers one question: what does “done” look like? Objectives say why, deliverables say what, boundaries say what is out, and acceptance criteria say how done gets checked. – The exclusions section earns its keep. Most scope arguments are about work one side assumed was included; a written not-in-scope list settles them before they start. – Assumptions are risks wearing plain clothes. Every assumption that fails becomes a schedule or budget change, so each one should be written down where it can be checked. – It is not a contract and not a charter. The scope of work is the client-facing commercial version; the charter authorizes the project. The scope statement defines the work for the team doing it. – A scope statement that stays a document fails. Its deliverables and acceptance criteria have to become the tracked plan, or the statement and the project drift apart within weeks.
What is a project scope statement?
A project scope statement is the written definition of a project’s boundaries, produced during planning and owned by the project manager. It records the objectives the project exists to hit, every deliverable it will produce, the explicit list of what is out of scope, the constraints the team must work within, the assumptions the plan depends on, and the acceptance criteria that decide when each deliverable is complete. In PMBOK-style planning it is the core output of scope definition, and the work breakdown structure is decomposed from it.
Its real function is cheaper than that description sounds: it converts a dozen slightly different mental pictures of the project into one shared picture, in writing, while disagreement is still free. Every project starts with the sponsor, the team, and the stakeholders each holding a private version of what is being built. Those versions diverge quietly until someone says “wait, I thought we were also getting X,” and by then the divergence costs money. The scope statement forces that conversation to happen in week one instead of week nine.
It also gives scope change a baseline. “Scope creep” is only detectable against a written scope; without one, every new request is just as legitimate as the original plan, because the original plan is a memory. With a scope statement, a new request is visibly a change, and changes can be assessed, priced in time, and approved or declined on purpose.
The six sections of a scope statement
Templates vary, but six sections carry the weight. If a section is missing from yours, it is usually the one the next dispute will be about.
1. Project objectives. Two to four statements of why the project exists, written so they can be checked at the end. “Launch the new onboarding flow to all customers by March 31 and cut time-to-first-value from four days to one” is an objective. “Improve the onboarding experience” is a wish. Objectives are the tiebreaker for every later scope decision: work that does not serve one of them is a candidate for the exclusions list.
2. Deliverables. The complete list of things the project will hand over, each specific enough to be counted and checked. Include the internal deliverables (test plans, documentation, training) alongside the headline ones, because unlisted deliverables get either dropped or delivered as unplanned work. Number them; the acceptance criteria and the work breakdown will both reference these numbers.
3. Boundaries and exclusions. The explicit statement of what is out of scope. Write it from experience of what people in this kind of project tend to assume: the adjacent system that will not be touched, the data that will not be migrated, the regions or user groups not covered, the support period that does not follow. This is the section teams skip because it feels negative, and it is the section that pays for the whole document. An exclusion written today is a dispute that never happens.
4. Constraints. The fixed conditions the project must operate within: the deadline that cannot move, the budget cap, the two engineers who are only available half-time, the compliance requirement, the technology mandate. Constraints are facts, not risks; the plan has to be built around them, and stating them up front stops the schedule from being negotiated against conditions nobody can change.
5. Assumptions. What the plan treats as true without proof: the vendor API will be ready by February, the sample data is representative, legal review takes two weeks, the current infrastructure can handle the new load. Every assumption is a dependency in disguise. Listing them does two things: it lets stakeholders correct the wrong ones now, and it makes the schedule impact traceable when one fails later (“dates assumed vendor delivery on Feb 1; delivery moved, dates move”).
6. Acceptance criteria. For each deliverable, the checkable conditions under which it will be accepted, and who accepts it. “Checkout flow passes the test cases in the QA plan and is approved by the product owner” is a criterion; “checkout flow works well” is an argument scheduled for the final week. This section is also where deemed-acceptance rules belong for internal projects with slow reviewers: reviewed within five business days, or it proceeds as accepted.
Some teams add a short project description and a milestone summary at the top. Both are fine and neither replaces the six above.
A worked example
A compressed but complete scope statement for an internal project, at the level of detail that actually gets written:
PROJECT SCOPE STATEMENT
Project: Customer portal self-service migration Version: 1.0
Owner: A. Rivera (PM) Sponsor: VP Customer Operations Date: 2026-09-08
1. OBJECTIVES
O1. Move password resets, invoice downloads, and plan changes into the
customer portal by Nov 30, 2026.
O2. Reduce tickets in those three categories by 60% within 60 days
of launch (baseline: 410/month).
2. DELIVERABLES
D1. Self-service flows for the three ticket categories, live for all
customers on the current portal.
D2. Help-center articles for each flow (3 articles, searchable).
D3. Support-team runbook covering the new escalation path.
D4. Launch report with 30-day and 60-day ticket-volume comparison.
3. BOUNDARIES / OUT OF SCOPE
X1. No changes to the billing engine; plan changes call existing APIs.
X2. Refund requests remain a ticketed flow.
X3. No mobile-app changes; portal web only.
X4. Legacy portal (customers not yet migrated) is not modified.
4. CONSTRAINTS
C1. Launch before the Dec 1 support-contract renewal.
C2. One backend engineer at 50% allocation until Oct 15.
C3. All customer-facing copy requires legal review.
5. ASSUMPTIONS
A1. Billing API supports plan changes without modification
(verified with platform team, 2026-09-04).
A2. Legal review turnaround is 5 business days per batch.
A3. Current auth system meets security requirements for reset flow.
6. ACCEPTANCE CRITERIA
D1: All flows pass the QA test plan; product owner sign-off;
error rate under 1% across a 2-week canary at 10% of traffic.
D2: Articles reviewed by support lead; findable for the top 5
search phrases per category.
D3: Runbook walkthrough completed with both support shifts.
D4: Report delivered within 10 business days of each checkpoint.
Approved: Sponsor ______ PM ______ Support Lead ______ Date ______Notice what the example does. Objectives carry numbers and dates. Every deliverable has at least one acceptance criterion pointing back at it. The exclusions anticipate the specific requests this project will get (“can we also do refunds?”), and the assumptions are dated and attributed where they were verified. That is the difference between a scope statement and a paragraph of good intentions.
How to write one without a committee
The document above takes a focused afternoon, not a workshop series. A sequence that works:
- Draft objectives with the sponsor first. Fifteen minutes with the person paying for the project settles why it exists. Everything else is derived from this.
- List deliverables, then derive exclusions. For each deliverable, ask “what will someone assume comes with this that does not?” That question generates most of the exclusions list.
- Pull constraints and assumptions from the people doing the work. The team knows the real allocation, the real review turnarounds, and which technical assumptions are shaky. Ten minutes per lead.
- Write acceptance criteria as if you will not be in the room. A criterion is done when a stranger could apply it and get the same answer you would.
- Circulate for objection, not wordsmithing. One round, with a deadline, asking a single question: “what here is wrong or missing?” Silence past the deadline is agreement.
- Get it signed, then version it. Unsigned scope statements protect no one, and every approved change after signing produces a new version number, not a quiet edit.
Scope statement vs scope of work vs project charter
Three documents, three jobs, endlessly conflated:
| Document | Audience | Job |
|---|---|---|
| Project charter | Sponsor and organization | Authorizes the project: names the PM, states the business case and high-level scope, grants the authority to spend |
| Project scope statement | Project team and stakeholders | Defines the work: objectives, deliverables, exclusions, constraints, assumptions, acceptance criteria |
| Scope of work (SOW) | Client and vendor | The commercial, usually contractual version: deliverables plus pricing, payment terms, and signatures |
The sequence matters: the charter comes first and authorizes planning, the scope statement is produced during planning and defines the work in detail, and a scope of work exists only when there is a client relationship to govern. The charter’s scope description is a paragraph; the scope statement is the full definition it expands into. If you need the charter itself, the project charter template has every section with the sign-off block. If your project has a client and money attached, you are writing a scope of work instead, and the scope of work template guide covers that document section by section, including the commercial terms a scope statement never carries.
The content overlap is real, which is why the confusion is. Deliverables, exclusions, and acceptance criteria appear in both the scope statement and the SOW. The reliable test is the audience: no commercial terms and an internal team means scope statement.
From scope statement to tracked scope
A scope statement is a snapshot, and projects move. The document earns its afternoon only if it becomes the structure the project is actually tracked against.
The mechanical version of that: each numbered deliverable becomes a tracked item with its acceptance criteria attached, the assumptions list becomes a set of dated check-items (an assumption is verified, or it converts into a risk), and scope changes arrive as new rows with an approval status instead of as silent edits to the plan. In Wisegrid that is one sheet: deliverables as rows with owner, status, and acceptance-criteria columns, a linked RAID log carrying the assumptions and the risks they turn into, and date-triggered automations nudging owners when a verification date or review window passes. Because every change lands as a row with a date and an author, the “how did scope grow 30%?” conversation has an answer you can scroll through rather than reconstruct.
The same grid feeds reporting: a status report built from live deliverable status is the scope statement doing its job months after it was signed, still the single agreed picture of what done looks like.
FAQ
What is a project scope statement in simple terms?
It is the written answer to “what exactly are we building, what are we not building, and how will we know it is finished?” It lists the project’s objectives, deliverables, exclusions, constraints, assumptions, and acceptance criteria, so the team and stakeholders share one definition of done before work starts.
What are the main components of a project scope statement?
Six sections: objectives (why, with measurable targets), deliverables (what will be handed over), boundaries and exclusions (what is explicitly out), constraints (fixed conditions like deadlines and budget), assumptions (what the plan treats as true), and acceptance criteria (the checkable conditions for each deliverable). Many teams add a short description and milestone summary.
Who writes the project scope statement?
The project manager writes it, during planning, with input from the sponsor (objectives), the team leads (constraints, assumptions, estimates), and key stakeholders (deliverables and exclusions). The sponsor approves it. Writing it is a drafting job for one person plus one round of structured review, not a committee exercise.
What is the difference between a project scope statement and a scope of work?
Audience and commercial content. The scope statement is internal: it defines the work for the project team and carries no pricing or legal terms. A scope of work is the client-facing version that forms part of a contract, adding commercial terms, payment schedules, and signatures. The deliverables-and-exclusions core is similar; the wrapper is different.
Is the scope statement part of the project charter?
No, it follows the charter. The charter authorizes the project and describes scope at summary level; the scope statement is produced during planning and expands that summary into the full definition: deliverables, exclusions, constraints, assumptions, and acceptance criteria. Small projects sometimes merge them into one document, which works as long as both jobs get done.
How long should a project scope statement be?
As short as completeness allows. One to three pages covers most internal projects; the worked example above is under a page and is complete. Length comes from the deliverables and exclusions lists being genuinely exhaustive, not from prose. A long scope statement nobody rereads protects the project less than a tight one everybody has actually read.
Turn the statement into the tracked plan
Put the deliverables, assumptions, and acceptance criteria into a grid the whole team works from: start with the project charter template if the project is not yet authorized, keep the risks and assumptions live in a RAID log, and generate stakeholder updates from real status with the free status report generator.
Start free → · Project charter template → · Scope of work guide →
About the author Ryan Kramer is the founder of Wisegrid, a higher-capacity work management grid built around a 1,000,000-cell-per-sheet limit, date-triggered automations with run history, and cross-sheet reporting. He writes about the project management documents teams actually keep updated. More from Ryan →