Statement of Work: Ultimate Guide & Template For 2026

If you’ve already created a project plan or timeline and a project estimate, then the SoW is the icing on the cake—it’s got the juicy details to tie everything together.

A well-written SoW clearly defines what your team will and won’t do on a project—helping you manage your contractors and protect both your timeline and the bottom line.

Author's Tip

Some people refer to the statement of work as a scope of work instead. Po-tay-to, po-tah-to.

Statement of Work Template & Example [Download]

Fortunately, I’ve got the template for you! My statement of work template is detailed and ready to use. It helps answer the questions: “what should I include in my SoW?”, “how much detail do I need?”, and “where do I store project information?”

My SoW template is approximately 12 pages long (1000 words) and available in a format that's compatible with Microsoft Word & Google Docs for you to adapt as you need. The template is unbranded and uses generic styling to make it easy for you to edit content and brand it with your logo.

The first section outlines overarching project information, while the second section defines the details of each phase. You can add subsequent phases if your project requires them. The template is available for download in the DPM Membership templates library.

Find more project management templates here.

What Should a Statement of Work Contain?

At a minimum, the SoW should clearly include:

• Project Objectives: purpose statement, i.e. why the project is happening and what it will achieve
• Project Governance: who has approval to do what
• Work Breakdown Structure (WBS): how the project will be completed, what approach will be taken, and the specific tasks and phases that will be completed
• Deliverables: what will be produced and by when (with a specific due date)
• Period of Performance: when the project will be delivered, along with the amount of time needed, approximate start date and end date, and a list of milestones
• Estimate: project pricing, along with a payment schedule
• Assumptions: what is and isn’t included in the project scope, including acceptance criteria, i.e. what is and isn’t acceptable to deliver
• Work Requirements: any other special requirements and specifics about how the project is to be completed, such as specific approaches or project management tools. Include functional requirements for software development projects.

If the work statement is too vague, too broad, or too generic, it can leave room for multiple interpretations. This can create misunderstandings later in a project. On the other hand, if the SoW is too detailed, it can constrain the project. You may end up doing work that’s not needed, simply because you said you would.

Types of Statements of Work

There are three main types of statements of work: design or detail, level of effort, and performance-based. Each defines how you specify project requirements, measure progress, and evaluate the work delivered.

• Design or Detail Statement of Work: Specifies exactly how the work must be completed, including processes, materials, technical requirements, and deliverables. This type works best when you need strict control over execution, such as construction or regulated projects. However, it gives vendors less flexibility to choose their own approach.
• Level of Effort (LOE) Statement of Work: Defines the amount of time, resources, or labor a vendor must provide rather than a fixed set of deliverables. It's useful for consulting, ongoing support, and projects where requirements may evolve. You'll need clear reporting and oversight to make sure the time spent delivers value.
• Performance-Based Statement of Work: Focuses on the results a vendor must achieve rather than prescribing how they complete the work. It defines measurable outcomes, performance standards, and acceptance criteria. I recommend this approach when you can clearly define success but want to give vendors flexibility in how they achieve it.

The right type depends on how much control you need over the work and how clearly you can define the expected results. You can also combine elements of different types to suit your project's requirements.

How to Write a Statement of Work

Keep these tips and tricks in mind when crafting a SoW:

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

1. Break it Up

Don’t scope what you don’t know. Rather than trying to create a SoW for an entire project, split the project into phases, and develop separate SoWs for each phase as the project progresses.

2. Make a Plan

Decide what you’re doing and how. Define the deliverables and the process required to produce them so you can clearly articulate what’s in and what’s out of the project scope.

3. Put it into Context

Explain why you’re doing the project. Even if the specifics of the plan evolve, the SoW should help you to assess whether the project was a success.

4. Be Specific

Set the project’s boundaries. Minimize the risk of misinterpretation from your client by defining the extent of the work to do and quantifying it wherever possible so the client doesn’t expect more than you’ve budgeted.

5. Make Assumptions Clear

Lay out the ground rules. Use project scope statements to explain mutual expectations and what has to hold true for your team to properly execute the project.

6. Simplify

Be clear and concise. Strike a balance between making the SoW as lean as possible while also carefully specifying the work to be done. Avoid words with multiple interpretations, and use plain language to ensure the SoW is easy to understand.

7. Share

As the project manager, you should know your SoW inside and out and be able to communicate its contents to your stakeholders. Make sure stakeholders have seen a copy of the SoW, and continue to refer back to the SoW throughout the project lifecycle.

How to Use a Statement of Work

If you don’t stick to the SoW, it’s highly likely you’ll end up:

• Not quite delivering what was desired
• Delivering late on your project goals
• Running over your budget

So how do you stick to the plan and keep your SoW on track?

1. Know Your SoW Inside & Out

