ESBD_443357_1754488060814_Attachment 1-1 - Statement of Work Final.pdf

RFO 212-25-0959

ATTACHMENT 1-1: STATEMENT OF WORK

Texas Office of Court Administration Public Safety Report System

Statement of Work

EXHIBIT 2: STATEMENT OF WORK (SOW)

The project objectives are to develop, implement, host in the cloud, maintain, support, and update a scalable System; to train all statewide Authorized Users on its use; and to ensure the System complies with the requirements outlined in the Requirements Response Workbook and this Statement of Work.

The System will enable judges to review both a defendant’s criminal history and public safety report, make informed and appropriate bail decisions, make a record of those decisions, and generate necessary reports.

1. Implementation Services Implementation Services refers to activities that must be performed by the Contractor after the Effective Date of the Master Services Agreement (Agreement) to prepare systems and resources for operations.

Implementation Services include everything from logistical arrangements and security protocols for Contractor’s staff, to the development of project plans, and an ongoing strategy for operations.

Additional implementation activities include, but are not limited to, creating and providing all manuals and training, and providing the Operation Procedure Manual.

Below is a detailed description of the work that must be completed by the Contractor to implement the System consistent with the requirements outlined in Attachment 3 (Requirements Workbook).

Contractor must host a project kick-off meeting within 14 days after the Effective Date, with the kick-off materials due to OCA five days prior to presentation. Contractor must provide a baseline project schedule with due dates of deliverables/work products not later than 30 days after the Effective Date.

1.1 Project Initiation

The Contractor must provide project management for the duration of the Agreement. The Contractor must provide resources to execute all project management tasks, functions, and activities described below. In addition, the Contractor must maintain and update project activities and associated work products on a timely, regular, and ongoing basis as set forth in this SOW.

Description Activities/Work Products

Project Initiation

Project Kick-off Materials

Project Kick-off Meeting

Project Baseline Schedule

Project Management Plan

Project Deployment Plan

Stakeholder Outreach and Communication Plan

Configuration Management Plan

Document Management Plan

Project Organization Plan

Description Activities/Work Products

Project Deliverable Expectation Document(s)

1.1.1 Objectives

1. Develop an understanding of the needs and challenges to implement an expedient, seamless, and minimally disruptive implementation of the System.

2. Engage with OCA technical and business stakeholders to generate understanding and trust in the product and implementation teams.

1.1.2 Activities

• Conduct project preplanning and preparation – Includes planning meetings with OCA as required to confirm the schedule, plans, documentation, and other logistics for the project related to project management responsibilities.

• Develop project kick-off materials – Conduct a project kick-off meeting with key stakeholders identified by OCA within fourteen (14) days of the Effective Date. The kick-off meeting must provide an overview of the project objectives, plans, project methodology, scope, and schedule, introduce the Contractor’s project team and roles and responsibilities, and outline project start-up procedures.

• Develop weekly status report templates and schedule ongoing communications for the project.

• Provide ongoing project management duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager (Project Manager) shall participate in project management meetings with stakeholders as scheduled by OCA.

• Deployment planning – Conduct workshops with OCA and other stakeholders to finalize approach for deploying the System into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.

• Develop Project Management Plan

• Project Deliverable Expectation Documents – For each project milestone, provide a high-level outline of component deliverables.

• Develop Baseline Project Schedule

• Develop Project Deployment Plan

• Develop Stakeholder Outreach and Communication Plan

• Develop Project Deliverable Expectations Documents

1.1.3 Work Products

1. Project Management Plan – Within 30 days following the kick-off meeting, Contractor shall create and deliver to OCA the Project Management Plan. Contractor shall maintain the Project Management Plan, which describes the overall project management approach and sets forth the Baseline Schedule, throughout the lifecycle of the project. The Project Management Plan will consist of the following at a minimum:

a. Project Kick-off – Contractor shall conduct a project kick-off meeting to share key project information for stakeholders to have a thorough understanding of the project, a clear sense of key dates and deliverables, and an understanding of the project’s goals and expected business outcomes.

