Statement of work template for software projects, with clause-by-clause notes

The statement of work is the document that decides whether a project makes money. The master services agreement protects you in a dispute. The SOW prevents the dispute, because it is the only place where anyone wrote down what “done” means.

I learned this on a fixed-fee build where the SOW had a paragraph of description and a price. The client’s understanding of that paragraph grew every week. Ours stayed where it was. By the end we had built roughly one and a half projects for the price of one, and there was nothing in the document I could point to and say “this was never included”.

The template below is the SOW I wish I had sent. It assumes you have a master services agreement in place with the client. If you do not, read the section on that further down before you use it.

What a statement of work has to do

A SOW has three readers, and each one needs something different from it.

The client’s project lead needs to know what they are getting and when. The deliverables table and the milestones are for them.

Your own team needs to know where the work stops. The out of scope list and the assumptions are for them. A developer who has read the SOW can say “that is a change request” in a meeting with confidence. A developer who has not will say “sure, we can do that”.

The third reader is whoever opens the document eight months later when something has gone wrong. That might be the client’s finance director, a new project lead who inherited the job, or a lawyer. That reader was in none of the meetings. Everything they will ever know about what was agreed is on the page.

Write for the third reader. If a stranger could read the SOW and tell whether a given feature was included, the document is doing its job.

How the SOW sits under an MSA

The template opens by tying itself to a master services agreement. That structure splits the contract in two.

The benefit shows up on the second project. The legal terms are already agreed, so the new SOW can be reviewed by the people running the project and signed in days. Without an MSA, every project reopens the argument about liability caps.

The rule that holds the two together is order of precedence. Section 11.2 of the template says the MSA wins if the two documents conflict, unless the SOW overrides a section of the MSA by name:

If this SOW conflicts with the MSA, the MSA prevails, except where this SOW names a section of the MSA and states that it is overridden for this SOW.

Clients sometimes ask for the opposite, with the SOW prevailing. Resist that. SOWs are written quickly by people who are thinking about features. You do not want a loosely worded line in a deliverables table to rewrite your limitation of liability by accident.

If you are doing a single project and the client does not want two documents, use a combined contract. I cover that format in the guide to the software development agreement. Do not send this SOW on its own with no agreement behind it. It deliberately leaves out liability, confidentiality, termination and the full IP terms, because it expects the MSA to supply them.

Statement of work vs scope of work

The two terms get used as if they were the same thing. They overlap, and the difference matters when you decide which one to send.

A scope of work describes the work: what is included, what is excluded, what the client provides. A statement of work is the whole commercial document for a project. It contains a scope of work, in sections 2 to 4 of the template, and adds milestones, acceptance, fees, payment schedule, change control and signatures.

For small jobs the full SOW is more process than the work can carry. A client buying a $9,000 audit does not want an eight-page document with an escalation table. Use the short-form scope of work template for those, and keep the SOW for projects where a misunderstanding would cost you more than a week.

The template, clause by clause

1. Project summary

Two or three sentences on what the client wants to achieve. It reads like filler and it earns its place. When a dispute arises over an ambiguous deliverable, the purpose statement is what both sides fall back on to interpret it.

Section 1.3 states the pricing model in one line. Everything after it reads differently depending on the answer. On a fixed fee, the deliverables table is the boundary of what the client gets for the price. On time and materials, the deliverables are a plan and the budget is the limit. If you have not settled which model fits the project, work through fixed price vs time and materials before you write anything else.

2. Deliverables

The table has four columns, and the fourth is the one most SOWs leave out: acceptance criteria. Each deliverable needs a test that someone outside the project could run and get the same result as you.

Writing the criteria is tedious, and it is the most valuable hour you will spend on the document. It is how you discover that “reporting dashboard” meant six reports to you and thirty to the client. Better to find that out before you have priced it.

Section 2.3 lists the environments you will test on. Section 2.5 closes the list:

The Deliverables are limited to the items in section 2.1. Any item, feature or service that this SOW does not list is outside the scope of this SOW.

That sentence is the legal backstop. The out of scope list that follows is the practical one.

3. Out of scope

In principle, section 2.5 makes an exclusions list unnecessary. In practice, the exclusions list is what the client actually reads.