You need to know your SoW better than anyone. Keep a copy on hand—I recommend uploading it to your project management software for central access but you can print it out, too.

Whatever you do, have the SoW available when you’re on a call or in a meet­ing; whenever it’s in question, everyone will look to you for answers.

2. Familiarize Stakeholders With the SoW

It’s not good enough for you alone to know the SoW. You need to evangelize the SoW with your team to guard against the risk of scope creep.

Even if your team was involved in architecting the SoW, it’s bound to have changed and evolved since project inception. Make sure team members understand:

• Project activities
• Deliverables
• Assumptions
• What success looks like

Circulate the SoW, print copies, whatever. Just make it visible and ensure everyone's read up. The last thing you want is for a team member to agree to an ad hoc client request (that isn’t part of the execution plan) or overlook a key contract requirement.

3. Get Buy-In From Your Team

Blind agreement is a bad thing. Take the time to go through the finalized plan with your project team and get their real buy-in. If they think that something doesn’t make sense or isn’t ultimately going to drive the success of the project, hash it out before you send everyone off to work.

If it's clear from the start, you reduce the number of necessary check-ins along the way, allowing your team to work with collaboration tools on their own time.

There’s never value in doing work simply because the SoW dictates it. If it’s good for the project, then you should be able to make a case to the client to change it.

4. Keep Your SoW Top of Mind

Don’t be afraid to bring up the SoW in your client meetings—in fact, a review of the SoW should be a standing agenda item. Discuss if the SoW is still valid and whether things are going according to plan.

If there are things that need to be adjusted, understand the reasons why, make the changes, and make sure everyone is aware of them.

But Remember

Don’t succumb to every new request and idea. The SoW is there to set boundaries on your project scope, so you don’t fall victim to project management’s Bogeyman: scope creep.

5. Watch Out for Scope Creep

Scope creep happens when the project scope begins to grow, seemingly sneakily. Typically, it’s when a scope change request starts out as one thing, then slowly morphs into a much bigger project that bites chunks out of your profits.

It sucks, but it happens honestly. Clients are full of (mostly) good ideas and, often, don't understand the schedule or budgetary implications of what they’re asking for.

In order to manage scope creep, you need to watch for, call out, and resolve the problem. When you see ad-hoc requests creep in, refer back to your SoW. If you and the client agree it’s out of scope but they still want it done, you need to issue a change request (i.e. an update to the SoW).

The change request should describe:

• The change from the original SoW
• How you’re going to execute the request
• The budget and timeline implications

6. Be Vigilant from the Beginning

Projects that go off the rails often do so in the early stages of the project.

It happens when project managers don’t want to rock the boat by raising issues when they should. The downstream effects of being too flexible in the first few weeks of a project can be huge.

Not only does it leave you with catching up to do, but it sets an expectation with the client that the SoW is flexible. They may assume that you’ll honor future requests for scope changes, regardless of their budgetary or timeline impacts.

Let this happen and you might as well say goodbye to your SoW's usefulness.

Here's a very un-serious explanation:

Project Statements Of Work (SoWs) | All You Need To Know In 60 Secs!

What Does a Statement of Work Document Do?

The statement of work exists to:

• Help you figure out what you need to charge
• Provide the extra layer of detail that cost estimates and project plans don’t usually include
• Reassure the client about what they'll be getting for their money
• Keep your team accountable with clear, publicly agreed-upon timelines
• Uninvite scope creep from the party by specifying what’s not included
• Set crystal clear expectations for both sides to proactively address miscommunication conflict

If you think this'll be a lot of work, you aren't completely wrong. But by putting in the work upfront to craft and agree upon a detailed SoW, you'll help the project succeed (profitably) and reduce many-a-headache later in the project life cycle.

Common Statement of Work Pitfalls and How to Avoid Them

Even a well-written statement of work can lead to disputes, delays, and unexpected costs if key details are missing. Here are six common pitfalls to watch out for and how to avoid them:

• Vague Scope and Deliverables: Unclear descriptions of what's included can lead to misunderstandings and scope creep. Define specific deliverables, requirements, and exclusions. Use measurable acceptance criteria so everyone agrees on what constitutes completed work.
• Unrealistic Timelines: Overly ambitious deadlines can lead to rushed work, missed milestones, and budget overruns. Build your schedule around realistic effort estimates, resource availability, and dependencies. Include contingency time for reviews, approvals, and unexpected delays.
• Unclear Roles and Responsibilities: When ownership isn't defined, tasks get missed and decisions stall. Assign an owner to each major deliverable, approval, and decision. Use a RACI matrix to clarify who's responsible, accountable, consulted, and informed.
• Poor Change Management: Without a formal process, small requests can expand the project beyond its original scope. Define how stakeholders must submit, assess, approve, and document changes. Require written approval for changes that affect costs, timelines, or deliverables.
• Missing Acceptance Criteria: Without agreed-upon standards, you risk disagreements over whether the work meets expectations. Define measurable acceptance criteria for each deliverable, including who approves it and how long they have to review it.
• Ambiguous Payment Terms: Unclear payment schedules and conditions can create disputes between clients and vendors. Tie payments to specific milestones or approved deliverables. Document payment amounts, due dates, invoicing requirements, and how disputed work affects payment.

