SCDHHS Project Management Office

CONSOLIDATED DELIVERABLES MANAGEMENT LIST

1.0 INTRODUCTION

The South Carolina Department of Health and Human Services (SCDHHS) defines a deliverable as a quantifiable good or service that will be provided or adhered to throughout the Project Lifecycle. Deliverables can be tangible or intangible, and are most often specified functions or characteristics of the project. The following tangible deliverables are included as part of the Consolidated Deliverables Management List (CDML) applicable to (SCDHHS) contractors managed in accordance with the Contractor (Vendor) Management Plan. The deliverables listed herein are the expected minimum list for SCDHHS third-party contracts. Depending on the scope of work (SOW), SCDHHS may include additional deliverables to this list or exclude by exception only. Therefore, this is not an all-inclusive list.

Unless otherwise indicated in the specific deliverable list below, deliverables will be submitted electronically by close of business (COB) at SCDHHS (5:00 p.m. Eastern Time). The ‘data rights of ownership’ for each deliverable is the State of South Carolina. Unless otherwise specified within the individual deliverable, any updates to a deliverable after the initial submission and SCDHHS’ approval will be communicated minimally on an annual basis.

Project-based deliverables are documented, monitored, measured and reported via the SCDHHS defined method (e.g., Schedule Management Plan, Communications Management Plan, etc.) throughout the contracted life of the projects lifecycle.

2.0 CONSOLIDATED DELIVERABLES MANAGEMENT LIST

2.1 BASIC TEMPLATE FIELDS

This field is a checkbox categorizing the deliverable’s ‘Type of Data’

|_| Recurring |_| Not Applicable (N/A)

Type of Deliverable Due: |_| Submission |_| Adherence

This field is contains the applicable status checkbox(es) for an initial deliverable.

When a recurring submission, the Status can be either ‘Annual Update’, ‘N/A’, or ‘Other: as specified’

2.2 SCDHHS Standard Deliverables List

The recurring project status reports are weekly due by Close of Business (COB) each Thursday.

The project status report is to outline progress toward the information related to the overall status of project delivery. The status reports will be produced weekly to provide stakeholders project information on the status and progress of the project’s delivery. The information provided will contain enough detail to allow stakeholders to make informed decisions and maintain oversight of the project.

At a minimum the reports will contain:

· Overall project status

· Deliverables, milestones, key activities accomplished

· Status of issues and/or risks

· Upcoming key tasks

· Upcoming deliverables and milestones

· Cost Performance Index (CPI)

· Schedule Performance Index (SPI)

· Key decisions made or needed Please refer to the SCDHHS PMO Communications Management Plan and Schedule Management Plan for additional information.

Recurring project schedule updates are weekly due by COB each Thursday.

The contractor (vendor) is expected to utilize the SCDHHS PMO project schedule basic template requirements. Use of an Integrated Master Schedule (IMS) may be required to organize and link multiple project schedules.

The primary functions of the project schedule are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines

Please refer to the SCDHHS PMO Schedule Management Plan for additional information.

The recurring list updates are due weekly by COB each Thursday.

Risk Management Plan

The Risk Management Plan defines how risks associated with SCDHHS programs or projects are identified, analyzed, and managed. It outlines how risk management activities are recorded, performed, and monitored throughout the lifecycle of the various projects in the portfolio and provides templates and practices for prioritizing risks by SCDHHS leadership.

The Risk Management Plan also provides standard terminology, clear roles and responsibilities; a detailed description of the risk management process; and the standard templates and tools used in the risk management process. It is designed to guide the PMO, program teams, project teams and other SCDHHS stakeholders for consistent risk management activities.

The primary objective of the risk management process is to ensure that risks are evaluated quantitatively and qualitatively; mechanisms to mitigate or eliminate risks are selected; and the success of the risk mitigation techniques are continuously monitored, measured, and reported.

The Risk Management Plan is a core document for PMO governance activities.

Issue Management Plan

The Issue Management Plan defines how issues associated with SCDHHS programs or projects are identified, analyzed, and managed. It outlines how issue management activities are performed, recorded, and monitored throughout the lifecycle of the various projects and provides templates and practices for documenting and prioritizing issues by SCDHHS leadership.

The overall goal of issue management is to protect the project from the negative impact of issues or unsatisfactory completion.

The objectives of issue management are as follows:

Ensure issues are documented in a standard and consistent manner Monitor a project to identify new or changing issues Analyze the issue to minimize the cost and other impacts Escalate issues where appropriate to acquire timely resolution Focus management’s attention on higher priority issues Make issue-related decisions at the proper level of authority (i.e. resolution activities, issue transference, closure, etc.)

Communicate clearly about issues with the team and project stakeholders Monitor, measure and report issues in a consistent manner to ensure appropriate management occurs through resolution Maintain a clear and accurate record of issues and related actions over the life of the project The Issue Management Plan is a core document for PMO governance activities.

