Everything you need to know about creating a statement of work (aka scope of work)

A statement of work (aka SOW or scope of work) 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.

You should not approach statement of work documents 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!

Statement of work vs scope of work vs 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. You’ll often create project charters 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.

Who needs to create 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 of a successful project. Take the time to prepare properly, and you’ll save yourself a lot 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 an 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 or scope 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. Use the following tips.

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

Decide how flexible you want to be.
Every project will undergo some changes over time. Get too detailed upfront, 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 you expect.

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 also makes the document more inviting to read for everyone.

Get buy-in.
Make sure everyone understands and agrees on the SOW. And remember, the buy-in isn’t something just for 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 helps you manage yourself and 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, and 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 those related to software development.

And finally — use a project management tool.
As you’ve probably already gathered, an 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.

How detailed should your SOW be?

This can be a double-edged sword. The more detail you can nail down upfront, the better. It’ll make it harder for your clients or contractors to find loopholes or take advantage of the agreement, like missing due dates, asking for more, or going overboard on working hours.

This also adds more, research, and decision-making for you before the project even starts. At the end of the day, though, being able to effectively keep your project and everyone involved well-managed is worth it. And, the more often you create SOWs, the faster you’ll be at it. You may even be able to carry over major parts or keep a working skeleton from project to project.

This post was originally published on November 20, 2018, and updated most recently on March 18, 2021.