SGAL RFP - Attachment B.docx

Attachment B – Proposal Forms

Proposer is to complete each of the Tabs 1 – 14 and submit per the instructions provided in the RFP. Any Exhibits provided by the Proposer are to be inserted at the end of each applicable tab. Proposers are permitted to make changes to the footers, and necessary formatting changes to tables, to optimize the presentation of information.

Proposer is instructed to organize Proposal in a tabbed format, and to insert the completed tab forms (Attachment B) in the corresponding tabs as a part of their Proposal response. In addition to the information captured through the questions and tables in Attachment B, Proposer is requested to provide complementary narrative information, diagrams, and images to help substantiate and support their proposal response to each tab section. Any such information may be provided in Proposers preferred formatting/branding.

Tab 14 Please insert the response to Attachment B, Functional and Technical Requirements, following Attachment A consolidated PDF Technical Proposal submission.

Supplements Any Proposer-submitted materials or documentation not specifically requested through this RFP may be included as Supplements to the Proposal in a separately marked “Supplements” tab of the proposal.

Attachment A CCMS Solution and Implementation Services

Tab 1 – Company Introduction and Relevant Experience

I. TRANSMITTAL CERTIFICATION

By signature on the Proposal, the Proposer certifies that it complies with:

1. The laws of the State of Florida and is licensed or qualified to conduct business in the State of Florida

2. All applicable local, state, and federal laws, codes, and regulations

3. All terms, conditions, and requirements set forth in this RFP

4. A condition that the Proposal submitted was independently arrived at, without collusion

5. A condition that the offer will remain open and valid for the period indicated in this solicitation; and any condition that the firm and/or any individuals working on the contract do not have a possible conflict of interest

6. The following Non-Collusion Affirmations

· I affirm that I am the Proposer, a partner of the Proposer, or an officer or employee of the Proposer’s corporation with authority to sign on the Proposer’s behalf.

· I also affirm that the attached has been compiled independently and without collusion or agreement or understanding with any other Vendor designed to limit competition.

· I hereby affirm that the contents of this Proposal have not been communicated by the Proposer or its agent to any person not an employee or agent of the Champaign Office, IL (the Office).

If the Proposer fails to comply with the provisions stated in this paragraph, the Office reserves the right to reject the Proposal, terminate the contract, or consider the Proposer in default.

Table 1-01: Transmittal Certification and Primary Contact Information

Name of the Proposer Representative

Title

Name of Company

Address

Telephone Number

Email Address

Signature of Authorized Officer of the Firm

Attachment A – Tab 1 CCMS Solution and Implementation Services

A signature provides the Office with the Proposer’s acknowledgement and acceptance of the RFP terms, requirements, and conditions, and the execution of same during the discharge of any succeeding contract.

II. TRANSMITTAL LETTER

A Transmittal Letter, printed on letterhead, shall be submitted and signed by an authorized representative of the Proposer, such as the owner, partner, or in the case of a corporation, the President, Vice President, Secretary, or other corporate officer(s) that address the following:

a. A statement naming the Proposer (legal name and if corporation, whether corporation has corporate seal) and stating the type of entity for the Proposer and any joint Proposer or subcontractor (e.g., corporation, limited liability company, partnership, sole proprietor, etc.)

b. A statement identifying, in summary, the name of the proposed software solution and any third-party partners included as part of the proposal;

c. A statement of acknowledging that all addenda to this Request for Proposal have been reviewed by the Proposer; and

d. A statement disclosing whether or not the proposal contains confidential information, trade secrets or other proprietary data the Proposer does not want to be subject to public inspection.

III. COMPANY BACKGROUND AND HISTORY

i. Proposer to provide a comprehensive history statement of the firm, including any mergers, assignments, or other corporate changes during the past 10 years.

ii. Proposer shall complete the Company Background and History Table as provided below.

If a partnership with third-party company is a part of the Proposal, the Company Background and History table shall be provided for each entity. It is expected that all points shall be addressed for each company involved in the Proposal, prime or third party. Proposer to copy the table as needed for each Partner/Third-Party Firm proposed and fill out for each.

Table 1-02: Company Background and History

Name of Proposer:

(Copy form and Complete if applicable for each) Name of Partner/Third-Party Firm:

Total number of employees

Type and number of employees committed to the product and support being proposed

Office locations (City and State)

Government:

Total number of active Private Sector CCMS clients

Total number of active Government Sector CCMS clients

Total years offering proposed software systems

County:

City:

Office: Other:

Total number of completed implementations of the proposed product and version

Total number of active government clients using the proposed product version

Largest active government installation, including population