b. Risk and Issue Management Plan & Registers – Contractor shall create and maintain a Risk and Issue Management Plan, Escalation Plan, and Risk and Issue Registers.

c. Integrated Change Management Plan – Outlines the process for identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as System design and acceptance criteria.

i. For change management, a change is defined as any modification within the scope of or reasonably related to this SOW content including any content in all SOW related documents. If a potential change is identified by a member of the project team, including the Contractor or OCA (or other internal/external stakeholder), then the change management process outlined below shall be used to initiate a formal Change Request. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re-baseline the project.

ii. Either OCA or Contractor may initiate a Change Request for a desired process change, additional funding, and/or a longer timeline as conditions may change on the project over time.

iii. Change Requests must contain the description of the change, the schedule to implement the change, and a fixed price based on the number of hours required.

iv. Contractor shall timely respond to a Change Request requested by OCA within seven (7) days from notice.

v. When the Project Manager reviews Change Requests, the Project Manager may approve the Change Request, consider alternatives, direct the project team to do more research, reject the Change Request and continue the project, or reject the Change Request and request a different change.

d. Project Deployment Plan –

i. Contractor shall conduct transition planning workshops with OCA to determine the approach for deploying the System into production, including possible phasing strategies, site-specific considerations, and benefits and risks of strategy alternatives. Key deployment planning activities required of the Contractor include at a minimum:

1. Perform analysis of phasing alternatives with OCA and designated stakeholders.

2. Identify high-risk transition areas and impact, develop mitigation strategies, and identify recommended mitigation actions and report results to OCA related to the phasing decisions.

3. Track any ongoing risks, based on finalization of phasing approach, in the Risk and Issue Management Plan and Risk and Issue Registers.

4. Document any decisions that impact the schedule in the Project Schedule.

5. Document any cutover consideration(s) in the final Cutover Plan.

ii. Using the information gathered through the transition planning workshops, the Contractor will develop the Project Deployment Plan:

1. Contractor shall develop and maintain a detailed Project Deployment Plan for the selected phasing alternative including the approach, activities, milestones, schedule and schedule dependencies, risk identification and mitigation strategies, and pre-cutover readiness assessment activities.

2. Once OCA has approved the Project Deployment Plan, the Contractor shall finalize the project schedule outlining the key project phases, tasks, activities, dependencies, budgeted hours, assigned resources, and deliverables for the System deployment. The schedule shall clearly define estimated resource hours associated with each task.

3. Contractor shall provide a finalized project organization chart.

2. Project Baseline Schedule – Contractor shall create and maintain a work plan and a Baseline Schedule, including Gantt chart(s) and a project calendar in Microsoft Project, that is developed and maintained in accordance with industry best practices. The work plan will reflect any changes from the Baseline Schedule originally agreed to during the project initiation and be updated on a weekly basis. The Baseline Schedule will include the following components at a minimum:

a. A consolidated view of the activities, activity descriptions, and activity durations assigned to stakeholders and Contractor.

b. Resources (OCA, other stakeholders, Contractor, and third-party vendors) assigned to each activity and their required level of effort.

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

d. Identification of all key Project Milestones.

e. Deliverable approval periods compliant with OCA’s document process as described in the Deliverable Expectations Document section below.

f. A critical path analysis and reporting process.

3. Configuration Management Plan – Describes the following:

a. Approach for managing programming changes, third-party software, provided APIs, and configuration settings made in the System, including testing, final approval of deployment, and deployment.

b. Methods for configuration release management controls between environments.

c. Configuration management process and any actions that will be required of OCA.

Identification of any specific skills that would be needed by those staff performing configuration activities.

d. Methods for conducting configuration audits and reviews to be held during the project.

e. How Contractor will create (and maintain) a Configuration Items Log that captures configuration items in a register, including identified baselines under control, that complies with the requirements.

