Statement of Work for the put project name here Project

Month day, year name, title N.C. Department of Commerce Information Resource Management Division

TABLE OF CONTENTS
1. BACKGROUND.......................................................................................................................... 5 2. OBJECTIVES ............................................................................................................................. 5 3. SCOPE........................................................................................................................................ 5 3.1 Inclusions ............................................................................................................................. 5 3.2 Exclusions ............................................................................................................................ 5 4. WORK APPROACH ................................................................................................................... 5 5. KEY PROJECT DELIVERABLES.............................................................................................. 6 6. STAFFING, ROLES & RESPONSIBILITIES.............................................................................. 7 6.1 Staffing ................................................................................................................................. 7 6.2 Roles & Responsibilities Matrix............................................................................................ 7 7. MANAGEMENT APPROACH .................................................................................................... 8 7.1 Deliverable Acceptance Management ................................................................................. 8 7.2 Risk Management ................................................................................................................ 8 7.3 Change Management .......................................................................................................... 9 7.4 Issues & Problem Management........................................................................................... 9 8. PROGRESS REPORTING AND COMMUNICATIONS ............................................................. 9 9. PROJECT PLAN ...................................................................................................................... 10 10. APPENDIX .............................................................................................................................. 10 10.1 Initial Risk Management Report ..................................................................................... 10 10.2 Forms and templates (customized for the project): ......................................................... 10 10.3 Other related and relevant documents ............................................................................ 10

Document1

Page 1

Submitted: mm/dd/yy

Statement of Work Name of Project

! General instructions in developing a statement of work from this template: Project SOWs 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 NC Logo document name (i.e. Statement of Work) project name preparers 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. Reporting to the IRMC) 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. An example of a simple SOW that contains all these elements is in PCDOCS #3509. This is just an example - Do not create your SOW from this document as the headings may be different.
Date Submitted: mm/dd/yy

Document1

Statement of Work Name of Project

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: 1. Attach a Deliverable Acceptance form (PCDOCS #3497) 2. Submit to Project Sponsor for review 3. Project Sponsor will endorse or return SOW within 2 business days. 4. If rejected: revise and repeat submittal process from step 1. 5. 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.

Useful PCDOCS Documents:

3497 Deliverable Acceptance form 3498 this SOW template 3499 Example of a Deliverable Acceptance Procedure 3500 Change Procedure template 3501 Change Request form 3502 Change Request Log 3504 Issues Log
Document1 Date Submitted: mm/dd/yy

Statement of Work Name of Project

3507 Status Report Form 3509 Example of a simple SOW 2008, 2013 Service Broker statements of work

Document1

Date Submitted: mm/dd/yy

Statement of Work Name of Project

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 projects 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 Transportations Purchasing Departments 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. (Eg., This project will use the Method/1 waterfall software development life cycle).
Date Submitted: mm/dd/yy

Document1

Statement of Work Name of Project

! ! ! 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).

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 workgroup project manager Jane Smith, Business Analyst, DHHS Must use the standard SOW format and content defined for the PKI program. Workgroup Sponsor Project Sponsor

! ! !

! ! ! ! !

Business Requirements Document

Must use PKI program template for BRD.

Steering Committee Project Sponsor

Design Specifications

Ray Gun, Technical Analyst, DHHS

Must contain all the details to be specified in Activity (Develop Design Specs) Task (Create document outline). A table of contents with 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

Steering Committee Project Sponsor

Document1

Date Submitted: mm/dd/yy

Statement of Work Name of Project

interim work product)

6. Staffing, Roles & Responsibilities

6.1 Staffing ! ! ! ! ! Describe the projects staffing requirements (FTEs, 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, IRMC QA 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 Dept. of Commerce/IRM Functional, Develop and maintain SOW and project Performance, and - IRM John Martin (Group plan for testing workgroup Lead) Acceptance Testing Provide input in the development of highRaj Varadharajan, SME level business requirements - Susan Barker, Tester 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 tests 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 Operations Dept. of Commerce/ITS/CCS Develop and maintain SOW and project - Barry Bell (Group Lead) and Administration plan for the system operations and - Charles Long (Group administration workgroup
Document1 Date Submitted: mm/dd/yy

Statement of Work Name of Project

Sponsor) Stuart Bobbit Joe Gelm Provide input in the development of highlevel 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 procedure (see PCDOCS#3499 for an example) and customize the Deliverable Acceptance Form (PCDOCS #3497) for the project and attach it in the Appendix section. The ABT Workbench-generated 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: 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 - action plan, who will be the driver, timeline, reporting and tracking (need to locate template in PCDOCS use Service Broker example, see PCDOCS#3464) An initial risk assessment must be performed and an initial Risk Management Plan must accompany the SOW (attach as an appendix) 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. Read more about the IRMs RAMP available at the IRMC website under the Policies & Standards page Remember that some would-be assumption statements should probably be converted into risk statements.
Date Submitted: mm/dd/yy

Document1

Statement of Work Name of Project

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 (PCDCOS #3500) 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 (PCDOCS #3501) 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 template (PCDOCS #3502) - 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 (PCDOCS #3504) - 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. (see PCDOCS #3507). 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 the IRMC. The monthly IRMC status report format and content will be adopted (PCDOCS #2394), with the following additional attachments (IRM QA does not require these, but our project mgt process does): - Deliverables Log - Issues Log - Risk Management Plan - Change Request Log - Current project plan 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.

Document1

Date Submitted: mm/dd/yy

Statement of Work Name of Project

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 (IRMC) Deliverable Acceptance Form Change Request Form Change Request Log Issues Log

10.3 Other related and relevant documents

Document1

Date Submitted: mm/dd/yy

10