Smallest active government installation, including population

Other products offered by the company

IV. RELEVANT EXPERIENCE

i. Please describe your relevant experience working with Florida government entities involved in legal services (Courts, State Agencies, Municipalities, etc.)

ii. Please describe any relevant experience working with government entities involved in legal services (Courts, State Agencies, Municipalities, etc), including any unique factors that arose during the implementation process.

iii. Identify two recent project implementations that are most comparable to the Office’s proposed implementation, and provide a project profile for each, including: scope of modules; project duration; any unique requirements or circumstances that were a part of, or came up during, the project; the legacy system converted from; etc.

iv. Please describe implementation barriers or challenges that have been experienced working within Florida on implementations. What proactive steps are planned in this proposed project to mitigate against similar challenges?

v. What sets the product(s) and services that your firm proposes apart from competitors’ products and services? Why should SGAL select your firm to partner with?

V. USE OF SUBCONTRACTORS

i. The Proposer shall identify any of the required Services that are proposed to be subcontracted, if any. This table is to be copied and filled out for each proposed subcontractor.

Table 1-03: Subcontractor Questions

Does your firm complete the implementations of the product being proposed or is this effort outsourced?

Has or will any portion of the proposed work be completed by subcontractors or contract employees?

This below portion of the table is to be copied and filled out for each proposed subcontractor.

Name of subcontractor and address

Summary of Service and estimated percentage of Work the subcontractor will be providing.

Reasons for subcontracting

Experience

Detailed subcontractor responsibilities

Previous history of projects using the named subcontractor

Any additional relevant information

The Office reserves the right to request a copy of the prime contractor/subcontractor contract verifying the prime contractor has the sole responsibility for any and all Services under this RFP and is financially liable, without exception, to SGAL for all Services contracted by the Proposer and the subcontractor under this RFP.

The Office reserves the right to request additional information regarding the subcontractor(s) as it relates to references, history of the firm, and other relative information that has been required of the Proposer to submit in this RFP.

The substitution of one subcontractor for another may be made only at the discretion and prior written approval of the Office.

ii. By signature (electronically or via ink) below on the Certification of Subcontractors/Partners, the Proposer and the Subcontractor/Partner certify that the Proposer has received the permission of the third-party to include the scope of software and services under the cover of the submitted proposal.

Table 1-04: Certification of Subcontractors/Partners

Proposer

Partner/Third-party software provider

Partner/Third-party software provider

Proposers are instructed to return a copy of this Certification table signed by an authorized firm agent as part of proposal responses.

VI. ACKNOWLEDGEMENT OF ADDENDUMS:

Addenda: Proposer shall acknowledge below the receipt of any addendum posted to the Office website.

ADDENDUM NO. DATE ISSUED

Tab 2 – Software Solution

I. SUMMARY DESCRIPTION OF EACH FUNCTIONAL AREA

Proposer to provide a summary description of the capabilities for each functional area contained in the RFP, in narrative format (minimum of two well-developed paragraphs per functional area). The purpose of this summary is so that SGAL has a high-level understanding of the proposed solution. The narrative should be written for an audience of the end-user community. Descriptions should be included for any products proposed by third parties to meet the capabilities described in the Functional and Technical Requirements in Attachment B.

Marketing materials should not be submitted/included as a part of the proposed functionality.

II. SOFTWARE DOCUMENTATION FEATURES AND FUNCTIONS

Proposer to provide a summary of their software documentation that describes the features and function of the proposed application software. Identify what makes your documentation user friendly and useful to the end user and technical user of the software.

III. PROPOSED SOFTWARE MODULES TABLE

Proposer to complete the table below. Proposed modules that are required to satisfy the requirements associated with the functional areas identified below cannot be proposed as complementary or optional.

Table 2-01: Proposed Functional Areas/Modules

Proposed Software Information

Product Component/Suite (Name and Version of the Proposed Software Solution)

Time on Market

Release Date of Most Current Version

Next Major Release Date

Next Minor Release Date

Was the product proposed originally developed by your firm, or, was the product acquired from another developer/entity?

Attachment A – Tab 2

Proposed Software Information

If the proposed product was acquired, what was the date of acquisition?

What is the future roadmap for the proposed product? Is there an end of sales or support date for the product?

Does your company have plans to release a differing product that offers the same or similar functionality in the next 5-10 years?

Licensing

Describe how the software is licensed (e.g., named user, concurrent users, enterprise/site, power user) and the options available for licensing:

How many licenses have been proposed?

Are the same licenses required for all users, or, would some users (e.g., those only accessing scheduling) have a different license type than other users (e.g., Judges)?

