How to Write a Project Scope Statement (Template + Example)

Most projects that drift off course don't fail because of one big mistake. They slip a little at a time: an extra feature here, a "quick" add-on there, a stakeholder who assumed something was included when it never was. A clear project scope statement is the simplest-looking document that prevents most of that. It tells everyone, in writing, what the project will deliver, what it won't, and how you'll know it's done.

This guide walks you through what a scope statement is, what to put in it, how to write one step by step, and a filled-in example you can adapt for construction, healthcare operations, or a small business project.

What is a project scope statement?

A project scope statement is a short document that defines the boundaries of a project. It describes the objective, the deliverables, the work included, the work excluded, the constraints and assumptions, and the criteria the client or sponsor will use to accept the result.

It is not the full project plan. The schedule, budget, and risk register all come later and build on top of it. Think of the scope statement as the agreement that every other planning document refers back to. When someone asks "is this part of the job?", the scope statement is where you look first.

Scope statement vs. project charter vs. SOW

• Project charter: authorizes the project and names the sponsor and project manager. It is high level and usually written before detailed planning starts.
• Scope statement: describes in practical detail what will and won't be delivered. It is written during planning and is used by the whole team.
• Statement of work (SOW): usually part of a contract with an outside vendor or client. It often contains scope information, plus commercial terms like payment and timelines.

On smaller projects these can blur together, and that's fine. What matters is that the scope is written down and agreed, whatever you call the document.

Why a scope statement matters

• It prevents scope creep. New requests can be compared against an agreed baseline instead of debated from memory.
• It makes estimates realistic. You can only estimate time and cost for work you have defined.
• It aligns expectations. Clients, managers, and crews read the same description of "done".
• It feeds the rest of the plan. Deliverables become the top level of your work breakdown structure, which becomes tasks on your schedule.
• It protects the team. When an out-of-scope request arrives, you have a neutral document to point to rather than a personal disagreement.

What to include in a project scope statement

A useful scope statement usually fits on one to three pages. These are the sections that do the real work:

1. Project objective: one or two sentences on why the project exists and what outcome it should produce.
2. Deliverables: the tangible results the project hands over, such as a finished room, a trained team, a launched website, or a written procedure.
3. In-scope work: the main activities needed to produce those deliverables.
4. Out-of-scope work (exclusions): things people might reasonably assume are included but are not.
5. Acceptance criteria: how the sponsor or client will decide each deliverable is complete and acceptable.
6. Constraints: fixed limits such as budget ceilings, deadlines, working hours, site access, or available staff.
7. Assumptions: things you are treating as true for planning, such as "materials are available from the usual supplier" or "the client provides content by week 2".
8. Key milestones: a handful of checkpoint dates, not the full schedule.
9. Stakeholders and approval: who signs off on the scope and who must approve changes.

How to write a scope statement in 7 steps

1. Start with the objective

Write a single sentence that answers "why are we doing this?" Keep it specific and outcome focused. "Renovate the clinic waiting area to seat more patients and meet the new layout plan by March 31" is far more useful than "improve the waiting area".

2. List the deliverables

Ask what will physically or digitally exist when the project is finished. Each deliverable should be something you could point at or hand over. If you can't picture it, it's probably an activity rather than a deliverable.

3. Describe the work that's included

For each deliverable, note the major pieces of work required. You don't need every task yet; that comes when you build the work breakdown structure. Aim for enough detail that someone new to the project would understand the size of the job.

4. Write the exclusions explicitly

This is the section people skip, and it is often the most valuable. Think about what a client or colleague might assume is included. Furniture? Signage? Staff training? Data migration? Ongoing maintenance? If it isn't included, say so plainly.

5. Define acceptance criteria

For each deliverable, describe what "accepted" looks like. Good criteria are observable: "all fixtures installed and passing the final walk-through", "procedure document reviewed and signed by the department lead", "website pages load correctly on phone and desktop". Avoid vague words like "high quality" without saying how quality will be checked.

6. Record constraints and assumptions

Constraints are limits you must work within. Assumptions are beliefs you're planning around that could turn out to be wrong. Every assumption is a possible risk, so it's worth copying the shaky ones into your risk register as you go.

