Exhibit_IV_-_Statement_of_Work.pdf

Exhibit IV - Statement of Work

Upon contract award and execution, the selected Respondent will be responsible for project management and implementation services to successfully deploy the new CMS solution and provide ongoing hosting, maintenance, and production support services.

The following subsections describe the activities and high-level expectations specific to implementation and production services expected to be delivered by the Respondent.

1. Implementation Services

Implementation services include:

1.1 Project Management

1.2 Enterprise Analysis & Design

1.3 Build (Development & Configuration)

1.4 Testing

1.5 Training and Knowledge Transfer

1.6 Cutover Readiness and Production Go-Live

1.7 Post Go-Live and Transition to Support

1.8 Production Support and Maintenance during Implementation

OCDA intends for the project’s implementation approach and schedule to generally align with Figure 1:

Sample of High-Level Implementation Plan, below, which reflects the implementation services and the associated key activities and work products outlined in this RFP. OCDA expects a phased implementation, initially learning from a preliminary (e.g. pilot) phase and deploying groups of functional processes into a production environment. Respondents can deviate from this high-level plan and propose an approach that has proven to be successful with other customers, as appropriate.

1.1 Project Management

The Respondent will provide project management support for the entire duration of the project. The

Respondent will provide resources to execute all project management tasks, functions, and activities described in the table below (Project Management Activities and Work Products). In addition, the

Respondent will maintain and update project activities and associated work products on a timely, regular, and ongoing basis.

Objectives:

Figure 1: Sample of High-Level Implementation Plan

Develop an understanding of OCDA’s environment and challenges to deliver an expedient, seamless and minimally disruptive implementation of the new CMS solution.

Engage with OCDA technical and business stakeholders to generate understanding and trust in the product and implementation team.

Figure 2: Project Management and Work Products identifies the minimum Project Management activities the Respondent shall be responsible for.

Figure 2: Project Management and Work Products

Activities Work Products

Conduct Project Pre-Planning and

Preparation – Conduct planning meetings with OCDA and other stakeholders as required to confirm the schedule, plans, documentation, and other logistics for the project related to project management responsibilities.

Develop Project Kickoff Materials and Conduct a Project Kickoff

Meeting with key stakeholders within thirty (30) days of contract execution.

Develop a baseline project schedule to reflect the project timelines, milestones, and deliverables.

Develop weekly status reports and schedule ongoing communications for the project.

Provide Ongoing Project

Management Duties – Provide weekly project plan and schedule updates, weekly status reports, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the

Respondent’s Project Manager shall participate in Project Steering

Committee meetings and any other meetings as required by OCDA.

1) Project Kickoff Materials – Describes an overview of the project objectives, plans, project scope and schedule, introduces the Respondent’s project team and roles and responsibilities, and outlines project start-up procedures.

2) Project Management Plan – Describes the overall project management approach and schedule throughout the lifecycle of the CMS solution implementation project. The Project

Management Plan shall define the following (at a minimum):

a) Project Objectives and Scope

b) Project Governance - Defines the governance structure and decision-making process and escalation strategy, including outcome tracking in a decision log for resolution of project risks and issues.

c) Project Organizational Chart - Identifies the project roles and responsibilities for the project.

d) Scope Management Process – Defines the process and procedures for managing scope, including any additions, subtractions, and/or modifications made to the original scope.

e) Risk and Issue Management Plans & Logs – This includes a Risk and Issue Management Plan, Escalation

Plan, and Risk and Issue Register.

f) Status Reporting Process and Templates

g) Document Management and Collaboration Process – Describes the location and guidelines for storing, accessing, and managing project documents and artifacts.

h) Quality Management Plan – Describes the approach to sustaining a culture of quality throughout the project lifecycle. The quality management model shall describe:

i) Quality tools / techniques / activities.

ii) Approach to standardization and focus on business outcomes.

iii) Methodology for monitoring quality performance and process adherence.

Activities Work Products

i) Integrated Change Management Process – Describes how change is managed throughout the project lifecycle, including but not limited to formal change requests and defined governance for different levels of change. The change management process includes identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as solution design and acceptance criteria.

j) Resource Management Process – Describes the on-boarding and off-boarding process for Respondent and

OCDA project resources.

k) Communications Management Strategy – Describes communication methods for core project management activities and escalations to senior leadership.

l) Deliverable Management Strategy – Describes the approach to deliverable planning, creation, submission, review, and approval.

Deployment Planning – Conduct workshops with OCDA and other stakeholders as appropriate to finalize approach for deploying the solution into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.

