What is a scope of work? And why do you need one?

At its core, a scope of work is a document that covers the working agreement between two
parties. Usually that’s a client (aka you) and an agency, vendor, or contractor (aka the outside
team you’re working with).
As a project manager, you’ll use a SOW to make sure expectations are clear and agreed-upon,
and that both you and whomever you’re working with know exactly what they should be doing.
To make that happen, an effective SOW should include things like:

 Project objectives: Your problem statement. What is it the issue that you’re facing and what do
you want to achieve with this project?
 Schedule/Milestones: When is the project starting and when does it need to be finished by? What
are the major milestones or phases of the project that you’ll be able to track and measure
progress by?
 Individual Tasks:What exactly needs to get done in order to go from where you are now to a
finished project?
 Deliverables: What do you need at the end of the project? Is it simply a .PSD file of the website
mockup? Or usable code on a staging server that you can implement when you’re ready?
 Payment Information: How much is the project going to cost and how are you going to pay the
team you’re working with?
 Expected Outcomes: The answer to your problem statement. Are you looking for an increase in
traffic, conversions, or sales? What is the business objective that you want to hit with this project
and how will you measure and report on it?
 Terms, conditions, and requirements: Define the terms you’re using in the SOW and any
conditions or requirements that aren’t already made clear.

While a project proposal helps get you buy-in for internal projects, a SOW is used when working
with outside teams. Therefore, it needs to be especially clear, use language everyone
understands, and set detailed tasks, deliverables, and other services.
A good SOW avoids some of the biggest project management traps, such as:

 Confusion, miscommunication, and disputes over scope

 Misinterpretations of expectations and needs
 “Selective Amnesia” of what was said and the need for expensive rework

It’s a lot to ask. But if you pull it off, an SOW will ensure you, your stakeholders, and the outside
teams you’re working with all have a clear idea of what a “successful” project looks like, and
how you’re going to get there.

Scope of Work template and outline

Alright, so we have a basic understanding of what a SOW is and what its purpose is. But what
does it look like in practice?
 Write your own? Use our template!
We've prepared a free template to help you write your own Scope of Work. Download it and
follow along the article.

Download Free Template

A SOW is a detailed doc that the people you’re collaborating with will reference back to
throughout the project and therefore needs some very specific information to be valuable. Here’s
a basic outline of what you should include:

Section 1: Introduction
Before you get into the project specifics, it’s important to get the highest-level information down.
What is the type of work that is being done? Is it a service that’s being performed or a product
that’s being built? Who are the parties involved.
The introduction can also cover the types of formal agreements that the SOW can be used to
create later, such as:

 Standing offer: An agreement to buy a service or product at a certain price for a certain time.
 Contract: A more formal, legally binding agreement based on mutually agreed details.
Section 2: Project Overview and Objectives
With the basics out of the way, it’s time to address why this project is being done. Start with an
explanation of the project, the context around it, and the business objectives it’s trying to solve or
expected outcomes.
You’ll get into more details later on in your SOW, so keep this intentionally surface level and
easy to understand. As Salesforce’s Paul Cannon explains:
“If a coworker or family member cannot explain what the scope is and what success looks like
then this foundational section needs to be updated until it is crystal clear.”

Section 3: Scope of work

The next section outlines the work that needs to be done in order to complete the project. Again,
keep this higher-level (as you’ll put specific tasks and requirements in the next section). You can
do this as either a bullet list of steps or a simple explanation.
For example, let’s say you’re contracting an agency to redesign your website. Your scope of
work section might include steps like “Design new website mockups,” and “develop new website
design.” While the next section will break these down into the actual tasks involved such as
“create new landing page design prototypes in InVision.”
In some cases, your scope section can also include technical requirements like the hardware and
software to be used.

Section 4: Task list

