Appendix_E_-_Project_Gates_and_Deliverable_Acceptance.docx

Project Gates and Deliverable Acceptance Quality Stage Gates The purpose of the Quality Gate process is to assist in monitoring the progress of the project and schedule compliance. The State has identified five primary stage gates as follows:

· Planning

· Requirements/Design

· Configure/Build

· User Acceptance

· Cutover Expected deliverables and implementation activities have been grouped by Phase into sequential activities that largely follow a waterfall approval process for major milestones. Iterative deliverables such as agile configuration and testing of modules in phases can be accommodated within a required stage gate. Completion and acceptance of all activities and deliverables at a defined stage trigger a formal Quality Stage Gate Review. The Quality Stage Gate Review is a higher-level review presented to representatives of the State and serves as a checkpoint to ensure all stakeholders are briefed on material changes to scope, design considerations and planning activities. Figure below provides a high-level outline of the anticipated Quality Stage Gate Process.

The Quality Stage Gate Review process is depicted in the diagram below which represents each phase and sub-phase of the project with five Quality Stage Gates and the acceptance criteria for each stage gate. Stage gates are represented by the red diamonds in the diagram below.

Quality Stage Gate Review Process

Project Implementation Reporting Weekly Reports. The Vendor is expected to provide a status report each week to the State as well as the IV&V Vendor within two business days following the weekly Project Status Meeting, beginning the week after the Kickoff Meeting. The State will provide the template. This report highlights tasks completed, tasks planned for the following week, all Project risks and issues, deliverables, milestones, and important tasks. The report will conform to Project Management requirements, Functional Requirements, and Non-Functional Requirements.

Monthly Reports. The Vendor shall provide a Monthly Status Report to the State no later than the third business day of the month following the reporting month. This report shall summarize all items reported in the weekly summary report. This report will conform to Project Management requirements, Functional Requirements, and Non-Functional Requirements.

Ad Hoc Reports. The Vendor shall produce and submit additional reports that State may require on a daily, weekly, or monthly basis, as deemed by the State to be necessary. Each of these reports will be due within five business days (unless otherwise mutually agreed), upon written request of the State.

Stage Gate Closeout Report. The Vendor will develop and submit a Stage Gate Closeout Report to the State no later than seven business days following the close of each Stage Gate. All deliverables of each Stage Gate shall be accounted for and accepted by the State.

Post-Implementation Report. At the end of Project implementation, the Vendor will develop and submit to the State as well as the IV&V Vendor a Post-Implementation Report no later than 20 business days following the end of the Deployment Stage Gate. This report will conform to Project Management requirements, Functional Requirements, Non-Functional Requirements.

Project Closeout Report. At the end of the Project, the Vendor will develop and submit to the State a Project Closeout Report no later than 20 business days following the end of the Security Stage Gate. This report will conform to Project Management requirements, Functional Requirements, Non-Functional Requirements.

DELIVERABLE REQUIREMENTS & ACCEPTANCE

Part 1 – Project Deliverable Project deliverables are generally either Document Deliverables or Software-based Deliverables. These two types of deliverables will follow unique acceptance and approval processes as follows:

1.1 – Document Deliverables

a. The Vendor will deliver all Document Deliverables to the State accompanied by a Deliverables Acceptance Form by the delivery date as established in the State’s Detailed Project Plan. If the Vendor is unable to meet the established delivery date, it will provide the State with written notice at least two (2) weeks prior to the delivery date. Such notice will specify the proposed new delivery date.

b. Unless otherwise noted, the State will review the Document Deliverable within ten business days of receipt of the Document Deliverable and deliver to the Vendor a Review Record which either:

a. Indicates the State has signed off on the Document Deliverable; or

b. Documents its comments on where and how the Document Deliverable fails to conform to the relevant Specifications.

Should the State not provide acceptance sign-off, or if no changes or comments are requested within the specified acceptance review period, the Vendor’s Project Manager will escalate the delay in sign-off to the State’s Project Manager for follow-up and action. Delays in sign-off can delay the State project's overall timeline. The Vendor’s Project Manager will assess any potential delays and provide this information as a part of the escalation process.

