Organization Name

Statement of Work for

[Project Name]

Prepared by: Your Name

Version: Version Number
Document Id: Reference Number or Document Id
Date: Release Date
Statement of Work [Project Name]

TABLE OF CONTENTS
TABLE OF CONTENTS..............................................................................................i
1. Background......................................................................................................................1
2. Objectives........................................................................................................................1
3. Scope................................................................................................................................1
3.1 Inclusions...................................................................................................................1
4. Work Approach................................................................................................................1
5. Key Project Deliverables.................................................................................................2
6. Staffing, Roles & Responsibilities...................................................................................3
6.1 Staffing.......................................................................................................................3
6.2 Roles & Responsibilities Matrix................................................................................3
7. Management Approach....................................................................................................4
7.1 Deliverable Acceptance Management........................................................................4
7.2 Risk Management......................................................................................................4
7.3 Change Management.................................................................................................5
7.4 Issues & Problem Management.................................................................................5
8. Progress Reporting and Communications........................................................................5
9. Project Plan......................................................................................................................6
10. Appendix........................................................................................................................6
10.1 Initial Risk Management Report..............................................................................6
10.2 Forms and templates (customized for the project):..................................................6
10.3 Other related and relevant documents......................................................................6

< Insert Revision Number and Date of Issue > Page i

Statement of Work [Project Name]

General instructions in developing a statement of work from this template:

 Project SOW’s must have the following components:
 Cover
 Table of Contents
 Background
 Objectives
 Scope
 Inclusions
 Exclusions
 Work Approach
 Development Methodology
 Major Activities (or Phases, Activities and Tasks)
 Technical Environment
 Key Deliverables
 Deliverable
 Responsibility
 Acceptance Criteria
 Staffing, Roles and Responsibilities
 Organization Chart
 Workgroups
 Roles & Responsibilities matrix
 Management Approach
 Acceptance Management
 Change Management
 Risk Management
 Issues & Problem Management
 Communications & Progress Reporting
 Baselined Project Plan
 SOW from each workgroup (abbreviated form)
 Appendix
 Attach templates, forms, references
 Initial Risk Management Report
 All instructions, tips and recommendations that you find within the template will be preceded by a
bullet-arrow and italicized. Remove these when you are finalizing the template.
 The document Cover must have
 CO or Agency Logo
 Document name (i.e. Statement of Work)
 Project name
 Preparer’s name and title
 Department/division
 Date submitted (manually typed, do not use computer-generated dates. This also serves
as the version reference.) The same manually typed date must be on all footers on all
pages of the SOW.
 For major projects (eg. monitored by OIT) All the sections and sub-sections are mandatory. For
simpler projects, the minimum requirement is that the SOW must have all the major sections – The
section entries do not have to be elaborate. The Management Section may be compressed but
ensure that the following are addressed: how deliverables will be submitted and approved, how
changes to the scope of work will be handled, how status will be communicated.
 Section entries must be brief and to the point.
 Name names as indicated. Name functions or titles as indicated.
 Spell-check before submitting for review and approval.
 Submittal process:

< Insert Revision Number and Date of Issue > Page 3

[Project Name] Statement of Work

1. Submit to Project Sponsor for review

2. Project Sponsor will endorse or return SOW within 2 business days.
3. If rejected: revise and repeat submittal process from step 1.
4. If signed: furnish signed copies Project Team, keep original in Project Notebook
 Any subsequent revisions to the SOW and baselined project plan have to be tracked and approved
via the Change Procedure described in the SOW.
 Do not state any ASSUMPTIONS in the statement of work. Rationale – assumption statements are
passive and have no clear drivers, timelines, and resolution plan. Transform assumptions into
either of the following:
- a scope statement,
- a roles and responsibilities statement,
- a “basis for estimate” statement within an Effort and Cost section if provided
- a risk statement
 Examples of assumption conversions:
Example 1:
Statement: It is assumed that the development environment will be available not only during office
hours but during weekends and holidays.
Transform into a risk statement: Should the development environment not be available during
weekends and holidays it will impact the project schedule by x weeks. The following steps will be
taken to mitigate this risk
(a) x will do this….. (b) y will do that…..
Example 2:
Statement: It is assumed that there will be 7 workstations available to the project team at the start
of the project initiation phase..
Transform into a roles and responsibilities statement: The IT Manager (specify name) shall
provide 7 workstations to the project team at the start of the project initiation phase.
Transform it into a risk statement as well, if it will most likely occur: Should the 7 workstations
not be available …… it will delay the project start by ….. The project manager will…. In order to
mitigate this risk.

Page 4 < Insert Revision Number and Date of Issue

>
Statement of Work [Project Name]

1. Background
 Describe relevant history that precedes the project.
 Describe the business drivers for the project or the problem or opportunity being addressed.
 Describe this project’s relationship to other initiatives or projects (eg. Dependencies, function of this
project in relation to a bigger picture)

2. Objectives
 Given the historical background and drivers (this is why Background must come before Objectives), state
what the project must accomplish. This should be brief and high-level– describe the final outcome that
will address the problem or the opportunity described in the previous section.
 Example: “The objectives of this project are:
- to install and make operational a shared services repository that would ensure centralized
documentation, facilitate shared services searches…….and,
- to develop standards for developing and documenting shared services that would ….

3. Scope
3.1 Inclusions
 Define what is included using metrics whenever possible.
 Provide specific details to ensure a complete and unambiguous understanding of the boundaries of the
project.
 Avoid a description of how work is to be performed – that is covered in the Work Approach
 The difference between objectives and scope – Objective describes the primary product(s) of the project
(eg., A PKI infrastructure, a shared services repository, an application system, a new section in the STA,
a new convenience contract process, etc) and the goals to be achieved by producing those products.
Scope describes the boundaries within which those products will be developed, delivered and deployed
(eg. Dept. of Transportation’s Purchasing Department’s administrative support section, or Statewide
mainframe platforms, or pilot effort or proof of concept effort only, etc).
 The scope statement is the foundation for the subsequent documents that further refine the project
coverage, such as business requirements, functional specifications, and infrastructure specifications
documents.
 Useful questions: what business area is targeted? What function within the business area is included?
Are the following included: conversion, training, interfaces, transition, maintenance and operations?
 Remember that some would-be assumption statements should probably be converted into scope
statements.
3.2 Exclusions
 This helps further define boundaries by clearly stating what is out of scope.
 Must be shorter than Inclusions.

4. Work Approach
 Describe how the work is to be performed – if a formal methodology will be used, provide a concise
description here. (E.g., “This project will use the Method/1 waterfall software development life cycle”)..
 Describe the major activities from the project plan. Do not include all the project plan details in this
section.
 State that the project plan is attached and includes ALL the tasks that must be carried out by the project.
 The Technical Environment wherein the work will be performed may be described here, if relevant (and
because it has a direct impact, on how the work is performed).

< Insert Revision Number and Date of Issue > Page 1

 [Project Name] Statement of Work

5. Key Project Deliverables

 List all the major project deliverables – these usually correspond with the major project activities
described in the Work Approach section – and may be combined with that section as long as it does not
become cumbersome.
 Interim deliverables may be included in this list if the final deliverable requires a lot of effort and a long
time to complete. I.e., some interim deliverable must be shown to demonstrate progress towards the final
deliverable.
 Signing-off on the interim deliverable may also be done to officially confirm direction and avoid the risk
of complete re-work.
 Work Products do not need sign-off and need not be listed under Key Project Deliverables. Work
products include status reports, issues log, change request log, risk mgt report, deliverables log, meeting
summaries.
 If the project involves various groups, identify the function or role responsible for producing the
deliverable. This information is to be reinforced in the Roles and Responsibilities section.
 Determine a criteria for acceptance of the deliverables. If details are unknown at SOW time, specify
when these criteria will be finalized and the medium (eg. “A document outline and a description of the
sections for document X will be provided during ActivityX-TaskX. This has to be approved prior to any
work commencing on production of the deliverable”, or “A layout of the report will be submitted for
approval…”, or “Coding standards will be drafted and approved …”).
 Indicate who will review and sign-off for approval.
 State that the deliverable due dates are indicated in the attached in the baselined project plan.
 This section is the basis for the Deliverables Log – maintained through ABT Project Workbench.
 Note that use of tables – rather than a narrative – to ennumerate the deliverables is preferred (even for
simple SOWs).
 Example:
Key Deliverable Responsibility Acceptance Criteria Approval Required
Statement of Work John Doe, DHHS Must use the standard SOW format Workgroup
workgroup project and content defined for the PKI Sponsor
manager program. Project Sponsor
Business Requirements Jane Smith, Business Must use PKI program template for Steering
Document Analyst, DHHS BRD Committee
Project Sponsor
Design Specifications Ray Gun, Technical Must contain all the details to be Subject Matter
Analyst, DHHS specified in Activity (Develop Design Expert
Specs) – Task (Create document Project Manager
outline). A table of contents wit
section description, and signed-off
by the Project Sponsor, will be the
basis for acceptance
Installed System X Implementation team Must meet all the requirements Steering
defined in the System Acceptance Committee
Criteria (note that the system/project Project Sponsor
acceptance criteria may either be
treated as a Key Deliverable – and
therefore included in this list – or as
an interim work product)

Page 2 < Insert Revision Number and Date of Issue >

Statement of Work [Project Name]

6. Staffing, Roles & Responsibilities

6.1 Staffing
 Describe the project’s staffing requirements (FTE’s, skills requirements)
 Describe how these requirements will be met (hire, outsource, draw from existing)
 Provide a project organization chart. The org chart must indicate functions and may include names.
Each role within the function must be indicated.
 Indicate whether resource is full-time or part-time. If part time, indicate expected level of participation.
 Remember that some would-be assumption statements should probably be converted into staffing
requirements statements.

6.2 Roles & Responsibilities Matrix

 In the matrix, indicate the
- Workgroup/Agency & Names of individuals
- Function (corresponding to the Org Chart function)
- List of Responsibilities
 Ensure all other references to responsibilities in other sections are supported here
 Avoid using “participate” or “assist” – be more specific about the activity to be performed
 Remember that some would-be assumption statements should probably be converted into R&R
statements.
 Include vendors, OIT IV&V group, or groups that will contribute to the project but may not be an
integral part of the project.
 Example:
Function Workgroup/Individuals Primary Responsibility
Functional, Dept. of Commerce/IRM • Develop and maintain SOW and
Performance, and - IRM John Martin project plan for testing workgroup
Acceptance Testing (Group Lead) • Provide input in the development
- Raj Varadharajan, SME of high-level business
- Susan Barker, Tester requirements
• Develop functional, performance,
and acceptance test plans
• Define and create the service
broker testing environment
• Select, install and evaluate test
tools
• Develop test drivers and test
cases
• Perform functional, performance,
and acceptance test
• Maintain test log and bug lists
• Prepare bi-weekly workgroup
progress reports for project
manager
• Review work of other workgroups
• Attend monthly project team
meetings
System Operation and Dept. of Commerce/ITS/CCS • Develop and maintain SOW and
Administration s - Barry Bell (Group Lead

< Insert Revision Number and Date of Issue > Page 3

[Project Name] Statement of Work

- Charles Long (Group project plan for the system

Sponsor) operations and administration
- Stuart Bobbit workgroup
- Joe Gelm • Provide input in the development
of high-level business
requirements
• Install and configure MQSeries
and ROMA
• Attend MQSeries and ROMA
training
• Evaluate, select, procure, and
install system management tools
• Develop internal system
operations and administration
standards and procedures
• Provide technical support to the
testing activities of IRM and
agency staff
• Perform functional, performance,
and acceptance tests
• Prepare bi-weekly workgroup
progress reports for the project
manager
• Review work of other project
workgroups
• Attend monthly project team
meetings

7. Management Approach
7.1 Deliverable Acceptance Management
 The focus of this section is to define the process for submitting, approving and rejecting deliverables.
 This section must briefly describe how the quality of deliverables will be assured and validated (this
should be subsequently described in-depth in a Quality Assurance plan). (Examples: pre-defined
acceptance criteria, templates, peer review, deliverable walkthrough).
 Define “Acceptance” as a written approval of the deliverable based on pre-defined acceptance criteria.
 Reinforce use of the acceptance criteria column in the Key Deliverables section.
 Decide on the approval authorities for each deliverable, turnaround time to review and approve. If a
group consensus is needed the Project Manager must drive this process and sign for the group.
 Describe a Deliverable Acceptance and Rejection.
 The Deliverables Log must be attached to the regular project status report.

7.2 Risk Management

 Define “risk” as anything that may have a negative impact to the project: schedule delay, increased
costs, poor quality of deliverables.
 Describe how the project will practice risk management:
 - action plan, who will Risk factors identification: indicate use of Kulik and Lazarus, RAMP tools.
 Risk mitigation: state the presence of the following elements in developing a risk mitigation plan for the
project be the driver, timeline, reporting and tracking
 An initial risk assessment must be performed and an initial Risk Management Plan must accompany the
SOW (attach as an appendix)

Page 4 < Insert Revision Number and Date of Issue >

Statement of Work [Project Name]

 Risk monitoring: The Risk Management Plan must be reviewed with the Project Team, Steering
Committee & Project Sponsor on a regular basis (indicate when). The document must be part of regular
project status reports.
 Remember that some would-be assumption statements should probably be converted into risk statements

7.3 Change Management

 Define “change” as any revision or adjustment to the SOW that may or may not impact project schedule
or budget.
 Describe the 3 types of changes that the project will track:
- Design changes – change to scope, deliverables (including those already approved),
activities/tasks, staffing, etc., .resulting in an adjustment to the project budget, schedule or
effort.
- Non-compliance changes – failure to perform something that was planned (including defective
- deliverables, staffing shortage). This also results in an adjustment to the project budget,
schedule or effort.
- Informational changes – changes that do not result in a change in schedule, effort and cost.
Example – change in management approach, or a change in project ownership due to a re-org.
 Customize the Change Management Procedure according to the project situation and embed it here.
Note that this describes the procedures for initiating, reviewing and approving changes as well as the
criteria for approval, and identifying the approval authority.
 Customize the Change Request Form according to the needs of the project and attach it in the Appendix
section.
 Describe how the changes will be tracked and its status communicated. Use the Change Request Log -
attach it in the Appendix section. The Log must be part of regular project status reports.

7.4 Issues & Problem Management

 Describe how the project will capture, prioritize, resolve, escalate, and monitor reported problems and
issues.
 Escalation may be based on criticality or the length of time an issue has been open.
 Describe how the issues and problems will be tracked and status communicated. Use the Issues Log
template - attach it in the Appendix section. The Log must be part of regular project status reports.
 Issues, when closed, should not be deleted from the log.

8. Progress Reporting and Communications

 Describe the levels of progress reporting required for the project. This is normally 2-levels: weekly for
 Workgroup-level, monthly for project-level reporting.
 Weekly Workgroup status reporting – the purpose is to enable the project manager to monitor and
control the progress of the project and update the project plan. An updated project plan should be
attached to the status report. If there are several workgroups involved, the project manager consolidates
the weekly reports (and updates the project-level project plan with actual hours, estimate to complete,
etc) and distributes the consolidated version to the project team.
 Monthly Project status reporting – the purpose is to communicate project progress to the project sponsor,
steering committee, and OIT. The monthly OIT status report format and content will be adopted , with
the following additional attachments:
- Deliverables Log
- Issues Log
- Risk Management Plan
- Change Request Log
- Current project plan

< Insert Revision Number and Date of Issue > Page 5

[Project Name] Statement of Work

 State when individual or workgroup status reports are due: day of the week, and time of day. Provide
enough time for project managers to consolidate info for weekly and monthly reporting

9. Project Plan
 Attach the baselined Project Plan. If the project plan is not yet baselined, attach the preliminary Project Plan
and ensure that the final project plan is defined as one of the deliverables in the Key Project Deliverables
section and that it is completed early in the project.

10. Appendix
10.1 Initial Risk Management Report

10.2 Forms and templates (customized for the project):

- Individual or Workgroup Status Report template
- Monthly Project Status Report template
- Deliverable Acceptance Form
- Change Request Form
- Change Request Log
- Issues Log

10.3 Other related and relevant documents

Page 6 < Insert Revision Number and Date of Issue >