Great Expectations (Writing a Great SOW)

The best way to ensure a successful partnership with a consultancy is to have a solid shared understanding of what the goals of the project are, what work will be done, how it will be done, and when it will be done. The Statement of Work (SOW) governing project work is the foundation for a successful outcome. This article explores how to take a high-level SOW from an accepted proposal and turn it into a robust and effective contract.

A draft Statement of Work (SOW) is included in a proposal to frame the initial conversation between a client and a consultancy. You, the client, have these goals and needs, we, the consultancy propose to meet them by performing the outlined work which would take these resources in this amount of time. If the client need in the RFP is well-defined (such as usability testing a website.) these draft SOWs can be concise and fairly short. If the client’s needs are more complex, such as discovery research, or UX strategy work, presenting them with several potential options can help them choose the type of engagement that best meets their stakeholder needs.

Statements of Work should cover the following areas:

Scope - What problem or need will this work address? What does the defined work include and how it will it be done?
Deliverables - What does the client get for their money?
Timeline - How long will the project take?
Responsibilities - What are the respective responsibilities of each party?
Resources - What resources are required to complete the project?
Price - How much will this cost?

If the proposal is accepted, that SOW provides the framework to flesh out a more detailed SOW. The client and consultancy discuss the upcoming project, settle any open questions, and finalize the SOW. Let’s look at what should be covered in each section.

Scope

What does the defined work include and how it will it be done?

State the client goals that are driving the project. This helps ensure planned activities to achieve that goal.
Be as specific about what is in scope (features, pages, activities) as possible.
Outline what related work is out of scope. Particularly when the project is focused on specific elements of a complex web site or product, this helps avoid confusion later about what is or is not in scope.

Deliverables

What does the client get for their money?

Ensure all required deliverables are listed, spelling out content or format requirements.
Define if, when, and by whom, deliverables will be reviewed by clients before final submission.
Define what counts as client acceptance of a deliverable. Acceptance could be client approval. If the deliverables are likely to require revision (if the deliverable has design components or if the client is known to question when a delivery is complete, , it’s wise to limit what is included to a certain number of revisions.

Timeline

How long will the project take?

How will project progress be measured? By time, completed activities or other milestones?

Which events trigger an invoice?
Which give you approval to move forward?
When are check-ins planned to assess progress or see if any changes need to be made?

Provide a timeline, based on business days rather than the calendar, that defines when things happen and how long they should take (check-ins, planned activities or milestones, as appropriate.

The risk of using the calendar for the SOW timeline is that often by the time paperwork is signed, it is out of date, which would expose the company to legal risk for promising an invalid timeline.
Defined durations for activities makes any future timeline shifts easier to track.

If deliverables will be reviewed:

Define the duration for those client review cycles and any expected revision. Where applicable, build in several iterations.
This is particularly important for projects with design elements, or more open-ended research goals that may require several cycles of review and revision before they are considered complete.

How many major or minor revisions are built into the current cost?
How are those defined? What counts as a major or minor revision?

Responsibilities

Who is responsible for doing what?

Which roles have authority and responsibility for:

Signing off on SOW changes
Reviewing and approving deliverables

Indicate where delays in fulfilling responsibilities will affect the timeline if they take longer than expected to perform (provision of necessary system access, client review and feedback, recruiting participants).
Define the fiscal and timeline consequences if those client responsibilities aren’t met, the more specific the better. If a prototype that will be used for testing is delivered late, how does that change the timeline, and what charges will that incur as a result? A prototype delivered late enough might force fielding to be pushed back, and the client would bear the facility and recruiting costs.

Pricing

How much will this cost?

Contract pricing could fill an entire article on its own. Here, we are primarily concerned with clearly spelling out what the costs are and how they are handled, rather than how to set prices or rates.

Specify the type of contract (Fixed Price, Time & Materials, Retainer) with a cost breakdown appropriate to that model.

When it’s easy to estimate the amount of effort to complete a project, often a Fixed Price model is appropriate.
When the project is more difficult or open-ended, T&M, Retainer, or some other arrangement may be more appropriate.

Summarize assumptions underlying provided pricing. Making these assumptions explicit makes it easier to catch any changes that might have financial repercussions.

Common examples:

How recruiting & compensation are handled
Whether testing is on-site, remote, or at a market research facility

Indicate what resources are required to complete the project. Client costs are typically either Labor (staff hours) or Other Direct Costs (ODC) which covers about everything else.

Tech (additional software, hardware, or services)
External Vendors (recruiters, compensation, research facilities)
Travel (hotel, transport, food)

What if (something changes)...?

In the ideal world, there would be no surprises or unexpected challenges in well-planned projects. But the real world is messy, The best way to handle the unexpected is to look at every section of the SOW and consider, what if something doesn’t go as planned? What if the plan changes? Have we protected ourselves (and our clients) by providing a clear framework to adapt and adjust?

Examples of common scenarios include:

What if the client adds additional project goals that require activities beyond what’s scope?

What if we planned for a single review cycle for deliverables, but the client requests additional review and revisions?

What if it looks like we need another week for a successful recruit of a hard-to-find population?

What if the client wants to increase the sample size of the study?

If something changes in a project, here are the questions your SOW should be able to answer:

Which roles are responsible for reviewing and approving these changes?
Who is responsible for handling discussions with the client about project changes?
What change of scope can be accommodated without a change order?
Which are big enough to require a change order?
How will changes to the SOW be documented and communicated to all parties?

Building a flexible process for change management into your Statements of Work will go a long way in handling those unexpected challenges by providing a clear path for resolution.