Develop the Project Deployment

Plan –Develop the plan using information gathered in the workshops.

Update, maintain, and revise the

Project Deployment Plan, as necessary – Maintain a detailed

Project Deployment Plan for the selected phasing alternative that includes the approach, activities, milestones, schedule and schedule dependencies, risk identification and mitigation strategies, and pre-cutover readiness assessment activities.

Finalize the Project Deployment

Schedule – Once OCDA has approved the Project Deployment Plan, finalize the project deployment schedule.

3) Project Deployment Plan – Describes the finalized approach for deploying the solution into production including any phasing strategies, site specific considerations, and benefits and risks of the specified strategy. The Project

Deployment Plan shall define the following (at a minimum):

a) Summary overview of the current environment and considerations for deployment.

b) High-risk transition areas and impact, mitigation strategies, and recommended mitigation actions.

c) Key risks, based on finalization of phasing approach.

d) Production cutover consideration(s).

e) Key decisions that impact the schedule.

f) Updated high-level project roadmap and deployment schedule.

g) Updated project organizational chart, if / as necessary.

Finalize the project organization chart

Develop Baseline Project Schedule to reflect the project timelines, milestones, and deliverables.

Update/publish the schedule and work plan on a weekly basis to reflect any changes from the baseline plan originally agreed to during the project initiation.

4) Baseline Project Schedule and Work Plan – Describes project activities and durations that are assigned to project stakeholders. The Project Schedule will define the following (at a minimum):

a) Project Milestones.

b) Project Tasks (including dependencies and durations).

c) Project Resources (including OCDA, selected Respondent, and third-party Respondents as identified) assigned to each activity and their required level of effort.

d) Project Deliverables.

e) Deliverable approval periods compliant with OCDA’s process as described in the Deliverable Expectation

Documents.

f) Critical Path Analysis.

Create a Configuration

Management Plan and

Configuration Items Log

5) Configuration Management Plan – Describes the approach for managing programming changes, third-party software, and configuration settings made in the system, including testing, final approval of deployment, and actual deployment. The

Configuration Management Plan defines the following (at a minimum):

a) Scope and granularity of configuration management.

b) Configuration item taxonomy.

c) Configuration data tools/ integration.

d) Approach to consistently tracking hierarchical relationships among application and infrastructure components.

e) Configuration Items Log - captures configuration items in a register, including identified baselines under control that complies with the requirements of the PMO.

Create a Stakeholder Outreach and

Communication Plan

Perform outreach to stakeholder groups as defined in the plan to ensure a successful implementation and user adoption of the system.

6) Stakeholder Outreach and Communication Plan – Describes how stakeholder groups inside and outside of OCDA are impacted by the CMS solution. The plan will define the following (at a minimum):

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

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

c) Tools Or Measures to Assess Progress: Information on how the Respondent intends to measure progress and any tools required.

d) Established Timeline: Timeline for outreach activities.

e) Stakeholder Engagement Table: Submit the following table of proposed methods of outreach and involvement for various stakeholders:

Methods of

Engagement

Stakeholder Purpose Level of

Involvement

2 <Insert methods of engagemen t>

3 Recorded webinar

4 <Identify stakehold er group>

5 Prosecuto rs

6 <Insert purpose of the engagemen t>

7 Awareness of upcoming integration changes

8 <Estimate duration of involvement

9 Recorded webinar available one month prior to go live

Develop Deliverable Expectation

Documents (DEDs) – Define the approach and criteria for satisfactory completion and approval of all deliverables defined in the contract.

7) Deliverables Expectation Documents (DEDs) – for all project Deliverables

1.2 Enterprise Analysis and Design

The Respondent will conduct requirements validation of the functional and non-functional requirements identified and provided in Error! Reference source not found. and Error! Reference source not found. 4 –

Non-Functional Requirements of this RFP.

The Respondent will collect and review the current state data, hold visioning sessions with stakeholders, and then document and finalize design decisions. The Respondent will introduce, train, and support the workgroups and stakeholders in data collection tasks required for the design process. The Respondent will develop the final detailed design document for the CMS solution and verify completeness and accuracy.

Objectives:

Validate the Respondent’s understanding of the requirements and submit an updated Requirements

Traceability Matrix.

Expose OCDA and appropriate stakeholders to how the system will look and function early on and continuously throughout the design and development process.

Follow an agreed upon methodology to clearly define design-level requirements for the future-state solution that are based on stakeholder inputs and collaboration.