If the Vendor does not deliver the Document Deliverable by the established delivery date, the ten-business day period (unless otherwise noted) will be extended by the period reasonably required by the State to reallocate resources to perform the review.

a. If the Review Record indicates the State has not signed off the Document Deliverable, the Vendor will, within three business days from the time the State delivers the Review Record, respond in writing addressing the points raised by the State in the Review Record and, as appropriate, amend the Document Deliverable.

b. The State will, within three business days of receiving a written response to the points raised in the Review Record and/or the amended Document Deliverable, notify the Vendor in writing the State considers that:

a. All the points raised in the Review Record have been addressed and/or amendments have been incorporated into the Document Deliverable, and the State signs off the Document Deliverable; or

b. If not all the points raised in the Review Record have been addressed and/or not all the amendments, have been incorporated into the Document Deliverable, in which case the State will provide a revised Review Record documenting its further comments on the Document Deliverable.

c. The parties will repeat the above processes until the State signs off the Document Deliverable per the acceptance process for Document Deliverables. Should the State not provide acceptance sign-off within the specified acceptance review period, the Vendor’s Project Manager will escalate the delay in sign-off to the State’s Project Manager for follow-up and action. Delays in sign-off can delay the State project's overall timeline. The Vendor’s Project Manager will assess any potential delays and provide this information as a part of the escalation process.

1.2 – Software-based Deliverables

a. Each Software-based Deliverable will progress through the established test phases in accordance with the State Testing Plan.

b. The State will sign off on Test Plan developed by the Vendor in conjunction with State representatives. Test Cases for User Acceptance Testing will be provided by the State.

c. The Vendor will execute each Test Phase in accordance with the Testing Strategy and Approach included as a part of the SOW, and as further defined in the Detailed Test Plan. Test Phases include the following activities:

i. Environment Setup Verification

ii. Unit Test

iii. System Test

iv. User Acceptance Test

d. The Vendor may only allow a Software-based Deliverable to enter a Test Phase if the entry criteria for the applicable Test Phase, as set out in the Detailed Test Plan, have been met or if otherwise agreed by both parties in writing, and/or as further defined in the Detailed Test Plan.

e. A Software-based Deliverable may only exit a Test Phase if Vendor has demonstrated to the State in a Test Summary Report that the exit criteria for the Test Phase, as set out in the Detailed Test Plan, have been met and the State has signed off the Test Summary Report in accordance with the established sign-off process.

1.3 – User Acceptance Testing

a. For User Acceptance Testing (UAT), the State will leverage State-provided Use/Test Cases as modified or developed for System Testing. UAT will be performed by the State in accordance with the Vendor Test Strategy and the relevant Detailed Test Plans. The State will manage UAT and provide testers to complete UAT. The successful Responder will support UAT by providing test environment support and batch execution.

b. The User Acceptance Test aims to determine whether the tested System Deliverables conform to the Requirements documented in Functional Requirements and Non-Functional Requirements (as they may have been amended by the parties, in writing, during the design and configuration process).

c. The successful Responder will provide an updated requirements traceability matrix to the UAT team, which maps each Requirement to the functionality or system component which fulfills that requirement.

1.4 – Go-Live Criteria Preliminary list of go-live criteria for assessing the system and State readiness for Go Live. It is a task within the Deploy Phase to finalize these criteria:

1) System Functionality – The successful Responder solution configured in support of the Implementation meets the functional and operational requirements as specified in the Fit/Gap Analysis and as evidenced by the State’s acceptance of UAT. Additionally, the system will be accepted for operation use when it satisfies the following four (4) requirements:

a. No Severity 1 issues (defined below)

b. No Severity 2 issues

c. All Severity 3 issues have workarounds identified, agreed with the State, and communicated to users

d. All Severity 4 issues identified, agreed, and documented

2) Data Readiness – Data migrated from source systems to the Vendor has completed QA and satisfies the following four (4) requirements:

a. No Severity 1 issues (defined below)

b. No Severity 2 issues

c. All Severity 3 issues have workarounds identified, agreed with the State, and communicated to users

d. All Severity 4 issues identified, agreed, and documented

3) Reporting – All reports identified elsewhere in the SOW to be completed by Vendor have been tested and accepted by the State. Acceptance criteria are:

a. No Severity 1 issues (defined below)

