Statements of Work (SoWs) can be used in context where services are being supplied but become quite important in Projects given they often represent a work package to be performed by a third party. The information in the SoW will therefore be used by the Project Manager in overall project estimations and used to inform cost plans and delivery timelines. SoWs need to be structured quite differently across different project types and for different services. This article describes a Statement of Work in more detail and provides some examples of the different ways to structure them for your project.
What is a Statement of Work?
Firstly, it is important to be clear on the difference between a Project Statement and a Statement of Work. A Project Statement (often called a Project Charter) is an internal document with the scope, objectives and other information that forms the promise between the Project and its sponsors. A Statement of Work is a legally binding agreement or contract between one entity and another to provide services for an agreed price, over an agreed duration.
There are usually two parties to the SoW:
- The Supplier (or Vendor) of the work
- The Client or recipient of the work
For a Client-side Project Manager the use of the Statement of Work will differ depending on the size and complexity of the Project. There may be several SoWs to manage during the Project lifecycle (for example one for the ‘product’, with separate SoW for a different service provider to test the product).
For a Supplier-side Project manager, the SoW may form the structure for the end-to-end Project i.e. to successfully deliver and receive payment for the product to the client.
Statement of Work examples in different methodologies
Waterfall
In Waterfall Projects, the SoW format will follow the overall project structure and should be captured as a work package in the Work Breakdown Structure. The SoW will define the deliverables and the time required to deliver them. These attributes would usually be estimated up front to cover the full delivery and acceptance of the service to completion. The vendor will likely receive milestone payments based on deliverables or time complete and the overall cost will be fixed at a maximum amount (the most the Client will pay) or minimum amount (the estimated cost which may increase based on time or materials consumed by the vendor).
Agile
In Agile Projects, the SoW needs to be structured differently to allow for iterative scope development and refinement. The roles and responsibilities (for Client and Supplier) need to be very clearly laid out to ensure adherence to the project methodology. Given an SoW is prescriptive in nature, it will need to be adapted to fit an Agile project approach. Examples of the different ways to adapt the SoW for Agile can include:
- Definition of Scope: Rather than have a detailed list of deliverables, the high level requirements and product scope can be defined. Detailed deliverables may change per iteration but the high level scope ideally should remain the same and allow governance of the vendor’s performance.
- Iterative timeline: The assumed iterations (Sprint, Program Increment, Release etc.) can be documented and vendor services boxed within each. At the beginning of each iteration, the Client and Supplier representatives can agree to the work and other relevant information required to provide and pay for the required services.
- Unit based cost model: The costs could be agreed as a unit cost based on time (iteration) or on completed work (story point). Depending on the unit, the Project Manager can control the vendor costs by monitoring the quality of delivery per unit.
- Definition of Done: No matter what the methodology, the Statement of Work cannot be open-ended and to govern completion a Definition of Done will help. This can be based on number of iterations complete, number of features complete, acceptance criteria met or any number of other ways that are measurable and specific enough to close the contract when complete.
It is important to remember that a Statement of Work is a contract and therefore comes with all the legal and compliance requirements that make sure it is enforceable and accounts for risks such as supplier failure and scenarios such as disputes and (worst case) contract breach. As a result, before you undertake an SoW it is important to seek guidance from your legal or vendor management team within your organisation.