4. Stakeholder Outreach and Communication Plan – Contractor shall describe its approach for outreach to the existing stakeholder groups to ensure a successful transition to the System. The Stakeholder Outreach and Communication Plan applies specifically to stakeholder groups that are outside of OCA but are impacted by the System. The Stakeholder Outreach and Communication Plan must include the following elements at a minimum:

a. Summary of Plan: Description of the methodology or approach that the Contractor will use to engage with the identified stakeholder groups.

b. Communication Channels: Information related to the type of communication channels that the Contractor intends to use.

c. Tools or measures to assess progress: Information on how the Contractor intends to measure progress and any tools required.

d. Established timeline: Timeline for outreach activities.

e. Stakeholder Engagement Table: Submit a table showing at minimum the following for each identified stakeholder to be part of any outreach:

i. Methods of Engagement

ii. Purpose

iii. Level of Involvement.

5. Document Management Plan – Provide approach to the delivery of correspondence and documentation with version control, to include any updated versions. Provide approach to providing notification of any correspondence including deliverables and documentation.

6. Project Deliverable Expectations Documents – For each project milestone, provide a high-level outline of component deliverables.

a. OCA and the Contractor will agree on the Project Deliverable Expectations Documents at the beginning of the project and confirm the Project Deliverable Expectations Documents before each subsequent milestone.

b. No work will be performed on any deliverable associated with a payment milestone until all Deliverable Expectations Documents have been approved in writing by the OCA Project Manager. As each project deliverable is submitted, the Contractor must include a copy of the associated Deliverable Expectations Document as the cover sheet.

c. All contract deliverables are given a unique number and tied to the project schedule.

The dates for deliverable submissions, review comments, and resubmissions must be tracked. OCA’s project SharePoint site will be utilized as the repository of record for deliverables.

d. Deliverables prepared by the Contractor will be subject to the review and approval by the OCA Project Manager or designee. The Contractor must be prepared to provide walkthroughs of deliverables to facilitate the OCA deliverable reviews. OCA will review, approve, or require modification to the Contractor’s deliverables. Approval shall be granted if the deliverable conforms to the requirements of the Deliverable Expectations Document. Upon receipt of a deliverable, OCA shall notify the Contractor within ten (10) business days, or as otherwise agreed to by OCA and Contractor, of its approval or rejection, with the reason(s) for rejection and what the Contractor must do so that the deliverable will be acceptable. The Contractor shall have five (5) business days, or as otherwise agreed to by OCA, to correct the deliverable and resubmit the deliverable for OCA review.

e. The Contractor and OCA will agree on the format and acceptance criteria for each project deliverable. The format of the Deliverables Expectations Documents will be defined within thirty (30) days from the effective date of the MSA.

1.2 Requirements Validation

The Contractor must validate the business and technology requirements identified and provided in Attachment 3 (Requirements Workbook).

Description Activities/Work Products

Requirements Validation

Requirements Traceability Matrix

Deliverable Expectations Document

1.2.1 Objectives

1. Validate the Contractor’s understanding of the requirements and submit a Requirements

Traceability Matrix.

1.2.2 Activities

• Review related background documentation.

• Meet with business and technical stakeholders to understand business objectives, activities taken to date, progress efforts, and other relevant information.

• Understand target datasets for the System.

• Develop a Requirements Traceability Matrix – Contractor shall review the Requirements to validate the Contractor’s understanding of the requirements to meet stakeholders’ expectations and identify areas for discussion.

• Submit a Requirements Traceability Matrix.

1.2.3 Work Products

1. Requirements Traceability Matrix – This Requirements Traceability Matrix is based on the

Requirements and includes any clarifications to ensure that the System meets stakeholder expectations.

1.3 Environment Provisioning and Configuration

The Contractor will document and complete the System build and configuration as defined by the final design specifications.

Description Activities/Work Products

Provisioning and Configuration

System Implementation Plan

Cutover Plan

API Technical Document

API Specification Document

Deliverable Expectations Document

1.3.1 Objectives

1. Perform all activities necessary to provision all environments needed to run the System, including any networking needed to connect securely to external systems.

2. Implement and configure the System per the developed design to prepare for testing activities.

3. Provide stakeholders and their vendors with the necessary documentation for them to connect to the API.

4. Meet with stakeholders and their vendors to provide overview of the API and to gather information as to when they will be able to connect.

5. Assist stakeholders and their vendors as issues arise.

1.3.2 Activities

• Develop the System Implementation Plan.

• Provision and configure the System based on the Requirements Traceability Matrix and approved System Implementation Plan.

• Integrate all components of the System.

• Configure the user interfaces and APIs needed to run the System.

• Develop the standard API documentation.

• Configure any emailing services needed.

• Provide technical support to stakeholders and OCA.

• Build and/or modify all reports and dashboards.

• Develop the Cutover Plan.

1.3.3 Work Products

1. System Implementation Plan – shall include the following content:

a. Security Plan

i. Approach for monitoring security, including how it complies with applicable security protocols and regulations.

ii. Approach for keeping security capabilities current with evolving known and potential security threats.

iii. Security roles and responsibilities, mission statement, key terms governing incident response, identification of an incident response lead, and incident detection channels.

iv. Strategy to identify and categorize incidents.

v. Process to communicate, contain, eradicate, and recover from incidents.

vi. Post-incident activities to ensure continuous security improvement.

b. Disaster Recovery and Business Continuity Plan

i. Approach for initiating disaster recovery and/or business continuity procedures to be undertaken in the event of a disaster affecting the System.

ii. Approach for ensuring all information necessary to

iii. restore operational service in the event of a disruption are correct and up to date.

iv. Functional roles and responsibilities of recovery teams.

v. Description of recovery scenarios that can be implemented.

vi. Recovery activities to be exercised and frequency of testing.

vii. Description/location of data backups, inventories, or other related documentation that must be recorded.

viii. Communication protocols and processes for restoring operations in a timely manner.

ix. Approach for retention and storage of backup files and software.

c. Infrastructure Services Plan

i. Definition of environments and the approach for maintaining application and infrastructure component consistency across all applicable environments.

ii. Approach for certifying and/or providing quality assurance of all applicable environments.

iii. Approach for managing programming environment changes including management of testing and deployment of new releases while maintaining capacity to apply hotfixes to production.

iv. Approach for communicating and supporting testing of all applicable environments with internal and external organizations/systems.

v. Approach for establishing initial capacity and anticipated growth requirements for the System including but not limited to storage, processing, and network bandwidth.

vi. Approach to performance tuning to ensure the System operates optimally and within defined service levels.

vii. Approach for monitoring ongoing usage and growth patterns of System resources including for cumulative growth and peak usage patterns.

viii. Approach for deployment of additional capacity as specified in the original plan and per the results of ongoing capacity monitoring.

ix. Approach for preventative and unplanned services to System services.

x. Documentation of third-party infrastructure service providers and associated communication and management processes.

d. Cutover Plan – The Contractor shall create a Cutover Plan that includes at a minimum:

1. Go-live cutover planning activities to assess transition readiness, go/no-go criteria, and fallback positions to be taken if no-go conditions are encountered for individual deployments.

2. Preliminary cutover schedule that clearly defines key milestones, deliverables, tasks, and responsibilities. The Cutover Plan will be updated prior to go live.

3. Cutover milestones where readiness to proceed is assessed, go/no-go criteria, and fallback positions to be taken if no-go conditions are encountered.

4. Pre-cutover checklist and post-cutover evaluation criteria.

5. Transition readiness assessment, including the preliminary schedule, rollback strategy, assessment scorecards, and defined critical readiness criteria that will drive go/no-go decisions related to overall readiness/preparedness for going live on the System.

2. Help Desk Support Plan – The Contractor shall create the initial draft of the Help Desk Support Plan to describe how Help Desk services will be provided for the System.

1. The Help Desk must be fully operational at the time of deployment.

2. The Contractor shall provide a staffing plan and resumes for key production support staff to OCA for review and approval. Contractor shall update this plan during cutover and will be responsible for updating the plan annually during the Term of the Agreement.

1.4 Testing

The Contractor must develop, conduct, and provide support to OCA and the applicable stakeholders in the development and execution of a test plan, test scripts, test cases and test input data. Contractor will lead all testing efforts (except for user acceptance testing (UAT)).

Defects identified in testing must be categorized as defined in Attachment 2 (Service Level Agreement).

Description Activities/Work Products

Testing

Testing Plan

Test Cases/Scripts

Test Results

Deliverable Expectations Document

1.4.1 Objectives

1. Prepare a detailed plan to test all aspects of the System and implement a tracking tool to log

System defects from identification through resolution.

2. Track expected versus actual test results, track all defects and resolutions, and document rework and retesting efforts for all tests and defect types.

1.4.2 Activities

• Develop test plans for implementation.

• Manage the test environment.

• Develop detailed test conditions, prepare test scripts, and utilize automated testing tools as appropriate to facilitate the testing process.

• Conduct testing activities as shown in the following table.

Testing Definition Participants Timing

Unit Testing Test the individual units of source code or smallest portion of data that will be included in the unit test.

Contractor During the configuration and development, completed satisfactorily before System Testing

Integration Testing

Test an assemblage of units to ensure they work properly together.

The Contractor will perform integration testing to validate the successful exchange of

Contractor, third-party entities, external or internal stakeholders as appropriate

During Integration Testing and System Testing

Testing Definition Participants Timing information between all interfacing systems and the System. The Contractor will coordinate interface testing with third-party entities and OCA.

API Testing Test all inbound and outbound APIs and document all success and failure results.

Contractor, third-party entities, external or internal stakeholders as appropriate

During Integration Testing and System Testing

System Testing

Test the entire System including components that will be integrated within the hosted platform. System testing will be performed with functional requirements and address the information flow in the System.

The Contractor will perform end-to-end System Testing and resolve any defects discovered, until System test results are produced to demonstrate the successful operation of the System, ensuring that the System is functioning, performing, and processing documents and data correctly.

Contractor, third-party entities, external or internal stakeholders as appropriate

After completion of development (“code complete”) and before UAT

Security/ Intrusion Testing

Test the authentication, authorization, and data protection of the System.

Contractor, third-party entities, external or internal stakeholders as appropriate

Before first cutover

User Acceptance Testing

Validate end-to-end business processes, including the business intelligence tool, the System setup, user access, user interface, and the APIs. Verify the System conforms to the expected and intended use. Verify performance on business-critical functions and confirm application integrity.

The Contractor shall support UAT testing activities conducted by OCA and business stakeholders and resolve defects to ensure the System functions properly and

OCA and business stakeholders

After System Testing and before each cutover

Testing Definition Participants Timing meets the acceptance criteria for exiting the testing phase.

Stress/ Performance Testing

The Contractor shall perform performance testing to validate the eventual full-scale use of the System by all business stakeholders, including mimicking the anticipated growth in System usage and data storage requirements. The Contractor shall continue performance testing until performance measures are met and are expected to be met under full operational conditions.

Contractor During System Testing and before UAT

Regression Testing

Retest the System following software deployments to ensure that faults have not been introduced/uncovered. Common tests include re-runs of previous functional tests and confirmation that previously fixed faults remain resolved.

Contractor After any software deployment

• Support UAT.

• Resolve defects.

• Record and submit test results.

1.4.3 Work Products

1. Testing Plan – Contractor should perform all initial tests. Testing plan must describe the procedures to be used in performing and completing all testing of the System including:

a. Systems integration testing per OCA-acceptable response times.

b. Stress/performance testing, including pass criteria that can handle the transaction load expected.

c. Security/intrusion testing, including meeting security controls delineated in TAC 202.

d. Test data creation approach, including data refresh process.

e. Approach to test documentation (e.g., test cases, test scripts, test case matrices added as design progresses).

