Request for Proposals


Sep 9, 2014 - Proposers shall note that only the City's written answers provided after the Conference will be binding. .... Star Lab Information Manag...

9 downloads 4 Views 288KB Size

Request for Proposals _______________________________

City of Minneapolis Law Enforcement Records Management System RFP2014-68 Issued September 9, 2014

Proposals Due by: October 30, 2014 1:00 p.m. (CT)

September 9, 2014 Minneapolis City of Lakes Information Technology Otto Doll Chief Information Officer 310 4th Ave South – Suite 400 Minneapolis MN 55415 Office

612 673-3190

To Whom It May Concern: The City of Minneapolis is soliciting proposals from qualified companies to provide the design, implementation and support of a commercial-off-the-shelf (“COTS”) Law Enforcement Records Management System (“RMS”), along with ancillary software and services. Please consider submitting a proposal. Please review the RFP for details. Specific submission instructions are highlighted under “Proposal Format” of the RFP. Submit the business proposal and price proposal in separate sealed envelopes and send an electronic copy with attachments to: [email protected] All proposals are due in the City of Minneapolis Procurement Office no later than 1:00 p.m. CT, October 30, 2014. An optional pre-proposal conference will be held September 30, 2014, at 1:00 p.m. CT, at 350 South Fifth Street, Room 319, Minneapolis, Minnesota. Thank you for your consideration. Sincerely,

Otto Doll Chief Information Officer

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 3 of 43

TABLE OF CONTENTS

1. Overview .................................................................................................... 5 1.1 1.2 1.3 1.4 1.5 1.6 1.7

Purpose of this Request for Proposals (RFP) ................................................................................. 5 Schedule of Activities ...................................................................................................................... 5 Principal Contact and Information Requests ................................................................................. 5 Pre-Proposal Conference ................................................................................................................ 6 Overview of the Scope of Work ...................................................................................................... 6 Structure of RFP ............................................................................................................................. 6 Addenda to the RFP ........................................................................................................................ 7

2. Background Information ........................................................................... 8 3. As-Is Information Technology Environment ........................................... 10 3.1 3.2 3.3 3.4

Current Records Management Environment ............................................................................... 10 Current Technology Environment ................................................................................................ 11 Police Department Mobile Environment ...................................................................................... 13 GIS Environment .......................................................................................................................... 14

4. Scope of Work ........................................................................................... 15 4.1 4.2

Objectives ...................................................................................................................................... 15 Project Requirements .................................................................................................................... 15

5. Proposal Response .................................................................................. 20 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13

Proposal Format ............................................................................................................................ 20 Proposal Section 2: Proposer Company Overview ...................................................................... 21 Proposal Section 3: Application Software ................................................................................... 22 Proposal Section 4: System Architecture .................................................................................... 28 Proposal Section 5: System Testing and Acceptance .................................................................. 31 Proposal Section 6: Implementation and Project Management .................................................. 31 Proposal Section 7: Documentation ............................................................................................. 33 Proposal Section 8: Training ....................................................................................................... 34 Proposal Section 9: Support, Warranty and Maintenance Provisions ....................................... 34 Proposal Section 10: Contract ..................................................................................................... 36 Proposal Section 11: Proposer References .................................................................................. 36 Proposal Section 12: Proposer Financial Information ................................................................ 37 Cost Proposal ................................................................................................................................. 37

6. Instructions on RFP Process .................................................................... 41 6.1 6.2 6.3 6.4 6.5 6.6 6.7

Proposal Due Date and Location .................................................................................................. 41 Contract ......................................................................................................................................... 41 City Rights/Rejection of Proposals ............................................................................................... 41 Modification or Termination of RFP Process .............................................................................. 42 Proposal Preparation Costs .......................................................................................................... 42 Data Practices ................................................................................................................................ 42 Conflict of Interest/Code of Ethics ............................................................................................... 42

7. Evaluation ............................................................................................... 43 Exhibits (under separate cover): E-1: Integration Requirements E2: Integration Types E-3: Acceptance Test Requirements

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

E-4: System Performance Requirements E-5: General Provisions for Contract Proposal Response Forms (under separate cover): Attachment A: Proposal Response Forms Attachment B: MPD Functional Requirements Attachment C: Cost Proposal Response Forms

September 9, 2014 Page 4 of 43

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 5 of 43

1. Overview 1.1

Purpose of this Request for Proposals (RFP)

The City of Minneapolis, Minnesota (“City”) is soliciting Proposal(s) from firms (“Proposers”) qualified to provide the design, implementation and support of a commercialoff-the-shelf (“COTS”) Law Enforcement Records Management System (“RMS”), along with ancillary software and services needed to meet the City’s requirements contained in this document. The software and services that the Proposer is to provide are referred to herein as “Project.” 1.2

Schedule of Activities

Table 1 shows the preliminary RFP schedule. Dates are subject to change and any changes will be noted in an addendum posted on the Procurement Website at the following URL: http://www.minneapolismn.gov/finance/procurement/rfp. Table 1: Preliminary RFP Schedule

1.3

Event

Date

RFP Available to Proposers Pre-Proposal Conference Questions Due Pre-Proposal Conference Responses to Pre-Proposal Conference Questions Available Proposer Questions Due Responses to Questions Posted Proposals Due Proposal Evaluations Demonstrations and Interviews Final Evaluation and Selection

September 9, 2014 September 23, 2014 by 9:00 AM CT September 30, 2014, City Hall, Room 319, 1-3 CT October 7, 2014 October 10, 2014 by 1:00 PM CT October 20, 2014 October 30, 2014 by 1:00 PM CT Completed on or around January 30, 2015 Completed on or around March 30, 2015 Completed on or around April 15 ,2015

Principal Contact and Information Requests

The Proposer’s primary interface with the City will be the Contract Administrator who will act as the City’s designated representative for the Project. Prospective responders shall direct inquiries/questions in writing only to: Barbara Malinski Contract Administrator City of Minneapolis Information Technology Email: [email protected] All questions are due no later than October 10, 2014 at 1PM Central Time. Responses to the questions will be posted by October 20, 2014 on City’s RFP website at the following URL: http://www.minneapolismn.gov/finance/procurement/rfp.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 6 of 43

The Contract Administrator is the only individual who can be contacted regarding this RFP before proposals are submitted. The Contract Administrator cannot vary the terms of the RFP. 1.4

Pre-Proposal Conference

Attendance at the Pre-Proposal Conference is voluntary for Proposers who plan to submit proposals. All potential Proposers are encouraged to attend this conference in person. The Pre-Proposal Conference will take place on September 30, 2014 from 1:00 PM to 3:00 PM CT at the following location: 350 South 5th Street, Room 319 Minneapolis, Minnesota 55415 Proposers are expected to raise any questions or issues they have concerning the RFP document at this point in the process. In order for questions to be answered at the Conference, they shall be submitted via email to the Contract Administrator by 9:00 AM local time on September 23, 2014. Questions not submitted in advance may be asked at the Conference, but may or may not be answered at the Conference. Proposers shall note that only the City’s written answers provided after the Conference will be binding. These answers shall represent the City’s official position and will supersede any previous oral statements made during the Conference or at any time by City personnel. Responses to questions asked prior to or at the Pre-Proposal Conference will be posted by October 7, 2014 on City’s RFP website at the following URL: http://www.minneapolismn.gov/finance/procurement/rfp. 1.5

Overview of the Scope of Work

The City expects the successful Proposer to provide software and services required to implement a Law Enforcement Records Management System, including ancillary software and integrations, meeting the requirements detailed in this RFP. Detailed expectations are described in Section 4 of this RFP. 1.6

Structure of RFP

The RFP is divided into six (6) sections as follows: 1. 2. 3. 4. 5. 6. 7.

Introduction Background Information As-Is Information Technology Environment Scope of Work Proposal Response Instructions on RFP Process Evaluation

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 7 of 43

The Proposer’s sealed Functional and Cost Proposals must conform to the requirements outlined in Section 5 of this RFP. 1.7

Addenda to the RFP

If any addendum is issued for this RFP, it will be posted on the City of Minneapolis web site at http://www.minneapolismn.gov/finance/procurement/rfp. The City reserves the right to cancel or amend the RFP at any time.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 8 of 43

