A Statement of Work (SOW) is a project management document which describes the work that is required of an external contractor, vendor, or supplier. It can either be included within the contract documents or simply be a reference for the project management team.
Also called Terms of Reference, the more generic Statement of Work is used by the Project Management Body of Knowledge (PMBOK) to refer to the technical work description for a component of a project. The Request for Proposals (RFP), Request for Quotation (RFQ), and Invitation to Tender (all equivalent) include the SOW, but add to it the non-technical stuff: Bid submission instructions, general specifications, insurance requirements, and so on.
In large organizations, the technical department that manages the work writes the Statement of Work, and the procurement department writes the RFP/RFQ/Invitation to Tender.
A Statement of Work contains the following parts:
- Tasks
- Deliverables
- Schedule
- Coordination requirements
- Laws, regulations, and standards
- Resources provided
Tasks
A task list is an integral component of a Statement of Work (SOW) as it outlines the specific activities that need to be accomplished within a project or contract. This list serves as a detailed roadmap, allowing you to define what work is part of the project, and what work is not. By including a task list, the SOW provides clarity on expectations, ensuring that all parties involved have a mutual understanding of the project scope.
Each task is typically described with enough detail to guide execution, often including deadlines and sometimes dependencies between tasks. It can include other meta data such as who will perform the task and how, but this is not foundational.
The task list within an SOW acts as the backbone of the project, transforming high-level objectives into actionable steps, thereby preventing scope creep and aiding in dispute resolution by offering a clear reference point for what was agreed upon.
The task list is derived from the project scope statement. If you don’t have one of those, you can itemize the work step by step to ensure all the tasks are listed.
Statements of Work sometimes, but not always, become part of the contract with an external vendor/subcontractor. If this is the case, it is important to be comprehensive. If even one thing is misunderstood the contractor may have grounds for requesting additional funds for work that is outside of the contract. It may seem hyper fussy at times, but there is a reason lawyers write pages of stuff to try to cover every remote possibility that could ever occur. There is simply no quicker way to resolve a conflict than to have the solution in the contract, no matter how fine the print.
Deliverables
Although the word Deliverables is not in the english dictionary (any that I’ve seen), and MS Word underlines it as a spelling mistake, it is very much in the the dictionary of project management. A deliverable is anything that must be ‘delivered’ to the client, customer, or owner. This can be a tangible item like a vehicle, or an electronic submission like a report, or even just a data set. It can also be a service, for example a training course.
Every project has deliverables which are produced for its stakeholders, and when a subcontractor is selected for a portion of the project, they have their own deliverables to the project.
These deliverables must be specified in the Statement of Work. If you can’t readily define what the vendor needs to provide you, then the project scope needs to be reconsidered and the deliverables further refined. Likewise, if you are a contractor reading a Statement of Work that doesn’t strongly define its deliverables, you should ask for clarification.
Schedule
Virtually every project has a schedule as a major requirement. Since a project is defined as a temporary endeavor with a defined beginning and end, the timing of that end point is usually a major consideration in project success.
Because of the critical nature of this item, the specification of project milestones and completion dates is usually a good idea within the Statement of Work. Likewise, a definitive contract completion date is much better than a range, or a flexible date.
Coordination Requirements
The tasks and deliverables define the work that must be completed, but usually projects don’t exist in a bubble. There are often other stakeholders or third parties that must be coordinated with or kept informed. Sometimes there is data that must be shared, or services that must be provided, to someone within the organization in order to perform the work.
Specifying these coordination requirements within the Statement of Work ensures that there are no bottlenecks to performing the work that lead to potential claims for extra work (money) that is outside the contract. In most jurisdictions, reasonable notification of impediments to carrying out a contract is a legal requirement enforceable by law.
Laws, Regulations, and Standards
Few projects these days are not directly impacted by government legislation. Environmental and safety regulations have gotten more stringent every year for many years. Whether environmental, safety related, employment based, or any other area, the work detailed in the Statement of Work often must satisfy legal requirements, which often requires resources that have budget and schedule implications.
Likewise, the work usually must conform to standards. Engineering, municipal government, environmental, or other stakeholder standards must be followed when performing the work. These standards should be specified within the Statement of Work to ensure that contractors know what is expected of them.
Resources Provided
Often the project must provide resources to contractors to enable them to perform the work. This can include data, equipment, or facilities. Data sets can introduce efficiencies in the performance of the work, and equipment and facilities can reduce the cost of the work. Any items that will be provided to the contractor should be specified so that there is no confusion.
Leave a Reply