Exhibit B - Scope of Services.pdf

PDF 199 KB Posted

Attached to
Voter Registration System
Solicitation number
7080
Issued by
Ohio

About this file

This is a Scope of Services exhibit for a Voter Registration Management System contract with the Cuyahoga County Board of Elections (CCBOE) in Ohio. The vendor is responsible for providing overall project management and professional services to deliver a VRM System with qualified personnel assigned to the project. The project is structured in five stages: Stage I (Design), Stage II (Development & Testing), Stage III (Data Migration, Transition & Go-Live), Stage IV (Operations), and Stage V (Acceptance). The vendor must submit a detailed Project Schedule using critical path methodology upon receipt of notice to proceed, with specific milestone commitments for each stage. The contract term extends from project initiation through maintenance services following Final System Acceptance, with no specific response dates, bid deadlines, or award dates identified in this scope document.

The scope outlines comprehensive acceptance testing requirements including Initial System Testing, Hardware Production Testing, Commissioning Testing, Disaster Recovery Testing, Formal Data Migration Testing and Validation, Go-Live Readiness Testing, and Final Acceptance Testing. The vendor must establish a Help Desk function available 24/7/365 with toll-free telephone support and maintain system performance to specified Key Performance Indicators (KPIs), including maximum load times of 2 seconds, save times of 2 seconds, system availability of 99.95% or greater, zero privacy breaches, and severity-based incident response times (8 hours for Severity 1, 24 hours for Severity 2, and 5 business days for Severity 3). Non-compliance with KPIs results in deductions from invoice payments ranging from 2.5% to 10% or greater based on accumulated non-compliance points. Upon contract expiration or termination, the vendor must perform transition activities within 180 calendar days, including development of transition and shutdown plans, database design information transfer, and support to ensure service continuity with a successor vendor.

View the file

Other files

File Type Posted
Exhibit A - Functional Specifications.pdf PDF
Supplier Portal Instruction Guide.pdf PDF
Request for Proposals.pdf PDF
Exhibit C - Proposal Pricing Form.xlsx XLSX spreadsheet

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

EXHIBIT B

SCOPE OF SERVICES

A. Services. The Vendor is responsible for providing the overall project management to ensure the timely and satisfactory delivery of the System, and shall have sole discretion in staffing its services to deliver the functionality of the System; provided that Vendor shall assign personnel who possess the training, skills, and qualifications necessary to properly provide the Professional Services. Subject to applicable laws, the CCBOE may inform the Vendor if the CCBOE determines that any personnel assigned by the Vendor are unacceptable. Within five days following the CCBOE’s request, the parties will review the matters and, if after such review the parties do not otherwise agree to retain the individual, the Vendor will remove the individual from the CCBOE’s account. Each of the CCBOE and Vendor shall designate at least one employee with knowledge of the

CCBOE’s business and Vendor’s technology and services as its primary contact to be available for communication with the other party in connection with the Professional

Services. If Vendor’s personnel are required to be present on the CCBOE’s site, the

CCBOE will provide adequate workspace and Vendor’s personnel shall abide by the

CCBOE’s reasonable policies, including worksite safety and security rules that are provided to Vendor in advance or are posted at the CCBOE’s site.

B. Project Schedule. Upon receipt of notice to proceed, the Vendor shall submit a Project

Schedule to the CCBOE for review and approval. The Project Schedule shall show, in detail using critical path methodology and logic, the Vendor’s work activities for the entire project. Upon CCBOE approval, the Project Schedule shall be considered the baseline schedule for the project. The Project Schedule shall constitute the Vendor’s commitment to the project milestone dates, which shall include at least the following overall stages:

1. Stage I - Design - Stage I shall involve efforts related to the Vendor’s configuration of the System. During this stage the Vendor shall design the System to meet both the functional and technical requirements of the RFP. During the design efforts the Vendor shall work closely with the CCBOE and facilitating the any necessary design workshops (Business Rules, Configuration and Reports

Design).

2. Stage II - Development & Testing - Based on the results of Stage I, Stage II shall involve the Contractor's efforts to develop, integrate and test the System.

Completion of Stage II shall culminate in successful completion of the

Commissioning Testing.

3. Stage III - Data Migration, Transition & Go-Live - Stage III shall involve the

Contractor's data migration efforts and transition (Go-Live) to the System. Stage

III shall culminate in the successful completion of all data migration and related testing, Go-Live Readiness Assessment, and Go-Live.