b. No Severity 2 issues

c. All Severity 3 issues have workarounds identified, agreed with the State, and communicated to users

d. All Severity 4 issues identified, agreed, and documented

4) User Readiness – All affected State departments/divisions have completed the training according to the Training Plan in order to prepare them to use the solution on Day 1, including:

a. All classroom training completed per the Training Plan

b. State department/division personnel have received soft copies of all finalized training materials

5) User Support – User support requirements defined and accepted by the State for the two-month post go-live support period. All post go-live support staff are named and identified two weeks prior to go-live.

a. Go-live plan is documented and accepted and includes the specific duties and expectations of the on-site support staff

b. Process for capturing, logging, and resolving operational issues during the post go-live support period is documented and agreed upon

c. Support escalation process documented and agreed upon

6) Operational Readiness – Support infrastructure, equipment, tools and procedures are in place and ready for use. Operational staff are trained (user and system administration). Technical support staff are in place and prepared to handle reporting, prioritizing and fixing problems.

a. Planning, Help Desk, and Change Control processes in place

b. User and System Administration training completed per Training Plan

c. Knowledge Transfer post go-live to System Admins

7) External Factors – Interfacing Organizations/Departments, stakeholders, and affected staff have been communicated with, and the State is ready for launch

8) Go Live Plan – The Go Live Plan is developed and accepted by business owners, and has been vetted via a dry run so that any potential gaps are identified and resolved prior to go-live

Vendor will also follow the Quality Gate process when it comes to the commencement of work and final acceptance of deliverables and exit of a quality gate. The purpose of the Quality Gate process is to assist in monitoring the progress of the project and schedule compliance. However, the primary project monitoring documents will be the Project Management Plan (PMP) and the Project Schedule.

Both the State and Vendor recognize that there will be instances requiring changes to the deliverable acceptances flow as outlined. When these instances occur, the State and Vendor PMs will discuss them in advance to reach mutual agreement and will communicate the proposed change to the appropriate stakeholders from both Parties, seeking their assent where necessary. A mutually agreed-to change to the flow of the Quality Gate process with no impact to project scope and schedule will not require a change request but will be documented in the Project Management Plan and the Work Breakdown Structure.

Vendor will meet with the State to develop the acceptance criteria for each deliverable. Vendor will subsequently develop a Deliverable Expectation Document (DED) for each deliverable. The State will provide input as required or requested by Vendor within five business days of the request by Contractor.

Deliverable Development and Acceptance Process

Vendor will subsequently develop a DED for each deliverable.

State will provide input as required or requested by Vendor within five business days of the request by Vendor.

The State will then accept and sign-off the DED.

Acceptance criteria for each deliverable is defined within this statement of work

After reviewing each deliverable, State will then prepare a written Deliverable Review Report, communicating to Vendor any issues and items to be resolved with the deliverable that does not meet the criteria established in the DED prior to formal acceptance.

The time frame for State to review a deliverable will be defined in the DED, based on what is defined in Deliverable Acceptance Process above.

State will facilitate a detailed walk-through review of each deliverable with assigned project team resources.

After reviewing each deliverable, State will then prepare a written Deliverable Review Report, communicating to Vendor any issues and items to be resolved with the deliverable that does not meet the criteria established in this statement of work prior to formal acceptance.

The time frame for State to review a deliverable is based on what is defined in this statement of work

This time frame will generally be two business days.

Unless a change is disputed, Vendor will address feedback received in the Deliverable Review Report, updating the deliverable for final review and acceptance by the State.

This time frame will generally be two business days.

Appendix E: Project Gates and Deliverable Acceptance

Part 2 – Requirements and Descriptions

2.1 – System Requirements & Design Deliverable Descriptions

1A - Project Kickoff Presentation

Written, Presentation

a. The overall project objectives, project plan, management of project schedule, risks, change, quality, communication, resources, and the various deliverables associated with the complete System Development Life Cycle (SDLC) of the Project.

b. The key stakeholders required to review and validate information relative to all steps of the project throughout the SDLC.

c. The process to provide input to the strategic and tactical reports on a regular basis.

d. Project performance measurements and critical success factors.