2. Background Information The City of Minneapolis (City) is the largest city in the state of Minnesota, and is home to approximately 400,000 residents. Minneapolis is also part of a larger metropolitan area including Saint Paul, the state’s capital, with a total metro-area population registering nearly 3.4 million people. The Minneapolis Police Department (“MPD”) is composed of approximately 840 sworn officers and 300 civilian employees who, in total, use 212 mobile computing units and 670 stationary workstations. The MPD is organized into three bureaus: Patrol, Investigations and Professional Standards. The Patrol Bureau provides police services, including 911 response, crime prevention, traffic control and emergency services (including homeland security). It is divided into five precincts, each led by a Precinct Inspector, plus the Special Operations Division. 1 The Investigations Bureau provides investigative services and includes the Violent Crimes Investigations 2 and the Special Crimes Investigations 3 Divisions. Precinct Investigations, which handles property crimes and missing persons, are also part of the Investigations Bureau. The Professional Standards Bureau includes the Office of Professional Standards and the Leadership & Organizational Development Division. The Internal Affairs, Technology and Support Services, 4 and Forensics Divisions comprise the Office of Professional Standards. The Pre- and In-Service Training Units Comprise the Leadership & Organizational Development Division. All bureaus, divisions and units within MPD depend on the accurate gathering, management and analysis of information to achieve the Department’s mission of providing quality and professional service in partnership with communities to advance safety, growth and viability in the City, as well as of committing to the development, accountability and support of its employees. To achieve its mission, the MPD employs various progressive policing initiatives. However, the MPD has experienced frustration that its technology has not kept pace with the initiatives.

1

The Special Operations Division includes the Bomb-Arson Unit, the Canine Unit, Homeland Security, Special Events, Strategic Operations Unit, SWAT, Traffic Enforcement and Accident Investigation and Traffic Control 2 Violent Crimes Investigations Division includes Assault, Weapons, Homicide, and Robbery Units. 3 Special Crimes Investigations Division includes Crimes against Children, Domestic Assault, Juvenile Investigations, Juvenile Outreach & Diversion, Licensing, Financial Crimes, Sex Crimes and Predatory Offender Units. 4 Technology and Support Services Division includes the Business Technology Unit, Intellectual Properties, Property & Evidence, Records Information and Transcription.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 9 of 43

Currently, the MPD uses a custom-built case reporting and management application called the Computer Assisted Police Reporting System, or CAPRS. Built and maintained in-house, CAPRS has been a stable application providing basic report writing and case management functionality for over twenty years. Since developing CAPRS, the information management needs of the Minneapolis Police Department have grown beyond the capabilities afforded by CAPRS. Functional limitations of CAPRS have spurred the desire to replace the application.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 10 of 43

3. As-Is Information Technology Environment 3.1

Current Records Management Environment

The core application MPD uses to manage law enforcement information is CAPRS, which resides on the City network and hardware supported by an outsourced vendor. 5 CAPRS is a report-writing application with limited case management functionality, and is not capable of managing the breadth and depth of information gathered by a police department the size of the MPD. It is a dated application that does not provide functionality commensurate with either advances in public safety information technology or the data management expectations placed on police departments today. As the MPD has adopted progressive policing and management approaches, reliance on CAPRS for data management has led to the development of inefficient, complex and repetitive work processes. Because CAPRS is primarily a report writing system designed to store incident reports, the MPD relies on additional applications, databases, paper forms and external systems to gather, store, and analyze information. The City of Minneapolis Information Technology department and resources within the MPD jointly provide the Department with ongoing system support for CAPRS, as well as for the other applications and systems comprising the records management environment. Table 2. MPD Applications Application

Purpose

CAPRS

Report writing, case management, use of force reporting, track property and evidence Query-only functionality Dispatching and mobile computing (queries, etc.); transfers basic incident data into CAPRS to initiate an incident report Portal for public to report certain types of incidents online Electronic citations Manage Crime Lab activity

CAPRS Web TriTech Computer Aided Dispatch Online Incident Reporting APS Ticket Writer Star Lab Information Management System Digital Image Management System Workforce Director Milestone-X License Plate Recognition System IBase Analyst Notebook

5

Store digital documents, including evidence Track field training evaluations, equipment issued to recruits, academy course scheduling, shift scheduling, time reporting Public safety camera software (in SIC and in squad cars) Run license plates against NCIC; LPRS data is checked against CAPRS for vehicles of interest Crime analysis; CAPRS data exported to a file that is imported by Analyst Notebook

The City of Minneapolis outsources some of its information technology services, including hardware, data and central computing services, network services, help desk services, and security services.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System Application

Purpose

Shot Spotter Olympus Digital Dictation (Winscribe) IBM Intelligent Operating Platform (IOP)

Locate source of shots fired in City Transcription

September 9, 2014 Page 11 of 43

City system for data analysis; MPD using IOP to generate CODEFOR reports

Table 2 lists commercially procured and in-house built applications that MPD uses to gather, store, and analyze information. The applications that the City of Minneapolis built and supports in-house are CAPRS, CAPRS Web, and Workforce Director. MPD procured the rest of the applications from commercial vendors. The MPD also uses paper logs and forms to collect and track information that CAPRS does not support or to comply with other agencies’ paper-driven processes. In addition to applications that were procured commercially or built in-house, the MPD uses a number of Excel and Access databases to store information that is either not captured in CAPRS or not captured in a way that is accessible to the end-user (see Table 3). Table 3. Excel and Access Databases Database

Purpose

Case Assignment Tracking Case Log Investigation Log

Lieutenants track unit assignments on Excel spreadsheets Some Lieutenants track case status on Excel spreadsheets Some Lieutenants and Sergeants track case activity on Excel spreadsheets Access database to track juvenile criminal history and missing juveniles Excel spreadsheet to gather and track crime activity; generate crime statistics including UCR statistics Excel spreadsheet for submitting UCR statistics to Bureau of Criminal Apprehension (BCA) Access database to track assignment of Crime Lab Work Orders Access database to track assignment of Crime Lab Work Orders within the Computer Forensics section of the Crime Lab Computer Forensics tracks case status in an Excel spreadsheet Access database to track criminal history, gang associations, intelligence information Access database to track MPD crash investigations Access database to track sex offenders Track towed and impounded vehicles Mapping incident data Geocodes CAPRS address data into X/Y coordinates

Juvenile Database CODEFOR FBI UCR Worksheet Crime Lab Work Order Log Computer Forensics Database Computer Forensics Suspect Tracking System Crash Database Criminal Sexual Conduct TOPS CrimeMaster Geocoder

3.2

Current Technology Environment

This section describes the current technology environment to assist Proposers with understanding the technology infrastructure in which the new System will operate. The City does not anticipate making substantial architectural changes to its enterprise technology

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 12 of 43

architecture other than the addition of servers, clients or services required to support he proposed System. All servers (physical or virtual) that are required to support the proposed system will be furnished by the City through its managed services provider. In section 5.4 of this RFP, the City requests the specifications for system components to ensure its technology environment can support the proposed System. The City’s managed service provider operates two geographically diverse data centers for hosting the City’s applications, including the majority of the City’s enterprise environment. The two data centers are connected by dedicated geographically diverse network connections providing a minimum of 200Mbs. Layer 2 and Layer 3 networking is supported between the data centers. One data center serves as a primary location and the other serves as a backup and disaster recovery facility. The facilities are configured as “live-live. The City’s enterprise network, including transport, is provided and managed by the managed service provider and provides a minimum of 10Mbs of bandwidth to each police location. The City is in the process of selecting a new managed services provider. The information provided in this document reflects the current environment. The City does not anticipate any major changes to the enterprise architecture in the future. Most of the servers operated on the City’s behalf are virtual servers and exist in a VMware environment. The City prefers virtual servers to physical servers, but is not averse to deploying specific physical servers to meet the requirements of mission critical applications. The virtual environment includes enterprise Storage Area Networks (SANs) and Network Attached Storage (NAS) to address its data storage requirements. The majority of application servers run Microsoft Windows 2008 Server. Microsoft SQL is the preferred database management system. Oracle 10g and 11g is also used to manage certain enterprise data. Table 4 lists major elements of the enterprise environment. Table 4: Curent Server Services Service

Specification

Roadmap

Server OS:

Microsoft Windows 2008 Server 32/64 bit run in a virtualized environment using VMware ESX Microsoft SQL Server 2008 R2 (Preferred RDBMS) Oracle 10g and 11g Storage Area Networks (SAN), Network Attached Storage (NAS) Hosted Storage Microsoft Internet Information Server 7.5 Microsoft Exchange 2003 Hosted Exchange on Office 365 Other Enterprise Application Services ESRI ArcServer 10.0 (GIS) Oracle Content Management 10g

Current

DBMS: Storage: Web Server: Mail Server:

GIS: Document Management:

Current Current Current Current Current Current Current Current

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 13 of 43

The City also uses standard client hardware as shown in Table 5. The current end-user clients use Microsoft Windows 7 Enterprise 32/64 bit operating system. The base image software includes the following applications:  Internet Explorer 9  Microsoft Office 2010 Professional  Adobe Acrobat Reader 10  Adobe Flash Player 11  WinZip 17  Symantec Anti-virus Table 5: City Client Hardware Specifications Standard Device Specifications