4. Stage IV– Operations – Stage IV shall commence immediately upon successful transition and full cut over of operations to the system in production environment.

5. Stave V – Acceptance – Stage V shall commence upon Final System Acceptance and signify the transition to Maintenance Services phase of the contract term.

C. Acceptance Testing. The Vendor warrants that its testing process will consist of several phases which are defined below in the order of required execution. The CCBOE personnel or its representatives may directly monitor testing and may assume direct roles as testers to validate test processes and results. Successful demonstration of a function during one test does not exclude that function from testing during subsequent tests. The

CCBOE shall have the right, at its sole discretion, to determine if the system is ready for the next steps in the testing process. The Vendor shall prepare the criteria for entry and exit for each test and shall consider that any deficiencies identified during the tests shall not trigger any loss of information to the CCBOE or related partners and shall not result in the need for extra work or extra cost to the CCBOE.

1. The Vendor shall prepare test data as part of the testing process. The test data shall be sufficient to support the full range of approved test procedures and fully demonstrate the compliance with the CCBOE’s requirements. The test data shall encompass various data sets to support the range of test cases, including valid, invalid/illegal, boundary conditions, and performance/load stress testing.

2. The Vendor shall maintain a detailed deficiency log and tracking system. The deficiency log shall include all System software, hardware, and integration. The deficiency log shall provide the means to report an issue, detail the approach to rectify the deficiency, associate comments and files attached to the issue, reporting capabilities on the status of testing and Deficiencies, and document the corrective action taken and the date and time of such actions.

3. The Vendor shall provide the CCBOE with online access to the deficiency log. The

Vendor shall also provide the CCBOE with the capability to generate reports from the

System.

4. The Vendor shall submit the Master Test Plan for review and approval by the

CCBOE. The Vendor shall identify and document in a Master Test Plan the modules, procedures, schedules, and the equipment and facilities required for testing. The

Master Test Plan shall be a road map for accomplishing the tests, including all required test phases identified below. The Master Test Plan shall clearly state the objectives, test scenarios, and success criteria of each level of testing and clearly define the requirements for success at each step in the testing process. The Master

Test Plan shall also identify the reports to be furnished at the end of each test, the rectification process for issues and anomalies, and the timelines for the rectification.

The Master Test Plan shall also address the overall schedule of testing, sequencing and interdependency of tests, test simulators, sources and generation of test data, reporting procedures, and the process for failure tracking, analysis, and resolution.

5. Initial System Testing: The Vendor shall perform Initial System Testing. The intent of

Initial System Testing shall be to verify that the Vendor has successfully developed the VRM System in accordance with the requirements set forth in the RFP, demonstrate core system functionality, and provide the basis for the Vendor to begin full system integration and preparation for deployment. Anomalies, failures, or other issues identified during Initial System Testing shall be documented and tracked in a punch-list format. All punch-list items shall be satisfactorily resolved prior to CCBOE approval or acceptance.

6. Hardware Production Testing: Any Hardware provided by the Vendor shall be unit tested to ensure it complies with the requirements of the VRM System. The Vendor shall notify the CCBOE of the results of the testing and post the completed unit test documentation in the project collaboration environment for review by CCBOE at its option.

7. Commissioning Testing: The Vendor shall demonstrate that the entire VRM

Management System is ready for operations commencement and the migration of data from the existing CCBOE systems. The tests shall demonstrate the integration of various subsystems including Hardware and Software. This test shall include all hardware and software, including any hardware and software acquired from third-party entities. The testing shall demonstrate all aspects of the VRM System, including internal and external communications interfaces under field conditions.

Commissioning testing shall include testing external interfaces demonstrating that the

VRM System, including all required components and services, is meeting all external data interface requirements in the agreement.

8. Disaster Recovery Testing: Disaster Recovery Testing is designed to demonstrate that the VRM System, including all required components and services, is meeting all

Disaster Recovery requirements in the Contract, including a communication system supporting a seamless transfer to the secondary system on a real-time basis. The

Disaster Recovery testing shall demonstrate that the VRM System can be seamlessly switched over from the primary system to the secondary system and successfully handle and perform normally under a failure or disaster recovery conditions. Further elaboration on the requirements for Disaster Recovery Testing is described in the specifications for the Disaster Recovery Plan.

9. Formal Data Migration Testing and Validation: The Vendor shall perform two distinct steps involving an initial Trial Migration Test to identify any anomalies, inconsistencies, or other problems with the adequacy of the data migration using a subset of data from legacy database and test procedures and Full Migration Test using the full database snapshot observing and recording the speed of execution, exercising the complete set of validation tasks, and identifying any remaining debugging efforts.

