How to Write a Scope of Work

A scope of work is the single most important document in any client project. It defines what you'll deliver, when, and for how much. Here's how to write one that prevents scope creep, sets clear expectations, and protects your profitability.

What Is a Scope of Work?

A scope of work (SOW) is a document that outlines what work will be done, what the deliverables are, and the timeline and budget for completing them. It's the contract between expectations and reality — the thing both you and your client point to when someone asks "was this included?"

Every project that goes sideways can trace the problem back to a missing or vague scope of work. The client expected revisions that weren't budgeted. The timeline assumed content would arrive on time. The "small addition" turned into two extra weeks of development. A well-written SOW prevents all of this.

Whether you're a solo freelancer or running a 50-person agency, the SOW is the document that keeps projects profitable and relationships intact.

SOW vs Statement of Work vs Project Brief

These three documents get confused constantly. Here's the difference:

• Scope of work (SOW): What you'll deliver, the timeline, and the budget. It's the working agreement that both parties reference throughout the project.
• Statement of work: A more formal, contract-adjacent document that includes everything in the SOW plus legal terms, termination clauses, intellectual property provisions, and detailed acceptance criteria. If the SOW is a handshake, the statement of work is the notarized version. Use the statement of work template for these engagements.
• Project brief: A high-level overview of the project goals, audience, and context. It's an input to the SOW, not a replacement for it. You might receive a project brief from the client, then write the SOW based on what it contains.

When to use which: most agency and freelance projects need a SOW at minimum. Complex or high-value engagements — anything over $25,000 or involving legal considerations — warrant a full statement of work.

Step 1: Define Project Objectives

Start with why the project exists. Write 3–5 measurable objectives that define what success looks like. Not vague aspirations — concrete outcomes.

Bad: "Redesign the website."

Good: "Redesign the marketing website to increase conversion rate from 2.1% to 3.5%, launch by June 1, 2026."

Each objective should answer three questions: what are we doing, for whom, and how will we measure success?

Here's an example objectives section for a website redesign:

1. Increase lead form submissions by 40% within 90 days of launch.
2. Reduce average page load time to under 2 seconds on mobile.
3. Launch the redesigned site by June 1, 2026, with all 12 core pages live.
4. Achieve WCAG 2.1 AA compliance across all public-facing pages.

These objectives give both parties a clear target. When the client asks for an animated homepage hero three weeks into the project, you can evaluate it against the objectives: does it serve one of these four goals? If not, it's a change order.

Step 2: List All Deliverables

A deliverable is a tangible output the client will receive. Be specific about every one of them — quantities, dimensions, formats, file types. Ambiguity here is where scope creep starts.

Instead of: "Logo design"

Write: "Primary logo (full color, monochrome, reversed) in SVG, PNG (3 sizes), and EPS formats. Includes one primary mark and one icon variant."

Instead of: "Website development"

Write: "12-page responsive website built on WordPress, including: homepage, about, services (4 pages), blog index, blog single, contact, privacy policy, and terms of service. Includes mobile-responsive layouts for all pages."

The golden rule: if you can't point to it as a file, mockup, or artifact, it's not a deliverable. "Strategy" isn't a deliverable. A "Brand Strategy Document (PDF, 15–20 pages)" is.

Step 3: Set the Timeline and Milestones

Break the project into phases. A typical structure looks like this:

Include client review periods in the timeline — these are where projects usually stall. If the client takes two weeks to review designs instead of three days, the launch date moves. Make this explicit.

Add buffer. Every project has unknowns. Build in 10–15% additional time for things you can't predict. If the project is 10 weeks, plan for 11.

Step 4: Define the Budget

Be explicit about the pricing model: fixed price, hourly, or retainer. Don't leave room for assumptions.

For fixed-price projects, break the budget down by phase and tie payments to milestones:

