How to write a kick-ass Statement of Work

So countless projects later I feel I’ve got the hang of writing watertight Statements of Work (SoW). Here’s my top tips for writing this critical document in under an hour.

  1. Start with background to give context.

Your statement of work isn’t just for your sponsor. Legal, procurement and financial teams will also be an audience. They along with other stakeholders may request to see what it is your project or resource is planning to implement. Keep it succinct and give people context around what the statement of work is about.

2. Outline deliverables and milestones

Be clear on what you plan to deliver whether it is in one go or across phases. Describe each deliverable in detail. You might want to show your major milestones or any decision gates on a Gantt chart.

3. Version control it

It will change following review so put version control in place. Over time you need to be able to see a historical record of what changed. Over the course of a programme it might be needed to write extensions or second and third SoWs.

Version control should be more than just dates. It should include a summary of the changes since the last version including supporting rationale. All referenced documents should also be under version control to clearly identify the correct version of those documents.

4. Leave no room for ambiguity

When describing deliverables ensure your language is tight with no room for uncertainty or ambiguity without becoming verbose. If you don’t know your requirements, delay your SoW. These documents are what a vendor or partner is legally agreeing to deliver.

It’s impossible to argue your case if a deliverable is off course or undelivered. If you haven’t articulated a deliverable properly you’re leaving yourself open to dealing with a situation where parties have differing views on what was expected.

5. Go easy with caveats

SoWs with lots of asterisks show one thing and one thing only — you haven’t prepared fully. If your document is full of caveats and asterisks then pull back and study your requirements and scope in more detail. Also remember that readers need to be able to navigate and get your document without flicking around looking for the hidden risks.

6. Think far ahead

Watch out for writing a high level sow that will be out of date once you start getting into the weeds of implementation. Plan your SoW as though it will cover the entire length of the programme. Brainstorm where the programme is likely to go and what you want included in the SoW.

The biggest common problem with SoWs is that they don’t fully anticipate events that are easily predictable. If you’re rolling out a new agent call centre system you know it’ll be used by hundreds if not thousands of people. Don’t write your deliverables as those it’s only looking at the capability for hundreds of users. If you know it or expect it, write it in.

7. Be prepared to revise your SoW when project is in-flight

Change can happen mid-delivery and your SoW should be updated to reflect this. Some projects don’t bother but I think it’s an important way of tracking historical change and having a single version of the truth that everyone is aiming for. Lots of changes could require a revised SoW. You might agree a price rise or change of scope verbally or in an email which doesn’t align with your previous SoW. There’s also the added benefit that having changes formally captured can avoid confusion should stakeholders change mid-flight.

Changes will need to be agreed by both parties. It is a great way to secure everyone’s agreement throughout the project. Again make sure your version control summary spells out the major changes.

8. Ways of working

Like any relationship, two parties will naturally have different ways of working. It’s important to define the framework for how the newly formed team will work together.

Leave no doubt in how governance and decision making is managed. If you’ve got a way of prioritising or planning active work, spell it out. Also don’t forget to include how you plan to deal with ad hoc tasks or escalations. Include a detailed narrative on how differences in interpretation of SoW content will be handled.

9. Run it past legal.

Your vendor or partner will do this but make sure your own legal team is okay with what you’re proposing. Don’t sign something you may later regret. Legal are there to help not hinder you. Remember that your SoW is naturally linked to a contract. Both documents are interdependent.

10. Expectations of both parties

Outline what you’re both responsible for. Write down what you expect from each other and where the lines of delineation are between what you are both doing. If someone has final sign off, write it down. If someone is responsible for writing requirements, spell this out. Remember to articulate some basics that you might have missed in ways of working such as how regularly you should meet and what behaviours you’re looking for.

11. Save it somewhere safe and accessible

I know of at least one project where the SoW was written signed off and then lost. Both parties could only find draft revisions. Legal who hadn’t been involved, had no record and were not best pleased. I carry mine around in every meeting albeit in the cloud and accessible via my iPad. Struggling to find an SoW is unacceptable.

12. Include rigorous pricing information

Spell out costs, include detailed breakdowns. Be clear on payment terms. Make sure there are no hidden fees or mistakes. Talk through this part of the SoW in much more detail. Make sure you can explain costs and breakdowns to your boss without fumbling or stumbling over how costs are split out. Make sure any table you create is very easy to read and understand. Finance are busy people and don’t need to have their time wasted trying to unravel your thinking.

Your SoW is a critical document. Getting it wrong can lead to your project or programme going off-track. Set time aside to write it and be prepared to go through several revisions. Hopefully my tips will help you pull yours together in no time.

At Strategy Activist we write SoWs almost monthly. We also help clients improve existing SoWs before any contract ink has dried. If you want to learn more about how we can help visit



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Paul Roberts

Work in travel tech. A fan of applying disruptive thinking to age old problems. Passions include writing, reading, ski touring and travel. Opinions are mine.