How are new users added to the system? Are there incremental costs per user?

If an existing user separates from service at the Office, may their license be re-assigned to a new staff member?

Deployment Model

Deployment Models Proposed to the Office (Corresponding Attachment C1 Cost Worksheets shall be completed for each separate deployment model proposed)

Attachment A – Tab 2

Proposed Software Information

Summary of Modules Proposed

No.

Functional Area

*Successful integration should include only those instances where both the software and the client are in production environments.

IV. OPTIONAL AND COMPLEMENTARY MODULES

What other system modules or products, not included in the scope of your proposal, would the Proposer recommend as complementary or optional to the Project Scope?

Table 2-02: Optional and Complementary Modules

V. PARTNERSHIPS/THIRD-PARTY PRODUCT RELATIONSHIP

i. Proposer to fill out the below table for each of the Partnership/Third-Party software product proposed.

– Not applicable, no Partnership/Third-Party software proposed

Table 2-03: Partnership and/or Third-Party Product Identification

Name of Partnership/Third-Party Software Firm

Name of Software Product

ii. For each product proposed as a Partnership/Third-Party product, detail the options available to the Office as it relates to contracting relationship between the Office and the Partnership/Third Party.

iii. Proposer to provide the approach and responsibilities for managing the implementation and acceptance testing for each of the proposed Partnership/Third-Party products.

iv. Proposer to provide the approach and responsibilities for the SLA/maintenance related to the Partner/Third-Party provider.

v. Proposer to submit references and qualification statements for each of the proposed Partners/Third-Party firms and attach as an Exhibit to Tab 2.

Confirmed, Exhibit attached.

vi. Proposer shall indicate if the proposed approach utilizes a systems integrator or consulting firm as the third-party.

VI. General

i. Proposer shall clearly indicate the deployment model(s) proposed from among the three categories presented in a-c below. If more than one product is proposed, please clearly identify the deployment model for each product proposed:

a. On Premise (locally hosted at the Office, perpetual licenses)

b. Proposer hosted (hosted and managed by the Proposer, perpetual licenses)

c. Software as a Service (SaaS or subscription-based models)

ii. Proposer shall fully describe the integration/interface/data exchange capabilities of the proposed system, including available API’s, middleware, web services, etc.

iii. For available API’s, does the proposed pricing include access to the entire API library? What functionality is exposed in the systems’ APIs?

iv. Please describe how the proposed solution(s) support accessibility and ADA compliance, in addition to the following specific questions.

a. Does the software provide keyboard equivalents for all mouse actions, including buttons, scroll windows, text entry fields, and pop-up windows?

b. If information is provided in an audio format, is it also capable of being displayed by the user in a visual format?

c. Does the application support user-defined color settings system-wide? Does the software ensure that color-coding is never used as the only means of conveying information or indicating an action?

d. Is special training available/provided for users with disabilities that will enable them to become familiar with the software and learn how to use it in conjunction with assistive technology provided as an accommodation?

v. Describe your proposed reporting features native to the system, and how the Office staff will be trained to develop and configure their own reports.

vi. What strategic decisions or direction is your firm taking or making related to the product being proposed today?

vii. What efforts does your firm take to protect confidential information and maintain necessary compliances (e.g., juvenile information, personally identifiable information, HIPAA, CJIS)?

viii. Please describe the database storage capacity of the proposed solution. Are there limits on the amount of data that can be stored in the proposed solution? If applicable, what tiers of storage are offered in the hosted/SaaS environment?

ix. Please describe the non-licensed user portal capabilities of the system as well as other available functionality such as electronic filing.

x. Does your firm have any plans or intentions of “sun-setting” the proposed product in the next ten (10) years, and continuing to provide support for the software by not continue to invest in upgrades/updates to the software? If this were to occur, whether by design or change in circumstances at your firm, what remediation would there be for the Office?

xi. Describe your approach to maintaining the system as up to date and in compliance with any rules/regulations/mandates, both federal and state, that may undergo changes.

xii. Describe your approach to ensuring security permissions and user roles restricting visibility between different user groups to ensure certain data points are not visible to other user groups who do not have permission.

Tab 3 – Project Approach and Implementation Methodology

I. PROJECT APPROACH

Proposer to provide a description of the proposed approach for providing the Scope described in the RFP, including a comprehensive description of the proposed implementation methodology for the Project. The description should include how the Proposer has developed this methodology to both incorporate lessons learned from experiences as well as to meet the needs described in the RFP.

