Statement of Work for the put project name here Project

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

....................................... PROJECT PLAN ...... KEY PROJECT DELIVERABLES............................................................................. 5 3......... 9 8......................... MANAGEMENT APPROACH ................................................................................................................................................. 5 5.......................................................................................................................................................................................................................................................... 8 7.. PROGRESS REPORTING AND COMMUNICATIONS ... 10 10....... SCOPE.......................1 Deliverable Acceptance Management ................................................................................................2 Risk Management .................................................................................................................. 9 9...3 Change Management ............................................................................... 10 10.......... ROLES & RESPONSIBILITIES............................................................................................TABLE OF CONTENTS 1.............................................................................................................................................. 6 6...................................................... 10 10. 8 7...................................... BACKGROUND....................................1 Staffing ....... 5 2..................2 Forms and templates (customized for the project): ............................................................................................................................ STAFFING...2 Exclusions ...................3 Other related and relevant documents ....................1 Inclusions ............................................4 Issues & Problem Management........................................................... WORK APPROACH ..........................................2 Roles & Responsibilities Matrix........................ 10 Document1 Page 1 Submitted: mm/dd/yy ...............1 Initial Risk Management Report ...................... 5 3... 8 7.................... 7 6....................................... APPENDIX ............................................................................................................................................................................................................................................................... 7 6........................... 7 7.......... 9 7.................................. OBJECTIVES .... 5 3.......................... 10 10.. 5 4............................................................................................................

references .Responsibility .Statement of Work Name of Project ! • 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 . how changes to the scope of work will be handled.Organization Chart . This is just an example .Acceptance Criteria Staffing.) The same manually-typed date must be on all footers on all pages of the SOW. how status will be communicated.Acceptance Management .Roles & Responsibilities matrix Management Approach .Change Management . • For major projects (eg.attach templates. The Management Section may be compressed but ensure that the following are addressed: how deliverables will be submitted and approved. Statement of Work) project name preparer’s name and title department/division date submitted (manually typed. Date Submitted: mm/dd/yy Document1 2 .Do not create your SOW from this document as the headings may be different.Issues & Problem Management .Risk Management . Remove these when you are finalizing the template.e. tips and recommendations that you find within the template will be preceded by a bullet-arrow and italicized.Communications & Progress Reporting Baselined Project Plan SOW from each workgroup (abbreviated form) Appendix .initial Risk Management Report - - - - - • • All instructions.Inclusions . the minimum requirement is that the SOW must have all the major sections – The section entries do not have to be elaborate. The document Cover must have NC Logo document name (i. forms.Exclusions Work Approach .Workgroups . do not use computer-generated dates.Development Methodology . Activities and Tasks) . Reporting to the IRMC) All the sections and sub-sections are mandatory.Technical Environment Key Deliverables . For simpler projects. Roles and Responsibilities . An example of a simple SOW that contains all these elements is in PCDOCS #3509.Major Activities (or Phases. This also serves as the version reference.Deliverable .

