Guideline

For

Statements of Work

This guideline is intended to accompany the SOW Template 052008. It should provide additional insight into the development of a complete statement of work. For more information and assistance Contact the Procurement and Contract Management Bureau of ITSD.

Table of Contents

1.Introduction

1.1Title of the Project

1.2Background

1.3Objectives

1.4Reference to Other Applicable Documents

2.Staffing Roles and Responsibilities

2.1Staffing

2.2Roles and Responsibilities Matrix

2.3Contractor staff matrix by major task, rate, hours and cost

3.Assumptions

4.Risks

5.Scope - Project Scope Definition

5.1Inclusions

5.2Exclusions

5.3Deliverables

5.4Milestones

6.Work Approach

7.Schedule

8.Completion Criteria and Final Acceptance

8.1Completion Criteria and Final Acceptance

8.1.1Completion Criteria

8.1.2Final Acceptance

9.Project Management

9.1State PMO

9.2Project Status Reports

10.State Policies, Standards and Computing Environment

11.Timeline and Period of Performance

12.Compensation and Payment Schedule

13.Additional Terms and Conditions Specific to this SOW

14.Miscellaneous

Appendix

15.Execution/Signature Block

SOW Guidelines 9-2008.doc1

1.Introduction

1.1Title of the Project

1.2Background

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 (e.g. Dependencies, function of this project in relation to a bigger picture)

1.3Objectives

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 opportunity described in the background.

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, align with state enterprise perspectives…….and, to develop standards for developing and documenting shared services that would …

1.4Reference to Other Applicable Documents

List other applicable documents. They may include, but are not limited to: RFP, Contract, Contractor Proposal, Project Charter, Requirements document, Project Plan, etc. Consider adding these documents to the Appendices.

2.Staffing Roles and Responsibilities

2.1Staffing

Contractor’s Project Manager

Name:

Contractor:

Address:

City:

State & Zip:

Phone:

Cell:

Fax:

Email:

The Agency’s Project Manager

Name:

Agency:

Address:

City:

State & Zip:

Phone:

Cell:

Fax:

Email:

Describe the project’s staffing requirements (FTE’s, skills requirements)

Describe how these requirements will be met (hire, outsource, draw from existing)

A project organization chart may help. 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.

2.2Roles and 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 Roles and Responsibilities statements.

Include Contractors, IV&V group, or groups that will contribute to the project but may not be an integral part of the project.

Include time commitments of resources

If the project is dependant upon outside commitments such as legal approval, moving to a new building, predecessor projects being completed, etc., be sure to list those events.

Identify the environment in which the parties will be working

Example on the next page:

Function / Workgroup/Individuals / Primary Responsibility
Functional,
Performance, and
Acceptance Testing / Dept. of Commerce/MPD
-John Edward (Group Lead)
-Jacki Kalbfleisch, SME
-Sallie Anne /
  • Develop and maintain SOW and project plan for testing workgroup
  • Provide input in the development of high-level business 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 Administration s / Dept. of Commerce/MPD
-Timothy John (Group Lead
-Dennis Todd (Group Sponsor)
-Janis Dolan
-Joe Norman /
  • Develop and maintain SOW and project plan for the system operations and administration workgroup
  • 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

2.3Contractor staff matrix by major task, rate, hours and cost

Provide a detailed table of tasks with staff, hours, rates and cost.

Major Task or component / Individual Contractor Staff / Hours for each staff / Rate / Cost
List major task or component / Staff name(one staff per line

3.Assumptions

Identify/Quantify:

  • Any unknowns
  • Potential Issues
  • Any contractor or agency assumptions (A detailed table of tasks with staff, hours, rates will be helpful in making it possible for the agency to be better able to evaluate the proposal from the Contractor.)

4.Risks

Identify/Quantify:

  • Risks to the project itself and the proposed mitigation strategy

5.Scope - Project Scope Definition – Define here the work that must be done to deliver a product with the specified Features and functions. In addition the steps below are more detailed as they relate to project scope.

5.1Inclusions

Define which tasks will be complete dot deliver the product. It would be appropriate to attach a WBS and a project schedule based on all known requirements tasks & deliverables. Only on rare occasions would it not be possible to complete a WBS and project schedule. In these cases a high level WBS and project schedule should be included with another deliverable at a later date to finalize a more detailed WBS and schedule.

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, but focus on “what” work needs to be performed. How the work is to be performed is covered in the Work Approach

The difference between objectives and scope – Objective describes the primary product(s) of the project (eg., A shared services repository, an application system, 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).

Useful questions: what business area is targeted? What function within the business area is included? Are the following included: conversion, training, interfaces, transition, warranty, maintenance and operations?

5.2Exclusions

This helps further define boundaries by clearly stating what is out of scope. Must be shorter than Inclusions.

5.3Deliverables

List all the major project deliverables – these usually correspond with the major project activities described in the Work Approach section.

List quantities, locations, dates for delivery and period of performance for services.

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. Signing-off on interim deliverables does not eliminate the requirement for the sign-off on final acceptance once all the interim deliverables and phases are integrated and tested in the final acceptance component of the project.

Work Products do not need sign-off and need not be listed under Key Project Deliverables, unless they are part of the specific plans that will be reviewed and approved. Work products include status reports, issues log, change request log, risk mgt report, deliverables log, and meeting summaries.

Scheduled Status Reports should be delivered on a regular basis. The frequency will depend on the complexity and timeline of the project. If the complexity is high and the timeline short, more frequent reports should be required.

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 …”).

Define required system documentation and user documentation. Require documentation to include customizations and configurations specific to this project.

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 the use of tables – rather than a narrative – to enumerate the deliverables is preferred (even for simple SOWs).

Example of a list:

Key Deliverable / Responsibility / Acceptance Criteria / Approval Required
Statement of Work / Daniel Joseph, MDT workgroup project manager / Must use the standard SOW template / Workgroup Sponsor
Project Sponsor
Business Requirements Document / Sherrie Kaye, Business Analyst, MDT / Must use PKI program template for BRD / Steering Committee
Project Sponsor
Design Specifications / Mary Pat Jackson, Technical Analyst, MDT / Must contain all the details to be specified in Activity (Develop Design Specs) – Task (Create document outline). A table of contents wit section description, and signed-off by the Project Sponsor, will be the basis for acceptance / Subject Matter Expert
Project Manager
Installed System X / Implementation team / Must meet all the requirements defined in the System Acceptance Criteria (note that the system/project acceptance criteria may either be treated as a Key Deliverable – and therefore included in this list – or as an interim work product) / Steering Committee
Project Sponsor
Project Status Report / Contractor Project Manager / Must use the state Project Status Report Template unless the Contractor Status Report is pre-approved. / State Project Manager/State Project Management Office

5.4Milestones

List a table of detailed milestones and the schedule for each of them.

6.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 MT PMBOK based methodology. Also indicate if the project will be tracked by the state CIO’s Project Management Office (PMO).

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 as an appendix 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).