• Discovery phase: $2,500 (due upon SOW signing)
• Design phase: $5,000 (due upon design approval)
• Development phase: $7,500 (due upon staging site delivery)
• QA & Launch: $2,500 (due upon launch)

State what's included and what triggers additional costs. For example: "Design phase includes up to 2 revision rounds per deliverable. Additional revisions billed at $150/hour." This one sentence has saved more agency-client relationships than any contract clause.

For hourly engagements, define the estimated range, the billing frequency, and what happens if the estimate is exceeded. The client should never be surprised by an invoice.

Step 5: State Assumptions and Exclusions

Assumptions are things you're taking for granted. If any of them turn out to be wrong, the scope, timeline, or budget may change.

Example assumptions:

• Client will provide all written content by April 15, 2026.
• The existing hosting environment supports PHP 8.2 and MySQL 8.0.
• Client has admin access to all third-party accounts (DNS, analytics, CMS).
• Feedback will be consolidated into a single point of contact.

Exclusions are what is NOT included. This section is critical — it draws the boundary of your responsibility.

Example exclusions: "This scope does not include: content writing, stock photography licensing, ongoing maintenance after launch, SEO, email marketing setup, or third-party integrations beyond the Stripe payment API."

The principle is simple: if it's not explicitly included in the deliverables, it's excluded. State this clearly so there's no ambiguity.

Step 6: Add Acceptance Criteria

Define how each deliverable will be reviewed and approved:

• Review rounds: How many are included per deliverable (typically 2).
• Feedback window: How long the client has to provide feedback (typically 3–5 business days).
• Late feedback: What happens if feedback doesn't arrive on time — the timeline shifts accordingly.
• Approval method: Written sign-off via email or project management tool. Verbal approval doesn't count.
• Post-approval changes: Once a deliverable is approved, changes become change orders with separate pricing and timelines. Use a change order template to handle these cleanly.

The acceptance criteria protect both sides. The client knows exactly how the review process works. You know that "approved" means approved — not "approved but actually we have more changes."

Step 7: Get Sign-off

A SOW nobody signed is just a wish list. Both parties sign the document before any work begins.

Include:

• Full name and title of the signer from each party
• Date of signature
• A statement confirming that both parties agree to the terms outlined in the SOW

Digital signatures through tools like DocuSign or HelloSign are perfectly valid. What matters is that there's a clear, documented moment where both sides said "yes, this is what we're doing."

The signed SOW becomes your reference document for the entire project. Every question about scope, timeline, or budget gets answered by pointing back to it.

Common Mistakes to Avoid

• Being too vague. "Design work" means anything to anyone. Specify exactly what you're designing, how many variations, and in what format.
• Missing exclusions. If you don't list what's out, everything is in — at least in the client's mind.
• No change process. How do you handle requests outside the scope? Define this upfront. A simple sentence like "out-of-scope requests will be handled via change orders" saves weeks of negotiation later.
• Skipping the sign-off. Without signatures, the SOW is a suggestion. Get it signed before you start work.
• One-size-fits-all. A $2,000 project and a $50,000 project don't need the same SOW depth. Scale the document to the engagement. A small project might need a one-page SOW. An enterprise engagement might need ten pages with appendices.

When to Use a Full Statement of Work Instead

Some projects need more than a scope of work. Consider a full statement of work when:

• The project budget exceeds $25,000 or the timeline is longer than 3 months.
• You're working with enterprise clients who require legal terms and liability clauses.
• The engagement involves intellectual property transfer or confidential information.
• Multiple phases will be billed separately with distinct approval gates.
• Subcontractors or third parties are involved in delivery.

A statement of work includes everything in a SOW plus legal protections, termination clauses, and detailed governance. Use the statement of work template for these situations.

Get the Template

Download the free scope of work template to get started immediately. It covers all seven sections above with fill-in-the-blank formatting so you can adapt it to any project in minutes.

Or manage scope, time, and invoicing in one place with Corcava. See how scope management fits into the full profitability lifecycle →