Attachment_2_-_Respondent_Proposal_Template.docx

Attachment 2 - Respondent Proposal Template

The structure of the Respondent Proposal consists of the following sections:

Section 1: Title Page Section 2: Respondent Proposal Transmittal Letter Section 3: Executive Summary Section 4: Table of Contents Section 5: Company Background & Experience Section 5A: Company Profile Section 5B: Company Background Section 5C: Respondent Experience and References Section 6: Product Overview Section 6A: Product Overview Section 6B: Product Roadmap Section 7: Functional Solution Section 7A: Background Section 7B: Functional Requirements Response Matrix Section 8: Technical Solution Section 8A: Conceptual Architecture Section 8B: System Architecture Section 8C: Technical Requirements Response Matrix Section 9: Implementation Approach & Understanding Section 9A: Staffing Requirements Section 9B: Project Management Approach Section 9C: Production Support and Maintenance during Implementation Section 10: On-Going Maintenance and Operations Section 10A: Overall Maintenance and Operations Section 10B: Patch / Upgrade Support Section 10C: Enhancements Section 10D: Call Center/Problem Ticket Support Section 11: Hosting Section 12: Software and Licenses Section 13: Payment Milestones and Deliverables Section 13A: Deliverables and Acceptance Criteria Section 14: Exceptions and Assumptions

1. Title Page

The Title Page shall include the title and number of the RFP, name and address of the Respondent(s), and the date of the offer.

2. Respondent Proposal Transmittal Letter

The Transmittal Letter is used to communicate the Respondent’s submission of a proposal in response to the requirements contained in the RFP. The Respondent Proposal Transmittal Letter must:

· Be signed by an employee who is authorized to legally bind the Respondent to all representations and commitments made in the Respondent’s proposal.

· Identify the name and contact information of the Respondent’s representative who may be contacted for all contractual matters.

· Indicate the Respondent’s acceptance of all the terms and conditions in this RFP except those items noted as exceptions in Attachment 16- Exceptions / Revisions to Model Contract of this proposal.

· Clearly state that the Respondent’s proposal is valid for one hundred and eighty (180) days after the submission of the proposal or, upon mutual agreement, for a specified, longer period.

· NOT contain any information related to cost.

3. Executive Summary

The Respondent shall submit an Executive Summary that outlines its Respondent Proposal. The Executive Summary shall, at a minimum, include the proposed products, and a summary of the proposed services of the submitting Respondent as well as any proposed subcontractors. This section should highlight key strengths of the Respondent’s proposal, and aspects which make it unique in addressing the needs of OCDA. The Executive Summary is intended to serve as an overview document that summarizes the contents of the Respondent Proposal. Marketing literature, excessive descriptions and detailed documentation are discouraged. While strict page limits are not mandated, Respondents are encouraged to be concise and direct in describing their response.

The summary must additionally summarize how the proposed solution aligns with the Respondent’s long term business strategy and the Respondent’s commitment to long term support for that solution, and why the Respondent is best qualified to implement and operate the CMS Solution. All cost information must be contained in Attachment 5 – Cost Workbook and not be included in any part of the Respondent Proposal Template or any other written materials.

4. Table of Contents

The Table of Contents shall outline the structure of the offer and include the critical elements as described in this RFP.

5. Company Background and Experience

OCDA is seeking a Respondent with proven experience and demonstrated success in assisting customers in designing, developing, and implementing a modern and robust prosecution CMS solution. For each Respondent participating in the project (including the prime Respondent and any proposed subcontracted vendors), complete the table in Figure 1: Organization Review to provide OCDA with an overview of the company organization. Duplicate the table as needed.

5.A. Company Profile

a. Provide a brief overview of your company, describing the history, size, mission, primary line of business, how its organized, and how its proposed products and resources that will be used to meet this RFP’s requirements using Figure 1: Organization Review.

Figure 1: Organization Review

Company Name

Address

Telephone Number

Website Address

Parent Company

Subsidiaries or Affiliated Companies

Date Company Founded

Number of years Company has been providing the Product or Service specified in this RFP

Most recent three (3) Fiscal Years’ revenue and net income in USD

Company Ownership Structure (e.g., public, private, joint venture)

Stock Exchange and Symbol (if publicly traded)

Locations in the U.S., and total number of staff in each location

b. The Respondent must also provide documentation of its “good standing” as a legal entity (corporation, partnership, etc.) in the state or jurisdiction where it is registered as a legal entity.

c. The Respondent must provide their business structure – corporation, partnership, sole proprietorship, etc. and number of years of operation under this structure.

5.B. Company Background

5.B.1 Recent Contracts

a. Identify a minimum of two (2) contracts (with at least one currently in production) for similar solutions and/or services which the Respondent has entered within the past five (5) years.

5.B.2 Contract Terminations

a. Disclose any contract terminations prior to contract completion for any reason during the past five (5) years. Describe the circumstances, and provide the customer names, addresses, and telephone numbers. If none, state “None.”

5.B.3 Business Disputes and Outstanding Litigation

a. Disclose any judgments that have occurred within the past seven (7) years and any current pending litigation. If the Respondent has partnered with other organizations for this Respondent Proposal, any judgments or litigation of the partner organizations must be provided.

b. If none are known to exist for any organization included in this offer, state “None.”

5.B.4 Mergers and Acquisitions

a. Disclose any announced or planned sale, merger, or acquisition of any participating organization or its products relevant to the scope of this RFP. Disclose any mergers or acquisitions that have occurred during the past 7 years and describe the impact to the organization or products.

5.B.5 Conflicts of Interest

a. Identify any potential conflicts of interest, including but not limited to conflicts under the California Political Reform Act (Government Code section 81000, et seq.) and Government Code section 1090, with OCDA or the County of Orange by any organization proposed to participate in this project.

5.B.6 Financial Solvency and Insurance Information

a. Respondent shall provide most recent annual financial report or year-end financial statements, and proof of liability insurance and workers compensation coverage.

5.B.7. Criminal Litigation

a. Respondent shall provide complete disclosure of any criminal litigation or regulatory action in which the Respondent has been judged guilty by a court of law or been found responsible or liable by an administrative or governmental entity within the last five (5) years related to the subject matter of this RFP. Civil actions resulting in losses, settlements, or potential liability in excess of $250,000 must be included. If none, the Respondent must include a statement to that effect.

5.C. Respondent Experience

5.C.1 Similar Services

a. Describe the Respondent’s experience providing similar services as detailed in this RFP.

5.C.2 Additional Information

a. This section shall also include the following information (at a minimum):

i. The total number of years of experience serving the public sector.

ii. A summary of the Respondent’s experience with the service/product.

iii. A summary of the Respondent’s experience with prosecution case management and the broader public safety domain.

iv. Identification of the Respondent’s other significant strengths.

5.C.3 Respondent References

a. Using Figure 2 Respondent Reference Template below as a template, Respondent must provide at least three (3) organizational references that can speak / attest to the Respondent’s experience in defining, developing, and deploying a solution like OCDA’s new CMS solution (as described by the functional and non-functional requirements included in this RFP) and in a project with comparable scope and complexity.

Please Note: OCDA reserves the right to contact additional customers / clients not listed as a reference.

b. Respondent must also identify roles on any included reference projects that were performed by Key Implementation Services Team Members (as listed below in Figure 4: Key Implementation Service Team Members) proposed for the CMS Solution. In describing the reference projects, the Respondent must refer to the Respondent’s experience as well as applicable involvement of any subcontracted Respondents.

Figure 2: Respondent Reference Template

Reference Organization Name

Reference Organization Primary Function

Reference Contact Name and Title

Reference Contact Telephone Number

Reference Contact Email

Project Name

Number of Client Project Staff and Users Involved

Contract Total Cost

Description of the Solution Implemented/Scope of Services Provided

Description of Similarities to OCDA’s CMS Modernization Effort

Project Start Date

Project End Date (Planned, Actual)

Implementation Challenges and How Respondent Addressed these Challenges

Respondent’s Project Manager

Respondent’s proposed CMS solution Key Implementation Team Members and their Roles on this Project, including subcontracted Respondents/Partners

Indicate whether a proposed subcontractor Respondent or partner was part of this project and how the team worked together successfully

6. Product Overview

6.A. Product Overview

a. Using Figure 3: Respondent Services Overview, provide a high-level overview of all in-scope products and components to be provided as described in this RFP.

b. If multiple Respondents will be providing any system/service component item, identify each Respondent separately. Respondents that desire to submit a single Proposal in response to this solicitation may only do so as prime/subcontractor relationships and must specify below. Providers of products licensed by the Respondent that are a significant part of the solution are to be included, even if those Respondents are not actively participating in the project.

c. Add additional lines as needed.

Figure 3: Respondent Services Overview

d. Additionally, the Respondent shall identify any unique aspects of the solution components and overall functionality that differentiate it from other market offerings. Response to this section is limited to five (5) pages (excluding responses to requirements in Attachment 3 – Functional Requirements and Attachment 4 – Non-Functional Requirements.

6.B. Product Roadmap

a. Provide Respondent product 5-year roadmap for core productized components of the proposed Commercial-off-the-shelf (COTS) solution. Include key technology and functionality investments that your organization anticipates making to enhance your relevant products and service offerings.

7. Functional Solution

7.A. Background

a. Provide a description of how the solution aligns with and supports modern prosecutorial operations and how the solution will help OCDA achieve operational objectives including but not limited to fair and effective administration of justice, efficiency, accountability, data integrity and transparency.

7.B. Functional Requirements Response Matrix

a. Complete the requirements matrix provided in Attachment 3 – Functional Requirements. Instructions on how to complete the matrix are provided in the RFP and within the attachment.

8. Technical Solution

a. Provide an overview of all the technology components (application software and infrastructure including software platforms and hardware) that are included in the offer, including a high-level architecture overview including components detailed in 8.A. and 8.B. below.

8.A. Conceptual Architecture

a. Provide a high-level conceptual architecture design diagram that illustrates the Respondent’s proposed CMS. The Respondent provided diagram shall provide an overview of the proposed solution components including but not limited to applications, integration, data repository(s), analytics tool(s), etc. The diagram should also demonstrate how the solution will expand and evolve over time to meet OCDA’s needs.

8.B. System Architecture

a. Describe the overall system architecture and topology for the offered CMS Solution. This must include information about the underlying platform and software on which the core components are built and supported, and how it will support security considerations, including how security will be maintained across OCDA and its criminal justice partners and meet State and federal security standards for prosecutorial agencies.

b. Describe the benefits of this architecture for OCDA, as well as any associate constraints or risks.

c. This section shall also include the following information (at a minimum):

i. Product Solution and Software Development Tools and Languages.

ii. Database Type and Structure.

iii. Proposed 3rd Party Software Components (if applicable).

iv. Proposed Middleware and Frameworks.

v. Proposed approach for meeting SOC2 compliance and other related security standards.

8.C. Technical Requirements Response Matrix

a. Respondents shall indicate their compliance with each requirement in accordance with the guidelines provided in Attachment 4 – Non-Functional Requirements which includes OCDA’s baseline set of solution capabilities identified for this RFP. Instructions on how to complete the matrix are provided in the RFP and within the attachment.

9. Implementation Approach and Understanding

a. This section shall include a narrative overview of how the proposed solution will be implemented to optimally meet and/or exceed OCDA’s requirements at go-live, support and maintenance during implementation, and on-going maintenance and operations. Respondent’s approach shall demonstrate Respondent's experience, expertise, and ability to plan and complete all work required under a contract arising from this RFP.

9.A. Staffing Requirements

9.A.1 Key Respondent Implementation Services Team Members

a. Respondent shall demonstrate that it can provide the project team necessary to transition from the existing systems to the new CMS Solution. Provide the following information:

i. Organization chart of the proposed project team.

ii. Key Implementation Services Team Member table response (see below) with roles/responsibilities for each proposed key project team member.

iii. Key Implementation Services Team Member Experience table responses (see below) and résumés for each listed project team member, including subcontracted Respondents.

iv. Description of the specific roles and responsibilities, including those that will be assigned to each subcontracted Respondent.

v. Description of Respondent’s ’s experience working with personnel from any partner or subcontractor included on the project team.

vi. Description of how Respondent will handle the replacement of key project staff if such a replacement is needed, and your ability to quickly bring in additional resources if required.

Please note: OCDA reserves the right to interview and approve or deny any proposed project team members or subcontracted Respondents.

b. Using Figure 4: Key Implementation Service Team Members and Figure 5: Key Implementation Services Team Member Experience below as templates, Respondent shall provide an overview of the experience of proposed Key Implementation Services Team Members and resumes.

Key Implementation Services Team Members include the Project Manager, Project Executive/Director, Technical Lead, and Implementation Lead. Respondent may insert additional rows to identify other roles that the Respondent considers to be a Key Implementation Services Team Member.

Figure 4: Key Implementation Service Team Members

Project Manager

Project Executive/Director

Technical Lead

Implementation Lead

Other Key Project Lead Role(s)

Figure 5: Key Implementation Services Team Member Experience

Team Member Name

Team Member Role

Team Member Years of Experience in Role

Summary Qualifications and Experience of Team Member

Team Member Professional Certification(s)

Respondent must provide an overview of the experience of each Key Implementation Services Team Member identified above (repeat the table above for each key team member). Identify any certifications that may be relevant to the delivery of the services requested in this RFP. If no relevant certifications are held, state “None” as part of the offer.

9.A.2 Key OCDA Staffing Requirements Needed to Support Implementation Activities

a. The Respondent must describe the business and technical staff, resources, and activities needed to support implementation services activities. Include a RASCI responsibility assignment matrix to clearly define the roles and accountabilities for OCDA and Respondent in each phase, and to ensure there are no dual responsibilities. All roles and responsibilities must be documented and communicated.

9.A.3 Staffing for Ongoing Production Support

a. The Respondent shall describe the solution's expected impact on OCDA’s business and technical resources needed to support and maintain the CMS Solution. Identify resource requirements by types and skills for the activities involved in unscheduled, scheduled, and routine work.

9.B. Implementation Services

9.B.1 Project Management Approach

a. Describe the approach to completing all activities and delivering all work products outlined in Section 1.1 Project Management of Exhibit IV – Statement of Work to deliver an expedient, seamless and minimally disruptive implementation of the new CMS Solution.

b. Please include a high-level implementation plan as outlined in Section 1.1 Project Management of Exhibit IV – Statement of Work.

This section shall also include the following information (at a minimum):

9.B.1.1. Project Management Methodology and Work Products (and compliance with industry standards such as the Project Management Institute), including:

a. Project Governance.

i. Provide recommendations on governance and how the Respondent will help ensure the required structure and processes are in place and supported throughout the implementation.

b. Scope Management Process.

c. Risk and Issue Management.

i. Identify key implementation risks and risk mitigation strategies of the solution based on prior Respondent experiences.

ii. Provide a sample risk register that will be used throughout project implementation to identify, monitor, and control risk.

d. Status Reporting Process and Template.

i. Provide a sample status report template.

e. Project Document Management and Collaboration.

f. Quality Management Plan

i. Description of the approach to sustaining a culture of quality throughout the project lifecycle.

ii. Identify specific tools, techniques, and activities utilized and performed to monitor, maintain, and improve quality performance.

iii. Describe the approach to standardization and focus on business outcomes.

iv. Describe the methodology for monitoring quality performance, including any proposed metrics. for reporting on quality throughout the project.

g. Integrated Change Management Process.

h. Resource Management Process.

i. Communications Management Strategy.

j. Deliverable Management Strategy.

9.B.1.2 Project Deployment Approach:

a. Provide a narrative that identifies the implementation lifecycle approach for the project (appropriate to the scope, magnitude, and complexity of the solution) that includes, at a minimum, how and when the following activities shall be performed: requirements validation/ elaboration, design, data migration, application development/ configuration, integration, test, and installation. Any implementation methodology, such as Agile or Waterfall, shall be clearly described along with the quality management processes in place to ensure a successful implementation.

This section shall also include the following information (at a minimum):

i. Provide a narrative that identifies the implementation lifecycle approach that the Respondent will apply to the Project (appropriate to the scope, magnitude, and complexity of the solution).

ii. Describe whether development/configuration approach will be Iterative, Waterfall, Agile, or other hybrid and fully describe all stages of development/configuration and major activities that shall occur.

iii. For each work stream or project phase, provide a concise narrative that fully describes the Respondent’s methods, tools, accelerators, frameworks, etc., associated with the Respondent’s proposed approach.

iv. Include all assumptions the Respondent is making with respect to OCDA’s role/staffing as well as the role and contribution of any key third parties the Respondent is including in its proposal.

v. Describe in detail how the Respondent will organize its team and leverage its methodology to deliver an OCDA-wide solution while achieving deployment synergies resulting in a cost-effective, high quality, and accelerated deployment.

vi. Describe if/how the Respondent proposes to execute a phased approach with OCDA’s project teams to seamlessly transition to the new solution with minimal business disruption.

vii. Describe how the Respondent proposes to continue to implement subsequent phases while simultaneously providing the necessary support and maintenance for releases that are already in/have just gone into production (if applicable).

9.B.1.3 Project Schedule and Work Plan:

a. Provide an implementation schedule and high-level work plan to meet the requirements and deliverables of this RFP. Contents shall include elaboration of, and details related to, the following:

i. Method used to estimate the project level of effort and schedule. Include tools and techniques used to derive the estimates. Identify the source or basis of the estimates used to develop the Respondent’s offer and the level of uncertainty and risk associated with the estimates.

ii. Respondent shall submit an implementation schedule and high-level work plan to meet the requirements and deliverables of this solicitation.

iii. The schedule shall identify an overall timeline, with key start dates and end dates for major project milestones, including any phased deployments proposed and assumptions that correspond to the Deployment Plan identified in the response section below.

iv. The work plan shall provide tasks, durations, key deliverables, and key milestones that correspond to the project schedule, deployment approach proposed, and deliverables proposed, as detailed in other sections of the offer.

v. Key schedule/work plan considerations:

· Provide an integrated, milestone-level, and detailed (level 2 WBS minimum) work plan, including Gantt chart of the Proposed Project Schedule that includes all services requested in this RFP.

· Schedule milestones should correspond with the deliverable milestones required in this SOW.

· Respondent must include reasonable and incremental review periods for Deliverables Expectations Document (DED’s) and deliverables that allow sufficient time for both OCDA review and Respondent to update deliverables based on OCDA review feedback.

· Respondent must clearly describe its approach to plan for and manage slack/contingency in the project schedule to account for unplanned delays or issues.

9.B.1.4 Configuration Management Plan:

a. Describes the approach for managing programming changes, third-party software, and configuration settings made in the system, including version control, release management, testing, final approval of deployment, and deployment.

This section shall also include the following information (at a minimum):

i. Description of the configuration management process and any actions that will be required of OCDA. Identify any specific skills that would be needed by OCDA staff performing configuration changes.

ii. Description of the tools, environment, and infrastructure required for the execution of configuration management activities to be completed by OCDA.

iii. Description of the methods for identifying project configuration items as well as for placing and managing them in the configuration register.

iv. Description of the methods for conducting configuration audits and reviews to be held during the project.

v. Description of the methods for configuration release management controls between environments.

9.B.2 Enterprise Analysis and Design Approach

a. Describe approach to completing all activities and delivering all work products outlined in Section 1.2 Enterprise Analysis and Design of Exhibit IV – Statement of Work to follow an agreed upon methodology to clearly define design-level requirements for the future-state solution that are based on stakeholder inputs and collaboration.

This section shall also include the following information (at a minimum):

9.B.2.1 Requirements Analysis and Traceability Approach:

a. Describe how project requirements are delivered during the project lifecycle, from RFP to production cutover, including details for the following:

i. Process to validate the Respondent’s understanding of requirements.

ii. Process to review current state artifacts, such as existing forms, screens, and reports to ensure accurate inputs and outputs are accounted for in the design of the solution.

iii. Process to validate that all requirements are delivered and satisfied to defined standards.

9.B.2.2 Conceptual Design Approach:

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

b. Methodology to clearly define design-level requirements for the future-state solution that are based on stakeholder inputs and collaboration.

c. Approach to conducting joint configuration and/or application design sessions with OCDA and other stakeholders, and how stakeholders will be exposed early and throughout the process to how the system will look and function.

d. Approach to documenting the solution design.

e. Approach to validating and finalizing design specifications including the use of prototype configurations, document reviews, sprint management of other methods employed as part of the Respondent’s proposed approach.

9.B.3 Build (Development and Configuration) Approach

a. Describe approach to completing all activities and delivering all work products outlined in Section 1.3 Build (Development and Configuration) of Exhibit IV – Statement of Work to implement the solution, including integrations with external systems, and converted data.

This section shall include the following (at a minimum):

9.B.3.1 Solution Implementation Approach:

a. Describe the use of any development approaches and tools used to customize the solution (outside of configuration) that may be necessary to meet OCDA’s requirements.

b. Identify and describe any major components of the solution that may require customization of the proposed base product based on the requirements contained in the RFP.

9.B.3.2 Integration Approach

a. Describe the overall approach and strategy for integrating the proposed solution with interfacing systems and agency partners described in this RFP. Respondent shall describe integration architecture and methods, requirements on external systems, conformance with national or industry standards, and the approach to testing integration. Respondent shall describe assumptions made regarding support from OCDA and partner agencies during the design and delivery of integrations.

9.B.3.3 Security Approach

a. Describe how information within the Respondent’s solution is secured.

This section shall also include the following information (at a minimum):

i. Security Architecture

ii. Security Level Management (Role-based access, including data access rights by user roles and permissions)

iii. Security Procedures and Protocols

9.B.3.4 Disaster Recovery and Business Continuity Approach

a. Describe the disaster recovery and/or business continuity capabilities of the proposed solution.

b. Describe the approach for initiating disaster recovery and/or business continuity procedures to be undertaken in the event of a disaster affecting the CMS solution.

9.B.3.5 Infrastructure Support Approach

a. Describe the solution environments and approach for maintaining application and infrastructure component consistency across all environments.

b. Describe the approach to performance tuning to ensure the solution operates optimally and withing defined service levels.

9.B.3.6 Reporting

a. Describe the reporting solution to support OCDA’s reporting needs, data analysis, and business intelligence.

This section shall also include the following information (at a minimum):

i. Design approach and methodology for reporting and analysis. Describe how the approach considers both standardized reports for pre-defined reporting and ad-hoc reporting needs.

ii. Development approach and methodology for reporting and analysis.

iii. Approach to providing self-reporting capabilities to OCDA technical and business staff.

iv. Relevant technology, tools, and capabilities of proposed solution.

v. Ability and constraints to utilizing OCDA-provided third-party reporting tools with the proposed solution.

vi. Methodology for estimating level of effort for reports of low, medium, and high complexity and how that will inform project implementation planning decisions.

9.B.3.7 Data Conversion/ Migration Approach

a. Describe the strategy for migrating data from source systems into the proposed solution.

This section shall include the following information (at a minimum):

i. Description of the methodology to be used in developing migration specifications and the identification of any potential issues, including description of the approval process for such specifications.

ii. Describe any constraints and risks associated with data migration for this project and how the Respondent will address these to ensure a successful migration.

iii. Technology and tools to be used.

iv. Roles and responsibilities of Respondent vs. OCDA and other stakeholders.

v. Any iterative data migration proposed, including proposed number of mock runs for data migration.

vi. Description of anticipated work sessions with OCDA staff to validate and test migrations.

vii. Respondent’s previous experience migrating data from off-the-shelf and/or custom-developed legacy source systems, including identifying issues encountered and any proposed staff that has experience in this area.

viii. Respondent’s previous experience migrating data from multiple legacy source systems into a single target system, including identifying issues encountered and any proposed staff that has experience in this area.

9.B.4 Test Strategy

a. Describe approach to completing all activities and delivering all work products outlined in Section 1.4 – Test Strategy of Exhibit IV – Statement of Work to test and validate the functionality of the implemented solution against the documented requirements.

This section shall also include the following information (at a minimum):

9.B.4.1 Testing Methodology:

a. Description of the process for creating and documenting test cases and scenarios including level of detail provided.

b. Describe the plan for tracking expected versus actual test results, and for tracking defects and associated resolutions.

c. Describe defect prioritization, time to resolution, escalation, and implications on any process and contractual obligations such as acceptance periods.

d. Describe the approach for testing during the project to verify that functionality being developed is consistent with the functionality expected by system users.

e. Include a high-level test plan aligned with Respondent’s proposed implementation approach for this project.

i. Describe the approach to using requirements traceability when testing to ensure end-to-end and comprehensive testing of entire solution prior to go live.

ii. Describe the entrance and exit criteria for each test phase (e.g., Unit Test, System Test, UAT, Performance Test, etc.).

iii. Describe the role(s) the Respondent expects OCDA or other stakeholders to perform during each test phase. In this description, Respondents should clearly identify the activities OCDA, or other stakeholders will be responsible for performing and avoid generic terms, such as “jointly” and “collaborate.”

9.B.4.2 Training Approach:

a. Describe anticipated training sessions for OCDA’s staff to prepare for testing.

9.B.4.3 User Acceptance Testing (UAT):

a. Describe the approach for supporting UAT.

b. Describe the plan for developing UAT test cases for OCDA.

c. Describe any test management processes (e.g., tracking expected versus actual test results defect tracking and associated resolutions, etc.) that are unique to UAT.

d. Include a high-level UAT test plan aligned with Respondent’s proposed implementation plan for this project.

9.B.5 Training and Knowledge Transfer

a. Describe Respondent’s approach to completing all activities and delivering all work products outlined in Section 1.5 - Training and Knowledge Transfer of Exhibit IV – Statement of Work to provide training and conduct knowledge transfer.

This section shall also include the following information (at a minimum):

9.B.5.1 Training Plan:

a. Identify and describe the types of training proposed, including:

i. Initial Product Training

ii. Train-the-Trainer sessions

iii. Configuration Training sessions

iv. Application and System Administration Training sessions

b. Describe how the Respondent delivers training in-person and in a remote environment to ensure success.

i. Demonstrate how the Respondent has supported client end user needs remotely. Provide examples that demonstrate how the Respondent helped clients maintain Case Management continuity in a disruptive time (e.g., during the COVID-19 Pandemic).

c. Describe the types of existing documentation that the Respondent can leverage for OCDA’s CMS training and knowledge transfer activities.

d. Describe any constraints and risks that can be a barrier to the success of the training effort, along with the actions that can be taken to address these constraints and risks.

9.B.5.2 Training Curriculum and Materials:

a. Describe the curriculum the Respondent intends to employ to train users, and any supporting training materials the Respondent intends to leverage and / or develop to support trainings.

9.B.6 Cutover Readiness and Production Go-Live

a. Describe the approach to completing all activities and delivering all work products outlined in Section 1.6 - Cutover Readiness and Production Go-Live of Exhibit IV – Statement of Work to transition to the Respondent’s ongoing support and maintenance team upon achieving Go-Live and initiating production.

This section shall also include the following information (at a minimum):

i. Describe the release approach for production cutover and activities required to begin production use of the new CMS solution, including the following (at a minimum):

· Key activities

· Critical success factors

· Roles and responsibilities (for both the Respondent and OCDA)

· Acceptance criteria

ii. List and describe documentation that will be provided, including the formats in which the documentation will be made available. Additionally, describe how the Respondent plans to provide ongoing updates to documentation throughout the life of the contract to ensure relevance of the documentation following implementation and system upgrades.

iii. Describe how “as-built” documents will be initially prepared and kept current during production support.

iv. Describe the approach to provide ongoing training for users as the new CMS solution is updated, and new users are onboarded.

9.B.7 Post Go-Live and Transition to Support

a. Describe the approach to completing all activities and delivering all work products outlined in Section 1.7 - Post Go-Live and Transition to Support of Exhibit IV – Statement of Work to provide production services to OCDA, including any assumptions for the provision of services.

This section shall also include the following information (at a minimum):

i. Describe the approach to transitioning to the Respondent’s ongoing support and maintenance team upon achieving Go-Live and initiating production.

ii. Describe how the Respondent will manage working software in production while also continuing to develop new releases for future deployment.

iii. Describe the roles and responsibilities of OCDA staff expected to support the system(s), including the skills and the approximate amount of time required.

iv. Describe system monitoring capabilities and how performance will be measured and tracked against service levels, including how real-time deviations are communicated to OCDA. Respondent shall also describe root cause analysis approach and how corrective/preventative measures are taken. Provide sample reports related to service level management as appropriate.

v. Describe the Respondent's overall release and deployment management approach for minor and major application releases and how OCDA's input and approvals are incorporated.

vi. Describe the Respondent's strategy for continuous customer alignment and engagement, release cadence, communication process, training plans, and risk mitigation plans to support proposed implementation deployment approach impacted by releases.

vii. Describe Respondent's approach for maintaining technical currency and anticipated major releases for the full term of this Agreement and how those releases will impact the CMS solution.

9.C. Production Support and Maintenance during Implementation

a. Describe the approach to providing ongoing production support and maintenance services once the solution is in production in response to 1.8 - Production Support and Maintenance during implementation of Exhibit IV – Statement of Work.

10. On-going Maintenance and Operations

10.A. Overall Maintenance and Operations Support

a. Describe the Respondent’s approach and methodology to application management, technical support, system enhancements, and other related support activities.

b. Describe the Respondent’s approach to service level management and provide a response to the Service Level Requirements identified by OCDA in Attachment 14 – Proposed Service Level Agreement including proposed measurements; proposed service levels; strategy for documenting service levels and performance against such service levels; and format and frequency of reporting. Specify the mechanisms, tools and techniques Respondent intends to put in place to meet, measure, report and improve upon these service levels.

10.B. Patch/Upgrade Support

a. Describe 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. Describe release strategy and typical schedule (quarterly, annually) with respect to patches, point upgrades, and major release upgrades. As part of this response, address your position on version compliance to remain on support and options clients may have to defer patches/upgrades.

c. Describe what tools and documentation are provided to facilitate patches or upgrades.

d. Describe any differences in patch/upgrade support options and services for single tenant SaaS vs. multi-tenant SaaS support vs. any other cloud-based models offered.

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

f. Describe the current patch management process including the cadence (e.g., patch cycle), types of patches generally applied, approach to systems, and testing.

10.C. Enhancements / Customizations

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

b. Describe the technical approach to enhancements and customizations, such as configuration management, documentation requirements, integration testing, regression testing, acceptance testing, and deployment.

c. Describe the approach to receive and process future enhancement and customization requests, including methodology for pricing (e.g., function point analysis) and future available resources to fulfill each request. Describe the process for rationalizing OCDA requested enhancements and customizations with Respondent’s other customers and the criteria by which such enhancements or customizations are incorporated into the core product.

10.D. Call Center/Problem Ticket Support

a. Describe the Respondent’s call center and problem ticket support services and service levels. Provide associated support service costs and rate information in Attachment 5 – Cost Workbook.

b. Describe the size and structure of the Respondent’s call center services teams.

c. Outline the call center hours of operation.

d. Describe any support tools or techniques used to diagnose and resolve critical or escalated problems more quickly. The escalation process should also be described.

e. Describe any differences in call center support for client hosted vs. single tenant SaaS vs. multi-tenant SaaS support vs. any other cloud-based models offered.

f. Describe any continuous improvement efforts underway or planned to improve the quality of call center support services.

g. Describe the availability of an online knowledge base that can be accessed directly by end-users and technical staff to obtain answers to frequently asked questions or perform research on symptoms to identify resolutions to known issues. Additionally, describe any interactive services (e.g., online chat) that will be available to system users.

h. Describe any continuous improvement efforts underway or planned to improve the quality of user group collaboration.

11. Hosting

a. Describe the solution’s hosting model in response to Section 3 - Hosting of Exhibit IV – Statement of Work.

12. Software and Licenses

a. Describe how software and licenses are delivered and consumed by OCDA (e.g., a one-to-many model by all contracted customers at any time on a pay-for-use basis or as a subscription based on use metric, or other).

13. Payment Milestones and Deliverables

a. The deliverables outlined in Figure 6: Expected Deliverables below are required by the Respondent.

For each deliverable in the table below, provide a response in which the Respondent:

i. Either confirm acceptance all activities and work products as described or identify gap and/or exceptions and describe proposed modifications. For proposed modifications, map them to the deliverables, activities, and work products in Exhibit IV – Statement of Work.

ii. Describe the proposed approach for developing the deliverable, including the Respondent’s understanding of the deliverable and how it plans to achieve success.

iii. Do not repeat the information provided in the Exhibit IV – Statement of Work.

Please Note: The awarded Respondent will be responsible for developing a Project Deliverable Expectations document, which describes the proposed high-level outline and format of each deliverable. This prevents rework by achieving early agreement on deliverable structure and anticipated content. The expectations document will be developed by tailoring an existing template in collaboration with OCDA. OCDA and the awarded Respondent will agree on the Project Deliverable Expectation documents to be provided at the beginning of the Project and review and approve the Project Deliverable Expectations before each subsequent deliverable phase.

13.A. Deliverables and Acceptance Criteria

a. No work will be performed on any deliverable associated with a payment milestone until the applicable Deliverable Expectations Documents (DED) have been approved in writing by the OCDA Project Manager. As each project Deliverable is submitted, the Respondent must include a copy of the associated DED as the cover sheet.

b. All contract deliverables are given a unique number and tied to the project schedule. The dates for deliverable submissions, review comments, and resubmissions will be tracked. The Respondent will provide a project repository tool (e.g., SharePoint) to record project deliverables and manage project tasks.

c. Deliverables prepared by the Respondent shall be subject to the review and approval of OCDA Project Manager or designee. The Respondent must be prepared to provide walkthroughs of deliverables to facilitate OCDA deliverable reviews. OCDA will review, approve, or require modifications to the Respondent’s deliverables. Approval shall be granted if, at OCDA’s sole discretion, the deliverable conforms to the approved DED and meets all other requirements of the said deliverable. OCDA shall notify the Respondent within ten (10) business days of its receipt of a Deliverable, or as otherwise agreed to by OCDA and the Respondent, of its approval or rejection, with the reason(s) for rejection. The Respondent shall have five (5) business days, or as otherwise agreed to by OCDA, to correct the deliverable and resubmit the deliverable for OCDA review.

d. The Respondent must account for OCDA review process when developing schedules, project plans, and timelines. Specific deliverables and acceptance criteria will be finalized based on an offer response to the RFP solicitation and any subsequent negotiations.

Figure 6: Expected Deliverables

2. Project Management Plan

3. Project Deployment Plan

4. Baseline Project Schedule and Work Plan

5. Configuration Management Plan

6. Stakeholder Outreach and Communication Plan

7. Deliverable Expectation Documents (DEDs)

2. Conceptual Design Documentation

2. Data Conversion and Migration Plan

3. Cutover Plan

2. Test Cases and Test Scripts

3. System Integration Test Results

4. UAT Support and UAT Results

2. Training Curriculum and Materials

3. Training Completion Report

2. Updated Project Implementation Plans

3. Final As-Built System Documentation

4. Technical Documentation for Knowledge Transfer

5. Updated Cutover Plan and Schedule

2. Project Closeout Report

3. Monthly Production Support Templates

14. Exceptions and Assumptions

Identify all general assumptions and dependencies associated with this offer in Figure 7: Assumptions and/or Dependencies; add additional rows, as necessary. Please note that any cost-related information should not be included here, but instead only be included in Attachment 5 – Cost Workbook.

Figure 7: Assumptions and/or Dependencies