Figure 3: Enterprise Analysis and Design Activities and Work Products identifies the minimum

Enterprise Analysis and Design activities the Respondent shall be responsible for.

Figure 3: Enterprise Analysis and Design Activities and Work Products

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 and the future-state solution.

Provide an updated Requirements

Traceability Matrix.

Review the functional and non-functional requirements defined in

Error! Reference source not found.

and Error! Reference source not found. 4 – Non-Functional

Requirements to validate the

Respondent’s understanding of the requirements to meet the State’s expectations and identify areas for discussion.

Conduct joint validation sessions with OCDA and appropriate stakeholders to validate understanding of identified requirements.

Submit an updated Requirements

Traceability Matrix.

1) Requirements Analysis and Traceability Matrix

(RTM) – Describes how project requirements are delivered during the project lifecycle, from the RFP to production cutover. The RTM is used to validate that all requirements are delivered and satisfied to defined standards (quality, testing, design, or other). The RTM shall define the following (at a minimum):

a) Requirements Definition, e.g.:

i) Type (e.g., Functional, Non-Functional)

ii) Requirement ID

iii) Level 0 Capability

iv) Level 1 Capability

v) Requirement / Description

vi) Priority

b) Proposal Response, e.g.:

i) Requirement Met

ii) Suggested Modification to Requirement or

Clarifying Comments

c) Enterprise Analysis & Design Review, e.g.:

i) Scope Clarifications/ Gaps/ Determination

ii) Design Considerations

d) Requirements Ownership, e.g.:

i) Stakeholder Group

ii) Requirement Owner

e) Traceability to Validation Artifacts/ Processes, e.g.:

i) Design Document(s)

ii) Business Process/ Transaction(s)

iii) Test Plan(s)

iv) Test Script(s)

Conduct workshops - Engage stakeholders to collect design-level requirements.

Create future state Conceptual

Design - Create conceptual future state design documentation for application, data/content, integration architectures, and all activities required to achieve the overall application architecture associated with the CMS solution.

2) Conceptual Design Documentation – Describes the implementation methodology and solution design specifications. Conceptual Design Documentation will define the following (at a minimum):

a) Description of implementation methodology (e.g., agile, waterfall, etc.).

b) Description of user interface(s).

c) Detail specifications for business rules, external system interfaces, validations, screen layouts, and user interfaces.

d) Solution software configuration and setup requirements.

e) Specifications for solution customizations.

f) Security design and programming specifications.

g) Inventory of Reports and/or Analytics.

h) Inventory of Integrations and business descriptions.

1.3 Build (Development and Configuration)

The Respondent will document and complete the solution build as defined by the final design specifications.

Objectives:

Perform all necessary execution activities to implement the solution, including integrations with external systems and converted data.

Figure 4: Build (Development and Configuration) Activities and Work Products identifies the minimum Build (Development and Configuration) activities the Respondent shall be responsible for.

Figure 4: Build (Development and Configuration) Activities and Work Products

Activities Work Products

Develop the Solution

Implementation Plan – Describe the solution implementation approach throughout application design, interface design, conversion design, etc.

1) Solution Implementation Plan – Describes the CMS solution management tools for all development environments and how they will be used to manage all development efforts using industry-standard software development tools and methodologies. The Solution

Implementation Plan shall define the following (at a minimum):

a) Industry-standard software development tools and methodologies leveraged for all development environments.

b) How the Solution conforms to defined standards for

System Design and Systems architecture.

c) Approach to gather design-level specifications and develop the design documentation for custom built components such as interfaces.

d) Detailed plans for integrating the solution with systems in use by OCDA, criminal justice partners, and other external organizations.

e) Respondent shall provide the sub-component plans that describe the following (at a minimum):

f) Security Plan – Describes the approach for monitoring the CMS solution security and keeping solution security capabilities current with evolving known and potential security threats. The Security

Plan shall define the following (at a minimum):

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

(2) Strategy to identify and categorize incidents.

(3) Process to communicate, contain, eradicate, and recover from incidents.

(4) Post-incident activities to ensure continuous security improvement.

g) Disaster Recovery & Business Continuity Plan –

Describes the approach for initiating disaster recovery and/or business continuity procedures to be undertaken in the event of a disaster affecting solution. The Disaster Recovery & Business

Continuity Plan shall define the following (at a minimum):

i) Approach for ensuring all information necessary to restore operational service in the event of a disruption are correct and up to date.

ii) Functional roles and responsibilities of recovery teams.

iii) Description of recovery scenarios that can be implemented.

iv) Recovery activities to be exercised and frequency of testing.

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

h) Infrastructure Support Plan – Describes the following

(at a minimum):

i) Definition of each solution environment (e.g., production, staging, test, etc.).

ii) Approach for maintaining application and infrastructure component consistency across all

CMS solution environments.

iii) Approach for certifying and/or providing quality assurance of the CMS solution environments.

iv) Approach for managing environment changes including management of test and deployment of new releases while maintaining capacity to apply hotfixes to production.

v) Approach for communicating and supporting testing of the CMS solution environments with external organizations/systems.

vi) Approach for establishing initial capacity and anticipated growth requirements for the CMS solution including but not limited to storage, processing, and network bandwidth.

vii) Approach to performance tuning to ensure the solution operates optimally and within defined serviced levels, Services shall include (at a minimum):

(1) Impact analysis of upcoming patches and upgrades.

(2) Modifications to Respondent-provided components and configurations to support upcoming patches and upgrades.

(3) Testing and deployment of patches and upgrades in all environments.

(4) Continuous health checks of the production system.

(5) Continuous tuning and other required system level administration.

(6) Recommendations for system performance tuning.

(7) Application modifications required to support scheduled infrastructure upgrades.

viii) Approach for monitoring on-going usage and growth patterns of the CMS solution resources.

including for cumulative growth and peak usage patterns,

ix) Approach for deployment of additional capacity as specified in the original plan and per the results of on-going capacity monitoring.

x) Approach for preventative and unplanned services to the CMS solution services.

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

i) Communication protocols inclusive of OCDA and additional users for infrastructure services.

Develop the solution based on the requirements of the RFP, approved

Implementation Plan, and detailed design requirements identified in the previous phase through configuration, interface development, and other applicable development-related activities according to the

Respondent’s software implementation methodology.

Integrate all components of the solution.

Develop and/or modify all reports.

2) Respondent must outline in their response how they will seek opportunities to involve stakeholders early on, including through demonstrations of prototypes, creation and distribution of business design documents, and access to sandbox environments to preview working functionality.

Develop a detailed Conversion and

Migration Plan and coordinate all conversion activities.

Convert/Migrate Data – Work closely with the designated resource

(e.g., incumbent Respondent or OCDA technical staff) to create data conversion algorithms, and data maps, identify impacts on existing systems and develop procedures for handling problems such as invalid formats of data values requiring validation.

3) The Data Conversion and Migration Plan – Describes the scope and approach to converting and migrating legacy application documents and data, where applicable, into the new CMS solution. The Data Conversion and

Migration Plan will define the following (at a minimum):

a) Scope and approach.

b) Data structure, volume, and quality.

c) Data mapping between source to target data for all fields to be converted.

d) Data transformation rules.

e) Testing approach.

f) Data validation process and exception reports.

g) Communication plan(s).

Conduct Cutover Planning Activities and Create a Cutover Plan - Perform go live cutover planning activities to assess transition readiness, go/no-go

4) The Cutover Plan will define the following (at a minimum):

criteria, and fallback positions to be taken if no-go conditions are encountered for individual deployments.

a) A preliminary cutover schedule that clearly defines key milestones, deliverables, tasks, and responsibilities.

b) An updated cutover schedule prior to go-live.

c) Pre-cutover checklist and post-cutover evaluation criteria.

d) Cutover milestones to assess production readiness, go/no-go criteria, and fallback positions.

e) Transition readiness assessments, 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 CMS solution.

1.4 Testing

The Respondent will develop, conduct, and provide support to OCDA and the applicable stakeholders in the development and execution of a test plan, test scripts, test cases and test input data. Respondent will lead all testing efforts (except for UAT). See Figure 5: Scope of Testing Types and Figure 6: Defect

Definitions for more detail.

Objectives:

Prepare a detailed plan to test all aspects of the CMS solution and implement a tracking tool to log system defects from identification through resolution.

Track expected versus actual test results, track all defects and resolutions, and document rework and retesting efforts for all in-scope test and defect types (refer to the tables below).

Figure 5: Scope of Testing Types

Testing Definition Participants Timing

Unit Testing

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

Respondent

During the Execution

Phase (e.g., configuration and development);

completed satisfactorily prior to moving into

System Testing

Integration Testing

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

The Respondent shall perform integration testing to validate the successful exchange of information between the CMS solution and all interfacing systems. The

Respondent shall coordinate interface testing third party entities.

