City_of_Santa_Cruz_ERP_RFP_-_Attachment_A.docx

Attachment A – 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 A) in the corresponding tabs as a part of their Proposal response. In addition to the information captured through the questions and tables in Attachment A, 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 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 California and is licensed or qualified to conduct business in the State of California

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 City of Santa Cruz (City).

If the Proposer fails to comply with the provisions stated in this paragraph, the City 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

Legal Name of Company

Business Entity Status (i.e. LLC, corporation, etc.)

Address

Telephone Number of principal office

Direct Telephone Number of Primary Contact

Email Address

Signature of Authorized Officer of the Firm

A signature provides the City 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 ERP clients

Total number of active Government Sector ERP clients

Total years offering proposed software systems

County:

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 California entities (Counties, Municipalities, etc.).

ii. Please describe any relevant experience working with similarly situated municipalities, including any unique factors that arise during the implementation process.

iii. Identify two recent project implementations that are most comparable to the City’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 California 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 the City 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 City 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 the City for all Services contracted by the Proposer and the subcontractor under this RFP.

The City 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 City.

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

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 City website.

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 two well-developed paragraphs per functional area). The purpose of this summary is so that the City 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 on 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?

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 employee self-service) have a different license type than other users (e.g., Human Resources Director)?

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

If an existing user separates from service at the City, may their license be re-assigned to a new staff member, or, must a license remain assigned to that staff member in order to maintain employee records/retiree benefits/etc.?

Deployment Model

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

Summary of Modules Proposed

*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 to be 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

ii. For each product proposed as a Partnership/Third-Party product, detail the options available to the City as it relates to contracting relationship between the City 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 two categories presented in a-b below. If more than one product is proposed, please clearly identify the deployment model for each product proposed:

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

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

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. Proposer shall describe available hardware options to support cash register/drawer functionality. The City will consider these on an optional basis, and costs shall not be included in the technical proposal.

v. Proposer shall describe available time clock options to support time capture functionality. The City will consider these on an optional basis, and costs shall not be included in the technical proposal.

vi. 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?

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

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

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 localities, 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 City during implementation? Will staff be on-site for full or partial weeks? With what frequency will Proposer’s Project Team staff be on-site at the City for any support or maintenance obligations? Has this approach been tailored based on social-distancing practices or has the proposed approach been standard for other implementations?

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

a. Describe in detail the approach for developing and testing integrations prior to the City user acceptance testing.

b. 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 City subject matter experts, or will the City 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 City technical environment, staffing, project management approach, and City resources available during implementation and support phases.

II. DEPLOYMENT