7. Review and get sign-off

Walk through the draft with the sponsor, the client, and the people who will do the work. Crews and frontline staff often spot missing work that managers overlook. Once everyone agrees, record who approved it and when, and agree on how future changes will be requested and approved.

Project scope statement example

The example below is a made-up illustration for a small business project. Adapt the headings and level of detail to your own work.

• Project: Retail shop refresh
• Objective: Refresh the shop floor layout and lighting so the store can reopen with the new product range before the holiday season.
• Deliverables: new shelving layout installed; LED lighting replaced on the shop floor; repainted walls; updated window display; staff briefed on the new layout.
• In scope: removing old shelving, installing new shelving units, electrical work for shop-floor lighting, painting, window display design and setup, a one-hour staff walk-through.
• Out of scope: stockroom changes, point-of-sale system upgrades, exterior signage, online store updates, restocking products.
• Acceptance criteria: shelving matches the approved floor plan; all shop-floor lights working; paint finished with no visible patches; owner approves the window display; all staff have attended the walk-through.
• Constraints: fixed budget agreed with the owner; work only outside opening hours; shop must reopen by the agreed date.
• Assumptions: shelving delivered by the end of week 1; no hidden electrical issues behind existing fittings; the owner approves designs within two working days.
• Key milestones: design approved; shelving delivered; installation complete; final walk-through and reopening.
• Approval: shop owner (sponsor); changes approved by the owner and project lead together.

Scope statement tips for different teams

Construction and field teams

Be precise about site boundaries, who supplies which materials, and which trades are included. Exclusions like "permits handled by the owner" or "landscaping not included" save a lot of arguments later. Tie acceptance criteria to inspections or walk-throughs.

Healthcare operations

For projects like moving a department, rolling out a new intake process, or reorganizing a supply room, spell out which units, shifts, and roles are affected. Note operational constraints such as keeping services running during the change, and name who signs off on new procedures.

Small businesses

Small teams often skip formal documents, but a one-page scope statement is quick to write and makes conversations with contractors, freelancers, and partners much clearer. Keep it short and focus on deliverables and exclusions.

Project managers on multi-team projects

When several teams contribute, add a line per deliverable naming the responsible team. A RACI matrix can sit alongside the scope statement to clarify who is accountable for what.

Common scope statement mistakes

• Listing activities instead of deliverables. "Hold meetings" isn't a deliverable; "approved floor plan" is.
• Leaving out exclusions. Silence gets read as "probably included".
• Vague acceptance criteria. If two people could disagree about whether it's done, the criteria need more detail.
• Treating it as fixed forever. Scope can change, but it should change through an agreed process, with the schedule and budget updated to match.
• Writing it alone. The people doing the work are the best source of missing items.

Turning your scope into a plan with GanttMaster

Once your scope statement is agreed, the next step is turning it into work people can actually schedule and track. GanttMaster is our iPhone and iPad project manager, and it fits naturally at this stage:

• Deliverables become tasks, work becomes subtasks. Create a task for each deliverable and break the in-scope work into subtasks with start and due dates, priorities, and an assigned user or team.
• Sequence the work on the Gantt chart. Link tasks with Finish-to-Start, Start-to-Start, and Finish-to-Finish dependencies and see the whole timeline at a glance.
• Add your key milestones as short checkpoint tasks. Link them to the work they depend on so they move when the schedule does.
• Carry assumptions into risk tracking. Log shaky assumptions as project risks with likelihood, impact, an owner, and a mitigation plan.
• Keep the budget constraint visible. Set a project budget, record expenses by category, and watch the remaining amount as work progresses.
• Reuse what works. Project templates let you start similar projects from an existing structure of tasks and subtasks.
• Keep the whole team on board. Assign tasks, add comments and file links (for example, a link to the signed scope document), and get notifications on updates, with no extra cost per team member.

Final thoughts

A project scope statement doesn't need to be long or formal to be effective. If it clearly states the objective, the deliverables, what's excluded, and how success will be judged, and the right people have agreed to it, you've removed one of the most common sources of project friction. Write it early, keep it where the team can find it, and come back to it whenever a new request appears.