City_of_Cleveland_HCM_Selection_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 Ohio and is licensed or qualified to conduct business in the State of Ohio

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

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

Name of Company

Address

Telephone Number

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 HCM clients

Total number of active Government Sector HCM 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 Ohio 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 Ohio on implementations. What proactive steps are planned in this proposed project to mitigate against similar challenges?

v. Please describe your experience with working with an organization with over 30 bargaining units and any challenges faced. What proactive steps are planned in this proposed project to mitigate against similar challenges?

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

V. USE OF SUBCONTRACTORS

The Proposer shall identify any of the required Services that are proposed to be subcontracted, or leverage third-party partners, 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 to a third-party?

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

Has a third-party software product been included in this proposal? If so, will the implementation of that product be completed by the software owner/manufacturer, the prime proposer, or a third-party integrator?

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

Name of subcontractor/partner and address

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

Summary of software functionality provided for by the subcontractor or partner.

Reasons for subcontracting/partnering

Experience

Detailed subcontractor/partner responsibilities

Previous history of projects using the named subcontractor/partner

Any additional relevant information

The City reserves the right to request a copy of any applicable 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.

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

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

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

Vendors to provide a release schedule

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 C 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 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 City, perpetual licenses)

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

c. 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. Describe your definition of “real-time” as it relates to interfaces.

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. Describe how the system works and interacts with Microsoft (MS) products.

