Enterprise MDM Supplement

Supplement 1
Enterprise Master Data Management (MDM)

Requirements, System Development Methodology
and Staffing Requirements
State of Ohio Department of Administrative Services, Office of Information Technology

Supplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 1
Table of Contents
1.0 Enterprise Master Data Management: Background and Overview 4
1.1 General Scope 4
1.2 Discovery Period 6
2.0 General Project Requirements 6
2.1 Data Management Strategy 6
2.1.1 Data Governance & Stewardship 6
2.1.2 Data Quality Management 6
2.1.3 Metadata Management 7
2.1.4 Key Deliverables 7
2.2 Enterprise MDM Solution Architecture 7
2.2.1 Key Deliverables 8
2.3 Ohio Benefits Expansion and Hardware Upgrade 8
2.3.1 Key Deliverables: 9
2.4 Enterprise MDM Service Integration with EDW 10
2.5 JFS Enterprise MDM Initiative 11
2.6 Medicaid Provider Management 12
2.7 Identity Management Integration 13
2.8 Development and Testing Environment Support 13
2.9 Maintenance and Operations 13
2.10 Data Quality Execution 13
2.11 Unanticipated Project Services 14
3.0 Solutions Requirements: Business, Data and Non-Functional Requirements 14
3.1 Overview of State Systems Referenced in this Supplement 14
3.2 Additional State Data Stores 14
3.3 Solution Sizing Requirements 15
3.4 Organization of Requirements 15
3.5 Business Requirements 17
3.6 Data Requirements: “Individual” Domain 29
3.7 Data Element Requirements: “Business” Domain 33
3.8 Non-Functional Requirements 35
3.9 RFP Assumptions 44
4.0 State Project Delivery, Management, Methodology and Approach Requirements 44
4.1 Project Management and Coordination Services 46
4.2 State Project Governance Considerations 47
4.3 Create and Maintain Project Plan 47
4.4 Project Financial Management 49
4.5 Project Review Check Point 51
4.6 Meeting Attendance and Reporting Requirements 51
4.7 Utilize OIT’s Document Sharing/Collaboration Capability 52
4.8 Production/Version Control and Release Management 53
4.9 Maintaining Solution and Operations Documentation 54
4.10 Project Delivery, Role and Responsibility Requirements 54
4.11 System/Environment Administration Support of the Project 54
4.12 Establish and Manage a Program Management & Master Release Calendar 55
4.13 Cooperation with State and State Contractors 55
4.14 Requirements Confirmation and Analysis (for each release) 55
4.15 Current Environment Assessment 55
4.16 Data Governance and Stewardship 56
4.16.1 Agency Data Quality Improvement Plan 56
4.17 Analyze Phase Requirements (for each planned release) 56
4.18 Design Phase Requirements (for each planned release) 57
4.19 Build Phase Requirements (for each planned release) 58
4.20 Test Phase Requirements (for each planned release) 58
4.20.1 Project Incident Management 60
4.20.2 Project Defect Management 60
4.21 Deploy Phase Requirements (for each planned release) 61
4.22 Organization Change Management 62
4.23 Knowledge Transfer and Production Handoff (for each planned release) 63
4.24 Project Completion Activities, Final Documentation and Post Implementation Support Obligations 64
4.25 Future Project Services Pricing Response and Rate Card 64
5.0 Schedule of Deliverables and Work Products 65
5.1 Delivery and Deliverable Standards 65
5.2 Schedule of Deliverables and Work Products 65
6.0 State Staffing Requirements 78

6.1 Contract Staffing and Key Activities 80
6.2 Staffing Plan and Time Commitment 81
6.3 Background Checks 82
7.0 Assumptions 83
7.1 Support Requirements 83
7.2 Pre-Existing Materials 83
7.3 Commercial Materials 83
8.0 Informatica Platform Environments 84

8.1 Informatica Platform Environment Implementation and Support During Development 84
9.0 Appendix A: Project Development Methodology Deliverables by Release 85

1.0 Enterprise Master Data Management: Background and Overview
The State is currently completing work on a Master Data Management (MDM) implementation which supports a
cross-agency Integrated Eligibility solution. This MDM implementation when completed will contain two Master
Data domains referred to as the Master Client Index (MCI) and Master Provider Index (MPI). This MDM
implementation is built using the Informatica Multi-Domain MDM platform, and is used to prevent data from being
duplicated at the point of entry within the Integrated Eligibility system.
The purpose of this project is to expand the current MDM implementation with data from additional agencies and
to enhance or add key MDM business capabilities. This expansion will advance the State’s ability to share and
use Master Data within and across agencies, while accounting for Federal Regulations, Ohio Revised Code, and
inter-agency data use agreements which govern the ability to do so. The scope of the Enterprise MDM RFP will
involve incorporating data from a limited set of systems from three (3) State Agencies: Ohio Department of
Medicaid (ODM), Ohio Department of Job and Family Services (JFS) and Ohio Department of Administrative
Services (DAS). The scope will allow the business capabilities to expand beyond the current focus on duplicate
detection to include:
 Facilitation of cross-agency integration via a common registry of system identifiers (IDs)

 Improved Data Quality at point of entry via integrated data quality rules
 Enhanced analytics through use of a harmonized golden record
1.1 General Scope
 Provide a functional (process and data quality) and technical assessment (design) of the current MDM
implementation, documenting lessons learned and recommendations for the future state architecture
 Design and gain approval for an Enterprise MDM architecture which supports data maintenance, data
integration and analytics use cases for ODM, JFS and DAS as defined in Section 2.0
 Ensure the Enterprise MDM solution will be able to support three (3) Master Data Domains: Individual,
Business, and Employee, and a common set of Master Reference Data. Only Individual, Business and Master
Reference Data are in scope. The domains are defined as follows:
 Individual: An Individual who is interacting for themselves or on the behalf of another Individual to
engage with or receive services from the State. An Individual has various internal names including
citizen, resident, client, recipient, beneficiary, individual tax payer, claimant, seeker, providers, etc.
 Business: A business is an individual or organization who is engaged in providing products or services to
or on behalf of the State. A Business has various internal names including licensed/certified providers,
local education districts, hospitals, day care centers, community homes, payers, pharmacies, laboratories,
vendor, etc.
 Employee: Any individual who is fulfilling the role of a known State agency employee, contingency
worker, contract worker, staff, Contractor, etc.
 Master Reference Data: Master Reference Data is any look-up data, look-up codes or any other type of
data that is used exclusively for categorizing data within one of the primary Data Domains
 Ensure the architecture is flexible to expand scope over time with respect to modifying the number of hubs,
agencies, source/target systems, domains, tables, attributes, rules, algorithms, etc.
 Ensure the architecture complies with all Federal, State and inter-agency guidelines with respect to the use and
sharing of data between ODM, JFS and DAS, and can be expanded to additional agencies as business needs
require
 Design, develop and implement a Data Governance and Stewardship strategy, which accounts ensuring timely
decisions are made and that data is actively managed and monitored to ensure initial and on-going data quality
 Design, develop and implement a Data Quality Management strategy which allows for the proactive definition,
documentation and education of Master Data quality standards and the active review of data to ensure
adherence to defined standards
 Design, develop and implement a Metadata Management strategy, which will result in standardized processes
and tools for obtaining, verifying, storing and distributing business/technical metadata relevant to the Enterprise
MDM implementation utilizing Informatica’s Business Glossary and Metadata Manager
 Lead the data remediation efforts to ensure that the Enterprise MDM solution is loaded with high quality Master
Data
 Work with each Agency to re-assess, refine and validate functional, data and non-functional requirements to
ensure a complete and implementable set of requirements for the releases identified in Section 2.3, 2.4, 2.5 and
2.6
 Design, build, test, implement and provide warranty support for the releases identified in Sections 2.3 and 2.4
 Complete the design work, and create implementation plans for the releases identified in Sections 2.5 and 2.6
 Specify and implement Informatica Platform environments to support development and testing activities for the
releases identified in Sections 2.3, 2.4, 2.5 and 2.6 consistent with environment requirements defined in
Sections 2.8 and 8.0
 Provide industry best practices for integrating an Identity Management solution with a Master Data
Management solution as defined in Section 2.7
 Define and document a post-implementation Maintenance and Operations (e.g., “Run”) strategy for the
Enterprise MDM environment
 Assume ownership for Maintenance and Operations (M&O) for releases covered in Section 2.3 and 2.4 once
the respective warranty periods have completed
 Overview of anticipated releases:
Refer to Release Domains in Agencies in Source System Consuming Anticipated

Document Scope Scope System Project Release
Section #: Date
2.3 Ohio Benefits  Individual  DAS  Ohio Benefits  EDW May/Jun 2018
expansion and  Business  Medicaid  Master Client  Ohio Benefits
hardware upgrade  JFS Index  MMIS
2.4 Enterprise MDM  Individual  Medicaid  Enterprise MDM  Enterprise Sep 2018
Service integration with  Business Data
EDW Warehouse
2.5 JFS Enterprise MDM  Individual  JFS  OJI  OJI Multi-Phase
Initiative  OWCMS  OWCMS  April 2018
 Ohio Benefits  Ohio Benefits  TBD
 + 1 TBD
2.6 Medicaid Provider  Business  Medicaid  MMIS  EDW No earlier than
Management  DAS – OAKS  OAKS  OAKS Dec 2018
(Finance)

Refer to Release Domains in Agencies in Source System Consuming Anticipated
Document Scope Scope System Project Release
Section #: Date
2.7 Identity Management  Future  DAS - DX  IDM  N/A Future
(IDM) Integration
1.2 Discovery Period

After award of Contract and commencement of work by the Contractor, the Enterprise MDM Project will be in a
Discovery Period. The discovery period is anticipated to have a duration of approximately three (3) months and is
comprised of the Enterprise MDM Solution Architecture, Data Management Strategy, and Ohio Benefits
Expansion and Hardware Upgrade work that will occur during this timeframe. Any State-approved refinements to
the Project or Work required due to the discovery period, may be cause for a limited fee adjustment. During the
discovery period, a Go/No-Go decision will be made by the State. If the State decides not to go forward with the
Work described in this Supplement, cancels this RFP for any reason, or contracts for the Work through some
other process or through another RFP, the State will be liable to the Contractor for those deliverables completed
and approved by the State during the discovery period.
2.0 General Project Requirements
2.1 Data Management Strategy
2.1.1 Data Governance & Stewardship

The State has implemented Data Governance practices to drive business-centric decision-making within
agencies. As the State expands the use of the Master Data Management service across agencies, it recognizes
that its Data Governance practices must do the same. The State is asking for the Offeror to evaluate current Data
Governance practices, and to propose and implement a Data Governance Strategy and Framework that
recognizes the unique decision-making needs at the State and Agency levels
The Offeror will be expected to:
 Define a Data Governance Strategy and Framework to meet State and Agency Level needs
 Define and Document key aspects of the framework including policies, procedures, roles & responsibilities, key
performance indicators, etc.
 Mentor individuals assigned to Data Governance roles
2.1.2 Data Quality Management

The State understands the importance of ensuring quality data is loaded into the Enterprise MDM, and the need
to continually and proactively monitor the data over time to ensure Data Quality persists. The Offeror will be
expected to develop a Data Quality Strategy and Approach which will, at a minimum, encompass the following:
 Processes to define, approve data quality standards, match rules, merge rules, unmerge rules, etc.
 Formalized approaches to:
 Profile and analyze data
 Identify, document and remediate data quality issues
 Identify missing data and establish enrichment plans
 Monitor data quality over time
 Develop reusable data quality rules to automate data standardization and cleansing
 Training materials to train Data Governance and Project team members on Data Quality Management
2.1.3 Metadata Management

The State understands that as it continues to drive stronger Data Management practices, the importance of
managing its Business and Technical metadata will increase. Therefore, the Offeror is expected to develop an
approach to creating, managing and making available Metadata related to the Enterprise MDM implementation.
The Offeror will be expected to:
 Develop a Metadata Management Strategy and Approach to manage and monitor the metadata
 Install and Configure Informatica Business Glossary and Metadata Manager in accordance with the defined
process and metadata attribute requirements
 Train Data Stewards and project team members on the processes and tools adopted
 Import relevant existing Metadata into the tools
 Support the Business Glossary and Metadata Manager environments during the project phases
 Define and implement processes to maintain Business Glossary and Metadata Manager environments on an
ongoing basis.
2.1.4 Key Deliverables

 Data Governance Strategy and Framework
 Metadata Management Strategy and Approach
 Data Quality Management Strategy and Approach
 Organizational Change Strategy and Plan
 Organization Change Job Aids and Training Materials
 Training materials (guides, job aids and/or play or run books) for Business Glossary and Metadata Manager
Refer to Sections 4 and 5 as well as Appendix A of this supplement for a complete discussion of methodology,
deliverables and work products
2.2 Enterprise MDM Solution Architecture

The long-term architectural direction with respect to the architecture model (single or multiple hubs) and the
implementation style (Consolidation, Co-existence, Transaction, etc.), which must be implemented, are not
defined. The Offeror is being asked to assess the defined functional requirements, data requirements, non-
functional requirements, current state architecture, relevant Federal and State laws pertaining to sharing data

across agencies (please refer to Supplement 2), and to propose an Enterprise MDM solution architecture and
implementation style.
The proposed Enterprise MDM solution architecture must make use of Informatica’s Multi-Domain MDM solution.
The State has procured an enterprise license for Informatica Multi-Domain MDM, which has sufficient licensing to
support up to nine (9) hub instances, each containing up to four (4) data domains with an unlimited number of
consolidated records. Additionally, the State has no limitations on the number of named users of Informatica Data
Director (IDD).
The State has the following additional Informatica technologies, which must be considered as the overall
architecture is designed
 Informatica PowerCenter
 Informatica Data Quality
 Informatica Business Glossary
 Informatica Metadata Manager
2.2.1 Key Deliverables

 Current Environment Architectural Assessment
 Proposed Solution Architecture
2.3 Ohio Benefits Expansion and Hardware Upgrade

The Ohio Department of Administrative Services (DAS) in coordination with the Ohio Department of Medicaid
(ODM) and the Ohio Department of Job and Family Services (JFS) have jointly implemented an Integrated
Eligibility solution, Ohio Benefits (O.B.). To provide enhanced capabilities for managing and searching for
Individual (Client) and Business (Provider) Master Data, O.B. was integrated with a lightweight MDM
implementation. The existing MDM solution provides a Master Data repository and probabilistic search
capabilities to identify and prevent duplicate records from being introduced into the Ohio Benefits solution. To
continue to improve data quality, the goal of this project is to transition from a lightweight MDM implementation to
a more robust solution and to transition to a new hardware infrastructure, which will be provided by the state. As
part of this initiative, the Offeror will be expected to:
 Partner with the DAS-OIT team to define HW specifications

 Install, configure and support Informatica Multi-Domain MDM and other required platform services during the
project
 Assess and enhance, as appropriate, search capabilities used to identify potential duplicates early in the Master
Data Management process
 Partner with the assigned Data Steward to create new workflows to:
 Standardize, Cleanse and Enrich source system data as required to meet eEnterprise MDM data
standards
 Identify duplicate records and, when necessary, manually resolve them into a single global record, with a
unique global identifier
 Monitor Enterprise MDM Process and Master Data quality key performance indicators (KPI’s) to ensure
the efficiency and effectiveness of the solution
 Implement automated data integration between the Enterprise MDM service, O.B. and MMIS to eliminate
manual processes currently required in each source system to propagate updates resulting from changes to
Master Data (e.g., attributes, merge, unmerge, etc.)
 Refer to Section 3 of this supplement for a complete list of business, data and non-functional requirements
2.3.1 Key Deliverables:

 Project Charter, Plan, and Kick-Off Package
 Data Cleansing Approach and Tools
 Requirements Definition
 Solution Architecture
 Data Quality Remediation Plan
 Implementation & Deployment Strategy
 Capacity Plan
 Functional Design Document(s)
 Technical Design Document(s)
 Security Design
 Technology Environments for Development and Test
 Data Conversion/Migration Plan
 Test Strategy
 Data Quality Scorecard
 Solution Component Code, Objects & Configuration
 Test Scripts & Cases
 Deployment & Stabilization Plan
 System Test Results Report
 Performance Test Results Report
 User Acceptance Test Results Report
 Operational Readiness Test Results Report
 System Turnover

2.4 Enterprise MDM Service Integration with EDW
The Ohio Department of Administrative Services (DAS) is establishing an Enterprise Data Warehouse (EDW) to
provide cross-agency analytic capabilities. To facilitate the integration of data from multiple source systems, the
Enterprise MDM system will become the EDW’s source of truth for Individual and Business Master Data. The
outcome of the EDW Integration scope will be an enterprise methodology and initial implementation for providing
the EDW with high quality Master Data. The methodology and implementation concepts must be reusable and
scalable, to support the EDW as its scope expands and begins to incorporate data from additional agency
solutions. As part of this initiative, the Offeror will be expected to:
 Partner with the DAS EDW team to develop a transition plan to use Enterprise MDM service as the source of
their master data (i.e., Individual and Business)
 Convert EDW sourcing Individual and Business Master Data from MMIS to the enhanced Enterprise MDM
service for Individual (Recipient) and Business (Provider) conformed dimension management.
 Develop integration services which provide batch and (near) real-time look-up of the unique global identifier
 Refer to Section 3 of this supplement for a complete list of business, data and non-functional requirements

 Updated Capacity Plan
 Security Design
 Test Strategy
 Data Quality Scorecard
 Solution Component Code, Objects & Configuration
 Test Scripts & Cases
 Deployment & Stabilization Plan
 System Test Results Report
 Performance Test Results Report
 User Acceptance Test Results Report
 Operational Readiness Test Results Report
 System Turnover
2.5 JFS Enterprise MDM Initiative

The Ohio Department of Job and Family Services (JFS) provides services to Individuals (citizens and residents of
Ohio) through its various offices. Each office utilizes their own independent solutions to manage unique master
lists of the Individuals for whom they provide services. JFS’s goal is to improve the management of these master
lists by utilizing the Enterprise MDM service. The two primary benefits from this effort will be to minimize
duplicate effort by reutilizing the data collected by peer offices and obtain a single registry of system ID’s across
systems, in order to improve their ability to share information. As part of this initiative, the Offeror will be expected
to expand the Enterprise MDM service to:
 Support the authoring capabilities within Ohio Benefits, OJI and OWCMS solutions to meet JFS needs
 Act as the single repository storing cross references of system identifiers (IDs) for JFS solutions and other State
Agency solutions which share data with JFS
 Support Data Steward efforts via workflows to:
 Standardize, Cleanse and Enrich source system data as required to identify matching records
 Identify matching records and develop a registry comprised of a unique global identifier and the
respective local system identifiers (IDs)
 Provide multiple pathways (push or pull) to access and utilize the cross reference whether real-time via web
services or obtaining batch updates which can be stored locally in each respective system
 Support initial data conversions and on-going data integrations of transactional data, which require look-up of
the unique global identifier via batch or (near) real-time services
Refer to Section 3 of this supplement for a complete list of business, data and non-functional requirements

 Security Design
 Test Strategy
2.6 Medicaid Provider Management
The Ohio Department of Medicaid is replacing its integrated Medicaid Management Information System (MMIS),
with a modern, modularized implementation. The new implementation will include a module, Provider
Management, to manage Business Master Data (e.g., Provider) and to integrate it across each additional MMIS
module, as well as other State solutions, such as Ohio Administrative Knowledge System (OAKS). The Offeror
will be expected to expand the existing MDM architecture so that it augments and supports the following
capabilities provided by the Provider Management module:
 Assess and enhance the search capabilities to identify potential duplicates early in the Master Data
Management process
 Support Data Steward efforts via workflows to:
 Standardize, Cleanse and Enrich source system data as required to meet enterprise data standards
 Identify duplicate records and resolve them into a single global record, with a unique global identifier, as
required
 Synchronizing changes to the Business (Provider) Master to and from other MMIS modules and other agency
solutions (e.g. OAKS)
Refer to Section 3 of this supplement for a complete list of business, data and non-functional requirements


 Security Design
 Test Strategy
2.7 Identity Management Integration

The State is implementing an enterprise Identity Management (IDM) solution, and is evaluating opportunities to
integrate the IDM solution with the Enterprise MDM service in order to create an enterprise view of identities and
accounts across the various State solutions. The Offeror is being asked to provide an industry assessment of
how leading organizations integrate these two solutions for this purpose. The Offeror is also being asked to
provide examples of actual implementation experience where this integration has been performed, if available.
2.8 Development and Testing Environment Support

The State is looking for a partner who will implement and support the development and testing environments
required for the development efforts discussed in this Supplement. Infrastructure requirements for these
environments are described in Section 8. The Contractor will coordinate with State OIT to procure or provision
each environment. Once the infrastructure components for each environment are ready, the Contractor will be
responsible for installing and configuring the Informatica platform. Additionally, the Contractor is being asked to
provide technical support for these environments throughout the design, development, testing and deployment
phases of each release described in this Supplement. The technical support team for these environments must
include an Informatica Administrator.
2.9 Maintenance and Operations

The State is looking for a partner who will support the Enterprise MDM platform and application components
commencing with transition management activities that occur during UAT and continuing through deploying the
release to the production environment and completing system turnover and knowledge management activities
with the application development team. The State requests a five-year maintenance and operations contract with
the Contractor with the ability to extend the contract twice for a two-year period. Please refer to Supplement 3,
which outlines the State and Contractor expectations for this effort.
2.10 Data Quality Execution

The State is anticipating that there will be manual efforts to review and cleanse data, above and beyond what
State resources will be able to support, in order to align data with defined Enterprise MDM data quality standards.
The State is looking to understand how the Offeror will be able to assist in staffing, training and managing these
temporary staffing resources on behalf of the Data Steward(s). Additionally, in order to provide funding for data
cleansing work required for the first two releases as defined in the RFP, the State requests that the Offeror
provide a pricing for 2,000 hours of Data Cleansing Services as a separate line item as a part of the Offeror’s
response to the RFP. The estimate for these services should be calculated using a blended rate for data
cleansing resources.
2.11 Unanticipated Project Services

In order to account for work that is identified beyond the scope documented within this RFP (i.e., unanticipated
project services), the State requests that the Offeror provide a pricing for 10,000 hours of Unanticipated Project
Services line item. This pool of hours will not be included as part of the Offeror’s fixed-not-to-exceed cost, but will
be used to fund unplanned work and enhancements that are beyond what the Offeror has agreed to in their RFP
response. The State also requests that the Offeror provide the resource/team structure planned to be utilized
when performing unanticipated project service work. The estimate for these services should be calculated using
the current blended rate for Unanticipated Project Services. Please refer to section 4.25 of this supplement for
specifics on the rate card and blended rates for future and unanticipated project work.
Unanticipated Project Services, excludes those services for manual data cleansing identified in Section 2.9 and
for Maintenance & Operations services as identified in Supplement 3. Unanticipated Project Services are not
intended to cover changes in project scope for either the project overall or a specific release.
3.0 Solutions Requirements: Business, Data and Non-Functional Requirements
3.1 Overview of State Systems Referenced in this Supplement

The State has analyzed the candidate source systems for the projects, and has provided in this section an
overview of the agency ownership and general sizing.
Agency or Contains Individual Contains Business

System Name Department “Individual” Row “Business” Row
Ownership Master Data Count Master Data Count
MMIS ODM Yes 9,000,000 Yes 335,000
Ohio Benefits DAS Yes 5,000,000 No N/A
Identity Management (IDM) DAS Yes Future Yes Future
Ohio Business Gateway DAS – TAX No N/A Yes 826,236 (Future)
OAKS DAS - Finance TBA To be Assessed Yes To be Assessed
OJI JFS Yes 3,400,000 Yes N/A
OWCMS JFS Yes 2,800,000 Yes N/A
Master Provider Index (MPI) DAS No N/A Yes In-Development
Master Client Index (MCI) DAS Yes 10,000,000 No N/A
3.2 Additional State Data Stores

The Offeror must specify how the solution will be designed and implemented to enable the State to add additional
data tables, data elements, source data and agency systems data. As part of this requirement, the Contractor will
produce a Logical as well as a Physical Data model for the Enterprise MDM.

3.3 Solution Sizing Requirements
The Contractor must analyze the capacity requirements (compute and storage) of the systems. The Contractor
will design and implement or otherwise provide tools to the State for archive and purge of data no longer required
by the System to State-provided backup devices. (e.g., “backup and archive all data that is older than 5 years” or
“backup and archive all load files from 2014”).
3.4 Organization of Requirements