Task management is an incredibly important part of any project, but especially when you’re
working with an outside team. Breaking down your larger scope into more granular actions is the
best way to ensure everyone’s on the same page about what needs to get done.
One point to remember here is that tasks are not deliverables (i.e. what you’ll receive). They’re
the actions that need to be taken. As such, each task you write down should explain a specific
action to be taken (i.e. “redesign landing page” vs. just “landing page”)
For software projects, you’ll want to be especially diligent about going into detail. Think about
functionality and list out everything the software will do right down to what fields are going to
be included and where that form is being sent.
It’s also a good practice to break your tasks down into phases.
So, for our website redesign project, our SOW might have a “kickoff” phase full of tasks around
research and planning. A “design” phase with prototyping and wireframing pages. A “build”
phase around developing and implementing the designs. And a “test” phase where we do
usability testing and look for bugs.

Section 5: Project Schedule

The SOW project schedule covers more than just start and end dates. It’s a chance to outline
when, where, how, and by whom the work is going to be done. Here’s the main questions this
section of your SOW should answer:
 How long is the project going to take and what are the phases/milestones?
Time is often one of the more important deciding factors when it comes to pricing a project, so
you’ll want to be clear upfront what expectations are.
Does the project have specific predetermined dates? Will it take place over a given period of
time (like “one 6-month period”). Or is there an end date that coincides with some other event
such as a change in government regulation (like GDPR) that affects your business model?
In Agile companies, this can often be hard to do. You might be able to estimate a timeline, but as
you’re working iteratively it’s not as simple as picking dates on the calendar.
Instead, you’ll want to think beyond a fixed scope and try to create structure to the project while
maintaining the flexibility to pivot and adapt. One way to do this is to create a schedule for the
first phase or milestone and then set aside time to reassess and adapt the SOW once you’ve
completed it.
In every case, however, a SOW should never have an open-ended project schedule. Rather, if
you need to leave it more flexible you should set a maximum amount of time that can be spent
without approval/notification.
Where is the project work going to take place?
Simply put, is this an on-site or remote project? You can also list if any regular meetings are
going to take place (like a daily Scrum) and when and where those will take place.
What are the required resources for you and the contractor?
Who’s doing what (both from the contractor and your team)? Do the contractor’s current
resources match up with the project expectations? And what about you? How many people are
you going to need to help run and support this project? Don’t forget to be realistic and allow for
a decent amount of overhead.

Section 6: Project Deliverables

It’s time to get down to brass tacks. The project deliverables section of your SOW is where
you’ll list exactly what you expect to receive at the end of the project. These are the natural
conclusions from the task list you’ve already put together above. So you might list things like:

 Coded, fully functional landing page

 Google Analytics setup and tracking metrics
 Redesigned e-commerce page template

In many situations, you might want to combine the deliverables and timeline so that you have an
accurate picture of when each deliverable should be finished and what’s dependent on it. This
way, you get a better overall picture of the flow of the project and can see where bottlenecks
might come up.

Section 7: Adoption plan

 This is something that’s left out of 90% of SOWs but is a valuable piece to include. An adoption
plan is the process for how the deliverables will be put into place. Whether that’s the migration
of your new website to your old domain or how a feature will be brought into an existing app.
You bought into the value of the project. And while it’s ultimately your responsibility to lead the
adoption of it at your company, why not let the experts you hired help guide you?

Section 8: Project Management

With most of the details on the actual project in place, there’s just a bit of administrative work
left to include in your SOW. This is where you outline and detail any missing information that’s
key to keeping you and the other party happy. This means things like:

 Payment: How and when will payments be made? Will it be by milestone and deliverable? Or on a set
schedule? Wire transfer or ACH? What happens if deadlines get missed or scope increases?
 Reporting: Who’s responsible for signing off on deliverables, approving scope changes/adjustments, and
handling support and maintenance?
 Terms: What other requirements and standards need to be agreed upon? This could be security
requirements. Exclusions (i.e. what’s not included). Or assumptions (i.e. who owns the code at the end of
the project).

Section 9: Success Criteria and Sign-off