Other Documents Related to the Statement of Work

There are a few similar and related documents to SoWs that are often mistaken for SoWs, even though they serve different purposes.

Document	What It Is	How It Differs From an SoW	When to Use It
Statement of Work	An agreement between a client and service provider that defines project scope, deliverables, timelines, responsibilities, and costs.	Establishes the specific work to be completed, how it will be delivered, and the terms both parties agree to.	When you need to formally define what's included and excluded from a project before work begins.
Master Services Agreement (MSA)	A contract that establishes the general terms governing an ongoing client-vendor relationship.	An MSA covers broader terms, such as payment conditions, confidentiality, and liability. An SoW defines the work for an individual project.	When establishing a new client relationship or planning multiple projects with the same vendor. An MSA often accompanies the first SoW and reduces repeated negotiations.
Project Charter	A document that formally authorizes a project and outlines its objectives, expected outcomes, and key stakeholders.	A charter focuses on the project's overall purpose and direction. An SoW provides more detail about specific deliverables, requirements, and execution.	At project initiation, especially for larger, multi-phase projects. It helps keep stakeholders aligned on project objectives throughout delivery.
Request for Proposal (RFP)	A document organizations use to solicit proposals from potential vendors, agencies, or contractors. It outlines project requirements, scope, and expectations.	An RFP communicates what an organization needs before selecting a vendor. An SoW defines the agreed-upon work after vendor selection.	When comparing potential vendors for a project. Vendors respond with proposals describing their approach, methodologies, and experience.

Frequently Asked Questions About Statements of Work

I’ve compiled responses to some frequently asked questions regarding project SoWs.

Is a Statement of Work Necessary?

Yes, a statement of work is 1000% necessary.

A statement of work is about managing and documenting expectations. And, as with any agreement, it’s best if those making the agreement know exactly what they’re agreeing to.

If you subscribe to an agile approach to documentation—i.e. as little as possible and only where necessary—you may think that the days of producing a SoW are over.

As a project manager, it’s in your best interest to have something that enables you to say, “sorry, that’s out of scope” when a client starts asking whether the estimate for a banner ad campaign also includes a campaign landing page.

The failure to write (or properly write) a statement of work is often the reason clients and agencies end up in conflict. When there’s uncertainty or ambiguity, it creates tension. The idea of a SoW is not to catch a client out, but to state exactly what’s being done, how, when, and the cost to ensure a common understanding of project requirements.

Are Statements of Work Important for Internal Projects?

Whether or not you actually build one is up to you but it can really help.

A statement of work for internal projects is less formal; it’s more of a game plan than anything else. Your team sets expectations and outlines the tasks and project deliverables they’ll need to complete. The document doesn’t need to be a formal SoW, like the one you might create for a client, but having some type of SoW in place is beneficial.

How Detailed Should a Statement of Work Be?

The short answer is: extremely detailed about the things that matter. Less detailed about the things that are likely to change.

You need to be specific in order to:

1. Prove that you understand and can communicate the project’s goals from its outset
2. Understand how success is being measured
3. Leave very little up for interpretation (thus closing the door to scope creep)
4. Make sure doubt and disagreement are dealt with early
5. Give you insurance against Client-zillas

The rest is up to you.

Remember: the aim isn’t to be a stickler for the sake of it; your SoW exists to ensure you and your client are on the same page from the start. Use as much detail as necessary to do that.

When Is the Best Time to Create a Statement of Work?

Start early & create your SoW in phases.

In our guide to estimating projects, we talk about three phases of estimation:

1. Ballpark
2. Budget
3. SoW Estimation

It’s a good idea to start making notes for your SoW in the ballpark estimation phase. Begin documenting your SoW as you’re creating the budget estimate so that, by the time you’re creating the final SoW estimate, you’ve got the information you need to send the SoW to the client for approval.

What’s Not Included in the Statement of Work?

SoWs are a critical part of project planning, not project execution (although, of course, they may be updated throughout the project life cycle to reflect changing requirements). As such, project SoWs typically do not contain:

• Risks and risk mitigation plans
• Project status reports / progress against schedule
• Project expenditures
• Lessons learned

 

What's Next?

Want to master the finer points of project scoping and planning? Check out expert-created training from the DPM School.