The State has organized its requirements in this Supplement. The below is a general organization of the State’s
requirements.
Area Description / Contents

This section lists the general set of business capabilities that are required for the holistic Enterprise MDM implementation. Each
requirement in this section must be evaluated for its applicability for each of the identified projects.
Requirements
Business
The following is a description of each column in the table:
REQ ID: Provides the unique Id to be used for traceability during implementation
Requirements Description by Category: Provides the statements of what is expected from the BI solution
Requirement Status: The current lifecycle status for the requirement
This section lists the data elements proposed to be stored in the Enterprise MDM solution for stated and future requirements for the
Individual.
Data Element Requirements
Data REQ ID: Provides the unique Id to be used for traceability during implementation
- Individual
Data Element Name: Provides the business term for the Data Elements
Description: Provides the description of the data element
Status: Classifies the status from a data governance lifecycle perspective
Business Data Type: Classifies the data in general terms
Source System: Lists the source system(s) where the data element has been identified to exist
Reference Data Candidate: Identifies attributes which should be constrained by a list of values
Multiple Values Permissible: Identifies if the Data Element may be present multiple times for a “unique” Master Data Record
Field is Candidate for use in Matching: Identifies attributes which have been historically used to assist in data matching
This section lists the data elements proposed to be stored in the Enterprise MDM solution for stated and future requirements for the
Business.
Data Element Requirements
Data REQ ID: Provides the unique Id to be used for traceability during implementation
- Business
Data Element Name: Provides the business term for the Data Elements
Description: Provides the description of the data element
Status: Classifies the status from a data governance lifecycle perspective
Business Data Type: Classifies the data in general terms
Source System: Lists the source system(s) where the data element has been identified to exist
Reference Data Candidate: Identifies attributes which should be constrained by a list of values
Multiple Values Permissible: Identifies if the Data Element may be present multiple times for a “unique” Master Data Record
Field is Candidate for use in Matching: Identifies attributes which have been historically used to assist in data matching

Area Description / Contents
Non-functional This section lists the non-functional requirements as it pertains to user access and security for the BI solution.
requirements
REQ ID: Provides the unique Id to be used for traceability during implementation
Non-Functional Description by Category: Provides the statements of what is expected from the BI solution
Status: The current lifecycle status for the non-functional requirement
This section lists statements that are expected to be true for the requirements to be fulfilled.
Assumptions

RFP
Assumption ID: Provides the unique Id to be used for traceability

Assumption Description: Provides the description of the assumption

3.5 Business Requirements
Note: For section 3.5, Offerors can address the Business Requirements at the end of each
section. Offerors do not have to address each Business Requirement individually.
REQ ID Requirement Description by Category Requirement

Status
BR-DPA Data Profiling & Analysis
BR-DPA.001 The Contractor shall configure and implement Informatica Data Quality (IDQ) to allow the Data Proposed
Steward (or delegate) to run periodic or on demand field level data profiling on source, target and
Enterprise MDM data.
BR-DPA-002 The Contractor shall provide the ability for the Data Steward (or delegate) to draft Data Quality rules Proposed
to address data quality issues, in the IDQ and implement them.
BR-DPA-003 The Contractor shall enable Data Stewards (or delegate) to develop Data Quality scorecard(s) Proposed
and/or reports, which provide a real-time view of current data quality (Completeness, Uniqueness,
Value distribution, Range, Pattern, Matches, De-duplication, Attribute data quality, Process
efficiency, etc.) in Enterprise MDM.
BR-DPA-004 The Contractor shall enable Data Stewards (or delegate) to develop historical Data Quality Proposed
scorecard(s) and/or reports for a historical view and trend analysis in Enterprise MDM.
Offeror
Response
BR-PRP MDM Pre-processing

BR-PRP-001 The Contractor shall configure and implement MDM System to parse all in-bound data from source Proposed
systems into Enterprise MDM to adhere to agreed upon canonical model(s).
BR-PRP-002 The Contractor shall configure and implement MDM System to enforce minimum data requirements Proposed
in order to accept any inbound data into Enterprise MDM.
BR-PRP-003 The Contractor shall configure and implement MDM System to accept any inbound data that meets Proposed
the Enterprise MDM minimum data requirements.
BR-PRP-004 The Contractor shall configure and implement MDM System to reject any inbound data that does Proposed
not meet the Enterprise MDM minimum data requirements.
BR-PRP-005 The Contractor shall configure and implement MDM System to maintain a log of all the rejected Proposed
records in an accessible repository for the Data Steward (or delegate) to review.
BR-PRP-006 The Contractor shall configure and implement MDM System for the Data Steward to prioritize and Proposed
manage remediation of rejected records.
BR-PRP-007 The Contractor shall configure and implement MDM System for the Data Steward to delegate the Proposed
review and remediation of rejected records.
BR-PRP-008 The Contractor shall configure and implement MDM System to monitor and manage pre-processing Proposed
issues until resolved through standard dashboard(s) and/or reports for the Data Stewards (or
delegates).
BR-PRP-009 The Contractor shall configure and implement MDM System to provide the Data Stewards (or Proposed
delegates) the ability to create custom dashboards and/or reports for pre-processing issues.
Offeror
Response
BR-DSC MDM Data Standardization, Cleansing and Enrichment

BR-DSC-001 The Contractor shall configure and implement MDM System to enforce consistent, industry Proposed
standard and re-usable set of Data Quality rules on records/fields loaded into Enterprise MDM

Status
BR-DSC-002 The Contractor shall configure and implement MDM System to standardize, cleanse and enrich all Proposed
Source system data (refer to the initial list of data in the Data Requirements document) loaded into
Enterprise MDM enforcing the to-be established Data Quality rules and standards.
BR-DSC-003 The Contractor shall configure and implement MDM System to maintain both the original source Proposed
system data (without any changes) and standardized/cleansed/enriched data in Enterprise MDM.
BR-DSC-004 The Contractor shall configure and implement MDM System to standardize the Source system Proposed
addresses to US Postal Standards or respective International Postal Standards. For example:
> Validation/Cleansing of address information shall preserve all salient data during manual and
systematic data cleansing (e.g., Apartment No., Lot No.)
> Zip+4 shall be added to each US Postal Address
> Each address shall be geo-located
BR-DSC-005 The Contractor shall configure and implement MDM System to standardize the Source system Proposed
phone numbers to the North American Numbering Plan (NANP) and other to be established
national/international standards.
BR-DSC-006 The Contractor shall configure and implement MDM System to enforce the Data Quality Rules (to Proposed
be defined) across all Enterprise MDM data entry points.
BR-DSC-007 The Contractor shall configure and implement MDM System with ability to enrich/enhance/improve Proposed
MDM data quality by loading and integrating external 3rd party vendor data into Enterprise MDM.
BR-DSC-008 The Contractor shall configure and implement MDM System to accept any inbound data that meets Proposed
the Enterprise MDM Data Quality rules.
BR-DSC-009 The Contractor shall configure and implement MDM System to reject any inbound data that does Proposed
not meet the Enterprise MDM Data Quality rules.
BR-DSC-010 The Contractor shall configure and implement MDM System to maintain a log of all the rejected Proposed
data in an accessible repository for the Data Steward (or delegate) to review.
BR-DSC-011 The Contractor shall configure and implement MDM System for the Data Steward to prioritize and Proposed
manage remediation of rejected data.
BR-DSC-012 The Contractor shall configure and implement MDM System to monitor and manage data quality Proposed
issues until resolved through standard dashboard(s) and/or reports for the Data Stewards (or
delegates).
BR-DSC-013 The Contractor shall configure and implement MDM System to provide the Data Stewards (or Proposed
delegates) the ability to create custom dashboards and/or reports for data quality issues.
Offeror
Response
BR-HUB MDM Repository - Enterprise MDM Hub

BR-HUB-001 The Contractor shall configure and implement MDM System to create and maintain a unique Proposed
Enterprise MDM Golden record with most accurate data (for e.g., Identification, Name, Address,
Demographics, Contact information, Relationships with other entities / providers, Interactions with
other entities / providers) for each “Individual” and “Business” entity from source systems.
BR-HUB-002 The Contractor shall configure and implement MDM System to maintain persistently, the Individual Proposed
or Business attributes respectively from one or more source records used to create or update the
Enterprise MDM Golden record.
BR-HUB-003 The Contractor shall configure and implement MDM System to generate a unique identifier Proposed
(Enterprise Individual ID for Individuals and Enterprise Business ID for Businesses) upon creation of
an Enterprise MDM Golden record.
BR-HUB-004 The Contractor shall configure and implement MDM System to maintain a registry of cross Proposed
reference identifiers of source system record(s) associated with the Enterprise MDM Golden record.
Offeror
Response
BR-RFD MDM Repository - Master Reference Data (e.g. look-up data)

Status
BR-RFD-001 The Contractor shall implement MDM System to maintain a persistent repository of Reference data Proposed
required to support Individual and Business Master Data domains.
BR-RFD-002 The Contractor shall implement MDM System to identify and verify the validity and accuracy of the Proposed
individual and business attributes. The aforesaid data attributes shall include date, time, system
info, how was it verified and user/system that verified it.
Offeror
Response
BR-DMG MDM Data Migration / Conversion – General

BR-DMG-001 The Contractor shall implement MDM System to have a consistent methodology/implementation to Proposed
perform bulk load of historical data (including complex transformations) from source systems into
Enterprise MDM for both the Individual and Business Master Data domains.
BR-DMG-002 The Contractor shall implement MDM System to have a consistent methodology/implementation to Proposed
manage scenarios where new Master Reference Data is identified during the Bulk Load process.
Offeror
Response
BR-DMI MDM Data Migration / Conversion - Individual

BR-DMI-001 The Contractor shall evaluate Individual (Client) Data from Ohio Benefits in the current MDM Proposed
system to design and implement migration/conversion changes interfacing with Enterprise MDM.
BR-DMI-002 The Contractor shall evaluate Individual Data from Master Client Index (MCI) in the current MDM Proposed
BR-DMI-003 The Contractor shall evaluate Individual (Recipient) Data from MMIS system to design and Proposed
implement migration/conversation changes (if necessary) into Enterprise MDM.
BR-DMI-004 The Contractor shall migrate Individual (Claimant) Data from OJI into Enterprise MDM. Proposed
BR-DMI-005 The Contractor shall migrate Individual (Seeker) Data from OWCMS into Enterprise MDM. Proposed
BR-DMI-006 The Contractor shall convert Individual Data from all named source systems into Enterprise MDM Proposed
conforming to Enterprise MDM requirements, data quality rules and standards.
Offeror
Response
BR-DMB MDM Data Migration / Conversion - Business

BR-DMB-001 The Contractor shall migrate Business (Provider, Payor) Data from MMIS into MDM. Proposed
BR-DMB-002 The Contractor shall migrate Business (Vendor, Customer) Data from OAKS into MDM. Proposed
BR-DMB-003 The Contractor shall evaluate Business Data from Master Provider Index (MPI) in the current MDM Proposed
BR-DMB-004 The Contractor shall migrate Business (Provider, Vendor) Data from IDM into MDM (Future scope). Proposed
BR-DMB-005 The Contractor shall migrate Business (Employer) Data from Ohio Business Gateway into MDM Proposed
(Future scope).
BR-DMB-006 The Contractor shall convert Business Data from all named source systems into MDM conforming Proposed
to MDM requirements, data quality rules and standards.
Offeror
Response

Status
BR-MTC MDM Matching (De-duplication)
BR-MTC-001 The Contractor shall implement MDM System with a reusable, multi-algorithm approach to Proposed
identifying candidate duplicate records (matching rules) for both the Individual and Business Master
Data Domains.
> Algorithms shall be designed so that they can be used unchanged for both batch and real-time
processes.
> Algorithms shall be designed to be used for specific purposes (e.g., only for batch or only real-
time processes).
> Algorithms shall become progressively less precise in terms of identifying candidate matches,
progressing from deterministic (i.e. 'exact') matching through to fully probabilistic (i.e. 'fuzzy')
matching.
> Algorithms shall cover any data issues with phonetic spellings or partial fields.
BR-MTC-002 The Contractor shall implement MDM System Matching algorithms to provide a matching score that Proposed
is indicative of the quality of the match identified.
BR-MTC-003 The Contractor shall implement MDM System for Data Stewards (or a delegate) to configure the Proposed
actions resulting from a range of match score(s), such as (a) definite (exact) matches (b) candidate
(potential) matches or (c) no match.
BR-MTC-004 The Contractor shall implement MDM System for Data Stewards to draft changes to data Matching Proposed
rules.
BR-MTC-005 The Contractor shall implement MDM System with ability to apply Matching algorithm changes with Proposed
flexible option to execute either in future or retroactively on existing (all or a subset of) records
around peak usage times and maintenance schedules.
BR-MTC-006 The Contractor shall implement MDM System to historically track when two or more records are Proposed
reviewed and rejected as candidate (potential) matches then omit these records from future
matching results.
BR-MTC-007 The Contractor shall implement MDM System to require a minimum number of attributes to assess Proposed
a match for Individual Master Data (e.g. First Name, Last Name, Date of Birth and Sex).
BR-MTC-008 The Contractor shall implement MDM System to require a minimum number of attributes to assess Proposed
a match for Business Master Data (e.g. Business Name and Business Address).
BR-MTC-009 The Contractor shall implement MDM System to trigger systematic matching based on establishing Proposed
matching algorithm after every record creation/addition, change/update, Merge, Unmerge (Split),
manual edit etc.
BR-MTC-010 The Contractor shall implement MDM System to track the matching algorithm used to match Proposed
records, so that any issues with matching can be quickly assessed and remediated.
BR-MTC-011 The Contractor shall implement MDM System to create a workflow task for the Data Steward (or Proposed
delegate) to review "candidate" (potential) matches.
BR-MTC-012 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or Proposed
delegate) to review "candidate" (potential) matches.
BR-MTC-013 The Contractor shall implement MDM System to process "no match" records as a singleton. Proposed
Offeror
Response
BR-MRG MDM Merge

BR-MRG-001 The Contractor shall implement MDM System for Data Stewards (or delegates) to configure Merge Proposed
rules to optimize the Golden record;
> Apply Trust rules based on the perceived Source System Data Quality (e.g., accuracy, currency,
completeness etc.)
> Trust rules shall be configurable for a single field, a group of fields or the entire record
BR-MRG-002 The Contractor shall implement MDM System to systematically Merge "definite" (exact) match Proposed
records in Enterprise MDM based on predefined Merge rules.
BR-MRG-003 The Contractor shall implement MDM System to create workflow tasks for Data Steward (or Proposed
delegate) to review records for Merge.

Status
BR-MRG-004 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or Proposed
delegate) to review Merge requests.
BR-MRG-005 The Contractor shall implement MDM System for Data Steward (or delegate) to review and Proposed
confirm/reject the need for Merging records.
BR-MRG-006 The Contractor shall implement MDM System for Data Steward (or delegate) to Merge records that Proposed
are manually identified as "definite" (exact) match records.
BR-MRG-007 The Contractor shall implement MDM System for Data Steward (or delegate) to manually initiate a Proposed
records Merge via Enterprise MDM UI.
BR-MRG-008 The Contractor shall implement MDM System with option to add a workflow task for a Data Steward Proposed
(or a delegate) to review the results of the systematic Merge process (e.g., Golden record review).
Offeror
Response
BR-UNM MDM Unmerge (Split)

BR-UNM-001 The Contractor shall implement MDM System for Data Stewards (or delegates) to configure Proposed
Unmerge (Split) rules to optimize the Golden record;
> Apply Trust rules based on the perceived Source System Data Quality (e.g., accuracy, currency,
completeness etc.)
> Trust rules shall be configurable for a single field, a group of fields or the entire record
BR-UNM-002 The Contractor shall implement MDM System to create workflow task(s) for Data Steward (or Proposed
delegate) to review Unmerge (Split) request(s) of previously Merged record(s).
BR-UNM-003 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or Proposed
delegate) to review Unmerge (Split) requests.
BR-UNM-004 The Contractor shall implement MDM System for Data Steward (or delegate) to review and Proposed
confirm/reject the need for Unmerging (Splitting) previously Merged records.
BR-UNM-005 The Contractor shall implement MDM System to systematically Unmerge (Split) records that are Proposed
identified as incorrect Merges, to the original individual record state.
BR-UNM-006 The Contractor shall implement MDM System to systematically apply all manual edits specific to Proposed
each Unmerged (Split) record that were previously applied to the Merged record.
BR-UNM-007 The Contractor shall implement MDM System for Data Steward (or delegate) to Unmerge (Split) Proposed
records that are manually identified as incorrect Merges, to the original individual record state.
BR-UNM-008 The Contractor shall implement MDM System for Data Steward (or delegate) to manually re-apply Proposed
all manual edits specific to each Unmerged (Split) record that were previously applied to the Merged
record.
BR-UNM-009 The Contractor shall implement MDM System for Data Steward (or delegate) to manually initiate an Proposed
Unmerge (Split) a record via Enterprise MDM UI.
BR-UNM-010 The Contractor shall implement MDM System to systematically reapply Merge rules to determine a Proposed
new set of Golden record values for each new composite.
BR-UNM-011 The Contractor shall implement MDM System with option to add a workflow task for a Data Steward Proposed
(or a delegate) to review the results of the systematic Unmerge (Split) process (e.g., Golden record
review).
BR-UNM-012 The Contractor shall implement MDM System to systematically update the corresponding System Proposed
Identifier cross references registry.
BR-UNM-013 The Contractor shall implement MDM System to historically track Unmerge (Split) and exclude the Proposed
Unmerged records from future match results.
BR-UNM-014 The Contractor shall implement MDM System to make all the Unmerged records available to any Proposed
Enterprise MDM downstream consuming system(s).

Status
Offeror
Response
BR-STW MDM Stewardship

BR-STW-001 The Contractor shall implement MDM System to create workflow task(s) for Data Steward (or Proposed
delegate) to review Enterprise MDM record(s) change request(s).
BR-STW-002 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or Proposed
delegate) to review Enterprise MDM record(s) change requests.
BR-STW-003 The Contractor shall implement MDM System to provide Data stewards with the capability to Proposed
remediate data quality issues (e.g., duplicates, incorrect Merges, missing fields, etc.).
monitor to-do/task lists, their status (based on Key Performance Indicators (KPIs)) and
management tools to delegate and transfer task assignments to ensure effective action(s).
BR-STW-005 The Contractor shall implement MDM System to enable Data Steward to assign priorities and Proposed
service level agreements (SLA) on task(s) and delegate resolution to team resources, and provide
direction via comments or notes applied to the task.
escalate issues and tasks (e.g., Situations like "Out of Office", need decision/resolution on an
issue).
BR-STW-007 The Contractor shall implement MDM System to provide Data Stewards to display all open tasks, Proposed
such as Match-Merge, Split, data quality checks, data stewardship audit and performance etc. with
dashboard(s) and/or reports.
BR-STW-008 The Contractor shall implement MDM System with the ability for Data Steward to track progress on Proposed
assigned tasks (e.g., workflow throughput per user).
BR-STW-009 The Contractor shall implement MDM System with the ability for Data Steward to audit and report Proposed
on the usage of Enterprise MDM data.
BR-STW-010 The Contractor shall implement MDM System with the ability for Data Steward to review data quality Proposed
metrics including duplicate analysis (e.g., match results and approvals), address validation,
percentage of matches by match algorithm, etc.
BR-STW-011 The Contractor shall implement MDM System with the ability for Data Steward to review all changes Proposed
made (e.g., data quality, manual authoring, survivorship, etc.) to a record within the Enterprise
MDM.
BR-STW-012 The Contractor shall implement MDM System with the ability for Data Steward to view relevant non- Proposed
master data within one or more source/target systems, which would enable remediation activities to
occur in order to successfully complete the Merge/Split/update of master data records.
Offeror
Response
BR-SRC MDM Search Capabilities

BR-SRC-001 The Contractor shall implement MDM System to provide search capability to assist users based on Proposed
their access privileges in searching and finding the record(s) they are interested in.
BR-SRC-002 The Contractor shall implement MDM Search capability to perform deterministic search, Proposed
probabilistic (fuzzy) search, phonetic (e.g., Soundex) search, value ranges (e.g., dates, ages, zip
codes, etc.) search, partial field search and searches based on common nicknames (e.g., Peggy for
Margaret), common abbreviations and transposed characters and fields, etc.
BR-SRC-003 The Contractor shall implement MDM Search capability to enable users to search different types of Proposed
records in Enterprise MDM (e.g., Individual, Business, Task, Golden record, Source system specific
record etc.).
BR-SRC-004 The Contractor shall implement MDM Search capability to enable user to perform single or multi- Proposed
parameter searches.
BR-SRC-005 The Contractor shall implement MDM Search capability to provide a score representing the degree Proposed
of accuracy of the search results.
Status
BR-SRC-006 The Contractor shall implement MDM Search capability to keep a historical search log (who Proposed
performed the search, what data was provided back, when was it searched, what search
parameters led to the display of the search etc.).
BR-SRC-007 The Contractor shall implement MDM Search capability with the ability to change one or more Proposed
search criteria and resubmit the search request.
BR-SRC-008 The Contractor shall implement MDM Search capability to return only basic information and upon Proposed
further request provide detailed information.
BR-SRC-009 The Contractor shall implement MDM Search capability to provide display options (e.g., Number of Proposed
records per page etc.) to display the search results in one or more pages with page level navigation
capabilities.
BR-SRC-010 The Contractor shall implement MDM Search capability to provide option to limit the number of Proposed
records returned after sorting and filtering criteria are applied, as part of the search result.
BR-SRC-011 The Contractor shall implement MDM Search capability with the ability to sort search results based Proposed
on one or more fields.
BR-SRC-012 The Contractor shall implement MDM Search capability with the ability to filter search results based Proposed
on one or more criteria provided by the user.
BR-SRC-013 The Contractor shall implement MDM Search capability with options to select one or more records Proposed
for further action (e.g., Create, Update, Delete, Merge, Split/Unmerge etc.).
BR-SRC-014 The Contractor shall implement MDM Search capability with options to export (for e.g., Excel, CSV, Proposed
PDF etc.), download, print the search results, etc.
Offeror
Response
BR-SEC MDM Role based security (Visibility rules)

BR-SEC-001 The Contractor shall implement MDM System with the ability to add, delete, change and view local Proposed
accounts within Enterprise MDM applications where applicable.
BR-SEC-002 The Contractor shall implement MDM System to provide role based security at record level, Proposed
column/field level, source system level, business domain level, record type, etc.
BR-SEC-003 The Contractor shall implement MDM System to provide role based security and access to the Proposed
hierarchy of Data Stewards to login, search/view, create/add, update, delete etc. on source system
records and Enterprise MDM Golden records.
BR-SEC-004 The Contractor shall implement MDM System to provide role based security and access to the Proposed
hierarchy of Data Stewards to login, search/view, create/add, update, delete, delegate, assign,
prioritize, transfer, monitor, etc. on Enterprise MDM tasks.
BR-SEC-005 The Contractor shall implement MDM System with capability to send warning and/or error Proposed
messages upon security violations.
BR-SEC-006 The Contractor shall implement MDM System with capability to assign the role based security Proposed
permissions for specific users, groups, etc.
BR-SEC-007 The Contractor shall implement MDM System with capability to assign the role based security Proposed
permissions individually or mass update via batch process.
BR-SEC-008 The Contractor shall implement MDM System with capability to display and filter specific records, Proposed
fields etc. based on role permissions.
BR-SEC-009 The Contractor shall implement MDM System with capability to optionally mask data for display Proposed
based on field level (one or more fields) security requirements.
BR-SEC-010 The Contractor shall implement MDM System for Data Steward (or delegate) to track and report on Proposed
new/current Enterprise MDM accesses granted to users, roles, applications/solutions via Enterprise
MDM UI.
BR-SEC-011 The Contractor shall implement MDM System to support “break-the-glass” or override access to the Proposed
Enterprise MDM applications and data for State authorized users.