2. Vendor will create, collaborate, and review the Project Initiation presentation content with Key Project Stakeholders as directed by the State. The presentation will be reviewed by the State prior to presenting it and will include, at minimum, the following topics:

a. Project Overview.

b. Project Schedule (high level).

c. Objectives and Definitions.

d. Phases and Quality Stage Gates

e. Artifacts

f. Roles and Responsibilities.

g. Keys to Success.

h. Next Steps.

i. Questions and Answers (Q&A).

j. Resources.

3. Vendor will capture any decisions or agreements from the kickoff meeting and submit the documentation to the State for review and acceptance.

1. Key State staff co-present on the objectives, values, and expectations of the project, and the importance of the project to State’s overall vision.

2. Ensure participation in the project planning activities as this will be a pre-requisite to the development of the kick-off presentation.

3. Ensure participation in the Project Kickoff Meeting.

1. Scope and Requirements Management Plan – Project Scope Management includes the processes required to ensure the project completes all the work required, and only the work required, to complete the project successfully. Managing the scope is primarily concerned with what is in and out of the scope of the project and the traceability of scope items throughout the project. The Scope and Requirements Management Plan will include the following elements:

a. Define the scope of the project (scope statement) and the product (specified features, functions, etc.)

i. Product

ii. Deliverables

iii. Services

iv. Scope Exclusions

b. Define the project approach and methodology

c. Define the requirements management approach

i. How requirements will be planned, tracked, and reported

ii. Configuration management activities such as how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes

iii. Requirements prioritization process

iv. Metrics that will be used and the rationale for using them

v. Traceability structure that reflects the requirements attributes captured in the Requirements Traceability Matrix (see 3B – Requirements Traceability Matrix)

d. Define the work breakdown structure (WBS)

i. Work to be completed by project team to accomplish the project objectives and create the required deliverables, decomposed into work packages used to group the activities, work products and deliverables. (WBS is an input to the Project Schedule)

e. Define scope validation and acceptance process for project deliverables.

Define the entrance and exit criteria for each Quality Stage Gate.

2. Schedule Management Plan – This plan establishes the policies, procedures, and documentation for planning, developing and managing the project schedule. The Schedule Management Plan will:

a. Define the scheduling method (e.g., critical path, agile/iterative, Kanban)

b. Process for baselining the schedule and schedule updates

c. Provide a milestone list

3. Cost Management Plan – This plan aligns the project budget with the WBS to track progress and financial performance. The Cost Management Plan will be used on an ongoing basis to do the following:

a. Define standard thresholds and criteria for escalation.

b. Continually monitor and analyze project financial performance for risk, negative trends, or early indicators of unfavorable performance.

c. Provide performance reports based on the State and Vendor’s developed criteria.

4. Quality Management Plan – The Quality Management Plan addresses the management of the project and the deliverables of the project. Quality measures and techniques are specific to the type of deliverables being produced and will be specified in the Deliverable Expectations Document for project deliverables. The Quality Management Plan will include the following elements.

a. Defined quality assurance responsibilities.

b. Detailed definition of all deliverables by phase and associated acceptance criteria.

c. Project deliverable review and acceptance process.

d. Regularly scheduled reviews of key project phases, stage gate exit criteria and milestones.

5. Resource Management Plan – The Resource Management Plan includes the processes to identify, acquire, and manage the resources required to successfully complete the project successfully (both human resources and physical resources). The Resource Management Plan will include at a minimum:

a. Identification of resource requirements (Vendor and State), activities, roles and responsibilities, skill requirements, expertise, required level of engagement and duration

b. Define training requirements for project resources (if needed)

c. Define organizational structure for resources (reporting and coordination of project tasks)

d. Defined process to replace resources who have left the project Office Space, equipment, background checks, access requirements, meeting room requirements, etc.

6. Risk Management Plan – The purpose of the Risk Management Plan is to identify and manage risks that can have a positive or negative effect on the project objectives if they occur. The object of Risk Management is to exploit or enhance positive risks (opportunities) while avoiding or mitigating negative risks (threats). THE Vendor will develop a Risk Management Plan which will be used on an ongoing basis to do the following:

a. Create and update the Risk Assessment Log.

b. Anticipate and identify risks.

c. Identify the severity and quantify the potential impact of each identified risk.

