Jory MacKay on September 06, 2018 9 Steps to Write a Scope of Work (SOW) for Any Project and Industry
🎁 Bonus Material: Scope of Work Template
Whenever you’re collaborating with people outside your organization, it’s all too easy for miscommunication or presumptions to send a project off course. That’s why a scope of work (or, SOW) is such an important document for any project manager.
A SOW brings together everything from work details, to schedules, terms, and expected outcomes to not only define exactly what should be done on a project. But also to protect you from the dreaded scope creep where features, additions, and nice-to-haves balloon your project beyond what you’d initially planned.
Think of it like a map that can guide the completion of basically any project you can imagine—from a website redesign to building a new app or feature.
In this guide, we’ll run you through everything you need to know about how to write an effective statement of work for any project and any industry.
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?
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:
- 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.
- 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.
- 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.
- 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.
- 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.
