Suppose you’re the founder of a small software engineering firm. You’re building a custom integration for an SMB client. You have a verbal agreement, and since the client wants a tight turnaround, you start building immediately.
Three weeks later, the client loops in procurement to finalize the deal. You expect them to ask about payment terms or to sign a contract. Instead, their stakeholders want to see all the project objectives and requirements in writing before they finalize. Trouble is, you’ve already done a lot of the work. Because the project was never fully scoped, you now have to spend valuable time reverse-engineering a statement of work.
But how do you write a statement of work? What should you include? Is it the same as a scope of work? These questions are common for founders and service teams in this situation. This article breaks down what goes into a statement of work and how to write one that protects your client relationships and your business.
What is a statement of work (SOW)?
A statement of work is a project source of truth that defines measurable objectives, scope of work, timeline, milestones, costs, and responsibilities of each party. Strong SOWs are explicit about the boundaries and what project success looks like.
A statement of work does two things at the same time:
- It sets expectations among project stakeholders: Verbal agreements are a good starting point, but it’s too easy to make assumptions or forget key details when terms aren’t put in writing. A simple misunderstanding, such as whether the expected response time is 24 or 72 hours, can create friction in a working relationship if not explicitly communicated.
- It’s an enforceable record of project terms: A statement of work is a project’s reference text. An SOW is not exactly a contract, but it binds two parties to project deliverables and outcomes within a certain timeframe. So if a vendor delivers a product or service with a chunk of the promised assets missing, the SOW acts as proof of what was agreed to.
A statement of work is essentially a project bible. It’s important to be explicit when creating one. Otherwise, you risk potential disputes with partners who are otherwise aligned.
Statement of work vs. scope of work vs. contract
A statement of work and scope of work are terms that are too often used interchangeably. And people new to contracting sometimes conflate both with the contract itself. But these are three distinct concepts, each serving a separate function.
Statement of work vs. scope of work
A statement of work is the full project agreement, while the scope of work describes what will be done. If you think of the project as a road trip, the scope of work is the destination, and the statement of work is the full itinerary: when it’s happening, where you’re going, how you’ll get there, how much it costs, and how you’ll know if the trip was a success.
The statement of work answers, “What are we doing? When? For how much, and how do we know when we’re done?” The scope of work answers, “What are we doing?”
Statement of work vs. contract
A contract is the framework for the legal relationship between two parties (IP, liability, indemnification, force majeure, etc.), whereas the statement of work governs a particular project. Sticking with the road trip analogy, the statement of work is the itinerary, while the contract is the road trip rules: who can drive, how you’ll share expenses, how you’ll resolve disputes, and what you’ll do if the car breaks down. You can have different itineraries under the same travel rules.
Another difference is who uses which document: Executives and the legal team review contracts, but project managers and delivery teams often use SOWs.
What a statement of work includes
A statement of work is only effective if it’s explicit and includes the right elements. SOWs have two components: the project-side details (what the work is) and the commercial-side terms (how it gets paid for and approved).
Project definition and work details
The SOW document covers core project management elements:
- Project overview and objectives: What the project is and what it’s supposed to accomplish.
- Scope boundaries: Project guardrails that detail what is and isn’t included in the project.
- Specific deliverables: Time, outcomes, or materials that will be delivered as part of the project.
- Roles and responsibilities of each party: Who is accountable for what and what their duties entail.
- Timeline with milestones: When each part of the project will be delivered and what significant stages must be completed.
What’s included in a scope of work is just as important as what’s excluded, as both establish expectations. Omitting exclusions is a common mistake that leads to scope creep.
Commercial and control terms
Here’s a (non-exhaustive) list of terms that help determine when work is accepted, paid for, and closed:
- Payment schedule: Payment terms for how and when the vendor or contractor will be paid (e.g., fixed fee, time-and-materials, milestone-based).
- Acceptance criteria: Requirements that have to be met before the project will pay out. Acceptance criteria are often overlooked, but they’re important because they determine when the project is done and when the payment is owed.
- Quality standards: Acceptable levels of quality that have to be maintained throughout the project.
- Approvals: The decisions and actions that require sign-offs from various authorized representatives.
- Compliance requirements: Legal or regulatory requirements that have to be followed through the execution of the project.
How to write an SOW
It’s tempting to take a shortcut when writing an SOW. But taking a fill-in-the-blank approach can easily backfire. Here’s a step-by-step guide to writing an SOW.
- Clearly define project objectives: Start with what you want from the project. What business needs does this meet? What does your team need? How will you know if the project is successful? Specificity is crucial to a strong SOW. For instance, instead of “The consultant will redesign onboarding,” say “The advisor will redesign the user flows and share high-fidelity mockups.”
- Detail project deliverables and terms: After a brief description of the project, determine deliverables, timeline, acceptance criteria, and payment terms in sequence. One step informs the next and leads to a cohesive SOW. For example, you estimate four weeks until go-live for an implementation, but when you break down the deliverables by timeline, you realize the data migration alone will take three weeks. Deliverables shape acceptance criteria and timelines, and timelines shape payment schedules.
- Formalize the draft: Now that you’ve clearly defined deliverables, timeline, and acceptance criteria, add in the guardrails that make the SOW document operative. Define your terms, project risks, assumptions, limitations, the necessary approvals, and most importantly, what a successful project looks like.
Be as specific as possible. A short, sharp SOW that defines two deliverables precisely is worth more than a long SOW that only gestures at two dozen.
Types of SOW (and when to use each)
SOW documents are common for setting expectations in project management, but the structure of an SOW depends on the type of project and where the risk sits. There are three main types of SOWs.
Design/detail SOW
These SOWs specify what the provider will do and how. For example, if a founder is hiring a developer for a website redesign, the design/detail SOW stipulates how many pages the website will have, what platform to use, how they’ll share design mockups and wireframes, and which tools it needs to integrate with. The buyer bears the risk of getting the specifics right. Design/detail SOWs work best when the client has a specific vision of the outcome and the process, particularly in deliverables-based work.
Level of effort (LOE)
Also known as a time-and-materials SOW, the LOE SOW prices the project by hours or resources rather than specific outcomes. This SOW works well for consulting and ongoing professional services where the project scope can shift. For example, if a startup founder hires a fractional CMO, the deliverable is their expertise for a certain number of hours per week, rather than a specific output. Because there's no fixed deliverable, the buyer bears the risk of scope drift and time overruns.
Performance-based SOW
Performance-based SOWs define results, but not how they’re achieved. These SOWs work best for engagements where the outcome is more important than the work itself, like software development and marketing engagements. For example, a startup founder engages a lead generation agency that agrees to deliver 100 MQLs per month within a specified vertical. In this case, the provider is responsible for delivering the result.
Picking the right type of SOW matters as much as drafting it well.
Your team writes the SOW. Crosby redlines it.
Every new engagement means another SOW to review: scope, payment terms, acceptance criteria, and whether any of it lines up with the underlying MSA. Your team spends valuable time reviewing terms when it could be focused on delivering value.
That’s where Crosby comes in. Your team writes the SOW, and Crosby’s AI agents flag nonstandard language in the MSA, potential scope creep, and overly broad acceptance criteria. A barred attorney supervises. Flat-fee payments and fast contract turnaround help your team stay on budget and schedule.
See it in action. Talk to Crosby today.