Everything you need to know about creating a statement of work

A statement of work (or SOW for short) is a formal document between a client/buyer and an agency, vendor, or contractor.

It defines exactly what’s included within a project to guarantee work is carried out according to expectations.

Statement of work documents should not be approached lightly. While you should aim to keep them as lean as possible, they do need to be detailed and accurate. One teeny mistake could cause you a whole world of pain later on.

There’s no point trying to sugarcoat it: SOWs are difficult and time-consuming to create. But that’s what we’re here to help you with!

What’s the difference between a SOW, a scope of work, and a project charter?

A statement of work is a highly detailed, legally-binding contract, while a project charter is a shorter, high-level, non-legal overview. Project charters are often created after the SOW.

There’s no difference between a scope of work and a statement of work. However, a project charter will contain a scope of work within it (more on this later). We’ll keep things simple and refer to it as a statement of work throughout this article.

Do you really need a SOW?

Analogy time! A woodsman was once asked, “What would you do if you had just five minutes to chop down a tree?” He answered, “I would spend the first two and a half minutes sharpening my ax.”

This parable is sometimes relayed as four hours to sharpen and six hours to chop, and sometimes wrongly attributed to Abe Lincoln — but you get the point: thorough preparation is the foundation to a successful project. Take the time to prepare properly, and you’ll save yourself a load of time, effort, and wasted resources further down the line.

Aside from the obvious pleas to efficiency, SOWs are also important for strengthening relationships between client and agency. A quality statement of work will keep your client informed and reassured throughout the project. Secondly, it will help your project managers stay focused on what’s in scope instead of what’s not, preventing ambiguity, miscommunication, and conflict — all of which have serious repercussions.

How and when should you write one?

Your SOW should be created just before project kick-off, but not while the client is still deciding what it is they want. So get that agreed upon first.

Creating a SOW is easy; creating a good one is not. So how do you decide what’s essential, and what’s fluff? To help make this whole process a little easier, we organized this section into ‘must haves’ and recommended info.

Here’s what your checklist must include:

  • Project description/overview
  • Purpose and scope (why it’s happening, what it will achieve, and the resources involved)
  • Project approach (phases and tasks)
  • Responsibility distribution (indicate who is answerable for each task)
  • Deliverables and due dates (a timeline indicating which deadlines are flexible and which are not; it’s also important to include performance metrics, so you can decide whether a deliverable has been successful)
  • Necessary approvals
  • Cost (a breakdown of estimates and a payment schedule)
  • General assumptions (what’s included, and what’s not; it’s also a good idea to indicate the maximum number of hours you are willing to commit for the budget agreed)
  • Glossary and appendix (deliverable descriptions and term definitions)

These things are good to include:

  • Location of work (this might not be relevant, but it would typically include information about where meetings will be held, and if any of the projects must be completed off-site)
  • Reviews of the product or service (measurable performance reviews for continual, iterative improvement)
  • Warranty and maintenance (this is more relevant for software development projects)
  • Miscellaneous (this could include travel arrangements and agreements, security requirements, and post-work requirements, such as testing)
  • Terms and conditions

How to write a statement of work

Grappling with this much information is a pretty daunting task, especially when doing this for the first time. To make it all a bit more manageable, break it down into sections. And use the following tips.

Be specific.
Leave no room for interpretation or ambiguity. Be upfront about hours, deadlines, and cost.

Decide how flexible you want to be.
Every project will undergo some changes over time. Get too detailed up front, and you risk making it difficult to deviate from the plan when necessary. Be too vague, and you risk creating ambiguity that the client might take advantage of. Focus on providing the most details in areas you think may be problematic later on. If something does go wrong, you and your client will be looking to the SOW for guidance.

Give the project context.
Explain why you’re doing this project. Having a strong purpose not only gives everyone direction, it makes room for flexibility down the line, allowing the project to evolve while keeping the goal specific and measurable.

Break it up.
You can split your SOW into two general sections: overarching phases (summary, milestones, governance, and assumptions) and phase breakdowns (schedule, budget information, approvals, and your appendix). So the overarching phases are like your skeleton plan; the breakdowns are where you add meat to the bones.

Lay down the ground rules.
Make sure everyone knows what’s expected and what’s not.

Make it clear.
This is no time for flowery language or business buzzwords. If there are technical terms, provide a glossary. Remember: this is a document for your client as much as your team.

It’s also worth bearing in mind that people digest information differently, so where possible, use diagrams or graphs to illustrate your point. Breaking up text with visuals not only makes things easier for the more visual learners, but it also makes the document more inviting to read for everyone.

Get buy-in.
Make sure everyone understands and agrees on the SOW. And remember, buy-in isn’t something you just do at the start. Projects and teams evolve, so check in with people any time anything changes, and make sure new project members are up to speed.

Share it.
Share the document with everyone, and make it easy to access.

Own it.
Whether you wrote it yourself or inherited it, it’s important to familiarize yourself with every detail before the project begins. Knowing the project inside-out not only helps you manage yourself, but it also makes you look organized and professional both within your team and in front of the client.

Use it.
There’s no point going through all the effort of creating a fabulous SOW only to let it gather dust somewhere. It’s important that you, your team, and your clients refer to it throughout the entire project.

Measure it.
Define success and failure — and don’t wait until the end to do this. Schedule formal times for reviews to keep your project on-track from start to finish. Regularly measuring success also allows you to continually refine and improve on the job.

Ask for help
Don’t go it alone if this is your first time creating a statement of work. If possible, find someone with experience and ask them to mentor you throughout the process. Their support will give you extra confidence, while they’ll feel flattered that you came to them for help. You may also need to consider hiring a technical writer for some sections, especially related to software development.

And finally — use a project management tool
As you’ve probably already gathered, a SOW document can be a bit of an unruly beast. So make it easier for yourself: choose project management software that lets you track and manage your progress in real-time. There’s no point putting all this work in, only to have everyone tripping up over the tech later on.

Try Backlog for 30 days.

Join 800,000 developers running on Backlog. No credit card required.

Try It Free