So you’ve been tasked with creating a Statement of Work, or SoW. That powerful document that details everything including a project’s purpose, resources, schedule, milestones and costs. The supporting contract document and blueprint that keeps the project on track.
And you’re going to write it.
Sounds a little daunting, right? It doesn’t have to be. While it is a very detailed document, its just a way of capturing the facts in a clear and logical order, and you can tap into several resources to get the information you need. You will want to engage your stakeholders, subject matter experts and leadership for their input.
What’s in an SoW?
Most Statements of Work follow a standard format and include a common set of contents. You’ll have to decide what is most important to include based on the scope of your project – but here are some of the greatest hits of SoW’s, and the ones you probably want to consider:
This is your statement of what the project/engagement is and what work will be done. Provide a brief backstory of the issues that led to the need for a solution; this will sets the stage for the explanation of the proposed solution and the project. Limit this section to three or four paragraphs that include details like:
- The need for the project, including a description of events leading to this need
- A description of how the work relates to the company’s missions and priorities.
- Key terms and acronyms that will be used throughout the SoW
- Any additional background information that would be useful in clarifying the project
Purpose & Objective
This statement explains why the project is being launched. The purpose statement should clarify the problem(s) that need to be solved. You want to write well-defined statements of what is to be achieved in order to successfully fulfill the project’s purpose. A well-defined objective statement looks like this:
The purpose of this project is to design, build, test and launch a more comprehensive order management system that will provide more specific order detail and enhance the order fulfillment organization’s capability with satisfying customer requests.
Scope of Work
The Scope of Work clarifies what the overall Statement of work does and does not include – it defines the limitations of the work to be performed during the project. The scope is meant to explain the intent of the engagement – not to explain of how the work will be done. This section also prevents “scope creep”, by serving as a reference when new tasks are introduced or requests are made. Your scope should include:
- An overview of the phases, tasks and activities of the project
- A description of the methodology to be used
- A description of the physical location where work will be performed
- The project timeline including phase completion and stop/go decisions (a process map would be a great visual here)
- Identify any work that would not be performed by the project team (out-of-scope)
Document the amount of time that is scheduled to complete the entire project from beginning to end. You should determine and include:
- How long should each deliverable take to complete
- How many hours are allocated per week, month, or sprint
For visual people, a snapshot of your timeline or Gantt chart can be a great way to support the schedule.
These are the outputs of the project and evidence that the contract requirements were met. Write in clear and simple language, getting very specific about how deliverables should be submitted, and give clear instructions for how they will be evaluated for approval. Be sure to:
- Link the deliverable to other objectives and deliverables
- Distinguishes the deliverable from anything related (technical writing vs. training development)
- Describes the testing that will verify that it meets the requirement
- Provides a means to measure the quality of the deliverable throughout the project lifecycle
- Describes the evaluation and acceptance process
Here’s the idea:
- Creation of End User Instructions by Technical Writer, final draft due by 12/12/2019, to coincide with product release and training plan
- Technical Review of documentation must be conducted between Technical Writer and SME within one week of submission
- Documentation approval based upon determination of accuracy during technical review
- Rejected documentation must be revised and resubmitted within one week of result
These are the activities and milestones that need to be completed to meet the larger deliverables. You’ll describe the work to be performed, and you can write them as processes with specific milestones. Clearly written tasks are also important for reducing scope creep. You should include:
- A detailed description of each task, with specifics on how one task relates to another (i.e. how does testing relate to development?)
- Specific start and finish dates
- The timeline and deadline requirements for each task
- An estimate of hours required to complete the task
- Detailed information on each resource including staff, software, equipment, and contractors
- Any internal or external project dependencies
- Every project task in sequential order
- A clear delineation of what each team member is responsible for
So, if your deliverable is a new customer interface on your website, one of the tasks may be designing a new contact form, with a related task to write the scripting for the form. Each of those tasks will have a specific resource assigned to them, a period of time to be completed, and criteria for approval. Those are the details you will need to spell out.
Testing & Compliance
Is the product or service regulated or will it require testing to meet thresholds and industry standards? If so, state the type of compliance required, simply and clearly like this:
- All phases of development must undergo User Acceptance Testing
- System must remain in compliance with ISO 27001 standards
- Processing of customer’s information must remain in PCI compliance
Costs and Payments
What are the costs associated with each component of the project? Detail the frequency of billing and payments and how payments are issued – including how invoices are received, requirements for purchase orders and payment approvals. Payments can even be tied to milestones reached along the project life cycle.
What determines the success of the project? How do your stakeholders define project success and what are they expecting from the product or services? Gather their detailed input and define it here.
Get Sign off
The final step before you release the SoW is to get approval and sign off. You don’t want to execute a process without the authority to do so. Getting sign off also ensures that stakeholders have the same expectations and understanding as the project team.
A few language tips
Keep your terms consistent. Don’t confuse the reader by using “vendor” in the first paragraph and “supplier” in the third to describe the same party.
Spell out your acronyms. Don’t make assumptions about what the reader knows, so be sure to write out the name of the expression the first time you use it, followed by the acronym in parenthesis in your Statement of Work (SoW).
Use direct language to describe the responsibilities of your resources. Words like “must”, “shall” and “will” are important distinctions from words like “may” and “should” which are too ambiguous for the SoW’s purpose.
Clearly, the Statement of Work is no small task, but it is your best tool for maintaining control over your many project management responsibilities and keeping your team operating at the highest possible standard. It will help you set expectations, avoid conflict and resolve issues, and deliver world class results every time.