The Vendor shall perform the following Data Migration Tasks:

a. Requirements Analysis - analyze the legacy system where the Vendor shall work with the legacy provider to obtain a full snapshot of the legacy data to identify the legacy data structure and elements that are necessary for successful migration and transition, quality issues that may impact migration or functionality, gaps and transformations to meet new business rules and policies, and identify interface needs and potential impacts.

b. Specifications Development - establish detailed requirements for executing the migration process with the legacy systems, including mapping, necessary system configurations, addressing impacts on security measures, and protecting personal identifiable information.

c. Development and Unit Testing - use a snapshot of the legacy database isolated from any production environment to develop and perform unit testing to verify migration strategies using standard automated processes and/or repeatable executable scripts that conform with the of Extract, Transform, and Load (ETL)

As unit testing and development are completed, the Vendor shall certify that the test procedures used are adequate for formal migration and validation to proceed with a high degree of confidence in success.

d. Formal Data Migration Testing and Validation - perform two distinct steps involving an initial Trial Migration Test to identify any anomalies, inconsistencies, or other problems with the adequacy of the data migration using a subset of data from legacy database and test procedures and Full Migration Test using the full database snapshot observing and recording the speed of execution, exercising the complete set of validation tasks, and identifying any remaining debugging efforts.

e. Implementation – perform the actual process of data migration from the legacy system to the new system. As the migration effort progresses, the Vendor shall document, track, and prioritize all issues that may be encountered in a punch-list format, and resolve any issue within the punch list and log the reasons for failure/issue, steps taken to resolve the failure/issue, and scale of impact.

10. Go-Live Readiness Testing: Upon completion of testing, the Vendor shall conduct a

Go-Live Readiness Assessment. The intent of the readiness assessment is to create and validate a checklist of events, tests, and results that shall ensure that the VRM

System is ready to begin normal operations. The CCBOE shall be actively involved in the readiness assessment and shall govern the final assessment as to if the Voter

Registration Management System is ready for Go-Live operations. For the System to be transitioned to a production status for Go-Live, the following requirements shall be achieved:

a. Successful completion and approval by CCBOE of all relevant test phases;

b. Successful completion of end-user training and approval of the completion of training by the CCBOE;

c. No Severity-1 issues/deficiencies;

d. No Severity-2 issues/deficiencies, or if there is a Severity-2 issue, there is a documented solution and a plan for remediating the issue which has been approved by the CCBOE;

e. Submittal and CCBOE acceptance of business continuity plans.

11. Final Acceptance Testing: The Vendor shall perform Final Acceptance Testing of the

VRM System. The intent of Acceptance Testing is to verify that the Voter Registration

Management System and all related services are in conformance with the CCBOE’s requirements and subsequently approved design documentation, plans, manuals and other deliverables. Acceptance Testing shall be performed under live operational conditions, using actual production data after Go-Live. The Vendor may request

Acceptance of the System upon achieving the following ninety calendar days of continuous production operations after Go-Live without a Severity-1 incident. If a

Severity-1 incident occurs, the clock for determining Acceptance is reset zero and the sixty-day period of continuous operation without a Severity-1 incident begins again.

Acceptance Testing shall include the validation of the full functionality specified throughout the RFP and the Key Performance Indicators as follows:

a. The CCBOE and or its representatives shall participate as test observers to validate and process test results. The Vendor shall provide an Acceptance Test

Plan to conduct and evaluate the test for the CCBOE’s review and evaluation, prior to Go-Live. During Acceptance Testing the Vendor and CCBOE shall validate that all reports of the VRM System are accurate and generated appropriately. The CCBOE reserves the right to withhold issuance of Final

Acceptance until all reports are accurate and in accordance with the requirements, business rules, and approved design documents and reports manual.

b. The Vendor shall manage and track any anomalies, failures, or other issues noted under Acceptance Testing. These observations shall be tracked in a punch-list format and reported on a weekly basis, at a minimum, to the CCBOE. The Vendor shall satisfactorily address all punch-list items prior to receiving Final Acceptance from the CCBOE. The CCBOE reserves the right to request re-testing of any punch list item prior to granting Final Acceptance.

c. Acceptance Testing shall be the final test to be completed and shall only be initiated once all VRM System elements have been installed and configured and all previous tests have been successfully completed. The CCBOE reserves the right, at its sole discretion, to determine if the System and associated services meets the requirements of the agreement.