Item Number

Change Management Plan

Change Management is the formal process for identifying and requesting, analyzing, reviewing, escalating, communicating, implementing, monitoring, measuring and reporting of SCDHHS changes in a defined, consistent and repeatable manner.

The change management process provides the mechanism for allowing SCDHHS leadership and other stakeholders to effectively prioritize changes, evaluate progress, manage costs and communicate status of identified changes.

The Change Management Plan outlines how change management activities will be performed, recorded and monitored including documenting and prioritizing approved changes.

The scope of change management includes the following:

Changes provide value to the program or project and are applicable to: Project Schedule, Budget/Cost, and/or Scope;

Non-project changes which includes IT Technical changes considered non-maintenance; and/or SCDHHS Deputy Areas’ policy-based initiatives Changes will follow a defined, repeatable process to ensure routine changes are completed with minimal restrictions while complex, high impact changes receive the necessary oversight.

The Change Management Plan is a core document for PMO governance activities.

Communications Management Plan

The purpose of the Communications Management Plan is to outline the communication management approach, methodology, and tools used to provide a unified communication framework for sharing accurate information with stakeholders (both internal and external) to ensure the positive impact SCDHHS program and projects in the portfolio. The approved communication management process ensures a defined, documented, repeatable and measurable process exists for successful quality management.

The Communications Management Plan defines how communications associated with SCDHHS programs or projects will be identified, created, approved, managed and distributed. It outlines how communications-related activities will be performed, recorded, and monitored throughout the lifecycle of the various projects and provides templates and practices for documenting and prioritizing communication artifacts by SCDHHS leadership.

The approach to communications management throughout any SCDHHS program and project in the portfolio is intended to be defined for each of two levels;

· Level 1 – Basic Internal SCDHHS-related Communications, and

· Level 2 – Advanced Internal SCDHHS-related Communications and External-facing Communications.

SCDHHS intends to work collaboratively with internal and external stakeholders during the life of the project in order to ensure a seamless approach to communications. Open, ongoing communication between stakeholders is critical to the success of all PMO projects

The Communications Management Plan is a core document for PMO governance activities.

Scope Management Plan

Scope Management typically follows a five-step process to include:

1) Collect Requirements,

2) Define Scope,

3) Create the work breakdown structure (WBS),

4) Verify Scope, and

5) Monitor and Control Scope.

The purpose of the Scope Management Plan is to outline the scope management approach, methodology, and tools used to define, develop, verify, monitor, control and report scope-related work and components that could impact SCDHHS program and/or projects in the portfolio.

Other program or project components which may directly affect scope management include at a minimum:

· Identifying new or missed requirements

· Changes to the baseline project schedule

· Variation in budget or costs The Scope Management Plan is a core document for PMO governance activities.

Staff Management Plan

The Project’s Leadership or Designee plans for necessary staff for the duration of the project during the Inception, Concept and Planning Phase of the project. Staff planning and estimating occurs to identify the necessary state and contractor roles needed. In addition, staff planning and estimating identifies each specific role and the role’s timeframe assigned to the project. The staff planning and estimating model directly affects the project’s overall budget.

The plan also describes the planning, acquisition and management of both state staff and consulting or contractor staff and describes the responsibilities assigned to key staff roles.

The Staff Management Plan is a core document for PMO governance activities.

Cost Management Plan

Cost management includes estimating, tracking, and controlling expenditures related to all SCDHHS major projects, system-based changes, IT equipment (i.e., infrastructure, hardware, software) and staff (i.e., contract and non-contract) costs.

The Cost Management Plan is a core document for PMO governance activities.

Schedule Management Plan

The Schedule Management Plan is a core document for PMO governance activities.

Requirements Management Plan

Requirements Management is the process of gathering, documenting, analyzing, tracing, prioritizing, and validating requirements. This also includes the requirements are implemented in accordance to standards and based on in scope of the program or project. Finally, controlling requirements in a defined, consistent and repeatable manner is inclusive of the requirements management process.

A requirement is a function or capability to which a project outcome should conform and meet the expectations of the customer and internal and external stakeholders. Requirements will be defined and managed throughout the life of the project via requirements traceability.

The Requirements Management Plan is a core document for PMO governance activities.

Quality Management Plan

This plan describes the approach to measuring the quality of work being performed, assessing compliance and incorporating continuous improvement across the project delivery area. The SCDHHS Quality Management Plan is built for:

Quality Planning Quality Assurance (QA) Quality Control (QC) Quality/Continuous Improvement

A well-established and disciplined quality management framework drastically reduces the risk of failure or unacceptable delays for completion, reduces the number and types of defects, understands the root cause of defects, demonstrates end-to-end requirements traceability, allows for more thorough and results-driven testing and provides thorough documented evidence throughout the life of the project.

All SCDHHS projects are subject to quality reviews. Quality reviews include evaluating services, processes and/or activities provided and comparing evaluation results with the accepted standards. Deviations from stated requirements or acceptable results are considered deficiencies and identified for improvement.