i. Based on information provided in this RFP and experience in working with other governmental entities, what is the Proposer’s perspective on the most significant risks to this Project, and how do you plan to mitigate these risks?

ii. With what frequency will Proposer’s Project Team staff be on-site at the State Office (or local Circuit Offices) during implementation? Will staff be on-site for full or partial weeks?

iii. Describe in detail the approach to developing interfaces/integrations/data exchanges. What is the division of responsibility between the Office and Proposer project teams? What technical skills are required of the Office staff for this work?

a. Following go-live of the software, what is the role of the Proposer in supporting the ongoing maintenance of developed interfaces/integrations/data exchanges?

iv. Describe in detail the approach to configuration and set-up activities. Will the Proposer team complete the majority of the configuration based upon information gathered from the Office subject matter experts, or will the Office be expected to perform much of the configuration?

v. Describe any additional assumptions made in the Proposal, not already identified in detail. These should include any assumptions related to the current the Office technical environment, staffing, project management approach, and the Office resources available during implementation and support phases.

Attachment A – Tab 3

II. DEPLOYMENT

Proposer to provide a detailed narrative description of how the implementation approach will vary between the deployment methods proposed (i.e., a traditional Office-hosted model, a Proposer-hosted and/or a subscription-based solution, etc.)

III. GO-LIVE AND ONGOING SUPPORT

Proposer to describe what level of pre- and post-go-live support is available under the proposed fee structure. If varying levels of support are available, this section of the RFP response should clarify these potential support services and highlight the level of support that has been proposed. Proposer shall use Attachment C1, Cost Worksheets, to clearly identify the varying fees based on the varying levels of support that are available.

i. What are the standard hours that support is offered, and through what means (telephone, web ticket submission, etc.)?

ii. Are after-hours and weekend support offered, and if so, is this part of the standard support offering or part of a different tier/offering?

iii. Describe the support that is offered to assist in potential situations where the Office is unable to conduct certain critical processes due to emergency situations.

iv. Is product support offered by Proposer, through the software developer/provider, or sub-contracted?

v. Are there optional, “enhanced” support tiers or offerings above and beyond what has been proposed?

vi. How often are releases provided, how is advance notification provided to customers of upcoming releases, and what is the process to test each release?

vii. Would the Office be able to test releases in a test environment prior to pushing updates to a live environment?

viii. Does the system have the ability to roll back updates should challenges or bugs be encountered?

ix. Describe how often major and minor software updates are provided, as well as the level of the Office resources required for a major update and the level of resources required for a minor update.

x. Please describe the major/minor upgrade process that is required if the solution requires a client-based installation.

xi. Are there future costs associated with upgrade processes? For example, costs associated with purchasing licensing for upgrades, professional services costs associated with implementing upgrades, etc.? Proposer to describe the frequency of upgrades and any price ranges for anticipated upgrades.

xii. What is the role of the Office in providing ongoing support and maintenance of the system proposed? How many FTE are typically required to support the system on the client-side, and what tasks are entailed?

IV. STATUS REPORTING

Proposer to detail their approach to providing status reports throughout the course of the Project. This section should include an example of the recurring status report and identify the expected delivery mechanism that will be used to provide the report to the Office.

V. RESOURCE HOURS

Proposer shall include the proposed resource levels for the Office Implementation Project Team and their Project Teams by completing the tables below.

Table 3-01: Project Team Resource Hours

Project Team Resource Hours

Instructions: The Proposer is asked to provide the number of resources that will be committed to the Project in terms of number of hours. These numbers should be based on the functionality the Office desires, included in the detailed Functional and Technical Requirements (Attachment B).

Assumptions: Any assumptions related to the number of Project Team staff for the Proposer or the Office teams, roles of staff, and duration of involvement used in the development of the resource hour estimates should be included here:

Functional Area Project Team Requirements and Design

/Project Management

Testing

Training

Total

Total Hours by Project Task:

Office Team

Vendor Team

Proposer shall include the anticipated resource hour’s levels for the Office Implementation Project Team based on typical project role by completing the tables below. Any comments related to the anticipated hours, any phase-specific involvement, or other assumptions should be noted in the Additional Vendor Comments column.

Table 3-02: Anticipated Hours by Project Role

Anticipated Hours by Project Role the Office Project Role (e.g., Project Sponsor, Project Manager, Conversion Lead)

Additional Vendor Comments

Executive Sponsor

Attachment A – Tab 3 CCMS Solution and Implementation Services

Steering Committee

Project Manager

Project Management Team

Functional Area Lead(s) – Assuming one lead per tab of Attachment B

Subject Matter Expert(s) – Note: one SME may serve as SME on two or more modules/functional areas

