A Statement of Work (SoW) is a document (usually a legal contract) that formalises an agreement between two parties (Client and Supplier). An SoW should document the “Why,” “Who,” “What,” “How,” “When,” “Where,” and “How Much?” of what’s being delivered, capturing the understanding of both parties so that the remit is clearly understood.
When creating a SoW, the below high-level structure can be used as a framework. The level of detail created should be appropriate for the engagement and requirements of both parties.
Why is this work required? For example, what problem statement is this SoW addressing and what business need does the work address?
Top Tip: Try to include benefits you wish to realise from the project. This will help you later when tracking these and when tracking the project ROI.
Scope of work
What work will be delivered? Provide as much detail as you can around the outcomes you’d like the supplier to be accountable for. Also state what WON’T be delivered.
Top Tip: If you can’t articulate the scope in detail, perhaps you need a SoW for discovery, with the outcome being to define the specifics of the SoW. The more detailed you can be here the better (and the lower the risk of scope creep or change requests!).
The schedule should outline When, Where and How the work will be delivered and Who will deliver it:
Does the project have a fixed timeframe with pre-agreed delivery dates, or does the work require an amount of effort (e.g. 100 x 8 hour days) but no date constraints by which the effort needs to be expended?
For either option, it’s important to ensure the time or effort is fixed to the scope. Additional scope can be impact assessed and delivered as a project change or as a new SoW.
Onsite vs remote vs hybrid
Certain activities may require onsite with other activities being location agnostic.
The schedule should cover how the work has been planned, e.g. is the work phased as design / development / test / release in a waterfall or in an agile methodology?
The schedule should show what skillsets are required to deliver the tasks within the plan e.g., project management, design, development, testing
The schedule should also reflect the expected level of resource required to deliver the tasks.
Deliverables (including acceptance criteria)
The specific outcomes that will be delivered to achieve the objectives of the SoW
To facilitate the sign off of the deliverables, acceptance criteria should be specific and objective, and include who in the Client organisation is responsible for sign off.
Top Tip: Our data shows that defining acceptance criteria reduces error rates by over 90%. Ensure you take the time to document the format, standards, and quality you wish to see.
The SoW should cover key management activities including:
- Meeting / Reporting Requirements
- Identified Assumptions
- Responsibilities / Dependencies (calling out what the Client is required to do is key for this work to be successfully delivered)
- Identified Risks
- Escalation Process.
The SoW should specify the charges attributed to each payment and what activity / deliverables need to be successfully delivered to achieve sign off for each payment.
Top Tip: Be sure to check that all charges are included here. It is not uncommon for some providers to include ‘hidden’ additional costs. Also, another common tactic is for the initial costs to be low, with the provider charging significant sums for inevitable change requests. For information on Rullion pricing see “how much does Rullion Change Delivery cost”.
A SoW can cover a range of work, from simple to complex, but it’s important to ensure that what is being captured is clearly understood. If there’s a large level of detail (e.g. thousands of tasks) then it’s more effective to create a higher level view in the main body of the SoW, and to capture the detail in an appendix to the SoW.
Struggling to write your SoW? We can help.
Download our SoW Template or if you would like to discuss how to shape your requirement, request a free SoW review from our team using the enquiry form below.