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!