Most agencies and consultancies have a story like this: a project was scoped at £30k, the client kept adding requests, and by the end the firm delivered £45k worth of work on the original budget. Nobody reported it until the project closed. Three months of margin gone.
The standard advice is “manage scope creep better.” Push back. Be more disciplined. But that puts the blame on the delivery team when the real problem is usually earlier up in the chain - the statement of work.
When a SOW is unclear, clients tend to interpret it in their favor. A clear SOW makes it easy to turn extra requests into change orders with a cost. At Magnetic, we work with hundreds of professional services firms, and those with strong margins usually have more detailed SOWs. They don’t have to say no as often because their documents set clear limits.
This guide explains what to include in a statement of work, how to build one that works in practice, and the common mistakes that can cost you money.
A statement of work is a document that defines the scope, deliverables, timeline, costs, and responsibilities for a project before work begins. It is the contractual agreement between your firm and your client.
A SOW is different from a proposal. The proposal is about selling the work, while the SOW defines exactly what the work includes. Once signed, the SOW is what you use to deliver and invoice.
The problem is that many firms blur these documents together. They send a proposal with vague deliverables, the client signs it, and now that loose language is the contractual basis for the entire engagement. Six weeks in, the client is asking for deliverables that were “implied” but never written down. You’re doing the work for free because there’s no document that says otherwise.
These three get confused constantly.
Project scope is what’s included and excluded from the work. It is one section within a SOW.
Statement of work is the complete document: scope plus timelines, costs, deliverables, responsibilities, assumptions, payment terms, and change control.
Contract / MSA is the legal agreement that governs the relationship. The SOW sits underneath it and spells out the specifics of each engagement.
A firm might have one master services agreement with a client and ten SOWs under it, one per project. The MSA covers the legal terms. The SOW covers the work.
Most firms don’t lose money on bad projects. They lose it on poorly defined ones.
The 2024 SPI Research Professional Services Maturity Benchmark reports that the average services firm earns about 12% profit, while the top 15% reach 20 to 25%. The difference is operational discipline, which starts with how you define the work.
If you’re unsure about your margins, try our agency profitability calculator. In a few minutes, it helps you identify where your projects are making or losing money by highlighting margin leaks, under-servicing, and opportunities to improve overall project profitability.
Over-servicing becomes invisible. Say the SOW reads “website redesign” with no mention of page count, revision rounds, or browser requirements. From the client’s view, every additional request is part of the initial deal, and you end up eating the cost.
Change requests have no mechanism. Without a change control clause, extra work gets agreed on calls and in email threads. Nobody logs it. Nobody prices it.
Budget tracking often becomes guesswork. The SOW might be in a shared directory, the budget in a spreadsheet, and timesheets in another tool. No one connects the scope to the spending until the project ends and someone asks, “did we make money on this?”
A consulting firm we work with discovered they had been over-servicing their biggest client by 22% for more than a year. Their SOW only said “ongoing strategic support” and didn’t mention hours, outputs, or review schedules. The client believed they were following the agreement, but the firm was losing profit the entire time.
Every SOW needs to answer three questions for each deliverable: what is it, when is it due, and what does “done” look like? If you can’t answer all three, the deliverable isn’t defined well enough.
These are the sections every professional services SOW should contain.
Write two or three paragraphs explaining what the project is, why the client wants it, and what success means. This section gives context, not scope. It helps anyone who joins the project later understand the purpose, even if they weren’t involved in the sales process.
This is the most important section. Here, you define exactly what is included in the project. Be specific and list every deliverable, output, and activity you will do.
If the SOW is vague, the client might ask for a 30-page website with unlimited revisions, since nothing says they can’t. A detailed SOW makes it clear what has been agreed, allowing little room for confusion.
This section is just as important as the scope. Clearly state what is not included in the project.
Clients usually don’t challenge boundaries to take advantage of them. They do it because they don’t know where the limits are. An exclusions section clears up any confusion.
Example exclusions for a website project:
Create a table or list that links each deliverable to a due date and acceptance criteria. This is what you use for invoicing, so be specific.
Example deliverables table for a website redesign engagement. Each milestone has a defined output, a deadline, and a clear definition of “done.”
Include a project timeline that shows phases, dependencies, and key dates. It doesn’t have to be a Gantt chart, but it should clearly state when work starts, when milestones are reached, and when the project ends.
Add a section explaining what happens if the timeline changes because of client delays, such as late feedback, incomplete content, or unavailable stakeholders. Most project overruns happen because the client is late, not the delivery team. Your SOW should make it clear what to do in these cases.
How much the project costs, the billing model (fixed fee, time-and-materials, retainer, or hybrid), and when payment is due.
For fixed-fee projects, link payments to milestones. For time-and-materials, list the billing rate for each role, estimated hours, and how often you’ll invoice. Choosing the right billing model is important because your utilisation rate affects whether your estimated hours will cover your costs.
Include:
Who does what, on both sides.
Client responsibilities are often overlooked. If the client needs to provide copy, photos, brand guidelines, access credentials, or make people available for feedback, write it here. If they miss a deadline, the timeline section will protect you.
Every SOW is built on assumptions. State them. Examples:
If an assumption turns out to be incorrect, it should start the change control process.
This is the section that saves your margins. It defines how changes to scope, timeline, or budget are handled once the project is underway.
A good change control clause covers:
If you skip this section, changes are handled informally. Someone might agree to extra work in a meeting, the team does it, and no one bills for it. Over many projects, this can add up to a big loss.
Explain how deliverables are formally accepted. This helps avoid the problem where a client keeps asking for changes because there’s no clear end point.
Spell out:
Here are two statement of work templates: one for fixed-fee projects and one for time-and-materials projects. Use these as starting points and adjust them to fit your firm’s billing model, industry, and your clients’ language.
After reviewing hundreds of SOWs from firms using Magnetic, we’ve noticed these five mistakes come up again and again.
“Ongoing support” is not a deliverable. “4 hours of technical support per month, covering bug fixes and minor updates to the production website, logged via the helpdesk” is a deliverable.
Every deliverable needs a quantity, a format, and a definition of done. If you can’t measure it, you can’t bill for it. And you definitely can’t prove when you’ve exceeded it.
Firms often skip this section because it feels uncomfortable to list what they won’t do. But without it, clients may assume everything related to the project is included. An exclusions section isn’t negative - clients usually appreciate it because it shows you’ve planned carefully.
If you don’t have a change control process, anything agreed to in a meeting becomes part of the project. For example, a project manager might say “sure, we can add that” during a call, and soon the team is doing extra work for free. With a clear process, every change is reviewed, and the client can see the cost and decide if they wish to continue.
If the client must provide content, access, brand assets, or make people available, include this in the SOW with a deadline. Otherwise, you might wait weeks for copy, your team sits idle, delivery gets delayed, and the project seems to have been delivered late, even though it wasn’t your fault.
This mistake makes all the others worse. The SOW is in a shared drive, the budget is in a spreadsheet, and timesheets are stored elsewhere. No one connects them until someone asks, “are we still on budget?” and it takes an hour to figure it out.
By the time you realise a project is over scope, it’s usually too late to fix it. The work is finished, the hours are logged, and the profit is gone.
The solution is to track scope, budget, and time in one system. This way, when hours used get close to the budget, you can see it right away and take action. That’s what PSA software is designed for.
A SOW that just sits in a team drive and never gets used won’t protect your margins. The goal is to write a document that your team and client actually refer to during the project.
Many firms create the cost estimate first and then build a SOW to fit it. This is the wrong order. The SOW should define the work, and the estimate should price it. If you price first, you’re guessing about work you haven’t fully planned, and those gaps will appear during the project.
Legal language belongs in the MSA, not the SOW. The SOW should be easy for your project manager, the client’s marketing director, and even a new team member to read. If a section needs a lawyer to explain it, the people doing the work will probably ignore it.
The person who sells the project is often not the one who delivers it. Before sending the SOW to the client, have the delivery team review it. They can spot unrealistic timelines, missing deliverables, and assumptions that might not work in practice.
Use the SOW in kickoff meetings and refer to it whenever scope questions come up. Quote it in project status reports, such as “We’re on track for Milestone 2 as defined in the SOW.” When people actually use the SOW, scope discussions are based on facts, not opinions.
SOWs often get updated. If you don’t track versions, you might end up with several copies in different emails and no one knows which is the latest. Number each version and keep them all in one place.
There’s no secret to protecting your margins- it all comes down to having the right process in place. A good SOW clearly states what’s included, what’s not, what happens if things change, and what the client needs to provide. The templates above are a starting point, but it’s important to connect your SOW to the system you use to track hours, budgets, and deliverables. If these are in separate tools, you’ll keep discovering overruns too late. Magnetic offers a 14-day free trial so you can see how it works when everything is in one place. No credit card needed.
.svg){kind=small}
A statement of work (SOW) is a document that defines the scope, deliverables, timelines, costs, and responsibilities for a project. In professional services, it is the agreement between a firm and its client specifying exactly what work will be delivered, by when, and for how much. A well-written SOW protects both parties by creating clear expectations before work begins.
A project scope defines what work is included and excluded. A statement of work is the more comprehensive document that outlines the scope, including timelines, deliverables, payment terms, acceptance criteria, assumptions, and change control processes. Scope is one section within the SOW. A scope tells you what you’re building. A SOW tells you what, when, how, for how much, and what happens when things change.
There is no fixed length. A SOW for a two-week design sprint might be two pages. A SOW for a six-month consulting engagement might be fifteen. Length must match complexity. The test is whether someone who missed the kickoff meeting could read the SOW and understand exactly what has been agreed. If they can’t, it’s too short.
Yes, but only through a formal change control process. A good SOW includes a section describing how changes are requested, evaluated, and approved. This usually involves a written change request, an assessment of impact on scope, timeline, and budget, and a written agreement from both parties before any additional work begins. Informal changes agreed over email are the most common source of scope creep.
Vague deliverables. Terms such as “ongoing support” or “as needed” give the client the expectation of unlimited work within a fixed fee. Every deliverable should answer three questions: what is it, when is it due, and what does “done” look like? If you can’t answer all three, the deliverable isn’t defined well enough.
Ideally, the person closest to the work. In most firms, this is the project lead or account director, not the person who sold the engagement. The sales team knows what the client wants. The delivery team knows what it will actually take to produce it. If the person writing the SOW hasn’t done the work before, they’ll underestimate effort, miss edge cases, and leave assumptions unstated. Get the delivery lead to write it, or at the very least, to review it thoroughly before it goes to the client.
Magnetic is an all-in-one workflow management platform designed and built for professional services firms.