f. Configuration management for each test level.

g. Approach to traceability to both the requirements and the design.

h. Approach to quality control/quality assurance.

i. Automated test usage (optional but preferred).

j. Approach to user acceptance testing (UAT).

k. Defect remediation release strategy and regression testing.

l. Entrance and exit criteria for each test level including alignment with industry standards.

2. Test Cases/Scripts –

a. Step-by-step documentation of interaction between user and System and the expected behavior and pass/fail criteria for testing.

b. Test scripts that provide coverage of the System to ensure that all critical aspects have been properly tested.

3. Testing Results –

a. Test date.

b. Person(s) conducting the test.

c. Test results.

d. Defects discovered (including severity and description).

e. Retest date and results if defects discovered.

f. Justification for terminating testing (for example, positive test results).

1.5 Data Migration

The Contractor will plan, develop processes, and implement a data conversion and migration plan to migrate the existing data in the database from the current public safety report system to the System.

Description Activities/Work Products

Data Migration Data Conversion and Migration Plan

Migrate Data

Deliverable Expectations Document

1.5.1 Objectives

1. Move data specified by OCA from the current public safety report system to the System, with all data elements mapped to the appropriate fields and locations.

2. Verify successful migration of data to the System.

1.5.2 Activities

• Develop the Data Conversion and Migration Plan.

• Conduct tests to validate migration of data.

• Migrate data.

1.5.3 Work Products

1. Data Conversion and Migration Plan – must address the following:

a. Approach to conversion, cleansing and migration.

b. Approach to risk management for data conversion effort.

c. Approach for testing migration or converted data.

d. Approach to reporting the number of records successfully converted vs. errors or exceptions.

e. Approach for cleansing data to prepare it for loading to the proposed System that is refined as necessary.

f. Approach to resolving data conversion errors and issues.

g. Approach for supporting OCA validation of converted data.

h. Tasks, timelines, and responsible parties for all conversion and migration tasks.

i. Entrance and exit criteria for each phase of the effort.

1.6 Training

The Contractor will be responsible for developing knowledge transfer and training plans, developing training materials to include training videos (tutorials), training guides, and conducting training for OCA personnel, stakeholders, and Authorized Users.

Description Activities/Work Products

Training Training Plan

1.6.1 Objectives

1. Train and/or provide training materials for each entity on the System functionality and how to perform their day-to-day tasks within the System.

This includes topics on:

a. Implementing the APIs to add/modify data.

b. Using the user interface to add/modify data.

c. General system operations including Jurisdiction configurations and management.

d. Using tools to create ad-hoc reports and running canned reports.

2. Train OCA staff and project team on the System functionality and how to perform their day-to-day tasks within the System. Deliver training courses defined in the Training Plan.

3. Additional staff training will be provided as requested from an Authorized User, their vendor, or local IT staff.

4. Ensure documentation and user guides are updated and complete.

1.6.2 Activities

• Prepare the Training Plan – including details on the different stakeholder groups trained, training methodology and the courses used for each group.

• Develop a detailed training curriculum – including presentations, online help, user guides, videos, and other materials.

• Deliver training courses – including those defined in the Training Plan.

1.6.3 Work Products

• Training Plan – Contractor shall create a Training Plan and provide training curriculum and materials that describe the following for the System:

a. Course list, duration of the course and method of course delivery.

b. Target audience role descriptions.

c. Specific learning objectives for each user to increase users’ readiness to perform their expected roles.

d. Lists of materials, facilities standards, equipment, user profiles, access procedures, work samples, and other items needed for each training session, including items that OCA is expected to furnish.

e. Training calendar indicating the specific attendees and locations for all user training sessions; the calendar shall also indicate any planned phases or iterations in the delivery of training.

1.7 Production Transition

The Contractor will deploy the System in accordance with the Cutover Plan. Deployment must include cutover to the System, activation of all interfaces, providing ongoing support, issue resolution, and conducting post-cutover assessment for each cutover.

Description Activities/Work Products