ix. Describe any existing State required reports created for other clients in Ohio that the City could leverage (e.g., Ohio Public Retirement System (OPERS).

x. 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? What implementation activities are recommended to be on-site (e.g. project kick-off, training, user acceptance testing/payroll parallel processing).

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

a. As it relates to teaching the City to configure the system (compensation plans, benefits, etc.) is it expected that the City would gain the knowledge of how to do this during the implementation, and complete a certain level of configuration itself? If yes, is this for all areas within the system or are there certain areas that only the proposer would configure?

b. What metrics and measures impact the scoping work effort for your professional services? If it is found that the City has a greater number of a certain metric (e.g. positions) than initially contemplated in the project would there be a change order to add to the configuration effort?

c. If there are changes during the implementation (ex. New benefit carrier or coverage option, re-negotiated collective bargaining units) how does this impact the project schedule and approach to setting up and testing the system?

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.

vi. Describe your approach to coordinating the delivery, review, and acceptance of project deliverables. What is the process for client-review of deliverables as well as the associated timelines. How is acceptance of deliverables documented?

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

II. GO-LIVE AND ONGOING SUPPORT

i. 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 C, Cost Worksheets, to clearly identify the varying fees based on the varying levels of support that are available.

ii. The City has a strong preference that a single vendor be responsible as a point of contact for any support requests related to one or more software products that may be submitted as a part of a proposal. For example, if a core HCM vendor has proposed a solution to address HR and payroll needs, and partnered with a time and attendance/scheduling vendor, the City would prefer to submit all support tickets to a single party as opposed to having to navigate support through two separate support teams. Please describe if this mode of support is offered or feasible through your proposal (if applicable to the scope of the software and/or any partnerships proposed) as well as describing how the contractual relationships would work as well as support call processes.

iii. Do your clients typically contract with a system integrator (if applicable) for managed services or other professional services following an implementation project in order to serve as a consulting firm to support optimization of implemented modules, support integration maintenance, provide ongoing upgrade/update testing and support, etc? If yes, please describe the services. The City would consider any such offerings as optional at this stage in the process unless required or strongly recommended by the proposer.

Support Processes and Standards

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

v. Are afterhours and weekend support offered, and if so, is this part of the standard support offering or part of a different tier/offering?

vi. Describe the support response and resolution tiers that are offered for the proposed solution.

a. Describe the escalation process the City would follow should a submitted support ticket not be satisfactorily resolved or responded to in a timely manner.

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

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

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

x. If there are challenges or work needed to be performed on integrations that are developed during the implementation process, what is the role of your firm in supporting the City with maintaining and troubleshooting these integrations once the City is in a live production environment?

Updates, Upgrades, and Release Management

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

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

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

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

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

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

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

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

IV. 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:

Vendor Team

Proposer shall include the anticipated resource hour’s levels 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 Vendor 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 (example: The City owns 20% of the work effort, and the Vendor owns 80% of the work effort) along with any narrative to support this estimate. The City requests detailed estimations.

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

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

VI. 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 Scope and the process used to request changes to Project Scope. 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 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 desired interfaces.

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

Tab 4 – Key Proposed Personnel and Team Organization

I. STAFFING ASSIGNMENTS AND SERVICES WARRANTY

i. Please provide your standard language related to your professional services warranty and standard of care.

ii. The City anticipates that any vendor 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 Contractor and the City will work together to remedy such non-conforming services. In addition, the City expects to be notified within 7 days, should the assigned project manager resign. Proposer to identify the approach to assignment and (as necessary) replacement/removal of vendor staff during the implementation process.

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

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

v. The City expects certain terms to be included in the resulting contract related to professional services delivery, including the assignment of personnel, personnel warranty, and acceptance processes. Please state any exceptions to the following clauses.

a. Contractor’s Personnel Commitment and Obligations. Contractor shall perform its obligations as set forth in the applicable Statement of Work. In addition, Contractor shall: designate and provide for each Statement of Work one, unless otherwise so stated as more than one, Contractor point of contact who shall be responsible for answering and resolving Customer questions and issues relating to the project(s) described therein; and provide sufficient, qualified, knowledgeable personnel capable of performing Contractor’s obligations as set forth in the applicable Statement of Work. Contractor shall assign and meet the required staffing and resource needs for its provision of its Services. If Customer notifies Contractor that it is dissatisfied with the services of any person supplied by Contractor, Customer shall provide Contractor with a written description of such unsatisfactory services, and Contractor shall try in good faith to promptly resolve any concerns. If Customer continues to be dissatisfied with such person due to issues related to performance, workplace conduct, or behavior, Contractor will remove that person from the situation and will assign another qualified person to Customer work as soon as possible. Contractor agrees to use commercially reasonable efforts to maintain consistency of project personnel (subject to personnel employment status, promotion, leave of absence) and commits that replacement staffing resources will have sufficient project knowledge, qualifications and experience, without additional cost to Customer, in order to render services in accordance with the Agreement. In such a case, Contractor will provide a replacement within a commercially reasonable time while preserving overall project timelines. Contractor shall require each of its agents, officers, and employees to abide by any of Customer policies that are communicated or provided in writing to Contractor, including those prohibiting sexual harassment, pandemic response, security, firearms, and smoking, as well as all other reasonable work rules, safety rules, or policies regulating the conduct of persons on Customer property at all times while performing duties pursuant to the Agreement. Contractor and its agents, officers, and employees performing services on Customer premises and otherwise using Customer software, hardware, or equipment, shall comply with all Customer-provided security and information technology policies and practices. Contractor agrees and understands that a violation of any of these policies or rules will constitute a breach of the Agreement and will be sufficient grounds for termination of the Agreement by Customer.

Proposer Exceptions:

b. Standard of Care. Contractor warrants that its Services will be performed in a good, timely, thorough, and workmanlike manner, in accordance with the Agreement and in a manner consistent with the same degree of skill and care ordinarily exercised by professionals performing similar services in the same locality or industry, at the same site, and/or under the same or similar circumstances and conditions. Contractor shall be responsible for the professional and technical accuracy and the coordination of all work furnished under the Agreement as further set forth in the associated Statement of Work. Contractor shall furnish appropriate qualified and competent professional services for each aspect and task for which it is assigned per the Statement of Work so that detailed checking or reviewing by Customer is not necessary, except as reasonably required for formal deliverables in connection with stated Acceptance Processes. Notwithstanding any provision to the contrary, Customer review, approval, testing, acceptance or payment for any of the Deliverables, Services, equipment, and/or materials furnished shall not be construed to operate as a waiver of any rights under the Agreement or any cause of action arising out of the performance of the Agreement. Without limiting the generality of other provisions of the Agreement, in the event that any aspect of Contractor’s performance fails to comply with applicable law or Statement of Work due to Contractor’s negligence, Contractor shall make all necessary corrections at no cost whatsoever to Customer.

Proposer Exceptions:

c. Acceptance Processes. Contractor shall coordinate and facilitate procedures to review, inspect and test deliverables and services and to gain Customer feedback and complaints, all to identify defects, deficiencies and problems with the Project during all stages of the SOW. All materials, equipment, work and services of any kind or nature be in conformance with the requirements of the SOW and the Agreement. Following Contractor’s review, inspection and testing (as further set forth in the SOW), and its prompt correction of all defects or deficiencies in the materials, equipment, work and services, it shall determine, in accordance with the standard of care set forth in the Agreement, whether said materials, equipment, work and/or services is ready for Customer acceptance. If no, then Contractor shall take such actions as may be necessary to correct the inadequacy. If yes, then Contractor shall certify to Customer its conclusions with all back up documentation, and request Customer written acceptance of such deliverables or services. Customer shall, within ten (10) business days or as otherwise mutually agreed to, accept or reject each service, milestone, or deliverable and notify Contractor of the same. If Customer does not agree the particular service, milestone, or deliverable meets the specifications identified in the SOW, or lacks the documentation necessary to make that determination, Customer shall notify Contractor, in writing, with reasoning within seven (7) business days of receipt of the service, milestone, or deliverable. Contractor shall address any deficiencies and redeliver the service, milestone, or deliverable within a mutually agreed upon timeframe based upon the complexity of the deficiencies. Customer shall then have five (5) business days, or as otherwise mutually agreed to, from receipt of the redelivered service, milestone, or deliverable to accept or again submit written notification of reasons for rejecting the service, milestone, or deliverable. This acceptance process will continue until Customer Accepts each deliverable. Customer failure to timely reject a service, milestone, or Deliverable shall not be construed as a constructive acceptance. In such an event where Contractor is without fault, Contractor’s sole remedy shall be an equitable extension of time in performance. Acceptance by Customer shall, in no event, modify or limit Contractor’s obligations under the Agreement or SOW, nor shall Customer be deemed to have waived any rights or remedies Customer may have under the Agreement or the resulting SOW.

Proposer Exceptions:

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 July 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 Tab 12 of this Attachment 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 July 2024. The City would like to target January 2026 as a potential go-live date for the human resources and payroll modules. The City follows a January 1 – December 31 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. List all browsers that are certified for use with the application and describe any required browser add-ons, function enablement, etc.

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

5. Please describe how data privacy and security compliance is supported within your proposed software solution.

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

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

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

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

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

iii. Does your solution have the ability to serve as a data warehouse for all legacy system data to be converted into? If so, is the data partitioned from “new” live data that is entered in the system?

iv. If your system does not have data warehouse capabilities, do you offer a separate solution/approach to maintain all of a client’s legacy data? What is your recommended best practice?

v. Describe your organization’s best practices related to converting legacy data, including if you would recommend the City consider alternatives to the requested conversion scope contained in Attachment B, Data Conversion tab.

vi. Describe your organization’s approach to converting scanned documents/attachments from a legacy system, and whether this is something that has been proposed in-scope or not.

vii. How many data conversion passes have been included within scope, and are there limitations on the number of conversion passes that can occur?

viii. Describe any alternative approached to a full data conversion process, such as imports or manually keying data, and where this is most advantageous to occur.

ix. Describe the approach to data conversion for the final conversion pass, including how far in advance this typically occurs prior to go-live, and what level of manual entry of data (new employees, catch-up contributions, accruals, etc.) may be required for City staff to perform.

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, into 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.