Finally, the last section of your SOW covers how you will accept the project deliverables. This
means who will authorize them and how deliverables will be reviewed and signed off on. You
should also provide a bit of guidance and criteria around what is “acceptable” work.
Getting this agreed upon up front might seem unnecessary, but it helps reduce the chance of
serious headaches later on when you receive something that isn’t what you expected. Remember,
a SOW is all about clarity and detail. The more you give, the better result you’ll get.
Once that’s out of the way, all that’s left is a couple of signatures and you’re ready to get going!

5 must-haves for effective SOWs

Before we move on, there’s just a couple points I want to make absolutely clear. Yes, I probably
sound like a broken record here, but clarity and detail are essential to an effective SOW.
 So as you’re writing your SOW, make absolutely sure that it hits all these must haves:

1. Explicit Details: If it’s not on the SOW, don’t assume it will get done. This means including assumptions
on effort, time, and resources.
2. Visualizations: Wherever possible show what you’re talking about rather than try to explain it.
Visualizations, pictures, and examples go a long way in explaining your goals and needs.
3. Definitions for any terminology: Again, the golden rule of SOWs is “thou shalt not assume.” If there are
business terms, phrases, or acronyms in your SOW, make sure they are defined.
4. Time for reviews: A SOW is a plan. But at their best, plans are just educated guesses. Make sure your
project schedule and deliverable timeline has space in it for reviews, pivots, and unexpected changes in
priorities.
5. Success definitions: Probably the most important aspect of an effective SOW is both parties being aligned
in what success looks like. If it’s at all unclear what you want to achieve at the end, rewrite it.

How to use a SOW with Agile Project Development

SOWs are powerful documents for project managers. But if you work with an agile team you’ve
probably got a few questions. First off, how can you create such a detailed document when
you’re working in sprints and adapting to tests and user research?
However, a good project still needs structure. As a company that practices Agile product
development, you might not know the full extent of your scope of work from the start. And your
document will need to account for any changes, additions, or pivots that can happen throughout
the product development lifecycle.
One way to handle this is by dividing the work into iterative phases.
Some phases may be more detailed than others. However, each can be re-assessed and adapted as
you hit milestones and test iterations. The earlier phases might have stricter requirements, while
later ones are estimates until you get closer to them.
Try to balance flexibility with structure. What do you know for sure? And what will only
become apparent once you’re in the project? Make educated guesses and work in checkpoints to
keep everyone on the same page and moving forward.

Final thoughts on writing a solid SOW

Whether you’re building a new product from scratch, going through a redesign, or just getting a
bit of illustration work done, a SOW is a powerful tool to keep everyone accountable and on
task. It might seem like a lot of work to do upfront, but the more you can make clear, the easier
the rest of the project will flow.
That said, there are a few final pieces of advice that can help make the difference between an
effective SOW and one that misses the mark:

 Keep it brief: Detail is important, but don’t go overboard. Writing a 30+ page SOW will inevitably mean
your contractor will have to spend time going through it line-by-line (maybe with their attorney) slowing
the whole process down and costing them money. The crazier the exclusions, clauses, and exceptions you
write, the more time it’s going to take them and the more concerned they’re going to be.
 Write in the earlier stages of a project: It’s never too early to start writing a SOW. Starting early means
that the document has the chance to evolve alongside your understanding of the project and your needs.
 Bring in other people to help: If you don’t have the expertise to write certain sections, ask for help. This
might mean bringing in a technical writer if you’re unsure of how to exactly express the requirements and
infrastructure.
 Be clear about what the project doesn’t include: Especially in agile software development, requirements
might be vague, so you need to be clear what paths not to take as much as which ones to go down.

There you have it! Whether you’re hiring an agency to help you build a new app or remodeling
your house, this should help you put together a comprehensive and clear SOW that will keep
everyone on track and accountable.

Write your own SOW using our template!

We've prepared a free template to help you write your own Scope of Work. Download it now to
jump start your own SOW writing.

Download Free Template

More articles about Project Management: