Scope of Work & Project Scope Template
A combined SOW and project scope template that reduces ambiguity—project objectives, deliverables, milestones, budget, team roles, assumptions, constraints, acceptance criteria, and sign-off. Two versions: plain-English and formal.
What You'll Get
- Plain-English version — Conversational tone for clients who prefer straightforward language
- Formal version — Professional language for enterprise clients or legal requirements
- Deliverables table — Clear listing of what's being delivered
- Assumptions & dependencies — What needs to be true for this to work
- Out of scope section — Explicit exclusions to prevent misunderstandings
- Change process section — How to handle scope changes
Download the Template
Get the scope of work template in PDF format.
No email required. Free to use and share.
Project Scope Template Preview
Use this structure to define the full scope of any project before work begins. Each field maps to a section in the downloadable template.
Defining "Out of Scope" (With Examples)
The most important part of your SOW is what's NOT included. Be explicit:
Website Redesign Example
In scope: Homepage, About, Services, Contact page designs (4 pages total)
Out of scope: Blog template, e-commerce functionality, copywriting, photography, SEO optimization, hosting setup, content migration
Brand Identity Example
In scope: Logo (primary + icon), color palette, typography selection, basic brand guidelines (10 pages)
Out of scope: Brand strategy/positioning, tagline development, extended guidelines, business card design, website design, social media templates
Marketing Campaign Example
In scope: Campaign strategy, 3 ad concepts, 1 landing page design, campaign setup in ad platform
Out of scope: Ongoing optimization, ad spend management, landing page development, copywriting beyond headlines, A/B testing beyond initial setup
How Change Requests Connect
Your SOW should explain what happens when scope needs to change:
"Changes to this scope will be documented using a Change Request Form. The client will receive impact assessment (time, cost, timeline) and must approve before work proceeds. Minor clarifications within the spirit of this scope require no formal change request."
Link to your Change Request Form in the SOW.
How to Use This Template
- 1
Start with the discovery call notes
Use information from your Creative Brief or discovery to populate the SOW.
- 2
Fill in deliverables first
Be specific: "5-page website" not "website redesign." Include quantities, formats, and specs.
- 3
Write the out-of-scope section
Think about what the client might assume is included but isn't. List those things explicitly.
- 4
Document assumptions
"Client will provide copy by X date." "Assumes access to Y platform." If these aren't met, scope changes.
- 5
Review with the client
Walk through the SOW together. Don't just send it—discuss it to ensure alignment.
Common Mistakes & How to Avoid Them
Being vague about deliverables
"Logo design" is vague. "Primary logo + icon variant, delivered in AI, EPS, PNG, SVG formats" is specific.
Skipping the out-of-scope section
If you don't say what's excluded, clients will assume it's included. Always have explicit exclusions.
Not defining acceptance criteria
"Approved by client" is subjective. "Client provides written approval within 5 business days" is measurable.
Ignoring dependencies
If you need client content, API access, or third-party assets, list them. Timeline delays from missing dependencies aren't your fault if documented.
What Is a Project Scope?
A project scope defines the boundaries of a project: what will be delivered, who is involved, how long it will take, and what it will cost. It's the single document that everyone—client, project manager, and team—refers back to when questions about "is this included?" come up.
Without a documented scope, projects drift. Features get added without adjusting timelines. Budgets overflow because assumptions were never written down. Teams work on things the client didn't ask for while missing things they did.
A project scope statement turns verbal agreements into a written record. It protects both sides: the client knows exactly what they're paying for, and the provider knows exactly what they need to deliver.
What to Include in a Project Scope Document
A complete project scope document covers twelve areas. The template preview above follows this structure:
1. Project name
Clear, descriptive title everyone can reference.
2. Description
One-paragraph summary of what the project is and why it exists.
3. Objectives
Measurable outcomes that define success.
4. Deliverables
Specific outputs with quantities, formats, and specs.
5. Milestones
Key checkpoints and review gates.
6. Timeline
Start/end dates and phase durations.
7. Budget
Total cost, payment schedule, and payment triggers.
8. Team roles
Who does what on both sides.
9. Assumptions
Conditions that must be true for the project to proceed as planned.
10. Constraints
Hard limits: regulatory, technical, or deadline-driven.
11. Acceptance criteria
How "done" is defined and measured.
12. Sign-off
Formal approval from both parties before work begins.
Project Scope vs Project Charter vs Scope of Work
These three documents get confused constantly. Here's how they differ:
Project Scope Statement
Defines what will be delivered and what won't. Focuses on deliverables, objectives, constraints, and acceptance criteria. Used by the project team and client to stay aligned on boundaries.
Audience: project manager, client, team leads
Project Charter
Authorizes the project to exist. Higher-level than a scope statement: it names the sponsor, states the business case, defines authority levels, and provides initial budget/timeline estimates. Typically created before detailed scoping.
Audience: executive sponsors, PMO, steering committee
Scope of Work (SOW)
A contractual document between client and provider. Includes everything in the project scope plus commercial terms: pricing, payment schedule, change process, and legal provisions. Often the document that gets signed.
Audience: client, provider, legal/procurement
In practice: For agencies and freelancers, the SOW usually contains the project scope. Enterprise organizations often create a charter first, then a detailed scope, then an SOW for vendor agreements. This template covers all three needs.
How to Run This in Corcava
- Attach SOW to the deal/project — Keep documentation connected to the work
- Create project milestones from deliverables — Turn SOW items into trackable tasks
- Share via client portal — Client can access and reference the SOW anytime
- Track changes with version history — See how scope evolved over the project
Maps to: Projects, Documents, Client Portal features
Scoping is where profit is won or lost.See how it fits into the full agency profitability lifecycle →
Frequently Asked Questions
What's the difference between an SOW and a proposal?
A proposal is a sales document—it sells the work and includes pricing, timeline, and why you're the right fit. An SOW is a project document—it defines exactly what will be delivered. The proposal may include an SOW section, or the SOW may be a separate document signed after the proposal is accepted.
What is the difference between a project scope and a scope of work?
A project scope statement defines what will be delivered, the objectives, constraints, and acceptance criteria. A scope of work (SOW) includes the project scope plus commercial terms: pricing, payment schedule, change process, and legal provisions. For agencies and freelancers, the SOW usually contains the project scope in a single document.
What should a project scope statement include?
A complete project scope statement covers: project name and description, objectives, deliverables, milestones, timeline, budget, team roles, assumptions, constraints, acceptance criteria, and sign-off. Each field should be specific enough that both parties reach the same conclusion about what's included.
Who is responsible for defining the project scope?
Typically the project manager drafts the scope based on discovery conversations, but it requires input and approval from both the client stakeholder and the delivery team. The client validates that the scope matches their expectations; the team confirms the scope is achievable within the stated timeline and budget.
Should the SOW include pricing?
It can, but doesn't have to. Some agencies include pricing in the SOW for simplicity. Others keep pricing in a separate agreement or invoice schedule. The key is that scope and price are clearly connected somewhere.
How detailed should deliverables be?
Detailed enough that both parties would reach the same conclusion about what's included. "Website" is too vague. "5-page marketing website including homepage, about, services, blog index, and contact page, responsive design, delivered as HTML/CSS" is clear.
When should I use the formal vs plain-English version?
Use formal for enterprise clients, procurement processes, or when legal review is involved. Use plain-English for startups, small businesses, and clients who value straightforward communication. When in doubt, ask what they prefer.
How do I handle scope that's hard to define upfront?
Use phases. Phase 1 can be discovery/scoping with a fixed price. Phase 2 is the actual work with scope defined after Phase 1 is complete. This protects both parties when requirements are unclear.
Should the client sign the SOW?
Yes, ideally. A signature indicates agreement. If formal signatures aren't practical, at minimum get explicit written confirmation: "Reply to this email with 'approved' to confirm you agree to this scope."