Scope of work template (short form, for projects under $25k)

Most small projects go wrong on paper before they go wrong in practice. The proposal says “new marketing site” and a price. Both sides sign. Six weeks later you are arguing about whether “site” included the blog migration.

A scope of work exists to make that argument impossible. The version below is the short form I use for fixed-fee work under about $25,000, where a ten-page contract would cost more goodwill than it saves. It fits on two pages when filled in. Copy it, adapt it, and send it. If you want the reasoning behind why vague scopes cost so much, the scope creep pillar has the arithmetic.

Scope of work versus statement of work

The two terms get used as if they were the same thing. They overlap, and the difference is practical.

A scope of work answers one question: what exactly is being done? It lists deliverables, limits, exclusions, and assumptions.

A statement of work, usually shortened to SOW, is the complete commercial document for one project. It contains the scope of work as a section and adds everything else: detailed acceptance procedure, payment milestones, intellectual property, warranties, staffing, and how it relates to the master agreement above it.

Use the short form when the client is a small or mid-sized business, the decision-maker is the person you are talking to, and the fee is small enough that neither side wants lawyers involved. Move up to the full statement of work template when the fee passes $25,000, when the client has a procurement process, or when the work involves custom software the client will depend on for years. If you expect repeat projects with the same client, sign a master services agreement once and hang short scopes under it. That combination is the fastest way to start follow-on work.

What each section does

Section 1: the outcome

One or two sentences in the client’s words about why they are spending the money. The second clause states that the outcome is context and the deliverables are the commitment:

The outcome in clause 1.1 explains why we are doing the work. It is not a deliverable and we do not guarantee it.

You want the outcome on the page because it is the yardstick for every later change request. “Does this get you closer to the thing you wrote in section 1?” is a useful question to be able to ask.

Section 2: deliverables

A table with four columns: number, deliverable, what “done” means, and quantity or limit. The last two columns are where most scopes fall short.

Compare two ways of writing the same line:

Any deliverable that can multiply needs a number: pages, templates, user roles, reports, languages, integrations, endpoints, training sessions, revision rounds. If you cannot put a number on it, you are selling discovery, and you should scope and price a discovery phase first.

The revision clause deserves attention:

A round is one consolidated list of changes, sent in writing by your project contact, within the review period.

“Consolidated” and “by your project contact” are the words that matter. They stop feedback arriving in fragments from five people over three weeks.

Section 3: exclusions

The list of things you will not do. I consider it the most valuable part of the document and the part most often missing. Write it for the specific project. After the sales calls you already know which topics are going to come up: the old blog posts, the second language, the thing the founder mentioned in passing. Put them here now.

Clients almost never object to an exclusion before signing. When one does, you have found a disagreement about scope before a single hour was spent, and you can add the item with a price.

Section 4: assumptions

Facts the price relies on that you do not control or have not verified. Content arrives by a date. The third-party API behaves as documented. One person can approve. If an assumption fails, the clause routes the consequence into the change process so it does not come out of your margin by default.

Keep this list to four or five precise items. A long list of vague assumptions reads like an escape hatch, and a sensible client will strike it.

Section 5: client responsibilities

The named project contact, the materials and access you need, the review turnaround, and what happens when the client goes quiet. The delay clause is one clients read twice:

If we are waiting on you for more than 5 business days past a date in this document, the timeline moves out by at least the length of the delay, and we may reschedule the remaining work around our other commitments.

Without it, a client can vanish for a month and expect your team to be free the morning they return. Agreeing who the contact is and when materials are due is also the main business of the project kickoff meeting, so the two documents reinforce each other.

Section 6: timeline and acceptance

Milestones with dates, and three ways a deliverable becomes accepted: written approval, use in production, or five business days of silence. Deemed acceptance by silence is what gives the project an end. It is also what makes your final invoice due on a date you can predict.

The warranty clause draws the line between a defect and a new request. A defect is a deliverable that does not work as section 2 describes. Anything else is a change.

Section 7: changes

The clause that makes the rest enforceable:

We do not start work on a change until your project contact has approved the change request in writing.

Everything in sections 2 to 4 defines the boundary. Section 7 says what happens at the boundary. In practice you will run this clause through a one-page form, and the change request process page has that form and the steps for using it.

Section 8: fee and payment

One fixed number, a deposit before work starts, and the balance before handover. For a small project, half up front and half on delivery is simple and fair. The final payment arriving before you hand over files and access is your only practical protection on a job this size.

A fixed fee only works when the scope is tight enough to estimate. If you filled in section 2 and felt unsure about half the lines, consider whether this project should be time and materials instead, or run the numbers through the fixed price risk calculator to see how much contingency the fee needs.

Section 9: fallback terms

Five short clauses on ownership, confidentiality, liability, portfolio rights, and governing law. They apply only when no other agreement exists between you. The ownership clause passes the deliverables to the client on full payment and keeps your pre-existing tools and methods with you. Delete the whole section when the scope sits under a master agreement, so the two documents cannot contradict each other.

One jurisdiction note: the late-payment interest in section 8 is drafted for the US. The UK has statutory interest on late commercial payments, so a UK version can refer to the statutory rate.

How to fill it in without wasting an afternoon

Write section 2 first and section 3 immediately after, while the sales conversations are fresh. Then price. Many owners price first and write the scope to fit, which is how a deliverable ends up with no limit on it.

Keep a master copy with your standard exclusions, assumptions, and terms already in place, and change only sections 1, 2, 6, and 8 per project.

Send the scope as a document to sign. A scope pasted into an email body tends to get a reply of “looks good”, which is weaker than a signature and easier to dispute.

After signing, the scope should be read aloud once, at kickoff, to everyone who will work on the project. A scope known only to the two people who negotiated it protects nobody. The Scope hub explains how the scope, the change form, and the kickoff work as a set, and the other templates are collected on the templates page.