Clients arrive with assumptions they have never said out loud. Of course you will load the content. Of course it includes the mobile app. Of course you will migrate the old data. Each of those is weeks of work, and the client honestly believes it was part of the deal, because nobody told them otherwise.

The list in section 3.1 names the usual suspects: content entry, data migration, third-party costs, integrations beyond the named ones, security testing, ongoing support. Then it ends with the most important line:

[ANY FEATURE DISCUSSED DURING SALES AND DELIBERATELY LEFT OUT]

Go back through your sales notes. Anything the client mentioned and you steered out of the first phase goes here by name. If the client talked about a loyalty program in the second call and you agreed to leave it for later, write “Loyalty program” in the exclusions. Otherwise the client will remember the conversation and forget the conclusion.

A specific exclusions list is the single best defense against scope creep. It moves the awkward conversation to before signature, when it costs nothing.

4. Assumptions and client dependencies

An assumption is a condition on your price. You estimated the integration at 40 hours because you assumed the other system has a documented API. If it turns out to have a spreadsheet export and a support contact who replies weekly, your 40 hours becomes 120.

Section 4.1 lists the assumptions. Section 4.3 gives them consequences:

If an assumption proves to be wrong, or a client dependency is late or incomplete, the affected dates move by at least the length of the delay. Where the Agency needs extra effort as a result, the Agency will raise a change request under section 7.

Without 4.3, an assumptions list is commentary. With it, a failed assumption is a schedule extension and a priced change.

The dependencies table in 4.2 puts a name and a date on everything the client owes you: access, content, test accounts, sign-offs. Most late projects are late because of the client side of this table. When you send the weekly status update, report against it. The record of “content due March 3, received April 11” is what protects you when the launch date slips. Your client onboarding process should collect most of these items in the first week.

Section 4.4 is the clause clients like least. If the client is more than ten business days late with a dependency, you can move the team to other work and bring the project back when a slot opens. It sounds harsh until you have paid four salaries for three weeks while waiting for a logo.

5. Milestones and acceptance

The acceptance process is what connects finished work to an invoice. The template gives the client five business days to test each milestone, requires any rejection to be in writing and specific, and then does the important thing:

A milestone is accepted if the Client has not delivered a rejection that meets section 5.3 by the end of the Review Period. A milestone is also accepted on the date the Client uses any of its Deliverables in production or releases them to end users.

This is deemed acceptance. Without it, a client who goes quiet has blocked your payment without ever refusing anything. With it, silence is approval and the invoice goes out on day six.

Two smaller clauses stop acceptance being used as a bargaining chip. Section 5.6 says a minor defect does not prevent acceptance. Section 5.7 says a new request raised during review is a change request. Between them they close the common pattern where a client holds a milestone payment over a list that is two cosmetic bugs and eight new ideas.

6. Fees and payment schedule

Here is the schedule from the template applied to a $120,000 project:

Two things about the shape. The deposit is large enough to fund the work up to the first milestone, so you are never financing the client’s project out of your own cash. The final payment is small. If the last $12,000 arrives two months late, that is irritating. If the schedule had been 50% up front and 50% on completion, the last $60,000 would be hostage to every final request the client could think of.

Section 6.2 says work starts when the deposit lands, and the start date moves with it. Section 6.6 lets you invoice completed work if the client pauses the project for more than 30 days. Both exist because of projects that sat half-finished and unbilled while a client “regrouped internally”.

7. Change control

On a fixed fee, change control is where the margin is kept or lost. The section says four things. Changes are written down on a form. The agency prices the effect on fees and dates within three business days. Nothing starts until the form is approved. A request made in conversation does not count:

A request made in a meeting, a call or a chat message becomes an approved change only when it has been recorded on a Change Request Form and approved under this section.

Section 7.5 gives small changes a fast lane, with approval by email from the client’s project lead. Without a fast lane, your team will skip the process for small things because the paperwork feels heavier than the work. Small things are exactly where a project bleeds.

Section 7.7 deals with swaps. A client who drops a feature after you have designed it will expect a full credit toward something new. The clause credits only work not yet started.

The form itself, and how to run the conversation without sounding like a bureaucrat, are in the guide to the change request process.

8. Team and communication

The clause that matters here is 8.2: the client names one project lead whose instructions you can rely on. Projects with two or three people giving feedback will receive contradictory feedback, and every contradiction turns into rework that nobody approved. When it happens, you follow the named lead and point to the clause.

The rest of the section sets expectations: a weekly written update, a meeting, a channel, business-hours response. Section 8.5 keeps your right to change who is on the team. Clients sometimes ask to name key people. Agree to consult them first. Do not agree to a veto, or one resignation puts you in breach.

9. Intellectual property

The IP terms live in the MSA. Section 9 of the SOW repeats the position in plain language so that the people running the project understand it without opening the MSA:

The Client owns the Deliverables under this SOW once it has paid all Fees due under this SOW in full. The Agency keeps ownership of the Agency Materials and licenses them to the Client as part of the Deliverables on the terms of the MSA.

Two points are packed into that paragraph.

First, ownership moves on full payment. Until the final invoice clears, the client is running code it does not own. Agencies underuse this. It is a stronger position in a payment dispute than any late fee.

Second, you keep your own materials. Every agency brings pre-existing code to a project: a starter framework, a component library, deployment scripts, utilities written years ago and improved on every job since. Most agencies sign contracts that assign all of it to each client, because “all work product” was in the template. The client gains nothing it needs from that. It needs to run, modify and transfer the software, and the license covers all three. You lose the right to your own toolkit.

Section 9.2 asks you to list the agency materials you expect to use. Do it. A client that sees “component library, deployment scripts” on the SOW at signing has agreed to the arrangement with open eyes. The reasoning behind the position is in who owns the code, and the wording options are in the guide to the IP clause for software development.

10 and 11. Warranty, support and general terms

Thirty days of defect fixes after final acceptance, then nothing unless the client signs a support arrangement. Section 10.2 says so explicitly, because the alternative is a client who believes the project fee bought indefinite maintenance. The natural next document is a retainer agreement, and the end of the warranty period is the right moment to offer one.

Section 11.3 puts an expiry date on the offer. Your price assumed a team available now. A SOW signed three months after it was sent deserves a fresh estimate.

What clients push back on, and what to concede

Negotiation on a SOW is usually light, because the heavy terms live in the MSA. These are the requests that come up most.

The pattern in the right-hand column: trade on duration and amounts, hold on mechanisms. A longer review period costs you a few days. No deemed acceptance costs you control of your invoicing.

The mistakes that cost money

Describing the work in a paragraph. Prose scope is ambiguous by nature. Tables force you to separate one deliverable from the next and attach a test to each.

Leaving out the exclusions because they feel negative. Owners worry that a long out of scope list makes them look difficult. Clients read it as a sign that you have done this before.

Promising dates without dependencies. A launch date with no conditions attached is a guarantee. A launch date that depends on content arriving by a stated day is a plan with two parties in it.

Back-loading the payments. Any schedule where more than about a fifth of the fee waits for final sign-off gives the client a hold over you at exactly the moment the requests get vaguest.

Letting the SOW drift from reality. If the project changes and the SOW does not, the SOW stops protecting you. Every approved change request is an amendment. File them with the SOW.

Starting before signature. The client is keen, the team is free, and the SOW is “with legal”. Work done before signature is work done on the terms of an email thread. If payment goes wrong later, the steps in what to do when a client is not paying all assume a signed document exists.

Sending it

Send the SOW as a document the client can sign electronically, with the MSA attached or referenced by date. Walk the client’s project lead through sections 3, 4 and 7 on a call before they sign. Ten minutes on exclusions, assumptions and change control at this stage saves ten hours of argument later, and a client who has heard the rules explained accepts them far more easily when they apply.

Keep the signed copy, the MSA and every approved change request together in one place. That folder is the project’s commercial record.

One note for readers outside the US. The SOW itself travels well, because it is mostly commercial terms. The legal differences sit in the MSA: late payment interest, how liability caps are tested, and how IP assignments must be worded. If you work under UK or EU law, the SOW needs little adjustment and the agreement above it needs local review.

All the other documents in this set are on the contracts hub, and every template on the site is listed on the templates page.