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
Wikipedia provides us with a standardized checklist of SOW
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
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
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
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.