Status
Offeror
Response
BR-CAU MDM Data Authoring using MDM UI (Create, Read, Update, Delete)
BR-CAU-001 The Contractor shall implement MDM System for a Data Steward (or delegate) with the ability to Proposed
manually Create, Update, Delete and View Individual and Business data via the Enterprise MDM UI.
manually Create, Update, Delete and View mass quantities of Individual and Business data records
via the Enterprise MDM UI.
perform mass updates on specific attributes across multiple records with the same data value(s) via
the Enterprise MDM UI.
manually Create, Update, Delete and View mass quantities of Individual and Business data records
by importing data from a defined data source (e.g., flat file, database table, etc.).
perform mass updates on specific attributes across multiple records with the same data value(s) by
importing data from a defined data source (e.g., flat file, database table, etc.).
BR-CAU-006 The Contractor shall implement MDM System to maintain a separate Individual or Business source Proposed
record(s) that are created manually by the Data Steward (or delegate) directly in the Enterprise
MDM system (with source as MDM Data Steward) that are used to create the Enterprise MDM
Golden record.
Offeror
Response
BR-NMI MDM Data Authoring using non-MDM UI (Create, Read, Update, Delete) - Individual
BR-NMI-001 The Contractor shall design and implement the appropriate MDM implementation style (i.e. registry, Proposed
consolidation, co-existence, transaction) to interface the Ohio Benefits systems with the Enterprise
MDM System for Individual (Client) Data.
consolidation, co-existence, transaction) to interface the MMIS system with the Enterprise MDM
system for Individual (Recipient) Data.
consolidation, co-existence, transaction) to interface the OJI system with the Enterprise MDM
system for Individual (Claimant) Data.
consolidation, co-existence, transaction) to interface the OWCMS system with the Enterprise MDM
system for Individual (Seeker) Data.
BR-NMI-005 The Contractor shall populate the MDM System with the above systems Individual Data into Proposed
Enterprise MDM in real time / near real time and/or on a scheduled and periodic basis.
BR-NMI-006 The Contractor shall populate the MDM System with the above systems Individual Data singularly Proposed
or as a mass data migration via batch processing.
BR-NMI-007 The Contractor shall implement MDM System to maintain each Individual source system record Proposed
separately that are used to create the Enterprise MDM Golden record.
BR-NMI-008 The Contractor shall implement MDM System to restrict systematic changes to business defined Proposed
immutable attributes (e.g., SSN, TIN etc.) for Individual data.
BR-NMI-009 The Contractor shall implement MDM System to generate electronic error notifications/alerts in case Proposed
of systematic updates to restricted immutable information for Individual data.

Status
BR-NMI-010 The Contractor shall implement MDM System to generate electronic warning notifications/alerts in Proposed
case of systematic updates to permissible immutable information for Individual data.
Offeror
Response
BR-NMB MDM Data Authoring using non-MDM UI (Create, Read, Update, Delete) - Business
BR-NMB-001 The Contractor shall design and implement the appropriate MDM implementation style (i.e. registry, Proposed
consolidation, co-existence, transaction) to interface the MMIS system with the Enterprise MDM
system for Business (Provider, Payor) Data.
BR-NMB-002 The Contractor design and implement the appropriate MDM implementation style (i.e., registry, Proposed
consolidation, co-existence, transaction) to interface the OAKS system with the Enterprise MDM
system for Business (Vendor, Customer) Data.
BR-NMB-003 The Contractor shall design and implement the appropriate MDM implementation style (i.e., registry, Future
consolidation, co-existence, transaction) to interface the Ohio Business Gateway system with the
Enterprise MDM system for Business (Employer) Data (Future scope).
BR-NMB-004 The Contractor shall design and implement the appropriate MDM implementation style (i.e., registry, Future
consolidation, co-existence, transaction) to interface the IDM system with the Enterprise MDM
system for Business (Provider, Vendor) Data (Future scope).
BR-NMB-005 The Contractor shall populate the MDM System with the above systems Business Data in real time / Proposed
near real time and/or on a scheduled and periodic basis.
BR-NMB-006 The Contractor shall populate the MDM System with the above systems Business Data singularly or Proposed
as a mass data migration via batch processing.
BR-NMB-007 The Contractor shall implement MDM System to maintain each Business source system record Proposed
separately that are used to create the Enterprise MDM Golden record.
BR-NMB-008 The Contractor shall implement MDM System to restrict systematic changes to business defined Proposed
immutable attributes (e.g., TIN, Business Type etc.) for Business data.
BR-NMB-009 The Contractor shall implement MDM System to generate electronic error notifications/alerts in case Proposed
of systematic updates to restricted immutable information for Business data.
BR-NMB-010 The Contractor shall implement MDM System to generate electronic warning notifications/alerts in Proposed
case of systematic updates to permissible immutable information for Business data.
Offeror
Response
BR-RDA MDM Master Reference Data Authoring (Create, Read, Update, Delete)
BR-RDA-001 The Contractor shall implement MDM System for a Data Steward (or delegate) to Create, Update, Proposed
View and Delete Master Reference Data via Enterprise MDM User Interface (UI).
BR-RDA-002 The Contractor shall implement MDM System for a Data Steward to monitor requests (create, Proposed
update, delete), review and approval of Master Reference Data changes via Enterprise MDM UI.
BR-RDA-003 The Contractor shall implement MDM System to store active, historical and pending Master Proposed
Reference Data.
BR-RDA-004 The Contractor shall implement MDM System to allow only active Master Reference Data to be Proposed
assigned to Master Data records.
BR-RDA-005 The Contractor shall implement MDM System for historical Master Reference Data to maintain links Proposed
with historical (e.g., deactivated) Master Data Records.
BR-RDA-006 The Contractor shall configure and implement MDM System to maintain a registry of system Proposed
identifiers for Source and Target systems associated with the Enterprise MDM Golden record(s).

Status
BR-RDA-007 The Contractor shall implement MDM System with the ability to upload file based Master Reference Proposed
Data changes for the following scenarios at a minimum:
> full re-load
> partial update
> new records only
> deletions only, etc.
BR-RDA-008 The Contractor shall implement MDM System to prevent Master Reference Data from being Proposed
deactivated/deleted when it is associated with one or more active Master Data record(s).
BR-RDA-009 The Contractor shall implement MDM System with the ability to accept and manage new Reference Proposed
Data values identified during batch conversion processes.
BR-RDA-010 The Contractor shall implement MDM System with the ability to accept and manage duplicate Proposed
Reference Data values with differences from various source systems.
Offeror
Response
BR-SYC MDM Data Synchronization/Harmonization (Notifications/Alerts)

BR-SYC-001 The Contractor shall implement MDM System to support batch, real-time and near real-time Proposed
distribution of data, which will encompass applications that pull or have data pushed to them due to
occurrence of Enterprise MDM changes (e.g. Merge, Unmerge, Authoring updates, etc.)
BR-SYC-002 The Contractor shall implement MDM System to send electronic notification(s) to a queue for all the Proposed
source/target/downstream systems to consume (Pull or Push) for each of the following scenarios
including (but not limited to):
> Creation/Addition of a new Individual or Business Golden record in Enterprise MDM
> Update/Change to an Individual or Business Golden record in Enterprise MDM
> Merge of Individual or Business Golden record in Enterprise MDM
> Unmerge (Split) of Individual or Business Golden record in Enterprise MDM
> Deletion/Deactivation of Individual or Business Golden record in Enterprise MDM
BR-SYC-003 The Contractor shall implement MDM System to send electronic notification(s) to a queue only for Proposed
specific source/target/downstream systems to consume for each of the following scenarios including
(but not limited to):
> Creation/Addition of a new Individual or Business source record in Enterprise MDM from specific
source system
> Update/Change to an Individual or Business source record in Enterprise MDM from specific
source system
> Merge of Individual or Business source record in Enterprise MDM from specific source system
> Unmerge (Split) of Individual or Business source record in Enterprise MDM from specific source
system
> Deletion/Deactivation of Individual or Business source record in Enterprise MDM from specific
source system
BR-SYC-004 The Contractor shall implement MDM System to send electronic notifications to a queue in a "fire Proposed
and forget" manner i.e. no follow up action is required for unconsumed messages.
BR-SYC-005 The Contractor shall implement MDM System electronic notification(s) to include following Proposed
information (but not limited to):
> Enterprise MDM generated unique identifier (Enterprise Individual ID for Individuals and
Enterprise Business ID for Businesses)
> Source system unique identifier, if the notification is for a specific system
> Individual or Business data that was added/changed/deleted/deactivated/merged/unmerged (split)
BR-SYC-006 The Contractor shall implement MDM System to send electronic notifications in (near) real time and Proposed
scheduled batch.
BR-SYC-007 The Contractor shall implement MDM System to maintain the electronic notifications in the queue Proposed
for a business specified period of time.
Offeror
Response

Status
BR-ANL MDM Analytics

BR-ANL-001 The Contractor shall implement MDM System to provide a Data Quality Dashboard for Data Proposed
Steward to proactively monitor Enterprise MDM data quality.
BR-ANL-002 The Contractor shall provide the following details in the Data Quality Dashboard including (but not Proposed
limited to):
> Total matched records in each Data Domain
> Total count of source system records and unique Golden records in Enterprise MDM for each
Data Domain
> Total records approved in 1 day, 1 week, 1 month, 1 quarter
> List of all new Master Reference Data codes added during a configurable period of time, and their
source (manual or systematic record creations through batch processing)
BR-ANL-003 The Contractor shall provide the following details for the monitoring purpose in the Data Quality Proposed
Dashboard including (but not limited to):
> Track progress on corrective actions individually, by resource and overall for the domain
> Data Quality Metrics
> Data Freshness
> Data Volumes
> Throughput Volumes
> Display which rules are used by Enterprise MDM by frequency and preference and to provide
suggested enhancements to such business rules
> Analytics and performance measures related to a range of processes and activities taking place
within Enterprise MDM, from the running of batch data loads to the execution of workflows against
benchmarks to the data quality of active client data in the Enterprise MDM. This metadata includes
information such as scoring on matches, number of records compared, etc.
BR-ANL-004 The Contractor shall implement MDM System to provide a System Performance Dashboard for Proposed
Data Steward to proactively monitor MDM system. Dashboard will provide key performance details
including (but not limited to):
> Enterprise MDM system performance
> Enterprise MDM process performance
> Enterprise MDM component (Cleansing, Standardization, Matching, Merging, Unmerging
(Splitting), Search etc.) execution performance, etc.
Offeror
Response
BR-GDD MDM Business Glossary / Data Dictionary / Metadata

BR-GDD-001 The Contractor shall configure and implement Informatica Business Glossary to document agency Proposed
and system specific terms, definitions, standards for each Critical Data Elements in the Enterprise
MDM Data Domains.
BR-GDD-002 The Contractor shall configure and implement Informatica Business Glossary to enable workflow to Proposed
harmonize terms and definitions across all agencies and systems to establish an enterprise set of
terms, definitions and standards, which will be the basis for the Enterprise MDM solution.
BR-GDD-003 The Contractor shall implement Informatica Metadata Manager to maintain the Informatica Business Proposed
Glossary by regularly updating the business glossary changes to provide complete consistency and
transparency of business terms and definitions across the enterprise.
BR-GDD-004 The Contractor shall configure and implement Informatica Metadata Manager to collect and store Proposed
data lineage from the source systems through Enterprise MDM to target systems as well as define a
process to manage the data on an ongoing basis.
BR-GDD-005 The Contractor shall populate and maintain the data lineage from the source systems through Proposed
Enterprise MDM to target systems in Informatica Metadata Manager, on an ongoing basis.
Offeror
Response

Status
BR-AUD MDM Data / Historical Auditing
BR-AUD-001 The Contractor shall implement MDM process to maintain all business rules (cleansing, matching, Proposed
merging, etc.), and how the rules have been applied within Enterprise MDM with sufficient visibility
to satisfy a timely audit review process.
BR-AUD-002 The Contractor shall implement MDM System for Data Steward (or delegate) with on-demand Proposed
access to all the functional logs (e.g., Security change log, Data Steward change log, Reference
data change log, etc.) for follow-up action through Enterprise MDM UI.
BR-AUD-003 The Contractor shall implement MDM System and processes to maintain a history of all data Proposed
changes (Add, Update, Delete, Unmerge (Split), Merge etc.) in a change log with the following
sample details:
> The before and after view of the data change
> System ID/User ID of the system/user that made the change
> How the change was made (batch, online, UI, data services, direct access, etc.)
> Date and Time of the change
Some example data changes are attribute level changes, record level changes, reference data
changes, to-do/task changes, role based security changes, Informatica Business Glossary, Data
Dictionary and Metadata changes.
BR-AUD-004 For financial, operational, compliance and legal reasons, the Contractor shall implement MDM Proposed
System and processes to capture and maintain a history of all system/user Enterprise MDM
activities in an activity log with the following sample details:
> System ID/User ID of the system/user that interacted with Enterprise MDM
> What the system/user interacted for (with criteria used for interaction)
> How the interaction was made (batch, online, UI, data services, direct access, etc.)
> Date and Time of the activity, etc.
Some example activities are data profiling, data search and view.
BR-AUD-005 The Contractor shall implement MDM System and processes to query, search and report based on Proposed
criteria like date ranges, user groups, users, system(s), etc. on the historical change and activity
logs respectively to identify and monitor any abnormal usage patterns.
BR-AUD-006 The Contractor shall implement MDM System and processes to maintain the historical change and Proposed
activity logs for a State specified period of time.
BR-AUD-007 The Contractor shall implement MDM System and processes to export change and activity logs into Proposed
text format in such a manner as to allow correlation based on time (e.g., Coordinated Universal
Time [UTC] synchronization). The Solution shall have the ability to format recorded time stamps
using UTC based upon ISO 8601.
BR-AUD-008 The Contractor shall implement MDM System to grant read access to the change and activity logs Proposed
to only those authorized users with explicit read access privilege.
BR-AUD-009 The Contractor shall implement MDM System and processes to protect the stored change and Proposed
activity logs from unauthorized modifications and deletions.
BR-AUD-010 The Contractor shall implement MDM System and processes to provide the ability for an authorized Proposed
administrator to set the inclusion or exclusion of auditable events based on organizational policy &
operating requirements/limits.

3.6 Data Requirements: “Individual” Domain
Note: For section 3.6, Offerors can address the Data Element Requirements at the end of this section. Offerors do not have to address each Data Element Requirement
individually.
Data Element Name Description Status Business Data Type
Field is Candidate
Reference Data
Source System
Multiple Values
Data REQ ID
Permissible
Candidate
for use in
Matching
DE-I1 Enterprise Individual ID The key assigned via the Enterprise MDM solution, Proposed
representing a unique Individual
DE-I2 Prefix The prefix of the Individual Proposed Character (String) Yes Yes
DE-I3 First Name The first name of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes
OJI, OWCMS
DE-I4 Middle Name The middle name of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits,
OJI, OWCMS
DE-I5 Last Name The last name of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes
OJI, OWCMS
DE-I6 Previous Last Name / The previous last name of the Individual due to Proposed Character (String) OJI, Ohio Benefits Yes Yes
Maiden Name marriage, adoption, etc.
DE-I7 Suffix The suffix of the Individual Proposed Character (String) Ohio Benefits Yes Yes Yes
DE-I8 Sex / Gender The sex/gender of the Individual Proposed Character (String) OJI, OWCMS Yes Yes
DE-I9 Date of Birth The date of birth of the Individual Proposed Date MCI, MMIS, Ohio Benefits, Yes
OJI, OWCMS
DE-I10 Deceased Indicator Indicator tells whether the Individual is deceased or not Proposed True/False OJI
DE-I11 Date of Death The date of death of the Individual Proposed Date MMIS
DE-I12 Marital Status Indicates tells whether the Individual is married, Proposed Character (String) MMIS Yes
divorced, etc.
DE-I13 Phone Number The phone number of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes Yes
OJI, OWCMS
DE-I14 Phone Number The phone number extension of the Individual Proposed Character (String) OJI, OWCMS Yes
extension
DE-I15 Phone Number Type The type of phone number (e.g., work, personal, etc.) Proposed Character (String) OJI, Ohio Benefits Yes Yes
provided by the Individual
DE-I16 Address Type The type of address provided by the Individual Proposed Character (String) MCI, Ohio Benefits, OJI Yes
DE-I17 Address Line 1 The first line of the address provided by the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes Yes
OJI, OWCMS

Field is Candidate
Reference Data
Source System
Multiple Values
Data REQ ID
Permissible
Candidate
for use in
Matching
DE-I18 Address Line 2 The second line of the address provided by the Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes Yes
Individual OJI, OWCMS
DE-I19 Address Line 3 The third line of the address provided by the Individual Proposed Character (String) MCI, MMIS Yes Yes
DE-I20 City The city corresponding to the Individual's address Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes Yes Yes
OJI, OWCMS
DE-I21 County The county corresponding to the Individual's address Proposed Character (String) OJI, OWCMS Yes Yes
DE-I22 State / Region The State corresponding to the Individual’s address Proposed Character (String) OJI, OWCMS Yes Yes Yes
DE-I23 Zip The Zip code corresponding to the Individual's address Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes Yes
OJI, OWCMS
DE-I24 Zip4 The Zip plus 4 corresponding to the Individual's Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes Yes
address OJI, OWCMS
DE-I25 Country The country corresponding to the Individual’s address Proposed Character (String) OJI Yes Yes
DE-I26 Valid Address Flag Indicator of whether the address is valid Proposed True/False MCI, Ohio Benefits, Yes
OWCMS
DE-I27 Longitude Geographical Longitude of the Individual's address Proposed Decimal MCI, MMIS, Ohio Benefits Yes
DE-I28 Latitude Geographical Latitude of the Individuals' address Proposed Decimal MCI, MMIS, Ohio Benefits Yes
DE-I29 Email Address The email address of the Individual Proposed Character (String) OJI, OWCMS Yes Yes
DE-I30 Email Type The type (e.g., work, personal) of email provided by the Proposed Character (String) OJI Yes Yes
Individual
DE-I31 Birth City The city corresponding to where the Individual was Proposed Character (String) Ohio Benefits Yes
born
DE-I32 Birth County The county corresponding to where the Individual was Proposed Character (String) Ohio Benefits Yes
born
DE-I33 Birth State/Region The State corresponding to where the Individual was Proposed Character (String) Ohio Benefits Yes
born
DE-I34 Birth Country The country corresponding to where the Individual was Proposed Character (String) OJI Yes
born
DE-I35 US Citizenship Status Indicator for US citizenship of the Individual Proposed Character (String) MMIS, OJI, OWCMS, Ohio Yes
Benefits
DE-I36 Citizenship The name/type of document provided by the Individual Proposed Character (String) OWCMS Yes
Documentation Type to verify Citizenship Status
DE-I37 Social Security Number The social security number of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes
OJI, OWCMS

Field is Candidate
Reference Data
Source System
Multiple Values
Data REQ ID
Permissible
Candidate
for use in
Matching
DE-I38 ID Type The type of identification provided by the Individual Proposed Character (String) OJI Yes Yes
(e.g., Driver’s License)
DE-I39 ID Number The number corresponding to the ID Type provided Proposed Character (String) OJI Yes
(e.g., the Driver’s license #)
DE-I40 ID Issued State The State from which the ID was issued Proposed Character (String) OJI, OWCMS Yes Yes
DE-I41 ID Issue Date The date the ID was issues Proposed Date
DE-I42 ID Expiration Date The date the ID will expire Proposed Date
DE-I43 Race The race(s) of the Individual Proposed Character (String) OJI, OWCMS Yes Yes
DE-I44 Ethnicity The ethnicity(ies) of the Individual Proposed Character (String) OJI, OWCMS Yes Yes
DE-I45 Relation The relationship link between this Individual and Proposed Character (String) OJI Yes
another Individual
DE-I46 Relationship Type The type of relationship between two Individuals (e.g., Proposed Character (String) OJI Yes Yes
parent, sibling, etc.).
DE-I47 Immigration Document The type of document provided to support immigration Proposed Character (String) Yes
Type status
DE-I48 Immigration Document The number corresponding to the immigration Proposed Character (String)
Number document provided
DE-I49 Immigration Date of The date the Individual entered the country based on Proposed Date
Entry immigration documentation provided
DE-I50 Immigration Document The date that the immigration document expires Proposed Date OJI, OWCMS
Expiration Date
DE-I51 Immigration Status The immigration status of the person Proposed Character (String) Yes
DE-I52 Country of Citizenship The country corresponding to where the individual has Proposed Character (String) OWCMS Yes
citizenship
DE-I53 Residency Status Self-verification by individual that they are a resident of Proposed True/False
Ohio, regardless of their mailing or physical address
DE-I54 Veteran Status Is this individual a veteran? Proposed Character (String) OJI, OWCMS Yes
DE-I55 Enlistment Date The date corresponding to when the individual entered Proposed Date OWCMS
military service
DE-I56 Discharge Date The date corresponding to when the individual left Proposed Date OWCMS
military service
DE-I57 Branch of Service The branch of the military the individual served in. Proposed Character (String) OWCMS Yes
DE-I58 Discharge Type The type of military discharge by which the individual Proposed Character (String) Yes
left the armed services
Field is Candidate
Reference Data
Source System
Multiple Values
Data REQ ID
Permissible
Candidate
for use in
Matching
DE-I59 System Name The name of the system where the individual has one Proposed Character (String) MCI, Ohio Benefits, OJI, Yes Yes
or more records OWCMS
DE-I60 System ID The unique Identifier used to track the individual within Proposed Character (String) MCI, MMIS, Ohio Benefits, Yes
a particular system OJI, OWCMS
Offeror
Response

3.7 Data Element Requirements: “Business” Domain
Note: For section 3.7, Offerors can address the Data Element Requirements at the end of this section. Offerors do not have to address each Data Element Requirement
individually.
Field is Candidate
Reference Data
Source System
Multiple Values
Data REQ ID
Permissible
Candidate
for use in
Matching
DE-B1 Enterprise Business ID The key assigned via the Enterprise MDM solution, Proposed
representing a unique Business
DE-B2 Business Name Type Indicator for the type of name: legal, corporate, Proposed Character (String) MPI, MMIS, OBG, OAKS Yes Yes Yes
DBA, etc.
DE-B3 Business Name The name associated with “Business Name Type” Proposed Character (String) MPI, MMIS, OBG, OAKS Yes Yes
for the Business
DE-B4 Ownership Type The ownership structure of the business: Corp, Proposed Character (String) MMIS Yes Yes
LLC, sole proprietor, etc.
DE-B5 Address Type The type of address provided by the Business Proposed Character (String) OBG Yes Yes Yes
DE-B6 Address Line 1 The first line of the address provided by the Proposed Character (String) MPI, MMIS, OBG Yes Yes
Business
DE-B7 Address Line 2 The second line of the address provided by the Proposed Character (String) MPI, MMIS, OBG Yes Yes
Business
DE-B8 City The city corresponding to the Business's address Proposed Character (String) MPI, MMIS, OBG Yes Yes
DE-B9 County The county corresponding to the Business’s Proposed Character (String) OBG Yes Yes
address
DE-B10 State The State corresponding to the business's address Proposed Character (String) MPI, MMIS, OBG Yes Yes
DE-B11 Zip Code The zip code corresponding to the Business's Proposed Character (String) MPI, MMIS, OBG Yes Yes
address
DE-B12 Zip Code +4 The Zip+4 corresponding to the Business's address Proposed Character (String) MMIS Yes Yes
DE-B13 Phone Number The phone number of the Business Proposed Character (String) MCI, MMIS Yes Yes
DE-B14 Phone Number Extension The phone number extension of the Business Proposed Character (String) MCI, MMIS Yes
DE-B15 Phone Number Type The type of phone number (e.g., direct, fax, support, Proposed Character (String) Yes Yes Yes
etc.) provided by the Business
DE-B16 External Identifier Type The type of external identifier associated with the Proposed Character (String) MPI, MIT, Yes
business (e.g., National Provider ID – NPI, DUNS
Number, etc.)

Field is Candidate
Reference Data
Source System
Multiple Values
Data REQ ID
Permissible
Candidate
for use in
Matching
DE-B17 External Identifier The identifier provided to the Business by an Proposed Character (String) MPI, MMIS, OBG Yes
Industry, State, Federal or other external
organization.
DE-B18 Tax Identifier Type The type of registered tax identification number Proposed Character (String) Yes Yes
provided by the Business based on its ownership
type (e.g., EIN, SSN)
DE-B19 Tax Identifier The tax identifier used by the Business to file taxes Proposed Character (String) MMIS, OBG Yes
DE-B20 Parent The Enterprise Business ID representing the Proposed Character (String)
business that is the immediate parent within the
business’s organizational hierarchy
DE-B21 Ultimate Parent The Enterprise Business ID representing the Proposed Character (String)
highest level within the business’s organizational
hierarchy
DE-B22 System Name The name of the system where the Business has Proposed Character (String) MPI, MMIS, OBG, OAKS Yes Yes
one or more records
DE-B23 System ID The unique Identifier (System Assigned Key - SAK) Proposed Character (String) MPI, MMIS, OBG, OAKS Yes
used to track the Business within a system
Offeror
Response

3.8 Non-Functional Requirements
Note: For section 3.8, Offerors can address the Non-Functional Requirements at the end of each
Non-Functional Requirement category. Offerors do not have to address each Non-Functional
Requirement individually.
Non-
REQ ID Non-Functional Description by Category Functional
Requirement
Status
NFR- AUD Audit and Compliance
NFR-AUD-001 The solution shall comply with Ohio's Ohio Revised Code (ORC) Access logging rules for confidential Proposed
information
NFR-AUD-002 The solution shall comply with applicable Federal and State of Ohio’s Audit and Compliance requirements Proposed
(Please refer to Supplement 2 – Section 5 and 7)
NFR-AUD-003 The Solution shall be able to detect security-relevant events that it mediates and generate audit records for Proposed
them. At a minimum the events shall include those listed here:
- start/stop
- user login/logout
- session timeout
- account lockout
- scheduling
- node-authentication failure
- signature created/validated
- Personally Identifiable Information (PII) export
- PII import
- security administration events
- backup and restore
NFR-AUD-004 The Solution shall audit all access to protected information in real time Proposed
NFR-AUD-005 The Solution shall provide alert mechanism for privacy breaches Proposed
NFR-AUD-006 When “Break-the-Glass” or an override access is performed, the Solution shall maintain a complete and Proposed
consistent audit trail of the individual who performed the override and the change made (before and after
action/state of the record).
Offeror
Response
NFR- BPM Business Process Modeling (BPM)
NFR-BPM-001 The Solution shall balance application workflow workload (assigned tasks) based upon user and work unit Proposed
queues.
Offeror
Response
NFR-CM Consent Management
NFR-CM-001 The Solution shall track acceptance of informed consent or privacy policies where the Individual or Business Proposed
authorizes the terms and conditions contained in the informed consent and privacy policies. Informed
consent may include consent for sharing of personal and program transaction based activities with other
Individuals, such as a designated legal representative, or a third-party.
Offeror
Response

Non-
Requirement
Status
NFR- DI Data Integration
NFR-DI-001 The Solution shall provide tooling for data source connectivity: Adapters for a range of source types beyond Proposed
Relational Database Management Solutions (RDBMS's) and legacy databases (access to data stored in
non-relational structures - for example, VSAM files and IMS databases), including packaged applications and
Web services, the ability to access semi-structured and unstructured data (such as e-mail, websites, office
productivity tools, content repositories and rich media)and the ability to interpret (as a source) XML
structures.
NFR-DI-002 The Solution shall provide the ability to load data in a variety of approaches including (but not limited to) the Proposed
following:
- Bulk data extraction and loading
- SOA Web Services via near real time integration
- Granular trickle-feed acquisition and delivery
- Changed-data capture (ability to identify and extract modified data)
- Event-based acquisition (time-based or data-value-based)
Offeror
Response
NFR- IDM Identity Management
NFR-IDM-001 The solution shall leverage the Identity Management solution of the State and State provided User ID’s to Proposed
support single sign-on capability for all users.
NFR-IDM-002 The Solution shall re-authenticate the user before any access to Protected Health Information (PHI) or Proposed
Personally Identifiable Information (PII) or other sensitive or confidential information is allowed, including
when not connected to a network (e.g., on unconnected mobile devices).
NFR-IDM-003 Identity management for State and non-State users and systems will be provided by the OIT Identity Proposed
Management solution. The Solution is required to integrate to the States provided solution which supports
industry LDAP standards. (Please refer to Supplement section 7.0 Security Review Services)
NFR-IDM-004 The Enterprise MDM solution set of capabilities must be able to provide, at minimum, the Proposed
following implemented Security Management Services:
*Users' access rights shall be based on what roles they play in the enterprise (State and Counties)
and/or what groups they belong to for external entities.
*Authentication of user identities — Technology component that verifies the identities of those seeking
to access client data. Shall include strong authentication supported by an appropriate infrastructure
for identity and access management.
*The solution shall have a mechanism for Annual Reconciliation of users to determine if access is still
needed.
*The authentication and authorization solution shall be ADA compliant.
*The solution shall include the capability to monitor activity continually according to a set of predefined
rules, and to notify administrators when abnormal activity is detected (Please refer to Supplement 2 section
7.0 Security Review Services)
NFR-IDM-005 The Solution shall enforce a limit of (configurable) consecutive invalid access attempts by a user. The Proposed
Solution shall protect against further, possibly malicious, user authentication attempts using an appropriate
mechanism (e.g., locks the account/node until released by an administrator, locks the account/node for a
configurable time-period, or delays the next login prompt according to a configurable delay algorithm).
NFR-IDM-006 The Solution shall provide an administrative function that resets passwords leveraging the Identity Proposed
Management Solution of the State.
NFR-IDM-007 When passwords are used, the Solution shall not display passwords while being entered. Proposed

Non-
Requirement
Status
NFR-IDM-008 The Solution shall provide only limited feedback information to the user during the authentication as per the Proposed
Identity Management Solution rules of the State.
NFR-IDM-009 When passwords are used, the Solution shall allow an authenticated user to change their password Proposed
consistent with password strength rules in compliance with the Identity Management Solution of the State.
NFR-IDM-010 When passwords are used, the Solution shall support password strength rules that allow for minimum Proposed
number of characters, and inclusion of alpha-numeric complexity, in compliance with the Identity
Management Solution of the State.
Offeror
Response
NFR- IOP Interoperability - Interfaces
NFR-IOP-001 The Solution shall provide a Service Oriented Architecture based infrastructure (i.e., hub and spoke) for Proposed
connecting to other solutions using an Enterprise Service Bus infrastructure.
NFR-IOP-002 The solution's Interface architecture for internal A2A (Application to Application) integration shall not have a Proposed
negative impact on the user experience and expectation for application performance.
NFR-IOP-003 The solution's interfaces shall secure and protect the data and the associated infrastructure from a Proposed
confidentiality, integrity and availability perspective.
NFR-IOP-004 The Solution shall be able to support Application to Application (A2A) asynchronous messaging using web Proposed
services. The messaging capabilities will be able to support a wide variety of A2A patterns including, but not
limited to, the following:
- Data look-up and retrieval
- Data look-up with services provided by other applications
- Simple bulk data transfer to/from other solutions.
NFR-IOP-005 The solution's interfaces shall continue to operate despite failure or unavailability of individual technology Proposed
components such as a server platform or network connection.
NFR-IOP-006 The solution's interfaces must be scalable to accommodate changes in scale including changes in user Proposed
population, transaction volume, throughput and geographical distribution.
Offeror
Response
NFR- MDM Master Data Management (MDM)
NFR-MDM-001 The Solution shall include integration middleware, including publish and subscribe mechanisms, to provide a Proposed
communication backbone for the bidirectional flow of client and provider data between the central repository
and the spoke solutions, be they copies or subsets of the repository, or remote applications.
NFR-MDM-002 The Solution shall provide the ability to integrate the data within the Enterprise MDM with management and Proposed
security tools.
NFR-MDM-028 The Solution shall adhere to the State specified architectural framework and standards e.g., Medicaid Proposed
Information Technology Architecture (MITA) for Ohio Benefits.

Non-
Requirement
Status
Offeror
Response
NFR-PER Performance
NFR-PER-001 The Solution shall support either a Production and hot (real time replication) DR design or a multi host site Proposed
Production design that would allow one site to seamlessly be offline and the other site would maintain
service without interruption.
NFR-PER-002 The Solution shall include a disaster recovery (DR) plan, including recovery point objective (RPO) and Proposed
recovery time objective (RTO) as mutually agreed upon with the State. And the DR plan shall provide
contingency mechanisms for client lookup capabilities and online collaboration in the event of a disaster.
NFR-PER-003 The Solution shall provide the ability to perform archival/incremental backups and the ability to perform Proposed
open/closed database backups.
NFR-PER-004 The Solution shall be available for use 99.9% of the time (no more than 8.8 hours of downtime per year). Proposed
NFR-PER-005 The solution shall be architected with no single point of failure, supporting a high-availability enterprise Proposed
NFR-PER-006 Hours of operations shall be 24 hours per day, 7 days per week, and 365 days a year. Proposed
Offeror
Response
NFR-PS Production Support
NFR-PS-001 Upon completion of any maintenance call, the Contractor shall furnish a maintenance activity report to the Proposed
State within 24 hours, which shall include, at minimum, the following:
- Date and time notified.
- Date and time of arrival.
- If hardware, type and serial number(s) of machine(s).
- If software, the module or component name of the affected software code.
- Time spent for repair.
- List of parts replaced and/or actions taken.
- Description of malfunction or defect.
NFR-PS-002 The Contractor shall provide the State with a list of personnel, contact information, and their area of Proposed
expertise of who shall be performing Enterprise MDM solution production support.
NFR-PS-003 The Contractor shall repair any corrupted data that is associated with a problem in the Enterprise MDM Proposed
solution.
NFR-PS-004 With concurrence from the State, the routine planned maintenance activities shall be scheduled without Proposed
disrupting the negotiated operational hours. Contractor shall provide the State with a copy of the schedule at
least 30 days in advance of the scheduled maintenance date for approval.
NFR-PS-005 The testing tools and test configurations shall be provided to the State as the Enterprise MDM solution are Proposed
transitioned into support.
NFR-PS-006 The Contractor shall provide instructions and training for State support staff that may need to access and Proposed
support the Enterprise MDM solution remotely (e.g., through PDAs, tablet PC's through a VPN).
NFR-PS-007 The Contractor shall develop an automated process for purging production Enterprise MDM solution files Proposed
when necessary.
Offeror
Response

Non-
Requirement
Status
NFR-RP Regulatory Policies
NFR-RP-001 The Solution must provide a mechanism to comply with Solution security requirements and safeguards Proposed
requirements of at least the following Federal agencies / entities:
- Social Security Administration (SSA)

- Department of Health & Human Services (DHHS) Center for Medicare & Medicaid Services (CMS)
- HHS Administration for Children & Families (ACF)
- U.S. Department of Education (ED)
NFR-RP-002 The Solution shall conform to the sub-parts of Section 508 of the Americans with Disabilities Act (ADA), Ohio Proposed
RC4112-05 and any other appropriate State or Federal disability legislation.
NFR-RP-003 The Solution will conform and support the Medicaid Information Technology Architecture (MITA) v3.0 or Proposed
later.
NFR-RP-004 The Solution shall be able to adhere to all legal, statutory, and regulatory requirements, as determined by Proposed
Ohio leadership.
NFR-RP-005 The solution shall adhere to Ohio's ORC regarding Personally Identifiable Information (PII) restrictions Proposed
Offeror
Response
NFR-SE Scalability & Extensibility
NFR-SE-001 The Solution shall be designed for ease of maintenance and readily allow future functional enhancements. Proposed
NFR-SE-002 The Solution shall be adequately flexible to keep up with ever changing technology and regulatory changes. Proposed
NFR-SE-003 The solution, including programs, database, and ancillary hardware and related software solutions shall be Proposed
able to retain its performance levels when adding additional users, functions, and data.
NFR-SE-004 The Solution shall be scalable and adaptable to meet future growth and expansion needs. Proposed
NFR-SE-005 State shall be able to modify the labels and arrangement of information in the data model Solution Proposed
documentation templates and can create custom data fields.
NFR-SE-006 The Solution shall provide the ability to create and/or modify edits and business rules which determine the Proposed
correctness/integrity of data.
Offeror
Response
NFR-SEC Security
NFR-SEC-001 The Solution shall support auditing at the object level (i.e., Table, Column). Proposed
NFR-SEC-002 The Solution upon detection of inactivity of an interactive session shall prevent further viewing and access to Proposed
the Solution by that session by terminating the session, or by initiating a session lock that remains in effect
until the user reestablishes access using appropriate identification and authentication procedures. The
inactivity timeout shall be configurable.
NFR-SEC-003 The Solution shall enforce a limit of (configurable) consecutive invalid access attempts by a user. The Proposed
Solution shall protect against further, possibly malicious, user authentication attempts using an appropriate
mechanism (e.g., locks the account/node until released by an administrator, locks the account/node for a
configurable time-period, or delays the next login prompt according to a configurable delay algorithm).

Non-
Requirement
Status
NFR-SEC-004 The Solution shall support grouping users by functional departments or other organization to simplify security Proposed
maintenance.
NFR-SEC-005 The Solution shall provide the ability to identify certain information as confidential (e.g., PII, PHI, etc.) and Proposed
only make that accessible by appropriately authorized users.
NFR-SEC-006 When access to a user's account is restricted, the Solution shall provide a means for appropriately Proposed
authorized users to "break the glass" and obtain access for emergency situations, as defined by Ohio policy.
NFR-SEC-007 The Solution shall enforce the most restrictive set of rights/privileges or accesses needed by users/groups or Proposed
processes acting on behalf of users, for the performance of specified tasks.
NFR-SEC-008 The Solution shall provide the ability for authorized administrators to assign restrictions or privileges to Proposed
users/groups.
NFR-SEC-009 The Solution shall support removal of a user s privileges without deleting the user from the Solution to Proposed
ensure history of user's identity and actions.
NFR-SEC-010 The Solution shall implement security controls in accordance with all Federal and State security policy and Proposed
regulations. Compliance with the most current version of NIST 800-53 shall be documented as part of this
NFR.
(Refer to Supplement 2 for additional details)
NFR-SEC-011 The Solution shall provide the ability to operate within an RBAC infrastructure conforming to ANSI INCITS Proposed
359-2004, American National Standard for Information Technology Role Based Access Control.
NFR-SEC-012 The Solution shall provide more-advanced session management abilities such as prevention of duplicate Proposed
logins, remote logout and location-specific session timeouts.
NFR-SEC-013 The Solution shall provide the ability for concurrent users to simultaneously view the same record, Proposed
documentation and/or template.
NFR-SEC-014 The Solution shall provide protection to maintain the integrity of data during concurrent access. Proposed
NFR-SEC-015 The software used to install and update the system, independent of the mode or method of conveyance, Proposed
shall be certified free of malevolent software (malware). Contractor may self-certify compliance with this
standard through procedures that make use of commercial malware scanning software.
NFR-SEC-016 The Solution shall provide the ability to perform Solution administration functions such as reference table Proposed
maintenance and adding / removing users from the system.
NFR-SEC-017 Information security shall be built into the Solution from its inception rather than bolted on after the Enterprise Proposed
MDM Solution has been implemented.
NFR-SEC-018 The Solution shall support security at the object level (e.g., Table, View, Index). Proposed
NFR-SEC-019 The Solution shall support security at the row and column level. Proposed
Offeror
Response
NFR-SOA Service-Oriented Architecture (SOA)
NFR-SOA-001 The Solution components shall be committed to an advanced approach to interoperability using web services Proposed
and Service Oriented Architecture (SOA) aligned with State standards and vision for interoperability.
NFR-SOA-002 The Solution shall develop/integrate services using standardized Web Services formats. Proposed
NFR-SOA-003 The Solution shall allow for centralized service maintenance (new, update, delete). Proposed
NFR-SOA-004 The solution shall provide the ability to publish services and related data to be used by different types and Proposed
classes of service consumers.
Offeror
Response

Non-
Requirement
Status
NFR-SDD Solution Design, Development and Customization
NFR-SDD-001 The Contractor shall repeat the test lifecycle when a failure occurs at any stage of testing (e.g., a failure in Proposed
Acceptance Testing that necessitates a code change will require the component to go back through Unit
Testing, Integration Testing, and so forth).
NFR-SDD-002 The Contractor shall allow the State to run validation and testing software against externally facing Internet Proposed
applications to help identify potential security issues, and must agree to repair any deficiencies found during
this testing.
NFR-SDD-003 As Enterprise MDM events contain date and time-sensitive elements, the testing infrastructure must provide Proposed
a method of altering and synchronizing the Solution date throughout each test phase. This requires the
ability to change the Solution date and time in some scenarios.
NFR-SDD-004 The Contractor shall install and test a single Defect Resolution Tracking Solution that the Contractor and the Proposed
State shall use collaboratively for the tracking of Solution defects, security, and Solution issues.
NFR-SDD-005 The Contractor shall provide the State access to the software components and documentation. Proposed
NFR-SDD-006 The Contractor may not use the State Production Solution resources (data or source files), or data derived Proposed
from the production Solution resources, off-site without authorization from the State.
Offeror
Response
NFR-SA Solution Administration
NFR-SA-001 The Solution shall provide data archiving capabilities based on State defined criteria. Proposed
NFR-SA-002 All Solution communications shall be protected by at least 128-bit encryption. Proposed
NFR-SA-003 The Solution shall be supported by public key/private key encryption Secure Socket Layer (SSL) certificates. Proposed
(Please refer to current State of Ohio Encryption Standards ITS-SEC-01 and FIPS 140-2. Links are provided
in Supplement 2).
NFR-SA-004 The Solution shall provide single sign-on capability and integrate with Ohio's Active Directory authentication Proposed
and authorization.
NFR-SA-005 The solution shall provide the capability to move all unnecessary data to offline storage according to a set of Proposed
business rules and schedule to be defined by the County leadership as a part of the ongoing system
operational decision making.
NFR-SA-006 The Solution shall maintain collaboration records in line with all State retention policies. Proposed
NFR-SA-007 The Solution shall provide an auto archive/purge of the log files to prevent uncontrolled growth of the log and Proposed
historical records storage using administrator-set parameters.
NFR-SA-008 The Solution shall support encrypting data while in-transit and while at rest. Proposed
Offeror
Response

Non-
Requirement
Status
NFR-SM Solution Management
NFR-SM-001 The solution shall provide the ability to generate administrative alerts and warnings when statistics indicate Proposed
an impact or potential limits on solution component performance and availability. The specific alerts will be
defined by the hosting services provider.
NFR-SM-002 The Solution shall provide Application Performance Monitoring and Management capabilities (i.e. transaction Proposed
monitoring, synthetic transactions, component root cause analysis (e.g., Application Server Management).
Offeror
Response
NFR-TML Transaction Monitoring & Logging
NFR-TML-001 The Solution shall allow for Report generation and analysis for application troubleshooting and capacity Proposed
planning.
Offeror
Response
NFR-CP Capacity Planning
NFR-CP-001 The Contractor shall analyze, evaluate and plan for the Enterprise MDM system’s Capacity Utilization in the Proposed
following areas:
 CPU capacity
 Disk Space capacity
 Memory capacity and usage
 Data Center LAN and Wide Area connectivity elements capacity.
NFR-CP-002 The Contractor shall provide a remediation/enhancement plan to the State, to address Proposed
Enterprise MDM system exceeding the norms of the State as notified by the OIT in the following
areas:
 CPU aggregate sustained utilization capacity
 Disk space capacity
 Memory usage
 Data Center LAN and Wide Area connectivity elements capacity
Offeror
Response
NFR-USB Usability
NFR-USB-001 The Solution will adhere to the accessibility standard as outlined in the web guidelines and based on the Proposed
W3C level 2 accessibility guidelines:
(http://www.w3.org/TR/WCAG10/full-checklist.html).
NFR-USB-002 The Solution shall support undo and redo while complying with specific rules like once confirmed/sent/etc., Proposed
no undo/redo.

Non-
Requirement
Status
NFR-USB-003 The Solution shall follow standardized conventions and limit the use of words, situations, or actions that have Proposed
multiple meanings.
NFR-USB-004 The Solution shall eliminate error-prone conditions or check for them and present users with a confirmation Proposed
option before they commit to the action.
NFR-USB-005 The Solution shall provide the option to have rollover / tooltip help or context messages and provide the Proposed
option to turn off this option in the user preferences profile.
NFR-USB-006 The Solution shall provide all Solution instructions in a visible or easily retrievable location, when Proposed
appropriate.
NFR-USB-007 The Solution shall adhere to all Federal and Ohio accessibility requirements, or their successors: Proposed
(section 508 of the Rehabilitation Act and detailed in section 1194.22 of the Code of Federal Regulations,
Web-based intranet and internet information and applications;
http://das.ohio.gov/LinkClick.aspx?fileticket=99cw1kez4Hc%3d)
NFR-USB-008 The solution's error messages shall be expressed in plain language, precisely indicate the problem, and Proposed
constructively suggest a solution.
NFR-USB-009 The Solution shall use colors to enhance user experience and Solution usability while complying with all Proposed
disability requirements notated elsewhere in these requirements.
NFR-USB-010 The Solution shall not show fields not accessible to a given user based on access rights, nor shall the Proposed
Solution show fields not in use.
NFR-USB-011 The solution shall provide validation checks by methods described within policy, functional, and detailed Proposed
requirements.
NFR-USB-012 The Solution shall identify invalid entries to the user as immediately as possible. Proposed
NFR-USB-013 The Solution shall provide the ability to suggest or automatically change entries that do not conform to data Proposed
entry standards.
NFR-USB-014 The Solution shall be designed to include only the necessary information and functionality on screens and Proposed
shall be based on the user's access level and the user's configuration.
NFR-USB-015 The Solution shall be designed to include logical transitions between screens and level of detail during Proposed
navigation.
NFR-USB-016 The Solution shall provide templates for data entry with identified mandatory and optional data fields. Proposed
NFR-USB-017 The Solution shall highlight and flag required and incomplete data fields. Proposed
NFR-USB-018 The Solution shall provide a user interface that shall be simple and consistent throughout all areas and Proposed
functions of the solution.
NFR-USB-019 The Solution's web interface shall be Web 2.0 compliant Proposed
NFR-USB-020 The solution shall support multi-language Proposed
NFR-USB-021 The solution shall support (including but not limited to; render and execute properly) the current or two Proposed
immediately previous major versions (read major versions as: numbered versions prior to decimal [i.e., 9.x,
14.x, etc.]) of Internet Explorer, Firefox, Chrome, Safari, as well as native browsers on Android and IOS
devices.
NFR-USB-022 The solution shall preserve context by limiting abrupt transitions and redisplays to maximize and enhance Proposed
the user experience and solution usability.
NFR-USB-023 The Solution shall follow State of Ohio conventions, making information appear in a natural and logical order. Proposed
Offeror
Response

3.9 RFP Assumptions
Assumption Assumption Description

ID
1 It is expected that upstream and target systems will be responsible for design, development and implementation of changes
within their systems to support integration with the Enterprise MDM environment.
2 It is expected that Data Use Agreements, or MOU (memorandums of understanding) will be required.
3 It is expected that the list of data elements will be further validated by the Contractor.
4 During the Fixed-bid implementation phase, the Contractor will perform work that is documented and explicitly approved,
which requires a written request that includes the scope, timing, applicable deliverables and cost is presented to and
approved by the State.
5 The State has procured an enterprise license for Informatica MDM, which has sufficient licensing to support any design and
data requirements within the scope of this RFP.
4.0 State Project Delivery, Management, Methodology and Approach Requirements

The Offeror will provide the State its recommended methodology and approach to the projects and any projects
that arise following the successful completion of the project because of this RFP.
The State maintains a project management and reporting methodology that is used at varying levels for complex,
transformational Information Technology projects. This methodology is designed to provide a substantive and
objective framework for the reporting and review of projects to impacted stakeholders and, should the need arise
identify the need for corrective action for one or many of the participants in a project (e.g., State, Contractor,
Customer, Stakeholder).
The State acknowledges that various Contractors that may do business with the State may maintain unique or
proprietary project management methodologies, but seeks to ensure that the overall project is delivered to the
State as contracted. Therefore, a minimum standard project management reporting standard has been created to
serve the State’s project management and oversight needs while not adversely impacting or influencing
Contractor provided delivery methodologies. For purposes of this RFP, this minimum standard has been extended
to include current environment assessment as well as data governance and stewardship related activities and
deliverables that are specific to a master data management project.
The Offeror must provide a summary Project Plan as requested by the State. For purposes of a summary project
plan specific phase and gate dates, effort and costs are a sufficient minimum.
Following the award of this Contract, and during the project mobilization phase Contractors must include the
following deliverables and milestones within their detailed project plans and methodologies at a minimum upon
commencement of the project: The Contractor will provide the State its recommended methodology and approach
to the projects and any projects that arise following the successful completion of the project because of this RFP.

4.1 Project Management and Coordination Services
The Contractor will follow the Project Governance structure defined by the State. Project Management will include
the activities to manage the Project including directing the Project Team according to the Project work plan,
reporting status, managing issues, assessing quality, leading project meetings, and monitoring schedule and
scope changes. The Project Team will produce project status reports on a weekly basis. The format of the status
report will be mutually agreed to by the State and the Contractor during the first week of the Project.
The Contractor will, in conjunction with an authorized Statement of Work arising from this Supplement:
 Be responsible for the coordination and delivery of the overall Project

 Ensure that an appropriate “Project Kickoff” occurs and that all integrated work plans are agreed to by the State
from project commencement
 Ensure that all efforts have an effective version control mechanism for all documents within the project
document library that will be maintained on a State provided Microsoft SharePoint site
 Work with the State leadership to ensure that the Project is staffed appropriately
 Ensure that required testing activities across both technical and operational components are completed to
minimize Project risk
 Collaborate with the task areas to ensure appropriate cross-team communication and delivery
For purposes of the Project, “Perform” means, that the party assigned the task has the duty and ultimate
responsibility to take all appropriate steps to complete or facilitate the identified task unless otherwise provided for
between the parties, subject to the Supporting party completing its interdependent responsibilities. The term,
“Support” means that the party has the duty and responsibility to provide ancillary support or assistance, which
may be necessary to enable the party providing the “Perform” task to complete that task unless otherwise
provided for by the parties. The designation, “-” means that the party has no responsibility for the task, unless
otherwise agreed by the parties.
Key Tasks State Contractor

Conduct Project kick-off meeting Support Perform
Create a Work Breakdown Structure (WBS) Support Perform
Create and Maintain a project work plan and any related deliverable sub plans Support Perform
Review Deliverables and manage the State’s approvals Perform Support
Review Deliverables and manage the Contractor’s approvals Support Perform
Prepare and conduct project meetings Support Perform
Prepare and conduct stakeholder meetings Perform Support
Create Project Status Reports adhering to the PMO policies Support Perform
Report and manage issues and risks Support Perform
Monitor and report schedule and scope changes Support Perform
Identify State stakeholders and manage expectations Perform Support
Assist with on-boarding for the Contractor resources Support Perform
Assist with on-boarding for the State resources Perform Support
Confirm State Project staffing Perform Support
Confirm Contractor Project staffing Support Perform
Confirm Project governance Perform Support
Confirm Data Governance Strategy and Framework Perform Support
Initiate System Turnover Process Support Perform
PAC – Provide planned checkpoint review dates Support Perform

4.2 State Project Governance Considerations
The State will provide the following team resources to participate in the overall governance of the project and its
delivery:
Office of Health
Transformation
ODM Provider
Ohio Benefits
Project Team
Management
EDW
JFS
Role
Data Stewards
Knowledge of the current business and data for Part
Part Time Part Time Part Time
Individual (Client, Recipient, Seeker, etc.) and Business n/a Time
SMEs SMEs SMEs
(Provider, Payor, etc.) and in the position to identify and SMEs
research data quality or other data related issues.
Master Data Management Strategist

Knowledge of the current master data management
solutions and use of Informatica. Establishes direction 1 FTE
from a data stewardship/governance as well as solution
architecture and requirements perspective.
Business Analyst Lead

Knowledge of Enterprise MDM functional, data and non- 1 FTE
functional requirements to provide guidance to
Contractor.
Data Analyst Lead

Knowledge of Enterprise MDM data requirements and 1 FTE
systems to provide guidance and oversight to the
Contractor on data analysis related activities.
IT Specialist Part
Part Time Part Time Part Time
Knowledge of the source systems that supports the n/a Time
SMEs SMEs SMEs
existing environments, data, and IT processes. SMEs
Source Data Provider(s)

Part
Representation from participating agencies that collect Part Time Part Time Part Time
n/a Time
the individual data elements and provide subject matter SMEs SMEs SMEs
SMEs
expertise to resolve questions.
Project Leadership Team

3 PTE
Provide oversight and executive sponsorship to the 1 PTE
1 FTE
Enterprise Master Data Management Effort.
4.3 Create and Maintain Project Plan

The Contractor must produce a detailed Project Plan, in electronic and paper form, to the State Project for
approval within twenty business days after the State issues a purchase order or other written payment obligation
under the Contract.
Master Project Plan
The Project Plan should include the following (at a minimum):
 Project Integration
 Project Scope
 Project Time
 Project Quality
 Project Staffing
 Project Communications
 Project Risks/Issues
 Project Procurement
The Contractor must lead a planning session, which ensures the following:
 A common understanding of the work plan has been established

 A common vision of all deliverables has been established
 Contains a critical path that identifies all major milestones, dependences (both internal and external to the
project), resources by name and resource assignments and is complete and inclusive of the entire work effort
from commencement until conclusion of all contracted activities
 Clarity on scope of overall project and the responsibilities of the Contractor has been defined and agreed to by
the State that includes a common understanding of the business, process, technical and other elements of the
overall implementation as required
Thereafter, the Contractor must:
 Formally update the Project Plan, including work breakdown structure and schedule, and provide the updated
Project plan as part of its reporting requirements during the Project
 Ensure the Project Plan allows adequate time and process for the development for the State’s review,
commentary, and approval
The State will determine the number of business days it needs for such reviews and provide that information to
the Contractor after award and early in the development of the Project Plan. Should the State reject the plan or
associated deliverables, the Contractor must correct all deficiencies and resubmit it for the State’s review and
approval until the State accepts the Deliverable at no additional cost to the State.
At a minimum, the Contractor must include a Proposed Project Plan(s), which will include the following:
 A summary Work breakdown structure Scope statement that includes the Work objectives and the Work
Deliverables and milestones associated with completion of all the Work with specific provisions for the work
contained and as required by the projects
 The Contractor must provide a detailed Project Plan as a Microsoft Project Gantt chart (in native MS
Project file “.mpp” format), showing all major Work tasks on a week-by-week schedule, with Proposed Team
Members (by name for Key Personnel and by Role for other Project team members) and indications of State
participation requirements in the Project(s) to serve as the basis for managing and delivering the Work. The
schedule must clearly demonstrate how the project will become fully operational by the delivery date. Within
this detailed plan, the Contractor must give dates for when all Deliverables and milestones will be completed
and start and finish dates for tasks. The Contractor also must identify and describe all risk factors associated
with the forecasted schedule.

 The Contractor will indicate who (State or Contractor) is assigned responsibility for each Deliverable
within the work breakdown structure to the level at which control will be exercised
 Performance measurement baselines for technical scope, budget adherence, deliverable assembly, production
and approvals in the context of the overall schedule
 Description of the Contractor’s proposed organization(s) and management structure responsible for fulfilling the
Contract’s requirements and supporting the Work, in terms of oversight and control
 A summary Required State staff and their expected roles, participation and level of effort by project area (e.g.,
functional, technical, business) as well as role within each Project Phase (e.g., Requirements, Design,
Construction, Testing, Deployment)
 Description of the review processes for each milestone and Deliverable (e.g., mandatory design review) and a
description of how the parties will conduct communication and status review
 Description of the Project issue resolution process including an escalation plan
 Description of the approach to manage subcontractors effectively, if the Contractor is proposing subcontractors
4.4 Project Financial Management

Project financial management is a discipline based upon standard financial and accounting principles focused on
those principles that apply to effective management of project and data cleansing services. The primary focus of
the project financial management with respect to this RFP is to ensure funding alignment between the fixed-not-
to-exceed price contract with the Contractor for development and data cleansing services provided to the actual
scope of services (e.g., components being supported along with other support tasks within the scope of this RFP)
acquired and management of approved funds to be used for unanticipated project services. More specifically,
financial management activities that the Contractor will be responsible for include:
 Management of Unanticipated Project Services Funding Pool
 Management of Data Cleansing Funding Pool
 Management of project scope changes relative to the baselined project development and data cleansing
services acquired as defined in this supplement
For purposes of this supplement and project development and data cleansing activities defined herein, the
Contractor will be fully accountable for managing project development costs within the scope of the fixed-not-to-
exceed price contract services acquired by the State as well as managing the funding pools for use to perform
approved unanticipated project services and data cleansing activities.
With respect to managing costs associated with project development and delivery, the Contractor will be expected
to perform monthly analysis of project development scope changes against the baselined requirements,
deliverables and work products as defined in this supplement. This analysis will be reviewed monthly to determine
whether adjustments to the project development fixed-not-to-exceed price contract are required to adjust it to
reflect current scope, inclusive of all project change requests.
Unanticipated Project Services is newly proposed work for the Contractor’s application development team. Types
of unanticipated work include additional work products or deliverables not contained in the RFP and associated
SOW and enhancement requests. Following are the key process steps regarding how Unanticipated Project
Services will be identified and managed:
 Candidate unanticipated project services are identified through a project change request or email request from
the State.
 Candidate unanticipated project service request is documented using a Project Change Request form that
provides additional descriptive information regarding the request, impact analysis, resource plan to resolve
along with development, testing, and production deployment estimates. Resource costing performed on the
Project Change Request is performed using the current blended project development rate in effect from the
Contractor. If the request is for additional data cleansing services, then the Project Change Request is costed
using the current blended rate for data cleansing resources.
 The Project Change Request along with cross reference information to the inbound request information is
documented in the Project Change Request Log.
 The Project Change Request is routed to the Project Leadership Team and other key stakeholders for review
and approval. Level of review and approval required will depend upon the nature and cost of the Project
Change Request. Review and approval steps along with status of the Project Change Request are tracked in
the Project Change Request Log.
 Once the Project Change Request is approved, costs associated with the change request will be added to a
committed column and used to decrement remaining available Unanticipated Project Services or Data
Cleansing funds. If the Project Change Request is for a change in project scope, then the cost of the change
request will be tracked with analysis on the fixed-not-to-exceed price contract.
 Should the approved Project Change Request reduce the scope of project development performed that are a
part of the project development fixed-not-to-exceed price contract, then the fixed-not-to-exceed price contract
amount will be renegotiated to reflect this change.
 Should the approved Project Change Request increase the scope of the project development performed that
are a part of the project development fixed-not-to-exceed price contract, then the fixed-not-to-exceed price
contract amount will be renegotiated to reflect this change.
 The approved Project Change Request status is tracked through development, data cleansing, testing, and
production deployment activities through to closure in the Project Change Request Log.
 When the approved Project Change Request development is ready for production deployment (this doesn’t
apply to data cleansing work) a Production Change Request is prepared, and approved using established
release management processes.
 Once the development work associated with the Project Change Request is deployed to the production
environment and validated, the cost associated with the project change request is moved from the committed
column to the actual incurred column (for unanticipated project services). The remaining available
Unanticipated Project Services fund balance is decremented to reflect successful completion and deployment of
the change. If the unanticipated project services work is design, architecture, or documentation related, then the
cost associated with the project change request is moved from the committed column to the actual incurred
column when the work is completed and has been formally accepted by the State.
For purposes of this Supplement and project development and data cleansing work contained herein, the
Contractor will be responsible for the following key financial management tasks:

Define Project Services fixed price services contract service change management process Support Perform
Define Project Services Unanticipated Project Services and Data Cleansing fund management
Support Perform
tracking and change management process.
Perform actual to forecast financial management of the project development and data cleansing
Support Perform
services provided in the fixed-not-to-exceed price contract monthly.
Perform monthly reporting of Unanticipated Project Services fund management including Project
Support Perform
Change Requests in process and a detailed analysis of the remaining available funds
Participate in financial management meetings with State Project Leadership team as well as
Support Perform
other key State stakeholders
4.5 Project Review Check Point

Upon completion of the baselined Project Plan and on a quarterly basis throughout the Project, the Contractor, in
conjunction with State Project team staff, must deliver a presentation to the State. At a minimum, the presentation
must address any known State or Contractor issues or concerns, including but not limited to the following:
 Project scope, budget and schedule

 Any changes to Key named resources assigned to the Project
 Project readiness including key issues and risk from their current status
 Project Status including variance from baseline for key milestones, tasks, deliverables (Significant work
products) and project closure
 Methodology, approach, and tools to achieve the Project goals (inventory and status of completeness and
agreement for documented project management and implementation approaches, i.e., Project management
plan, communication plan, requirements traceability, implementation approach and methodology)
 Roles, responsibilities, and team expectations
Upon completion of the presentation, the State will immediately assess the health of the project and determine
next steps for moving forward with the Project, within one week of the meeting, which may include the following:
 Continue the Project

 Terminate the Contract
 Suspend the Contract
See Suspension and Termination language in Attachment Four for remedies for failure to deliver the proposed
work.
Note: There may be additional Project Reviews conducted by the State on an as needed basis throughout the
term of the Contract to assess Project health and ensure the Project is progressing successfully.
4.6 Meeting Attendance and Reporting Requirements

The Contractor’s project delivery approach must adhere to the following meeting and reporting requirements:
 Immediate Reporting - The Project Manager or a designee must immediately report any Project staffing
changes to the State Project Representative
 Attend Weekly Status Meetings - The State and Contractor Project Managers and other Project team members
must attend weekly status meetings with the Project Representative and other members of the Project teams
deemed necessary to discuss Project issues. These weekly meetings must follow an agreed upon agenda and
allow the Contractor and the State to discuss any issues that concern them.
 Provide Weekly Status Reports - The Contractor must provide written status reports to the Project
Representative at least one full business day before each weekly status meeting
 At a minimum, weekly status reports must contain the items identified below:
 Updated GANTT chart, along with a copy of the corresponding Project Plan files (i.e. MS Project) on
electronic media acceptable to the State
 Updated Critical Path analysis with the aforementioned GANTT chart and an accompanying PERT chart
 Status of currently planned tasks, specifically identifying tasks not on schedule and a resolution plan to
return to the planned schedule
 Issues encountered, proposed resolutions, and actual resolutions
 The results of any tests
 A problem tracking report must be attached
 Anticipated tasks to be completed in the next week
 Task and Deliverable status, with percentage of completion and time ahead or behind schedule for tasks
and milestones
 Proposed changes to the Project work breakdown structure and Project schedule, if any
 Planned absence of Contractor staff and the expected return date
 System integration/interface activities
 The Contractor's proposed format and level of detail for the status report is subject to the State’s approval
4.7 Utilize OIT’s Document Sharing/Collaboration Capability

In conjunction with the delivery of the Project, coincident with the start of the project through its conclusion, the
Contractor must use the State provided and hosted document management and team collaboration capability
(Microsoft® SharePoint™) to provide access through internal State networks and secure external connections to all
project team members, approved project stakeholders and participants. In conjunction with the utilization of this
tool, the Contractor must:
 Structure the document management and collaboration pages and data structures in such a manner as to
support the overall requirements of the Project
 Store all documents in machine readable, editable and native formats (e.g., XLSx, PPTx, VSD, DOCx) as
opposed to proprietary, non-editable, image format or PDF based renderings
 Be responsible for the maintenance and general upkeep of the designer configurations of the tool in keeping
with commercially reasonable considerations and industry best practices as to not adversely impact the project
delivery efforts performed by the Contractor and State
 At the conclusion of the project, or upon request of the State, ensure that the State is provided a machine
readable and comprehensive backup of the SharePoint™ database(s) contained within the tool that is owned
by the State and not proprietary to the Contractor or otherwise required by the State to maintain ongoing project
documentation and artifacts (i.e., Contractor is to remove all Contractor proprietary or non-State owned or
licensed materials from the tool)

4.8 Production/Version Control and Release Management
The Contractor will be responsible for working with the State and executing the production deployment and roll-
out of any Release Package to the State’s on-premises environment instance. Production deployment includes
software deployment to the production environment and (if applicable) interfaces to production tools and systems
that orchestrate, manage, report or control those devices and services managed by the Service, identification of
interfaces and any required conversions/migrations, installation of server software, and any required testing to
achieve the proper roll-out of the Release Package software.
Contractor will establish and comply with the State required implementation and deployment procedures. This
may include laboratory testing, migration procedures, the use of any pre-production or pseudo-production
environment prior to production migration. Contractor will submit to the State, for the State’s approval, a written
deployment plan describing Contractor’s plan to manage each such implementation. The tasks and activities to be
performed by Contractor as part of the deployment services also include the following:
 Establish procedures and automated software versioning mechanism(s) to ensure that the entire contents of a
release, following State acceptance or authorization to implement to a production environment, are complete
and maintain all elements that comprise the defined Release Package and the then current production version
of the software prior to deployment of the Release Package to same
 Develop, prepare and test emergency back out or roll back procedures to return the production system to its
pre-deployment State as it pertains to correcting an errant, erroneous or defective deployment of a Release
Package to the production environment inclusive of all code, data, middleware, infrastructure, tables and
parameters
 If, in the mutual opinion of the State and Contractor, the deployment of a Release package to the production
environment is errant, erroneous or otherwise defective, implement back-out or rollback procedures in their
entirety upon the written authorization or direction of the State
 If required, convert electronic data into a format to be used by the new solution using a data conversion
program as well as perform any data cleansing of legacy data, with the State’s assistance, prior to loading data
to the new solution
 Conduct production release(s) (including “day in the life” simulations) and fine tune solution as mutually agreed
with the State as appropriate
 Compile and maintain solution issue lists
 Conduct post Production Deployment quality and progress reviews with appropriate State personnel
 Develop, and thereafter maintain and make available to the State, a knowledge base of documentation
gathered throughout the Release Package’s life and allow for re-use of such documentation for future Projects
 Establish a performance baseline for the impacted business systems, and where appropriate document
requirements for future enhancement of the business systems implemented as part of a future Project or
Authorized Work

4.9 Maintaining Solution and Operations Documentation
For all custom processes, modifications, and nonproprietary portions of the solution, the Contractor will:
 Document the solutions developed or modified by the Contractor in accordance with established methods,
processes, and procedures such that, at a minimum the State or a competent 3rd Party vendor can
subsequently provide a similar scope of Services
 Develop and maintain, as agreed appropriate, the documentation on system environments. Where it is
determined that documentation is inaccurate (for example, due to demonstrated errors or obsolescence), and
such inaccuracy may negatively affect the Services, Contractor will correct such documentation as part of
normal day-to-day operational support
 Update programmer, End User and operational reference materials
 Maintain all documentation on the State’s SharePoint site
4.10 Project Delivery, Role and Responsibility Requirements

The State has organized our requirements for responsibilities of the State and Contractor based on the
anticipated Activity Areas required to analyze, design, implement and deploy the solution as well as those
requirements and activities required to support the deployment of the overall solution. Should a Contractor, as a
result of the review of these requirements in light of their proposed approach require additional roles or clarity, the
Contractor must indicate the additional requirements of the State and provide a high level rational for the same as
part of their response.
The responsibility matrices included throughout the remainder of this section identify Key Tasks to be performed
as part of this project. Each Key Task has been assigned to a party and the level of responsibility for each party is
designated as either a Perform, Support or designated “-” for no responsibility.
Note: If the Contractor’s recommended methodology does not align with the responsibility matrices below, the
Contractor will propose and subsequently as the Contractor adhere to matrices that do align with the Contractor’s
methodology. The Contractor must also demonstrate that the recommended methodology and the responsibility
matrices comply with the State’s need to: (1) know the Contractor has a complete understanding of the State’s
requirements, (2) the Contractor’s design and development efforts are in line with the State’s requirement for the
solution, (3) monitor the Contractor’s progress during the project, (4) the project risk is acceptable and is
managed effectively by the Contractor, (5) have accurate and complete technical documentation regarding the
solution (as designed and as delivered), and (6) know the solution delivered and deployed by the Contractor has
been adequately tested and meets the State’s requirements.
4.11 System/Environment Administration Support of the Project

The Contractor will coordinate with the State, but be responsible for all environments (production, non-production,
demo/training/CRP, development and testing) as required to support the overall effort and will:
 Perform technical activities including but not limited to: version control, PS-Admin, Informatica, PL/SQL,
workflow, dashboard, reporting, batch integration, web service, notification and alert development, system
code/object migrations, job scheduling definitions, patch implementations, log administration, data copies and
exports, interface and scheduled reporting/ETLs, and responsibility for incident resolution such that migrations

into production will be executed at agreed periodic intervals and other production changes will be scheduled
during the maintenance window
 Support multiple release levels of System software/hardware elements for in-scope Services, provided that
such support does not impair the Contractor’s ability to meet Contractor development and project commitments
until such time as all environments can be upgraded to the same version/release level
4.12 Establish and Manage a Program Management & Master Release Calendar
The Contractor will coordinate with the State in the development, and maintenance on a monthly basis a Master
Release Calendar that includes a schedule (with dates) of:
 Major/Minor and Scheduled Releases, Upgrades, Updates and Enhancements

 Implementation of Projects, Minor Enhancements or Discretionary Work
 Scheduled Maintenance Windows and Planned Outages
 Major and Minor Project Key Dates (i.e., Start, SDLC Gate Completion, Production Release, Completion)
whether Contractor delivered or otherwise
 Other pertinent dates that require end-user notification or coordination
4.13 Cooperation with State and State Contractors

Contractor will cooperate with the State in its attempts at transferring, replacing or augmenting the services
responsibilities to another provider in a manner in keeping with not adversely affecting the provision of ongoing
services and other projects being performed concurrent with this project.
4.14 Requirements Confirmation and Analysis (for each release)

The expectation for this project phase is the Contractor will thoroughly document the desired Enterprise Master
Data Management business requirements, and elaborate on and confirm all State business, operational,
functional and technical requirements and recommend changes which will improve the State’s business
processes and requirements.
4.15 Current Environment Assessment

The expectation for this project phase is the Contractor will thoroughly document the current Informatica platform
environment focusing on its usage for the current state implementations of the Master Client Index (MCI) and
Master Provider Index (MPI). Based upon this understanding, the Contractor will recommend a future state
Master Data Management solution approach focused on both the business and data requirements as well as the
optimal usage of Informatica platform components and services to achieve an Enterprise Master Data
Management future state that supports both an Enterprise hub and potentially agency-specific hubs. Additionally,
the focus will be on extending and improving MCI and MPI work performed for Ohio Benefits in a broader
enterprise context.

4.16 Data Governance and Stewardship
The expectation for this project phase is the Contractor will collaborate with the State business and IT
professionals to mature our current Data Governance and Data Stewardship practices. The matured set of
practices shall include the following:
 Strategy and Framework for Enterprise Data Governance
 Strategies for Data Stewardship, Data Quality and Metadata Management
 Data Management Standards to support the scope of the Enterprise Master Data Management initiative
 Data Quality Policies, Standards, Procedures and Tools
 Metadata Management Policies, Procedures and Guidelines
 Identify and Define Master Data Management Key Performance Indicators
 Define Master Data Management Dashboards and Reports
These strategies, policies, procedures, guidelines and tools will be used by the project team during each project
implementation within the scope of this RFP. Scope of tasks coverage will include Enterprise MDM as well as
Agency specific procedures and guidelines as they pertain to Individual and Business (Provider) data domains
within the scope of this RFP. Contractor shall make recommendations on how these strategies, policies,
procedures, guidelines, and tools may be extended for other ongoing projects and initiatives.
4.16.1 Agency Data Quality Improvement Plan

If an agency fails to produce data that meet required standards in any area, the Contractor must include a brief
data quality improvement plan that describes how the agency must move toward quality standards to meet the
delivery dates required by the Project. The plan must address all standards that the agency did not meet,
describe what new policies or procedures to put in place to meet the standards, identify barriers to moving to a
higher quality level, and identify the technical assistance needed to implement the plan.
4.17 Analyze Phase Requirements (for each planned release)

The Contractor Team will review, analyze and update the State’s Requirements and system(s) documentation.
The Contractor team will conduct workshops to confirm with SMEs the results of their business requirements
analysis.
The Contractor Team will also analyze impacts to the integration points with external systems. In addition, the
Contractor team will analyze external systems and data, and recommend data for migration to the solution as
applicable.
The Contractor team will deliver the resulting business requirements (expected to be a modified version of the
State’s current functional requirements), a Requirements Traceability Matrix (RTM), the accompanying business
processes modified as required and a list of customizations if applicable. All changes to the State’s original
functional requirements and business processes are to be clearly indicated.

Review and update Business and Technical Requirements. Support Perform
Profile source/target data and Document the results Support Perform
Document analysis of integration points with external systems. Support Perform
Provide functional impacts within external systems. Support Perform
Assess and Document impacts to upstream and downstream systems Support Perform
Create Requirements Traceability Matrix. Support Perform
Create Customization Tracking Database (if applicable). Support Perform
Define Functional and Technical Requirements. Support Perform
Define the solution architecture. Support Perform
Define changes within upstream and downstream system(s) Support Perform
Document possible solution options for identified gaps, as applicable Support Perform
Document plan for integration points. Support Perform
Define technical environment requirements for the project from design through deployment and run.
This includes any components or tools required to support development, test, configuration Support Perform
management, etc.
Updated RTM with functional requirements and technical requirements cross-referenced. Support Perform
Define the required training and operations materials Support Perform
Define Data Quality Scorecard Support Perform
Define Data Quality Remediation Plan Support Perform
Perform Data Profiling Support Perform
4.18 Design Phase Requirements (for each planned release)

The Analyze Checkpoint must be successfully completed prior to beginning the Design phase. This includes the
State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope and schedule
for the remainder of the Project will also be completed at the Analyze Checkpoint.
The Contractor Team will create and maintain Functional Designs for the solution. Functional Designs contain
data, business and security impacts and includes integration points to external systems.

Define or Extend Master Data Management Framework Support Perform
Define or Extend Infrastructure Architecture Perform (OIT) Support
Define or Extend Business Architecture Support Perform
Define or Extend Data Architecture Support Perform
Define or Extend Integration Architecture Support Perform
Define or Extend Solution Architecture Support Perform
Create Functional Designs (High and Low level functional design documents) based on
Support Perform
requirements.
Define and Document Data Quality Rules Support Perform
Build changes within upstream and downstream system(s) Perform Support
Update Requirements Traceability Matrix with design and configuration cross references Support Perform
Create System Test, UAT, and ORT strategies Support Perform
Create and update the Technical Designs for solution, including any interfaces to external
Support Perform
systems.
Create and update the Security Designs for the solution. Support Perform
Update environment plans for the Project Support Perform
Build technology environments required for Build & Test Support Perform
Support technical environments, including patches and fixes Support Perform
Create Implementation and Deployment Strategy Support Perform
Create the training and operational document outlines Support Perform
Define Development Playbook Support Perform

4.19 Build Phase Requirements (for each planned release)
The Design Checkpoint must be successfully completed prior to beginning the Build phase. This includes the
State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope and schedule
for the remainder of the Project will also be completed at the Design Checkpoint.
The Contractor Team will build the solution and prepare for testing. The State will provide one (1) knowledgeable
SME per functional area in test preparation and as mutually agreed to with the Contractor to support test
preparation.

Provide test conditions and scripts. Support Perform
Build and Unit Test configuration and security to support the business processes Support Perform
Build Data Quality Dashboard Support Perform
Create System Test, UAT, and ORT conditions, scripts, and scenarios Support Perform
Prepare testing schedule and participation for System Test, UAT, and ORT Support Perform
Create Master Test Plan Support Perform
Build Data Quality Rules Engine and Data Quality Dashboards Support Perform
Test changes within upstream and downstream system(s) Perform Support
Build and Unit Test the solution as applicable Support Perform
Build and Unit Test customizations as applicable Support Perform
Perform Manual Analysis and Cleansing of Source system data Support Perform
Build and Unit Test updates to Execution Environment (i.e. interfaces, print, security services,
Support Perform
and network infrastructure)
Build Test Environment(s) Support Perform
Build Training environment Support Perform
Build Operations Environment (i.e. production) Support Perform
Create Assembly Test and Performance Test conditions, scripts, and scenarios Support Perform
Create Deployment and Stabilization Plan and tools (readiness criteria, critical path, and cutover
Support Perform
activity list).
Create the training and operational documents Support Perform
Update Requirements Traceability Matrix Support Perform
4.20 Test Phase Requirements (for each planned release)

The Test Readiness Review Checkpoint must be successfully completed prior to beginning the Test phase. This
includes the State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope
and schedule for the remainder of the Project will also be completed at the Test Readiness Review Checkpoint.
For avoidance of doubt with respect to testing activities, the Contractor is accountable for all activities associated
with System Test while the State will participate in these activities. The State is accountable for UAT Test
execution while Contractor will be responsible for test preparation, management and tracking of UAT activities.
The Contractor Team will execute System Test, User Acceptance Test (“UAT”), and Operational Readiness Test
(“ORT”). The State will provide SMEs knowledgeable in test execution and as mutually agreed to with the
Contractor to support test execution.
System Test focuses on the customizations, configurations, workflow and integrations. Test conditions and test
scenarios to be included in the System Test will be mutually agreed upon by the Contractor and the State. These
scenarios will be based on an analysis of the requirements, changes, and modifications that are approved for
implementation.

UAT verifies the usability of the new processes and ensures that the system meets the needs of the organization
and the end user. UAT leverages System Test Scripts and is executed by Agency resources. A key objective of
UAT is to facilitate an understanding of the technology and the business change being implemented.
ORT includes end-to-end testing of processes and technologies and will be executed by State members of the
Project team. ORT will be conducted during a specific time-period before Go-Live.
The State will conduct a Security Test that includes an application scan, manual testing of the system using client-
side code analysis, and loading maliciously formatted inbound interface files.
The Contractor Team will develop and prepare weekly status reports to monitor the progress of each test phase.
The status reports will contain sections for condition creation, script creation, script execution, issue identification
and resolution, and defect identification and resolution.

Develop and maintain test data repositories as agreed appropriate Support Perform
Manage and track System /Regression Test, UAT, and ORT Support Perform
Manage and execute Data Quality rules in Rules Engine and document results Support Perform
Validate and Sign-off on Data Quality rules Perform Support
Execute System / Regression Test and document results Support Perform
Deploy changes within upstream and downstream system(s) Support Perform
Execute UAT Perform Support
Document UAT results Support Perform
Execute ORT Perform Support
Document ORT results Support Perform
Prepare for and execute Security Test Perform Support
Prepare for and execute Assembly Test Support Perform
Prepare for and execute Performance Test Support Perform
Support Functional Team Testing Support Perform
Conduct Test Moves to Production (Mock Conversion) Support Perform
Create the Deployment and Stabilization Plan Support Perform
Develop, update and maintain a migration checklist Support Perform
Conduct training on operational processes and procedures to the users Support Perform
Prepare for final Move to Production Support Perform
Update Requirements Traceability Matrix Support Perform
The Contractor team will execute Assembly Test and Performance Test.
Assembly Test verifies that the technical architecture works together as planned and tests that all modules were
migrated appropriately. The objective of the Assembly Test is to verify that related components function properly
when assembled into an overall system.
Performance Test establishes a baseline of acceptable performance for a sample of master data transactions.
The tests are conducted under a practical proportion of expected transaction and user volumes to mimic real-
world usability. The sample is based upon mocked up data entered into the solution. The number, frequency, and
concurrency of online user transaction load will be defined using the most recent Contractor team estimates of
activity available at the time of test preparation. The estimates will be based on enterprise-wide usage (as
opposed to usage of only the Initial Release Agencies).
The Contractor will recommend a Test Moves to Production strategy as appropriate for their solution’s
environment(s). The Contractor will demonstrate to the State that the strategy allows for the development and

testing of a migration process and checklist, as well as an assessment of timing and any mitigation or resolution
of any issues related to timing.
Throughout the Project duration, if a testing or production incident is due to errors, omissions, documentation
inconsistencies, or bugs in an “in-scope” environment, supported server, or “in‐scope” software element licensed
by a Third Party to the State, the Contractor will assist the State by referring such incident to the appropriate Third
Party entity for resolution and coordinating with the Third-Party Contractor, as appropriate, to help minimize the
State role in problem management.
The Contractor will, to the extent possible, implement measures to help avoid unnecessary recurrence of
incidents, by performing root cause analysis and event correlation for items discovered during testing/validation
activities.
4.20.1 Project Incident Management

For purposes of this Supplement, an incident is defined as an unplanned interruption in a development or test
environment that is being used to perform application and IT service development. Incident management is the
process utilized for managing these to resolution. Project Incidents may be recognized by the development team,
detected and reported by event monitoring tools or communication from users involved in testing or data
governance activities where their work involves use of the Informatica Platform. From a project perspective,
objectives for this process include:
 Ensure that standardized methods and procedures are used for efficient and prompt response, analysis,
documentation and reporting of incidents
 Increase visibility and communication of incidents to IT support staff
 Utilize professional approach in quickly resolving and communicating incidents when they occur
The Contractor will be responsible for the following activities:
 Define a project incident management approach and process for the development and test environments used
for release development within the scope of this RFP
 Recommend and implement tools to perform project incident management
 Perform incident status tracking and reporting
4.20.2 Project Defect Management

From a project perspective, defect management is the process by which identified functional and technical
deficiencies in the release under development. Additionally, a project incident may be escalated to a defect if the
incident occurred as a result of software changes introduced to a development or test environment by work
performed by the project team. The three types of defects managed by the project development team include:
 Development Defects - These are confirmed defects discovered in development or testing environment
during related development, system, performance, assembly and UAT testing performed by the project team.
Identified defects are reviewed and assigned a severity and priority that determines what order the defects are
resolved. All severity 1 and 2 defects are resolved prior to the release under development being deployed to the
production environment. The business users may also prioritize defects discovered during system, performance

or UAT and indicate that the release under development may not be deployed to the production environment
until these are successfully fixed and retested.
 Warranty Support - These are confirmed defects discovered in the Production environment within the twelve
(12) month warranty support period. Correction of the identified defect may occur within the warranty support
period or slightly outside of the period consistent with established SLAs defined in Supplement 4 of this RFP. In
most cases, correction of warranty support defects are performed by the application development team and
deployed to production by the M&O team.
 Infrastructure Configuration Changes – Upon analysis and triage of an incident or problem report, the project
development team may discover that an Informatica platform or other configuration change is required to
correct the problem and that no changes to an Informatica object or source component are required to resolve
the problem. When this occurs, the change is treated as a configuration change and not a defect. These
changes are performed by the project development team for the impacted development or testing environment
or are coordinated with the State OIT team if the required change is to infrastructure not owned or maintained
by the project development team.
Defect management processes and tools will leverage those tools and techniques used by the application
development team. The Contractor is requested to provide recommendations regarding defect management tool
usage as part of the RFP response. All defects will be associated with the specific release that introduced the
unexpected behavior.
4.21 Deploy Phase Requirements (for each planned release)

A Test Completion Checkpoint must be successfully completed prior to beginning the Deploy phase. This includes
the State’s acceptance of all deliverables due to date per the project schedule.
The Contractor Team will support the deployment activities and will conduct a deployment readiness assessment
to determine the readiness of the organization and the solution for go-live. Part of the readiness review will be to
determine that the State has reviewed and accepted all functional, technical, and user documentation. Upon
completion of the readiness assessment, the State will make a final go-live decision. The go-live date will be
scheduled and resources, roles, and responsibilities will be confirmed.
Identify deployment readiness criteria, critical path, and contingency plan Support Perform
Assess deployment readiness Support Perform
Define stabilization approach and plan Support Perform
Verify Requirements Traceability Matrix Completeness Perform Support
Perform end user role-based security implementation design. Provide guidance and
Support Perform
recommendations regarding best practices and methods based upon business requirements
Define end user security mapping and assignments for new or altered functionality Perform Support
Create production deployment plan Support Perform
Create detailed task lists and work plans for deployment Support Perform
Create production deployment staffing schedule Support Perform
Create production deployment roles and responsibilities Support Perform
Perform Data Conversion/Migration and Remaining Data Cleansing Support Perform
Perform deployment activities Support Perform
Perform cutover activities Support Perform
Create Solution Run Book Support Perform
Coordinate Production Acceptance Checklist items for Deployment Perform Support
Deploy the Solution Support Perform

System Turnover Support Perform
The Contractor Team will drive the planning and execution for the system deployment activities. Deployment
includes coordination of software deployment to the file server elements, identification of interfaces and any
required conversions/migrations, installation and testing of any required middleware products, installation of
server software, and any required testing to achieve the proper roll‐out of the application software.
The Contractor Team will execute the deployment plan, which will describe the plan to manage the go-live. The
tasks and activities to be performed include the following:
 Execute required data conversions or migrations as applicable

 Perform required data matching activities and error reporting as applicable
 Document data issues and provide to the State for resolution as applicable
 Compile and maintain solution issue lists
 Produce an end-to-end final validation of the operational architecture and corresponding operational
documentation for the upgraded and implemented modules
 Conduct quality and progress reviews with appropriate State personnel
 Develop, and thereafter maintain and make available to the State, a knowledge base of documentation
gathered throughout the Project’s life and allow for re‐use of such within the State for future Project Phases or
upgrades
 Create solution run book
 Transition solution support responsibility according to the Deployment & Stabilization Plan. This transition
activity will include a series of solution support transition meetings and review of the solution run book
The production deployment schedule will be agreed upon mutually by the State and the Contractor.
Production migration activities will adhere to the State Production Acceptance Criteria (PAC) and will not be
considered for production migration until all such criteria are met or otherwise accepted by the State. Any
deviation, partial acceptance or waiver of requirements in the Production Acceptance Criteria must be agreed to
in writing by the State in advance of presentation of any deliverables associated with, or determined to be part of
these Production Acceptance Criteria.
Throughout the Project, Application and Tools patches and fixes will be reviewed. Patches will be applied until the
QA environment is established. After the QA environment is established and prior to Go-Live, any Application or
Tools related patches and fixes will be evaluated for implementation based on the criticality of the patch or fix.
4.22 Organization Change Management

Organization Change Management pertains to those activities and work products designed to assist the State
with adoption of Data Governance, Data Stewardship, Data Quality, and Enterprise MDM solution utilization. As
such, organization change management will cover those activities that require executive sponsorship and cross-
agency participation to support the effective implementation of an Enterprise MDM solution along with a strategy
that’s focused on helping individuals understand how to make the underlying process changes successfully.
While change happens one person at a time, processes and tools need to be developed to facilitate this change.
More specifically, the State seeks assistance from the Contractor in the following areas:
 Defining an Organization Change Vision
 Creating an Organizational Change Sponsorship Roadmap
 Creating and Executing an Organizational Change Strategy and Plan
 Performing Organizational Change Analysis
 Creating Organizational Change Communication Plans and Materials
 Creating Organizational Change Job-Aids and Training Materials
 Conducting Organizational Change training sessions.
The Contractor will perform or assist with the performance of the following:
Conduct Organization Change Vision Sessions Support Perform
Define an Organization Change Vision Support Perform
Create an Organizational Change Sponsorship Roadmap Support Perform
Socialize Organization Change Vision and Sponsorship Roadmap with Key State Personnel Support Perform
Create an Organization Change Management Strategy Support Perform
Create an Organization Change Management Plan Support Perform
Perform Organizational Change Analysis Support Perform
Create Organizational Change Specific Job-Aids and Training Materials Support Perform
Execute the Organizational Change Management Plan Perform Support
Conduct Organizational Change Training Sessions Support Perform
Measure Outcomes of Organizational Change Management activities and fine tune plan Support Perform
The Contractor will drive the planning, analysis and material development while the State will lead on the overall
execution of the organizational change management plan.
4.23 Knowledge Transfer and Production Handoff (for each planned release)
 The Contractor will perform knowledge transfer support to the State in keeping with State System Turnover
process, which will be made available to the Contractor at the commencement of the project to support
knowledge transfer to the State. In general, the System Turnover deliverable will include, at a minimum, the
following work products:
 Final Requirements Traceability Matrix for the Project as Implemented
 A list of all customizations and objects as implemented
 Detailed System Test Cases and Demonstration of Successful Completion of Same
 Detailed Performance Testing Results showing at least one high volume process (e.g., a Fiscal Quarter or Year
or Seasonal Processing as mutually agreed)
 Completion of State User Acceptance Testing and an affirmation of same by State
 Operational Readiness Testing Results and an affirmation of same by State
 Complete User and System Administration Documentation that represent the system as implemented
 Complete training and knowledge transfer to all Enterprise MDM users, upstream and downstream system
stakeholders

 Complete operational documentation sufficient for the State or the State’s managed service vendor to operate
and maintain the system in the State’s environments inclusive of Production, DR, Demo/Train and at least one
non-Production replica of the system as delivered
 Complete the Production Acceptance Checklist and conduct review meetings with the State Project Manager
and other State personnel as described in the System Turnover process
4.24 Project Completion Activities, Final Documentation and Post Implementation

Support Obligations
The warranty support period for each production release defined as a part of this RFP will be 12 months from the
production deployment date. If after ninety (90) days of successful execution (defined as no Severity 1 or 2
issues) by the Contractor in the State production environment, the Contractor shall be relieved of active
management of the release as contained herein. During the period, immediately following the introduction of the
Contractor provided enhancements, configurations or extensions to the State’s production environment the
Contractor must:
 Ensure adequate staffing from the Contractor Project Team is on hand (or available remotely) to ensure that
during this period all defects identified by the State and mutually committed to resolve by the Contractor in this
RFP or under any SOW are adhered to.
 This responsibility shall specifically include:
 Prompt isolation, triage and repair of any Severity 1 or 2 issues
 Performance Monitoring of the System to ensure that there are no statistically significant (i.e., +5%)
deviations from actual production performance as compared to the system performance prior to the
implementation of Contractor developed elements
 All interfaces, and system functions perform and function as specified
 Compile all final versions of the upgrade documentation, work products and delivery materials and locate /
organize them as ‘FINAL’ on the State provided SharePoint site
 Obtain a final acceptance document from the State and the Contractor confirming that all the above has been
delivered and accepted as final
If, during the warranty support period, the introduction to Production, a Severity 1 or 2 issue occurs that can be
directly attributable to the efforts of the Contractor, and not the State or other non-Project parties, the change will
be made within established SLAs as defined in Supplement 4.
4.25 Future Project Services Pricing Response and Rate Card

Contractors must provide a Project Rate Card, by project personnel role and experience level as well as
Technical role and experience level that is binding over the Contract term. Additionally, the Contractor is
requested to provide two blended rates. The first is a blended rate to be applied when estimating Project Change
Requests for project scope changes and Unanticipated Project Services. The second is a blended rate to be
applied when estimating Project Change Requests for additional data cleansing services These blended rates
along with the resource staffing that used as the basis of estimate when calculating each blended rate needs to
be provided as a part of the response to this RFP. The Contractor may not propose rates (blended or otherwise)

in any Project Service SOW that differs from these rate cards as allowed under any contract arising from this
RFP.
5.0 Schedule of Deliverables and Work Products

To support the execution of the Project and provide supporting follow-on documentation, the Contractor will create
and deliver to the State the following set of Deliverables, Work Products and Artifacts. The State Project Manager
will serve as the representative for coordinating respective internal reviews of the subject Deliverable(s) and Work
Products for sign off by the State. The Contractor should modify or propose other deliverables based on their
solution or methodology characteristics. Any differences proposed to the ones listed below should include an
explanation in the Contractor’s response.
5.1 Delivery and Deliverable Standards

 The Offeror will define, document and submit all standards they intend to utilize in the performance of this
project. Once the State approves these standards, variances to standards must be approved by the State prior
to implementation of other than standard practices.
 The Contractor’s work and deliverables will be in accordance with the Contractor’s standards (e.g., SDLC,
project management, etc.) that have been approved by the State
5.2 Schedule of Deliverables and Work Products

Artifact,
Work
Name Work Product and Deliverable Descriptions Phase
Product or
Deliverable #
WP-001 Project Execution This is a detailed description of their requirements gathering and analysis, Prioritization and
design, build, test, deploy and run methodologies the Contractor follows,
Methodology standards the Contractor intends to apply to this project, and any Scheduling
applicable tool sets. Contractor must address topics such as:
Resource Management
Configuration Management
Data Management
Organization Change Management
Development Methodology
Test Methodology
Training
WP-002 Project Work Plan Documents the tasks required to complete the Project, the responsible Prioritization and
party for the task, task dependencies, and the resources, duration and
work hours required. This plan should include key milestones and phases. Scheduling
The project work plan should be in an acceptable format for the State (e.g.,
MS Project). The Contractor’s project manager will work with the State’s
project manager to ensure an acceptable Project Workplan is completed
and accepted as baseline within 20 business days after the Kickoff
Meeting.
WP-003 Work Breakdown Structure This document is a hierarchical decomposition of the project into phases, Prioritization and
deliverables and work packages. In the work breakdown structure supplied,
(WBS) sufficient detail needs to be presented and maintained over the course of Scheduling
the project to track the earned value against the proposed costs and work
efforts. This WBS will be reflected in the Project Workplan.

Artifact,
Work
Product or
Deliverable #
WP-004 Resource Plan The resource plan must specify resources required, by type, over the Prioritization and
duration of the project. Contractor must identify all required resources
(Contractor, State or otherwise) to complete the project, except where Scheduling
otherwise specified in this document, and include all costs for those
resources that are to be provided by the Contractor. Sample roles should
be inclusive of Developers, Business Analyst, Administrator, Security
Analyst, Database Administrator, or any other roles deemed necessary by
the Contractor. The Contractor will specify the percent of time each
resource will perform their role on State premises.
WP-005 Organization Structure This is an org structure reflecting a high-level org structure that Prioritization and
incorporates both Contractor and State resources. Roles to address may
include any of the following: Scheduling
 Sponsors and Stakeholders
 Project Management
 Quality Assurance
 Team Structure and Leads
WP-006 Phasing Strategy/ Documents the recommended phasing strategy and deliverables by project Prioritization and
phase for each project or release in the scope of this RFP.
Deliverables by Phase Scheduling
WP-007 Detailed Cost/Time Financial analysis of costs associated with completing the individual project Prioritization and
within the scope of this RFP along with the time analysis as documented in
Analysis the project plan. Scheduling
WP-008 Project Management Plan This document must explain the approaches used for the following: Prioritization and
 Scope Management
Scheduling
 Change Management (including required communications,
escalation path and approvals)
 Issue Management
 Risk Management
 Communication Management
 Stakeholder Management
 Status Reporting
 Project Workplan Management
 Project SLAs, SLOs, and Metric Reporting
 Project Budget /Actual Analysis
WP-009 Requirements This document explains the approaches and techniques used to elicit Prioritization and
requirements, document requirements and obtain business and technical
Management Plan approval of the requirements. This document also contains specifics Scheduling
regarding how requirements management tools will be used to document
requirements as well as how the requirements traceability matrix will be
generated ad maintained.
WP-010 Project Charter A statement of the scope, outlines the project objectives, constraints, key Prioritization and
business drivers and benefits, reviews major items that are in and out of
scope, identifies the main stakeholders, discusses major business and Scheduling
technical risks that may be encountered during project execution, proposed
budget and spend authority, high level project release planning and key
milestone dates, and defines the authority of the project manager. It
provides a preliminary delineation of roles and responsibilities of those
involved in the project. The project charter also serves as a reference of
authority and focal point throughout the project. It represents a baseline for
the overall project definition and may be used in both team meetings and in
change management discussions to assist with scope management. This
deliverable also contains the Project Management Plan and Requirements
Management Plan work products.
WP-011 Kickoff Meeting Deck Documents the governance for the Project, roles, approach, timeline, and Prioritization and
deliverables in a presentation format to be presented to the Project team. Scheduling
DEL-001 Project Plan, Charter & Contains all planning work products including Project Execution Prioritization and
Methodology, Project Work Plan and Work Breakdown Structure (WBS),
Kick-Off Package Resource Plan, Organization Structure, Phasing Strategy and Deliverables Scheduling
by Phase, Detailed Cost and Time Analysis, Project Management Plan,
Artifact,
Work
Product or
Deliverable #
Requirements Management Plan, Project Charter, and Project Kick-Off

meeting deck and supporting materials.
WP-012 Current Technical Evaluates the current infrastructure, technologies, versions and Current
configuration specifics that are in used for the currently deployed and upon
Environment Document which existing Master Client Index (MCI) and Master Provider Index (MPI) Environment
solutions are implemented. Assessment
WP-013 Current MCI Documents and evaluates the current MCI implementation and identifies Current
opportunities for improvement.
Implementation Environment
Assessment Assessment
WP-014 Current MPI Documents and evaluates the current MPI implementation and identifies Current
opportunities for improvement.
Implementation Environment
Assessment Assessment
WP-015 Future State MDM Solution Documents future state MDM framework and solution architecture Current
alternatives and recommends solution(s) for the State to consider with the
Recommendations implementation projects within the scope of this RFP. Environment
Assessment
DEL-002 Current Environment Contains all current environment assessment work products including Current
Current Technical Environment (Informatica Platform) document, Current
Architectural Assessment MCI Implementation Assessment, Current MPI Implementation Environment
Assessment, and Future State Enterprise MDM Solution Assessment
Recommendations.
WP-016 MDM Key Performance This document defines master data management related key performance Data
indicators and their calculations that were identified as part of the data
Indicators stewardship strategy work performed. These definitions will be used to Management
implement master data management related dashboards and reports.
WP-017 MDM Dashboards and This document defines requirements and functional design for dashboards Data
and reports to be generated and used for MDM development and MDM
Reports operational management. Management
DEL-003 Data Governance Strategy This document defines the Data Governance Strategy and Framework to Data
be used in managing the data domains within this scope of this RFP. The
and Framework framework will be defined in such a manner that it can be readily extended Management
for other data domains in the future. This strategy and framework shall
describe (at a minimum):
 Data Governance Charter, Vision and Mission Statement
 Data Governance Organization Structure, Roles and
Responsibilities
 Data Governance Goals, Governance Metrics, Success
Measures and Funding Strategies
 Data Governance Intake Process
 Proactive, Reactive and Ongoing Data Governance Processes
 Decision Rights, Accountabilities and Controls
 Data Governance Maturity Model and Roadmap
 Participation and Integration points with project development
teams
 Monitoring and Reporting processes
 Privacy, Security, and Regulatory Compliance Approach and
Coordination
WP-018 Metadata Management These documents define processes and procedures to be followed to Data
request, review and approve changes to the Business and Technical
Policies, Procedures & metadata to ensure accuracy. These processes and procedures will Management
Guidelines support both real-time and batch data changes. Procedures will also be
developed that provide step-by-step instructions on how to export data
from either the Informatica Business Glossary or Metadata Manager and
distribute to others for review.

Artifact,
Work
Product or
Deliverable #
DEL-004 Metadata Management This document defines a strategy that ensures that Business Glossary and Data
Metadata Manager are updated with Source and Target “current state” and
Strategy and Approach “future state” business and technical metadata. Management
WP-019 Data Quality Policies, These documents define discrete data quality policies and procedures that Data
further elaborate the data quality management strategy transforming
Standards, Procedures, strategic concepts into actionable steps that the data stewards may use (or Management
and Tools direct others to use) to resolve identified data quality issues. This work
product also includes tools that may be used to either automate or make
the data profiling and related analysis work easier to perform.
WP-020 Data Cleansing Approach This document defines data cleansing approaches to be used on the Data
project and tools that will be developed or leveraged as part of data
and Tools cleansing effort. Management
DEL-005 Data Quality Management This document will define a strategy that ensure the quality and integrity of Data
Strategy and Approach data loaded into the Enterprise MDM architecture and establish a Management
plan/approach to proactively monitor the data once it is loaded. More
specifically this strategy will outline:
 Summarize results of data profiling efforts to analyze and make
recommendations for global data standards, match rules, merge
rules, and unmerge rules.
 Define approach for developing a reusable data quality rules
engine to automate data standardization and cleansing.
 Define approach to identify and document data quality issues
and approach to be used to establish and execute a quality
remediation plan for both impacted source systems and the
Enterprise MDM.
Define approach to identify missing data and establish a data enrichment
plan by the assigned data steward.
WP-021 Functional Requirements Define and further elaborate the State’s original functional and data Analyze
requirements and the rationale for changes to these. These requirements
should be to a level of detail such that ambiguity is removed and that they
support the development of functional and technical specifications. The
data requirements are also captured in a Business Glossary.
WP-022 Technical Requirements All recommended changes to the State’s original technical requirements Analyze
and rationale for the changes. These requirements should be elaborated
upon as required to support the development of the technical specification
and design.
WP-023 Data Requirements/ Data requirements are those data elements that correctly represent the Analyze
data domain within the scope of the project. When elaborating data
Business Glossary requirements, the logical organization and relationships between data
entities and attributes are analyzed. Additionally, business relevant to data
capture and transformation are also identified. Data requirements are a
prerequisite to measure data quality. From a business perspective, data
requirements are captured in a business glossary that’s used to
communicate and govern the organization’s business concepts,
terminology, definitions, and relationships between terms (glossary data
elements).
WP-024 Non-Functional A requirement that specifies criteria that can be used to judge the operation Analyze
of a system, or a quality attribute of the system rather than specific
Requirements behaviors.
WP-025 Non-Functional Review and evaluate the State’s original non-functional requirements and Analyze
make recommendations for changes and/or perform additional elaboration
Requirements Assessment of these requirements to fully define quality and other measurement
considerations.
WP-026 Business Rule Definition A rule that defines, describes or constrains some aspect of business Analyze
operational processes or data and always resolves to either true or false.
Business rules are intended to assert business structure or to control or
influence the behavior of the business. These rules may apply to people,

Artifact,
Work
Product or
Deliverable #
processes, corporate behavior and computing systems in an organization,

and are put in place to help the organization achieve its goals.
WP-027 Data Quality Scorecard This document defines requirements and high-level design for a data Analyze
Requirements quality scorecard. The scorecard will be used to manage overall data
quality of the data domain within scope of the project.
WP-028 Report Requirements Necessary information required by a department, organization, or Analyze

governmental body that is organized in a specific format and generated
either on-demand or within a certain period of time to a defined schedule.
Data contained in these reports are captured as data requirements.
WP-029 Process Flows Illustrate and document future state business process flows, highlighting Analyze
both user interaction by role and key integration points as well as internal
controls.
WP-030 Process Change Model This document identifies business processes impacted by the data domain Analyze
and State Agencies within the scope of the project and how these
processes may be changed or enhanced to improve overall data quality
and confidence levels in the future state solution in scope.
WP-031 Business Process This document defines new, future state business processes that will be Analyze
Definition implemented either within the scope of the project or in parallel with the
project.
WP-032 Requirement and Process Documents the results of the requirement and business process analysis Analyze
and workshop sessions in spreadsheet format, specifically:
Verification All recommended changes to the State’s original functional requirements
and State processes and rationale for the changes.
For each business process gap analyzed, list the functional requirement,
standard functionality of the appropriate component of the solution, options
to meet the requirement and recommendation
WP-033 Requirements Traceability Lists the requirements for the processes which will be designed and/or built Analyze &
and subsequently tested and deployed. This deliverable will be revised and
Matrix updated and will be due at each phase check point or as defined in the Updated at end
agreed upon project work plan. of each
subsequent
phase
DEL-006 Requirements Definition This document is a compilation of the following documents or work Analyze
products:
 Functional Requirements
 Technical Requirements
 Data Requirements
 Non-Functional Requirements
 Non-Functional Requirement Assessment
 Business Rule Definitions
 Data Quality Scorecard Requirements
 Report Requirements
 Process Flows
 Process Change Model
 Business Process Definition
 Requirements and Process Verification
 Requirements Traceability Matrix
WP-034 Level 0 System Design This document defines the level zero context data flow diagram (DFD) with Analyze
system and descriptive information regarding each integration point
contained within the diagram.
WP-035 Solution Architecture This document and supporting charts define a roadmap of the project for Analyze
Implementation Roadmap the data domains and agencies within its scope.
WP-036 MDM Architecture Documents the architectural design of the MDM framework to be Analyze
Framework implemented to support the data domains within the scope of the project.

Artifact,
Work
Product or
Deliverable #
WP-037 Business Architecture This document defines the blueprint of the Enterprise MDM solution project Analyze
to provide a common understanding of the State and agencies within
scope. Aligns strategic objectives of the initiative to tactical data domain
management and governance. Additional artifacts incorporated in this
document include Business Process Model, Class Models, and Use Case
Models.
WP-038 Logical Infrastructure This document and associated diagrams defines the future state logical Analyze
Architecture infrastructure landscape comprised of hardware, software, and
infrastructure component relationships and primary end-to-end data flow
between the respective components. The analysis contained in this
document supports functional, data, technical and non-functional
requirements as well as MDM Architectural Framework considerations.
WP-039 Logical Data Architecture This document and its supporting logical data models and related artifacts Analyze
defines the target data architecture that enables the defined business
architecture and architectural vision. It also identifies candidate architecture
roadmap components based upon gaps between the baseline and target
data architectures. Additionally, the data architecture defines:
 How data entities are utilized by business functions, processes
and services
 How and where enterprise data entities are created, stored,
transported and reported
 Data transformations and complexity to support information
exchange between applications
 Supporting data integration requirements
 Data definitions, models, and other related metadata
WP-040 Logical Integration This document defines the logical integration architecture and associated Analyze
artifacts which elaborates the integration approaches, methods,
Architecture
techniques, and communication protocols to ensure that data moves from
one application to another. May also specify or design common component
development, templates, and code snippets to consistently implement data
integration between the Enterprise MDM data hub or supporting hub and
the agency specific applications that utilize the data.
WP-041 Logical Enterprise Update logical enterprise architecture diagrams to reflect changes covered Analyze
Architecture under other solution and architecture design documents that are within the
scope of this RFP.
DEL-007 Solution Architecture This document defines the application architecture that is to be used during Analyze
the project and contains the solution architecture (logical and physical).
This architecture must show all components and how various systems
interrelate, including the external technical environment the solution will
operate within.
DEL-008 Data Quality Remediation This document defines data domain specific remediation activities and Analyze
Plan approaches to be used during the project. This plan leverages and
expands upon data quality strategy, policies, procedures, and guidelines
defined from an overall data management perspective.
WP-042 Implementation Strategy This document defines the implementation strategy and approach specific Analyze
to the data domains within the scope of the individual project or release.
WP-043 Deployment Strategy This document defines the deployment strategy and approach that will be Analyze
used to perform data cleansing and conversion as well as cover other
summary level deployment considerations.
WP-044 Knowledge Transfer Plan A plan defining the activities and roles required to perform knowledge Analyze
transfer of the operations and support of the solution.

Artifact,
Work
Product or
Deliverable #
DEL-009 Implementation & Consolidation of Implementation and Deployment Strategies and Analyze
Deployment Strategy approaches that will be used to perform data cleansing and conversion as
well as to implement the data domain artifacts under development for a
specific release. This deliverable also includes planned knowledge transfer
activities that will be deployed as part of the software implementation and
data conversion process.
WP-045 Technical Environments The identification of all technical environments and the associated Analyze
Requirements requirements, inclusive of all technical environments to be used for the
project from the Build Phase through Test, Deploy and Run.
WP-046 Infrastructure Migration Identifies the activities and tasks to be executed to complete migration of Anayze
Plan MDM infrastructure to the new set of target development and testing
environments. This deliverable also defines the configuration and use of
each environment and product within the Informatica platform and also
incorporates the Technical Environments Requirements work product.
WP-047 Performance Requirements Defines performance requirements for the solution under design. These Analyze
requirements are usually defined as a part of the capacity planning process
that’s performed during the design phase of the project. At a minimum,
performance requirements include the following:
 Maximum satisfactory response time for each distinct type of
user-computer interaction or system-to-system interaction either
through batch processing or web services during peak
processing periods.
 Response time that’s minimally acceptable the rest of the time.
 Typical throughput required and the times that this throughput
will be taking place.
 Size and timing of maximum throughput periods.
 Mixture of requests expected and how the mix varies with time.
 Total number of users and anticipated concurrent system usage.
 Assumptions regarding process performance, total workload, or
other related considerations.
WP-048 System Sizing Define CPU, memory, local storage and network storage requirements for Analyze
each development and test environment as well as for Production and
Requirements Disaster Recovery environments.
DEL-010 Capacity Plan This plan consolidates the Capacity Plan, Technical Environments Analyze
Requirements and Infrastructure Migration Plan. More specifically, the
Capacity planning components of this deliverable includes the results of the
process of determining the operational capacity the solution needs to
achieve to satisfy the business process demands of the system as well as
the number of environments required to complete development, testing,
data migration and conversion activities. It should include planning through
the accomplishment of the State’s long-term goal of the solution supporting
all identity Management within the State, including sub recipient
management, sub recipient needs, etc. This document(s) specifies by
phase and system the sizing, CPU, and memory requirements.
WP-049 Checkpoint Report – Documents any difference in the Project scope, schedule, and/or resources Analyze
Analyze at or before the end of the Analyze Phase. The focus of this deliverable will
be on the scope of the solution. Also, indicates any deliverables which
have not been accepted by the State per the Workplan.
WP-050 Physical Infrastructure This document and associated diagrams further elaborates and evolves the Design
Architecture future state logical infrastructure architecture diagrams into the future state
physical infrastructure landscape comprised of hardware, software, and
infrastructure component relationships and primary end-to-end data flow
between the respective components. The analysis contained in this
document supports functional, data, technical and non-functional
requirements as well as MDM Architectural Framework considerations.

Artifact,
Work
Product or
Deliverable #
WP-051 Physical Data Architecture This document and its supporting data models and related artifacts further Design
elaborates the logical data architecture and related models developed
during the Analyze phase into the target logical and physical data
architecture that enables the defined business architecture and
architectural vision. Additionally, the data architecture defines:
 How data entities are utilized by business functions, processes
and services
 How and where enterprise data entities are created, stored,
transported and reported
 Data transformations and complexity to support information
exchange between applications
 Supporting data integration requirements
 Data definitions, models, and other related metadata
WP-052 Physical Integration This document further elaborates the logical integration architecture into Design
the physical integration architecture and associated artifacts which
Architecture elaborates the integration approaches, methods, techniques, and
communication protocols to ensure that data moves from one application to
another. May also specify or design common component development,
templates, and code snippets to consistently implement data integration
between the Enterprise MDM data hub or supporting hub and the agency
specific applications that utilize the data.
WP-053 Enterprise Architecture Update physical enterprise architecture diagrams to reflect changes Design
covered under other solution and architecture design documents that are
within the scope of this RFP.
WP-054 Technical Data Dictionary Captures business and technical metadata information about business data Design
within scope of a particular data domain. This information includes
standard definitions of data elements, their meanings, and allowable
values. It provides more detail about each attribute within the data domain
that will be used in both logical and physical data mapping, functional and
technical design and during development and data conversion/migration
activities.
WP-055 Logical and Physical Data A logical data model represents the data architecture of a specific business Design
Models data domain, including relationships between data in a graphical way
without regard to the physical implementation or the database
management system technology involved in storing the data. A physical
data model or database schema is a representation of a data design of a
specific business data domain as it is intended to be implemented within
the target database management system. Typically, the physical data
model is derived from a logical data model, however, is may be reverse-
engineered from a given database implementation.
DEL-011 Updated Solution This document incorporates updates to the Solution Architecture Design
Architecture deliverable created during the Analyze phase to incorporate updates to the
application architecture that is to be used during the project and contains
the solution architecture (logical and physical components).
DEL-012 Functional Design Functional design of the solution. Includes the Systems Requirements Design
Document Document: systems specifications and functional requirements including
reliability, performance, operations, usability, maintainability and functional
specifications for any interfaces to external systems.
WP-056 Interface Control Document An Interface Control Document (ICD) clearly describes all possible inputs Design
and outputs of a single system for all potential actions whether they are
internal to the system or transparent to the system users. The ICD may
describe the interface between two systems or the interface protocol
between two physical components. The level of detail included in any ICD
is dependent upon the requirements of the stakeholders to successfully
deliver on project requirements. ICDs define for the development team
system inputs, outputs, internal interfaces, and interfaces between other

Artifact,
Work
Product or
Deliverable #
systems, subsystems and/or users. An ICD should only describe the

interface itself and not any characteristics of the systems using it.
DEL-013 Technical Design Documents the technical specifications for the solution to include: Design
Data definitions, identifying any new data elements and classifying new
Document data to be added to the list of confidential and sensitive data.
Unit Test scripts – including both normal and exception processing
Changes to technical architecture
Interfaces to external systems
Any customizations if applicable.
Data Migration from external systems at deployment, if applicable.
Master Data Model
Metadata Model
Data Validation Rules
Data Control Rules
ETL Rules (Source, Transformation and Target)
DEL-014 Security Design Documents the details of the approach that will be followed to meet the Design
identified security requirements of the Sate.
DEL-015 Technology Environments Establish the Technology Environments for Development and Testing Design
for Development and Test
DEL-016 Data Conversion/ Migration The Data Conversion Plan (DCP) describes the strategies involved in the Design
preparation, specifications for converting data from existing source
Plan system(s) to the target system, and related data cleansing activities that
will be performed as part of the data conversion process. More specifically,
the DCP includes the following:
 Overall Approach and Assumptions
 Data Conversion Processes
 Inventory and cross reference of Source and Target Data
Elements, Schema, Metadata and all Self-Describing files
 Specific Processes for Data Extraction, Transformation and
Loading for each data source
 Definition of tools needed to execute the data conversion
 Data Cleansing processes to be performed, as required, during
Data Conversion
 Strategy and Processes for Data Quality Assurance and Control
WP-057 Master Test Plan This document the plan, scripts (including expected results) and schedule Design
required to execute the various tests phases, including but not limited to
System Test, User Acceptance Test, and Performance Test. This
deliverable also includes individual test plans for each of these test types.
WP-058 Test Analysis Report Records results of the tests, presents the capabilities and deficiencies for Design
review, and provides a means of assessing software progression to the
next stage of development or testing.
WP-059 QA Metrics Definition Identify and define QA Metrics that will be used during the development Design
and testing phases of the project. These metrics will provide the project
leadership team with measurements and supporting information regarding
the current quality state of the project. Types of QA metrics may include:
 Requirements Traceability with Test Case Coverage
 Test Case Execution
 Test Case Pass Rate
 Defect Metrics (Total Outstanding Defects by Severity, Days
Open, and Trend Analysis)
DEL-017 Test Strategy Defines the test types and activities that will be performed during the Design
development and testing phases of the project. It outlines the key issues
and activities to be performed during the testing process and describes the
testing environments and risks that are mitigated by testing. More
specifically, the test strategy includes the following:

Artifact,
Work
Product or
Deliverable #
 Test Rounds or Levels (e.g., Unit Testing, Integration Testing,

System Testing, Performance Testing, and User Acceptance
Testing)
 Testing resources and their roles and responsibilities
 Testing Environment Requirements
 Testing Tools
 Defect Tracking Procedures
 Test Approach
 Test Environment Plan
 Test Schedule
 Test Priorities
 Test Status Collection and Reporting
 Test Record Maintenance
WP-060 Stakeholder Project communications targeted towards specific stakeholder groups that Design
will be used during design, development, testing, data conversion, and
Communication Materials production deployment activities.
WP-061 Checkpoint Report – Documents any difference in the Project scope, schedule, and/or resources Design
at or before the end of the Design Phase. The focus of this deliverable will
Design be on the scope of the solution. Also, indicates any deliverables which
have not been accepted by the State per the Workplan.
WP-062 Software Development The Software Development Plan (SDP) describes a developer’s plans for Build
conducting a software development effort. The SDP describes
Plan development platform usage (e.g., Informatica Platform) and defines how
monitoring will be performed during software development. It also details
methods to be used and approach to be followed for each activity,
organization, and resources. It should reference specific standards,
methods, tools, actions, reuse strategy, and responsibility associated with
the development and qualification of all requirements.
WP-063 Build and Unit Test Results Provide build documentation (i.e., changes to code) as a result of unit tests Build
conducted during the Build phase. These results also include QA metrics
and trend analysis.
WP-064 Component Test Results These documents are the presentation of the results from component level Build
testing inclusive of substantiation of Contractor testing of all elements as
required by the State and contained in the requirements traceability matrix.
WP-065 Solution Component Code, Technical explanation on developed source code, components, and Build
configuration that enables application support or maintenance developers
Objects, and Configuration to maintain the source code. Conceptual and architectural information as
Technical Documentation well as other input is incorporated as a part of this documentation so that
the developer may put the information in context. This documentation will
be used during knowledge transfer activities from the development (build)
team to the maintenance and operations (M&O) team.
DEL-018 Solution Component Code, Creation of Source Code, Objects, and Informatica specific objects and Build
configuration to implement defined functional, non-functional, and data
Objects, and Configuration requirements. This deliverable also includes build and unit test results,
component test results and solution component code, objects, and
configuration technical documentation.
DEL-019 Test Scripts and Cases A test case is a set of conditions or variables under which a tester will Build
determine whether a system or function under test satisfies requirements
or works as designed (consistent with defined requirements). Similarly, a
test script represents a set of instructions that will be performed on the
system or function under test to verify whether the system functions are
working as designed. These may be executed manually or by using an
automated testing tool. Definition of these cases or scripts include user ID
access restrictions, step-by-step instructions on how to execute the case or
script as well as the expected results of each step.
DEL-020 Operational Performance The Operational Performance Baseline is a grouping of performance Build
benchmarks of standardized performance measurements of overall system
Baseline performance of the system under test as well as critical functional
performance. These benchmarks will include performance measurements
for varying volumes and concurrent user levels and will be used during

Artifact,
Work
Product or
Deliverable #
performance testing activities to evaluate whether performance tests pass

or fail.
WP-066 Checkpoint – Test Documents any difference in the Project scope, schedule, and/or resources Build
at or before the end of the Design Phase. This checkpoint report will focus
Readiness Review on the readiness for entering the test phase. Also, indicates any
deliverables which have not been accepted by the State per the Workplan.
WP-067 System Test Results These documents are the presentation of the results from a particular Test
testing Phase inclusive of substantiation of Contractor testing of all
elements as required by the State and contained in the requirements
traceability matrix.
WP-068 Defect List A listing of all software defects in a build of the system under test as of a Test
point in time. The list contains the number, title, brief description of the
defect, severity, priority, date identified and date resolved. A defect is a
condition in a software product which does not meet a software
requirement (as stated in the requirement specifications) or end-user
expectations (which may not be specified but are reasonable). In other
words, a defect is an error in coding or logic that causes a program to
malfunction or to produce incorrect/unexpected results. The list provides a
consolidated means of tracking and reporting on defects while they are
being resolved.
DEL-021 System Test Results A report that recaps the results of system integration testing. The test Test
report includes the following:
Report
 Name and email address of the tester
 Date and time when the test was performed
 Scope of test, e. g. for component API testing the name and
version of the service component and the part of the API, Web
Service or Batch Processing that has been tested
 Test environment including operating system and type of test
client, e. g. programming language and XML-RPC library used
for component API testing, or Web browser used for GUI testing
 Test plan, i.e. the list of test cases giving method/use case and
input parameters used
 Test log listing the outcome of the test case executions (manual
testing or automated testing via scripts)
 Summary of test results
 Identified defects and status of defect resolution
 Recommendation for action when errors had been encountered
This deliverable also includes test readiness review, system test results,
and defects lists.
DEL-022 Performance Test Results These documents are the presentation of the results from performance Test
testing measuring actual performance results against established
Report performance requirement baseline for a given process or function.
Performance testing results contain all performance testing inclusive of
substantiation of Contractor testing of all elements as required by the State
and contained in the requirements traceability matrix.
WP-069 Checkpoint – Test This checkpoint report will focus on the readiness for exiting the test phase Test
and entering the UAT. Also, indicates any deliverables which have not
Completion Report been accepted by the State per the Workplan.
WP-070 System Procedures Step-by-Step instructions on how to perform a given system procedure. Test
These procedures may be accumulated and included in an end user
training guide or in system operational documentation or an operational
runbook.
DEL-023 System Operational A compilation of routine procedures and operations that the system Test
administrator or operator carries out. These procedures may be assembled
Documentation in a runbook. They include procedures for every anticipated scenario, and
generally use step-by-step decision trees to determine an effective
response to a scenario.
WP-071 User Job Aid Document A document or instruction cards, memory joggers, or wall charts, which Test
allows an individual to quickly access the information that he or she needs
to perform a task. It contains step-by-step instructions to complete the task
being described.
Artifact,
Work
Product or
Deliverable #
WP-072 Training Scripts Step-by-Step instructions regarding processes and procedures to be Test
addressed as part of a training class or session to a target audience. These
scripts are written specifically for the audience who will be receiving the
corresponding training.
WP-073 Training Guide A training guide or manual is a book or booklet of instructions, designed to Test
educate a target audience on functionality of the system. There may be
guides or manuals that are written for an IT audience versus various levels
or types of business users.
DEL-024 Training Materials Consolidated deliverable that consists of User Job Aid documents, training Test
scripts and training guides used to provide business users with necessary
system or other job related information as it pertains to the project.
WP-074 UAT Test Plan The UAT test plan outlines the strategy that will be used to verify and Test
ensure an application meets its business requirements. It documents entry
and exit criteria for UAT, Test scenarios and test cases approach and
timelines of testing. The UAT test plan is developed by business SMEs,
Data Stewards, and other Data Governance representatives.
WP-075 UAT Test Scripts and An UAT test case or script is a set of conditions or variables under which Test
the Business SME, Data Steward, or other Data Governance
Cases representative will use to determine whether a system or function under
test satisfies requirements or works as designed (consistent with defined
requirements). Definition of these cases or scripts will be performed by the
business and will include user ID access restrictions, step-by-step
instructions on how to execute the case or script as well as the expected
results of each step. Successful execution of these scripts and cases will
serve as the foundation upon which the system is “accepted” for production
deployment.
WP-076 User Acceptance Test These documents are the presentation of the results based on the State’s Test
completion of acceptance testing of the Contractor developed upgrade
Results elements. The Contractor will facilitate this deliverable and include
identification, classification (i.e., Severity 1-3), and the prioritization of fixing
all defects based on State UAT efforts. These results also include defect
lists, prioritized defects, and defect remediation plans and level of effort
estimates to resolve
DEL-025 UAT Test Results Report Consolidates the UAT testing results, published defect list, prioritized Test
defects and remediation plans for open defects at the end of the UAT test
cycle.
DEL-026 Data Quality Scorecard Dashboard that calculates and displays key performance indicators for the Test
release under development. This deliverable is both the actual
implementation of the score card and its results for the release under test.
DEL-027 Operational Readiness Operational acceptance testing (OAT) is used to conduct operational Test
readiness (pre-release) of a product, service, or system as part of a quality
Test Results management system. OAT is a common type of non-functional software
testing, used mainly in software development and software maintenance
projects. The report recaps the results of operational testing and makes a
recommendation on the application’s readiness to be deployed to
production.
WP-077 Checkpoint – UAT Test This checkpoint report will focus on the readiness for exiting the UAT and Test
entering the Deploy Phase. Also, indicates any deliverables which have not
Completion Report been accepted by the State per the Workplan.
WP-078 Version/Release Document The Version Description Document (VDD) is the primary configuration Deploy
control document used to track and control versions of software to be
released to the operational environment. It is a summary of the features
and contents for the software build. It identifies and describes the version
of the software being delivered to the State, including all changes to the
software since the last VDD was issued. Every unique release of the
software (including the initial release) shall be described by a VDD.
WP-079 Deployment Approach Detailed approach and plan for cutover activities for transitioning the in- Deploy
scope processes into production. Includes:
 Deployment preparation
 Cutover planning
 Stabilization planning for Post Go-Live support
Artifact,
Work
Product or
Deliverable #
DEL-028 Deployment & Stabilization The plan will cover the timeframe before Go-Live and after Go-Live. This Deploy
document must identify the series of tasks to be performed in the
Plan appropriate sequence to ensure production readiness. This plan must also
explain the approach for business continuity during and after cutover.
The plans will detail the following for each task:
 Task name
 Owner
 Target date for completion
 Critical path indicator
 The type of tasks will include:
 Knowledge transfer/training tasks
 Operational cutover tasks (i.e., converting data, etc.)
 Publish revised policies and procedures
 Technical Architecture tasks including readiness, mock
deployments and production cutover
 Post Go-Live support tasks
 Approach for the project team to hand-over long term support to
the run support team
DEL-029 Business Contingency/ Defines instructions and procedures that enables the State to respond to Deploy
accidents, disasters, emergencies, and/or threats without any stoppage or
Continuity Plan hindrance in its operations with respect to the Enterprise MDM solution. A
subset of activities within the Business Continuity Plan are actions specific
for disaster recovery.
WP-080 Job Schedule Definition A document that defines each job that needs to be run in a batch mode (or Deploy
intraday processing), its parameters, other job dependencies and the
general time frame that the job needs to be executed. Also, included in the
definition are actions to be taken should the job not execute successfully to
completion.
WP-081 SLA Definitions and Review Service Level Objectives (SLO) and Service Level Agreements Deploy
(SLA) that pertain to maintenance and operations (M&O) as defined in
Parameters Supplement 4 of this RFP. Verify calculations, parameters, and
measurements for each SLO and SLA and adjust, as required, to achieve
the correct measurement for production monitoring purposes.
WP-082 Release Checklist This list contains items that need to be completed prior to the software Deploy
application being released to production. The list contains the name of the
individual responsible for the item, estimated time to complete and planned
completion date.
WP-083 Release Verification The list contains items that need to be performed to verify that the release Deploy
has been successfully deployed into another environment. For deployment
Checklist purposes, this checklist is focused on deployment to production.
WP-084 Audit Impact Statement Statement that summarizes that all security, privacy, and regulatory Deploy
requirements have been satisfied by the project. Refer to Supplement 2 of
this RFP for a discussion of these requirements and standards.
DEL-030 Release Implementation A consolidation of the job schedule definition, SLA definitions and Deploy
parameters, release checklist, release verification check list, audit impact
Plan statement, and other release implementation plan specifics that outline
activities and tasks to complete deployment of the release under
development into production.
WP-085 System Deployed This is the completed production implementation of the release under Deploy
development that has been reviewed and approved by the State.
WP-086 Development Playbook A book that contains strategies for requirements, conceptual architecture Deploy
alternatives, design (including design patterns), code snippets, test plans
and cases to enable consistent implementation or onboarding of new
agencies to the Enterprise MDM solution as well as new source and target
systems. The focus of this deliverable is to make future common
development efforts repeatable.
DEL-031 System Turnover Transition solution support responsibility per the Deployment & Deploy
Stabilization Plan. This includes Knowledge Transfer Activities per the
Knowledge Transfer Plan. This also includes the system deployed and the
development playbook.
Artifact,
Work
Product or
Deliverable #
WP-087 Organizational Change This document defines the common vision for organization change Organization
Vision management activities to be performed in support of the project. Change
Management
WP-088 Organizational Change This document defines the organizational change sponsorship roadmap Organization
Sponsorship Roadmap and how each stakeholder or sponsor will be engaged to support required Change
organizational change to support long-term maintenance and operation of Management
the data domains and agencies within the scope of the Enterprise MDM
project.
DEL-032 Organization Change This is a consolidated deliverable that contains the Organization Change Organization
Strategy and Plan Vision and Sponsorship Roadmap as well as additional information that Change
further defines the organization change strategy and planning Management
considerations.
WP-089 Organizational Change This document recaps the change analysis investigation performed to Organization
Analysis support the vision and roadmap to make the actions defines within these Change
two documents tangible in terms of specific organizational changes that will Management
need to be made within an agency or with functions performed by workers
using a specific application system that integrates with the MDM solution.
Change analysis will also include required process change for data
stewards to perform their work on projects and operationally in a
meaningful, effective manner.
WP-090 Organization Change Defines the communication types, frequency, format, and audience for Organization
Communication Plan each organization change specific communication to support the defined Change
vision and roadmap Management
DEL-033 Organization Change Job- These documents are job-aids and training materials specific to Organization
Aids and Training Materials organizational and individual change required to support master data Change
management, data governance, and data stewardship processes that are Management
not addressed in job-aids and training materials developed for a specific
project within the Enterprise MDM initiative.
A-001 Incident Report A form, or screen, containing details of Incidents involving any component Project Incident
of an IT Infrastructure or any aspect of the IT Service. Incident reports may
come from a variety of sources and will usually result in the creation of an Management
Incident record.
A-002 Defect Report Detail description of the identified software problem in clear, unambiguous Project Defect
language, along with the required steps to reproduce the error or defect.
Any logs that further describe the defect are attached or included as a part Management
of the defect report. This information allows for the developer to replicate
the defect so that the code and/or configuration may be fixed and deployed
to production.
6.0 State Staffing Requirements

The State will provide oversight for the Project, but the Contractor must provide overall Project management for
the tasks under this Contract, including the day-to-day management of its staff. The Contractor also must assist
the State with coordinating assignments for State staff, if any, involved in the Project. Additionally, the Contractor
must provide all administrative support for its staff and activities. Throughout the Project effort, the Contractor
must employ ongoing management techniques to ensure a comprehensive Project Plan is developed, executed,
monitored, reported on, and maintained.
The Contractor must provide a Project Manager for the Work. The Contractor must employ the proposed Project
Manager as a regular, fulltime employee on the Proposal submission date and throughout the term of the
Contract, including all renewals. Contractor’s full-time regular employees must perform at least 30% of the effort
required to complete the Project. The Contractor may use its personnel or subcontractor personnel to meet the
remaining 70% of the effort.

As this project is an Enterprise offering supported by DAS/OIT and includes Agency participation in the Projects
identified herein, the following table represents the State’s minimum commitments to this Project. Should, based
on the experience of the Offeror additional roles be required of the State, the Offeror will identify these roles,
provide rationale and include a summary description of the skills and competencies required for each position.
Note that all roles (State minimum or otherwise) must be included in the Offeror’s Staffing Plan as required in this
section of the Supplement. For all State roles marked “as required”, Offerors are to include (within their proposal)
the staffing level required of the State to ensure that the project is supported adequately.
The State will provide a dedicated State Project Lead (Project Representative) to serve as the Contractor’s day-
to-day point of contact for the Project. This role will be staffed throughout the duration of the Project. The State
Project Lead will facilitate process and policy decisions in support of the Project schedule. State personnel
assigned to the Analyze Phase will maintain consistent involvement throughout the duration of the Project. These
individuals will be accessible and available to participate as agreed upon in the approved Project Plan. Offeror
may recommend additional assistance required to successfully complete the project. This may be communicated
via a RACI diagram.
Projects
Enterprise
MDM
State Solution Enterprise
Enterprise Architecture Ohio Benefits MDM
MDM Core and Current Expansion Service Medicaid
Team Data State and Hardware Integration JFS Enterprise Provider
Project Area (DAS/OIT) Management Assessment Upgrade with EDW MDM Initiative Management
Overall Project
1 FTE
Management
State
Standards 1 PTE as
Lead: State required
Policy and IT (advisory)
Standards
1 FTE
Security (design
Advisor phases),
(State CISO part-time
Office) advisory
thereafter
1 FTE
Privacy (design
Advisor phases),
(State CIPO part-time
Office) advisory
thereafter
Security/Privac Up to 1 FTE
y SME as required
1 FTE
(design
phases),
Business Lead
part-time
advisory
thereafter
1 FTE
Data Analyst (design
Lead phases),
part-time

Projects
Enterprise
MDM
State Solution Enterprise
Enterprise Architecture Ohio Benefits MDM
MDM Core and Current Expansion Service Medicaid
Team Data State and Hardware Integration JFS Enterprise Provider
Project Area (DAS/OIT) Management Assessment Upgrade with EDW MDM Initiative Management
advisory
thereafter
Data
Modeler/Data -
Architect
Data
1 PTE As
Governance
Required
Lead
Data Stewards Part Time SMEs as developed as part of Data Management Deliverables or requested by Vendor
1 PTE As 1 PTE As 1 PTE As 1 PTE As 1 PTE As 1 PTE As
Technical Lead -
Required Required Required Required Required Required
Integration 1 PTE As 1 PTE As 1 PTE As 1 PTE As 1 PTE As 1 PTE As
-
Lead Required Required Required Required Required Required
System Test
As required As Required As Required As Required As Required As Required As Required
Lead
System Test
As required As Required As Required As Required As Required As Required As Required
Participants
Up to 4 PTE
(Network,
State
Server,
Infrastructure
Storage,
Liaisons
Directory) as
required
6.1 Contract Staffing and Key Activities

The Offeror is to consider the roles provided by the State as well as those proposed that are required for each
Project based upon the details, the key activities, proposed time commitments required for each role, and the
percent of the proposed time the role will be on the State’s premises performing work. The Offeror, as part of their
response will identify all roles that are required to be performed (by phase), the work location(s) for the team and
identify requirements for performing these roles off-site at an Offeror location or on State’s Premises (e.g., Project
Manager, business analysis, technical lead, functional lead, etc.). Offerors are to propose a combined team
organization (i.e., State and Offeror) designed to deliver the project to the State as per the requirements in this
Supplement.
Offeror Team Organization, Key Personnel and Work Location(s)

Role On Site % Time
# Offeror Role Role Activity FT/PT or Off On Site
Site
Analyze Phase
[insert rows as required]
Design Phase

Role On Site % Time
# Offeror Role Role Activity FT/PT or Off On Site
Site
Build Phase
Test Phase
Deploy Phase
Post Implementation Support
6.2 Staffing Plan and Time Commitment

The Offerors Staffing Plan and Time Commitment response must include the following information:
 An organizational chart including any subcontractors and key management and administrative personnel
assigned to this project
 A contingency plan that shows the ability to add more staff if needed to ensure meeting the Project’s due
date(s)
 The number of people onsite at State location(s) at any given time to allow the State to plan for the appropriate
workspace. Offeror Note: The following table is provided as an example of what the State expects the Offeror
to provide in the proposal response for this requirement
Illustrative Offeror Staffing Plan

Project Month 1 2 3 4 5 6 7 8 9 10 11
Startup /
Phase Design Phase Build Phase Test Phase Deployment Operate
Analyze
Project Management
State 3 3 3 3 3 3 3 3 3 3 3
Offeror 2 2 2 2 2 2 2 2 2 2 2
Functional FTEs
State 4 4 4 4 4 4 4 4 4 4 4
Offeror 8 8 8 8 8 8 8 8 8 8 8
Technical FTEs
State Infrastructure 2 2 2 2 2 2 2 2 2 2 2
State Security 1 1 1 1 1 1 1 1 1 1 1
Offeror 6 6 6 6 6 6 6 6 6 6 6
Business / Agency FTEs
State 4 4 4 4 4 4 4 4 4 4 4
Offeror 2 2 2 2 2 2 2 2 2 2 2
Summary Total
State 14 14 14 14 14 14 14 14 14 14 14
Project Month 1 2 3 4 5 6 7 8 9 10 11
Startup /
Phase Design Phase Build Phase Test Phase Deployment Operate
Analyze
Offeror 18 18 18 18 18 18 18 18 18 18 18
Offerors are encouraged to add additional roles and responsibilities as appropriate based on their proposed
Project Staffing Plan as to highlight the involvement of their Proposed Team and inclusion of State resources in
the project to help ensure its success. The number of FTEs depicted in the above table are provided as an
illustrative example and in no way connotes State expectations as to the level or involvement of the State or
Offeror in this project.
A statement and a chart that clearly indicates the time commitment of the proposed Project Manager and the
Offeror’s Key Project Personnel, inclusive of the Project Manager and the Offeror’s proposed team members for
this Work during each phase of the Projects, the System Development Life Cycle associated with Projects, and
the commencement and ongoing operation of the within the OAKS enterprise Service.
 The Offeror also must include a statement indicating to what extent, if any, the candidates may work on other
projects or assignments that are not State related during the term of the Contract. The State may reject any
Proposal that commits the proposed Project Manager or any proposed Key Project Personnel to other projects
during the term of the Project, if the State believes that any such commitment may be detrimental to the
Offeror’s performance.
In addition, the Offeror’s proposal must identify all Key Project Personnel who will provide services as part of the
resulting Contract. The Key Project Personnel are identified in each applicable Supplement. The State expects
that the proposed named Key Project Personnel will be available as proposed to work on the Project. Resumes
for the proposed candidates must be provided for all Key Project Personnel. Representative resumes are not
acceptable. The resumes will be used to supplement the descriptive narrative provided by the Offeror regarding
their proposed project team.
The resume (2-page limit per resume) of the proposed Key Project Personnel must include:
 Proposed Candidate’s Name
 Proposed role on this Project
 Listings of completed projects (a minimum of two references for each named Key Project Personnel) that are
comparable to this Project or required similar skills based on the person’s assigned role/responsibility on this
Project. Each project listed should include at a minimum the beginning and ending dates, client/company name
for which the work was performed, client contact information for sponsoring Directors, Managers or equivalent
level position (name, phone number, email address, company name, etc.), project title, project description, and
a detailed description of the person’s role/responsibility on the project.
 Education
 Professional Licenses/Certifications/Memberships
 Employment History
6.3 Background Checks

All Contractor and subcontractor personnel assigned to the Enterprise MDM Project who have access to sensitive
or confidential information or to sensitive State systems must have a current fingerprint search and background
check performed by the Federal Bureau of Investigation or other Federal investigative authority. The fingerprint
search and background checks must be completed before any such Contractor or subcontractor personnel gain
access to State facilities, sensitive and/or confidential information or systems. All costs associated with this
requirement will be at the Contractor’s own expense. At its discretion, the State may reject any Contractor or
subcontractor personnel based on the information provided in the completed background check.
The Offeror must confirm in their Proposal that all Offeror and subcontractor personnel assigned to the Project will
have Background Checks completed before Project Start or before reporting to State designated Project facilities.
7.0 Assumptions
The Offeror must list all the assumptions made in preparing the Proposal in the “Template P General
Assumptions” document. If any assumption is unacceptable to the State, the State may at its sole discretion
request that the Offeror remove the assumption or choose to reject the Proposal. No assumptions may be
included regarding the outcomes of negotiation, terms and conditions, or requirements. Assumptions should be
provided as part of the Offeror response as a stand-alone response section that is inclusive of all assumptions
with reference(s) to the section(s) of the RFP that the assumption is applicable to. Offerors should not include
assumptions elsewhere in their response.
7.1 Support Requirements

The Offeror must describe the support it wants from the State other than what the State has offered in this RFP.
Specifically, the Offeror must address the following:
 Nature and extent of State support required in terms of staff roles, percentage of time available, and so on
 Assistance from State staff and the experience and qualification levels required
 Other support requirements
The State may not be able or willing to provide the additional support the Offeror lists in this part of its Proposal.
The Offeror therefore must indicate whether its request for additional support is a requirement for its performance.
If any part of the list is a requirement, the State may reject the Offeror’s Proposal, if the State is unable or
unwilling to meet the requirements.
7.2 Pre-Existing Materials

The Offeror must list any Pre-Existing Materials it owns that will be included in a Deliverable if the Offeror wants a
proprietary notice on copies that the State distributes. For example, the Offeror may have standard user
interfaces or standard shells that it incorporates in what is otherwise custom software. (See the Ownership of
Deliverables section of the General Terms and Conditions.) The State may reject any Proposal that includes
existing materials for a custom solution, if the State believes that such is not appropriate or desirable for the
Project.
7.3 Commercial Materials

The Offeror must list any commercial and proprietary materials that the Offeror will deliver that are easily copied,
such as Commercial Software, and in which the State will have less than full ownership (“Commercial Materials”).
Generally, these will be from third parties and readily available in the open market. The Offeror need not list
patented parts of equipment, since they are not readily copied. If the Offeror expects the State to sign a license
for the Commercial Material, the Offeror must include the license agreement as an attachment. If the State finds
any provisions of the license agreement objectionable and cannot or does not negotiate an acceptable solution
with the licensor, regardless of the reason and in the State's sole discretion, then the Offeror’s Proposal may be
rejected. If the State is not going to sign a license, but there will be limits on the State's use of the Commercial
Materials different from the standard license in the General Terms and Conditions, then the Offeror must detail
the unique scope of license here. Unless otherwise provided in this RFP, proposing to use Commercial Materials
in a custom solution may be a basis for rejection of the Offeror’s Proposal, if the State, in its sole discretion,
believes that such is not appropriate or desirable for the Project. Any deviation from the standard license,
warranty, and other terms in Attachment Four also may result in a rejection of the Offeror’s Proposal.
If the Offeror proposes a Deliverable that contains Commercial Software or other Commercial Materials with
terms that differ from the terms in Attachment Four for Commercial Software and Materials, then those terms
must be detailed here, and any proposed separate agreement covering those items must be included in the
Offeror’s Proposal. This is required even if the State will not be expected to sign the agreement. Any deviation
from the standard terms in Attachment 4 may result in a rejection of the Offeror’s Proposal.
8.0 Informatica Platform Environments

This section defines the Informatica development and testing related environments that need to be implemented
as part of the scope of this RFP. Additionally, the Contractor will need to provide technical support for these
environments throughout the system development lifecycle for all releases that are within the scope of this RFP.
8.1 Informatica Platform Environment Implementation and Support During

Development
The following environments need to be procured and implemented as part of the scope of this RFP. Please note
that the State has already acquired an enterprise license for all Informatica products to be used in these
environments.
Environment Usage Quantity
Development To perform application development for releases included in the scope 2
of this RFP
System Testing To perform system integration testing and UAT defect correction 2
validation testing prior to deploying the change in UAT
UAT To perform user acceptance testing 2
Prod Replica Restricted environment that contains a replica of production data. This 1
environment is used to test external web services, such as the Federal
Data Hub, where production data is needed to successfully complete
this testing. This environment may also be used for performance
testing.
Prod Production environment where the releases will be used by the 1
business users working for agencies within the scope of this RFP

Environment Usage Quantity
Disaster Recovery Disaster recovery environment to fail over onto in the event of a 1
production system outage due to a natural disaster or other unforseen
event
9.0 Appendix A: Project Development Methodology Deliverables by Release

Below is a matrix of required deliverables and key work products by project as outlined in Section 2 of this
Supplement.


Enterprise MDM Supplement

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Enterprise MDM Supplement

Încărcat de

Drepturi de autor:

Formate disponibile

Supplement 1

Enterprise Master Data Management (MDM)

State of Ohio Department of Administrative Services, Office of Information Technology

6.0 State Staffing Requirements 78

8.0 Informatica Platform Environments 84

9.0 Appendix A: Project Development Methodology Deliverables by Release 85

State of Ohio Department of Administrative Services, Office of Information Technology

 Facilitation of cross-agency integration via a common registry of system identifiers (IDs)

1.1 General Scope

Refer to Release Domains in Agencies in Source System Consuming Anticipated

State of Ohio Department of Administrative Services, Office of Information Technology

1.2 Discovery Period

2.0 General Project Requirements

2.1 Data Management Strategy

2.1.1 Data Governance & Stewardship

The Offeror will be expected to:

2.1.2 Data Quality Management

2.1.3 Metadata Management

2.1.4 Key Deliverables

2.2 Enterprise MDM Solution Architecture

State of Ohio Department of Administrative Services, Office of Information Technology

2.2.1 Key Deliverables

2.3 Ohio Benefits Expansion and Hardware Upgrade

 Partner with the DAS-OIT team to define HW specifications

2.3.1 Key Deliverables:

State of Ohio Department of Administrative Services, Office of Information Technology

2.4.1 Key Deliverables:

2.5 JFS Enterprise MDM Initiative

2.5.1 Key Deliverables:

2.6 Medicaid Provider Management

2.6.1 Key Deliverables:

State of Ohio Department of Administrative Services, Office of Information Technology

2.7 Identity Management Integration

2.8 Development and Testing Environment Support

2.9 Maintenance and Operations

2.10 Data Quality Execution

2.11 Unanticipated Project Services

3.0 Solutions Requirements: Business, Data and Non-Functional Requirements

3.1 Overview of State Systems Referenced in this Supplement

Agency or Contains Individual Contains Business

3.2 Additional State Data Stores

State of Ohio Department of Administrative Services, Office of Information Technology

3.4 Organization of Requirements

Area Description / Contents

The following is a description of each column in the table:

The following is a description of each column in the table:

The following is a description of each column in the table:

State of Ohio Department of Administrative Services, Office of Information Technology

The following is a description of each column in the table:

Assumption ID: Provides the unique Id to be used for traceability

State of Ohio Department of Administrative Services, Office of Information Technology

REQ ID Requirement Description by Category Requirement

BR-PRP MDM Pre-processing

BR-DSC MDM Data Standardization, Cleansing and Enrichment

State of Ohio Department of Administrative Services, Office of Information Technology

BR-HUB MDM Repository - Enterprise MDM Hub

BR-RFD MDM Repository - Master Reference Data (e.g. look-up data)

State of Ohio Department of Administrative Services, Office of Information Technology

BR-DMG MDM Data Migration / Conversion – General

BR-DMI MDM Data Migration / Conversion - Individual

BR-DMB MDM Data Migration / Conversion - Business

State of Ohio Department of Administrative Services, Office of Information Technology

BR-MRG MDM Merge

State of Ohio Department of Administrative Services, Office of Information Technology