a scope statement..a roles and responsibilities statement. The project manager will…. • • • • 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 3 . Name functions or titles as indicated. and resolution plan. Project Sponsor will endorse or return SOW within 2 business days. The following steps will be taken to mitigate this risk (a) x will do this…. Spell-check before submitting for review and approval.. Submittal process: 1. Name names as indicated. if it will most likely occur: Should the 7 workstations not be available …… it will delay the project start by ….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. (b) y will do that…. In order to mitigate this risk. Submit to Project Sponsor for review 3. Rationale – assumption statements are passive and have no clear drivers.Statement of Work Name of Project • • • • Section entries must be brief and to the point. If rejected: revise and repeat submittal process from step 1. 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. 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.. 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.a “basis for estimate” statement within an Effort and Cost section if provided . . 4. 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. Transform it into a risk statement as well. . 5. timelines.. If signed: furnish signed copies Project Team. Transform assumptions into either of the following: . Attach a Deliverable Acceptance form (PCDOCS #3497) 2. Do not state any ASSUMPTIONS in the statement of work.

2013 – Service Broker statements of work Document1 Date Submitted: mm/dd/yy 4 .Statement of Work Name of Project 3507 – Status Report Form 3509 – Example of a simple SOW 2008.

. Scope 3. “This project will use the Method/1 waterfall software development life cycle”). a new section in the STA. functional specifications. 3. state what the project must accomplish. Describe this project’s relationship to other initiatives or projects (eg. a shared services repository. Provide specific details to ensure a complete and unambiguous understanding of the boundaries of the project. Scope describes the boundaries within which those products will be developed. or Statewide mainframe platforms. maintenance and operations? Remember that some would-be assumption statements should probably be converted into scope statements.to install and make operational a shared services repository that would ensure centralized documentation.1 Inclusions ! ! ! ! Define what is included using metrics whenever possible. training.. The scope statement is the foundation for the subsequent documents that further refine the project coverage. 4. Objectives ! ! Given the historical background and drivers (this is why Background must come before Objectives). Example: “The objectives of this project are: .to develop standards for developing and documenting shared services that would …. (Eg. transition. interfaces. Date Submitted: mm/dd/yy Document1 5 . function of this project in relation to a bigger picture) 2. and infrastructure specifications documents. facilitate shared services searches…….Statement of Work Name of Project 1.2 Exclusions ! ! This helps further define boundaries by clearly stating what is out of scope.and. Dependencies.. A PKI infrastructure. of Transportation’s Purchasing Department’s administrative support section. This should be brief and high-level– describe the final outcome that will address the problem or the opportunity described in the previous section. an application system. a new convenience contract process. 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. Describe the business drivers for the project or the problem or opportunity being addressed. etc). Background ! ! ! Describe relevant history that precedes the project. ! ! ! 3. Work Approach ! Describe how the work is to be performed – if a formal methodology will be used. Dept. provide a concise description here. Must be shorter than Inclusions. or pilot effort or proof of concept effort only. Useful questions: what business area is targeted? What function within the business area is included? Are the following included: conversion. such as business requirements. delivered and deployed (eg. etc) and the goals to be achieved by producing those products.

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

Remember that some would-be assumption statements should probably be converted into staffing requirements statements.IRM John Martin (Group plan for testing workgroup Lead) Acceptance Testing • Provide input in the development of highRaj Varadharajan. The org chart must indicate functions and may include names. Each role within the function must be indicated.Workgroup/Agency & Names of individuals . If part time. of Commerce/IRM Functional. • Develop and maintain SOW and project Performance. ! Example: Function Workgroup/Individuals Primary Responsibility Dept. install and evaluate test tools • Develop test drivers and test cases • Perform functional.2 Roles & Responsibilities Matrix In the matrix.Charles Long (Group administration workgroup Document1 Date Submitted: mm/dd/yy ! 7 . performance. ! Include vendors.Susan Barker. or groups that will contribute to the project but may not be an integral part of the project.Function (corresponding to the Org Chart function) . 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. IRMC QA group. indicate expected level of participation. outsource. performance. skills requirements) Describe how these requirements will be met (hire. draw from existing) Provide a project organization chart. Roles & Responsibilities 6. Indicate whether resource is full-time or part-time. and acceptance test plans • Define and create the service broker testing environment • Select.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.1 Staffing ! ! ! ! ! Describe the project’s staffing requirements (FTE’s.Statement of Work Name of Project interim work product) 6. of Commerce/ITS/CCS • Develop and maintain SOW and project . SME level business requirements . indicate the .Barry Bell (Group Lead) and Administration plan for the system operations and . Staffing. and . Tester • Develop functional. 6.