d. Upon the satisfaction of the acceptance requirements, the Vendor shall submit an

Acceptance Letter with appropriate supporting documentation to the CCBOE requesting its acceptance of the system, and the CCBOE shall provide the Vendor with written notification of System Acceptance if those requirements are satisfied.

D. Maintenance Services. Once the CCBOE issues Final Acceptance, the Vendor shall provide support and maintenance services for the system to continue its operations with no degradation in the performance throughout the term and any renewal thereof.

1. Software modifications that are required to maintain and support the System as a part of the normal course of business such as version changes, configuration or parameter changes or minor changes to software code or any code changes necessary to meet new regulatory standards or changes that improve the Vendor’s ability to maintain and support the System, shall not be considered upgrades or enhancements that are to be paid for separately by the CCBOE. Upgrades or enhancements required for reasons such the addition of new functionality or that provide the CCBOE with a demonstrable benefit in performance, costs or productivity, may be proposed by the

Contractor.

2. The Vendor shall provide all preventive and corrective maintenance of the System. To every extent possible, performance of maintenance activities shall be completed in a manner that does not disrupt or degrade CCBOE operations. All updates shall be scheduled and planned with BOE staff. Any such efforts shall be clearly documented in advance for BOE concurrence. The Vendor shall establish and staff a Help Desk function that shall include a toll-free telephone number when at such times, a person shall be available at that number to report confirmation of reduced System performance, outages and problems or to discuss and resolve a request for maintenance twenty-four (24) hours a day, seven (7) days a week, 365 days a year.

3. The Vendor shall provide the required system security level access, software tools, training and any other materials required to maintain the system to the performance levels specified herein and in the Contract.

4. Software modifications that are required to maintain and support the System as a part of the normal course of business such as version changes, configuration or parameter changes or minor changes to software or code; or, changes that improve the Vendor's ability to maintain and support the System, shall not be considered upgrades or enhancements that are to be paid for by the CCBOE in accordance with the following paragraph.

5. Upgrades and enhancements required for reasons such as to meet major changes to standards, statutes or interoperability requirements or the addition of new functionality; or, that provide the CCBOE with a demonstrable benefit in performance, costs or productivity, shall be proposed by the Vendor in accordance with the requirements of the BOE and coordinated through the BOE staff.

6. All the unscheduled maintenance repairs, when reported, shall be assessed and classified as either Severity Level 1– High; Severity Level 2- Medium; or Severity

Level 3- Low: or an Enhancement. The CCBOE, in its sole judgement, shall be responsible for the classification of System incidents and the Vendor shall provide response in accordance with the following:

Class Description Response

Severity 1 –

High Impact

Critical incident that is immediately and materially preventing the CCBOE from performing business operations using its primary production

System. There is no immediate solution, or the solution is extremely complex.

The Vendor shall acknowledge the incident and begin problem diagnostics on the incident within 30 minutes of the incident being reported. The Vendor shall resolve the incident within eight (8) hours of identification through permanent solution or implementing a temporary work around that allows the incident to be re-classified as

Severity 2 or 3. The Vendor shall provide periodic updates to the CCBOE (every 2 hours) during the incident resolution period.

Severity 2 –

Medium

Impact

Significant incident that presents a material impact to the

CCBOE’s business operations using its primary production

System. However, there is a solution allowing business operations to proceed in the interim.

The Vendor shall acknowledge the incident within 30 minutes and begin problem diagnostics on the incident within three (3) hours of the incident being reported. The

Vendor shall resolve all Severity 2 incidents within 24 hours of incident identification. The

Vendor shall provide periodic updates to the

CCBOE (every 4 hours) during the incident resolution period.

Severity 3 –

Low Impact

Incident preventing the System from working according to approved design, but has a limited immediate impact on the CCBOE’s business operations.

The Vendor shall acknowledge the incident within 30 minutes and begin problem diagnostics on the incident within one (1) business day of the incident being reported.

The Vendor shall resolve all Severity Level 3 incidents within five (5) Business Days of identification.

12. Key Performance Indicators. The Vendor shall maintain the System to operate in compliance with, at a minimum the Key Performance Indicators (“KPIs”) listed below. Unless otherwise noted, “days” refers to calendar days:

Required Performance Measurement* KPI Non-Compliance Points

Load Time shall not exceed 2 seconds for registration records, where “Load Time” is the time required to display existing registration records after the elector’s voter ID number or other identifying characteristics