Device

Standard Desktop: Dell Optiplex 780

Processor: Core 2 Duo 3.0GHz Operating System: Windows XP Professional SP2 Memory: 2.0GB RAM Monitor: 17" All-In-One Monitor Video: Integrated Video Hard Drive: 160GB Hard Drive Drive: 8X DVD+/- RW Drive with Roxio Creator Dell USB Keyboard and Mouse Processor: Core 2 Duo 3.33GHz Processor Operating System: Windows XP Professional SP2 Memory: 4.0GB RAM Monitor: 24" Wide Screen Monitor Video: 256MB ATI Radeon HD 3450 Graphics Card Hard Drive: 250GB Hard Drive Drive: 16X DVD+/- RW Drive with Roxio Dell USB Keyboard and Mouse Processor: Core 2 Duo 2.26GHz Processor Operation System: Windows XP Professional SP2 Memory: 2.0GB RAM Display: 14.1" Widescreen WXGA LED Display Hard Drive: 80GB Hard Drive Drive: 8X DVD+/- RW Drive with Roxio Processor: Core 2 Duo 2.80GHz Processor Operation System: Windows XP Professional SP2 Memory: 4.0GB RAM Video: Mobile Integrated Video Display: 14.1" Widescreen WXGA LED Display Hard Drive: 160GB Hard Drive Drive: 8X DVD+/- RW Drive with Roxio

Engineering Desktop: Dell Optiplex 780

Standard Laptop: Dell Latitude E6400

Engineering Laptop: Dell Latitude E6400

3.3

Police Department Mobile Environment

The City has installed Data911 M6s and Panasonic Toughbooks CF30/31s in its public safety vehicles. When remote access is required, Verizon 4G LTE USB modems establish network connectivity, and NetMotion Mobility client software provides access to resources on the City network via an encrypted VPN tunnel.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 14 of 43

The City also uses Dell Venue 11 Pro tablets. When users require remote access on these devices, an integrated Verizon 4G LTE broadband device establishes network connectivity and Cisco AnyConnect client software provides access to resources on the City network via an encrypted VPN tunnel. 3.4

GIS Environment

The City’s enterprise GIS data environment is constructed and maintained in ESRI ArcGIS 10.0, which publishes theme-based map services that may be consumed by various applications. The City separately maintains point address and centerline information in an Enterprise Address Management (EAM) system. The EAM system is a SQL database and maintains the primary data elements related to addresses. There are additional systems deployed across the City that may contain secondary information relative to particular addresses.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 15 of 43

4. Scope of Work 4.1

Objectives

The City expects the successful Proposer to provide software, documentation, and services required to implement a Law Enforcement Records Management System, including ancillary software and integrations, meeting the requirements detailed in this RFP. The proposed solution should also include provisions for warranty, support, and product maintenance for at least five years following cutover to the new systems. 4.2

Project Requirements

4.2.1

Software System

The City expects the Proposer to provide all software necessary for a RMS and Report Writing System that meets the specifications in this RFP, and is fully functioning and fully integrated at the time of implementation. Proposers are responsible for providing a System with sufficient functionality and performance capabilities to support all of the City’s needs. All proposed software versions must be available and operational in a live environment on or before the Proposal deadline. The version for each module proposed must be identified in the Proposer’s response. The City will not consider or allow mid-implementation upgrades during this project. While the City does not expect custom integrations to be operational and demonstrable, it does expect that the Proposer will have experience implementing a similar integration. 4.2.2

Integrations

The Proposer will be responsible for providing integrations between the RMS and external systems described in Exhibit 1. 4.2.3

Implementation and Support

The Proposer, with appropriate involvement from City employees, must perform all tasks required to implement the proposed system, including all configuration, testing, training, and construction of integrations. The Proposer must include in its Proposal a comprehensive project plan showing time and resources required to accomplish tasks. 4.2.4

Project Management

The contracting firm will be responsible for applying project management methodologies in the areas of project planning, resource management, project monitoring, production control, configuration management, quality assurance, test planning and execution, training plan, implementation methodology, change management and business process re-engineering, post-implementation support and documentation. The Proposer must present a comprehensive project schedule and statement of work showing time and resources required to accomplish tasks. The Statement of Work must

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 16 of 43

describe the location in which the Proposer intends to perform project tasks. The Proposer must employ professional project management software, such as Microsoft Project. The Proposer shall provide a project manager who, along with the City’s project manager, will be responsible for coordinating the following:  Project plan development and implementation and project status reporting  Any subcontractor work  Requested system changes and modifications to the project plan  All technical, educational, documentation and support services The Proposer’s Project Manager will provide weekly status reports to the City and adhere to the directives of the City Project Manager and/or staff. During the course of the project, until Final System Acceptance, the contracting firm’s project manager will:  Attend regular status meetings  Submit regular status reports, covering such items as: - Progress of work being performed - Milestones attained - Resources expended - Problems encountered - Corrective action taken - Status of issues/problems  Participate in weekly project status conference calls 4.2.5

Change Management

The City believes this Project will alter current business processes. The City expects to work with the Proposer to identify process changes and develop training tools and materials to facilitate the transition to the new systems using new business processes. 4.2.6

Documentation

Documentation must be developed to support the software and the City’s business processes. Any software tools or utilities that are desirable to tune, test, maintain or support the system must be specified in the documentation. Any tailoring or configuring must be documented and delivered to the City. At a minimum, the contracting firm shall provide the City with the following:  User documentation  Data dictionaries  Configuration documentation  Interface documentation  System administration manuals  Application software tutorials  Database setup and maintenance  Entity relationship diagrams  Report creation and maintenance

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

   

September 9, 2014 Page 17 of 43

Ad hoc reporting manuals System documentation, including installation procedures Help desk support call escalation process Disaster recovery manual

All user documentation, including application and integration documentation, help documentation and software tutorials shall be available online and accessible from within the relevant application. Additionally, the successful Proposer is expected to provide sufficient copies of each type of user documentation to each user group. 4.2.7

Training

The City recognizes the involvement, understanding, and commitment of employees is essential to the successful implementation of the proposed System. As such, City employees will assist in all key process design and configuration decisions. It should be noted that training may need to take place in various locations throughout the City and at times that are convenient to personnel working non-regular hours. The Proposer is expected to provide the following types of training programs:  A training program for the City’s core project implementation team that includes the training necessary to understand the overall system architecture, integration configurations, data import/export capabilities and workflow configuration options  A training program for the application administrator that includes the training necessary to configure, tailor, monitor and administer the system’s technical and functional aspects  A training plan and training documentation to support the training of all end-users in the functionality of the various proposed system components  Post-implementation training for ongoing end-user training of the initial system, as well as for future version releases Except for post-implementation training, all training must be completed in a satisfactory manner before the City will give formal Final System Acceptance. Proposers shall make available post-implementation training as requested by the City. All training material shall meet the following requirements:  Training materials shall be provided at least three (3) weeks prior to the start of any training course  Training materials must be for the version of the software that will be deployed. Training materials for previous/older versions of software is unacceptable  Training materials shall be customized by the Proposer to include functionality defined in this RFP and any functionality that is developed during the implementation process  All training material will be provided in electronic format (one version must be a .pdf) for unlimited duplication by the City  Training materials shall reflect sound adult learning principles and all training sessions shall include a demonstration of knowledge and skills transferred to the trainees

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 18 of 43

Additionally, the Proposer shall provide a training system that will allow users to simulate live operations for the System without degrading system performance. 4.2.8

System Testing

The implementation must include adequate provisions for functional, performance and reliability testing. The City requires Proposer involvement in the development and execution of all test plans to assure that the System delivers the expected results. Satisfactory completion of a mutually agreed-upon Acceptance Test for each stage of the implementation is required, as is a Final Acceptance Test in a fully integrated environment (to ensure components work together as intended). The Acceptance Test will include a confirmation of each functional requirement identified in this RFP, in addition to required performance and reliability acceptance procedures that the City may require. The Proposer will be expected to demonstrate all contracted functionality, using the product as configured for the City, during testing. Final System Acceptance will not occur until all testing demonstrates the implemented product works as contracted in the live environment for ninety days. Specific test requirements are described in Exhibit 3. 4.2.9

Warranty

The system solution as proposed in this RFP must include a first year warranty for Proposersupplied hardware and software, including all software updates, enhancements and refinements and integrations, for a minimum of twelve (12) months after the Final System Acceptance date. The City also requires a warranty for implementation services (e.g., work products, developed modifications) for the same period. The warranty shall conform to contractually agreed upon specifications and protect against any defects or damage caused by manufacturers, Proposers, or proposed Subcontractors, in the System’s equipment or software. Additionally, the Proposer will warrant its responses to the functional requirements included in Attachment B to this RFP and any other element of this RFP, and will agree to attach its RFP response to any contract reached with the City. Final System Acceptance shall be determined by the City according to an agreed upon testing plan. All repairs and expenses to cover repairs made under warranty, including parts, software, labor travel expenses, meals, lodging and any other costs shall be borne by the Proposer. All repairs and expenses to cover repairs that are due to the Proposer’s inability to perform based upon warranty guidelines shall be borne by the Proposer. 4.2.10 Support and Maintenance The City expects that a five (5) year maintenance and support agreement will be offered. The support agreement must describe priority levels for system errors and include a guaranteed response time for each priority level. 4.2.11 Account Manager The selected Proposer will provide the City with an Account Manager who will be the single point of contact throughout the Proposer’s relationship with the City. The Account Manager, and any Proposer personnel as determined by the City, may be subject to

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 19 of 43

successfully completing background checks before being allowed access to the City’s systems and information. The City reserves the right to request and have the Account Manager replaced if the City determines a change would best result in successful completion of the project.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 20 of 43

5. Proposal Response This section describes the specific format that Proposers must use to respond to the RFP. Failure to follow the format requested in this section, or failure to use the provided forms, could result in a proposal being rejected. There are two parts to the proposal, the Functional Proposal and the Cost Proposal. Instructions for each are detailed below. Submit one (1) original and twelve (12) hardcopies of the Functional Proposal. In addition, submit two (2) electronic copies of the Functional Proposal on a compact disc, flash drive or other portable electronic storage device. The original proposals must include original signatures, in ink, by authorized personnel, on all documents that require an authorized signature. Submit one (1) original hardcopy and two (2) electronic copies of the Cost Proposal on a compact disc, flash drive or other portable electronic storage device. Seal the Cost Proposal in a separate envelope, distinctly mark it as the Cost Proposal, and include it in the same package as the Functional Proposal. Failure to submit a sealed Cost Proposal may result in disqualification of the entire proposal. 5.1

Proposal Format

The City expects the Functional Proposal to be divided into twelve (12) clearly marked and identified sections. Several parts of the RFP require the use of Response Forms, which can be found in Attachments A, B and C. The Proposer must use the Response Forms when indicated and include in the appropriate section. Unless otherwise instructed, do not retype or alter these forms. The proposal must follow the format prescribed below and address all requirements identified in this RFP. The objective of the prescribed format is to facilitate the review of all proposals. Failure to complete and furnish all information requested in the specified form and format may result in the rejection of the proposal. The Cost Proposal must be submitted in a separate sealed envelope in the same package as the Functional Proposal. Instructions for the Cost Proposal Format are in Section 5.13. Table 6 describes each section. Proposers should label each section as described in the table and provide a table of contents that includes page number references. The paragraphs following the table explain the detail requested for each section, and are referenced accordingly in the table. Paragraph numbering within proposals should correspond to question numbers in the detailed RFP. The City realizes that proposals may contain the same information in different sections. When information is requested multiple times, please copy the information into each pertinent section so that the Evaluation Committee can evaluate each section individually.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 21 of 43

In addition to the sections described below, Proposers should submit, on official company letterhead, a Cover Letter that contains the following information:  Statement of Interest: This statement shall indicate the firm’s general interest and capability to perform the project. It shall also include a brief summary of any information that might be especially important to the City.  Statement of Proposal Validity: The proposal must be valid for at least two hundred forty (240) days from the RFP due date. During this time, the proposal is a firm offer and the City may enter into contract negotiations with the successful Proposer.  Contact Person: The Proposer shall include the name, title, address, telephone number, fax number and email of the key contact person for any questions regarding the proposal.  Signature of Authorized Representative: An authorized representative of the firm must sign the proposal and the name and title of the representative must be typed below the signature. The proposals containing the original signatures shall be clearly marked “Original.” Table 6: Functional Proposal Format Overview

5.2

Proposal Section

Description

RFP Reference

1

Letter of Transmittal/Executive Summary/Table of Contents

N/A

2 3 4 5 6 7 8 9 10 11 12

Proposer Company Overview Application Software System Architecture System Testing and Acceptance Implementation and Project Management Documentation Training Support, Warranty and Maintenance Contract Provisions Proposer References Proposer Financial Information

5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12

13

Cost Proposal (submitted in a sealed envelope per instructions in Section 5.13)

Proposal Section 2: Proposer Company Overview 1. Complete and include the Proposing Firm Information Form (Attachment A – Form A). 2. If the Proposer is a corporation, formal proof of the authority of the officer signing the Proposal to bind the corporation should be submitted with the proposal. A copy of the corporate resolution or minutes can be adequate proof; a simple letter is not sufficient. 3. Provide background information about the Proposer’s company history and experience in the market for public safety information systems. 4. Provide an overview of the Proposer’s strategic plan for the proposed products.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

5.3

September 9, 2014 Page 22 of 43

Proposal Section 3: Application Software

Clearly label and identify each sub-section for easy reference. 5.3.1

Software License Agreement 1. Include copies of the proposed standard software licensing agreements. 2. What type of licensing agreement is proposed (e.g., site license, concurrent license, named license, etc.)? 3. How many licenses are proposed? 4. List any restrictions on licensing.

5.3.2

Major System Components 1. Complete and include the Application Software Module Form (Attachment A – Form B). Identify all Application modules included in the RMS application, as well as the module in which desired functionality is located. All modules listed must be included in the Cost Proposal. 2. Does the Proposer provide a site license option(s) for the system proposed? If no, please identify those components for which site licensing is not an option and indicate why a site license would not be the most cost effective option.

5.3.3

Functional Requirements 1. Use the Excel Workbook provided in Attachment B to indicate how Proposer can satisfy the City’s functional requirements. The Proposer should complete the spreadsheet, but should not modify or alter the workbook format in any manner except to provide responses where requested. Modification or alteration of the workbook format may result in rejection of the proposal. The Proposer should include the workbook in electronic format on a compact disk, flash drive or other portable electronic storage device in this section. a. The Proposer should leave the workbook as an Excel file and not convert to .pdf. If the Proposer wants to provide a .pdf version of the Excel file, it should do so in a file separate from the main functional proposal document. b. All detailed requirements in Attachment B are numbered in the left-hand column. These identification numbers should not be changed or omitted in the proposal. c. Detailed response instructions are included on the first worksheet of the workbook. Failure to follow the instructions may result in rejection of the proposal. Proposers are asked to indicate their ability to comply with the requirement using the codes described in the following paragraphs:  “S” indicates that the requirement will be met by proposed existing software that is installed and operational at other sites and can be demonstrated to the City. The cost of requirements receiving this response code is included in the cost of the standard application software. If the software required to meet this requirement is under development or in a test or beta phase, do not answer with an “S” response. Answer with

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

 





September 9, 2014 Page 23 of 43

an “N” response and indicate the development status in the “Comments” column. “N” indicates that the Proposer cannot comply with the requirement. If a Proposer is answering “N” because it cannot meet the requirement in its entirety, please indicate why in the "Comments" column. “A” indicates that the Proposer cannot meet the requirement exactly the way the requirement is stated, but the Proposer can meet the requirement without modification to the standard application software and without additional cost to the City. The cost of a requirement receiving this Response Code is included in the cost of the Proposer’s standard application software pricing. For example, the requirement can be met via functionality in another module, through standard features in the operating system, or through an easy work-around. Responses in this column must be accompanied by an explanation in the “Comments” column. Failure to provide an explanation will result in the response being counted as an “N” response. “M” indicates that the Proposer can meet the requirement by modifications to existing standard software. Responses receiving this Response Code may have an additional cost associated with them. Additional costs for modifications must be listed in the Cost Proposal and must reference the specific functional requirement associated with the cost. Failure to provide a cost for modifications will result in the response being counted as an “N” response. “T” indicates that the Proposer can meet the requirement through use of third party software. All "T" responses must have supporting explanations in the “Comments” column, including the name of the third party provider. All third party software necessary to meet the listed requirements must also be listed in the Cost Proposal. Failure to do so will result in a re-coding of the response as an “N.”

Note that a blank response will indicate to the City that the Proposer cannot meet the requirement. Blank responses will be counted as “N” responses. 5.3.4

Integrations 1. Complete and include the Integration Identification Form (Attachment A – Form C) for each of the required integrations. If an Integration Identification Form is not provided for an expected integration, the City will assume that it is not included in the proposed solution. For each integration:  Describe Proposer’s specific experience with the desired integration, including number of sites installed, date initially installed, operational status, direction of data exchange, and the development language or tool  Described the proposed approach to developing the integration  Exhibit 2 lists various types of integrations; in the Integration Identification Form, when describing the proposed approach, indicate the

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

2.

3.

4. 5. 5.3.5

September 9, 2014 Page 24 of 43

integration type per the descriptions in Exhibit 2 (Proposer can refer to the number corresponding to the integration type in Exhibit 2)  List any assumptions or constraints (e.g., communications protocol) to successfully completing the integration  Describe the services being provided and any assumptions regarding working with the external organization to develop the integration  If the Proposer has experience with a similar integration to a system being requested by the City, the Proposer should indicate as such The City may choose to implement integrations directly with your system. For example, integrations with the Bureau of Criminal Apprehension (“BCA”) and Hennepin County include data mapping to specific XML schema and transport to the agency via an enterprise service bus or web services. The City may manage the transport component with the system provider managing the data mapping component. As such: a. What is the Proposer’s strategy for publishing data that has been mapped to the specific XML schema? b. What is the Proposer’s approach to simplifying and supporting the development, installation, and maintenance of integrations? c. Provide an explanation of the tools utilized to build the integration. d. Is a repository/warehouse offered to support a data dump from the proposed applications that would allow third party applications to query the database? If not, what mechanism is proposed for third party application queries? e. What training is provided for customers to develop unique third party integrations? Describe documentation provided for system integration processes, training programs and related support options. Does the System incorporate open data sharing models and standards such as the Global Justice XML Data Model (GJXDM) or the National Information Exchange Model (NIEM)? Does the solution support standardized integration of functional and data access methods with other systems? If yes, explain. Does the solution provide a web services-based integration layer (SOAP-based or REST-based)?

System Administration 1. Provide a description of the system administration module and the functionality it provides. 2. What periodic System management functions should be performed to maintain System performance? 3. How much time is needed to administer the system once it has reached steadystate given the size of the Minneapolis Police Department plus the external systems user base. For data entry users there are approximately 1,200 active users from Minneapolis Police Department, University of Minnesota Police Department and Minneapolis Park Board Police. In addition to these users there are approximately 1,400 web only users from external agencies.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 25 of 43

4. Describe the level of expertise required to perform system configuration activities. 5. Use the Post-Implementation System Staffing Form (Attachment A – Form D) to identify the resources required to provide ongoing support for the system after implementation. Include a description of the City personnel required to manage the proposed system post-implementation. 6. Describe how your solution’s integration, business rules and database can be custom configured to meet the needs of users across multiple jurisdictions and departments. 5.3.6

Security Features 1. The City of Minneapolis is connected to a government network through the State of Minnesota. The government network allows firewall-restricted access to computer systems hosted at other government agencies. Please provide information about how your system would both enable and provide security for other government agencies to access the system through this network. 2. Describe to what level of depth (field, screen, module, etc.) security and permissions may be controlled within application modules. 3. Describe how the System’s security provisions limit access to individual functions or data. Be sure to address the Proposer’s role-based security provisioning. 4. Explain the capabilities provided to: a. Securely add, remove and modify users b. Help establish, remove and recover authentication credentials 5. Describe what security functions are provided by the application software versus those that are provided by system software or the operating system. 6. Describe the auditing capabilities of the System (include screenshots). 7. Describe how the proposed System manages user passwords and unsuccessful log-on attempts. a. Can the City establish the number of attempts allowed? b. What is the reporting or alerting mechanism used to communicate unauthorized access? 8. Describe the features of your system (e.g., account password, group, or role management) that can be managed through Active Directory security measures. 9. With what third-party security tools (e.g., log management, security monitoring) is the Proposer’s system able to interface? 10. Describe how the Proposer’s solution complies with CJIS security requirements. 11. The System must have the capability to terminate temporary or emergency useraccess automatically after a defined period. The City must be able to customize the defined period. Describe how the Proposer’s solution accomplishes these requirements. 12. Does the solution have the capability to lock out a user after a set number of unsuccessful login attempts? If yes, describe how configuration can be customized for City use of the System. 13. Describe how remote access is managed and secured:

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 26 of 43

a. For City personnel b. For system provider’s personnel (note that the solution must not require a permanent network connection) 14. The City has a requirement for the ability to highlight, flag, or otherwise alert users with the appropriate security access that a record or data element is confidential (#2508 in Attachment B – Functional Requirements). a. Can the Proposer’s solution meet this requirement? b. If the Proposer’s solution can meet this requirement, does it support multiple classification levels? 5.3.7

Data Export 1. The City of Minneapolis utilizes several Enterprise systems that require data from multiple City of Minneapolis business systems, including the MPD’s RMS. It is required that the proposed system support the export of data to these numerous systems. The information should be delivered or accessible to these external systems in as near real-time as possible. a. Describe the preferred and any alternate methods for the proposed system to export data to external systems. b. Does the proposed system allow for direct access to the RMS data? Describe all methods that are supported for direct access to the RMS data store c. Does the proposed system provide prebuilt ETL Packages for use with the systems data store? d. Does the proposed system support a process in which RMS data is published to a messaging system? Describe which message systems the proposed system supports. e. Describe how the proposed system can support the City’s desire to comply with open data initiatives given that police data needs to be sanitized for public consumption prior to release to the public.

5.3.8

Geofile and Address Validation 1. Describe the proposed system’s geospatial internal environment and construct. 2. Does the proposed system support multiple map services? 3. Does the proposed system have an independent geospatial environment or can it use the City’s GIS geospatial data directly? 4. The City’s Enterprise Master Addressing System can support multiple integration options. Please describe the Proposer’s preferred and supported mechanisms. 5. Does the proposed system have the ability to associate and incorporate the City’s unique alphanumeric Enterprise Address Identifier with all stored addresses? 6. Can the RMS validate addresses against the City’s Enterprise Master Addressing System? 7. Is the RMS geofile able to import address data from jurisdictions outside of the City of Minneapolis (e.g., Hennepin County)? 8. What utilities are provided to manage the geospatial environment?

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 27 of 43

9. Describe the system administration tasks required to create, update, and maintain the geospatial environment. 10. What is the process for bidirectional synchronization of the system’s geospatial data with the City’s GIS database? 11. Describe any potential integration your system can provide with external GIS systems or services. Describe if these integrations are standard, configurable or customized. 5.3.9

Reporting 1. Describe the reporting environment. 2. Describe the mechanism by which the City can transfer RMS data into a data repository that the City can use for reporting purposes. The City should be able to update the reporting database as a user-defined interval without the system provider’s involvement. 3. List and describe the real-time and historical reports that are included with the inbound, outbound, and transactional aspects of the solution. 4. Describe the delivery options available for the reports. 5. How will the proposed System allow administrators to schedule automatic delivery of reports? 6. What is the process to add and store additional reports that are defined by City users? 7. Describe any limitations to the quantity of reports that can be run. For example, is there an upper limit for storing queries after which performance is affected? 8. If reports are managed in a hosted environment, are there time and capacity limits? 9. Does the proposed system provide a pre-built integration into Cognos? 10. Describe the technical access control mechanism provided by the system to authenticate unique users and to authorize individual users to reporting resources.

5.3.10 Public Online Reporting The City of Minneapolis currently uses a custom-built application that allows for both public online and 311 operator reporting of certain types of incidents. The public can access the online reporting application on the City’s website. The City’s 311 operators are able to take reports over the telephone and use a web-based data entry wizard to collect relevant information for generating a police report. The 311 operators are trained to collect information that the public cannot report using the online reporting tool (e.g., suspect information). The City of Minneapolis would like to understand how the Proposer’s solution could meet this need via a web-based system, incorporating the following requirements:  No manual data entry on the part of the MPD is required to either enter or route the incident  The City of Minneapolis can determine the types of incidents that can be reported by the public and by 311operators (they types of incidents that each can report may be different)

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

     5.4

September 9, 2014 Page 28 of 43

The 311 operators can enter additional information about incidents (information that the public cannot enter) The system provides a case number to the reporting individual or to the 311 operator to provide to the reporting individual over the telephone The system follows the same routing rules as police-generated incidents (e.g. route to appropriate personnel or units depending on the crime type) The system allows for these incidents to follow the same incident approval process rules as police-generated incidents (e.g. route to appropriate personnel or units depending on the crime type) The system provides an electronic police report to the reporting person (email preferred) upon completion of the report

Proposal Section 4: System Architecture

Proposers should clearly label and identify each sub-section for easy reference. 5.4.1

System Diagram 1. Systems should be architected to operate with one primary technical function per server. Provide a diagram of the proposed System architecture. The diagram should include an overall representation of the servers, network, peripherals, workstations and integration points, as well as a representation of the System environments (e.g., Production, Disaster Recovery, Training, and Quality Assurance). The architecture must take into account the following requirements: a. System should be architected to operate with one primary technical function per server (e.g., application server separate from database server) b. System should operate in virtual and/or shared server environments (e.g., shared application server environment, shared database server environment) c. System must be a premise-hosted solution; the City is not interested in a cloud-based solution d. System should not require local disk storage to operate successfully e. Server software architecture should not include foreground applications that require interaction with the console or elevated privileges to run 2. How will the server configuration provide the redundancy necessary to guarantee the performance criteria stated in Exhibit 4? Do you recommend any alternative system architecture configurations? If yes, please describe. 3. Describe the hardware and software platforms on which the Proposer’s solution will run.

5.4.2

Proposed Server and Workstation Configuration 1. Complete and include the Server Configuration Form (Attachment A – Form E).  All servers required to implement the proposed solution must be included in the Server Configuration Form. 2. Complete and include the Recommended Workstation Configuration Form (Attachment A – Form F).

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System





5.4.3

September 9, 2014 Page 29 of 43

All Windows based client software applications must operate on the City of Minneapolis standard end-user hardware devices consisting of Intel platform devices using Microsoft Windows (see description of current technology environment in Table 5, section 3.2 of this RFP) The City will use the information in this section to ensure that its desktop and mobile computers comply with the specifications required for optimal system performance.

Performance and Availability 1. Describe the System’s capabilities for: a. System performance monitoring b. Load balancing c. Error reporting d. Describe any impact to systems (e.g., interference to normal operations, system shutdown) that will occur during server upgrades and/or expansions. e. Describe any impact to systems that will occur during software upgrades or updates. f. All database and system jobs must have minimum impact on the production environment. How does the system architecture insure the System meets this requirement? g. Identify all anticipated performance bottlenecks and propose solutions to those bottlenecks. h. The City expects all System applications to operate concurrently at designed capacity. How will Proposer ensure operation of all system components without any System degradation?  Note: Stating simply that the system is designed to handle concurrent operations without an explanation of how it is designed to do so will be considered nonresponsive. i. The City expects the RMS application to be available 99.95 percent of the time (assuming the server environment is operating as expected). Describe how the Proposer will guarantee this level of System availability both initially and during the life of any license and maintenance contract. j. What are the Proposer’s remedies if the contracted level of application availability is not met?

5.4.4

Disaster Recovery 1. Describe how the System transitions to a disaster recovery environment. 2. Describe how the System supports a hot, warm or cold disaster recovery environment. 3. Do operations automatically failover to the backup environment in the event of a failure in the production environment? 4. Describe the progression toward full restore of services in the event of a disaster. 5. The City expects that all functionality will be available, and all service levels restored to normal operating conditions, once the system has been restored for

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

6. 7. 8. 9. 5.4.5

September 9, 2014 Page 30 of 43

City use. How much time is required until operations commence in the backup environment when operations in the production environment fail? What steps, degree of user intervention, and time are required to return operations to the primary environment (in the event of failover to the backup environment)? Describe the proposed method of restoring data files. Describe any limited functionality with which the system will operate during the restoration process. Describe any security protections that will not be operable during the restoration period.

Network Compatibility 1. Describe how the mobile field reporting application works in an environment of intermittent mobile computer connectivity. 2. What is the slowest wired network connection speed that will still ensure the Proposer’s system can meet the System Performance requirements in Exhibit 4? 3. What is the slowest wireless network connection speed that will still ensure the Proposer’s system can meet the System Performance requirements in Exhibit 4? 4. How do you handle variances in available bandwidth (variations in wireless connectivity strength)?

5.4.6

Operating System 1. Provide the name and version number of the proposed Operating System (for both servers and clients). 2. The City will purchase licenses for the Operating System (server and client). What licenses does the City need to purchase for the proposed solution? 3. If the Proposer’s recommended Operating System incorporates any proprietary or non-standard components, provide justification for the component (servers and clients).

5.4.7

System Software Applications and Utilities 1. Complete and include the System Software Form (Attachment A – Form G), identifying the name, company, and release level of the following applications and any other programs that the Proposer recommends above and beyond the main RMS Application:  Database Management System  Languages/Development Tools  Utility/Report Writer Programs  Administrative Tools  GIS and Map Maintenance Tools  Mobile and Remote Maintenance Tools  Other

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 31 of 43

Note: All software must be accounted for within this section. If Proposer is assuming that the City already owns required software, those assumptions must be stated. 2. Provide a list of supported browsers, along with the version supported. 3. Are there any extensions required within the browser software to operate the Proposer’s solution? 5.5

Proposal Section 5: System Testing and Acceptance 1. The City requires a review process to verify the Proposer’s responses to all of the functional requirements and to confirm that the proposed software meets defined user requirements prior to commencing software implementation. Describe your approach to confirming requirements, determining modifications necessary to meet the City’s specifications and then addressing those modifications. 2. Exhibit 3 outlines Acceptance Test Requirements. Does the Proposer agree to the Acceptance test requirements? Clarify any exceptions. The Proposer must submit an alternative to any exceptions taken. 3. Provide a comprehensive Acceptance Test Plan that incorporates these requirements. The City will consider as non-responsive any Proposer that does not provide an Acceptance Test Plan, or at a minimum, a sample of the plan that illustrates the process and parameters underlying its test approach, including, but not limited to:  How each of the functional specifications in the RFP will be tracked, documented and tested prior to System Application Component Acceptance and Final Acceptance.  How integrations will be tested  How System reliability will be tested  How System performance and speed will be tested  How integration of System with existing public safety systems will be verified  Remediation procedures for failed tests and found errors  The delineation of testing tasks between the City and Proposer personnel

5.6

Proposal Section 6: Implementation and Project Management

Proposers must clearly label and identify each sub-section for easy reference. 5.6.1

Project Management 1. Describe the Proposer’s approach to managing an implementation of this magnitude. Address at a minimum the following components of project management: a. Project communications b. Schedule management c. Issue management d. Scope management e. Risk management f. Quality assurance

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 32 of 43

2. Describe the Proposer’s recommended quality control procedures for solution implementation. 3. Include in this section a Statement of Work that breaks down the System implementation by tasks and delineates Proposer and the City’s responsibilities within each task. Tasks should include configuration, testing and integration development and deployment. For each task, identify the City resources required for successful task completion, expected contributions, and expected time commitment. Address project management services including creating and maintaining a detailed deployment plan, along with a detailed task list. 4. Include in this section a realistic implementation project schedule that starts at contract signing. The schedule should describe tasks to be performed by the City as well as by the Proposer. 5. The implementation of a COTS RMS system is likely to alter the City’s business practices. Describe the process by which the Proposer will work with the City to identify and review current business processes and provide recommendations to improve overall officer efficiency by leveraging the functionality of the System. Further, what specific documentation will be provided to the City both during and after implementation regarding future business processes? 5.6.2

Project Team 1. Identify the primary individuals who will be involved in the project. Note that these individuals must be available for oral interviews. 2. Describe the expected composition of the City’s Project Team. 3. Identify a project manager who will be the primary point of contact for the duration of the project through formal project acceptance. Note that this individual must be available for oral interviews. 4. Include in this section resumes for the proposed personnel. 5. Any personnel from the successful Proposer working directly on the project, or any third party who may be contracted to work on the project by the successful proposer will be subject to a background investigation and fingerprint check before being allowed to work with the City on the proposed system. Is there any reason that Proposer would object to this condition of the Contract? 6. Describe the process and actions available to the City, should the assigned project manager not meet the performance expectations of the City. 7. Use the Implementation Staffing Form (Attachment A – Form H) to provide a description of the City agency personnel required to implement the proposed system.

5.6.3

Implementation Process 1. Describe the Proposer’s approach for rolling out a project of the magnitude required for the City of Minneapolis. Address the following project components, specifically as they will apply to the City given the size, composition, structure and resources of the Police Department: a. Testing

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 33 of 43

b. Training c. Cutover to live operations d. Post-cutover support 2. What does the Proposer recommend for the composition of the City’s core project team? What are the roles of each member during various project tasks (e.g., application configuration, server configuration, testing, training, and cutover)? 5.6.4

Legacy Data Access

The City would like access to its legacy data, either by having that data available in the new system or available for querying purposes. It will convert property and evidence data from CAPRS into the new system. The City is open to alternative proposals, and intends to rely on the Proposer’s experience with accessing legacy data from its current system to identify the most effective manner in which to access the data. 1. Provide a proposal for accessing legacy data. The proposal should describe: a. Multiple approaches and the advantages and disadvantages of each approach b. Recommended approach c. Proposer’s experience with the recommended approach 2. Include costs for each approach as options in Table 8 of the Cost Proposal. 5.7

Proposal Section 7: Documentation 1. Will the Proposer agree to supply comprehensive hard and soft copies of all types of documentation listed in the “Documentation” section of the Scope of Services in this RFP? 2. Include in this section a sample of the Proposer’s documentation for system installation procedures. 3. Identify any requested documentation that the Proposer does not provide, as well as the reason it is not provided. 4. Is the System documentation consistent with instructions supplied by the online help for the proposed Software Applications? Describe any inconsistencies. 5. Will all documentation be tailored to include Minneapolis-specific configuration, requirements or functionality developed during the implementation process? 6. Will the Proposer provide authority to copy documentation for internal use as necessary? State any exceptions. 7. Will the Proposer be willing to provide a complete set of user documentation for the finalist evaluation phase? 8. Is documentation available with upgrades? If so, does the Proposer provide an entirely new set of documentation, or does the documentation reflect only the changes? 9. Does the Proposer provide FAQs, cheat sheets or similar documentation? a. Is this documentation available on hardcopy or available electronically within the application? b. If it is available within the application electronically, can those forms be modified by the City?

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

5.8

September 9, 2014 Page 34 of 43

Proposal Section 8: Training

It is anticipated that the Proposer and the City will work together to develop a final training plan that will include training formats, locations, timeframes, and curriculum. The City requires a preliminary Training Plan with the Proposal to assess the Proposer’s approach to training. 1. Provide a training plan that addresses the training requirements outlined in the “Training” section of the Scope of Services in this RFP. Include the key elements of the Proposer’s training approach, including the approach to providing System, Software Application and System Administration training. 2. Use the Training Hours Form (Attachment A – Form I) to provide a description of classes, including:  Types of training classes that will be provided and the expected participants (e.g., roles, functional areas)  Number of participants for each class  Prerequisites for all participants  Length of each class in hours  Location (e.g., on-site/off-site) and method of delivery (e.g., classroom, online)  Total number of trainer hours proposed 3. Does the Proposer provide refresher training? If yes, describe what refresher training is available. Include the cost of refresher training in the Cost Proposal as an option. 4. Does the Proposer provide any computer-based training options (either on-line or via a CD) to bring new employees up to speed on the System? 5. What level of flexibility will the City have in determining how to best use the proposed training hours? 5.9

Proposal Section 9: Support, Warranty and Maintenance Provisions

5.9.1

Customer Support 1. Describe the City’s options for contacting the system provider with end-user or technical issues. Address at a minimum the following options:  Telephone support  Web-based support  On-site support 2. Does the Proposer support User Groups? If so, describe the user group process as it pertains to future product enhancements. 3. Describe the Proposer’s support procedure for different types of errors. 4. Provide a description of how the Proposer: prioritizes issues, determines response time, logs support calls, tracks incidents, monitors the escalation of problems, diagnoses and corrects problems, and resolves problems. 5. The City does not expect to pay for service it is not receiving and will expect reduction in future maintenance fees for errors not resolved in a timely manner. Explain the compensation the Proposer will offer for:

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

   5.9.2

September 9, 2014 Page 35 of 43

Errors not remedied within an agreed upon number of hours within a given quarter Errors not remedied within an agreed upon number of hours of a given year Errors not remedied with the next release fix

Warranty 1. Provide in this section a copy of the Proposer’s standard warranty. 2. Will the proposed System include a minimum first year warranty commencing at final System Acceptance? If not, explain. 3. Does the Proposer warrant that the implemented System will conform with its responses to the functional requirements in Attachment B and the performance specifications in Exhibit 4? a. If not, explain. b. List any conditions of warranty. 4. Will the Proposer agree to cover expenses to repairs made under warranty, including parts, software, labor, travel expenses, meals, lodging and any other costs associated with the repair? 5. Will the Proposer cover repair costs for work it is unable to perform based upon warranty guidelines? 6. Do any Customer Support provisions differ during the Warranty Period (as compared to during Maintenance Periods)?

5.9.3

Software Application Maintenance 1. Include in this section of copy of the Proposer’s standard maintenance agreement. 2. Provide an overview of the Proposer’s current roadmap for releasing new functionality (e.g., what the City can expect in future releases and when the City can expect the releases) 3. What services and products are included the Proposer’s maintenance program. Address specifically: a. Customer support provisions b. Upgrades, updates, enhancements and fixes c. Training d. Documentation e. Professional services 4. What services and products are specifically excluded from the Proposer’s maintenance program? 5. Will the Proposer provide labor, equipment and other materials necessary to maintain the Application and System Applications in good operating condition and in conformance with the Performance Requirements? Identify and explain in detail any exceptions. 6. What is the philosophy and process for providing software patches for corrections of software errors?

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 36 of 43

7. How often does the Proposer provide software updates and enhancements? Describe the release cycle for both major and minor releases. 8. What is the process for delivery and installation of fixes, upgrades, and new releases? Mention the time required, outages required, and specific steps for different types of updates. a. How are changes to software tested and documented? b. Will integrations be upgraded along with the standard applications? If so, how will Proposer ensure that integrations are not broken or compromised? c. If customizations are proposed, will they be upgraded along with the standard applications? If so, how will the Proposer ensure that customizations are not lost or compromised? d. How will software on mobile computers be upgraded? Will updates be pushed to the devices or will it require manual intervention? 9. How long does it take to implement a major upgrade? 10. In reference to system software, standard desktop applications and third party public safety software products, how does the Proposer handle maintenance and upgrades to third party products that are part of the proposed System? 11. Is maintenance for third party products that are part of the proposed System included in the Proposer’s maintenance agreement? 12. Are updates provided to meet changes in federal, state or county requirements (e.g. a change to data schema or reporting requirements)? a. Is there an additional charge for these updates? If yes, what is a typical range for such additional charges? b. If there are additional charges, how are they determined? 13. How does Proposer manage changes in federal, state or county schema when the changes affect integrations with federal, state or county data? 14. How long is maintenance continued for older releases? 15. If the City decides to upgrade System hardware, will Proposer charge a fee to install the software on the new hardware? 16. What training assistance for updates is provided? 5.10

Proposal Section 10: Contract

The City expects to include the provisions in Exhibit 5 in the Implementation and Software License Agreements. 1. Does the Proposer agree to the Terms and Conditions in Exhibit 5? If no, identify which provisions to which the Proposer is taking exception, and describe the exception taken. Include suggested wording for any exception taken. 5.11

Proposal Section 11: Proposer References 1. Complete and include the Reference Form (Attachment A – Form J). Each Proposer must provide at least ten references. At a minimum, the references should meet the following criteria:  At least two (2) references should be for systems installed within the last three (3) years

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

  

September 9, 2014 Page 37 of 43

At least two (2) references should be for systems installed more than three (3) years ago At least two (2) references should include clients with populations greater than 250,000 At least two (2) references should include installations for an RMS integrated with a CAD provided by a different vendor

If the Proposer has worked in the State of Minnesota, such references should be included. 5.12

Proposal Section 12: Proposer Financial Information 1. Complete and include the Proposer Financial Background Form (Attachment A – Form K). 2. Provide a copy of the company’s latest audited financial statements.

5.13

Cost Proposal

Submit one (1) original hardcopy and two (2) electronic copies of the Cost Proposal on a compact disc, flash drive or other portable electronic storage device. Seal the Cost Proposal in a separate envelope, distinctly mark it as the Cost Proposal, and include it in the same package as the Functional Proposal. Failure to submit a sealed Cost Proposal may result in disqualification of the entire proposal. The Cost Proposal forms are included in Attachment C, which is an Excel workbook. Proposers must submit Attachment C as an Excel workbook. Please note that:  Proposals must be for a fixed price solution.  All costs for every component referred to in the proposal, including options, must be included in the cost proposal.  Costs must be unbundled and separately listed. Proposals that do not detail specific costs on the provided forms will be considered non-responsive.  The Proposer shall bear the onus of any errors made in pricing the services (e.g., omitting a component of the services).  Should the Proposer have failed to either include in the price, or to deliver to the City, any component necessary to perform the functionality or provide services as proposed in the RFP, the Proposer shall be required to provide same at the Proposer’s own expense. The cost proposal consists of eleven (11) tables. The following sections provide instructions for completing each table. In addition to the Cost Proposal, Proposers may include pricing sheets in their own format. 5.13.1 Cost Proposal Tables 1 – 5: Application Software Costs Use Tables 1 – 5 to list the costs for all proposed software components comprising the RMS and Report Writing System as follows:  Table 1: RMS Application Costs

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

   

September 9, 2014 Page 38 of 43

Table 2: Report Writing Application Costs Table 3: Interface Costs Table 4: Other Module/Component Costs Table 5: Application Software Modification Costs

Proposers should take note of the following requirements:  All costs required to provide the software functionality requested in this RFP must be included in these tables. The Proposer will be responsible for any costs not accounted for in these tables.  The Proposer must provide a cost for any proposed software modification required to meet functional requirements. If a cost is not provided, it will be assumed that there is not a cost for the modification. If ultimately there will be a cost, the Proposer will be responsible for that cost.  Include the unit and total package costs, and the annual maintenance expense for the System.  The “Annual Maintenance Cost” should represent the annual maintenance cost for Year 1.  For purposes of the Cost Proposal, Year 1 begins upon Final System Acceptance, which will be at the conclusion of a post-cutover test period. All costs prior to Final System Acceptance must be included in the One-Time Costs.  All modules included on the Application Software Module Form must be included on the Application Software Cost Form.  All integrations included on the Integration Identification Form must be included on the Application Software Cost Form. Note that the costs associated with integrations include all costs associated with the development, testing and deployment of the defined integration.  Do not include integration costs on the Application Software Modification Cost Table (Table 5). List all standard and custom integration costs on the Integration Cost Table (Table 3).  A cost must be provided for each of the required integrations. If the price of an integration is included in the base application cost, list the price as $0. If the Proposer is not providing an integration, list the price as "not included."  The City will provide hardware and system software; Proposer need not include these costs in the Proposal.  Other Module/Component Costs include costs for any software necessary to meet the requirements that is not listed as an RMS or Report Writing cost. If a Proposer indicates that a functional requirement is met by use of third party software, the third party software must be listed in this table. A cost must be listed for the third party software; otherwise, the City will assume the functionality is provided at no additional cost and the Proposer will bear the cost of providing the functionality should it be selected as a System Provider.  All responses of "M" in the functional requirements document must have a corresponding cost in Table 5. If a cost is not provided in Table 5, the City will assume the functionality is provided at no additional cost and the Proposer will bear the cost of providing the functionality should it be selected as a System Provider.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 39 of 43

5.13.2 Cost Proposal Table 6: Total Application Software Totals should automatically populate Table 6 upon completion of Tables 1, 2, 3, 4, and 5. Proposers are responsible for verifying the accuracy of the totals in Table 6. 5.13.3 Cost Proposal Table 7: Implementation Costs Use Table 7 to describe and list all costs that would be associated with implementation of the proposed System, including, but not limited to the following:  Installation of Software  Installation of Third Party products  System Integration with existing public safety systems  Project Management  Training  Travel  Any other costs (describe) Proposers can add rows as necessary to include all costs. 5.13.4 Cost Proposal Table 8: Optional Costs Use Table 8 to list all optional cost items that could be associated with implementation of the System. Any optional costs to which the Proposer refers in the Functional Proposal must be identified on the Optional Cost Form in order for that option to be considered in the evaluation process. 5.13.5 Cost Proposal Table 9: Total One Time Costs Totals should automatically populate Table 9 upon completion of Tables 6, 7, and 8. Proposers are responsible for verifying the accuracy of the totals in Table 9. 5.13.6 Cost Proposal Table 10: Recurring Costs Use Table 10 to present a summary of all recurring costs for the proposed System for the first five (5) years of ownership after implementation. Year 1 begins upon Final System Acceptance, which will occur after a post-implementation test period. All costs incurred prior to Final System Acceptance should be included in the appropriate table for one-time costs. Any subtotals carried forward to this page should agree with the corresponding detail pages. 5.13.7 Cost Proposal Table 11: Hourly Rates Use Table 11 to list hourly rates that are proposed as part of this Contract. These rates should be guaranteed for at least five (5) years of ownership after implementation. Present rates for at least each of the following resources:  Analyst  Programmer  Hardware/Server Configuration

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

    

September 9, 2014 Page 40 of 43

Project Manager Trainer Data Conversion Database Administrator Other (describe)

5.13.8 Cost Proposal Table 12: Payment Schedule Use Table 12 to propose a payment schedule. The City does not agree to accept this payment schedule; it is for evaluation purposes only. It is the City’s expectation that all payments will be tied to concrete milestones with objective completion criteria, for example software configuration, completion of training, acceptance testing. The City reserves the right to hold back 25% of all payments until Final System Acceptance.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 41 of 43

6. Instructions on RFP Process 6.1

Proposal Due Date and Location

The Proposer shall submit one (1) original and twelve (12) hardcopies and two (2) electronic copies of its Functional Proposal and one (1) original hardcopy and two (2) electronic copies of its Cost Proposal to the City of Minneapolis Procurement Office. Packages must be labeled: City of Minneapolis - Procurement Request for Proposals for: Minneapolis Police Department Records Management System 330 2nd Avenue South, Suite 552 Minneapolis, MN 55401 The submittal shall be made at or before 1:00 PM CT on October 30, 2014. NOTE: Late Proposals may not be accepted. 6.2

Contract

The contracting parties will be the City of Minneapolis and the Proposer selected to provide the services as described herein. The selected proposal, along with the RFP and any counter proposal will be incorporated into a formal agreement after negotiations. The City reserves the right to negotiate all elements of the requirements, submittals, Proposals, terms and conditions and/or scope of services as part of the contract negotiation process prior to any formal authorization of the contract by the City. The City reserves the right to make no award under this solicitation, and the right to cancel this request or any portion thereof. This is a right of the City and not a prerogative of the Proposer. If at any time the contract negotiations are judged ineffective, the City may cease all activities with a Proposer and begin contract negotiations and preparation activities with a different Proposer, continuing the process until a Contract is executed. As a part of this process, the City may obtain “best and final offers” from all Proposers judged to be finalists. The City reserves the right to cease all contract negotiation activities at any time and reject all Proposals if such action is determined by the City to be in its best interest. 6.3

City Rights/Rejection of Proposals

The City reserves the right to reject any or all proposals or parts of proposals, to accept part or all of proposals on the basis of considerations other than lowest cost, and to create a project of lesser or greater expense and reimbursement than described in the Request for Proposal, or the respondent's reply based on the component prices submitted.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 42 of 43

This RFP is a general request for a proposal as opposed to a specific request for a specific assignment. 6.4

Modification or Termination of RFP Process

The City is under no obligation to proceed with this project and may cancel this Request for Proposal at any time without the substitution of another, if such cancellation is deemed to be in the best interest of the City. 6.5

Proposal Preparation Costs

There is no express or implied obligation for the City of Minneapolis to reimburse responding firms for any expenses incurred in preparing Proposals in response to this Request for Proposal. The City of Minneapolis will not reimburse responding firms for these expenses, nor will City pay any subsequent costs associated with the provision of any additional information or presentation or procurement of a contract for these services. 6.6

Data Practices

All Proposals shall be treated as non-public information until the Proposals are opened for review by the City. At that time, the names of the responders become public data. All other data is private or non-public until the City has completed negotiating the Contract with the selected Proposer(s). At that time, the Proposals and their contents become public data under the provisions of the Minnesota Government Data Practices Act, Minnesota Statutes, Chapter 13 and as such are open for public review. 6.7

Conflict of Interest/Code of Ethics

Pursuant to Section 15.250 of the City’s Code of Ordinances, both the City and the Proposer are required to comply with the City’s Code of Ethics. Chapter 15 of the Code of Ordinances requires City officials and the Proposer to avoid any situation that may give rise to a “conflict of interest.” A “conflict of interest” will arise if Proposer represents any other party or other client whose interests are adverse to the interests of the City. As it applies to the Proposer, the City’s Code of Ethics will also apply to the Proposer in its role as an “interested person” since Proposer has a direct financial interest in this Agreement. The City’s Code of Ethics prevents “interested persons” from giving certain gifts to employees and elected officials.

City of Minneapolis, Minnesota RFP for Law Enforcement Records Management System

September 9, 2014 Page 43 of 43

7. Evaluation Each Proposal received will first be reviewed to determine responsiveness and completeness of the Proposal. If the Proposal is determined by the City to be responsive and complete, the City will proceed to evaluate the Proposal on its merits. The Supplier should note that while the total cost to the City of the proposed solution to deliver Services is a material factor, it will not be the sole factor in the City's evaluation; other aspects of Supplier's Proposal (e.g., solution, performance, terms and conditions, references, etc.) will also weigh in the City's evaluation. Ultimately, the City expects to select the Supplier(s) whose Proposal(s) the City determines, in its sole discretion, is(are) overall in the City’s best interests.