Integration Lead

System Administrator

Reporting Lead

Organizational Change Management Lead

Training Lead

Other Vendor-Defined Roles (list below)

Proposer to provide their overall estimated split/division of the work effort as shared between the Office and the vendor teams (example: the Office owns 20% of the work effort, and the Vendor owns 80% of the work effort) along with any narrative to support this estimate.

Table 3-03: Anticipated Work Effort Division

Anticipated Work Effort Division

Estimated number of individuals required for Project Team

Approximate Percentage of Work Effort Owned

General Comments

VI. IMPLEMENTATION PLAN

Proposer to provide their overall objectives and approach to the Office’s implementation. Discuss timing as being chronological, in parallel, etc., for all of the modules proposed.

Proposer shall submit a Sample Implementation Plan as an Exhibit to Tab 3. Exhibit submitted Yes No

VII. PROJECT MANAGEMENT PROCESS

Proposer to provide their overall approach for managing the Office’s Project, including the following areas:

i. Scope Management: approach for managing the Project Scope and the process used to request changes to Project Scope.

ii. Schedule Management: approach for managing the Office’s Project Schedule and the process used to submit requested changes to the schedule.

iii. Risk Management: their approach for documenting Project risks, providing recommendations for mitigating the risk, and how this will be communicated to the Office’s Implementation Project Team.

iv. Quality Management: approach/policies to assure that all written deliverables have received appropriate reviews for quality before being submitted to the Office.

v. Communication Management: approach that will be used to provide the Office with a detailed communication plan.

vi. Organizational Change Management: process, tools, and techniques they will use to manage the people side of change.

vii. System Interface Plan: approach and process that will be used to perform the Office desired interfaces.

viii. Resource Management Plan: approach to resource management and managing resource allocation for the Office and vendor teams.

Attachment A – Tab 3 Page 19 of 45 CCMS Solution and Implementation

Tab 4 – Key Proposed Personnel and Team Organization

I. ORGANIZATIONAL CHART

i. The Office anticipates that any vendor staff assigned to the Project will remain assigned to the Project, unless SGAL deems the services to not meet expectations at which point the Contractor and SGAL will work together to remedy such non-conforming services. Proposer to identify the approach to assignment and (as necessary) replacement/removal of vendor staff during the implementation process.

ii. Describe the proposed approach to staffing for the implementation process. Will SGAL be working with separate resources on the Proposer team based on functional area (e.g., case and volunteer management) or will the Office work with a more limited number of resources that may provide cross-functional expertise?

a. Does your firm provide certification(s) for staff based on knowledge/achievement in understanding the software solution? If so, will all staff assigned to the implementation be certified in the software product(s) proposed?

iii. Proposer to submit as an Exhibit to Tab 4, an Organizational Chart including subcontractors and reporting structure of the entire team proposed to work on the Office’s project.

II. PROJECT TEAM RESUMES (PROPOSER)

i. As an Exhibit to Tab 4, resumes shall be provided for the implementation team, as well as additional personnel involved in the proposed project governance structure, including any partners/subcontractors. Resumes shall be specific to the actual personnel to be assigned to this Project for all primary roles (e.g., Project Manager, Conversion Lead). Resumes to include listing of past software implementation projects and certifications held for each team member.

Attachment A – Tab 4

ii. Summary of Project Team: Proposer shall complete the table on the following page listing a summary of the Project Team Members including any partners/subcontractors.

Table 4-01: Proposer Project Team Members

Proposer Project Team Members

Name

Title

Tab 5 – Project Schedule

I. PROJECT SCHEDULE

i. Proposer shall submit a proposed Project Schedule with the major milestones, activities, and timing of deliverables for the Scope of Work described in the RFP. In addition, the response should reflect Project predecessors, successors, and dependencies.

· The Office requests that the sample Project Schedule be in a Gantt (bar) chart format.

· The Office would expect implementation of the project to begin by May 2026.

· Proposer to submit as an Exhibit, a sample Project Schedule and insert in Tab 5 Exhibit submitted Yes No

II. PROJECT DELIVERABLES, MILESTONES, AND PAYMENT APPLICATIONS

i. Proposer to include a list of deliverables and milestones of the Project and should describe exactly how and what will be provided to meet the needs of the Office.

ii. Proposer to submit their payment schedule, tied to the listed deliverables and milestones for review by the Office, as an exhibit to Tab 5. This schedule shall be consistent with the terms provided in Attachment C2 of the RFP (Cost Narrative) and should not include the dollar amounts for payments, but rather the events that would trigger payments. Notation should be made as to the payment structure for services (e.g., fixed fee, time and materials).

