As a digital producer, statements of work (SOW) can feel like a pain in the administrative tush. The work has probably already surreptitiously kicked off, and you’re overloaded trying to brief in the internal team, wrangle the contract from business development, and impress the client all at the same time.

So, just do all three. Make the SOW work for you.

Write a SOWWW

Scope. Opportunity. What. Why. When.

There are plenty of Statement of Work (SOW) templates, here’s the one we use at Portable. It’s structured pretty traditionally, which is great because it will generally fit into any external document structures clients might have without much fuss.

When done right, it might force some conversations best had sooner rather than later.

This article discusses how to make best use of the process of drafting the Statement of Work, and the next article discusses the template itself.

Portable’s SOW process

Step 1: Do a handover with business development

Draft the SOW with the person in the organisation who has brought that client or project on board. The idea is to make sure you’re capturing the initial conversation, and background about why it’s important both for the client and for the agency.

Once you know the strategic goals driving the work, you can sell the project to the team and get them on board, prioritising the work plan to support the strategy as well as the execution.

Step 2: Do a briefing and planning workshop with the team

Hold a kick off meeting with the internal project team where you brief them in over at least an hour, giving them the opportunity to ask plenty of questions, and prompting them to generate and write down:

• what might go wrong (risks)
• what they think they know about the project (assumptions)
• what kind of assets they’ll be producing (deliverables)
• what check ins, feedback points, access to resources they’ll need (requirements)
• how they’re going to limit their efforts (scope)

Then, collect all the tidbits of project knowledge and document them in the SOW. This way, you’ll have the internal team working intimately within the plan and be aligned on how you’re going to deliver.

Step 3: Share with client and negotiate if needed

Once the SOW is updated to reflect both business development’s and the project team’s planning, send it to the client and get their feedback.

In most cases 90% of it will be in step with what they’re expecting. But that little 10% margin of misalignment is not a problem. In fact, it’s your sweet spot to identify issues, manage expectations and make knots into bows before the work starts.

There’s no boilerplate for how to negotiate through the 10%. But know this:

• you are armed with all the information you need to be an operator and warrior to make this project work internally
• you’re opening the earliest opportunity to build your client’s trust in your ability to work through complexities calmly for the good of the project

Breaking down the SOWWW

Our SOWWW focuses on defining scope, opening opportunities and explicitly stating what you’re doing, why you’re doing it and when it’s all got to be delivered. (You’ll notice there’s no mention of money here. That can often be left to a larger contract negotiation, but can easily be brought it where appropriate.) Here’s a description of each of my SOWWW linchpins.

S :  Scope

I’m going to assume most people reading this have some reference to 'agile' in their project delivery approach. (If you don’t, trust me it’s coming!)

Agile+ Client Expectations is not a comfortable pairing. Delivering agile projects isn’t easy. Sometimes, it’s not actually what realistically a client can sign off. Picture this conversation being had by your client contact and their boss.

'Yep, so in 200 hours they’ll deploy something. The next thing in the priority list. And we can change whatever it is, as long as it’s done the right way and we pivot. So can you sign here?'

Their boss probably does not get agile beyond seeing it as a bullet point on the agenda at their last management meeting. Not do they care about understanding it just yet. They want to sign on a deliverable, know what they're going to get. Agencies have moved to delivering 'feature-based agile', where they commit to delivering a key value proposition while using a time-boxed period to define the extent to which the feature is realised or finessed.

Scope is your best friend. Here’s where you get to be creative in defining what’s in scope for your team to look at, consider, do, plan, create, fix, and what’s not within your given time frame or effort. For example, this is the place to specify that you’re not going to fix up brownfield code bugs in IE8, or engage with the client’s CEO three times over breakfast for their take on the logo design.

O:  Opportunity

Every project is an opportunity, hopefully to do your best work yet as a team and maybe make a real difference to users down the line. Reminding yourself, the team and your client contact about the key opportunities within the project is important.

This means understanding why the client has come to you in the first place. Why do they think it’s important and worth spending money on? Why do they think you’re the best agency to do it with? And why does your agency value this work?

And once you know the answers to this, reflecting it in black and white in the Statement of Work is great. It should help build the vision into an otherwise dry document. If opportunities (aka goals) are written boldly at the start of the document, and the rest of the document backs up how you’re going to reach them, you’re less likely to get any pushback.

If you don’t understand the key opportunities however, it’s likely that trying to write them is going to be a struggle. The rest of your project plan is going to reflect that missing insight. Forcing yourself to write them down important so you, your team and the project don’t miss the goalposts.

W: What, why and when

Once you understand the scope of the project and the key opportunities you’re meeting, your approach, activities, work plan, effort and timeline all comes into focus very quickly. Writing the what you’ll be delivering, why you’re delivering it and when should be done, all frames how the project is going to work, step by step.

What exactly are you going to do, and what are you producing? This could be a report (of how many pages, in what format?), a website (for whom, what browsers, with what content?), or a journey map (for which customers, with illustrations or as a flow diagram?). I’m trying to get at fact that you can afford to be a lot more detailed than you might even like to when defining deliverables and how you produce them.

It’s even possible to attach examples of expected deliverables, to help set expectations of what that report, website or journey map might look like.

Why are you doing the things in your work plan? Spelling this out helps the client see the value in your process, and shows your team the reasoning to why you’ll be asking them to do things according to the plan.

Go ahead and explain why you’re spending two days interviewing users for insights, the point of doing usability testing, or doing daily check ins with the development team.

Your client is going to be that more able to understand and help you when you let them in on your process or methodology. In most cases having a shared understanding of the why will let you and the client more collaboratively define or tweak the deliverables in later stages of the project.

When: milestones are important to help you swing from branch to branch through a complex project, probably just one in a forest of other projects your team is working to deliver at any one time.

The order of what you’re delivering is important, so outlining dependencies and expected turnaround times is important to communicate and agree on. The team can refer to these milestones and plan more detailed activity around them, and the client can gather the resources they need in order to help you meet them.

Some common milestones I’ll capture are kick off meetings, staged delivery of assets, consolidated feedback from client, User Acceptance Testing windows, workshops, engagement with stakeholders and presentations as well as the final activity or deliverable to cap the project. This unambiguous end to the project that allows you to tick off 'complete' and send the final invoice, so it’s usually something like 'delivery of report', 'launch', or 'export of brand design files'.

Don’t forget to mark it in your calendar to celebrate!