Writing the SOW

The Statement of Work, or SOW, is the bible for the work the project must produce. The SOW is a key governance tool whether it is being used to direct work for a vendor or contractor, or it is being used to direct the work internally, the SOW must contain a description of all the work that is expected. The description need not be at the detail level, indeed for large projects capturing detail in the SOW is not practical, but should be comprehensive and include work that produces the projects deliverables as well as administrative work such as project reporting.

The SOW will form a key part of the contract if the work is being done by a vendor or contractor. Work captured in this document is part of the vendor’s contractual obligation to you. Work not contained in the SOW will only be done if it is mutually agreed upon, or introduced to the project through a change request. The SOW is also important to the internal team, although there are no legal implications, because resourcing will be planned to accommodate only that work described in the SOW. This article was written for the purpose of providing the project management practitioner with tips and tricks for producing an effective SOW.

Do I Need an SOW

The SOW is a valuable organizational tool to capture the work of the project. Its value lies in its ability to capture all the critical work elements of your project and is useful in 2 situations: to form a part of a contract with an external vendor or consultant, or as an intermediate planning step for a large complex project where the work is being done internally. You don’t need an SOW when your project is small and simple enough for you to directly translate your Scope Statement into your Work Breakdown Structure tool (e.g. MS Project).

An SOW is very helpful when the project is large and complex because it allows you to engage Subject Matter Experts in the type of work to be performed who don’t have access to MS Project. Descriptions of the work to be performed can be contributed by anyone with written communication skills and a technical command of the work. The SOW also serves as a communications tool, communicating the scope baseline for the project.

When to Write Your SOW

The SOW should be written after your Scope Statement, during the planning phase of your project. Your Scope Statement should be written first and it should capture, in very general terms, the product of the project. Let’s say your organization is launching a project to develop a software based system to capture and track orders for software. Your Scope Statement would include that language. It would probably also include a list of the users it should support such as order entry clerks, software engineers who configure the orders, managers who generate reports from the system, and shipping clerks who ship the orders. You may also include the features you want in the system, such as whether it is internet or intranet accessible, how many orders it is to store, what information it should store about each order, how the system will collect payment for the order, etc. The Scope Statement will give you information about what it is you need to build.

Now that you know what it is you are building, you need to capture details on how you are going to build it. Now you need to author your SOW. The Statement of Work defines the work to be done, so it must be written before the work can be scheduled, or broken down in your Work Breakdown Structure.

What Goes into the SOW

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 standardized 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 off-shore.
• 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.
• Specialized Requirements These will include any special qualifications for the work force, 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 organizations 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 organization.

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.

Next Steps

Your next step will be to have your project sponsors, or the customer for the project, approve the SOW. The SOW will now become the official scope baseline for your project. Anything detailed in the SOW must be present in the final product.

Your SOW captures the work the project team will do, but at a high level of detail. You will need to break these items down further in order to complete your Work Breakdown Structure (WBS). You may find that uniquely identifying each item in your SOW will help you ensure that all the deliverables and work packages described in your SOW are represented in your WBS. You should also check your SOW against the Scope Statement to ensure that all the items in the Scope Statement are represented in the SOW.

The start and end dates you capture in your SOW should be captured in your WBS. If you are using MS Project or similar tool to support your WBS, the start date will be the first entry in the tool. You will use the end date as a constraint. Once you have completed the capture of all the information in your WBS, the breakdown of that work, and the scheduling of the tasks, you will need to check the resultant end date against the end date from your SOW. You will use the schedule dates from your SOW for major deliverables in the same way.

You should use your SOW as a communications tool to explain the work of the project to your stakeholders. You can do this by posting the SOW on a publicly readable site with other project documents for public consumption. Remember to update the SOW when a change that modifies the work of the project is approved.

Taking care to capture the right information about the work of your project, taking pains to ensure the information is as accurate as possible, and making good use of that information for the rest of your planning activities will save planning time down the road. Just keep in mind that it is a "living” document and that changes to any elements represented in the SOW should be reflected in it.

The tips and tricks described in this article are intended to help the project manager using the best practices promoted by the PMI. Project managers who are certified have already implemented those best practices. If you haven't been certified as a PMP^® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.