7.Schedule

Dates of the seller’s key tasks or completion of the major elements of the project

I Identify interim quality gate milestones-these are decision points where the project can be stopped or approved to go forward.

8.Completion Criteria and Final Acceptance

8.1Completion Criteria and Final Acceptance

8.1.1Completion Criteria

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.

Clearly describe how you will determine if the contractor has successfully met your needs so that they may be paid.

8.1.2Final Acceptance

Describe in detail the precise definition of the conditions and criteria that will be applied to determine that the contract has been successfully completed.

Include warranty period of 6 months or a year depending on complexity of the project.

Define how the State Contractor Assessment process will be used.

9.Project Management

Project Management is key component to the successful completion of your project. ITSD recommends that seasoned and certified project managers be used on your high risk and high cost projects. Industry standard project management methodologies need to be used and are summarized below.

Depending on the size of the project, the project may have to be monitored by the state Project Management Office (PMO) and the PMO would have to be copied on all status reports for the project. If reports will be required to be submitted to the PMO, this should be spelled out in this section.

If the RFP or Contractor Evaluation Proposal (Procurement CEP) provides adequate detail of requirements, a Project Management Plan (PMP) would be expected in the SOW. If, however, there is not enough detail in the RFP or CEP, then a high level PMP would be expected in the SOW, and the SOW should include a deliverable for a detailed PMP in the initiation stage of the project.

9.1State PMO

If the project is of such a size that it must be reported to the state Project Management Office (PMO), there must be language in the SOW which requires that coordination. Also, if there is an IVV contractor, that should be specified and the touch points defined between the IVV and the state PMO.

9.2Project Status Reports

Define how often, and what needs to be included in project status reports, which are to be provided to the state/agency PM by the contractor.

10.State Policies, Standards and Computing Environment

Contractor must comply with most current and up to date State Policies, Standards and Computing Environment. Contractor must confirm that the version they have are the most current. Documents can be found at these web sites:
Environment -
Policies -
Supported Software -
Ensure that the above links are the most recent and are accurate.

If there are technical architectures specific to this project, they must be defined. If the technical architecture does not align with the state enterprise standards and direction, then the architecture design must be discussed and approved by ITSD before inclusion in the SOW.

11.Timeline and Period of Performance

Outline the dates of contractor’s key tasks or submission of product or service.

The period of performance for this project will start on [start date] and the work tasks are estimated to continue through [end date]. The State has the right to extend or terminate this SOW at its sole discretion.

12.Compensation and Payment Schedule

An example of a payment schedule is included below.

Describe how all invoices from the Contractor must include detail of tasks and deliverables being billed for. In addition, describe how the deliverables and tasks being billed for must be accepted by the project manager before the approval of payment of each invoice.

Consider a holdback of 20% as the final payment to be made only after final acceptance, which may be after the post implementation period of maybe 30 days, where the system must run error free. An agency should consider a warranty period of several months, depending on the size and complexity of the project. If there is a warranty period, it is recommended that final acceptance and payment of the final invoice or holdback not be made until the warranty period is over, and the project manager has signed off on the acceptance checklist prior to the approval of final payment. The holdback may be required depending on the complexity of the project.

For total cost calculation and budget purposes (but not to be a part of the SOW), it is recommended that an agency budget for a 25% contingency fund. This may be required depending on the size and complexity of the project.

Example of payment schedule:

Agency shall pay Contractor an amount not to exceed [Four hundred fifty thousand] dollars ($450,000) [specify maximum dollar amount] for the performance of all activities necessary for or incidental to the performance of work as set forth in this SOW. Contractor’s compensation for services rendered shall be based on Contractor’s Prices as set forth in this section defining the staff and hourly rate plus expected hours per component of the project as follows:

2.Implementation and Conversion

Per Section ….Total Cost $__450,000______

2.1 Implementation

Per Section…Cost $__350,000 less20% for holdback______

2.2 Conversion of data