The Quality Management Plan is a core document for PMO governance activities.

Contractor Management Plan

Having consistent and well-defined deliverables and a process to manage these deliverables are critical for effective contractor management as well as successful project delivery. To this end, SCDHHS must identify and manage the contractor’s contracted deliverables throughout the life of the project.

The Contractor (Vendor) Management Plan identifies the process, procedures and tools used to identify and manage deliverables during the life of the project and includes this Consolidated Deliverables Management List and contains the SCDHHS Deliverables Management process.

An approved deliverables management process ensures a defined, documented, repeatable and measurable process exists for successful quality management.

The Contractor (Vendor) Management Plan is a core document for PMO governance activities.

Note

The RD also provides a summary of the tools which will used to enter, store and manage business requirements, business rules, user requirements and functional and non-functional requirements for the project through to traceability.

Note

The RTM is developed in concurrence with the initial list of requirements (either the User Requirements Specification or Functional Requirements Specification). As the Design Specifications and Test Activities are developed, the traceability matrix is updated to include the updated documents. Requirements must be traced to the specific test step during the testing process. The RTM includes the following elements:

· Requirement ID

· Requirement Type

· Requirement Description

· Success Criteria

· Use Case or Story ID

· Use Case Description

· MITA 7 Conditions and Standards

· Status

· Priority

· Functional Design Specification

· Architectural Design Specification

· Systems Components

· Software Module (s)

· Interface Requirement?

· Unit Test Case ID

· Unit Test Case Description

· Integration Test Case ID

· Integration Test Case Description

· UAT Test Case ID

· UAT Test Case Description

· Comments

Type of Deliverable Due: |X| Submission |_| Adherence

Note

Contractor (Vendor) must use either an SSP template, completed using SCDHHS approved formatting and governance, or use the SCDHHS Governance, Risk and Compliance (GRC) solution to document system security and operating controls to ensure that the design and implementation of the services delivered contain such controls, processes and procedures that meet or exceed federal standards and guidance. Information about the use of a template or GRC solution will be provided at the kick-off meeting.

Type of Deliverable Due: |X| Submission |_| Adherence

Note

Contractor (Vendor) must use an ISRA template, completed using SCDHHS approved formatting and governance, or use the SCDHHS Governance, Risk and Compliance (GRC) solution to show the system risks in the context of MARS-E V2.0 control RA-3. Information about the use of a template or GRC solution will be provided during the kick-off meeting.

Type of Deliverable Due: |X| Submission |_| Adherence

Note

Type of Deliverable Due: |X| Submission |_| Adherence

Note

This plan must:

· Be tested periodically, at schedules agreed upon by the Contractor (Vendor) and SCDHHS, with a written report to SCDHHS. It will be the Contractor’s (Vendor) sole responsibility to maintain adequate back-up to ensure continuous operations.

· Include procedures for accessing necessary electronic Protected Health Information (ePHI) in the event of an emergency; continue protection of ePHI during emergency operations.

· Contain all necessary documentation e.g., process flows, technical diagrams, functional design document, functional design document s, etc.

The Contractor (Vendor) must:

· Support a Recovery Time Objective (RTO) of 24 hours from the time of a disaster declaration and Recovery Point Objective (RPO) of eight (8) hours.

· Propose a schedule for testing the Disaster Recovery Plan before and after implementation, and included in the project schedule.

· Have geographically diverse operations to minimize impact in the event of a disaster.

· Provide a plan to return operational status to normal in the event of a disaster.

· Describe recovery processes, including requirements for communication plans and redundant or stand-by hardware, software, and staffing.

· Describe provisions to support interim manual operations during recovery.

SCDHHS welcomes the Contractor (Vendor) to propose Disaster Recovery/Business Continuity as a Service where the Contractor (Vendor)’s solution can be integrated with other SCDHHS DR/BC requirements, systems, and teams.

Type of Deliverable Due: |X| Submission |_| Adherence

Note

It is a description at the very highest level to start setting the expectation on both business and technology changes that would be implemented by the project.

This document will be used to drive business requirements that would meet the goals expressed. If available, this activity will use the business architecture, information architecture and information flows as input and describe the impact that the project would have on these architectures.

Type of Deliverable Due: |X| Submission |_| Adherence

Note

Components of the FDS include: Sequence Diagram, Component Diagram (including UI wireframes), Information Flow Diagram, Conceptual Data Model, Interface Diagram

The FDS is used to update the Business Architecture, Application Architecture and Information Architecture.

Type of Deliverable Due: |X| Submission |_| Adherence

Note

The TDS defines platform requirements, user interfaces, components, batch jobs, interfaces and data models as it is physically implemented.

Components of the TDS include: Interface Control Documents, Deployment Model, Platform architecture, Physical Data Model, Component Diagram (including user interfaces), etc.