Date Submitted: mm/dd/yy Document1 8 . templates. select.2 Risk Management ! ! ! ! ! ! ! ! Define “risk” as anything that may have a negative impact to the project: schedule delay. Read more about the IRM’s 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. who will be the driver.1 Deliverable Acceptance Management ! ! ! ! ! ! The focus of this section is to define the process for submitting.action plan. Define “Acceptance” as a written approval of the deliverable based on pre-defined acceptance criteria. turnaround time to review and approve. 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. peer review. Decide on the approval authorities for each deliverable. 7. The document must be part of regular project status reports. Steering Committee & Project Sponsor on a regular basis (indicate when). 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. reporting and tracking (need to locate template in PCDOCS – use Service Broker example. (Examples: pre-defined acceptance criteria.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. deliverable walkthrough). 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. Risk mitigation: state the presence of the following elements in developing a risk mitigation plan for the project . 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). procure. timeline. approving and rejecting deliverables. The ABT Workbench-generated Deliverables Log must be attached to the regular project status report. Management Approach 7. performance. Describe how the project will practice risk management: Risk factors identification: indicate use of Kulik and Lazarus. If a group consensus is needed the Project Manager must drive this process and sign for the group. Reinforce use of the acceptance criteria column in the Key Deliverables section. poor quality of deliverables. RAMP tools. increased costs. 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.

effort and cost. An updated project plan should be attached to the status report. Customize the Change Request Form (PCDOCS #3501) according to the needs of the project and attach it in the Appendix section.Risk Management Plan . . etc. reviewing and approving changes as well as the criteria for approval. This also results in an adjustment to the project budget.Design changes – change to scope.attach it in the Appendix section. ! ! Document1 Date Submitted: mm/dd/yy 9 . Issues. should not be deleted from the log. Provide enough time for project managers to consolidate info for weekly and monthly reporting. when closed. escalate. and identifying the approval authority.. The Log must be part of regular project status reports. resolve. If there are several workgroups involved. schedule or effort. Example – change in management approach. . and the IRMC.Current project plan State when individual or workgroup status reports are due: day of the week. estimate to complete. Monthly Project status reporting – the purpose is to communicate project progress to the project sponsor. deliverables (including those already approved). 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. Use the Change Request Log template (PCDOCS #3502) .Non-compliance changes – failure to perform something that was planned (including defective deliverables. Note that this describes the procedures for initiating. schedule or effort. Describe how the issues and problems will be tracked and status communicated. Progress Reporting and Communications ! ! Describe the levels of progress reporting required for the project. ! ! ! 7. staffing.Informational changes – changes that do not result in a change in schedule. Customize the Change Management Procedure (PCDCOS #3500) according to the project situation and embed it here. staffing shortage). or a change in project ownership due to a re-org. .Change Request Log . with the following additional attachments (IRM QA does not require these. Use the Issues Log template (PCDOCS #3504) . etc) and distributes the consolidated version to the project team. This is normally 2-levels: weekly for workgroup-level. activities/tasks.Issues Log . prioritize. The monthly IRMC status report format and content will be adopted (PCDOCS #2394). Describe how the changes will be tracked and its status communicated.Statement of Work Name of Project 7. the project manager consolidates the weekly reports (and updates the project-level project plan with actual hours.attach it in the Appendix section. but our project mgt process does): .Deliverables Log . and time of day.4 Issues & Problem Management ! ! ! ! Describe how the project will capture. The Log must be part of regular project status reports. Describe the 3 types of changes that the project will track: .3 Change Management ! ! Define “change” as any revision or adjustment to the SOW that may or may not impact project schedule or budget. Escalation may be based on criticality or the length of time an issue has been open. steering committee. (see PCDOCS #3507). 8. and monitor reported problems and issues. monthly for project-level reporting.resulting in an adjustment to the project budget.

Appendix 10.1 Initial Risk Management Report 10. If the project plan is not yet baselined. Project Plan ! Attach the baselined Project Plan.3 Other related and relevant documents Document1 Date Submitted: mm/dd/yy 10 .Statement of Work Name of Project 9. 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.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. 10.

Sign up to vote on this title
UsefulNot useful