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] 1. 2. 3. 4.
Statement of Work
Submit to Project Sponsor for review Project Sponsor will endorse or return SOW within 2 business days. If rejected: revise and repeat submittal process from step 1. 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 Statement of Work
Responsibility John Doe, DHHS workgroup project manager Jane Smith, Business Analyst, DHHS
Acceptance Criteria Must use the standard SOW format and content defined for the PKI program. Must use PKI program template for BRD
Design Specifications
Ray Gun, Technical Analyst, DHHS
Installed System X
Implementation team
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 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)
Business Requirements Document
Page 2
Approval Required Workgroup Sponsor Project Sponsor Steering Committee Project Sponsor Subject Matter Expert Project Manager
Steering Committee Project Sponsor
< 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 Functional, Performance, and Acceptance Testing
System Operation and Administration s
Workgroup/Individuals Dept. of Commerce/IRM - IRM John Martin (Group Lead) - Raj Varadharajan, SME - Susan Barker, Tester
Dept. of Commerce/ITS/CCS - Barry Bell (Group Lead
< Insert Revision Number and Date of Issue >
Primary Responsibility • 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 • Develop and maintain SOW and
Page 3
[Project Name]
Statement of Work -
Charles Long (Group Sponsor) Stuart Bobbit Joe Gelm
• • • • • • • • • •
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
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
Page 4
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)
< 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 >