d. Quantify the probability of each identified risk.

e. Support the development of risk mitigation plans for each identified risk.

f. Provide guidance for assessing the efficacy of risk mitigation actions.

g. Describe work products and processes for assessing and managing risks.

h. Detail the escalation and remediation mechanisms for risks.

i. Detail how risks and issues will be tracked and reported and the format of risk and issues reports (depth, detail, and content).

7. Communications Management Plan – The Communication Management Plan defines the communication activities for the project, including method, cadence and artifacts for both internal (project team) and external stakeholders. The Communication Management Plan includes:

a. Types of meetings and frequency including, status meetings, stakeholder meetings, project scrum meetings

b. Communication methods (email, reports, presentations, etc.)

c. Distribution methods

d. Approach for documenting and distributing meeting minutes

e. Collaboration tools

8. Stakeholder Management Plan – The Stakeholder Management Plan provides a structured approach to the identification, prioritization, and engagement of all stakeholders. The Stakeholder Management Plan includes:

a. Identification of all project Stakeholders (both internal and external and expectations and level of interest/support/influence in the project

b. Stakeholder register (position, location, contact details) Engagement plan for each stakeholder (communication / engagement strategy)

9. Change Management Plan – This plan covers both technical and non-technical changes and will be jointly developed by the Vendor and State. The Change Management Plan will be used on an ongoing basis to do the following:

a. Track all Change Requests, including providing a status. It will contain at a minimum the following:

i. Tracking Number and date of the request.

ii. Priority Rating of the request.

iii. Category of the Request (Technical or Non-Technical), as long as the non-Technical changes do not include Organizational Change Management (OCM) changes.

iv. Scope Determination (In Scope or Out of Scope).

v. Requestor Information (name, title, department, contact information).

vi. Impact of Requested Change (budget, schedule, staffing, etc.).

vii. Benefit of the Requested Change.

viii. Urgency of the Requested Change (e.g., routine, urgent, immediate, critical).

ix. Assessment of contract language and alterations necessary.

ix. Authorization or Denial of the Change Request.

x. Status of the Change (in work, not started, on hold).

xi. Required Completion Date.

xii. Point of Contact for follow-on action(s) required.

xiii. Due date for next action.

b. Analyze the impact of Change Requests. The impact of the proposed Change Request will be documented in the Change Request Form.

c. Authorize or Deny the Request. The authorization or denial will be in writing using the Change Request Form.

d. Change Orders will be signed by the Vendor Project Manager and State Contract Authorized Representative and any contract amendments required signed by all original parties prior to execution of any work related to the change.

The Vendor Responsibilities

1. Shall facilitate and lead the discussions to finalize the various sub-plans within the Project Control document.

2. Shall incorporate related decisions made during the project planning and kickoff meetings into the plan.

3. Maintain complete and up-to-date team organization charts as well as contact lists that provide names, titles, phone/pager/cell phone numbers, and email information for all personnel assigned to the project.

4. Shall create, in conjunction with the State, project performance metrics.

1. Ensure participation in meetings and activities.

2. Create, in conjunction with The Vendor, project performance metrics.

The Work Breakdown Structure (WBS) will define the project’s overall objectives by describing the project tasks, deliverables, milestones, and resourcing.

1. The WBS will include:

a. A consolidated view of the activities, activity descriptions, and activity durations assigned to the State and the Vendor.

b. Resources (State, Vendor, and third-party vendors) assigned to each activity and their required level of effort.

c. A list of all required project deliverables tied to the appropriate project milestones.

d. Identification of all key Project Milestones.

e. Deliverable approval periods in concert with State’s DED process as described in the Project Management Plan Deliverable Development and Acceptance Process.

f. A critical path analysis and reporting process.

The Vendor Responsibilities

1. Shall develop the Project Schedule with input from the State PM and others designated by the State.

2. Shall baseline the Project Schedule

3. Shall maintain the Project Schedule on an on-going basis throughout the life of the project and update it, in collaboration with the State’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

4. Shall ensure the availability of the Project Schedule in a central location.

1. Provide input into the Project Schedule.

1D – Change Log

a. Tracking Number and date of the request

b. Priority Rating of the request

c. Category of the Request (Technical or Non-Technical), as long as the non-technical changes do not include Organizational Change Management (OCM) changes

d. Scope Determination (In Scope or Out of Scope)

e. Requestor Information (name, title, department, contact information)

f. Impact of Requested Change (budget, schedule, staffing, etc.)

g. Benefit of the Requested Change

h. Urgency of the Requested Change (e.g., routine, urgent, immediate, critical)

i. Authorization or Denial of the Change Request

j. Contract Amendment Status

k. Status of the Change (in work, not started, on hold)

k. Required Completion Date

l. Point of Contact for follow-on action(s) required

m. Due date for next action Vendor Responsibilities

1. Shall maintain the Change Log on an on-going basis throughout the life of the project and update it, in collaboration with the State’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

2. Shall ensure the availability of the Project Change Log in a central location.

3. Shall update the Requirements Traceability Log based on Change Order decisions

1. Follow the project change management processes

2. Approve, Deny, Defer Change Orders in accordance with change management processes

1E – Risk Log

a. Date Risk was Identified

b. Description of Risk

c. Impact Description (budget, schedule, staffing, etc.)

d. Severity of the Risk

e. Probability of the Risk

f. Risk Mitigation Strategy

g. Action Items and Assignment

h. Status of the Risk (Open, Closed) Vendor Responsibilities

1. Shall maintain the Risk Log on an on-going basis throughout the life of the project and update it, in collaboration with the State’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

2. Shall ensure the availability of the Project Risk Log in a central location.

3. Shall provide an update on key risks and issues on Weekly Status Reports

1. Follow the project risk management processes

2. Participate in risk identification and mitigation activities

1F - Decision Log

a. Issue/ Decision No

b. Status (open, closed)

c. Description of Issue

d. Decision Description

e. Priority (L/M/H)

f. Raised by

g. Owner Decision Maker Vendor Responsibilities

1. Shall maintain the Decision Log on an on-going basis throughout the life of the project and update it, in collaboration with the State’s PM as necessary, but no less than weekly to reflect the accurate status of the project.

2. Shall ensure the availability of the Decision Risk Log in a central location.

3. Shall provide an update on key issues and decisions on Weekly Status Reports

1. Participate in Issue resolution / project decision making

Planning

Write State specific requirements for Monthly Project Management

1. TBD

a. Introduction

b. Purpose

c. Scope

d. References & Related Documentation

e. Glossary of Terms

f. Classification Approach (e.g., Standard Feature, Configuration, Gap, etc.)

g. Requirements Analysis (Functional & Technical) – per functional/technical group

i. Analysis Approach

ii. Client Objectives (per functional/technical group)

iii. Scope of Analysis

iv. Client Business Overview (capabilities, systems in use, processes, reports,

v. Analysis

vi. Recommendations

h. List of Gaps with Proposed Remediation Options

i. Proposed Gap Remediation Vendor Responsibilities Identify how all requirements will be addressed within the solution, identify gaps, identify options to resolve gaps, document gap resolution decisions in the Project Decision Log. Resolutions can include modifications to business processes, solution enhancements, removal from scope, etc.

1. Confirm and accept gap analysis, select resolution for each gap.

a. Requirements ID

b. Source of Requirement (SOW, Gap Analysis, Stakeholder Request, etc.)

c. Create Date

d. Description of Requirement

e. Technical / Functional Grouping

f. Status of Requirement (proposed, approved, rejected, gap, etc.)

g. Classification (e.g., Critical, Important, Useful)

h. Configuration status

i. Design status

j. Development status

k. Test Case ID

l. Test Status Vendor Responsibilities: Maintain Requirements Traceability Matrix (real-time), provide the State access to RTM, publish reports derived from Traceability items, identify change items, and generate change orders.

1. Review & Validate RTM, approve/deny change orders.

a. Solution Architecture Overview

b. Architecture Components

c. Architecture Diagrams

d. Applications

e. Infrastructure

f. Sites

g. Middleware

h. Integration

i. Interfaces

j. Processes

k. Environments

l. Hosting Service Specifications

m. Licenses / Agreements

n. Security (end-user authentication, access control configuration)

o. Software/Hardware requirements

p. Auditing

q. Configuration Management Plan

r. Help Content Development & Maintenance Vendor Responsibilities: Tailor SAD to State context (hosting, user authentication, environments, licensing, etc.).

1. Provide input based on State architectural requirements. Review & Validate SAD.

Elements of a SCS should contain at a minimum:

a. Hardware Configuration

b. Operating System Configuration

c. Software Configuration

d. Interface Configuration

e. Data Configuration Vendor Responsibilities: Work with State Subject Matter Experts to tailor the configuration based on gap analysis review / decisions. Provide spreadsheets to the State to document configuration values. Update Requirements Traceability Matrix.

1. Provide input based on State specific configuration requirements. Review & Validate SCS.

a. Navigation

b. User Interface (screen / report mock-ups)

c. Inputs/Outputs

d. Db Tables/Columns

e. Field Edits/Validation Rules

f. Error Handling & Messages

g. Access Roles

h. Report Parameters, Sort, Groups, etc.

i. Business Rules

j. Logical Data Model

k. Audit Logging

l. References and Standards

m. Requirements Traceability Vendor Responsibilities: Work with State Subject Matter Experts to elaborate the design based on gap analysis review / decisions. Update the Requirements traceability Matrix.

1. Provide input based on State requirements. Review & Validate SDS

a. Report Listing

a. Name of Report

b. Description

c. Fields

d. Parameters

e. Calculations

f. Sort Order

g. Filtering

b. Dashboard Listing

a. Name of Dashboard

b. Description

c. Columns

d. Parameters

e. Sort & Filter Options

c. Forms Listing

a. Name of Form

b. Description

c. Fields

d. Parameters

e. Calculations

d. Queries Listing (supported by analytics tools)

a. Name of Query

b. Description

c. Data

d. Calculations Vendor Responsibilities: Work with State Subject Matter Experts to compile the inventory based on gap analysis review / decisions. Update Requirements Traceability Matrix

1. Provide input based on State requirements. Review & Validate listing.

a. Cloud or Hybrid Infrastructure Deployment mapped to State Design Requirements

b. Infrastructure Security Components Deployment mapped to State Specifications

c. Backup(s), Snapshot(s) and Replication(s) Deployment mapped to State Specifications

d. Environment Performance, Security, Audit Logging and Alerting Deployment mapped to State Specifications Vendor Responsibilities: Deploy the Infrastructure Environment Configured to State provided specifications. Facilitate workshops to validate State specific configurations. Deploy and Publish the Infrastructure Environment for State review and approval. Provide a transmittal release document to State with Environment release number, release notes that outline progress and changes from the previous build.

1. Allocate and assign State SMEs to participate in validation sessions. Review, Test & Validate the Infrastructure Environment Configuration builds as they are released per schedule.

a. System Configuration to Design Specifications

b. Configure Parameters by Type (e.g., Structural, Validate Values, Set Read-only and System Overrides)

c. Configure Data Types

d. Set Name and Label Configurations

e. Set User and User Role Configurations

f. Set System Administration Configurations Vendor Responsibilities: Configure the Application Build(s) to State provided specifications. Facilitate workshops to validate State specific configurations. Build and Publish the Application for State review and approval. Provide a transmittal release document to the State with build number, release notes that outline progress and changes from the previous build.

1. Allocate and assign State SMEs to participate in validation sessions. Review, Test & Validate the Application Configuration builds as they are released per schedule.

a. Reporting Infrastructure

b. Self-Service, User and Administrator reports and dashboards

c. Custom components developed to specifications mapped to State requirements

d. Third-party Software

e. Administrative Tools Vendor Responsibilities: Deploy the Reporting Infrastructure, Reports, Dashboards, and Custom Components to the State provided specifications. Facilitate workshops to validate State requirements. Build and Publish the Reporting Infrastructure, Self-Service, User & Administrator Reports and Dashboards for State review and approval. Provide a transmittal release document to the State with build numbers and release notes that outline progress and changes from the previous build.

1. Allocate and assign State SMEs to participate in validation sessions. Review, Test & Validate the Application Configuration builds as they are released per schedule.

4A – Detailed Data Cleansing Plan(s)

a. Approach

a. Clearly stated data cleansing objectives

b. Identified Vendor and State Assumptions

c. Identified Constraints

d. Risks

b. Data Cleansing Strategy

a. Cleansing Scope

b. Cleansing Approach

c. Roles & Responsibilities

d. Cleansing Schedule

e. Cleansing Quality Assurance and Validation

c. Data Cleansing Preparation

a. Prerequisites (e.g., Sandbox Environments & Tools)

b. Backup / Snapshot Strategy

c. Backout and Restore Process

d. Data Cleansing Specifications Vendor Responsibilities: Develop the Detailed Data Cleansing Plan(s) with State provided input. Facilitate workshops to identify State specific requirements. Publish the Detailed Data Cleansing Plans for State review and approval.

1. Allocate and assign State SME resources to participate in workshop sessions. Review & Validate the Detailed Data Cleansing Plans(s)

4B: Detailed Data Conversion Plan(s)

a. Approach

a. Clearly stated data conversion objectives

b. Identified Vendor and State Assumptions

c. Identified Constraints

d. Risks

b. Data Conversion Strategy

a. Conversion Scope

b. Conversion Approach

c. Roles & Responsibilities

d. Conversion Schedule

e. Conversion Quality Assurance and Validation

c. Data Conversion Preparation

a. Prerequisites (e.g., Sandbox Environments & Tools)

b. Backup / Snapshot Strategy

c. Backout and Restore Process

d. Data Conversion Specifications Vendor Responsibilities: Develop the Detailed Data Conversion Plan(s) with State provided input. Facilitate workshops to identify State specific requirements. Publish the Detailed Data Conversion Plans for State review and approval.

1. Allocate and assign State SME resources to participate in workshop sessions. Review & Validate the Detailed Data Conversion Plans(s).

a. Approach

a. Clearly stated data migration objectives

b. Identified Vendor and State Assumptions

c. Identified Constraints

d. Risks

b. Data Migration Strategy

a. Migration Scope

b. Migration Approach

c. Roles & Responsibilities

d. Migration Schedule

e. Migration Quality Assurance and Validation

c. Data Conversion Preparation

a. Prerequisites (e.g., Sandbox Environments & Tools)

b. Backup / Snapshot Strategy

c. Backout and Restore Process

d. Data Migration Specifications Vendor Responsibilities: Develop the Detailed Data Migration Plan(s) with State provided input. Facilitate workshops to identify State specific requirements. Publish the Detailed Data Migration Plans for State review and approval.

1. Allocate and assign State SME resources to participate in workshop sessions. Review & Validate the Detailed Data Migration Plans(s).

4D: Conduct Data Conversion(s) and Migration(s)

a. Data Extraction and Staging

b. Data Transformation and Loading

c. Data Synchronization

d. Migration Reversal

e. Migration per Data Source to Schedule Vendor Responsibilities: Conduct the Data Conversion(s) and Migration(s). Facilitate workshops to identify State specific requirements. Publish the Data Conversion(s) and Migration(s) builds for State review and approval to schedule.

1. Allocate and assign State SMEs to participate in validation sessions. Review, Test & Validate the Data Conversion(s) and Migration(s) iterations as they are released per schedule.

a. Design Guidelines & Approach

a. Glossary of Terms

b. Design Considerations

c. Assumptions, Constraints & Risks

d. Alignment with State Architecture

b. Design Considerations

a. Development Methods & Contingencies

b. Architecture Strategies for State Alignment

c. Data Exchange Performance Requirements

c. System Architecture & Architecture Design

a. Logical View

b. Hardware Architecture

c. Software / Tools Architecture

d. Information Architecture

e. Security Architecture

f. Performance

g. Full Integration Architecture Diagram

d. Interface & Data Exchange Design

a. Interface & Data Exchange Requirements

b. Database Impacts

c. Security Requirements

e. Internal Interface Requirements

f. External Interface Requirements Vendor Responsibilities: Develop the Interface & Data Exchange Specification Document(s) with State provided input. Facilitate workshops to identify State specific requirements. Publish the Interface & Data Exchange Specification Document(s) for State review and approval.

1. Allocate and assign State SME resources to participate in workshop sessions. Review & Validate the Interface & Data Exchange Specification Document(s).

5B - Conduct Interface and Data Exchange Development