SOW (Statement of Work)

The next thing that you want to do is start working on your Statement of Work (SOW), a crucial document that you will constantly update and use as a baseline for your project. Depending on the size and complexity of the project, and your knowledge about the subject matter, you will need to organize meetings with the stakeholders in order to refine the SOW and get it approved. A well-thought out SOW generally contains the following sections:

Executive Summary

Provides a short overview on the purpose of the project, its background, its scope and sometimes a high-level project plan. 

Goals & Objectives

Describes the objectives of the project. The majority of project management literature recommends SMART objectives that are:

• Specific: your objectives must be clear so that if someone reads them, he or she can interpret them without ambiguity.
• Measurable: you should be able to measure whether you are meeting the objectives or not.
• Achievable: do not try to attempt more than you can.
• Realistic: do you have the resources to achieve your objective?
• Time-specific: specify when an objective will be attained (date)

Project goals example:

Goal	Team Role
Satisfied customers	Product Manager
Delivery within project constraints	Program Management
Delivery to product specifications	Development
Release after addressing all issues	Testing
Enhanced user performance	User Education
Smooth deployment and ongoing management	Logistics Management

Scope

Details the scope that you identified in the Executive Summary of the SOW. In this section, describe the work that will be done. Also, if required, explain what will not be done – this is especially useful to avoid confusion. Note that the Scope section is one of the most important sections of the SOW. Therefore, be very specific when writing it.

Deliverables

A list of the deliverables to be produced by the project. Describe each deliverable in an unambiguous manner that is understood by the team member responsible for it.

Examples of deliverables are:

• Project plan
• Requirements document
• Design document
• Source code
• Test plan
• Test cases
• Release notes
• User guides

Assumptions, Risks & Constraints

There might be a number of unknown issues while you are planning your project. For such issues you need to make assumptions, which constitute a risk. Typical project risks are associated with timeframes, and availability of resources (funding, project team members, supplies, etc.). Detail the identified risks in your project and include contingency plans for each risk. There might also be some constraints on the delivery of the project, e.g. time or cost constraints which are also part of the project’s assumptions and might be treated as risks.