Start your SOW with the information in your Scope Statement. All the elements captured in your Scope Statement should appear in your SOW. The Scope Statement tends to capture the deliverables of your project at a high level; your SOW will contain these deliverables, when they are to be delivered by, and how the deliverables will be built. The SOW should also contain information about deliverables at a more detailed level. For example, if your Scope Statement includes an order capture and management system, you might break that deliverable down into a database to capture, store and track the information, a front end to interface with users and a reporting system to manage reports.
Wikipedia provides us with a standardised checklist of SOW information categories:
• Scope of work: A detailed description of the work, the software and hardware to be used, and the exact nature of the work.
• Location of the work: Where the location of the work to be done would be other than a standard location. This would be applicable to an SOW for work to be performed offshore.
• Period of performance: The start and finish date for the project, maximum billable hours per time period, etc.
• Deliverables schedule: Due dates for the deliverables of the project. This would include completion dates for development, QA testing, User Acceptance Testing, etc.
• Applicable standards: Industry standards or other standards imposed on the project deliverables. These should include any standards such as ISO, CMM, CMMI, etc.
• Acceptance criteria: These would include any quality standards that must be met, for example zero priority 1 defects. They should also include any other conditions that must be met such as number of test cases, number of test cases executed, etc.
• Specialised requirements: These will include any special qualifications for the workforce, such as a PMP certified Project Manager.
Scope of work, period of performance, and deliverables schedule are all mandatory information. The rest are optional and will only apply to those projects where they are applicable. For example, noting that work is to be performed in the performing organisations office space adds no value. Noting the work space, and who is responsible for providing it will be relevant to a SOW covering work to be done by a consulting organisation.
The scope of work to be performed should include administrative work as well as work on the project deliverables. Administrative work also includes project management work. You may not want to include project management work if you will be performing the work for an internal client. On the other hand, including it will help to set client/sponsor expectations. Include the reports and other communications you intend to use to keep your stakeholders informed on project progress. You should also include any information that you will need from the team, such as progress reports. Include administrative work such as entering project time into a time tracking tool, if the use of such a tool isn’t a standard operating practice for the project team.
Don’t try to capture too much information about deliverables or how the work will be done. Remember that you set expectations when you put information in the SOW. It will be difficult to change anything you’ve captured in the SOW (you’ll need a change request approved by your sponsors or customers). You should not attempt to capture details about deliverables for projects where an iterative SDLC is used. Describing the methodology to be used and only the major deliverables will be sufficient. Using a Waterfall methodology will allow you to capture more detail about doing the work and the project deliverables.
