Project scope statement template
A project scope statement says what a project will deliver and what it will not: the objective, the deliverables, what is in and out of scope, the assumptions and constraints, and how the result will be accepted — so that every later request can be checked against it. Below are what to include, a template, a filled-in example for a software project, how to write the out-of-scope list, how to write the statement, and how it differs from a project charter, a statement of work and a WBS.
Asset prep is in or out. Writing product descriptions is in or out. If it’s out of scope, price it.
— r/web_design, 2026
In the PMBOK Guide’s terms, the project scope statement describes the project’s scope, its major deliverables, its assumptions and its constraints, and is part of the scope baseline (Wikipedia). Karl Wiegers’ vision and scope template gives the reason to write it down: the scope “provides a reference frame against which proposed features and requirements changes can be evaluated” (Software Requirements Essentials, template downloads).
What a project scope statement includes
| Section | What goes in it |
|---|---|
| Objective | The business problem, and how success will be measured |
| Deliverables | What the client receives: software, documents, training, access |
| In scope | Features, users, systems and data the project covers |
| Out of scope | What someone might expect, but will not get |
| Later | What is planned for a later phase, not this one |
| Assumptions | What is taken as true, and who provides what by when |
| Constraints | Fixed dates, budget, technology, rules |
| Acceptance | How each deliverable is accepted, and by whom |
| Changes | How the scope changes once it is agreed |
| Agreed by | Names, roles, date and version |
A scope statement has no price, payment terms or warranty: those belong in the statement of work, which points to the scope.
Project scope statement template
Copy it into a document; square brackets are yours to fill in.
PROJECT SCOPE STATEMENT
Project: [name]
Client: [organization]
Version: [x.y], [date]
1. OBJECTIVE
[The business problem, and how success
is measured]
2. DELIVERABLES
D1 [what the client receives]
D2 [ ]
3. IN SCOPE
- [feature, user group, system, data]
4. OUT OF SCOPE
- [what someone might expect, but will
not get in this project]
5. LATER
- [planned for a later phase]
6. ASSUMPTIONS
- [what is taken as true; who
provides what, by when]
7. CONSTRAINTS
- [dates, budget, technology, rules]
8. ACCEPTANCE
[How each deliverable is accepted,
and by whom]
9. CHANGES
A change to sections 2 to 5 is a
change request: impact, cost and
dates, approved in writing.
AGREED BY
Client: [name, role] [date]
Supplier: [name, role] [date]
Project scope statement example
The customer portal from the other templates, where customers see and pay their company’s invoices. This is phase 1, agreed with the first signed version of the requirements.
PROJECT SCOPE STATEMENT
Project: Customer portal, phase 1
Version: 1.0, 28 January
1. OBJECTIVE
Shorten the time invoices stay unpaid
(BR-03): customers see their invoices
and pay them by card.
2. DELIVERABLES
D1 The portal, live
D2 Admin and support guide
D3 Training for the accounts team
D4 Code, scripts and accounts, handed
over
3. IN SCOPE
- Sign-in for customers' staff
- Invoice list and PDF download
- Paying an open invoice by card
- Email receipt; one payment reminder
- Only the Billing role can pay
- Performance: NFR-007
4. OUT OF SCOPE
- Paying part of an invoice
- Languages other than English
- A mobile app
- Changes to the accounting system
5. LATER
- Saved cards: decide in phase 2
6. ASSUMPTIONS
- The client opens the payment
provider account by 15 February
- The finance lead answers questions
within 3 working days
- Invoices come from the accounting
system's daily export
7. CONSTRAINTS
- Live by the end of May
- Card data is never stored by the
portal
8. ACCEPTANCE
D1: user acceptance testing by the
accounts team, against requirements
1.0. D2 to D4: review by the finance
lead.
9. CHANGES
Change requests, approved by the
client's product owner.
AGREED BY
Client: Finance lead 28 Jan
Supplier: Delivery lead 28 Jan
In the months that followed, each request that came in could be checked against it. A blog on the portal (CR-6) did nothing for the objective; it was priced and declined. Invoices in French (CR-9) and paying part of an invoice (CR-10) were both on the out-of-scope list, so each became a change request with its own cost and dates, not an argument about what had been promised. The constraint on card data led to the hosted payment page in the technical specification.
In scope vs out of scope: writing the out-of-scope list
The in-scope list is the easy half; the out-of-scope list prevents the arguments. Wiegers’ instruction for it: “Identify any product features or characteristics that a stakeholder might anticipate, but which are not planned to be included in the new product.”
Places to look for what someone might anticipate:
- What competitors and the old system do. If the old system kept cards on file, someone will expect saved cards.
- Neighbouring systems. The accounting system, the CRM, the website: what changes there, and who changes it.
- Data. Old records to migrate, how far back, and who cleans them.
- Languages, devices and browsers. “Customers abroad” can mean translations.
- Content and assets. Who writes the text, who supplies the images.
- Everything after go-live. Hosting, support, training for new staff.
Then read the list to the client. One commenter’s advice from 2011 still holds: write down every feature, “Then show it to the client to make sure nothing has been missed or out of scope” (Hacker News).
How to write a project scope statement
- Start from the objective. One sentence of business problem and one measure of success. A request that does nothing for the objective is the easiest to decline.
- List the deliverables — what the client will hold at the end, including documents, training and access, not only software.
- Draw the boundary. Wiegers’ checklist for defining solution boundaries asks: “Which business processes, functions, data, and events will be part of the solution? Which ones will remain outside it?” and, last, “How do we know where to stop?”
- Write out of scope with the client, from what they might expect, not only from what you decided to leave out.
- Give each assumption an owner and a date. An assumption that turns out false changes the scope, and everyone should be able to see when it did.
- Say how each deliverable is accepted. The detail can live in the requirements and the UAT test plan; the scope statement names who accepts what.
- Say how the scope changes: a change request, an impact analysis for anything large, and who approves it.
- Agree it, and give it a version. The signed scope statement is part of the scope baseline that later changes are measured against.
Scope statement vs project charter vs SOW vs WBS
| Document | What it does | Detail |
|---|---|---|
| Project charter | Starts the project: why, who sponsors it, high-level scope and budget | Low |
| Vision and scope document | Sets the business objectives and which features go in which release | Low |
| Project scope statement | Fixes what is delivered and what is not | Medium |
| Statement of work | Makes it a contract: scope plus price, schedule and acceptance terms | Medium |
| Work breakdown structure (WBS) | Breaks the scope into packages of work | High |
| Requirements document | Says what the product must do | High |
On a small project, the scope statement is often a section of the statement of work. On a larger one, or an internal one with no contract, it stands on its own, and the SRS or BRD holds the detail it refers to.
Product scope vs project scope
Product scope is what the product does: its features, such as paying an invoice by card. Project scope is all the work needed to deliver it, including work that produces no feature — the support guide, the training, the handover in the example above. A scope statement covers both; the features are easy to remember, and the rest is easy to forget until it is missing.
Scope statements in agile projects
On an agile project, time and budget are often fixed and the scope is what flexes. A scope statement still has a job: the objective, the boundaries and the out-of-scope list do not change from sprint to sprint, while the backlog does. Wiegers’ template splits scope into the initial release and later ones — “indicate which major features will be deferred to later releases” — which fits release planning, and the MoSCoW categories fit inside each release.
When the scope changes
An agreed scope does not mean nothing changes; it means every change is visible. One commenter: “it’s common that some requirements change a little or get dropped in a way that makes your life easier. It’s great when both sides can be reasonable and non-adversarial about it all” (Hacker News, 2022).
For a request that is out of scope, one commenter’s favourite sentence (credited to Karl Sakas): “I can absolutely do [XYZ] but unfortunately it’s out of scope. Would you like me to give you a quote to include it?” (r/agency, 2025). The answer becomes a change request, the scope statement gets a new version, and the scope creep that starts with an unrecorded yes does not.
Where Specroot fits
This is the problem Specroot works on: the agreed scope kept with its version and its sign-off, so a request can be checked against what was actually agreed — in scope, out of scope or later — instead of against what each side remembers. Specroot for agencies and consultancies.
Read next
- Statement of work template for software development — A free statement of work template for software projects, what a SOW should include, SOW vs scope of work vs MSA, and clauses for acceptance and changes.
- Scope creep in software projects — Scope creep is work added to a project without a decision about what it costs. Examples from software projects, what causes it, and how to stop it.
- Change request template for software projects — A free change request template for software projects, with a filled-in example, a change request log, and the email that asks the client for a decision.