[LOAD TIME]= [END TIME]-

[START TIMЕ] where: END

TIME = the instant the screen begins to populate the fields; and

START TIME = the instant after the elector’s account number is typed in and the ENTER (action) key is pressed.

20 points for failure as indicated by trouble tickets logged with help desk. 10 points for each additional 3 seconds required to load information.

has been entered by an authorized system user.

Save Time shall not exceed

2 seconds, where Save Time is the time required to save updated information.

[SAVE TIME] = [END TIME] -

[START TIME] where: END

TIME = when the screen clears and is ready to process the next system entry; and START TIME when the system user finishes updating the fields and presses the ENTER (action) key.

20 points for failure as indicated by trouble tickets logged with help desk.

10 points for each additional 2 seconds required to save information.

System Availability shall be

99.95% or greater

[AVAILABILITY*] =

[ACTUAL UPTIME] /

[SCHEDULED

AVAILABILITY*], as calculated monthly. Where

“Availability” means working in full functionality as designed and required, and “Scheduled

Availability” means the

“Availability” excluding any

CCBOE approved outages.

100 points for failure to maintain availability, 20 points for each tenth of a percentage point below

99.95%.

Zero Privacy Breach Due to a

System Vulnerability Personal

Account Information

Number of breaches identified (quality audit).

100 points for each breach.

Vendor responsiveness to track and resolve maintenance support issues, and general requests from the CCBOE

Number of non-responsive request greater than 5 business days.

10 points for each request.

Severity 1 issues resolved within

8 hours of incident being reported.

One or more Severity 1 issues unresolved within 8 hours of incident being reported.

75 points per Severity 1 issue unresolved within 8 hours.

Severity 2 issues resolved within

24 hours of incident being reported).

One or more Severity 2 issues unresolved within 24 hours of incident being reported.

50 points per Severity 2 issue unresolved within 24 hours.

Severity 3 issues resolved within

5 business days of incident being reported).

One or more Severity 3 issues unresolved within 5 business days of incident being reported.

25 points per Severity 3 issue unresolved within 5 business days.

A reduction in the amounts payable to the Vendor shall be deducted from the Vendor's invoice for non-compliance with KPIs based on the number of KPI non-compliance points assessed by the

CCBOE in accordance with the Deduction for Non-Compliance table below.

Non-Compliance Points Non-Compliance deduction from amount due

0 to 25 0%

26 to 50 2.5%

51 to 75 5%

76 to 100 7.5%

100 to 200 25%

Every 100 points greater than 200 Additional 10%

E. End of Agreement Transition. In the event of expiration or termination of this Agreement, the

Vendor shall perform transition activities within this Agreement that will overlap with start-up activities for any successor. The Vendor shall meet the following requirements for transition of all or part of the system environment, data and operations. The transition shall take place within one-hundred-eighty (180) Calendar Days of notification from the CCBOE.

1. The Vendor shall confer and cooperate with the successor to determine the activities required to transition the system in an orderly manner and to allow the transition to occur without interruption of services or operations under the existing Contract.

2. The Vendor shall designate a Transition Manager who shall serve as the single point of contact for transition-related activities.

3. Within thirty (30) Calendar Days of notification from the CCBOE of its intention to transition to the successor, the Vendor shall develop, seek CCBOE’s approval for, and manage an issue resolution process for the transition.

4. The Vendor shall develop and submit a system-to-system interface transfer plan for the

CCBOE’s review and approval.

5. The Vendor shall develop and submit for CCBOE review and approval an Operations

Shutdown Plan. Shut down activities shall include the confidential destruction of certain

CCBOE designated hardcopy and electronic records. The CCBOE may request that certain transition-related documentation or functions be transferred to the Successor before the final transition date. The Contractor shall respond to such requests within ten

(10) Calendar Days of the request.

6. The Vendor shall provide System database design information and access to the successor. The Vendor shall provide sufficient System experienced personnel during the entire transition period to ensure that the qualities of services are maintained at the levels required. The Vendor shall provide support to help the successor maintain the continuity and consistency of the services required.

7. The Vendor shall allow the successor to conduct on-site interviews with the Vendor employees. The Vendor shall review and update system related business processes, procedures, database, business rules, and related documentation as a part of the transition process. The Vendor shall add any missing information and correct any deviations from current operating protocol and route to CCBOE for review and approval per current requirements.

File details come from the government source that posted it. Updated .