Exhibit submitted Yes No

III. PROJECT SCHEDULE QUESTIONS

Table 5-01: Project Schedule Questions

1. Based on current obligations, what is the earliest you can begin implementation after contract signing?

Attachment A – Tab 5

2. What activities would the Proposer expect to occur within the first 60 days of contract signing?

3. How long does the typical implementation of the product being proposed take for an organization of similar size to the Office?

4. What special considerations are there related to the timing of go-live activities? Does it vary based on functionality?

IV. PROJECTED GO-LIVE DATES

The Office anticipates that implementation activities would begin in May 2026. The project and all required modules must be completed, tested and fully deployed on or before June 30, 2027. The Office follows a July 1 – June 30 fiscal year. Proposers are encouraged to propose phasing and timelines that best align with the Proposers implementation approach.

Table 5-02: Projected Go-Live Dates

I

II

III

Tab 6 – System and Application Architecture

I. GENERAL OVERVIEW

Proposer to provide a description of the proposed system and application architecture for the proposed application.

II. SYSTEM AND APPLICATION ARCHITECTURE QUESTIONS

Table 6-01: System and Application Architecture Questions

1.What is the source language(s) of the product?

2.How many environments are available with your proposed solution at no additional cost (e.g., test, training, production)?

3.Describe how often major and minor software updates are provided, as well as the level of the Office resources required for a major update and the level of resources required for a minor update.

4.Please describe the major/minor upgrade process that is required if the solution requires a client-based installation.

5.List all browsers that are certified for use with the application and describe any required browser add-ons, function enablement, etc.

6.The underlying architecture of the application design is important to the Office. Please describe your system architecture model and explain the capabilities and features of this model that led to your use of it in developing this system.

7.Please describe how data privacy and security compliance is supported within your proposed software solution. Is the system HIPAA compliant?

8.Describe your approach to ensure scalability of the product. This includes transaction growth, upgrades, and replacements of components of the architecture, technology, and application.

Attachment A – Tab 6

9. List all hardware/operating system/database platforms upon which the product is supported. Provide specifications in terms of processors, processor speed, memory requirements, and other sizing and capacity factors to assist the Office in budgeting for and acquiring hardware. List which industry standard benchmarks or guidelines measures are used to establish this recommendation.

10. Describe the design philosophy of your application. Include in your response the degree to which there is a common design philosophy across all modules, common programming languages and tools, and the extent of shared software code across all applications.

Attachment A – Tab 6

Attachment A – Tab 8

I. APPROACH

Tab 7 – Data Conversion Plan

Proposer to detail their approach to developing and implementing the data conversion plan, and what processes will be undertaken by the Proposer’s project team to convert existing data, as well as to interface with identified source systems. Include methods of quality control and testing that will be utilized specific to data conversion.

Describe your organization’s recommended approach toward retention of legacy data. Please describe what options are available, and supported, within your proposed solution. Also, please provide any relevant references of organizations that have successfully addressed legacy data with your solution.

II. ROLES AND RESPONSIBILITIES

The Awarded Proposer may assist SGAL in the conversion of both commercially available software-based data, and any applicable data maintained in a Microsoft Office application, into the new system.

It is expected that the Office will be responsible for data extraction from current systems and data scrubbing, and that the Awarded Proposer shall be responsible for overall data conversion coordination, definition of file layouts, and data import and validation into the new system(s).

Awarded Proposer should plan to have converted data ready for the User Acceptance Testing (UAT) phase of the Project.

As part of the resulting Project, the Awarded Proposer shall develop and provide a detailed Data Conversion Plan that describes how files will be converted to the proposed system (e.g., through software conversion aids/utility programs or special programs that must be written, the actual conversion procedures). A conversion schedule should identify planned conversion steps, estimated hours, and what resources will be required (by the Office or Awarded Proposer) for all pertinent legacy data.

A. Proposer to confirm their proposal includes providing the services identified in this Section (Item II Roles and Responsibilities) and provide any additional services that are also provided as part of your Data Conversion Plan/Program.

B. Proposer to specify or provide the format in which legacy system data should be extracted and provided to the Proposer for conversion activities.

C. Proposer to specify how it will assess and classify legacy cases to determine which should be archived versus partially or fully migrated.

D. Proposer to describe the technical and functional approach to archiving cases, including how archived cases can be searched and accessed.

E. Proposer to specify whether archived cases can be linked to or integrated with the new CCMS.

F. Proposer to describe the workflow and system considerations for efficiently reactivating archived cases when future action is required.