Respondent, 3rd party

Respondents, External or

Internal

Stakeholders as appropriate

During Interface

Development and

System Testing

System Testing

Test the entire solution including components that will be integrated on the hosted platform. System tests are executed with functional requirements and address the information flow in the system, where the underlying assembled units are no longer addressed separately, but collectively as a whole. System testing often is the test that indicates to the development community whether the system is behaving as required, verifies, and validates that a system can work in production.

The Respondent shall 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.

Respondent, 3rd party

Respondents, External or

Internal

Stakeholders as appropriate

Occurs once development is “code complete”; Must be completed satisfactorily prior to User

Acceptance Testing

Security/Intrusion

Testing

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

Respondent, 3rd party

Respondents, External or

Internal

Stakeholders as appropriate

Must be completed prior to cutover

User Acceptance

Testing (UAT)

Validate end-to-end business processes, comparing actual vs.

expected results. UAT validates the system setup for transactions and user access, confirms the expected and intended use of the system, verifies performance on business-critical functions, and confirms application integrity.

The Respondent shall support UAT testing activities conducted by

OCDA and business stakeholders and resolve defects to ensure the

CMS solution functions properly and meets the acceptance criteria for exiting the Testing Phase.

OCDA &

Business

Stakeholders

Occurs after System

Testing and Prior to go live

Stress/Performance

Testing

Test ‘transaction processing’ capacity of the ‘system’ when the system refers to a process, application, or infrastructure to look at behavior with standard, increased and decreased workload.

The Respondent shall perform performance testing to validate the eventual full-scale use of the system by all users, including mimicking the anticipated growth in the number of users, documents, and storage requirements as the system is deployed. The

Respondent shall continue performance testing until performance measures are met and are expected to be met under full operational conditions.

The Respondent shall work with third-party network resources to perform a network analysis to determine any likely network deficiencies leading to poor system testing results.

Respondent

Part of System Testing;

must be completed prior to UAT

Regression Testing

Retest a previously tested ‘system’ following modification to ensure that faults have not been introduced/uncovered because of the changes. Common tests include re-runs of previous functional tests and checks of re-emerging of previously fixed faults.

Respondent Between Phased

Deployments

Figure 6: Defect Definitions

Defect

Level Definition

A documented Defect that causes:

a) Complete application failure or application unavailability

b) Application failure or unavailability in one or more of the Authorized Users locations, or

c) Systemic loss of multiple essential system functions.

Defect

Level Definition

A documented Defect that causes:

Repeated, consistent failure of Essential Functionality affecting more than one user or

Loss or corruption of data.

3 A Level 1 Defect with an existing Circumvention Procedure, or a Level 2 Defect that affects only one user or for which there is an existing Circumvention Procedure.

4 A Documented Defect that causes failure of Non-Essential Functionality or a cosmetic or other Documented Defect that does not qualify as any other service level defect.

Figure 7: Testing Activities and Work Products below provides typical activities and work products that occur during the project phase.

Figure 7: Testing Activities and Work Products

Activities Work Products

Develop Test Plan based on Error!

Reference source not found. Scope of Testing Types which outlines the scope of testing, Respondent’s responsibilities, and defect definitions in Figure 6: Defect

Definitions

1) The Test Plan – Describes the approach to conducting all in-scope testing activities. The Test Plan shall define the following (at a minimum):

a) Test objectives.

b) Testing scope (e.g., features/functions to be tested or not tested).

c) Key decisions, issues, and constraints.

d) Testing assumptions, risks, and contingencies.

e) Test types:

i) Unit Testing

ii) Integration Testing

iii) System Testing

iv) Security/Intrusion Testing

v) User Acceptance Testing (UAT)

vi) Stress/Performance Testing

vii) Regression Testing

f) Test management approach:

i) Test environment(s).

ii) Test tool(s).

iii) Test coverage and scripts.

iv) Test data (e.g., how test data are created and refreshed).

v) Test volume.

vi) Frequency of tests.

vii) Test automation/ re-use.

viii) Change management.

ix) Release Management.

x) Test quality metrics.

xi) Defect tracking.

g) Defect remediation release strategy and regression testing.

Setup and Manage Test

Environment – Plan, design, and implement a test environment that replicates the production environment and network connectivity. The Respondent shall load the test environment with enough data to perform effective testing.

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

2) Test Cases and Test Scripts – Describes the conditions and procedures to determine if the new CMS solution is working as expected. A test case can have one or multiple test scripts. Test scripts include the sequence of instructions to be performed on the new CMS solution to verify it is performing as expected. Test Cases and Test

Scrips shall define the following (at a minimum):

a) Test Case ID

b) Test Case Summary

c) Related Requirement

d) Prerequisites

e) Test Script / Procedure

f) Test Data

g) Expected Result

h) Actual Result

i) Status

j) Comments

k) Tester

l) Data of Test Execution

m) Test Environment

Conduct System Testing and

Resolve Defects – For each defect identified during testing, establish a prioritization rating indicating the relative sequence to fix defects as defined in Figure 6: Defect

Definitions in the previous section.

3) System Integration Test Results – Defines the following

(at a minimum):

a) Date scenario was executed.

b) Person who executed the scenario.

c) Test result status (pass/fail).

d) Defects discovered.

Submit Final System Testing

Results – Perform performance testing to validate the eventual 300% full-scale use of the system by all

OCDA users, including mimicking the anticipated growth in the number of users, documents, and storage requirements as the system is deployed.

Continue performance testing until performance measures are met and are expected to be met under full operational conditions.

Submit final system testing results.

e) Retest dates and results.

f) Justification for exiting System Test stage.

Support UAT, Defect Resolution, and Submit UAT Results.

4) UAT Support and UAT Results - Ensures UAT is completed with defects resolved to ensure the CMS solution are functioning properly. For each test scenario during UAT, the test results shall define the following (at a minimum):

a) Acceptance test results for the overall solution.

b) Date scenario was executed.

c) Person who executed the test scenario.

d) Test result status (pass/fail).

e) Defect, priority, and resolution log.

f) Retest dates and results.

g) Justification for exiting UAT stage.

1.5 Training and Knowledge Transfer

As part of the Services to be provided under this SOW, the Respondent will be responsible for developing

Knowledge Transfer and Training Plans, developing Training Materials, and conducting OCDA Training and Evaluations, where appropriate.

Objectives:

Utilize a train-the-trainer approach as well as end user training - based on the size and geographic location of the user group being trained.

Deliver training courses defined in the Training Plan and provide a Training Completion Report.

Figure 8: Training and Knowledge Transfer Activities and Work Products identifies the minimum

Training and Knowledge Transfer activities the Respondent shall be responsible for.

Figure 8: Training and Knowledge Transfer Activities and Work Products

Prepare a Training Plan – Detailing the different stakeholder groups of trainees and the training methodology and courses to be used for each.

Develop a detailed training curriculum - Prepare training materials, and deliver training to users, technical staff, and personnel who will be responsible for training new end users and providing refresher training to other OCDA or external staff.

1) Training Plan – Describes the approach for delivering training during the project lifecycle. The Training Plan will define the following (at a minimum):

a) Course list.

b) Target audience role descriptions.

c) Specific learning objectives for each user and support role to be used to assess 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 OCDA is to supply and/or furnish.

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

2) Training Curriculum and Materials – Defines the following (at aa minimum):

a) Course presentation materials/user manuals (Trainer

Version).

b) Course presentation materials that are current with the configuration and production release.

c) Recorded training videos.

d) Student training exercises.

e) Pre-assessment and post-assessment materials.

f) Training data specifications for training exercises (if applicable), including training data initialization procedures.

Deliver training courses defined in the Training Plan and provide a

Training Completion Report.

Provide adequate end user support whether through user manuals or on-line help.

3) Training Completion Report – Describes the results of training courses delivered as described in the Training

Plan. The Training Completion Report shall define the following (at a minimum):

a) Summary of all training provided including course, date, and attendees.

b) Summarized training exercise results.

c) General observations of completed training and future training recommendations.

d) Training satisfaction survey results (survey to be distributed to all stakeholders that participated in formal training classes).

1.6 Cutover Readiness and Production Go-Live

Figure 9: Cutover Readiness and Production Go-Live Activities and Work Products

Activities Work Products

Confirm the overall readiness of the hosted infrastructure and/or other third-party provided components to support the CMS solution’s application and operation.

1) Readiness Report to inform Go/No-Go decision.

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

2) Updated Project Implementation Plans – The list of associated artifacts is below; each plan should include the minimum set of components defined within this SOW and as agreed to with OCDA during the implementation project:

a) Risk and Issue Management Plans (note: associated

Logs would carry over from the project to production)

b) Integrated Change Management Plan

c) Deployment Plan

d) Configuration Management Plan

e) Stakeholder Outreach and Communication Plan

f) Security Plan

g) Disaster Recovery and Business Continuity Plan

h) Infrastructure Services Plan

i) Help Desk Support Plan

j) Test Plan

k) Training Planning, Curriculum, and Materials

Submit the final As-Built System documentation.

3) Final As-Built System Documentation – Provide final as-built configuration documentation of each of the delivered environments, including the results of smoke tests of those environments. Respondent shall provide documentation specific to OCDA’s CMS solution implementation.

4) Technical Documentation for Knowledge Transfer –

Provide technical documentation of sufficient depth and clarity to enable technical personnel to understand the underlying structure and function of system components to troubleshoot the application interfaces (including platform, network, and security interfaces), to perform all global and regional administration and operation duties, and to plan for potential future integration with other applications.

Submit the Cutover Completion

Report.

Cutover to Production and start providing Production Services once the first pilot stakeholder group is in production.

Submit updated roles and responsibilities, and resumes, for key production support staff.

5) Updated Cutover Plan and Schedule - Update the preliminary draft of the Cutover Plan created as part of the

Project Management phase with the finalized set of activities to cutover the CMS solution into Production, according to a phased approach whereby the solutions will be deployed in groups of OCDA stakeholders over time.

a) Final Cutover Plan shall include a detailed schedule that clearly defines key milestones, deliverables, tasks, and responsibilities. Using the

Cutover Plan as the guide, the Respondent will lead the deployment/cutover effort.

b) Cutover Completion Report - Respondent shall provide a Cutover Completion Report that validates the full transition of the CMS solution into production.

1.7 Post Go-Live and Transition to Support

The Respondent will provide support for initial production usage of the system. Respondent will coordinate transition to Respondent’s ongoing support and maintenance team upon achieving Go-Live and initiating production. Prior to deployment, the Respondent’s team will develop processes, policies, and procedures for post-production support.

Objectives:

Ensure adoption and successful transition for all users.

Keep the project active until all deliverables have been accepted in accordance with accepted criteria before closeout.

Figure 10: Production Support Activities and Work Products identifies the minimum Production

Support & Transition activities the Respondent shall be responsible for.

Figure 10: Production Support Activities and Work Products

Activities Work Products

Provide a Service-Level

Performance Dashboard for OCDA to monitor performance against Error!

Reference source not found..

Monitor the production solution to report on operations and performance metrics against service levels requirements defined in Error!

Reference source not found., transaction volumes, status of application support, and problem management activities.

1) Service-Level Performance Dashboard – Describes service performance and is used to enhance Respondent and OCDA relationship management through open performance communication. The Service-Level

Performance Dashboard will define the following (at a minimum):

a) Actionable strategies and remediation plans.

b) Management of contract performance.

Complete project closeout and production readiness activities –

Ensure the following are addressed:

- OCDA has accepted all deliverables.

- All outstanding issues and defects have been resolved or addressed.

- Document lessons learned and best practices identified during the project.

- All project artifacts have been placed in the project repository.

- Transition has been completed to operations, maintenance, and/or business.

- Transition Open Defects to Support

– any noted deficiencies will be enumerated and associated action plan provided including timing for correction of each such deficiency.

- Transfer knowledge to the solutions support staff.

2) Project Closeout Report – Provide final report outlining the project’s accomplishments against the project scope, budget, schedule, and SLAs.

3) Monthly Production Support Templates – Create initial templates of monthly production support reports for

OCDA to verify that the reports are sufficient and accurate before the project closes. Reports shall include the following:

a. Maintenance services completed per period.

b. Maintenance services in progress per period.

c. Maintenance services planned next period.

d. Upcoming planned release schedule (minimum of 6 months forward looking).

e. Risks and issues.

The Respondent and OCDA will agree on additional points of contact and a reporting structure and schedule to support day-to-day operations and reviews of the

Respondent’s overall performance.

These may include technical, financial, and service level requirements reviews as well as the resolution of other operational issues.

Reporting structures will be documented and maintained by the

Respondent in an online repository accessible to OCDA’s management team. A regular meeting schedule will be established for the reporting levels outlined in this document. The

Respondent must provide processes and procedures acceptable to OCDA that can be used to manage day-to-day relationships in meeting Service Level

Requirements and shall include:

- Escalation

- Contract change management; and

4) No work product associated

- Performance reporting (e.g., Service

Level Requirements (SLRs), project status, outstanding service request status) as outlined in the Error!

Reference source not found..

Participate in lessons learned activities led by OCDA - Help the project team and stakeholders share knowledge gained from the project to facilitate repeating desirable outcomes and improvements for future projects and avoiding undesirable outcomes.

5) No work product associated

1.8 Production Support and Maintenance during Implementation

The Respondent shall provide ongoing support and maintenance services during the implementation phase of the solution’s design and build, as necessary depending on agreed-upon phasing approach of solution launch (i.e. maintenance of solution of solution after phase 1 of Go-live, while subsequent phases are still in development). A final comprehensive list of services will be included as an agreement in the contract between OCDA and the Respondent.

The Respondent shall be responsible for providing production services as agreed to in the final contract and the updated plans listed this SOW once the first site is in production. The Respondent shall update the plans annually or as otherwise mutually agreed upon in the Agreement.

2. Maintenance and Operations

2.1 Overall Maintenance and Operations

OCDA requires the Contractor to provide ongoing production operations and maintenance services once the modern CMS Replacement is live in production. A final comprehensive list of services will be established before go-live of the solution as agreed upon by OCDA and the Contractor.

OCDA requires the Contractor to deliver production services as stipulated in the plans referred to in sections 1.6 – Cutover Readiness and Production Go-Live and 1.7 – Post Go-Live and Transition to

Support when the system is live. The Contractor must ensure the plans are revised annually or as otherwise mutually agreed upon.

2.2 Patch and Upgrade Support

OCDA requires the Respondent to:

a. Provide relevant patch and upgrade support services and service levels to ensure that a high-quality release management strategy can be executed during and after implementation.

b. Provide a release strategy with a typical schedule (quarterly, annually) with respect to patches, point upgrades, and major release upgrades. OCDA requires Contractor to maintain version compliance to remain on support and requires the option for OCDA to defer patches/upgrades.

c. Provide tools and documentation to be provided to facilitate patches or upgrades.

d. Have patch/upgrade support options and services for client-hosted vs. single-tenant SaaS vs. multi-tenant SaaS support vs. any other cloud-based models offered.

e. Identify any continuous improvement efforts underway or planned to improve the quality of patch/upgrade support services.

f. Establish a patch management process to be in place including the cadence (e.g., patch cycle), types of patches generally applied, approach to systems, and testing.

g. Establish an approach and process in place to support third-party patch releases (e.g., browser updates, windows updates, etc.).

h. Establish an approach to regression testing as it relates to ensuring that technical debt is not introduced as part of future patches.

2.3 Enhancements

OCDA requires the Respondent to:

a. Ensure a management approach for application enhancements, such as assessment of change impact, estimation of required effort to implement the change and change approval requirements.

b. Have a technical approach to enhancements, such as configuration management, documentation requirements, integration testing, regression testing, acceptance testing, and deployment.

c. Have an established approach to process future enhancement requests, including methodology for pricing (e.g., function point analysis) and future available resources to fulfill enhancement requests.

d. Collaborate closely with OCDA to address feature enhancements and product updates, including discussions on the prioritization of core product enhancement requests. The Contractor shall provide information on the frequency and scheduling of enhancements' releases. It is expected that the

Contractor will maintain a dedicated resource allocation for ongoing product development related to the proposed CMS solution. The Contractor shall demonstrate that there are planned investments for the future growth of their solution, such as major new features and technology upgrades.

2.4 Help Desk and Problem Ticket Support

a. Provide help desk and problem ticket support services and service levels. This includes associated support service cost and rate information in Attachment 5 - Cost Workbook.

b. Have established help desk services team that can quickly diagnose, resolve critical problems, and escalate timely.

c. Have established continuous improvement efforts underway or planned to improve the quality of help desk support services.

d. Provide an online knowledge base that can be accessed directly by users and technical staff to obtain answers to frequently asked questions or perform research on symptoms to identify resolutions to known issues.

3. Hosting

The respondent shall provide the modern CMS replacement based on a Software-as-a-Service (SaaS) or other cloud-based solution. OCDA defines a cloud-based model as an application model in which the software is owned, delivered, and managed remotely by the Respondent. Respondents are responsible for delivering software based on one set of common code and data definitions that is consumed in a one-to-many model by all contracted customers / users at any time on a pay-for-use basis or as a subscription based on use metrics.

4. Software and Licenses

The respondent shall utilize a pay-for-use or subscription model, with a consistent version of the application simultaneously offered to multiple customers, either through a multi-tenant public cloud model, a single-tenant, or an on-premises version. Respondent shall provide software licenses to ensure sufficient and consistent access to all identified OCDA users (currently and future users as necessary) to the CMS solution.