8-RFP 546288.docx

DOCX document 123 KB Posted

Attached to
Community Engagement Platform
Solicitation number
546288
Issued by
Wayne County, Detroit City, Michigan

About this file

This is a Request for Proposals (RFP) issued by the City of Detroit Office of Contracting and Procurement on behalf of the Department of Innovation and Technology for a Community Engagement Platform, which is a cloud-based mass communications system. The City seeks a qualified contractor to provide a public-facing online portal enabling citizens and city employees to manage mass communications via email and text message, with capabilities including user subscription management, scheduled and ad-hoc message sending, branded and custom templates, unlimited email sends with bounce management, and a minimum of 5,000,000 SMS/text messages per year. The system must include 24/7 monitoring and support, data migration services, delivery and engagement reporting, web-hosted training sessions, and comprehensive documentation. The pre-proposal conference is scheduled for June 5, 2026, at 1:00 p.m. EST via Microsoft Teams, with questions due by June 12, 2026, at noon EST and proposals due June 22, 2026, at 4:00 p.m. EST through the EUNA Bonfire Supplier Portal. The contract term is five years with two optional one-year renewals, contingent on Detroit City Council approval.

The evaluation will occur in one phase with technical proposals reviewed before cost proposals, using criteria including product quality and ability to meet functional and security requirements (40 points), project approach and work plan (30 points), vendor experience and staff capabilities (15 points), and pricing (15 points). Respondents must demonstrate a minimum of three years of experience providing similar services for comparable projects. Detroit Equalization Credits will be applied post-evaluation for qualifying businesses. The City anticipates one award and reserves the right to request oral presentations or demonstrations, negotiate with top-ranked respondents, reject any proposals, or cancel the RFP. All proposals must be submitted through the EUNA Bonfire portal; faxed or mailed proposals will not be accepted. Pricing terms are based on a firm cost proposal with payment under the City of Detroit Prompt Payment Ordinance, and no work may commence until the contractor receives both a City Council-approved Contract Purchase Agreement (CPA) and a Standard Purchase Order (SPO).

View the file

Other files

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

CITY OF DETROIT

OFFICE OF CONTRACTING AND PROCUREMENT

REQUEST FOR PROPOSALS

RFP NO. 546288

Community Engagement Platform

Buyer: Latrece Yelder

EVENT / ACTIVITY
DUE DATE / TIME
ADVERTISEMENT DATE
(Date)

05/22/2026

PRE-PROPOSAL

CONFERENCE

(Date) 6/5/2026 @ 1:00 pm EST Location: Microsoft Teams

Bid 546288 Pre-Bid Conference | Meeting-Join | Microsoft Teams

QUESTIONS DUE
(Date) 6/12/2026 @ noon

All questions must be submitted online in the Supplier Portal as indicated in Section 3.3 of this RFP.

ANSWERS DISTRIBUTED
48-72 hours
PROPOSAL DUE DATE *
(Date) 6/22/2026 @ (Time) 4:00 pm EST

In the Supplier Portal as specified in Section 4.5 of this RFP.

* Respondents must register in EUNA Bonfire to download bid documents and submit bids. The City cannot guarantee the accuracy of any bid documents obtained from outside of EUNA, and bids submitted outside of EUNA Bonfire will not be accepted. Detailed resources about registering and bidding, including video tutorials and live, virtual office hours, are available at www.detroitmi.gov/suppliersupport.

Questions about the specifics of this RFP must be asked within the EUNA Bonfire Messages interface for the bid on or before the date and time indicated above. Questions asked via phone, email, and/or other means will not be answered.

Proposals must be uploaded in EUNA Bonfire on or prior to the date and time indicated above. Late and/or emailed proposals will not be accepted.

TABLE OF CONTENTS

Section 1. Project Summary and Background3
1.1.PROJECT REQUEST3
1.2.BACKGROUND/DESCRIPTION OF ENVIRONMENT3
1.3.AWARD CLAUSE INCLUDING RENEWAL OPTIONS3
Section 2. Statement of Work4
2.1.SERVICES TO BE PERFORMED4
2.2.OPERATIONAL INFORMATION4
2.3.TECHNICAL INFORMATION4
2.4.PAYMENT & PERFORMANCE BOND (Construction)5
Section 3. Proposal Evaluation and Selection Process6
3.1.MINIMUM QUALIFICATIONS6
3.2.ADHERENCE TO TERMS OF PROPOSALS6
3.3.QUESTION DEADLINE6
3.4.EVALUATION CRITERIA6
3.5.EVALUATION PROCEDURE7
3.6.ORAL PRESENTATION/DEMONSTRATION7
3.7.REJECTIONS, MODIFICATIONS, CANCELLATIONS7
3.8.PROTESTS7
Section 4. Required Proposal Content and Submission Process9
4.1.ACCURACY AND COMPLETENESS OF INFORMATION9
4.2.REQUIRED PROPOSAL CONTENT AND FORMAT9
4.3.REQUIRED COST PROPOSAL9
4.4.ECONOMY OF PREPARATION10
4.5.SUBMITTAL INSTRUCTIONS10
Section 5. General Conditions and Requirements for RFP11
5.1.CONTRACT APPROVAL11
5.2.PAYMENT11
5.3.INVOICES11
5.4.ASSIGNMENT12
5.5.MODIFICATION OF SERVICES AFTER CONTRACT APPROVAL12
5.6.NEWS RELEASE12
5.7.MISCELLANEOUS12
5.8.OFFICE OF INSPECTOR GENERAL13
RFP Attachments List14

Section 1. Project Summary and Background

PROJECT REQUEST

The City of Detroit Office of Contracting and Procurement (OCP) on behalf of Department of Innovation and Technology requests proposals from qualified Respondents to render certain technical or professional services ("Services") as set forth in this RFP to provide a Mass Communication Platform.

BACKGROUND/DESCRIPTION OF ENVIRONMENT

The City of Detroit Department of Innovation and Technology is seeking a Contractor to provide a public facing on-line portal for citizens and city employees that includes a cloud-based Mass Communications Platform. The System will provide the ability for staff to manage users and reporting tools. Provide customer and technical support (24 hours and emergency), bug fixes, software updates and a robust API for data migration and connectivity. The platform must allow the public to sign up to receive mass communications from the City of Detroit via email and/or text message. The platform will allow email and/or text message subscribers to subscribe to multiple mailing lists via an online portal. The platform will allow the scheduling of communications as well as the ability to send email and/or text message communications to citizens on an ad-hoc basis. The platform will allow Administrators to use branded templates as well as create custom templates for sending communications through the system. The platform will provide unlimited email sends with delivery and management of all bounces. The platform must be accessible from any secure location via the Internet. Provide a subscription network for citizens to subscribe to public mailing lists through the network. Allow users to subscribe and unsubscribe to mailing lists via an online portal. Provide text messages from a shared short code within the United States.

AWARD CLAUSE INCLUDING RENEWAL OPTIONS

If a contract is awarded as a result of this RFP, it will be a City of Detroit IT Contract (Attachment E). The term of the contract will be for Five (5) years with the option for two (2) one-year renewals. Any renewal option exercised under this contract is effective only after the approval of the Detroit City Council and signed by the Chief Procurement Officer. The City anticipates one award as a result of the RFP.

Section 2. Statement of Work

1.

2.

1.

2.1. SCOPE OF WORK- TECHNICAL INFORMATION, DATA SECURITY AND

COMPLIANCE

REQUIRED

· Cloud-based platform mass communications platform with subscribe and unsubscribe capabilities.

· User interfaces for Subscribers and Administrators

· Provide unlimited email sends with delivery and management of all bounces.

· Support to upload and migrate existing email lists.

· Provide delivery and engagement reports on communications sent through the system.

· Access to participate in the mass communication network.

· Ability to send mass notifications to multiple devices.

· 24/7 system monitoring, email and phone support during business hours, auto response to inbound messages from end users, and emergency support

· Text-to-subscribe functionality.

· Provide up to 4 web-hosted training sessions annually.

· Access to a complete archive of all data created by the client.

· Message template and integration development

· Minimum of 5,000,000 SMS/text messages per year

· New version release schedule, to include how the release would be accomplished at the user level and into a cloud-based data center.

· Backup and recovery procedures

· Documentation to include operations, technical manuals, online help, and training materials.

OPTIONAL

· Dynamic targeting for campaign sends by zip code

· Link conversion tracking for event and form submissions

· AI writing tools to improve open/click rates

· Accessibility checking tools to ensure compliance with ADA guidelines

· Creative control over subscription network pages

Proposers must describe their proposed solution and related functionality to capture and track all steps of the described processes including but not limited to data migration, data validation, data storage, data security, auditing capabilities, reporting, interfaces, and system requirements at the desktop and network level. Every proposal shall include the following sub-sections:

The substance of this Section of the Proposer’s response will be incorporated into the final contract, as part of Exhibit A “Scope of Services”.

A. Software Requirements

Proposer shall provide a detailed description of the product(s) and product versions being proposed. The response to this section shall detail the system features and capabilities and indicate if these are native to the software or if integration with a 3rd party software is required or recommended.

Include the following:

1. Cloud-based mass communications platform with subscribe and unsubscribe capabilities.

2. User interfaces for Subscribers and Administrators

3. Provide unlimited email sends with delivery and management of all bounces.

4. Support to upload and migrate existing email lists.

5. Provide delivery and engagement reports on communications sent through the system.

6. Access to participate in the mass communication network.

7. Ability to send mass notifications to multiple devices.

8. 24/7 system monitoring, email and phone support during business hours, auto response to inbound messages from end users, and emergency support

9. Text-to-subscribe functionality.

10. Provide up to 4 web-hosted training sessions annually.

11. Access to a complete archive of all data created by the client.

12. Message template and integration development

13. Minimum of 5,000,000 SMS/text messages per year

14. New version release schedule, to include how the release would be accomplished at the user level and into a cloud-based data center.

15. Backup and recovery procedures

16. Documentation to include operations, technical manuals, online help, and training materials.

All proposals must include the following information:

Proposed Solution

Cloud-based Mass Communications Platform with subscribe and unsubscribe capabilities

User interfaces for Subscribers and Administrators

Provide unlimited email sends with delivery and management of all bounces

Support to upload and migrate existing email lists

Provide delivery and engagement reports on communications sent through the system.

Access to participate in the mass communication network

Ability to send mass notifications to multiple devices

24/7 system monitoring, email and phone support during business hours, auto response to inbound messages from end users, and emergency support

Text-to-subscribe functionality

Provide up to 2 web-hosted training sessions annually

Access to a complete archive of all data created by the client

Message template and integration development

Up to 5,000,000 SMS/text messages per year

New version release schedule, to include how the release would be accomplished at the user level and into a cloud-based data center.

Backup and recovery procedures

Documentation to include operations, technical manuals, online help, and training materials.

B. Hosting and Platform Requirements

The Proposer must give an overview of all platform requirements associated with the proposal. If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable. Proposer must describe the following:

i. System Environments – The Proposer shall state all environments (e.g., production, development, and test) included in the proposal. If such environments are limited in functionality, scope or otherwise, the proposal shall describe such limits.

ii. Shared Components of the System - The Proposer shall clearly state and describe all shared components of the System (e.g., network segments, back-up tapes, etc.). The Proposer shall assume responsibility that any System components not identified as shared components are provided by the Proposer as System components dedicated for the City’s use only.

iii. Data Storage Limits and Overages – The Proposer shall clearly state all email message limits associated with the System. Where exceeding such email message limits would cause the City to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.

iv. Data Transfer Limits and Overages – The Proposer shall clearly state all text/SMS limits associated with the System. Where exceeding such text/SMS limits would cause the City of Detroit to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.

Solution

System environments

Shared components

Email Message limits

Text/SMS Message limits

C. Cloud Solutions

The Proposer shall clearly state and describe:

i. Its proposed service model (e.g., SaaS, PaaS, IaaS).

ii. Its proposed Cloud deployment model (e.g., Private Cloud, Public Cloud, Community Cloud or Hybrid Cloud);

iii. Whether it relies upon any third parties in the provisioning of its Cloud deployment model.

iv. Whether the Proposer offers any other Cloud deployment.

v. How another of Proposer’s Cloud deployment models might impact the City’s data security and any compliance obligations.

vi. How another of Proposer’s Cloud deployment models might impact pricing, but the Proposer shall state such costs in a clearly marked pricing proposal.

Proposed service model

Proposed cloud deployment model

3rd party provisioning

Rationale for cloud deployment solutions

Other cloud deployment solutions

Data security and compliance considerations

D. Network

The Proposer shall give an overview of all network and bandwidth requirements associated with the proposal. If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable; Proposer shall describe the following:

i. Normal Bandwidth Requirements – The Proposer shall include a reasonable estimate of minimum bandwidth required for concurrent application access and data access for “normal” daily operational use for cloud, hybrid and/or on-premise systems. Proposer shall also provide its definition of “normal daily operational use.”

ii. Peak Bandwidth Requirements – The Proposer shall include a reasonable estimate of peak volume/times for each retrieval and uploading transactions for cloud, hybrid and/or on premise systems

iii. Typical Impact – The Proposer shall include a reasonable estimate of the typical impact expected on the network post implementation.

iv. Other Network Requirements – The Proposer should describe the optimal physical network infrastructure required for an on premise solution to effectively mitigate latency and data speed issues. If proposing a cloud-based or hybrid hosting solution, please describe the physical network infrastructure, connectivity testing and performance assurance. Network architecture diagrams must be included with details regarding the management of remote systems.

If any assumptions are made to support the answers, clearly state those as part of the response.

Normal bandwidth requirements

Peak bandwidth requirements

Typical impact

Other network requirements

E. Data Extract, Transform, and Load

The proposal shall give an overview of all data migration, conversion, and transformation requirements associated with the System. If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable. Proposer shall describe the following:

i. Data Extract – The Proposer shall include the cost of extracting the data from the source System as part of their price proposal. The Proposer will explain the process to convert the data into a single format for the transformation processing and any tools that will be used. If the performance of this task will cause the City to incur additional cost, the Proposer shall state such costs in its separate pricing proposal.

ii. Data Transform – The Proposer shall include the cost of transforming the data from the source system to the proposed system as part of their price proposal. The Proposer will explain the transformation type required to meet the business and technical needs of the target database and the tools that will be used. If the performance of this task will cause the City to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.

iii. Data Load – The Proposer shall include the cost of loading the data to the proposed system as part of their price proposal. The Proposer will explain the load process and tools. If the performance of this task will cause the City to incur additional cost, the Proposer shall state such costs in its clearly marked pricing proposal.

Data extract

Data transform

Data load

F. Data Ownership, Access and Retention

If awarded, all City data shall be and remain the sole and exclusive property of the City. The selected Proposer will treat City data as Confidential Information. The selected Proposer will be provided a license to the City data hereunder for the sole and exclusive purpose of performing its obligations under the Standard Contract, including a limited non-exclusive, non-transferable license to transmit, process, and display the City data only to the extent necessary in the provisioning of the services and not for the storage or recording of the City. The selected Proposer will be prohibited from disclosing City data to any third party without specific written approval from the City. The selected Proposer will have no property interest in, and may assert no lien on or right to withhold data from the City.

Proposer is expected to acknowledge and accept, or state any objections to, the City’s data use and ownership.

Proposer shall also provide a statement of its data protection practices and its responsibilities to protect and prevent the use or sale of data to/or by external entities. The Proposer’s full data protection policy shall be included as an attachment to its proposal.

Furthermore, the proposal shall state that the Proposer will meet the following data-related System requirements:

i. At all times, the City shall be able to receive data, associated metadata, and reasonably granular subsets thereof, as well as any associated files or attachments, from the System in a useable, encrypted format.

ii. Upon termination of the contract and at the City’s written request, the Proposer shall destroy City data, including back-ups and copies thereof, according to the National Institute of Standards and Technology (NIST) standards or as otherwise directed by the City.

iii. The System shall have the ability to retain City data in a manner that is searchable and capable of compliance with records retention laws and best practices.

iv. At no time may Proposer suspend or terminate City’s access to City data or the System for breach of contract or term or condition relating to the System without giving the City reasonable notice and opportunity to cure according to the City’s dispute resolution process.

G. Licensing and additional Terms and Conditions

Proposer shall describe the following:

i. Licenses The Proposer shall also succinctly state:

a. . The duration of the software licenses, if any (e.g., perpetual)
b. The City’s rights under the license (e.g., use, disclosure, sale, etc.)
c. Other license restrictions.
d. Any terms and conditions within the license that contradict or conflict

with the provisions of the Standard Contract.

ii. Additional Terms and Conditions – The Proposer shall agree to the terms and conditions in the City’s Contract (attached as Appendix A), as well as any special conditions to which the City and the Proposer agree, will supersede any terms and conditions proposed by the Proposer or third parties. If the proposal would require the City to agree to any of the following, Proposer shall include complete copies of same:

a. Acceptable use policies;

b. Privacy policies;

c. Other terms and conditions.

H. Intellectual Property

In addition to any other rights granted to the City under the Standard Contract or by operation of law, the Proposer must grant the City a perpetual, royalty free license to all materials prepared pursuant to the contract or in anticipation of the contract, including but not limited to the data, data schemas, studies, briefs, drawings, maps, models, photographs, files, records, computer printouts, estimates, memoranda, computations, papers, supplies, notes, recordings, and videotapes, whether such materials are reduced to writing, magnetically or optically stored, or kept in some other form, for unlimited use by the City for any lawful purpose.

I. Support and Maintenance

The proposal shall individually address each the following requirements and provide sufficient detail on how it meets the following requirements:

i. Multi-tiered support – The proposal shall provide multiple tiers of support and shall state whether the City is assumed to provide the lowest level, Tier 1, support. Define the tier support level and the criteria for each.

ii. Severity levels – The proposal shall provide support and maintenance response proportionate to varying levels of incident severity. Define the severity levels and define the response criteria.

iii. Multiple contact method – The proposal should provide for multiple methods of reporting an incident to the Proposer. Define the methods to initiate support for each tier.

iv. First-tier support scripts – If the Proposer assumes that the City will provide Tier 1 support, the Proposer shall deliver sufficient scripts and training to the City help desk staff and/or departmental technicians to adequately function as Tier 1 support. Define the script format, training requirements and if the provider is able to provide training.

Multi-tiered support

Severity levels

Multiple contact method

First-tier support scripts

The proposal shall individually address the following service level agreements (SLAs) for support and maintenance services, whether such SLAs are offered, any additional cost for such SLAs, and detail on such:

i. Proposer’s Help Desk Availability SLAs – Help desk availability refers to the required time frames during which certain Services provided by the help desk must be available to end-users, and response to automatically generated help desk incidents must be achieved.

ii. Proposer’s Response Time SLAs – Response time is the number of seconds it takes an end-user to connect with Proposer’s contact center live representative. Proposer will provide toll-free telephone lines in adequate quantity to handle call volume; automatic call distribution system (“ACD”) system(s) to record call date, time and duration information; and electronic interfaces to all systems for monitoring and reporting.

iii. Proposer’s Incident Resolution SLAs – Incident resolution is the time elapsed from the initiation of the help desk Incident until Service is restored.

iv. Proposer’s End-User Account Administration SLAs – Routine functions, such as setting up end-user IDs, changing End-User authorization tables, changing account codes and similar functions, which are handled by Proposer.

v. Proposer’s Client Satisfaction SLAs – Measures the level of end-user satisfaction in relation to help desk services.

For each SLA, the Proposer shall state:

i. Details on what written reports Proposer will provide to the City to demonstrate compliance with the SLAs in addition to the reports specified.

ii. Detail on any levels of SLAs, whether by severity or other classification.

iii. Detail on offered service level credits, fee reductions, and/or earn backs.

Help desk availability SLAs

Response time SLAs

Incident resolutions SLAs

End-user account administration SLAs

Client satisfaction SLAs

J. Data Security and Compliance