III. Responsibility of Data Conversion Activities Proposer shall complete the table below based on whether the roles identified are supported by the proposed data conversion methodology and approach. The roles defined in Table 7-01 and Table 7-02 contain the indicators that Proposer shall use to report their support of the identified roles. Any conflicts shall be noted with a comment. In the event additional activities are proposed, the Proposer shall identify the roles for both the Office and their Implementation Project Teams.

Table 7-01: Definition of Roles

Table 7-02: Summary of Response Indicators

C

Conflict The Proposal has a conflict with the prescribed responsibility roles and proposes alternate responsibility in its proposed data conversion methodology and approach.

Table 7-03: Responsibility of Deliverables

Tab 8 – Security and Software Hosting

I. GENERAL OVERVIEW

Proposer to provide a description of the proposed application security features/functionality as well as the underlying technology used to support hosting and access to the software by clients.

II. SECURITY QUESTIONS

Proposer to respond to the following questions related to system security and access controls.

Table 8-01: Security Questions

1. Is Active Directory integration and/or single sign-on supported? Please provide applicable diagrams and/or details to substantiate the level of integration and compliance with published internet standards (i.e., LDAP and DNS).

2. Proposer shall detail the ability of the proposed system(s) to integrate with Active Directory Domain Services implemented in accordance with published internet standards such as Lightweight Directory Access Protocol (LDAP) and Domain Name System (DNS). If such integration is not offered, Proposer shall explain the identify management solution that is provided.

3. Describe how the SaaS application/service provides two-way user and group synchronization with Active Directory (AD). (e.g., As users and groups are added to and removed from AD, these changes are reflected in the SaaS applications). Would the Office AD be able to push, and the SaaS applications able to receive, user profiles and groups?

4. When a user is added to AD, are the proposed solutions automatically provisioned and, conversely, when a user is removed from AD, access is automatically revoked?

5. Are users able to sign on to the Windows network once, and then easily gain access to the proposed applications without having to enter an additional set of credentials?

6. Will Proposer require remote access to the Office systems/network to provide support/management of the solution either during implementation or post go-live? If yes, please describe in detail what type of access is required.

7. If any access, remote or physical, is required for accessing the Office’s systems/network, will Proposer agree to reviewing and having applicable staff consent to follow the applicable Office Security Policies?

8. Will Proposer staff resources be accessing the Office systems/network remotely from outside the United States? If yes, please describe in detail the reasoning and how security will be managed.

9. Describe in detail the password requirements and account management standards for the system.

· Can complex password requirements be enforced on the software along with aging requirements if SSO is not available?

· Can accounts be locked-out automatically after ## failed login attempts?

· Are session timeouts enforced in the system?

10. Describe in detail the current and enforced information security management policy?

11. Does the Proposer have independent third-party vendors that conduct annual information security penetration tests for all IT related systems, and can these tests be provided to the Office?

12. Provide the type of documented information security policies that are currently in place?

13. Has Proposer experienced any security breaches, ransomware attacks, phishing, or malware incidents in the past few years?

14. Is multi-factor authentication required or optional?

III. SOFTWARE HOSTING QUESTIONS

Proposer to respond to the following questions regarding their software hosting platform proposed for the Office.

Table 8-02: Software Hosting Questions

1. Where are the data center and storage facilities?

2. What is the total number of active clients currently served by hosted/SaaS solutions provided by your company?

3. How many years has your company provided hosted/SaaS solutions?

4. How are hosted/SaaS software applications deployed for use by numerous customers?

5. What availability and response time do you guarantee?

8. What is your process for notification of standard maintenance and downtime?

9. What data security and system redundancy capabilities are available at Proposer’s data center and storage facilities?

10. Will data be encrypted at rest, and in transit? Please explain any applicable protocols.

11. Provide relevant documentation related to any recent certifications pertaining to the Proposer’s hosting technical and operation capabilities or that of their subcontracted provider for these services.

12. Provide detailed information on the way(s) in which the Office will access the software if deployed in a SaaS or hosted environment. Such information should include how the software is accessed when on or off the Office network, as well as any additional hardware/software that may be required for accessing the software.

13. How is data stored? Would the Office data be physically or logically segmented from other client data?

14. Please describe the database storage capacity of the proposed solution.

i. Are there limits on the amount of data that can be stored in the proposed solution?

ii. If applicable, what tiers of storage are offered in the hosted/SaaS environment?

15. What disaster recovery services are provided under your standard hosting agreement? If not standard, is there a separate agreement/cost associated with disaster recovery?

16. Please describe the anticipated cost savings or cost avoidance (e.g., reduced hardware needs, maintaining failover sites) that may be realized through selecting a SaaS deployment model. Specific figures from past projects that can be substantiated may be included.

Tab 9 – Testing & Quality Assurance Plan

I. APPROACH

Describe your standard approach to testing and quality assurance.

II. SAMPLE PLAN

Submit a Sample Testing and Quality Assurance Plan that would be very similar to the plan utilized for the Office’s Project. Proposer to submit as an Exhibit a Sample Plan in Tab 9.

Exhibit submitted Yes No

III. PLAN DETAILS

Awarded Proposer must provide a Testing and Quality Assurance Plan that describes all phases of testing that may be used: unit, system, interface, integration, regression, parallel, and user acceptance testing (UAT). It is the Office’s expectation that the Testing and Quality Assurance Plan govern all phases of the Project and that the Proposer will also provide assistance during each testing phase involving the local Circuit Office and Portal users. The Awarded Proposer will develop the initial UAT plan, provide templates and guidance for developing test scripts, and will provide onsite support during UAT. The Awarded Proposer will also provide a plan for stress testing the system, which will occur during or after UAT. Proposer to confirm their proposal includes providing the services identified in this Section (Item III Plan Details) and provide any additional services that are also provided as part of your Testing and Quality Assurance Plan not listed.

IV. LEVELS OF SUPPORT

What levels of support will be provided by the Proposer during the Office testing phases? Will Proposer resources be onsite during certain testing phases? Will Proposer include virtual training resources? Are varying service levels offered for testing support?

Attachment A – Tab 9

Tab 10 – Training Plan

I. PROPOSED TRAINING APPROACH/STRATEGY

Proposer to describe the proposed approach to training users of the system, including the frequency of training, timing in the overall sequence of the implementation, as well as training resources/materials that will be provided to trainees.

Proposer to provide their approach to the training plan and what makes their training plan successful and effective for system implementations. Include your approach to when and why you choose to use on-site training versus a webinar or a train-the-trainer format.

Proposer to detail the knowledge transfer strategy proposed to prepare the Office staff to maintain the system after it is placed into production.

Proposer to detail the approach to conducting training using webinar (e.g., GoToMeeting, Zoom, Teams, Skype), including how Proposer staff will monitor staff comprehension and, if applicable, provide assistance to trainees on navigation through the system.

Proposer to identify the requested analysis/training room environment requirements and any other requirements related to the training facility/room/equipment. Requirements may include any presentation equipment, whiteboards, seating style, number of computers, printers, and other amenities needed to support on-site implementation activities.

Attachment A – Tab 10

II. TRAINING PLAN AND RESOURCE HOURS

Proposer to provide a chart detailing the proposed training plan and resource hours allocated for the Office’s project. A sample format of the chart is detailed below. Cost Worksheet provided in Attachment C1 to coincide with the hours and resources proposed.

Table 10-01: Training Plan Legend

Legend

Table 10-02: Training Plan

Training topic/course

General summary of number of sessions offered of this course

Maximum class size

Format for the class

Training data that will be used for this topic/course (live, sandbox, etc.)

Proposer to submit as an Exhibit a Sample Training Plan and insert in Tab 10.

Exhibit submitted Yes No

III. TRAINING COORDINATION

Proposer to detail the roles and responsibilities for the training effort, including but not limited to:

Table 10-03: Training Roles and Responsibilities

Role/Responsibility Identify if Role/Responsibility is the Office/Proposer (including any Subcontractors)/Shared

Training Coordination/Scheduling

Training Curriculum/Material Development

Training Instruction/Delivery

Other:

IV. SYSTEM DOCUMENTATION

Proposer to provide a detailed description of system documentation and resources that will be included as part of the implementation including, but not limited to, detailed system user manuals, “Quick Reference” guides, etc. as available. Proposer to itemize optional items on Attachment C1. Proposer to check off (in the table below) all that are available and included as part of the RFP response.

Table 10-04: System Documentation

Quick Reference Guides

Online Support

Help Desk Support

User Group Community Resources

Annual User Conferences

Videos

Custom User Guides/Manuals

Other:

CCMS Solution and Implementation Services

Tab 11 – References

I. INSTRUCTIONS FOR REFERENCES

Proposer is responsible for verifying correct phone numbers and contact information. Failure to provide accurate data may result in the reference not being considered, which includes the provision of contact person(s) who do not have knowledge of the services provided by your firm. Failure to submit references may result in the Proposal not being considered for evaluation.

The Office may request a more detailed list, including other governmental agencies. The Office reserves the right to request or contact additional or different references from the provided…