White Paper

Statement of Work (SoW)

A Statement of Work (SOW) is a formal document that captures and defines the work activities, deliverables
and timeline a vendor will execute against in performance of specified work for a client. The SOW typically
forms part of a purchase order or contract. Therefore, if the project is being performed under contract for an
external client, the work to be performed is likely to be defined in a SOW issued by the client (The Project
Statement of Work). A Project SOW may also be developed by an internal client to concisely define the
project’s deliverables based on inputs from the business case, strategic plan and other documents. If the
project needs to procure goods or services from external subcontractors and suppliers, their requirements are
defined in a SOW issued by the project (a Procurement Statement of Work).

The essence of a well written SOW is a concise narrative of precisely what has to be delivered, where and
when. Other more detailed or technical information is referenced from the SOW.

Contract documents defining the project’s scope of work:

There are a number of interrelated documents that describe the overall scope of work in a project. Whilst the
use of these terms varies by application area, the general intent of the documents should be consistent:

• Project scope: An overall statement of the work needed to be accomplished to achieve the delivery of
the product, service or result (product scope); including objectives, deliverables1, constraints and other
relevant items. The Project Scope Statement is a narrative description of these requirements including
the major deliverables, assumptions, constraints, and a description of the work to provide a basis for
understanding and agreement with stakeholders.

• Product scope: Describes the features and functions that characterise the product, service or result that
will be transitioned to the project’s customer or ‘end user’ – the deliverable. It is a sub-set of the overall
project scope.

• Specification: A document that defined in a complete, precise and verifiable manner, the technical
attributes (features) of the product service or result to be created and (usually) how they will be achieved
and tested or measured. Specifications are usually for a designated part of the overall project such as a
‘Design specification’, ‘Manufacturing Specification’ and ‘Test Specification’.

• Statement of work2: A concise description of a deliverable to be supplied (usually included in a

contract or purchase order).

1
The deliverables will include the product that is required by the customer / end user; but may also include other items
such as training, knowledge acquisition, capability development, lessons learned, etc., required by the performing
organisation and other stakeholders.
2
SOW may be created by the client to define the work of a project (the project SOW) and would typically be associated
with the purchase order, contract or agreement issued by the client to the project organisation. SOW are also created
as part of the project’s procurement processes (procurement SOW) to define the work to be performed by a supplier or
subcontractor. In the context of the PMBOK® Guide, ‘SOW’ (no descriptor) usually means the ‘Project SOW’.

1 www.mosaicprojects.com.au
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
For more White Papers see: http://www.mosaicprojects.com.au/WhitePapers.html
 White Paper
Elements of a typical Statement of Work (SOW):

Areas that are typically addressed by a SOW are as follows:

• Purpose: Why are we doing this project? The objectives3 the contract/subcontract is expected to achieve.

• Scope of Work: This describes the work to be done in appropriate detail.

• Location: This describes where the work is to be performed and (if needed) where the deliverables are
to be installed or handed over to the client.

• Period of Performance: This specifies the allowable time for the work, such as start and finish time,
number of hours that can be billed per week or month, where work is to be performed and anything else
that relates to scheduling.

• Deliverables Schedule: This lists the specific deliverables, describing what is due and when.

• Applicable Standards: This describes any standards that need to be adhered to in fulfilling the contract
including technical, quality, safety and environmental performance standards.

• Performance criteria: Applicable ‘service level agreements’ (SLA), warranties, etc – usually by
reference to annexed or public documents.

• Acceptance Criteria: This specifies how the buyer or receiver of goods will determine if the product or
service is acceptable, what objective criteria will be used to state the work is acceptable.

• Special Requirements: This specifies any special requirements, such as degrees or certifications for
personnel, travel requirements, and anything else not covered in the contract specifics.

• Type of Contract/Payment Schedule: The payments breakdown whether up front or phased and a
reference to the overarching contract.

• Miscellaneous: There are usually a few other elements that need to be added or referenced….

Defining the Scope of Work included in the SOW:

The definition of the scope of work to be included in the SOW (or any other scoping document should
comprise two elements. A description of the product, service or result to be created (the deliverables) and the
boundaries of the work (what is in and what is out of scope):

• The deliverables. The three key elements of the deliverable are a description of what it is (at an
appropriate level of detail), how you will know the deliverable has been delivered (easy for tangible
deliverables but more difficult for intangible items such as a ‘culture change’), and the quality to be
achieved and how this will be tested and accepted. The specific details are usually defined in the detailed
scope statement and specifications referenced from the overall SOW.

• Project boundaries. Boundary statements are used to define what is within the boundaries of the SOW
and are therefore to be delivered by the supplier or project, and what is outside those boundaries. The
more accurately you can define these boundaries, the better off the project will be. The nature of a true

3
For more on objectives and benefits see:
http://www.mosaicprojects.com.au/WhitePapers/WP1042_Outputs_Outcomes_Benefits.pdf

2 www.mosaicprojects.com.au
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
For more White Papers see: http://www.mosaicprojects.com.au/WhitePapers.html
 White Paper
boundary statement is that there is both an in-scope element and a relevant out-of-scope counterpart that
between then define the limits of the work. A few examples include.
o Defining which major life-cycle processes that are in scope or out of scope. For example are the
requirements filly defined or is there some work required to refine requirements? Who is
responsible for developing the support system and who will provide ongoing support of the end
users and for how long?
o Defining which of the support functions are in scope or out of scope. For instance, how much of
the training is ‘in scope’ and how much will be done as part of an organisational change
management process…. Developing the training documentation, training the trainers, training the
end users, ….. All of this work could be in-scope or the SOW may simply require some assistance
to help the organisation’s training department do the work.
o Defining which parts of the organisation are in scope or out of scope. In some cases, defining the
‘departments’ involved in the project help to define the boundaries. For instance, the project may
be applicable to the Human Resources and Accounting Departments, but the Manufacturing
Division might be out of scope. Or perhaps your project is only impacting the corporate office
while the field offices are out of scope.
o Defining what functionality is in scope or out of scope. For instance financial reporting may be in-
scope, but Human Resources reporting is out of scope.

Generally, the most important aspect of this process is writing the ‘out-of-scope’ statement. Statements such
as ‘this SOW’ does not include training (or integrated testing)’ focuses everyone’s mind on making sure
these important functions are covered off elsewhere.

_____________________________

th
First published 30 July 2011, augmented and updated.

This White Paper is part of Mosaic’s Project Knowledge Index

to view and download a wide range of published papers and articles see:
http://www.mosaicprojects.com.au/PM-Knowledge_Index.html

3 www.mosaicprojects.com.au
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
For more White Papers see: http://www.mosaicprojects.com.au/WhitePapers.html