What is a Statement of Work?
The SOW acronym Statement of Work template is a simple formal document with all the details of a given project or work. Typically, SOW acts like an agreement between two parties in which one of them is a customer, and the other is a vendor or supplier. A good SOW usually has Purpose, Scope, Timelines, Costs, Payments, Reporting Requirements, Change Requests procedure, and a few other things depending on the type of work or project.
What should a statement of work contain?
Purpose can be defined at the company level and used across projects. Typically, SOWs form a contract between various parties involved.
Summary is a brief point by point description of the services required from the vendor or the delivery party. The summary can also contain a bit of information about the work or project that is to be delivered.
Background is detail about why we needed to get this work done.
This section of the document will detail the schedule for the project or task undertaken. This can be displayed using a Gantt chart or a simple table explaining the start and stop for each phase. When drafting timelines, it is essential to include some buffer or contingency if some tasks take longer than expected. Typically, post-completion support or post-go-live support is also added to the timelines. This post-go-live support is for any issues which are identified after the project is completed.
A payment schedule will explain how the payments will be made. Depending on the project and the parties involved, there are a few differences this could be handled. Most of the time, payments are made after each of the phases are complete. Below is an example of a payment schedule for a software development project.
Location of Work
It is essential to cover the location where the actual work will be done. Depending on the type of work, the vendor or customer might have to make special arrangements. This is true for especially projects where the work location is in a protected or hazardous area. Also, giving the details of the location ensures that the vendor can organize resources and/or make travel arrangements.
For example, when working on companies that have top security requirements, then the people on the project will need special clearances.
In this section, the customer will also mention how access will be arranged for the vendor. The vendor can even specify any special requirements they might have. For example, what will be working hours and when should the vendor be onsite, etc.
Statement of Work Template - Requirements or Specifications
This is the central part of the document. Here we will define all the work to be done by the vendor. The more detail, the better in this section. This is also a good point in the process to point out any particular criteria that you would like to use to verify the work being done.
Depending on the type of project and organization, this section of the SOW should contain line items for each of the deliverables delivered. For example, for a software development project, this section will have details on the project's system requirements.
This section described any contractual obligations and expected behaviors of the supplier, from the obligation to comply with organizational standards and procedures to ethical considerations that should inform their actions. An excellent place to get information is to look at your existing company policies and procedures.
For example, the customer might need that adhere to a specific dress code when working on their office premises. There could also be a requirement to undertake specific compliance-related courses before the work is started. Also, typically all the contractors are expected to follow all the values or integrity processes defined within the customer's organization. The contractor has to ensure that all the work is done with integrity.
Here are some of the sample contractual obligations:
- Keep all documents and proprietary information confidential;
- Work on-site for the duration of the contract;
- Meet all tasks, deliverables, and milestones as identified in this SOW;
- Return all materials belonging to ABC upon completion of the contract;
- Maintain security clearance with no conflict for the duration of the contract;
- Comply with guidance mandated in the ‘Working with ABC’ handbook, including ABC’s code of conduct.
Performance Reporting Requirements
To ensure proper monitoring and control, the SOW should identify the metrics used to measure the supplier's performance and any requirements identifying for that progress to be reported appropriately back to the project.
One of the key things here is to agree on the metric used for measuring progress and quality. For example, in a software development project, the improvement can be measured by how much of the application code is complete. The number of defects in the code can be an indicator quality of the code being delivered.
In the case of a project management consulting project, the total progress of the entire project and how the stakeholders are managed could be a metric for progress. How the reporting and other documentation in the project are managed could be a sign of quality.
Change Requests Procedure
No matter how well a project is planned and managed, there will always be changes. Having a process for managing changes is essential. This process can be the existing process but still needs to be clearly defined. Although changes can halt project progress, they are sometimes crucial so that the project's end goals are met.
A change request process should include a change request form, who should the request be sent to, and who will be approving the change. The process should also define how the changes will be sized and how the cost of each change request will be calculated.
It is essential that all the appropriate documentation also be attached with the SOW. This could be requirements documents, request for proposals, resumes of contractors, billing rates, etc. The version of the document plays a vital role as the work done will be on the information based on the document. It is also important to note what was the source of the document. If any templates or documents were used, then they too should be listed on the templates.
Last but not least, in fact, the most critical part. This is where people who will authorize the work will sign off. This is typically signed by the company CEO or COO and their counterpart on the vendor side. Once the SOW is signed off, then the work can start.
Why Do You Need an SOW?
- Saves you time: Producing an SOW is a time-consuming exercise, let’s be honest; yet, starting with the right foundations and ensuring that you haven’t missed any essential requirement will save you time in the long run.
- Saves you cost: Most of the unplanned costs in projects come from scope changes, either controlled or uncontrolled (scope creep). By clearly writing down what the scope should look like, its boundaries, and requirements to be met, the likelihood of scope change requests is reduced, and cost savings can be gained.
- Sets clear expectations: Putting the definition of the project scope down on a piece of paper is a great way of setting expectations, not just for the suppliers but even internally. Have your project board and key stakeholders reviewing the document and use it as an opportunity to reinforce what the project is and is not and what it is set to achieve.
- Removes ambiguity: It is too easy to get confused about a particular deliverable order or understand the point of a specific feature without guidance. Clearly stating all the project scope requirements in an SOW enables a complete view of the project's objectives and provides an opportunity for questions to be clarified, ambiguity removed.
- Assigns accountability: By listing the performance criteria and performance targets by which suppliers will be measured and any other contractual obligations, responsibility is more quickly generated, enabling better delivery chances to those targets.
- Saves your reputation: In an SOW, compliance with organizational procedures and standards can be mandated, including ethical concerns, and, therefore, the company’s reputation is better protected.
Tips on Writing an Effective SOW
The content of SOW might seem to be trivial when you start working on it. But the content in SOW becomes critical once the project starts to deliver. It is important to craft the SOW to include all the details to ensure that both parties know what they are signing off on. Here are some tips on how to write an effective SOW -
- Use an existing template - Using an existing template will ensure that you have covered all the required content.
- Document all the requirements - It is best to conduct a workshop with all the stakeholders to understand what is expected of the project.
- Add contingency to dates - It is important to have some buffer in the dates you commit. Once you reserve dates, you will be held to it.
- Add contingency to budget - Having a little extra money will always be helpful.
- Payment Terms - Do not agree to pay everything upfront. Opt for phased payments or deliverables based payments.
- Cover Compliance and Regulatory Requirements - If your company has specific regulatory needs, then have them covered in the SOW. The vendor needs to be aware of any special arrangements that they need to make.
- Get it reviewed - Get the SOW reviewed by all the parties involved. This needs to be done before the SOW is actually sent out.
SOW Sample(PDF) for Software Implementation
In this sample, we will look at a software implementation for a Customer Relationship Management solution. The SOW covers the deployment, project management, and handover services provided by the selected supplier in support of ABC’s Customer Relationship Management (CRM) solution project.
The SOW captures all the key details of the project, including an introduction and background. It clearly states the objectives of the project with start and end dates. This sample uses all the sections defined in the template and is a perfect example of software implementation.
Statement of Work Template Word
- Background and Current Project
- Goals and Objectives
- Proposed Solution
- Services Included
- Functional Requirements
- Non-Functional Requirements,
- R & R (Roles and Responsibilities)
- Attachments and Appendixes