The proposal shall give an overview of the System’s software, hardware, and other controls supporting the System’s data security and the City’s evolution to a Zero Trust Environment. The Proposer shall provide sufficient details on its data security and privacy controls (using the City of Detroit Cloud Service Provider Security Checklist set forth in Section 10 below and details for any compliance certifications and/or accreditations.

The Proposer shall also provide a reasonably detailed explanation as to how the proposal will protect the System and City’s data within each of the following additional data security categories (NOTE: the City recognizes that reasonable descriptions of each security attribute below will vary in length, some attributes requiring little explanation, others not). If Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable:

i. Password configurations (e.g., complexity, aging, etc.);

ii. Authentication configurations (e.g., active directory, encrypted data exchange, hash, etc.);

iii. Encryption configurations (e.g., symmetrical AES-256, asymmetrical RSA 2048, etc.) for both data at rest and data in motion;

iv. Logging/Auditing review capabilities (e.g., verbose user tracking and reporting, etc.);

v. Physical security (e.g., 24-hour security, alarms, restricted access, etc.);

vi. Personnel security (e.g., extensive background checks, annual recheck, etc.)

vii. Web Application configurations (e.g., SQL injection protection, buffer overflow, etc.);

viii. Network transmission security (LAN and VPN);

ix. Data that is to be transmitted off-site must be encrypted end to end.

Password: complexity, aging, presentation

Authentication

Encryption

Logging & Auditing

Physical Security

Personnel Security

Web application configuration

Network transmission security

Data encryption

K. Development and Configuration Practices

Proposer shall describe its application development methodology and how its methodology adheres to applicable best practices and standards regarding both data security and data privacy. Proposer shall state how it will tender its deliverables in a manner that reasonably protects the security, confidentiality and privacy of City data and any individuals who may be considered data subjects as to the City, Contract deliverables, or City’s data. Specifically the Proposer shall state whether it conforms to the following:

i.Microsoft Secure Coding Guidelines for the .NET Framework;
ii.CERT Secure Coding Standards;
iii.OWASP Secure Coding Principles;
iv.Privacy by design principles; and

v. Federal Trade Commission’s Fair Information Practice Principles. On-Premise Cloud Hybrid Hosting

Description

Development & Configuration Practices

L. Business Continuity and Recovery

The proposal shall individually address each the following requirements and provide sufficient detail on whether and how it meets the following requirements.

i. Proposers shall have an automated backup and recovery capability for the system and application, including incremental and full back up capabilities. Additionally, system backups shall be accomplished without taking the application out of service and without degradation of performance or disruption to City operations.

ii. Proposers shall be able to provide the service from at least two geographically diverse data centers that do not share common threats (e.g. the data centers cannot be in the same earthquake zone, likely hurricane path, same flood zone, etc.). The data centers shall at a minimum meet Tier III standards for redundancy of power, telecommunications, HVAC, security, fire suppression and building integrity.

iii. Proposers shall specify whether, in the event of a technology or other failure at the primary processing center, the alternate system will meet the following tiers, for which the City’s use should be identical regardless of which location is processing the City’s work:

Category
Alternate system characteristics
High availability
Continuous operation without interruption or degradation in service.
Standard availability
Available for City of Detroit use within 48 hours with no degradation in service.
Non-Critical Availability
Available for City of Detroit use within 96 hours with no degradation in service.

i. Proposers shall implement crisis management, business continuity and disaster recovery plans, subject to City approval, which the City will not reasonably withhold. These plans shall outline how the Proposer will support the City’s recovery at the alternate site, including backup staff required to implement the plan in an emergency if the Proposer’s primary staff is unavailable. Such plans shall also include a minimum of annual testing in coordination with the City.

ii. Proposers shall specify the System’s proven, maximum tolerable length of time that a computer, system, network, or application can be down after a failure or disaster occurs or its recovery time objective (“RTO”) and the amount of data at risk, as determined by the amount of time between data protection events, and as it reflects the amount of data that potentially could be lost during a disaster recovery point objective, (“RPO”) in case the primary site becomes unavailable. The selection of the RTO and RPO will be agreed upon objectives between the Proposer and the City.

iii. Proposers shall specify whether the System will meet the following availability tiers, which tier, and shall specifically describe how the System meets such tier:

Category
Availability
RTO
Characteristics and RPO
High Availability
99.982%
Intra-day
Typically involves data replication to a hot-site for each transaction or at short intervals, like 15 minutes.
Standard Availability
99.741%
24 to 48 hours
Nightly imaging to cloud / data center. System reestablished at time of disaster from cloud / data center. May lose up to one day of data.
Non-Critical Availability
99.671%
48 to 56 hours
Nightly imaging to cloud / data center. System reestablished at time of disaster from cloud / data center. May lose up to one day of data.

Description

Automated backup* recovery

Data centers

Availability

Business continuity and disaster recovery plans

RTO (Recovery Time Objective) and RPO (Recovery Point Objective)

Availability tiers

2.2. PROPOSED PROJECT APPROACH AND IMPLEMENTATION

METHODOLOGY

A. Although a detailed approach format is included in the following sections, Proposers are expected to propose a ‘industry - best practice’ methodology and solution, and are encouraged to provide innovative ideas to meet the needs of the City in a timely manner. The proposed project plan shall adhere to an industry project delivery methodology. Proposers shall provide a detailed project plan and methodology that clearly demonstrates how their team will initiate, reengineer and automate the processes described in this RFP. Proposals shall include a detailed work breakdown structure that conveys how work will be performed and communicated in an organization of similar size and complexity. The City requires a managed implementation that accomplishes tangible deliverables by a date agreed to within a joint project task list and timeline. The proposed approach and methodology shall include, but should not be limited to, the following sections.

B. Overview of the Implementation Methodology. The Proposer must agree to comply with the City’s project delivery methodology for tracking progress and documents for the duration of the project. In addition, the Proposer will submit weekly status reports to the City. These reports will include:

i.Work accomplished each week from the task list and timeline.
ii.Updated GANTT charts.
iii. Tasks for the next week from the task list and timeline.
iv. List of deliverables for the current week and next week.

v. Status of risks or issues that affect delivery in accordance with the Provider

vi. Task list and timeline.
vii. Invoice requests and payment schedules
viii. Other items relevant to project delivery.

Proposers should provide an implementation methodology and include:

i.Brief description of the project delivery methodology.
ii.Project phases.
iii. Team roles.
iv. Milestones for each phase and deliverables.
v.Quality delivery plans.
vi. Test Policies and Processes.
vii. Change Management Processes.
viii. Training methodology.
ix. Customer care processes and procedures.
x.Requirements traceability procedures.

C. Project Task List and Timeline. Proposers should provide a task list and timeline down to the resource level. This should include:

i. Phases, in accordance with the implementation methodology.

ii. Milestones

iii. Governance

iv. Tasks

v. Assumptions, and

vi. Dependencies with the City delivery team.

The selected Proposer is responsible for accurately estimating effort and presenting a comprehensive plan reflecting careful assessment of the requirements in this RFP document and related attachments.

D. Requirements Validation and System Design. Proposers should provide a detailed description of its approach to validating business and technical requirements, in order to design a system solution and related architecture that adheres to industry best practices and the current the City’s technology environment. The City expects this section to include at a minimum:

i.Business requirements validation checklist.
ii. Technical requirements validation checklist.
iii. System design validation checklist.
iv. The City responsibilities.

E. System Implementation and Configuration. Proposers shall provide a detailed description of the proposed build and release approach. Describe the level of effort and timeline based on the expected configuration and customization work. The City expects this section to include at minimum:

i. Proposed environments.
ii. Software configuration at the desktop.
iii. System architecture.
iv. System design.
v. List of deliverables to the City.
vi. List of deliverables from the City required by the Provider.
Implementation and Configuration
Solution

Environments

Software configuration

System architecture

System design

Deliverables

City of Detroit project deliverables

F. Quality Planning, Assurance and Control. Proposers shall provide a detailed description of the proposed quality methodology adhering to best practices and clearly identifying control tasks and testing. The City expects this section to include at minimum:

i. Provider quality policy.

ii. Provider test policy.

iii. Provider test plans.

iv. Provider testing procedures.

v. Provider test levels and types.

Proposer shall conduct unit and integration testing prior to delivering the System to the City for User Acceptance Testing (UAT). The test cases and test results from unit and integration testing will be provided as a stage gate for the City approval to start UAT. The test cases and test results shall be mapped back directly to requirements identified by the City using a traceability matrix.

Requirement
Test case
Test results
List requirement
List steps for each test case
List results

G. Knowledge Transfer, Training and Transition. The City requires and expects the selected Proposer to provide training for all Board staff, plus certain staff of the Office of the Chief Financial Officer. Therefore, all Proposers are required to describe the recommended knowledge transfer, training and transition processes. Describe the City’s responsibilities. This plan should include at minimum:

i. Knowledge transfer plan: location, format, and total hours, number of employees trained.

ii. End user training plan: location, format, total hours, number of employees trained

iii. Application administrator training plan: location, format, total hours, number of employees trained

iv. Transition plans from old to new system.

v. Support provided during roll-out of the new system: location, format, and total hours, number of employees trained

vi. The City responsibilities during each milestone during knowledge transfer, training, and transition.

Provide the response in this format:

Knowledge Transfer, Training, and Transition
Solution

Knowledge transfer plan

End user training plan

Application administrator training plan

Transition plan from old to new system

Support provided during roll-out

City of Detroit responsibilities

H. Contract Performance Review and Acceptance. Proposers should describe all expected contract performance metrics and steps to transfer all assets to the City. This close out plan should include at a minimum:

i. List of deliverables.

ii. Acceptance criteria for all deliverables: who will be submitting, timeframe for acceptance from submission and any default acceptance timelines.

Performance, Review, and Acceptance
Solution

List of documentation

Acceptance criteria

2.3. CLOUD SERVICE PROVIDER CHECKLIST

Proposers must provide the following information:

Issues
Status/Comment

Adhere to The City Data Security, Data Privacy, Identity Management, Data Deletion, Physical Security, Business Continuity, Backup Encryption, Incident Management and FTI Deletion (if Federal Tax Information is held) Policies

Clear understanding of responsibilities for applications running on cloud infrastructure. City list, Provider list

The provider must show diagram (and possible past examples) of their governance and notification processes for their services, as required by The City

Describe how the provider will guarantee legal and regulatory compliance with government and sectorial (industry specific) laws and regulations

Describe Established Patch Deployment

Describe the mechanism in place to provide reports to the City of Detroit for both normal and exceptional behavior relating to security and privacy operations

Cloud providers security and privacy controls to follow one of the following set of best practices:

o NIST Series o ISO/IEC Series o COBIT o ITIL

Provide SSAE 16 Compliance Documentation

Describe process for Account Management

Describe details of monitoring and how it will be reported

Describe the issuance of encrypted Login Credentials

Describe how a data inventory of City of Detroit Data Assists will be kept.

Will the City of Detroit receive a description of all responsible parties and their roles

Guarantee Encryption of all PII and other data deemed confidential (part of data inventory)

Describe Key Management Program

Describe Malware Program

Process for Separation of data belonging to different consumers in a multi‐tenant environment

Statement guaranteeing Adherence to all Privacy laws governing the physical areas of data storage

Willing to participate in a Risk Assessment and Privacy Impact Assessment covering the storage of PII

Network traffic must be screened and firewall protected Network must have intrusion detection & prevention in place

Network must have detailed logging and documented notification

Process used to separation of network traffic in a shared multi‐tenant provider environment

Dedicate VLANs with dedicated virtual firewall

Describe how the City of Detroit network access separated from provider network access

Are the City of Detroit VMs are on a dedicated hypervisor

Will Providers servers only communicate with The City of Detroit logical disk units

Will online storage and backup media scrubbed when retired or replaced

Service Provider is required that all security terms must also pass down to any peer cloud service providers

Documented exit process and obtain approval by the City of Detroit

OPERATIONAL INFORMATION

Awarded Contractor(s) will work closely with City agency staff.

The Respondent is expected to provide service in accordance with the terms of the executed contract and under the rules, regulations, and supervision of the City.

TECHNICAL INFORMATION

City Data Standards The City is committed to centralizing and warehousing Data for the purpose of improving service delivery and enabling cross departmental analytics. The System must enable Data access, Data interoperability, warehousing of resulting Data, and adherence to City data standards which the City has provided to the Contractor for review.

Specifically, the System requires:

· We require access to all System data for automated data warehousing purposes, provided through at least one of the following machine-readable methods:

· Preferred: Direct database access, or access to a reporting database (ODBC-compatible)

· Alternative: API access providing data in one or more of the following formats: JSON, CSV, or XML

· Full documentation of APIs (including field names and objects) and the database schema used by the application.

· Ability for City to programmatically update data within the System as needed via API

· Any location-based data or platform utilizes the City’s base units geocoder, Base Units Database, and/or address Data standards as applicable.

· The ability for the City to use and govern Data as it deems necessary-- centralizing it, porting it into other systems, and using it for additional and future organizational needs.

· Data collected, transferred and stored meet minimum standards to ensure confidentiality, integrity and availability.

· Data to meet compliance rules / regulations in order to ensure the sensitive digital assets are guarded against loss, theft and misuse. These rules come in a number of forms including applicable industry compliance / standards (i.e. HIPAA, PII, PCI-DSS, NIST, ISO), state or federal-level laws or even supra-national regulations.

· The System must have the capacity to store field-level metadata and display it in the user interface when appropriate

· API is able to provide Data in a JSON format.

· Data system or data exports integrate easily with ESRI products including feature services.

· Systems or platforms that support data exchanges (pushes and pulls) that can happen dynamically.

Section 3. Proposal Evaluation and Selection Process

2.

MINIMUM QUALIFICATIONS

Proposals will only be accepted from those firms demonstrating a minimum of three (3) years of experience providing the services requested in the RFP for projects of similar scope and size.

ADHERENCE TO TERMS OF PROPOSALS

A proposal once accepted by the City of Detroit may become a binding contractual obligation of the Respondent. The failure of a successful Respondent to accept this obligation and to adhere to the terms of the Respondent’s proposal may result in rejection of the proposal and the cancellation of any provisional award to the respondent. Respondents are not permitted to take advantage of any errors or omissions in specifications since full instructions will be given should they be discovered before bid submission date.

QUESTION DEADLINE

All questions regarding the RFP shall be submitted through the Supplier Portal no later than the time and date specified in the solicitation. In the interest of transparency, only written questions will be accepted. Answers to questions will be posted within the Supplier Portal. The City of Detroit does not guarantee a response to questions submitted after the question deadline.

Should a Respondent be in doubt as to the true meaning of any portion of this RFP or find any patent ambiguity, inconsistency, or omission herein, the Respondent must make a written request for an official interpretation or correction in accordance with the instructions for submitting questions as specified in this RFP.

Respondents are advised that no oral interpretation, information or instruction by an officer or employee of the City of Detroit shall be binding upon the City of Detroit.

Respondents requesting changes to the RFPs terms and conditions, specifications, quantities, etc.; or if clarifications are needed, must make the request in writing by the stated bid submission deadline. .

EVALUATION CRITERIA

Phase One Criteria not to exceed 100 points, Technical Proposals will be evaluated before Cost Proposals are reviewed.

Proposal Evaluation Criteria
Possible Points
1. Quality of the product, including its ability to meet the City of Detroit’s functional, technical and security requirements
40
2. Project Approach and Work Plan, including the proposed delivery model, training program, maintenance and support offerings, and ability to meet the City’s objectives described in this RFP.
30
3. The vendor’s experience and staff capabilities including references and experience with similar implementations for comparable agencies
15
4. Pricing
15
Total Points Possible
100

Detroit Equalization Credits according to the following table shall be applied after the technical and price evaluation. (Please see Equalization Credit Statement for more information)

Detroit Equalization Credits – Prime Contractor
Possible Points
Detroit Headquartered Business
5
Detroit Based Business
2
Detroit Resident Business
5
Construction Workforce Investment Business (Construction over $1M)
3
Construction Workforce Development Business
3
Detroit Small Business
1
Detroit Micro Business Concern
2
Joint Venture
2
Mentor Venture
1

EVALUATION PROCEDURE

Following the receipt of proposals, a City designated Evaluation Committee will evaluate each response. All PROPOSALS, which meet the required format of this RFP, will be evaluated. Any proposals determined to be non-responsive to the specifications or other requirements of the RFP, including instructions governing submission and format, will be disqualified unless the City determines, in its sole discretion, that non-compliance is not substantial or that an alternative proposed by the Respondent is acceptable.

The City may also at its discretion request oral presentations, make site visits at Respondent’s facility and may request a demonstration of Respondent’s operations. If scheduled, a final determination will be made after the oral presentations and/or demonstrations are complete.

The City may also at its sole discretion, elect to rank order the qualified proposals, and negotiate with some limited number of the highest scored qualified respondents. A final determination would include the cumulative inputs of this evaluation procedure. All decisions reached by the Evaluation Committee will be by consensus.

Any of the additional data specs and standards described in Section 2.3 that are met will be factored positively into the overall score.

ORAL PRESENTATION/DEMONSTRATION

The City reserves the right, at its own discretion, to request oral presentations regarding proposals submitted in response to the RFP. Failure to make an oral presentation will be grounds for rejection of your proposal. Respondents will be notified by the Office of Contracting and Procurement of the date, time and location for oral presentations.

REJECTIONS, MODIFICATIONS, CANCELLATIONS

The City of Detroit expressly reserves the right to:

1) accept or reject, in whole or in part, any and all proposals received;

2) waive any non-conformity;

3) re-advertise for proposals;

4) withhold the award for any reason the City determines;

5) cancel and/or postpone the request for proposals, in part or in its entirety, and/or,

6) take any other appropriate action that is in the best interest of the City.

This RFP does not commit the City of Detroit to award a contract, to pay any cost incurred in the preparation of a proposal under this request, or to procure or contract for services.

PROTESTS

Protests can be filed with the Office of Procurement. Interested parties aggrieved by a solicitation or the award of any resulting contract may file written notice of protest to the following:

City of Detroit Chief Procurement Officer 2 Woodward Avenue, Suite 1008 Detroit, MI 48226 “Procurement Protest”

At a minimum, such protests shall include:

1) name of protestor.

2) solicitation/contract number and description; and

3) statement of grounds for protest (reference specific text in the solicitation, bid or contract document that is at issue).

An actual or prospective bidder or offeror whose direct economic interest would be affected by the award of a contract or the failure to award a contract has the right to protest any aspect of the solicitation, evaluation, or selection process of a City of Detroit procurement.

A protest by a prospective bidder which challenges the terms of the solicitation itself must be received by the City no later than 4:00 p.m. EST of the business day prior to the date scheduled for the bid closure. Failure to meet this deadline shall result in a protester waiving its ability to challenge the terms of the solicitation.

A protest by a bidder which challenges a contract award must be received no later than 4:00 p.m. EST five (5) business days after the award of a City procurement. Failure to meet this deadline shall result in a protester waiving its ability to challenge the contract award.

All protests must be submitted in writing and received by the required timeframe.

The Chief Procurement Officer (CPO) or as delegated, the Deputy CPO, has the sole authority to respond to, decide and act upon supplier protests.

The decision of the Chief Procurement Officer and/or the Department Director are final and is not subject to appeal.

Section 4. Required Proposal Content and Submission Process 3.

ACCURACY AND COMPLETENESS OF INFORMATION

All information pertaining to the prospective respondent’s approach in meeting the requirements of the RFP shall be organized and presented in the prospective respondent’s proposal. The instructions contained in this RFP must be strictly followed.

Accuracy and completeness are essential. Omissions and ambiguous or equivocal statements will be viewed unfavorably and may be considered in the evaluation. Since all or a portion of the successful proposal may be incorporated into any ensuing contract, all prospective respondents are further cautioned not to make any claims or statements that cannot be subsequently included in a legally binding agreement.

REQUIRED PROPOSAL CONTENT AND FORMAT

To be considered responsive, each proposal must, at a minimum, respond to the following RFP sections in their entirety, responses must be uploaded in the Supplier Portal along with the Affidavit of Disclosure Interests Form and Non- Collusion Affidavit found under requirements section of the of RFP#546288:

Required Response Item

1.
Attachment A – Respondent Questionnaire

Respondent shall provide their Organization Experience, per the requirements provided in Attachment A.

2.
Attachment B – Proposal Introduction and Solution / Approach

Respondent shall provide their Proposal Introduction and Solution / Approach and Capacity/Staffing, per the requirements provided in Attachment B.

3.
Attachment C – Pricing

Respondent shall provide their Pricing proposal, per the requirements provided in Attachment C.

4.
Attachment D1 – Forms, Affidavits and Documents – Bid Requirements

Respondent shall provide their completed Certificate of Authority, Non-Collusion Affidavit, and Affidavit of Disclosure of Interests, along with your organization’s financial statements (Balance Sheets, Income Statements and Statement of Cash Flows) for the previous three (3) years.

Please do not submit your tax returns. in Attachment D1.

5.
Attachment D2 – Conditions of Award

Respondent will be required to provide their completed Forms, Affidavits, Insurance and Documents, if they are selected as the award winner provided in Attachment D.

6.
Attachment E – IT Contract

Respondent shall provide their agreement to the Model Professional Services Contract or note any exceptions provided in Attachment E.

7.
Attachment F – Requirement Matrix
8.
AI Factsheet – Please complete the AI Factsheet using the link below.

https://app.smartsheet.com/b/form/ce9622cae7d0401092739f338b1d6b98

REQUIRED COST PROPOSAL

Respondents are requested to make a firm cost proposal to the City of Detroit, through the completion of Attachment C. If a contract is entered into as a result of this RFP, it will be a contract for fees as related to providing all requested services, with a price not to exceed the total price quoted…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .