Article Overview
Ever wondered how to write a Statement of Work document? Keep reading this article to find out more about what a Statment of Work document is and tips and tricks on how to write one.
Table of Contents
- What is a Statement of Work (SoW)?
- It’s About Communication
- What Assumptions are Involved
- What About Scope Uncertainty?
- SOW and Learning
- Who Does What?
- Closing
Step One in writing a Statement of Work (SoW) is to know what a SoW is: A Statement of Work (SoW) is a document within a contract that describes the work requirements for a specific project along with its performance and design expectations. The main purpose of the SoW is to define the liabilities, responsibilities, and work agreements between two parties, usually clients and service providers1.
In the Beginning
Use a company approved template. If there is not, there are many sample templates on the internet. Pick one that meets the company's needs and get it approved for use.
Tip 1: The objective of the project should be written in a way that the team will know what successfully done looks like.
Tip 2: Be sure to use language everyone will understand. Try limiting the use of acronyms or have a page attached explaining each acronym. Larger firms based their culture on acronyms but smaller firms, unless the acronyms are industry-specific, do not use many. Those that are unable to be removed outright, include an acronym dictionary along with the SoW as another page.
The Team
The statement of work should connect the person or persons paying for the project, you will likely have follow-up questions.
Tip 3: Clearly identify the sponsors for the project. It is important to know the source of the direction as well as who is signing the checks and as such, should be a strong influence on the scope and scope clarifications and answering questions including tradeoff decisions.
As with most project documents, especially early in set up and execution, the SoW should have a list of Assumptions. Those assumptions made at the time of writing the SoW. This information will help the readers to understand the basis and expectations of the SoW and the statements included. Remember, an assumption is something accepted as true or likely to happen.
Examples:
• The delivery date assumes ‘X’ number of hours or resources.
• The delivery date assumes the material required is readily available.
Speaking of Expectations, they should also be explained or listed.
One of my favorite Assumptions/Expectations is that the supplier will not need a lot of supervision by the Project Team. Yes, the team is available to answer questions but not live at the supplier’s facility.
Tip 4: Clearly present Assumptions and Expectations using clear communication guidelines.
The statement of work is used to focus the team on the objective and therefore limit the scope of the work. As the SoW does not provide the full content of scope, since it is early in the project, there are still opportunities for interpretation errors or extension.
Tip 5: Even if the scope of the project is not fully known when creating the SOW, be as specific as possible especially on the objective or the problem that is to be solved. The goal is to eliminate or focus the direction to avoid the exploration of errant approaches that will not achieve the objective of the project.
What challenges might someone in these industries face during the writing process, and how can they overcome them? If you expect the final product to be able to be predicted in its entirety in the SoW, then you are going to have some difficulty. The better solution is to do what you know, learn from that doing and alter things as you learn.
This will require a good measure of control over the SoW and the subsequent requirements and updates of those documents due to learning while doing. This updating must be controlled and not left to ad hoc approaches.
Tip 6: Establish a process for modifying or updating the SoW. This should include the owner of the process and signature approvals before any change to the SoW is officially released. One critical key for lessons learned is to keep all versions of the SoW for a traceable follow.
In the case of Agile projects and/or Software development projects, where one delivers the product iteratively, steadily increasing the total capabilities defined and test each instantiation of the software. Update the requirements and SoW as you go through these iterations. This update is fodder for the next iteration of the software.
Our experience is there is never enough clarity of liabilities and responsibilities. We have heard this phrase a few times, “That is not our responsibility”. In most cases a phrase like ‘Execute all the plumbing required per the plans”, is enough. Some team members will include that in the SoW attached to the plumbing contract. But, in order to be clear on liabilities and responsibilities, this could be expanded to “provide all labor and materials to install the plumbing system as designed in the approved Architectural drawings.” And could be expanded further.
Another example is when a team member shortens the description of the SoW. I once reviewed a SoW before being issued and questioned the writer about the description. The reply I received was: “We have worked with them before and they will know what I mean.” We re-wrote the SoW so it was clearer and could be sent to someone ‘we might not have worked with before.”
Do not be conservative with your words. There will always be opportunities for misunderstandings on SoW documents, and clarity on liabilities and responsibilities will reduce the number of incidents.
The word Performance has a few uses in the Project Management world. There is the performance of team members. The performance of suppliers. And the performance of the deliverable. In the description above, “…performance and design expectations” I would say performance here has to do with the performance of the deliverable. Be clear with your intent. If there is a performance expectation for the supplier include it and explain it clearly. The SoW helps us identify the details of the work required to achieve the objective. The SoW is a pre-requisite to the work breakdown structure.
These 6 Tips are presented to help increase success with writing SoWs and the deliverables received from them. There is a famous saying attributed to Aristotle, “well begun is half done.” The SoW is the beginning of the project in a tangible incarnation, from this point forward, the project is underway. Get this completed well, we actually stand a chance of creating a working project environment. Do this poorly or forget it altogether, we will rely more heavily on luck to be successful.
We would like to hear about your experiences with using the tips or tips of your own.
Additional Resources
• MIL-HDBK-245D DEPARTMENT OF DEFENSE HANDBOOK: PREPARATION OF STATEMENT OF WORK (SOW)
References:
[1] VillaNova University: What is a Statement of Work?