Proposer to provide a detailed narrative description of how the implementation approach will vary between the deployment methods proposed (i.e., 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 afterhours 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 City is unable to conduct certain mission-critical processes, such as processing payroll, 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 City 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 City 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 City 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 City.

V. RESOURCE HOURS

Proposer shall include the proposed resource levels for the City 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 City 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 City teams, roles of staff, and duration of involvement used in the development of the resource hour estimates should be included here:

Proposer Team

Proposer shall include the anticipated resource hour’s for the City 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 Proposer Comments column.

Table 3-02: Anticipated Hours by Project Role Anticipated Hours by Project Role

City Project Role (e.g., Project Sponsor, Project Manager, Conversion Lead)

Executive Sponsor

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

Data Conversion 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 City and the vendor teams, the City expects to own 20% of the work effort, and the Proposer owns 80% of the work effort along with any narrative to support this estimate.

i. Describe how the implementation work effort will be split between the City staff and Proposer’s staff (i.e., configuration, testing, training, etc.)?

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 City’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 City’s Project, including the following areas:

i. Scope Management: approach for managing the Project’s Scope of Work as described in the RFP and the process used to request changes to the Project’s Scope of Work. It is the City’s desire to use the proposed software system “as is” and, as such, any changes (e.g., customizations or modifications to the software) must be reviewed and approved by the City’s Implementation Project Team.

ii. Schedule Management: approach for managing the City’s Project Schedule (as defined further in Tab 5 below) 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 City’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 City.

v. Communication Management: approach that will be used to provide the City 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 City’s desired interfaces.

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

ix. Escalation Plan: protocol for collaboratively resolving issues encountered during the term of any contract resulting from this RFP. The proposed escalation process must explain how issues or complaints are prioritized and resolved.

Tab 4 – Key Proposed Personnel and Team Organization

I. ORGANIZATIONAL CHART

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

ii. Describe the proposed approach to staffing for the implementation process. Will the City be working with separate resources on the Proposer team based on functional area (e.g., payroll, time/attendance) or will the City 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 City’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.

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

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 City requests that the sample Project Schedule be in a Gantt chart format.

· The City would expect implementation to begin in 3rd Quarter 2024.

· 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 City.

ii. Proposer to submit their payment schedule, tied to the listed deliverables and milestones for review by the City, 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?

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 City?

4. What special considerations are there related to the timing of go-live activities? Does it vary based on functionality (e.g., benefits go-live being aligned with open enrollment, payroll with calendar year or quarter)?

IV. PROJECTED GO-LIVE DATES

The City anticipates that implementation activities would begin in the 3rd Quarter 2024. The City would like to target 3rd Quarter 2025 as a potential go-live date for financial modules, and 1st Quarter 2026 as a go-live date for human resources and payroll modules. The City would like to target 3rd Quarter 2025 as a potential go-live date for utility billing, the City anticipates the utility billing activities would overlap with the ERP implementation activities. The City follows a July 1 – June 30 fiscal year. Proposers are encouraged 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 and during which hours, as well as the level of City 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 City. 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.

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 City 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.

Tab 7 – Data Conversion Plan

I. APPROACH

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 will assist the City in the conversion of both commercially available software-based data, and any applicable data maintained in Microsoft Excel and Access, in to the new system as further described in the sources identified in Attachment B, Data Conversion tab.

It is expected that the City 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 City 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.

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 City and their Implementation Project Teams.

Table 7-01: Definition of Roles

Table 7-02: Summary of Response Indicators

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 City 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 City 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 City’s systems/network, will Proposer agree to reviewing and having applicable staff consent to follow applicable City Security Policies?

8. Will Proposer staff resources be accessing the City 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?

III. SOFTWARE HOSTING QUESTIONS

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

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?

6. How many instances of unplanned outages have any of your customers experienced within the past five years? Describe the nature of any such outages, including the mitigating steps that have been established to minimize repeat outages.

· What has been the duration and scope of such unplanned outages?

7. What are the standard relief schedules for unplanned system downtime/outages?

· In how many instances has your firm had to pay client relief for unplanned outages?

8. What is your process for notification of standard maintenance and downtime? What is your process for notification of unplanned outages 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. How many years has your company provided SaaS solutions?

12. What is the total number of active clients currently utilizing the proposed software as a SaaS deployment provided by your company?

13. 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.

14. Provide detailed information on the way(s) in which the City 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 City network, as well as any additional hardware/software that may be required for accessing the software.

15. How is data stored? Would City data be physically or logically segmented from other client data?

16. 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?

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

18. 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.

19. Please describe the proposed services for user setup, authentication and management processes.

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 City’s Project. Proposer to submit as an Exhibit a Sample Plan in Tab 9.

Exhibit submitted Yes No

III. PLAN DETAILS

Awarded Proposer will be responsible to 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 City’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 City 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 City testing phases (e.g., parallel and UAT)? Will Proposer resources be onsite during certain testing phases? Are varying service levels offered for testing support?

V. PARALLEL TESTING

Describe the proposed approach to payroll parallel testing, including the number of anticipated parallel tests which would be performed for payroll processes.

Describe the proposed approach to parallel testing for utility billing, including the number of anticipated parallel tests which would be performed for billing processes.

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 City 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.

II. TRAINING PLAN AND RESOURCE HOURS

Proposer to provide a chart detailing the proposed training plan and resource hours allocated for the City’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

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

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