Production Cutover

System Deployment

Readiness Report

Updated Plans

Final Configuration

Integration Report

Cutover Completion Report

1.7.1 Objectives

1. Finalize and execute the activities identified in the Cutover Plan to transition the System into production.

1.7.2 Activities

• Confirm the overall readiness of the hosted infrastructure, APIs, and/or other third-party provided components to support the System and its operation in the production environment.

• System deployed into production.

• Confirm reporting.

• Submit updated versions of previously developed plans to reflect activities to be undertaken as part of production support.

1.7.3 Work Products

1. Readiness Report – documentation that indicates the System infrastructure, APIs, and/or other third-party components that are prepared in the production environment. This report is used to inform go/no-go decision.

2. Updated plans.

3. Final configuration – documentation of the final configurations including testing results.

4. Integration Report – Provide updates of how many stakeholders and vendors have connected, how many are left that need to connect, and timeline of stakeholders that must connect.

5. Cutover Completion Report.

1.8 Implementation Finalization

Upon cutover, the Contractor will finalize implementation by transitioning from its internal team dedicated to implementation to its internal team dedicated to support and maintenance. The Contractor will develop and provide a comprehensive Operation Procedure Manual which provides guidelines for the operation and use of the System. It should include processes, policies and workflows for the System and procedures for production support.

Description Activities/Work Products

Operations Support and Maintenance

Operation Procedure Manual

Monthly Report Template

Implementation Project Closeout Report

1.8.1 Objectives

1. Transition from implementation activities to production services.

1.8.2 Activities

• Establish online service level dashboard to ensure service levels are met.

• Establish monthly service level reporting templates.

1.8.3 Work Products

1. Implementation Project Closeout Report – includes the outlining of the project’s accomplishments against the project’s scope, budget, schedule and agreed service levels.

2. Monthly Report Templates – includes the template reports used to report the ongoing status of the System each month.

3. Operation Procedure Manual – includes outlining performance of regular maintenance, ongoing configuration, enhancements with respect to timeframes as well as support for stakeholders and Authorized Users. Includes procedures for updating new business rules, correcting defects found in the System and providing updated training documentation. Provide call center hours and approach to problem ticket(s) support and resolution. Provide communication channels as to how Customers can submit support tickets.

2. Production Services Production Services refers to those activities performed by Contractor following cutover of the System.

2.1 Operations, Maintenance & Support

Description Activities/Work Products

Operations, Maintenance &

Support

System Operations and Support

API Issues Report

Service Level Agreement and Service Level Requirements Reports

2.1.1 Objectives

1. Operate, maintain and support the System, ensuring that all requirements are continuously met.

2. Comply with the terms of the Master Services Agreement, including the Service Level

Agreement and Service Level Requirements.

2.1.2 Activities

• Provide ongoing operations support and maintenance.

• Maintain the environments with regard to timely upgrades and patching, especially for security purposes as well as ongoing configuration.

• Resolve support issues in a timely manner and consistent with the Service Level Agreement.

• Correct defects found in the System based on detailed requirements described in the

Requirements Traceability Matrix, the Statement of Work, and published test results.

• Update user and training documentation and online help to reflect changes that have been made to the System.

• Provide a web page that displays notification when the System is unavailable for scheduled maintenance or unscheduled outages.

• Provide electronic notification for all updates and fixes deployed to the Contractor’s System that could impact OCA, stakeholders, and Authorized Users.

• Provide timely support in compliance with the Service Level Agreement and Service Level

Requirements and to resolve problems with System processing, portals and all related interfaces.

• Provide all services required for preparation of System for production (1.4 Testing, 1.6 Training, and 1.7 Production Transition) for all subsequent releases, including patches, upgrades, and change orders.

2.1.3 Work Products

1. Service Level Agreement and Service Level Requirements Reports and Notifications – Provide all reports and notifications required by the Service Level Requirements in a timely manner.

d. Cutover Plan – The Contractor shall create a Cutover Plan that includes at a minimum: