Build a Statement of Work
Learning Objectives
After completing this unit, you’ll be able to:
-
Identify the sections of a statement of work.
-
Address feedback for a statement of work.
Similarity in Statements of Work
Not every statement of work looks the same, since each customer's business needs, top priorities, and deliverables for each project are different. Yet, every SOW must cover the same topics.
What follows is a list of topics—grouped in seven sections—to include in a best practice SOW. Feel free to group these differently, but make sure to create a logical flow, so the customer sees how one section leads to the next.
Background
Always include the project background information here, even if it was stated in earlier documents. This is important for two reasons.
-
The SOW is a legal document, and all information should be in it.
-
The SOW keeps all the customer’s stakeholders informed, since the executive sponsors, the senior leadership supporting the project and signing the contract, and the project teams delivering the work are not the same people.
In this section, include the customer’s needs, business objectives, and measures of success.
These topics establish the foundation for all of the work that will be identified in this SOW. Provide as much detail as possible so everyone has all the pertinent information and has the same understanding.
Scope
Write down all of the features and functions that will be built to accomplish the goals stated in the background section.
In this section, answer the following questions.
-
Training: Who is training users on the new features?
-
Change management: Who's building internal support for the project?
-
Post go-live support: Who supports the software after the launch and for how long?
-
Data migration: Who moves the data from the old systems to Salesforce?
-
Integration: What external systems need to connect to Salesforce and who does the integration?
-
User acceptance testing: Who tests the new software to confirm it’s fit for its purpose?
Include what’s out of scope, or the work items your team is not going to do. This helps you defend your work later on if the customer asks for more features.
The customer wants to know how everything in scope will be built. You cover that in the approach section.
Approach
Explain the methodology—or approach—for how you plan to build the scope items.
Identify how:
-
You as the consultant are going to work.
-
Your customer is going to work.
-
You and your customer teams plan to work together.
Don’t just state methodologies like Agile, Waterfall, or Hybrid. Identify the project phases, inputs and outputs of each phase, key milestones, sign-offs, project management, and quality management processes. This is especially important when working with customers that approach project management differently than how we do in the software industry.
Now that you’ve stated how you’re going to work together, it’s time to identify the work that’s going to get done.
Customer Responsibilities
Customers also have items that they need to provide you, or customer deliverables. If a customer doesn’t meet their obligations, it’s more difficult or even impossible for your team to meet yours. Identify things that need to happen for your team to be able to do work. These are dependencies.
Also establish the roles, responsibilities, and who on the customer’s team is filling those roles.
Next, determine how your team is going to work on this project to meet your obligations.
Project Schedule and Fees
Since schedules and fees are dependent on the work you plan to do and how you plan to do it, make sure you create clear connections between this section and what you cover in scope and approach. Present the customer with both the costs and the speed that they should expect the work to be completed. If either of these don’t meet the customer’s expectations, discuss how changes to the scope, approach, or cost can help them achieve the desired outcome.
In this section, include details on:
-
Roles: who is doing what on your team.
-
Timelines: when the customer should expect the deliverables.
-
Travel expenses: who’s covering which expenses.
-
Rate table: what the hourly rate is for each project role.
-
Pricing model: how and when your team charges for their work.
While an entire Trailhead module could be dedicated to pricing a project, it’s worth calling attention to the two main methods.
-
Fixed rate: This is when the customer pays a fixed amount for the entire project.
-
Time and materials: This is when the customer pays only for the hours worked.
Whichever method you choose, make sure there’s clarity around what happens if or when something changes in the scope.
Now that you’ve stated what work is getting done, how it’s getting done, and who is doing the work, it’s time to state what happens when the work gets done and what happens if it doesn’t.
Terms and Conditions
This section provides you with legal protection if things go off track.
Here are a few examples of terms and conditions.
-
Change order: If the customer wants to make a change to the project, they’re required to submit a written request
-
Termination: If either your team or the customer’s—or both parties—wants to end the contract, this establishes a process to make it go smoothly.
-
Warranty: This is where you promise to deliver a quality of work that is reasonably free from issues.
In addition, most SOWs are governed by a professional services agreement (PSA). A PSA defines the terms for how you as the consultant and the customer interact.
We suggest having your lawyers talk to your customer’s lawyers to iron out any differences.
Finally, while every project assumes certain things as given, it’s a good idea to explicitly call these out.
Assumptions
There are a lot of unknowns at the start of every project. Scope, timelines, and costs are often presented with the assumption that certain conditions are true, certain dependencies are met, and certain undiscovered issues don’t arise.
Be as thorough as possible in defining assumptions. Use your knowledge from previous experiences implementing similar solutions, working with the same customer, or working in the same industry. At this point, state exactly what you assume the customer is going to do in the course of a project.
For example:
-
Are they taking on part of the scope?
-
If you ask a question in an email, how long does the customer have to respond?
-
If your resources are required to be on-site, what kind of office equipment or network access do you need?
The more detail you include for this step and the other six steps, the better prepared you’ll be when something unexpected happens.
Address Feedback Like the Pro You Are
You’ll most likely get feedback on your SOW. This is good! It shows that your customer is interested in the project and wants the work to get done.
Here’s what to consider when you receive feedback.
-
Be ready to defend your SOW: Customers will ask questions on every aspect. Be ready to articulate your reasoning for each section of the SOW, and connect the goals to the scope, timeline, method, and fees. The more clearly you connect the different points, the less pushback you’ll get.
-
Understand the different ways to reduce cost: The customer will probably ask for a lower price. Here are three ways to lower the cost:
-
Reduce the scope: Lessen the amount of work done.
-
Lower the hourly rate: Charge less for each hour of work.
-
Provide a discount: Reduce the overall cost of the final project by a specific amount.
-
Avoid reducing the estimated number of hours of work while keeping the scope the same. This approach can create problems down the road.
Bringing a project from idea to reality is a big challenge. Follow these steps to create a best practice SOW so that all parties are happy with the idea and the finished product, and set your customer up for success.
