CITY OF PHOENIX Procurement Division … OF PHOENIX Procurement Division REQUEST FOR PROPOSAL RFP 16-011 (AW) PHOENIX FIRE DEPARTMENT COMPUTER AIDED DISPATCH (CAD) & RECORDS MANAGEMENT

CITY OF PHOENIX Procurement Division

REQUEST FOR PROPOSAL

RFP 16-011 (AW)

PHOENIX FIRE DEPARTMENT COMPUTER AIDED DISPATCH (CAD) & RECORDS MANAGEMENT SYSEM (RMS)

MODERNIZATION PROJECT

PROCUREMENT OFFICER Andria Williams

Finance Supervisor 602-262-7789

[email protected]

TABLE OF CONTENTS


251 W. Washington Street 8th Floor

Phoenix, AZ 85003 Phone: (602) 262-7181

Solicitation No. RFP 16-011 (AW)

Page 2 of 137

Solicitation Instructions Section I Solicitation Response Checklist Introduction City’s Vendor Self-Registration and Notification Schedule of Events Obtaining a Copy of the Solicitation and Addenda Preparation of Proposal Addenda Licenses Certification Submission of Proposal Withdrawal of Offer Proposal Results Award of Contract City’s Right to Disqualify for Conflict of Interest Offeror Compliance with Health, Environmental and Safety Requirements Submittal Format Solicitation Transparency Policy Protest and Appeals Process

Standard Terms and Conditions Section II Definition of Key Words Used in the Solicitation Contract Interpretation Contract Administration and Operation Costs and Payments Contract Changes Risk of Loss and Liability Warranties City’s Contractual Rights Contract Termination

Special Terms and Conditions Section III Contract Type, Price Term of Contract Insurance Requirements Suspension of Contract Performance Interference of Contract Performance Contractor’s Performance Emergency Service Subcontractors Contract and Subcontractor Worker Background Screening Storage Space Onsite Acceptance Testing Dispute Resolution Disclosure of Litigation or Financial Condition Final Inspection and Approval Incorporation by Reference Specifications

TABLE OF CONTENTS



Phoenix, AZ 85003 Phone: (602) 262-7181


Page 3 of 137

Scope of Work Section IV

Submittals Section V Attachments & Exhibits Section VI

SECTION I - SOLICITATION INSTRUCTIONS



Phoenix, AZ 85003 Phone: (602) 262-7181


Page 4 of 137

Please read this before continuing on to the solicitation document.

SOLICITATION RESPONSE CHECK LIST

Check off each of the following as the necessary action is completed.

□ 1. All forms have been signed. All of Section V, Submittals, is included.

□ 2. The prices offered have been reviewed.

□ 3. The price extensions and totals have been checked.

□ 4. Any required drawings or descriptive literature have been included.

□ 5. The delivery information block has been completed.

□ 6. If required, the amount of the bid surety has been checked and the surety has been included.

□ 7. Review the insurance requirements, if any, to assure you are in compliance.

□ 8. The specified number of copies of your offer has been included.

□ 9. Any addenda have been signed and are included.

□ 10. The mailing envelope has been addressed to: City of Phoenix, Procurement, 8th Floor, 251 W. Washington Street, Phoenix, AZ 85003.

The mailing envelope clearly shows: Your company name and address, the solicitation number, and the proposal opening date.

□ 11. The response will be mailed in time to be received no later than 2:00 p.m. local Arizona time.

□ 12. Request for Consideration of Alternate Terms.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 5 of 137

1. INTRODUCTION

The City of Phoenix invites sealed proposals for Phoenix Fire Department Computer Aided Dispatch (CAD) & Records Management System (RMS) Modernization Project, to

provide software, implementation services and support as part of the CAD/RMS Modernization Project in accordance with the specifications and provisions contained herein.

The PFD dispatch system supports 26 jurisdictions, 2 private ambulance companies, and approximately 3,400 responders. The target date for PFD and all member agencies to be using the new CAD and RMS software is December, 2018.

This solicitation is available through Arizona Relay Service 7-1-1. Please call TTY 800-367-8939 for assistance.

2. CITY’S VENDOR SELF-REGISTRATION AND NOTIFICATION Vendors must be registered in the City’s e-Procurement Self-Registration System at https://www.phoenix.gov/financesite/Pages/EProc-help.aspx in order to receive solicitation notices, respond to solicitations and access procurement information. The City may, at its sole discretion, reject any offer from an Offeror who has not registered in the City’s e-Procurement system.

3. SCHEDULE OF EVENTS

Proposal Issue Date November 12, 2015

Mandatory Pre-Proposal Conference December 2, 2015, 9:00 A.M. Local Arizona Time

Final Written Inquiries Due Date December 16, 2015, 10:00 A.M., Local Arizona Time

Proposal Due Date January 22, 2015, 2:00 P.M. Local Arizona Time

Interviews (If required) February 29, 2015 through March 4, 2015

Proposal Submittal Location: Calvin Goode Building City of Phoenix Finance Department Procurement Division 251 W. Washington Street, 8th Floor Phoenix, AZ 85003

Mandatory Pre-Proposal Conference in person, or by teleconference. Submit written questions by November 20, 2015, 10:00 A.M., Local Arizona Time. Verbal responses to submitted questions will be provided during the Pre-Proposal Conference. Notes or minutes of the meeting will not be distributed. Pre-Proposal Location: Fire Administration Building Phoenix Fire Department 150 S. 12th Street

Phoenix, AZ 85003

The conference bridge information for the MANDATORY Pre-Proposal Conference: Toll Free: 877-848-7030 Access Code: 1462363 WEB Conference: https://connect4.uc.att.com/service16/meet/?ExEventID=81462363

https://www.phoenix.gov/financesite/Pages/EProc-help.aspx




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 6 of 137

Finalist Interviews: Calvin Goode Building City of Phoenix Information Technology Services Department 251 W. Washington Street Phoenix, AZ 85003

City reserves the right to change dates and/or locations as necessary.

4. OBTAINING A COPY OF THE SOLICITATION AND ADDENDA Interested Offerors may download the complete solicitation and addenda from

https://www.phoenix.gov/solicitations. Internet access is available at all public libraries. Any interested Offerors without Internet access may obtain this solicitation by calling (602) 262-7181 or picking up a copy during regular business hours at the City of Phoenix Finance Department, Procurement Division, 251 W. Washington Street, 8th Floor, Phoenix, AZ.

5. PREPARATION OF PROPOSAL 5.1 All forms provided in Section V, Submittal, must be completed and submitted with your

proposal. It is permissible to copy Section V forms if necessary. Erasures, interlineations, or other modifications of your proposal shall be initialed in original ink by the authorized person signing the proposal. No proposal shall be altered, amended or withdrawn after the specified proposal due time and date. The City is not responsible for Offeror’s errors or omissions. All time periods stated as a number of days shall be calendar days.

Any deviation from this solicitation shall be clearly stated and identified in Tab 9 titled Alternative Terms/Exceptions and must be included with your submittal. Submission of additional terms, conditions or agreements with your proposal may result in rejection of your proposal.

5.2 It is the responsibility of all Offeror’s to examine the entire solicitation and seek clarification

of any requirement that may not be clear and to check all responses for accuracy before submitting a proposal. Negligence in preparing a proposal confers no right of withdrawal after due date and time. Offerors are strongly encouraged to:

A. Consider applicable laws and/or economic conditions that may affect cost,

progress, performance, or furnishing of the products or services. B. Study and carefully correlate Offeror’s knowledge and observations with the RFP

document and other related data. C. Promptly notify the City of all conflicts, errors, ambiguities, or discrepancies which

an Offeror has discovered in or between the RFP document and such other related documents.

5.3 The City does not reimburse the cost of developing, presenting or providing any response

to this solicitation. Offers submitted for consideration should be prepared simply and economically, providing adequate information in a straightforward and concise manner. The Offeror is responsible for all costs incurred in responding to this solicitation. All materials and documents submitted in response to this solicitation become the property of the City and will not be returned.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 7 of 137

5.4 Offeror’s are reminded that the specifications stated in the solicitation are the minimum

level required and that proposals submitted must be for products or services that meet or exceed the minimum level of all features specifically listed in this solicitation. Proposals offering less than the minimums specified are not responsive and should not be submitted.

5.5 If provisions of the detailed specifications preclude an otherwise qualified Offeror from

submitting a proposal, a written request for modification must be received by the Deputy Finance Director at least seven (7) calendar days prior to the proposal opening. The City may issue an addendum to this solicitation of any approved specification changes.

5.6 Prices offered shall not include applicable state and local taxes. The City will pay all

applicable taxes. For the purposes of determining the lowest cost, the City will not take tax into consideration. Taxes must be listed as a separate item on all invoices.

6. ADDENDA

The City of Phoenix shall not be responsible for any oral instructions made by any employees or officers of the City of Phoenix in regard to the bidding instructions, plans, drawings, specifications, or contract documents. Any changes to the plans, drawings and specifications will be in the form of an addendum, which will be available at https://www.phoenix.gov/solicitations or by calling (602) 262-7181. The Offeror shall acknowledge receipt of any/all addendum by signing and returning the document with the proposal submittal.

7. LICENSES If required by law for the operation of the business or work related to this Proposal, Offeror must possess all valid certifications and/or licenses as required by federal, state and local laws at the time of submittal.

8. CERTIFICATION By signature in the offer section of the Offer and Acceptance of Offer pages, Offeror certifies:

The submission of the offer did not involve collusion or other anti-competitive practices.

The Offeror shall not discriminate against any employee, or applicant for employment in violation of federal or state Law.

The Offeror has not given, offered to give, nor intends to give at any time hereafter, any economic opportunity, future employment, gift, loan, gratuity, special discount, trip, favor, or service to a public servant in connection with the submitted offer.

9. SUBMISSION OF PROPOSAL Proposals must be in the actual possession of the Procurement Division on or prior to the exact

time and date indicated in the Schedule of Events. Late proposals shall not be considered. The prevailing clock shall be the City Finance Department, Procurement Division’s clock. Proposals must be submitted in a sealed envelope and the following information should be noted on the outside of the envelope: Offeror’s Name Offeror’s Address (as shown on the Certification Page) RFP Number RFP Title




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 8 of 137

All proposals must be completed in ink or typewritten. Include the number of copies indicated in the Submittal section.

10. WITHDRAWAL OF OFFER

At any time prior to the solicitation due date and time, an Offeror (or designated representative) may withdraw the proposal by submitting a request in writing and signed by a duly authorized representative. Facsimiles, telegraphic or mailgram withdrawals shall not be considered.

11. PROPOSAL RESULTS Proposals will be opened on the proposal due date, time and location indicated in the Schedule of Events at which time the name of each Offeror shall be read. Proposals and other information received in response to the Request for Proposal shall be shown only to authorized City personnel having a legitimate interest in them or persons assisting the City in the evaluation. Proposals are not available for public inspection until after award recommendation has been posted on the City’s website.

A preliminary tabulation will be posted on the Procurement Division’s website, https://www.phoenix.gov/finance/business-opportunities/bid-awards-and-recommendations within five (5) calendar days of the proposal opening. The information on the preliminary tabulation will be posted as it was read during the proposal opening. The City makes no guarantee as to the accuracy of any information on the preliminary tabulation. Once the City has evaluated the proposals an award recommendation will be posted on the website. No further notification will be provided to unsuccessful Offerors.

12. AWARD OF CONTRACT Award(s) will be made to the overall highest scoring Offeror(s). If two or more finalists are tied, the finalist with the lowest cost will be awarded the contract. Notwithstanding any other provision of this solicitation, the City reserves the right to: (1) waive any immaterial defect or informality; or (2) reject any or all proposals or portions thereof; or (3) reissue a solicitation.

A response to a solicitation is an offer to contract with the City based upon the terms, conditions, and specifications contained in the City’s solicitation. Proposals do not become contracts until they are executed by the Deputy Finance Director. A contract has its inception in the award, eliminating a formal signing of a separate contract. For that reason, all of the terms, conditions and specifications of the procurement contract are contained in the solicitation, unless any of the terms, conditions, or specifications are modified by an addendum or contract amendment.

13. CITY’S RIGHT TO DISQUALIFY FOR CONFLICT OF INTEREST The City reserves the right to disqualify any Offeror on the basis of any real or apparent conflict of interest that is disclosed by the proposal submitted or any other data available to the City. This disqualification is at the sole discretion of the City. Any Offeror submitting a proposal herein waives any right to object now or at any future time, before any body or agency, including but not limited to, the City Council of the City of Phoenix or any court.

14. OFFEROR’S COMPLIANCE WITH HEALTH, ENVIRONMENTAL AND SAFETY REQUIREMENTS

The Offeror’s products, services and facilities shall be in full compliance with all applicable federal, state and local health, environmental and safety laws, regulations, standards, codes and ordinances, regardless of whether or not they are referred to by the City.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 9 of 137

At the request of the City representatives, the Offeror shall provide the City:

Environmental, safety and health regulatory compliance documents (written safety programs, training and records, permits, etc.) applicable to services requested.

A list of all Federal, State and local citations or notice of violations (including but not limited to EPA, OSHA, Maricopa County) issued against the Offeror or their subcontractors including dates, disposition and resolutions.

The City further reserves the right to make unannounced inspections of the Offeror’s facilities (during normal business hours).

15. PREPARATION OF SOLICITATION All printed, excel spreadsheet, electronic media (CD/DVD, Jump Drive or etc.) responses in the Submittal Section must be completed and accurate with your response. It is permissible to copy sections if necessary. Erasures, interlineations, or other modifications of your solicitation shall be noted by the authorized person signing the solicitation. No submittals shall be altered, amended or withdrawn after the specified solicitation due time and date. The City is not responsible for Offeror’s errors or omissions. All time periods stated as a number of days shall be calendar days. Any deviation from this solicitation shall be clearly stated and identified in Tab 9 titled Alternative Terms/Exceptions and must be included with your submittal. Solicitations submitted with additional/alternate terms, conditions or agreements may be considered as non-responsive and rejected. Due to the complexity of the offers and to aid in the evaluation, the offers should contain all required information in tabbed sections as indicated in the electronic spreadsheet. Omissions or alternations of the electronic spreadsheet will be sufficient grounds for the City to consider your offer to be non-compliant. The submittal shall include ample written evidence, in the form of technical specification, cut/tear sheets, brochures, pictures, drawing, etc., to demonstrate that all specifications herein have been met and/or exceeded Offeror shall organize and submit their response (printed and electronic) in the following order: Tab 1 Phoenix Fire CAD & RMS Functional Requirements, Subsections 3.1, 3.2 Tab 2 Phoenix Fire System Architecture and Technical Design, Subsection 4 Tab 3 Implementation & Support, Subsections 5, 6, 7, 8, 9 Tab 4 Qualifications, Experience and References Tab 5 Pricing Tab 6 References Tab 7 Submittal of Offer, Including Source Code Escrow Agreement, Software License

Agreement, Support Maintenance Agreement and Software Warranty Agreement Tab 8 Addenda Tab 9 Alternative Terms/Exceptions Tab 10 Evaluation literature, illustrations, specification sheets, blueprints and photos




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 10 of 137

16. EVALUATION CRITERIA

In accordance with Phoenix City Code, Chapter 43 - Procurement, Competitive Sealed Proposal awards shall be made to the responsible Offeror(s) whose proposal(s) are determined to be the most highly rated taking into consideration the following evaluation criteria. Only the evaluation criteria set forth in this request for proposals will be used in the evaluation process. The evaluation factors are listed in the relative order of importance. Further, each proposal has two parts: (1) a Technical Component and (2) a Price (cost or pricing) Component. Each proposal will be evaluated on its technical and cost merits by a panel of

reviewers. The proposal evaluation factors are as follows:

Technical Component A. Functional and Technical Requirements 400 points (40%) B. Implementation and Support 250 points (25%) C. Qualifications, Experience, and References 150 points (15%) D. Compliance with Terms and Conditions 100 points (10%) Price Component E. Pricing 100 points (10%)

TOTAL 1,000 points

The narrative portion and materials presented in response to this RFP shall be submitted with the Price Component as set forth in Paragraph 16.5 below and follow the same order as requested and must contain, at a minimum, the following:

16.1 FUNCTIONAL AND TECHNICAL REQUIREMENTS (400 POINTS) Phoenix Fire CAD and RMS Functional Requirements. The Offeror must provide fully completed responses to ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET. Please refer to section IV subsection 2.2.1 for instructions. Offeror must complete responses to Section IV (Scope of Work), Subsection 3 (Functional and Technical Requirements). Please refer to section IV subsection 2.2.2 for instructions. 16.1.1. Phoenix Fire System Architecture and Technical Design. The Offeror must provide fully completed responses to Section IV (Scope of Work), Subsection 4 (System Architecture and Technical Design), incorporating responses as directed in each subsection. Please refer to section IV subsection 2.2.3 for instructions.

16.2 IMPLEMENTATION AND SUPPORT (250 POINTS)

16.2.1 Technical Interfaces. The Offeror must provide fully completed responses to Section IV (Scope of Work), Subsection 5 (Product Interfaces). Please refer to section IV subsection 2.2.5 for instructions. The response must include interface construction and unit testing for each of the required interfaces defined in the Technical Interfaces Listing (Attachment C). Please refer to section IV subsection 2.2.4 for instructions. 16.2.2 Data Conversion. The Offeror must provide fully completed responses to Section IV (Scope of Work), Subsection 6 (Data Conversion). Please refer to section IV subsection 2.2.5 for instructions.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 11 of 137

16.2.3 Implementation. The Offeror must provide fully completed responses to Section IV (Scope of Work), Subsection 7 (Implementation). Please refer to section IV subsection 2.2.5 for instructions. 16.2.4 Support. The Offeror must provide fully completed responses to Section IV (Scope of Work), Subsection 8 (Support). Please refer to section IV subsection 2.2.5 for instructions.

16.3 QUALIFICATIONS, EXPERIENCE, AND REFERENCES (150 POINTS) 16.3.1 References and Qualifications. The Offeror must provide fully completed responses to Section IV (Scope of Work), Subsection 9 (Qualifications and Experience), including references to be listed in Tab 6 - References. Please refer to section IV subsection 2.2.6 for instructions.

16.4 COMPLIANCE WITH TERMS AND CONDITIONS (100 POINTS) Terms that will be a part of the contract for this project are included in Section II (Standard Terms and Conditions) and Section III (Special Terms and Conditions) of this Solicitation/Request for Proposal. Offerors are responsible for reviewing all terms and conditions. To be responsive, Offerors must be prepared to enter into a contract with the City containing the Standard and Special Terms and Conditions. If the Offeror is unable to agree to any specific provision(s) within the Standard and/or Special Terms and Conditions, the Offeror must provide the following in Section V (Submittal): (a) identification of the specific provision(s) or language to which the Offeror objects; (b) an explanation for the Offeror’s objection; (c) alternative language or modifications the Offeror is requesting. Under no circumstances shall an Offeror submit its own standard contract as a response to this Solicitation. At the sole discretion of the City, an Offeror’s refusal to accept the Standard and Special Terms and Conditions may be grounds for disqualification from further consideration for contract award. The City requires Offerors to submit the following Offeror-specific documents in response to Section V (Submittal):

Source Code Escrow Agreement Software License Agreement Support and Maintenance Agreement Software Warranty Agreement

The provision of these documents should not be construed as the City’s acceptance of the submitted content. The City will evaluate the required documents in context with the City’s Standard and Special Terms and Conditions. The City will evaluate the Offeror’s acceptance of the Standard and Special Terms and Conditions. At its sole discretion, the City will deduct points (up to a maximum of 100) from proposals based on the nature and quantity of an Offeror’s submitted objections. Nothing herein prohibits the City from introducing or modifying contract terms and conditions.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 12 of 137

16.5 PRICING (100 POINTS)

Offerors shall submit prices in accordance with Section V (Submittal) which represents the City’s official request for price quotation and must be completed by the Offeror. The pricing stated must be a firm fixed price. Unless otherwise and specifically provided, the price is all-inclusive and must include all necessary costs including, but not limited to, materials, labor, travel, copying costs, incidentals, equipment, space, profit, insurance, and any other items necessary to effectively conduct and complete the Scope of Work. Pricing submitted must conform to the format defined in Section V (Submittal), Attachment B – Cost Worksheet. Prices must be provided as requested. Bids submitted without the requested price information will be considered as non-responsive and rejected.

17. OFFEROR INQUIRIES All questions that arise relating to this solicitation shall be directed in writing to: Andria Williams Email address: [email protected] To be considered, written inquiries shall be received at the above email address by December 16, 2015, 10:00 A.M. local Arizona time. Inquiries received will then be answered in an addendum and published on the Procurement Website. No informal contact initiated by Offerors on the proposed service will be allowed with members of City’s staff from date of distribution of this solicitation until after the closing date and time for the submission of proposals. All questions concerning or issues related to this solicitation shall be presented in writing.

18. SUBMITTAL FORMAT The written solicitation shall be signed by an individual authorized to bind the Offeror. The solicitation shall provide the name, title, address and telephone number of individuals with authority to contractually bind the company and who may be contacted during the period of the contract. All fees quoted shall be firm and fixed for the full contract period. Each submittal shall be: A. Typewritten for ease of evaluation. B. Submitted in an 8-1/2 x 11 inch loose leaf three-ring binder. C. Set forth in the same sequence as this RFP (i.e., Offerors should respond to this RFP in sequence and each response should reference the applicable section of this RFP). D. Signed by an authorized representative of the Offeror. E. Submitted with the name(s), title, address, and telephone number of the individuals(s) authorized to negotiate a contract with the City.

19. AWARD QUALIFICATION The Offeror hereby agrees that to qualify for award, all of its employees assigned to the City of Phoenix sites to satisfy obligations under this Contract shall be used exclusively for that purpose during the hours when they are working in areas covered by this Contract and shall perform no work at other City of Phoenix facilities. In the event that other services, in addition to or separate from the services specified herein, may be deemed necessary by the Deputy Finance Director or his authorized representative, the Offeror may be requested to perform the additional or special service.

mailto:[email protected]




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 13 of 137

20. SOLICITATION TRANSPARENCY POLICY Commencing on the date and time a solicitation is published, potential or actual Offerors or respondents (including their representatives) shall only discuss matters associated with the solicitation with the Mayor, any members of City Council, the City Manager, any Deputy City Manager, or any department director directly associated with the solicitation (including in each case their assigned staff, except for the designated procurement officer) at a public meeting, posted under Arizona Statutes, until the resulting contract(s) are awarded to all offers or responses are rejected and the solicitation is cancelled without any announcement by the Procurement Officer of the City’s intent to reissue the same or similar solicitation. As long as the solicitation is not discussed, Offerors may continue to conduct business with the City and discuss business that is unrelated to the solicitation with the City staff who is not involved in the selection process.

Offerors may discuss their proposal or the solicitation with the Mayor or one or more members of the Phoenix City Council, provided such meetings are scheduled through the Procurement Officer conducted in person at 251 West Washington, Phoenix, Arizona, 85003, and are posted as open meetings with the City Clerk at least twenty-four (24) hours prior to the scheduled meetings. The City Clerk will be responsible for posting the meetings. The posted notice shall identify the participants and the subject matter, as well as invite the public to participate. With respect to the selection of the successful Offerors, the City Manager and/or City Manager's Office will continue the past practice of exerting no undue influence on the process. In all solicitations of bids and proposals, any direction on the selection from the City Manager and/or City Manager's Office and Department Head (or representative) to the proposal review panel or selecting authority must be provided in writing to all prospective Offerors.

21. PROTEST PROCESS

Staff recommendations to award the contract(s) to a particular Offeror or Offerors shall be posted on the Procurement Division’s website https://www.phoenix.gov/finance/business-opportunities/bid-awards-and-recommendations. Any unsuccessful bidder may file a protest no later than 7 calendar days after the recommendation is posted on the website. All protests shall be in writing, filed with the Procurement Authority identified in the solicitation and include the following:

Identification of the IFB or other solicitation number;

The name, address and telephone number of the protester;

A detailed statement describing the legal and factual grounds for the protest, including copies of relevant documents;

The form of relief requested; and

The signature of the protester or its authorized representative.

The Procurement Authority will render a written decision within a reasonable period of time after the protest is filed. The City will not request City Council authorization to award the contract until the protest process is completed.

22. EVALUATION AND AWARD A. PROPOSAL EVALUATION, NEGOTIATION AND SELECTION The City will evaluate and negotiate Proposals, select the Proposer whose proposal represents the best value to the City, and award any Contract in accordance with the criteria and procedures described in this RFP, including this section. The RFP’s approach contemplates that proposals will first be evaluated to determine which ones are in the Competitive Range. The City may then discuss




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 14 of 137

with Proposers and negotiate proposals that are in the Competitive Range, after which the City may request Best And Final Offers (BAFOs). But the City may select a proposal for award without discussions or negotiations and without requesting BAFOs. B. EVALUATION COMMITTEE The City will appoint an Evaluation Committee. The Evaluation Committee may consist of City staff, staff from other transit agencies, and other persons. The Procurement Officer shall chair the Evaluation Committee and serve in a non-voting capacity. The Evaluation Committee will evaluate proposals, establish the Competitive Range, negotiate proposals, and select the Proposer, if any, to receive the Contract award. The City may appoint a Subject Matter Expert (SME) Team to provide technical assistance to the Evaluation Committee. The SME Team may consist of City staff, staff from other public agencies, and other persons. The SME Team shall evaluate the technical portion of each proposal for compliance with the RFP specifications. The SME Team will provide a summary of its technical review to the Evaluation Committee. The Procurement Officer will review and score Price Proposals. The Proposer offering the lowest total cost will receive the maximum points allocated for price. All other Proposers will receive points based on the mathematical relationship between their proposed price and the lowest Proposer’s price. C. PROPOSAL SELECTION PROCESS In selecting a Proposer, the City will apply the evaluation criteria set forth above (Paragraph 16) and will evaluate proposals as provided in Sections F and G below. The section “Qualification (Responsibility) Requirements” below specifies the requirements for determining responsible Proposers, all of which requirements must be met by a Proposer to be found qualified. The final determination of a Proposer’s qualifications will be based upon all information received during the evaluation process. D. QUALIFICATION (RESPONSIBILITY) REQUIREMENTS The following requirements determine Proposer responsibility. All of these requirements must be met. They are not listed in order of importance. The City’s final review of a Proposer’s responsibility will be based on the information in the proposal, any information submitted at the City’s request, all information in a Best and Final Offer (if applicable), and information received from Proposer’s references. Any Proposer whose proposal does not meet these requirements, as determined by the Evaluation Committee, is not responsible, and the Proposer’s proposal will not be considered further in the evaluation process. The requirements are as follow: Each Proposer shall possess and demonstrate the capability to perform the Work and to complete the Contract in a satisfactory manner, as measured by the following:

Proposer’s ability to secure the required performance bond as evidenced by a letter of commitment from a surety authorized to write surety business in Arizona confirming that the Proposer can be bonded for the required amount.

Proposer’s ability to secure the required insurance coverages in limits that meet minimum RFP requirements, all as evidenced by a commitment letter from an underwriter confirming that Proposer is insurable for the required coverages in the required limits.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 15 of 137

Each Proposer shall demonstrate evidence that its human and physical resources are sufficient to perform the Contract and to ensure the level of service required, including sufficient personnel in the requisite disciplines and all necessary licenses, skills, experience and equipment to complete the Contract as required. Each Proposer shall demonstrate evidence of satisfactory past performance of contracts of similar size, scope and complexity as evidenced by client references.

E. PROPOSER EXCEPTIONS The Procurement Officer will review and analyze all Proposer exceptions, conditions, reservations or understandings, if any, stated in each proposal in Tab 9 – Alternative Terms/Exceptions. If the exceptions, conditions, reservations or understandings are acceptable, the Evaluation Committee will evaluate the proposal according to the evaluation criteria affected by the exceptions, conditions, reservations or understandings. The City may reject any and all exceptions. Proposer may not take exception to mandatory RFP requirements or to requirements that are conditions of responsiveness. F. EVALUATION PROCEDURE The detailed evaluation forms and procedures follow the same proposal format and organization specified in Section I, Solicitation Instructions, “Submittal Format”. Therefore, Proposers must closely read and strictly follow all instructions. By submitting a proposal, the Proposer accepts all of the Contract documents, except the conditions, exceptions, reservations or understandings that are explicitly, fully and separately stated and submitted in accordance with Section E Proposer Exceptions.” Under the criteria set forth in Section C “Proposal Selection Process,” the Evaluation Committee will evaluate any conditions, exceptions, reservations or understandings that do not result in the rejection of the proposal. Evaluations will be made in strict accordance as described in Section C above. The Evaluation Committee will recommend the Proposal that constitutes the best value and is the most advantageous to the City.

G. EVALUATION OF COMPETITIVE PROPOSALS 1. Determining Responsiveness Nonresponsive proposals will not be considered in the evaluation process. The RFP states criteria that determine responsiveness, and the RFP identifies terms and conditions that if included or excluded from proposals (as the case may be) will render a proposal nonresponsive. The Procurement Officer will review only exceptions, conditions, reservations or understandings that are explicitly, fully and separately stated in a proposal to determine if one or more are acceptable. Exceptions, conditions, reservations, or understandings are presumed to be unacceptable, and a Proposal that includes unacceptable exceptions, conditions, reservations, or understandings may be rejected as nonresponsive. 2. Qualification of Responsible Proposers The Procurement Officer, will review each Proposal to determine if the Proposer is responsible. This determination will be made based on the initial information in the Proposal, any information at the City’s request, information in any Best and Final Offer, and information received from Proposer’s references, including information about Proposer’s past history. A review of responsibility may occur up to contract award.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 16 of 137

3. Detailed Evaluation of Proposals and Determination of Competitive Range The Evaluation Committee will perform and document its evaluation in accordance with the criteria and procedures set forth in Section C “Proposal Selection Process.” During deliberations, the Evaluation Committee will reach a consensus score for each evaluation criterion except price, which the Procurement Officer will score. The consensus scores will determine the Proposers’ rankings and which Proposals are within the Competitive Range. 4. Proposals not within the Competitive Range In accordance with City policies, the City will notify Proposers of any proposals that the City has determined are not in the Competitive Range. 5. Discussions with Proposers in the Competitive Range The City will notify each Proposer whose proposal is in the Competitive Range and provide in writing any questions or requests for clarification, if any, that the City has to the Proposer. Each Proposer so notified may be interviewed by the City and asked to discuss answers to written or oral questions or provide clarification to any aspect of its proposal. If a proposal in the Competitive Range contains conditions, exceptions, reservations or understandings to or about any Contract requirement, the City (as provided in Section E “Proposer Exceptions”) may discuss or negotiate the conditions, exceptions, reservations or understandings during these meetings. But, the City, in its sole discretion, may reject any and all conditions, exceptions, reservations and understandings, and the City may instruct any Proposer to remove the conditions, exceptions, reservations or understandings. If the Proposer fails to do so, the City will determine the Proposal is nonresponsive, and the City will revoke its determination that the proposal is in the Competitive Range. To the fullest extent permitted by law, the City will not provide any information, financial or otherwise, to any Proposer about other proposals received in response to this RFP. During discussions with Proposers in the Competitive Range, the City will not give Proposers specific prices or specific financial requirements that Proposers must meet to qualify for further consideration. But, the City may state that proposed prices are too high with respect to the marketplace or otherwise unacceptable. Proposers will not be told of their relative rankings before Contract award. 6. Best and Final Offers (BAFO) Each remaining Finalist in the Competitive Range may be afforded the opportunity to amend its proposal and make one BAFO. The request for BAFOs will include the following:

Notice that discussions/negotiations are concluded.

Notice that this is the opportunity to submit a written BAFO.

A common date and time for submission of a BAFO by each remaining Finalist in the Competitive Range, allowing a reasonable opportunity to prepare BAFOs.

Notice that if any modification to a BAFO is submitted, it must be received by the date and time specified for receipt of BAFOs.

Notice to each remaining Finalist that does not submit a notice of withdrawal or a BAFO that their immediately previous proposal will be construed as their BAFO.

If a remaining Finalist’s BAFO modifies its initial Proposal, the modifications must be identified in the BAFO. The City will evaluate BAFOs based on the same requirements and criteria applicable to initial Proposals. The City will adjust appropriately the initial scores for criteria that have been affected by Proposal modifications made by a BAFO. Based on the criteria defined in Section C




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 17 of 137

“Proposal Selection Process” as weighted, the City will then perform final scoring and prepare final rankings. The Evaluation Committee will recommend the proposal that is the best value and most advantageous to the City based on the evaluation criteria. The results of the evaluation and the selection of a Proposer for any award will be documented in the Solicitation File. The City reserves the right to make an award to a Proposer whose proposal it judges to be the best value and most advantageous to the City based on the evaluation criteria, without conducting written or oral discussions with any Proposer and without soliciting BAFOs. 7. Interviews The City reserves the right to conduct interviews with some or all of the Proposers at any point during the evaluation process. However, the City may determine that interviews are not necessary. In the event interviews are conducted, information provided during the interview process may be taken into consideration when evaluating the stated criteria. The City shall not reimburse the Proposer for the costs associated with the interview process. H. DEBRIEFING After Contract award, unsuccessful Proposers will be notified and may request a debriefing.

SECTION II - STANDARD TERMS AND CONDITIONS



Phoenix, AZ 85003 Phone: (602) 262-7181


Page 18 of 137

1. DEFINITION OF KEY WORDS USED IN THE SOLICITATION

Shall, Will, Must: Indicates a mandatory requirement. Failure to meet a mandatory requirement may result in the rejection of an Offeror’s proposal as non-responsive.

Should: Indicates something that is recommended but not mandatory. If an Offeror fails to provide recommended information, the City may, at its sole option, ask the Offeror to provide the information or evaluate the Offeror’s proposal without the information.

May: Indicates something that is not mandatory but permissible.

Additionally, for purposes of this Solicitation and any subsequent contract or agreement, the following definitions shall apply: “A.R.S.” Arizona Revised Statute "City" The City of Phoenix "Contractor" The Offeror as an individual, partnership, company, corporation or

entity that, as a result of the competitive process, is awarded a contract by the City.

"Contract/Agreement" The legal contract or agreement executed between the City and

the Contractor. "Contract Representative" The City employee or employees who have specifically been

designated to act as a contact person(s) with the Contractor, and responsible for monitoring and overseeing the Contractor’s performance under this Contract.

“days” Means calendar days unless otherwise specified. “Deputy Finance Director” The contracting authority for the City of Phoenix, AZ, authorized

to sign contracts and amendments thereto on behalf of the City of Phoenix, AZ.

“Employer” Any individual or type of organization that transacts business in

this state, that has a license issued by an agency in this state and employs one or more employees in this state. Employer includes this state, any political subdivision of this state and self-employed persons. In the case of an independent contractor, employer means the independent contractor and does not mean the person or organization that uses the independent contractor’s contract labor. (A.R.S. § 23-211).

“Offer” Means bid, proposal or quotation. “Offeror” Means a Vendor who responds to the Request for Proposal. “Solicitation” Means a Request for Proposal (“RFP”).




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 19 of 137

“Suppliers” Firms, entities or individuals furnishing goods or services directly to the City.

“Vendor” A seller of goods or services.

2. CONTRACT INTERPRETATION

2.1 APPLICABLE LAW: This Contract shall be governed by the law of the State of Arizona, without effect to Arizona’s conflict of law rules and any lawsuits pertaining to this Contract shall be brought only in the federal or state courts in Maricopa County, State of Arizona.

2.2 IMPLIED CONTRACT TERMS: Each and every provision of law and any clause required

by law to be in this Contract shall be read and enforced as though it were included herein, and, if through mistake or otherwise, any such provision is not inserted, or is not correctly inserted, then upon the application of either Party, the Contract shall be physically amended to make such insertion or correction.

2.3 CONTRACT ORDER OF PRECEDENCE: In the event of a conflict in the contractual

provisions of this Contract, as agreed to by the Parties and as may be amended, the following shall prevail in the order set forth below:

A. Special Terms and Conditions B. Standard Terms and Conditions C. Scope of Work D. Specifications E. Attachments F. Exhibits G. Instructions to Offerors H. Other documents referenced or included in the Request for Proposal, including

Offeror’s submitted proposal 2.4 ORGANIZATION—EMPLOYMENT DISCLAIMER: The Contract resulting hereunder is

not intended to constitute, create, give rise to or otherwise recognize a joint-venture agreement or relationship, partnership or formal business organization of any kind, and the rights and obligations of the Parties shall be only those expressly set forth herein. The Parties agree that no persons supplied by the Contractor in the performance of Contractor’s obligations under this Contract are considered to be City employees and that no rights of City civil service, retirement or personnel rules accrue to such persons. The Contractor shall have total responsibility for all salaries, bonuses, retirement, withholdings, workers’ compensation, occupational disease compensation, unemployment compensation, any and all other employee benefits and all taxes and premiums appurtenant thereto concerning such persons, and Contractor shall save and hold the City harmless with respect thereto.

2.5 SEVERABILITY: The provisions of this Contract are severable to the extent that any

provision or application held to be invalid shall not affect any other provision or application of the Contract which shall remain in effect without the invalid provision or application.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 20 of 137

2.6 NON-WAIVER OF LIABILITY: The City of Phoenix, as a public entity supported by tax

monies and in execution of its public trust, cannot agree to waive any lawful or legitimate right to recover monies lawfully due it. Therefore, any Contractor agrees that it will not insist upon or demand any statement whereby the City agrees to limit in advance or waive any right the City has or might have to recover actual lawful damages in any court of law.

2.7 PAROL EVIDENCE: This Contract is intended by the undersigned Parties as the final

expression of their agreement and is intended to be the complete and exclusive statement of the terms of the agreement between the Parties. No course of prior dealings between the Parties and no usage in the trade shall be relevant to supplement or explain any term used in this Contract. Acceptance or acquiescence in a course of performance rendered under this Contract shall not be relevant to determine the meaning of this Contract even though the accepting or acquiescing Party has knowledge of the nature of the performance and the opportunity to object.

3. CONTRACT ADMINISTRATION AND OPERATION

3.1 RECORDS: All books, accounts, reports, files and other records relating to the Contract

shall be subject at all reasonable times to inspection and audit by the City for five (5) years after completion of the Contract. Such records will be produced at a City of Phoenix office as designated by the City.

3.2 PUBLIC RECORD: All proposals submitted in response to this Solicitation shall become

the property of the City and become a matter of public record available for public review or disclosure pursuant to the State of Arizona Public Records law.

Offeror shall accordingly mark any information included in its proposal that Offeror deems

confidential or proprietary (collectively, “Proprietary Information”). If the City receives a request to review or disclose such Proprietary Information, the City will provide Offeror with written notice of the request to allow Offeror the opportunity to obtain a court order within seven (7) days from the date of notice. If no court order is issued and received by the City within such seven (7) day period, the City may disclose or allow the review of such Proprietary Information in accordance with the State of Arizona Public Records law.

3.3 CONFIDENTIALITY AND DATA RECORD: All data, regardless of form, and including,

without limitation, originals, images and reproductions, prepared by, obtained by, or transmitted to Offeror/Contractor, in connection with this RFP or resulting Contract, is confidential, proprietary information owned by the City. Except as specifically provided in this RFP, or the resulting Contract, Offeror/Contractor shall not disclose any of the above described data to any third person without the prior written consent of the City Manager, or his/her designee. Personal identifying information, financial account information, or restricted City information, whether electronic format or hard copy, must be secured and protected at all times to avoid unauthorized access. At a minimum, Offeror/Contractor must encrypt and/or password-protect electronic files. This includes any data saved to laptop computers, computerized devices or removable storage devices.

When personal identifying information, financial account information, or restricted City information, regardless of its format, is no longer necessary, the information must be redacted or destroyed through appropriate and secure methods that ensure the information cannot be viewed, accessed or reconstructed.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 21 of 137

In the event that data collected or obtained by Offeror/Contractor, in connection with this RFP or resulting Contract, is believed to have been compromised, Offeror/Contractor shall notify the City Privacy Officer immediately. Offeror/Contractor agrees to reimburse the City for any costs incurred by the City in investigating any potential breach of this data and, where applicable, the cost of notifying individuals who may be impacted by such breach. Contractor agrees that the requirements of this Paragraph 3.3 shall be incorporated into all subcontractor agreements entered into by Contractor. It is further agreed that a violation of Paragraph 3.3 shall be deemed to cause irreparable harm justifying injunctive relief in court. A violation of Paragraph 3.3 may result in immediate termination of this Contract without notice. Offeror, in submitting its proposal to the RFP, and Contractor, in signing the Contract, agree to be bound by Paragraph 3.3. Further, the obligations of Offeror/Contractor under Paragraph 3.3 shall continue past the expiration date of the RFP and shall survive the termination of this Contract.

3.4 DISCRIMINATION PROHIBITED: Contractor agrees to abide by the provisions of the

Phoenix City Code, Chapter 18, Article V as amended.

Any Contractor, service provider, supplier and/or lessee in performing under this Contract shall not discriminate against any worker, employee or applicant, or any member of the public, because of race, color, religion, sex, national origin, age or disability, nor otherwise commit an unfair employment practice. The Contractor, service provider, supplier and/or lessee will take action to ensure that applicants are employed, and employees are dealt with during employment without regard to their race, color, religion, sex, or national origin, age or disability. Such action shall include, without limitation, the following: employment and adherence to a policy to pay equal compensation to men and women who perform jobs that require substantially equal skill, effort and responsibility, and that are performed within the same establishment under similar working conditions, promotion, demotion or transfer, recruitment or recruitment advertising, layoff or termination, rates of pay or other forms of compensation, and selection for training, including apprenticeship. The Contractor, service provider and/or supplier further agree that this clause will be incorporated in all subcontracts with all labor organizations furnishing skilled, unskilled and union labor, or who may perform any such labor or services in connection with this Contract. The Contractor further agrees that this clause will be incorporated in all subcontracts and/or job-consultant agreements or subleases connected with this Agreement that is entered into by Contractor.

3.5 LICENSES AND PERMITS: Contractor shall keep current federal, state, and local licenses

and permits required for the operation of the business conducted by Contractor as applicable to this Contract.

3.6 ADVERTISING: Contractor shall not advertise or publish news releases concerning this

Contract without the prior written consent of the Deputy Finance Director, and the City shall not unreasonably withhold permission.

3.7 EXCLUSIVE POSSESSION: All services, information, computer program elements, reports, and other deliverables which may be created under this Contract are the sole property of the City and shall not be used or released by Contractor, or any other person, without prior written permission by the City.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 22 of 137

3.8 OWNERSHIP OF INTELLECTUAL PROPERTY: Any and all intellectual property, including, but not limited to, copyright, invention, trademark, trade name, service mark, and/or trade secrets created or conceived pursuant to or as a result of this Contract and any related subcontract (“Intellectual Property”), shall be considered work for hire and the City shall be considered the creator of such Intellectual Property. The agency, department, division, board or commission of the City requesting the issuance of this Contract shall own (for and on behalf of the City) the entire right, title and interest to the Intellectual Property throughout the world. Contractor shall notify the City, within thirty (30) days, of the creation of any Intellectual Property by it, or its subcontractor(s). Contractor, on behalf of itself and any subcontractor(s), agrees to execute any and all document(s) necessary to assure that ownership of the Intellectual Property vests in the City and shall take no affirmative steps that might have the effect of vesting all or part of the Intellectual Property in any entity other than the City. The Intellectual Property shall not be disclosed by Contractor or its subcontractor(s) to any other person or entity without the express written authorization by the City. If by operation of law, the Intellectual Property is not owned in its entirety by the City automatically upon its creation, then Contractor agrees to assign and hereby assigns to the City the ownership of the Intellectual Property. Contractor agrees to take such further action and execute and deliver such further agreements and other instruments as the City may reasonably require to give effect to this Paragraph 3.8.

It is expressly agreed by Contractor that these covenants are irrevocable and perpetual.

3.9 HEALTH, ENVIRONMENTAL AND SAFETY REQUIREMENTS: Contractor’s products,

services and facilities shall be in full compliance with all applicable federal, state and local health, environmental and safety laws, regulations, standards, codes and ordinances, regardless of whether or not they are referred to by the City.

At the request of the City, the Contractor shall provide the following:

Environmental, safety and health regulatory compliance documents (written safety programs, training records, permits, etc.) applicable to services provided by the Contractor in this Contract.

A list of all federal, state, or local (EPA, OSHA, Maricopa County, etc.) citations or notice of violations issued against Contractor, or its subcontractors, including dates, reasons, dispositions and resolutions.

The City shall have the right, but not the obligation, to inspect the facilities, transportation vehicles or vessels, containers and disposal facilities provided by Contractor or its subcontractor(s). The City shall also have the right to inspect operations conducted by Contractor or its subcontractor(s) in the performance of this Contract.

3.10 COMPLIANCE WITH LAWS: Contractor agrees to fully observe and comply with all applicable federal, state and local laws, regulations, standards, codes and ordinances when performing under this Contract regardless of whether or not they are referred to by the City. Contractor agrees that upon the City’s request, Contractor will provide its business records so that the City can verify such compliance.

Because Contractor will be acting as an independent contractor, the City assumes no responsibility for Contractor’s acts.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 23 of 137

3.11 LAWFUL PRESENCE REQUIREMENT: Pursuant to A.R.S. §§ 1-501 and -502, the City

is prohibited from awarding a contract to any natural person who cannot established that he or she is lawfully present in the United States. In order to establish lawful presence, this person must produce qualifying identification and sign a City-provided affidavit affirming that the identification provided is genuine. This requirement will be imposed at the time of contract award. In the event the prevailing responder is unable to satisfy this requirement, the City will offer the award to the next-highest scoring responder. The law does not apply to fictitious entities such as corporations, partnerships and limited liability companies.

3.12. LEGAL WORKER REQUIREMENTS: The City is prohibited by A.R.S. § 41-4401 from awarding an agreement to any contractor who fails, or whose subcontractors fail, to comply with A.R.S. § 23 214(A) (e-verify). Therefore, Contractor agrees that: Contractor and each subcontractor it uses warrants their compliance with all federal immigration laws and regulations that relate to their employees and their compliance with § 23-214, subsection A. A breach of this warranty shall be deemed a material breach of the Agreement and is subject to penalties up to and including termination of the Agreement. Upon the City’s request, Contractor or subcontractor will provide employee records for all employee(s) who work(s) on this Agreement to ensure that Contractor or subcontractor are in compliance with this warranty.

3.13 CONTINUATION DURING DISPUTES: Contractor agrees that notwithstanding the existence of any dispute between the Parties, under the terms of the Contract, Contractor shall continue to perform the obligations required of it during the continuation of any such dispute unless enjoined or prohibited by an Arizona Court of competent jurisdiction.

3.14 EMERGENCY PURCHASES: The City reserves the right to purchase or receive services

from other sources any items or services that are required on an emergency basis and cannot be immediately supplied from or provided by Contractor.

3.15 STRICT PERFORMANCE: Failure of either Party to (a) insist upon the strict performance

of any item or condition of the Contract, or (b) exercise, or delay the exercise of any right or remedy provided in the Contract, or by law, shall not be deemed a waiver of any right of either Party to insist upon the strict performance of the Contract.

4. COSTS AND PAYMENTS

4.1 PAYMENT TERMS: The City shall make every effort to process payment for the purchase

of material or services within thirty (30) calendar days after receipt of a correct invoice unless a good faith dispute exists to any obligation to pay either all or a portion of the account.

4.2 PAYMENT DEDUCTION OFFSET PROVISION: Contractor acknowledges that the City

Charter requires that no payment be made to any Contractor as long as there is an outstanding obligation due to the City. Any obligation Contractor owes to the City will be offset against any payment due to Contractor from the City.

4.3 LATE SUBMISSION OF CLAIM BY CONTRACTOR: The City will not honor any invoices

or claims which are tendered ninety (90) days after the Contract expires (last item of the account accrued).




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 24 of 137

4.4 NO ADVANCE PAYMENTS: Advance payments are not authorized. Payment will be

made only for actual services or commodities that have been received and accepted.

4.5. PARTIAL PAYMENTS: Partial payments are not authorized. Payment will be made as described in the Pricing and Payment Schedule to this Contract.

4.6 FUND APPROPRIATION CONTINGENCY: The Contractor recognizes that any

agreement entered into shall commence upon execution of acceptance, via signature, by the City and continue in full force and effect until termination in accordance with its provisions. The Contractor and the City herein recognize that the continuation of any contract after the close of any given fiscal year of the City, which fiscal year ends on June 30 of each year, shall be subject to the approval of the budget of the City providing for or covering such contract item as an expenditure therein. The City does not represent that said budget item will be actually adopted, said determination being the determination of the City Council at the time of the adoption of the budget.

4.7 MAXIMUM PRICES: The City shall not be invoiced at prices higher than those stated in

any contract resulting from this proposal. Offeror certifies, by signing this proposal that the prices offered are no higher than the lowest price the Offeror charges other buyers for similar quantities or services under similar conditions. Offeror further agrees that any reductions in the price of the goods or services covered by this proposal and occurring after award will apply to the undelivered balance. The Offeror shall promptly notify the City of such price reductions.

4.8 METHOD OF ORDERING (PURCHASE ORDERS): Issuance of written purchase order(s)

by the Procurement Division. Contractor shall deliver items and/or services only upon receipt of a written purchase order issued by the Procurement Division. All Contractor invoices and packing/delivery tickets must include the City of Phoenix purchase order number.

4.9 METHOD OF INVOICING: Invoice must include the following: A. City purchase order number, requisition number, or contract agreement number. B. Items listed individually by the written description and part number. C. Unit price, extended and totaled. D. Quantity ordered, back ordered, and shipped. E. Applicable tax. F. Invoice number and date. G. Requesting department name and "ship-to" address.

5. CONTRACT CHANGES

5.1 CONTRACT AMENDMENTS: The Contract (Section II, Standard Terms and Conditions,

Section III, Special Terms and Conditions), Pricing and Payment Schedule and the End User License Agreement (EULA) shall be modified only by a written contract amendment signed by the Deputy Finance Director and persons duly authorized to enter into contracts on behalf of the Contractor.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 25 of 137

5.2 ASSIGNMENT–DELEGATION: Contractor may assign its rights and obligations under

this Contract without the approval of the City to a third party in connection with a merger, consolidation, liquidation or reorganization of Contractor or its wholly owned subsidiaries or affiliates. Otherwise, no right or interest in this Contract, nor monies due, thereunder, shall be assigned in whole or in part without written permission of the City, and no delegation of any duty of Contractor shall be made without prior written permission of the City, which may be withheld for good cause. Any assignment or delegation made in violation of this Paragraph shall be void.

5.3 NON-EXCLUSIVE CONTRACT: Any Contract resulting from this Solicitation shall be

awarded with the understanding and agreement that it is for the sole convenience of the City. The City reserves the right to obtain like goods or services from another source when necessary.

5.4 AUTHORIZED CHANGES: The City reserves the right at any time to make changes in the

specifications of this Contract and/or the time of delivery. If the change causes an increase or decrease in the cost of, or the time required for performance, an equitable adjustment may be made in the price or delivery schedule, or both. Any claim for adjustment shall be deemed waived unless asserted in writing within thirty (30) days from the receipt of the change. Any price increases or extensions of delivery time shall not be binding on the City unless evidenced in writing and approved by the Deputy Finance Director prior to the institution of the change.

6. RISK OF LOSS AND LIABILITY

6.1 TITLE AND RISK OF LOSS: The title and risk of loss of material or service shall not pass

to the City until the City actually receives the material or service at the point of delivery; and such loss, injury, or destruction shall not release Contractor from any obligation hereunder.

6.2 ACCEPTANCE: All goods and/or services provided are subject to acceptance by the City. Goods and/or services failing to conform to the specifications of this Contract shall not be accepted by the City and Contractor’s performance will be noncompliant. Noncompliance shall allow invocation by the City of the cancellation clause(s) set forth in this Contract.

6.3 GENERAL INDEMNIFICATION: Contractor shall indemnify, defend, save and hold

harmless the City and its officers, officials, agents, and employees (hereinafter referred to as “Indemnitee”) from and against any and all claims, actions, liabilities, damages, losses, or expenses (including court costs, attorneys’ fees, and costs of claim processing, investigation and litigation) (hereinafter referred to as “Claims”) for bodily injury or personal injury (including death), or loss or damage to tangible or intangible property caused, or alleged to be caused, in whole or in part, by the negligent or willful acts or omissions of Contractor, or any of its owners, officers, directors, agents, employees or subcontractors. This indemnity includes any claim or amount arising out of or recovered under the Workers’ Compensation Law, or arising out of the failure of such Contractor to conform to any federal, state or local law, statute, ordinance, rule, regulation or court decree. It is the specific intention of the Parties that the Indemnitee shall, in all instances, except for Claims arising solely from the negligent or willful acts or omissions of the Indemnitee, be indemnified by Contractor from and against any and all Claims. It is agreed that Contractor will be responsible for primary loss investigation, defense and judgment costs where this indemnification is applicable. In consideration of the award of this Contract, the Contractor




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 26 of 137

agrees to waive all rights of subrogation against the City, its officers, officials, agents, and employees for losses arising from the work performed by the Contractor for the City.

6.4 INDEMNIFICATION–PATENT, COPYRIGHT AND TRADEMARK. Contractor shall indemnify and hold harmless the City against any liability, including costs and expenses, for infringement of any patent, trademark or copyright or other proprietary rights of any third parties arising out of contract performance or use by the City of materials furnished or work performed under this Contract. Contractor agrees upon receipt of notification to promptly assume full responsibility for the defense of any suit or proceeding which is, has been, or may be brought against the City and its agents for alleged infringement and/or for the alleged unfair competition resulting, without limitation, from similarity in design, trademark, appearance or process of goods or services by reason of the use or sale of any goods or services furnished under this Contract. Contractor further agrees to indemnify the City against any and all expenses, losses, royalties, profits and damages including court costs and attorneys’ fees resulting from the bringing of such suit or proceedings including any settlement or decree of judgment entered therein. The City may be represented by and actively participate through its own counsel in any such suit or proceedings if it so desires. It is expressly agreed by the Contractor that these covenants are irrevocable and perpetual.

6.5 FORCE MAJEURE: Except for payment of sums due, neither the City, nor Contractor

(individually Party), shall be liable to the other nor deemed in default under this Contract if and to the extent that such Party's performance of this Contract is prevented by reason of force majeure. The term "force majeure" means an occurrence that is beyond the control of the party affected and occurs without its fault or negligence. Force majeure shall not include late performance by a subcontractor unless the delay arises out of a force majeure occurrence in accordance with this force majeure term and condition. If either Party is delayed at any time in the progress of the work by force majeure, the delayed Party shall notify the other Party in writing of such delay, as soon as is practical, of the commencement thereof and shall specify the causes of such delay in such notice. Such notice shall be hand-delivered or mailed certified-return receipt and shall make a specific reference to this provision, thereby invoking its provisions. The delayed Party shall cause such delay to cease as soon as practicable and shall notify the other Party in writing when it has done so. The time of completion shall be extended by written contract amendment for a period of time equal to the time delay resulting from force majeure which prevented the delayed Party from performing in accordance with this Contract.

6.6 LOSS OF MATERIALS: The City does not assume any responsibility, at any time, for the protection of, or for the loss of materials, from the time that contract operations have commenced until final acceptance by the Deputy Chief of Technical Services of the Phoenix Fire Department of the work, goods and/or services subject to this Contract.

6.7 DAMAGE TO CITY PROPERTY: Contractor shall perform all work so that no damage to

any buildings, grounds and/or any other City property results. Contractor shall be responsible for the satisfactory repair of any damage caused, or, where applicable, shall be responsible for replacing any damaged property to the satisfaction of the City at no cost to the City.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 27 of 137

Contractor shall take care to avoid damage to adjacent finished materials that are to remain. If finished materials are damaged, Contractor shall repair and finish to match existing material as approved by the City at Contractor's expense.

7. WARRANTIES

7.1 GUARANTEE: All goods and services under this Contract shall be guaranteed as

described in the agreed upon Warranty to this Contract. 7.2 QUALITY: Contractor expressly warrants that all goods or services furnished under this

Contract shall conform to the specifications, appropriate standards, and will be new and free from defects in material or workmanship. Contractor warrants that all goods or services furnished hereunder will be merchantable, and will be safe and appropriate for the purpose which goods or services of that kind are normally used. Inspection, test, acceptance of use of the goods or services furnished hereunder shall not affect the Contractor’s obligation under this warranty, and such warranties shall survive inspection, test, acceptance and use. Contractor’s warranty shall run to the City, its successors, and assigns.

7.3 RESPONSIBILITY FOR CORRECTION: Contractor shall be fully responsible for making

any correction, replacement, or modification necessary for specification or legal compliance.

7.4 LIENS: Contractor shall hold the City harmless from any claimants supplying labor or

materials to Contractor or from Contractor’s subcontractor(s) in the performance of the work required under this Contract. Contractor shall provide written certification that all liens against materials and labor have been satisfied, before the City will make payment.

7.5 BEST STANDARDS, PRACTICES AND WORKMANSHIP: Where not more specifically

described in any of the various sections of this Contract, workmanship shall conform to all of the methods and operations of best standards and accepted practices of the trade or trades involved, and shall include all items of fabrication, construction or installation regularly furnished or required for completion of the services provided. All work shall be executed by personnel skilled in their respective lines of work.

8. CITY’S CONTRACTUAL RIGHTS

8.1 RIGHT TO ASSURANCE: Whenever one Party to this Contract in good faith has reason

to question the other Party's intent to perform, the former Party may demand that the other Party give a written assurance of that other Party’s intent to perform. In the event that a demand is made and no written assurance is given within five (5) days, the demanding Party may treat this failure as an anticipatory repudiation of this Contract by the other Party.

8.2 NON-EXCLUSIVE REMEDIES: The rights and remedies of the City under this Contract

are non-exclusive. 8.3 DEFAULT IN ONE INSTALLMENT TO CONSTITUTE BREACH: Each installment or lot

of the Contract is dependent on every other installment or lot. Thus, a delivery of non-conforming goods or services, or a default of any nature under one installment or lot will impair the value of the entire Contract and will constitute a total breach of the entire Contract.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 28 of 137

8.4 ON TIME DELIVERY: Because the City is providing services which involve health, safety and welfare of the general public, delivery time is of the essence. Delivery must be made in accordance with the delivery schedule promised by the Offeror.

8.5 DEFAULT: In case of default by the Contractor, the City may, by written notice, cancel

this Contract and contract with another source. Further, the City may recover any excess costs incurred by (1) deduction from any unpaid balance due the Contractor; (2) collection against the Contractor and/or the Contractor’s performance bond, or (3) a combination of the above remedies, or other, remedies provided by law.

8.6 COVENANT AGAINST CONTINGENT FEES: Contractor warrants that no person or

selling agent has been employed or retained to solicit or secure this Contract upon an agreement or understanding for a commission, percentage, brokerage, or contingent fee, excepting bona fide employers or bona fide established commercial or selling agencies maintained by the Contractor for the purpose of securing business. For breach or violation of this warranty, the City shall have the right to annul the Contract without liability, or in its discretion, to deduct from the contract price a consideration, or otherwise recover the full amount of such commission, brokerage or contingent fee.

8.7 COST JUSTIFICATION: In the event only one proposal or response to this

Solicitation/Request for Proposal is received, the City may require that the Offeror submit a proposal or response in sufficient detail for the City to perform an analysis to determine if the proposal price is fair and reasonable.

8.8 WORK PRODUCT, EQUIPMENT AND MATERIALS: All work product, equipment, or

materials created or purchased under this Contract belongs to the City and must be delivered to the City at City’s request upon termination of this Contract. Contractor agrees that all materials prepared under this Contract are “works for hire” within the meaning of the copyright laws of the United States and assigns to City all rights and interests Contractor may have in the materials it prepares under this Contract, including any right to derivative use of the material.

9. CONTRACT TERMINATION

9.1 GRATUITIES: The City may, by written notice to the Contractor, cancel this Contract if it is found that gratuities, in the form of entertainment, gifts or otherwise, were offered or given by the Contractor, or any agent or representative of the Contractor, to any officer or employee of the City making any determination(s) with respect to the award or performance of this Contract. In the event this Contract is canceled by the City pursuant to this provision, the City shall be entitled, in addition to any other rights and remedies, to recover or withhold from the Contractor the amount of the gratuity.

9.2 CONDITIONS AND CAUSES FOR TERMINATION: This Contract may be terminated at

any time by mutual written consent, or by the City, with or without cause, upon giving thirty (30) days written notice to Contractor. Additionally, the City, at its convenience and by written notice, may terminate this Contract in whole or in part. If this Contract is terminated, the City shall be liable only for payment under the payment provisions of this Contract for services rendered and accepted and any material received by the City before the effective date of termination. Contractor shall submit detailed cost claims in an acceptable manner and shall permit the City to examine such books and records as may be necessary in order to verify the reasonableness of any claims. Title to all materials, work-in-process and any




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 29 of 137

completed but not yet delivered goods, will pass to the City after costs are claimed and allowed.

The City reserves the right to cancel the whole or any part of this Contract due to failure of Contractor to carry out any term, promise, or condition of the Contract. The City will issue a written notice of default to Contractor for acting, or failing to act as in any of the following:

In the opinion of the City, Contractor provides personnel who do not meet the requirements of the Contract;

In the opinion of the City, Contractor fails to perform adequately the stipulations, conditions or services/specifications required in this Contract;

In the opinion of the City, Contractor attempts to impose on the City personnel, materials, products/goods, services or workmanship of an unacceptable quality.

Contractor fails to furnish the required service(s) and/or product(s)/goods within the time stipulated in the Contract;

In the opinion of the City, Contractor fails to make progress in the performance of the requirements of the Contract and/or fails to give the City a positive indication that Contractor will or can perform to the requirements of the Contract.

9.3 CONTRACT CANCELLATION: All Parties acknowledge that this Contract is subject to cancellation by the City pursuant to the provisions of A.R.S. § 38-511.

SECTION III – SPECIAL TERMS AND CONDITIONS



Phoenix, AZ 85003 Phone: (602) 262-7181


Page 30 of 137

1. CONTRACT TYPE, PRICE

The Contract shall be fixed price with price adjustments during the implementation period. Thereafter, annual maintenance costs will be capped at the amounts defined herein. All prices submitted shall be firm and fixed for the contract period.

2. TERM OF CONTRACT

The initial Contract term shall commence on execution of contract acceptance, via signature, by the City and continue in full force and effect until termination in accordance with the Contract provisions.

3. INSURANCE REQUIREMENTS

Contractor and its subcontractors shall procure and maintain, until all of their contractual obligations have been discharged, including any maintenance and warranty periods under this Contract are satisfied, insurance against claims for injury to persons or damage to property which may arise from or in connection with the performance of the work hereunder by the Contractor, its agents, representatives, employees or subcontractors.

The insurance requirements are minimum requirements for this Contract and in no way limit the indemnity covenants contained in this Contract. The City in no way warrants that the minimum limits contained herein are sufficient to protect the Contractor from liabilities that might arise out of the performance of the work under this Contract by the Contractor, its agents, representatives, employees or subcontractors and Contractor is free to purchase additional insurance as may be determined necessary. MINIMUM SCOPE AND LIMITS OF INSURANCE: Contractor shall provide coverage with limits of liability not less than those stated below. An excess liability policy or umbrella liability policy may be used to meet the minimum liability requirements provided that the coverage is written on a “following form” basis.

Commercial General Liability–Occurrence Form Policy shall include bodily injury, property damage and broad form contractual liability coverage. General Aggregate $2,000,000 Products–Completed Operation Aggregate $1,000,000 Personal and Advertising Injury $1,000,000 Each Occurrence $1,000,000 Contractor will provide the City with a certificate of insurance evidencing the limits listed above and indicating that the City is insured under Contractor’s policy. The policy must be endorsed to include the following additional insured language: "The City of Phoenix is named as an additional insured with respect to liability arising out of the activities performed by, or on behalf of the Contractor". Automobile Liability Bodily Injury and Property Damage coverage for any owned, hired, and non-owned vehicles used in the performance of this Contract . Combined Single Limit (CSL) $1,000,000




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 31 of 137

Contractor will provide the City with a certificate of insurance evidencing the limits listed above and indicating that the City is insured under Contractor’s policy. The policy must be endorsed to include the following additional insured language: "The City of Phoenix is named as an additional insured with respect to liability arising out of the activities performed by, or on behalf of the Contractor, including automobiles owned, leased, hired or borrowed by the Contractor. Worker's Compensation and Employers' Liability. Workers' Compensation–Statutory Employers' Liability Each Accident $100,000 Disease–Each Employee $100,000 Disease–Policy Limit $500,000

Contractor will provide the City with a certificate of insurance evidencing the limits listed above and indicating that the City is insured under Contractor’s policy. Policy must contain a waiver of subrogation against the City of Phoenix. This requirement does not apply when a contractor or subcontractor is exempt under A.R.S. 23-901, AND when such contractor or subcontractor executes the appropriate sole proprietor waiver form. Technology Errors and Omissions Liability The policy must cover errors and omissions or negligent acts in the delivery of products, services, and/or licensed programs for those services as defined in the Scope of Work for this Contract. Each Claim $1,000,000 Annual Aggregate $1,000,000 In the event that the professional liability insurance required by this Contract is written on a claims-made basis, Contractor warrants that any retroactive date under the policy must precede the effective date of this Contract; and that either continuous coverage will be maintained or an extended discovery period will be exercised for a period of two (2) years beginning at the time work under this Contract is completed. Network Security and Privacy Liability The policy must cover but not be limited to 1) coverage for third party claims and losses with respect to network risks and invasion of privacy, 2) crisis management and identify theft response costs, 3) cyber extortion, 4) computer fraud coverage, and 5) funds transfer loss. Each Claim $1,000,000 Annual Aggregate $1,000,000 In the event that the network security and privacy liability insurance required by this Contract is written on a claims-made basis, Contractor warrants that any retroactive date under the policy must precede the effective date of this Contract; and that either continuous coverage will be maintained or an extended discovery period will be exercised for a period of two (2) years beginning at the time work under this Contract is completed.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 32 of 137

Media Liability (if the Contractor is involved in the production or publication of content) The policy must cover any and all errors and omissions or negligent acts in the production or publication of content, including but not limited to plagiarism, defamation, libel, slander, false advertising, invasion of privacy and infringement of copyright, title, slogan, trademark, service mark and trade dress Each Claim $1,000,000 Annual Aggregate $1,000,000 In the event that the media liability insurance required by this Contract is written on a claims-made basis, Contractor warrants that any retroactive date under the policy must precede the effective date of this Contract; and that either continuous coverage will be maintained or an extended discovery period will be exercised for a period of two (2) years beginning at the time work under this Contract is completed. ADDITIONAL INSURANCE REQUIREMENTS: The policies shall include, or shall be endorsed to include, the following provisions: On insurance policies where the City of Phoenix is named as an additional insured, the City shall be an additional insured to the full limits of liability purchased by the Contractor even if those limits of liability are in excess of those required by this Contract. Contractor’s insurance coverage shall be primary insurance and non-contributory with respect to all other available sources. NOTICE OF SUSPENSION OR CANCELLATION: For each insurance policy required by the insurance provisions of this Contract, Contractor must provide to the City, within two (2) business days of receipt, written notice that a policy is suspended, voided or cancelled for any reason. Such notice shall be mailed by U.S. Mail, certified return receipt, to City of Phoenix Finance Department, Purchasing Division, 251 W. Washington Street, Phoenix, Arizona 85003; or emailed to [email protected]. ACCEPTABILITY OF INSURERS: Insurance is to be placed with insurers duly licensed or authorized to do business in the state of Arizona and with an “A.M. Best” rating of not less than B+ VI. The City in no way warrants that the above-required minimum insurer rating is sufficient to protect Contractor from potential insurer insolvency. VERIFICATION OF COVERAGE: Contractor shall furnish the City with certificates of insurance (ACORD form or equivalent approved by the City) as required by this Contract. The certificates for each insurance policy are to be signed by a person authorized by that insurer to bind coverage on its behalf. All certificates and any required endorsements are to be received and approved by the City before work commences. Each insurance policy required by this Contract must be in effect at or prior to commencement of work under this Contract and remain in effect for the duration of the project. Failure to maintain the insurance policies as required by this Contract or to provide evidence of renewal is a material breach of contract.

mailto:[email protected]




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 33 of 137

All certificates required by this Contract shall be sent directly to City of Phoenix, Deputy Finance Director/Purchasing, 251 West Washington, Phoenix, Arizona 85003. The City Department, contract number and location description are to be noted on the certificate of insurance. The City reserves the right to require complete, certified copies of all insurance policies and endorsements required by this Contract at any time. DO NOT SEND CERTIFICATES OF INSURANCE TO THE CITY'S RISK MANAGEMENT DIVISION. APPROVAL: Any modification or variation from the insurance requirements in this Contract must have prior approval from the City’s Law Department, whose decision shall be final. Such action will not require a formal contract amendment, but may be made by administrative action.

4. SUSPENSION OF CONTRACT PERFORMANCE The City reserves the right to suspend performance on the Contract wholly, or in part, if it is deemed necessary in the best interests of the City. This suspension will be without compensation to the Contractor, its successors, and/or assigns other than compensation for completion/delivery requirements existing prior to the suspension and that have been satisfied.

5. INTERFERENCE OF CONTRACT PERFORMANCE Upon the occurrence of any condition that interferes with Contractor’s full performance of the Contract, Contractor shall immediately notify by telephone the City of Phoenix contact listed below. Further, Contractor shall confirm this notification in writing by US Mail, certified return receipt, within twenty-four (24) hours. Contact: The Deputy Chief of Technical Services for the City of Phoenix Fire Department.

6. CONTRACTOR'S PERFORMANCE Contractor shall furnish all necessary labor, tools, equipment, and supplies to perform the required services. The City will evaluate issues which may arise as to the quality and acceptability of any work performed under the Contract. If, in the City’s opinion, performance becomes unsatisfactory, the City shall seek assurance from Contractor of Contractor’s intent to perform and Contractor’s plan for corrective action. This contract provision does not alter or affect the Contract Termination provisions provided herein. The Contractor will correct any specific instances of unsatisfactory performance. In the event the unsatisfactory performance is not corrected within the time specified above, the City shall have the immediate right to complete the work to its satisfaction and shall deduct the cost to cover from any balances due or to become due the Contractor. Repeated incidences of unsatisfactory performance may result in cancellation of the Contract for default.

7. EMERGENCY SERVICE Emergency service is to be provided as described in the agreed upon Master Support Agreement

(MSA) to this Contract.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 34 of 137

8. SUBCONTRACTORS

Contractor may utilize subcontractors in the performance of this Contract, subject to City approval. Any subcontractor or subcontract used by Contractor with respect to performance under the Contract shall in no way relieve the Contractor of any responsibility for performance of all requirements under the Contract. Contractor shall not change or add any subcontractors, for the performance of Services under this Contract, without the advance written approval of the Deputy Finance Director. When requesting the City’s approval, the Contractor shall list all outgoing subcontractors, all new subcontractors, their contact information, their proposed responsibilities under the Contract as well as their qualifications to perform the intended work.

9. CONTRACT AND SUBCONTRACTOR WORKER BACKGROUND SCREENING Contractor agrees that all contract workers and subcontractors (collectively “Contract Worker(s)”) that Contractor furnishes to the City pursuant to this Agreement shall be subject to background and security checks and screening as set forth in this Paragraph 9 (collectively “Background Screening”) at Contractor’s sole cost and expense. The Background Screening provided by Contractor shall comply with all applicable laws, rules and regulations. Contractor further agrees that the Background Screening required in this Contract is necessary to preserve and protect public health, safety and welfare. The Background Screening requirements set forth herein are merely the minimum that are required for this Agreement. The City in no way warrants that these requirements are sufficient to protect Contractor from any liabilities that may arise out of Contractor’s performance under this Agreement and further, the City in no way warrants or indemnifies Contractor’s failure to comply with this paragraph. Therefore, in addition to the specific measures set forth below, Contractor and its Contract Workers shall take such other reasonable, prudent and necessary measures to further preserve and protect public health, safety and welfare when providing services under this Agreement. The City may, in its sole discretion, accept or reject any or all of the Contract Workers proposed by Contractor to perform work under this Agreement as well as those Contract Workers actually providing services during the term of this Agreement. The risk level and Background Screening required for this Agreement is “standard risk.” A standard risk Background Screening shall be performed when the Contract Worker’s work assignment will: (i) require a badge or key for access to City facilities; or (ii) allow any access to sensitive, confidential records, personal identifying information or restricted City information; or (iii) allow unescorted access to City facilities during normal and non-business hours. The standard risk Background Screening is applicable to the Contractor selected for this RFP.

The Background Screening for standard risk shall consist of the following: (a) the screening required by Arizona Revised Statutes § 41-4401 to verify legal Arizona worker

status (e-verify and verification of employment eligibility);

and

(b) a background check for real identity/legal name, and shall include felony and misdemeanor records from any county in the United States, the state of Arizona, plus any other jurisdiction where the Contract Worker has lived at any time in the preceding seven (7) years from the Contract Worker’s proposed date of hire;




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 35 of 137

CONTRACTOR CERTIFICATION By executing this Agreement, Contractor certifies and warrants that Contractor has read the Background Screening requirements and criteria in this Paragraph 9, understands them and that all Background Screening information furnished to the City is accurate and current. Also, by executing this Agreement, Contractor further certifies and warrants that Contractor has satisfied all such Background Screening requirements.

TERMS OF THIS SECTION APPLICABLE TO ALL OF CONTRACTOR’S CONTRACTS AND SUBCONTRACTS Contractor shall include the terms of this Paragraph 9 for Contract Worker Background Screening in all contracts and subcontracts for services furnished under this Agreement including, but not limited to, supervision and oversight services.

MATERIALITY OF BACKGROUND SCREENING REQUIREMENTS; INDEMNITY

The Background Screening requirements of this Paragraph 9 are material to City’s entry into this Agreement and any breach of this paragraph by Contractor shall be deemed a material breach of this Agreement. In addition to the indemnity provisions set forth in Section II, Paragraph 6.0, Risk of Loss and Liability, of this Agreement, Contractor shall defend, indemnify and hold harmless the City for any and all Claims (as defined in Section II, Paragraph 6.0) arising out of this Background Screening paragraph including, but not limited to, any claims relating to the disqualification of a Contract Worker by Contractor or the City for failure to satisfy this Paragraph 9.

CONTINUING DUTY; AUDIT

Contractor’s obligations and requirements that Contract Workers satisfy this Background Screening paragraph shall continue throughout the entire term of this Agreement. Contractor shall maintain all records and documents related to all Background Screenings and the City reserves the right to audit Contractor’s compliance with this Paragraph 9.

ACCESS CONTROLS, BADGE AND KEY ACCESS REQUIREMENTS A CONTRACT WORKER SHALL NOT BE ALLOWED TO BEGIN WORK IN ANY CITY FACILITY WITHOUT: (1) THE PRIOR COMPLETION AND CITY’S ACCEPTANCE OF THE REQUIRED BACKGROUND SCREENING; AND (2) WHEN REQUIRED, THE CONTRACT WORKER’S RECEIPT OF A CITY ISSUED BADGE. WHEN APPLICABLE, A BADGE WILL BE ISSUED TO A CONTRACT WORKER SOLELY FOR ACCESS TO THE CITY FACILITY(IES) TO WHICH THE CONTRACT WORKER IS ASSIGNED. EACH CONTRACT WORKER THAT ENTERS A CITY FACILITY MUST USE THE BADGE ISSUED TO THE CONTRACT WORKER. BADGE ACCESS PROCEDURES An authorized City of Phoenix badge application form is available at the City of Phoenix Badging Office, 251 W. Washington St., 2nd Floor, Phoenix, AZ 85003-1611. As applicable, each Contract Worker (as defined herein) who is furnishing Standard Risk (as defined herein) services under this Agreement shall submit to the City of Phoenix, Banking and Cashiering Division, 305 W. Washington Street, 1st Floor, Phoenix, AZ 85003-1611: (i) a fully completed and authorized City of Phoenix badge application form; (ii) a check in the initial badge fee amount listed below made payable to the “City of Phoenix”; and (iii) two forms of identification. One form of identification must be a government issued credential with an accompanying photograph. The second form identification must be a valid




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 36 of 137

passport; military issued identification card; immigration and naturalized services identification card; social security card; or an original birth certificate. After receipt of the badge application and payment, the Contract Worker will proceed to the badging office for processing of the badge application and issuance of the badge. The City will not process the badge application until the Contract Worker satisfies the required Background Screening (as defined herein). The Contract Worker shall comply with all requirements and furnish all requested information within five (5) business days from initial submission of the badge application or the subject Contract Worker’s badge application shall be rejected. KEY ACCESS PROCEDURES If the Contract Worker’s services require keyed access to enter a City facility(s), a separate key issue/return form must be completed and submitted by the Contractor for each key issued. The key issue/return form is available at City of Phoenix Badging Office, 251 W. Washington St., 2nd Floor, Phoenix, AZ 85003-1611 and the completed form shall be submitted to the badging office at the address above.

STOLEN OR LOST BADGES OR KEYS Contractor shall report lost or stolen badges or keys to their local police department and must obtain a police department report (PDR) prior to re-issuance of any lost or stolen badge or key. A new badge application or key issue form shall be completed and submitted along with payment of the applicable fee listed below prior to issuance of a new badge or key.

RETURN OF BADGE OR KEYS All badges and keys are the property of the City and must be returned to the City at the Badging Office within one (1) business day (excluding weekends and City holidays) of when a Contract Worker’s access to a City facility is no longer required to furnish the services under this Agreement. Contractor shall collect a Contract Worker’s badge and key(s) upon the termination of the Contract Worker’s employment; when the Contract Worker’s services are no longer required at the particular City facility(s); or upon termination, cancellation or expiration of this Agreement. CONTRACTOR’S DEFAULT; LIQUIDATED DAMAGES; RESERVATION OF REMEDIES FOR MATERIAL BREACH Contractor’s default shall include, but is not limited to, any of the following: (i) Contract Worker gains access to a City facility(s) without the proper badge or key; (ii) Contract Worker uses a badge or key of another to gain access to a City facility; (iii) Contract Worker commences services under this Agreement without the proper badge, key or Background Screening; (iv) Contract Worker or Contractor submits false information or negligently submits wrong information to the City to obtain a badge, key or applicable Background Screening; or (v) Contractor fails to collect and timely return Contract Worker’s badge or key upon termination of Contract Worker’s employment, reassignment of Contract Worker to another City facility or upon the expiration, cancellation or termination of this Agreement. Contractor acknowledges and agrees that the access control, badge and key requirements in this Contract are necessary to preserve and protect public health, safety and welfare and accordingly, Contractor agrees to properly cure any default within three (3) business days (excluding weekends and City holidays) from the date written notice of default is provided by the City. The Parties agree that Contractor’s failure to properly cure any described default shall constitute a breach of this Agreement. In addition to any other remedy available to the City at law or in equity,




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 37 of 137

the Contractor shall be liable for and shall pay to the City the sum of one thousand dollars ($1,000.00) for each breach for which Contractor has been provided notice. The Parties further agree that the sum fixed above is reasonable and approximates the actual or anticipated loss to the City at the time and making of this Agreement in the event of Contractor’s breach. Further, the Parties expressly acknowledge and agree to the fixed sum set forth above because of the difficulty of proving the City's actual damages in the event of Contractor’s breach. Moreover, the Parties further agree that three (3) breaches by Contractor arising out of any described default within a consecutive period of three (3) months, or three (3) breaches by Contractor arising out of the same default within a period of twelve (12) consecutive months shall constitute a material breach of this Agreement by Contractor and the City expressly reserves all of its rights, remedies and interests under this Agreement, at law and in equity including, but not limited to, termination of this Agreement. BADGE AND KEY FEES The following constitute the badge and key fees under this Agreement. The City reserves the right to amend these fees upon thirty (30) days prior written notice to Contractor. Initial Badge Fee: $55.00 per applicant Replacement Badge Fee: $55.00 per badge Lost/Stolen Badge Fee: $55.00 per badge Replacement Key Fee: $55.00 per key Lost/Stolen Key Fee: $55.00 per key Replacement Locks $55.00 per lock

10. STORAGE SPACE ONSITE

Contractor may store supplies, materials and equipment in a storage area on the City premises (in a location to be defined by the Phoenix Fire Department). Contractor agrees to keep its portion of this storage area in accordance with all applicable fire regulations. The use of City storage facilities will be on a space available basis and subject to the approval of the Fire Department. No materials or equipment will be stored or temporarily set in restrooms, under stairwells or other spaces accessible to the public. Any hazardous chemicals such as solvent based strippers and cleaners will not be stored on City property. If storage is in an electrical closet, a minimum of thirty-six (36) inches shall be provided in front of all electrical panels. The width shall be a minimum of thirty (30) inches or the width of the panel. The width of working space in front of the electrical equipment shall be the width of the equipment or thirty (30) inches, whichever is greater. In all cases, the work space shall permit at least a ninety (90) degree opening of equipment doors or hinged panels.

11. ACCEPTANCE TESTING

All material or service is subject to final inspection and acceptance by the City in accordance with the agreed upon Acceptance Test Plan in the Statement of Work.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 38 of 137

12. DISPUTE RESOLUTION

Contractor shall cooperate with the City to assure that all claims and controversies which arise during Contractor’s performance under this Contract will be resolved as expeditiously as possible in accordance with the following resolution procedure:

a. Any dispute between the City and Contractor arising prior to completion of Contractor’s performance or the earlier termination of the Contract shall be resolved, if possible, by the Designated Project Manager, or the Designated Project Manager’s designee, on behalf of the City and on behalf of Contractor.

b. If the Designated Project Manager, or the Designated Project Manager’s designee, and Contractor are unable to resolve any dispute within three (3) business days after notice of such dispute is given by either Party to the other, the matter shall be submitted to the City’s Chief Technology Officer and the superior to the Contractor’s Designated Project Manager, or the Designated Project Manager’s designee for resolution, if possible.

c. If the Parties fail to resolve any dispute(s), using the protocol provided above, either Party

reserves the right to litigate the dispute exclusively within the courts in Maricopa County, Arizona, under exclusive application of Arizona procedural and substantive law and notwithstanding Arizona Choice of Law rules.

13. DISCLOSURE OF LITIGATION OR FINANCIAL CONDITION

Contractor warrants and represents that there are no suits, actions, other proceedings, or reasonable anticipation of litigation in any judicial or quasi-judicial forum that will or may adversely affect Contractor’s ability to fulfill its obligations under this Contract. Contractor further warrants that it will immediately notify the City if, during the term of this Contract or any extension of this Contract, Contractor becomes aware of any lawsuits, actions or proceedings or has reasonable anticipation of litigation in any judicial or quasi-judicial forum that involve Contractor or any of Contractor’s subcontractors and that will or may adversely affect Contractor’s ability to fulfill its obligations under this Contract or any extension of the Contract.

14. FINAL INSPECTION AND APPROVAL

Final inspection and approval will be in accordance with the Acceptance Test Plan agreed to and provided in the Statement of Work.

15. INCORPORATION BY REFERENCE The Parties agree that Contractor’s response to this Solicitation/Request for Proposal is incorporated by reference and is a part of this Contract between the City and Contractor. This includes without limitation (a) the submitted and agreed upon License Agreement; (b) the submitted and agreed upon Source Code Escrow Agreement; (c) the submitted and agreed upon Software Maintenance and Support Agreements; and (d) all submitted and agreed upon warranties.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 39 of 137

16. SPECIFICATIONS

The specifications and/or drawings associated with this project are intended to generally describe a complete installation. Any additional materials or labor required for the complete project as intended shall be provided by the Contractor at no cost, whether or not it has been detailed in these documents.

SECTION IV - SCOPE OF WORK



Phoenix, AZ 85003 Phone: (602) 262-7181


Page 40 of 137

1. INTRODUCTION The City of Phoenix (the City) and the Phoenix Fire Department (PFD) seek to acquire a Computer Aided Dispatch (CAD) System and Records Management System (RMS) to support public safety dispatching operations for PFD and all participants of the Automatic Aid Consortium. The CAD/RMS system will be used to dispatch fire and medical units to 9-1-1 emergency Incidents, manage PFD resources, provide communications between multiple resources, and manage information related to PFD business operations and administrative functions. To complete this acquisition, PFD seeks a vendor that provides an effective and carefully structured approach to implement the CAD/RMS system. In this context, implementation refers to all efforts required to provide a complete and functioning system and will prepare Phoenix Fire and the Automatic Aid participants to use the system effectively. This includes technology and implementation planning, detailed design, software integration, designing and implementing software modifications, testing, training, conversion assistance, end user and technical documentation, project management, and post-implementation warranty support, and continued technical support and services. 1.1 PROJECT BACKGROUND Phoenix Fire operates the second largest 911 Public Safety Answering Point (PSAP) within the State of Arizona. PFD’s CAD system also serves as the system of record and accreditation reporting for the jurisdictions in the regional Automatic Aid Consortium. The current production CAD system and RMS was installed in 1994, and is running on an OpenVMS Operating System (OS). The OpenVMS operating system is reaching the end of its service lifetime, and support for this OS will be slowly phased out over the next few years. To keep pace with the growing demand for services the CAD system needs to be replaced to maintain service levels and meet response time standards established by the National Fire Protection Association (NFPA 1221). With these support limitations as the primary driver, Phoenix Fire desires to undertake a project investigating the feasibility, requirements, cost, and expected timeframe to modernize its current systems, and then integrating those systems into existing companion systems. 1.2 PROJECT MISSION The CAD/RMS Modernization Project is a vehicle to apply up to date technology to sustain the existing operational results that have made Phoenix one of the best and most respected Fire services in the country. Continuing the tradition of strategic use of technology in Fire operations, PFD will acquire, install and maintain a contemporary regional Fire/EMS dispatch, mobile, and records solution that ascribes to national standards and industry best practices, while strengthening PFD’s regional partnerships to further improve employee and public safety. 1.3 GOALS AND DESIRED OUTCOMES CAD System Goals and Outcomes The system should:

Meet the specified current CAD functional requirements for PFD, as outlined in the RFP.

Provide a high level of availability, security, and reliability.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 41 of 137

Provide a highly configurable CAD system to allow PFD to meet current and future needs without extensive software customization. This should optimize both the ability of the Vendor to provide long-term support and the ability of PFD to implement future upgrades and enhancements to the product.

Provide a high level of user satisfaction.

Position PFD to take advantage of technology to improve departmental performance and efficiency.

Allow easy access to the data for reporting and query generation and without the need for a programming specialist.

Facilitate bi-directional integration with the PFD-Record Management System (PFD-RMS) and other applications (such as City of Mesa Fire Department CAD).

RMS Goals and Outcomes The system should:

Support standardized reporting formats.

Provide centralized storage of data and allow retrieval from all levels of the department(s).

Provide a centralized training record management system for all departmental training and certifications.

The ability to track, maintain, and store transactional data related to Incidents.

Interface to systems required for PFD operations (e.g. Electronic Patient Care Reporting).

Provide inventory management tools.

Maintenance tracking and management tool for fire facilities and equipment.

Documentation and tracking of Fire Prevention activities: o Inspections o Hazardous Materials o Fire Protection Systems o Hydrants

Vendor related Goals and Outcomes Enter into a long-term business relationship with a CAD vendor that:

Has a history of successful implementation of comparable projects with agencies of similar size and complexity as the City of Phoenix and its Automatic Aid Consortium

Has a long-term commitment to the CAD business.

Has long-term viability as a company.

Has qualified and experienced project staff to assign to PFD’s project for the duration of the entire project.

Commits to long-term customer support on a 24 hours per day, 7 days per week basis.

Has a product enhancement strategy that factors in customer needs and wants.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 42 of 137

1.4 CURRENT ENVIRONMENT The Phoenix Fire Department Regional Dispatch Center (PFRDC) operates a Computer Aided Dispatch (CAD) system that provides dispatch and deployment services for 26 jurisdictions and 2 private ambulance companies.

2014 Key Metrics: Population served: 3.5 Million Area: 2500 square miles Phone Volume: 778,402 Incidents: 371, 049 Fire Stations: 100+ Responding Vehicles: 600+ Responders: 3500+ Support Staff: Approximately 700

The current Northrop Grumman CAD system was originally designed and programmed by PRC in 1986. It was upgraded to Hewlett Packard Integrity servers running OpenVMS v8.3 in 2007. In 2014, the servers were upgraded concurrent with the installation of OpenVMS v8.4. The supporting operating system, OpenVMS, and the application code base, written in ODDBOL (a proprietary, macro-enabled version of COBOL), were retained. The application uses a Storage Array Network (SAN), and additional servers to host key integrated dispatch applications. CAD uses bidirectional interfaces with MDC devices relying on a commercial cellular infrastructure, as well as with the City of Mesa Fire Department’s Intergraph CAD (via a CAD-to-CAD interface, enabling shared resource information, location information, and access to closest-unit dispatching recommendations). CAD exports Incident data to a File Transfer Protocol (FTP) site, accessible by external agency’s Fire RMS products (e.g Firehouse, etc). The CAD system is mission critical and must be available at all times. To accommodate component failure, or to allow routine maintenance, three clustered servers are connected to a Storage Array Network (SAN). The live CAD process can run on any individual server while one of the other servers runs a watchdog process designed to monitor the live CAD processes for unresponsive behavior. If detected, the secondary CAD will assume command of the live CAD processes without user intervention. The CAD system is configured in a Primary (AHQ)-Secondary (AHQ 2) site configuration. The sites are interconnected by a 20 Mbit/Sec network connection. Replication occurs periodically between the live CAD and the Disaster Recovery server located at AHQ 2. The secondary site is dependent on the primary site being operational to support some functionalities. The limited functionality of the secondary site is an identified weakness and incremental improvements are being made as funding becomes available to allow operation in absence of the primary site.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 43 of 137

1.4.1 DISPATCH CENTER ARCHITECTURE Conceptual Architecture

1.4.1.1 PHOENIX FIRE ALARM HEADQUARTERS (AHQ) The Northrop Grumman CAD system is installed in Fire Alarm Headquarters (AHQ) located at 150 South 12th Street, Phoenix. This site serves as the primary dispatch center. The Live and Backup CAD systems run on a Hewlett Packard Integrity platform. A third server acts as the DBS/RMS/Test server. The primary center is connected to 30 CAD workstations and has connection to 600+ MDCs via a connection to the commercial providers (e.g. Verizon, AT&T). The CAD system utilizes a road network calculation tool (Routeware) running on a separate server. When resource selection is being calculated by CAD, the system queries the Routeware server to determine the resources closest (time or distance) to the Incident. The CAD resource selection routine then selects the closest (time or distance) most appropriate resources for dispatch to the Incident. The CAD servers at AHQ are connected to a DEC (Digital Equipment Corporation) serial server to provide serial I/O interfaces to:




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 44 of 137

Bidirectional Interfaces USDD (US Digital Designs) Station Alerting - Interface to the station alerting system to notify stations of dispatches. The system turns on the lights and opens an audio path to the appropriate areas of the station based on the resource assigned. The system provides on-site generated automated voice alerting to minimize delays from voice dispatches from the dispatch center. Input Only ALI (Automatic Location Information) – provides an input of ALI information to the CAD system to locate the location of the 911 caller. Output Only Back Up Status System (BUSS) – the BUSS is a custom application that maintains the Unit (Resource) Status (US) of all resources on the CAD system. The BUSS provides a snapshot of the status of the entire system in the event of a CAD outage. The BUSS provides the dispatchers a means of maintaining system statuses while in a manual mode until CAD is restored. The BUSS can be run from a dispatcher console. PageGate from NotePage, Inc – Provides an interface to paging message servers for commercial alpha numeric paging services. Log (System Logs) – Messages logged from all the CAD environments are stored on a server. 1.4.1.2 AHQ 2 The secondary site Alarm Headquarters 2 (AHQ 2) is located at 2425 West Lower Buckeye Road. This site is the backup site for AHQ and provides access to CAD, RMS and all systems located at AHQ via a 20 Mbit/sec network connection. AHQ 2 is connected to 30+ workstations. A Disaster Recovery (DR) server located at AHQ 2 provides the ability to run another instance of the CAD system if AHQ were offline. CAD running on the DR server at AHQ 2 does not have the full functionality of the primary site. Incremental upgrades to the secondary site are scheduled to be completed by Phoenix Fire to provide full functionality, including but not limited to:

Direct connection to the commercial cellular providers for connectivity to the 600+ mobile clients.

Connectivity to all serial interfaces. Both centers are capable of receiving calls from the primary PSAPs of approximately 26 jurisdictions. Calls are answered and processed in AHQ or AHQ 2. The Incident processing is dependent on how the workflow is configured between the 2 centers and where the CAD software is running. 1.4.2 RMS The current RMS utilizes an Oracle 11g repository on an HP Integrity server running OpenVMS using the SAN drive infrastructure as CAD. It contains a history of incident, resource, personnel, premise, and hydrant data used to drive reporting, data sharing, providing business data for analysis via download and automated feeds. Data is accessed using Tri Fox SQL Reporting services with custom developed front end. There are a limited number of predefined reports and the core functions of the RMS do not support standardized reporting formats. Custom software solutions are utilized to interface to ePCR, ambulance billing and other systems required for fire business operations.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 45 of 137

1.4.3 GIS The CAD system uses GIS data that is maintained using ESRI (Environmental Systems Research Institute) tools by Phoenix Fire technical staff. There are conversion and release processes that propagates data to CAD and the mobile devices. The dispatch and mobile operations use GIS data for address verifications and spatial queries in real time to locate critical resources during incidents. Information from the Fire GIS group is shared with other City of Phoenix Departments (Police, Water Services) and any other agency or city through the main City of Phoenix GIS data source. Requests and updates from surrounding jurisdictions are maintained by Fire GIS. Data and aerials from other GIS sources (e.g. County Assessor’s Office, Maricopa County Flood District) are consumed by Fire. 1.5 FUTURE STATE The PFDRDC will have two centers operating in parallel to provide complete system redundancy. In addition the City of Mesa Fire Department CAD will be connected to the PFDRDC CAD system to provide a back-up to Mesa and possibly surge capacity for the Phoenix system. 1.5.1 Transition to Future State The first installation of the new CAD system will occur at the secondary site (AHQ 2). Operations on the new CAD system will be initiated at AHQ 2. The primary site (AHQ) will remain intact to provide back-up during the stabilization and tuning of the new system. The initial installation of servers, workstations, and other utilities at AHQ will demonstrate correct operation of a two site configuration. When PFD is confident of the stability of the new CAD system the primary site operating on the current CAD (AHQ) will be taken offline for rehabilitation (cabling, power, etc.). Upon completion of the rehabilitation, the remaining workstations at the primary site (AHQ) will be connected to the new CAD system. 1.6 COMPUTER AIDED DISPATCH SYSTEM BACKGROUND The Phoenix Fire Department operates a regional fire, emergency medical, and emergency medical transportation service dispatch center. All agencies dispatched by the Phoenix Fire Department Regional Dispatch Center (PFDRDC) are members of the Central Arizona Life Safety System Response Council (CALSSRC). The CALSSRC provides informal governance over dispatch policies at the strategic level. The CALSSRC’s Regional Operations Consistency Committee (ROCC) is charged with ensuring that jurisdictional dispatch policies are consistent with the goals of the region. Dispatch policies for PFDRDC are established by the Deployment Relationship by Objective (RBO) labor/management committee. This committee is co-chaired by an Assistant Fire Chief of the PFD’s Operations Division and the President of International Association of Fire Fighters Local 493. Each of the other jurisdictions for which the PFDRDC provides dispatch services has its own internal process for establishing dispatch policies within their jurisdiction. It is the goal of the PFDRDC to implement all dispatch policies via the CAD system. This helps to ensure that policies are followed consistently, improves the efficiency of dispatch operations, and allows dispatch personnel to focus their attention on more important tasks. The sections below describe workflow and system behaviors representing the current environment and are considered very important to the PFDRDC.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 46 of 137

1.6.1 WORKFLOW

High Level Workflow

For efficiency and ease of management when dealing with a high volume of Incidents the PFDRDC requires a CAD system that can divide the work load associated with each Incident among several roles known as dispatch functions as defined by the PFDRDC. The PFDRDC’s current dispatch functions are: Call Takers, Decision Dispatcher (DD), Tactical Radio Operator (TRO), Inbound Service Representative (ISR), Outbound Service Representative (OSR), Private Ambulance Provider Representative (PAPR), Customer Service Representative (CSR), Lead Dispatchers (LEAD), and Supervisors (SUPV). A typical Incident will route from Call Taker to Decision Dispatcher to Tactical Radio Operator. All of these functions are described in the workflow management descriptions found in SECTION IV.3.1 PHOENIX FIRE SPECIFIC FUNCTIONALITY - COMPUTER AIDED DISPATCH (CAD) and ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET. 1.6.2 CALL TAKING A PFDRDC call taker receives emergency and non-emergency requests for assistance from various sources such as the E-911 phone system, external agencies like Police Departments and even other Fire Departments, sometimes Incidents are received through non-emergency phone lines or radio communications from first responders in the field. A CAD system Incident entry form shall be designed to handle all possible call entry scenarios. Generally, only two pieces of information are required to generate an Incident in the CAD system. The location and the call type or nature of the emergency. However there is a need in many cases to gather supplemental information from the caller such as a call back number or a caller’s current location, which may be different than the location of the emergency, or gather specific instructions to send to first responders like “meet person at front gate”. Sometimes the call taker needs to indicate when a resource or multiple resources are currently responding or resources are already on scene of an emergency. Besides the need to transfer E911 information into the call takers entry form, there is a need to transfer cell phone coordinates from the E-911 system into CAD so those coordinates may be transmitted to the first responder’s mobile devices. The cell phone coordinates can additionally be used to validate the location of the emergency entered, by alerting the call taker when the distance between the address entered and the caller cell coordinates are greater than a configurable delta distance.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 47 of 137

The call taker’s main responsibility is to enter Incidents along with all important and relevant information gathered from the caller into the CAD system. Once enough additional information has been gathered, as determined by call taker, the Incident shall be submitted for dispatch. The PFDRDC requires an EMD/EFD protocol solution that conforms to the behaviors described in the EMD/EFD requirements section. Typically an Incident entered by the call taker will route to the appropriate decision dispatcher’s queue. 1.6.3 DECISION DISPATCHER (DD) Incidents entered either by a call taker or entered by any other means that require a Fire Department resource to be dispatched shall be routed to the decision dispatcher’s dispatch queue unless the call type for the Incident is configured for automatic dispatch (e.g. drowning call types are configured for automatic dispatch). All subsequent requests (e.g. Special Calls, Balance of Assignment, etc.) requiring additional Fire Department resources on any Incident shall be routed to the Decision Dispatcher. The Decision Dispatcher is responsible for fulfilling that request. The decision dispatcher selects Incidents that are routed to its dispatch queue. Once selected by the Decision Dispatcher, the CAD system assigns the appropriate tactical radio channel (if not already assigned) to the Incident based on call type and location, automatically suggests resources based on pre-built response plans (for initial dispatches and balance of assignments), and displays those suggested resources along with resources that were bypassed (e.g. bypassed resources are unavailable resources that would have been suggested if they were available). The Decision Dispatcher reviews the selection and must have the ability to modify the suggestion and the assigned tactical radio channel before dispatching. The Decision Dispatcher is typically responsible for the voice announcement of each dispatch. The voice announcement can be done either by the Decision Dispatcher or by the synthesized voice announcing system. Once the Decision Dispatcher submits the resource suggestion for dispatch, CAD shall send a dispatch message to MDCs and alert stations for all Fire Department resources in the suggestion list. CAD interfaces to a station alerting system that provides a positive or negative acknowledgement when CAD attempts to alert stations. CAD shall indicate to the Decision Dispatcher when a station fails to acknowledge a dispatch. All Incidents requiring any resource must be assigned to a tactical radio channel (done automatically by CAD). The assignment of the tactical radio channel by CAD must occur before resources are assigned or dispatched. After the Incident is dispatched by the Decision Dispatcher CAD shall route the Incident to the Tactical Radio Operator assigned to work the tactical radio channel assigned to the Incident. 1.6.4 TACTICAL RADIO OPERATOR (TRO) A tactical radio operator is responsible for any Incident that is assigned to a tactical radio channel controlled by the TRO’s workstation. When a TRO signs on to a CAD workstation the TRO can query for tactical radio channels assigned to their workstation, or if desired, assign tactical radio channels to their workstation.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 48 of 137

The TRO manages the Incident from initial dispatch to Incident closure. The CAD system is required to assist the TRO in managing resources, responding and onscene, of an Incident. Additionally, the TRO documents significant events on an Incident and requests additional resources as they are needed on an Incident. Requests for additional resources are routed by CAD to either the Decision Dispatcher (DD), Outbound Service Representative (OSR) or the Private Ambulance Provider Representative (PAPR) depending on the type of resource requested. 1.6.5 OUTBOUND SERVICE REPRESENTATIVE (OSR) The OSR function is a radio support position responsible for initiating outbound requests for services from outside agencies not directly dispatched by the CAD system (e.g. utility companies, taxis, some private ambulance companies, helicopters, police departments, etc). These agencies provide a service on many Incidents and need to be tracked. Since these resources are not directly dispatched by the CAD system and with a need to minimize workload on the TRO and the decision dispatcher, requests for these resources are routed to the OSR function. 1.6.6 PRIVATE AMBULANCE PROVIDER REPRESENTATIVE (PAPR) The Private Ambulance Provider Representative is a unique function assigned to a PFDRDC CAD workstation located at a remote dispatch center. Private ambulance requests assigned to this private ambulance dispatch agency are routed to the PAPR workstation. Personnel use this workstation to manage private ambulance requests and indicate what resource has been dispatched to fulfill the request. When a request for an ambulance has been made, the CAD system must correctly determine the appropriate ambulance provider based on the Incident location. If CAD determines that the suggested ambulance is dispatched by a private ambulance company configured with a PAPR workstation, CAD will route the request to the PAPR workstation. 1.6.7 Mobile Data Computer (MDC) The Mobile Data Computer (MDC) allows Fire Department resources to maintain their current status, manage their roster, receive dispatch information, and communicate electronically with dispatch center personnel and other resources. Additionally, the MDC provides automatic vehicle location information to CAD and helps first responders navigate to a CFS. The MDC allows first responders to query CAD for relevant information about a CFS or query CAD for details and background information such as CFS history, premise information, and select RMS information pertinent to the current CFS. Company and command officers use the MDC to maintain situational awareness and manage resource assignments while on a CFS. The Command Officer Functionality found in the SECTION IV 3.1.5 Incident Resource Management and ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET File Number F.4.0 Command Officer Functionality is a description of the situational awareness and resource management desired by the company and command officers. 1.6.8 Configuration and Administrative Team The PFDRDC has a CAD administration team that manages the ever changing dispatch policies, resource/vehicle configurations, fire station additions, dispatch warnings and alerts, EMD/EFD protocols, system timers, call types, application security, hospital information, radio identifiers and all rotation lists. In addition, the team looks after any




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 49 of 137

geographical changes to response areas managed by the GIS team. The CAD team is involved in all aspects of the system to insure proper functionality and performance. The PFDRDC requires a CAD solution with a highly configurable resource suggestion/response plan program that will meet the dispatch policy needs of all jurisdictions dispatched by the PFDRDC as described in SECTION IV 3.1.3 Resource Suggestion Program and ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET File Number B.8.04 Resource Suggestion. The PFDRDC requires a CAD solution that provides a high degree of resource configuration. A resource in the CAD system must contain many attributes to distinctively describe, define capabilities and behaviors for a resource. Most importantly these attributes are used by the CAD’s resource suggestion algorithm. Attribute requirements for resources are fully described in ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET File Number B.8.10 Managing Resources and File Number B.8.11 Special Resource Configurations. It is important to note that resources requested by the TRO or resources suggested by the resource suggestion program are routed to the proper dispatch workstation (e.g. decision dispatcher, OSR, PAPR, etc.) based on a resource attribute. Other important configuration and administration requirements found in ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET

File Number B.8.02 Dispatch Warnings and Pager Notifications

File Number B.8.07 Cross Staffing Configurations and Behaviors

File Number B.8.08 Managing Hospitals

File Number B.8.09 Managing Call types

File Number B.8.12 Managing Vehicles

File Number B.8.13 Standard Data for any Geographical Area

File Number B.8.15 Managing Dispatch Functions

File Number B.8.16 Shift Calendars by Jurisdiction 1.7 RECORDS MANAGEMENT SYSTEM BACKGROUND In this RFP, the PFD has specified the requirements for the features that are desired for the PFD’s Fire RMS. This system has been broken down into 5 functional areas. The following sections will provide a brief overview and background of each of those functional areas. Please refer to ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET TAB D – FIRE RMS and TAB E – FIRE RMS SYS ADMIN for detailed requirements. 1.7.1 TRAINING PFD has the need to track and maintain the records of all training provided and acquired by its members. These records will include the classes taken by PFD members as well as any certifications and special skills such as paramedic, EMT, technical rescue, hazardous materials, languages, driver’s training, FAA certifications (aviation), that have been acquired by the member. When applicable these training records should include any evaluations that are done through the process of completing the training. Currently, PFD uses multiple training records management systems and data stores. Some of these are “home grown” and some are vendor supplied. The Proposed Solution should become the complete “one stop shop” for all training records, certifications, and skill documentation. These training records will need to be completed, maintained, and reported on in conjunction with the City of Phoenix records retention guidelines and federal mandated requirements such as NFPA and OSHA.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 50 of 137

1.7.2 INCIDENT REPORTING The Incident Reporting requirements for PFD are broken up into two areas. The first is the ability to track and maintain the transactional data about an incident from the CAD System. This is the primary function that the current Fire RMS provides. The Proposed Solution will need to provide a permanent data store and reporting capabilities on the dispatch data. This includes, but is not limited to call location, call type or nature, call times, resources involved, and personnel involved. PFD also has a need to provide final disposition reports for all incidents in which the department has responded. These incidents reports should encompass all incident categories: Fire, EMS, Hazardous Material, Technical Rescue and non-emergent Service Calls. There are several reporting standards that apply to incident reporting that should be followed. These include but are not limited to: NFIRS, NEMSIS, and AZ-PIERS. The Proposed Solution needs to provide a mechanism for filling out these reports and storing them for future review and analysis. This reporting system needs to be easy to use for the first responder and should be available from the MDCs in the fire apparatus so that the reports can be complete as soon as the crew has finished their work on the incident. 1.7.3 PHYSICAL RESOURCES PFD has the need to track and maintain records about the Physical Resources that are used by the department. This would include tracking of fire facilities, fire apparatus, and any equipment assigned to and used by PFD personnel. Currently, PFD has an existing system that is used for facility and work order tracking. The Proposed Solution should integrate with that system so that the Fire RMS has some basic information about the Fire facilities for the purpose of it being related to other RMS information. The City of Phoenix has a fleet management system that tracks and maintains information about all City vehicles. It is PFD’s desire to load data from that system into the Fire RMS and track PFD specific information in the Proposed Solution. PFD would want this to include the ability to track collisions and damage as it relates to PFD vehicles. PFD equipment is tracked in various sources. The Proposed Solution should be able to track and maintain information about all PFD equipment, this includes but is not limited to: all protective equipment, technology, and tools issued to PFD members, resources, or stations. This information is not currently tracked in a system. The City currently tracks warehouse inventory and PFD related commodities in SAP. We anticipate the continued use of SAP for this inventory in the foreseeable future. 1.7.4. PERSONNEL PFD needs to track personnel, staffing, and roster data about its members. The City of Phoenix currently uses PeopleSoft to track personnel data and PFD uses TeleStaff for staffing and scheduling. The Proposed Solution should be able to have information from these systems populate the basic information about PFD members and their schedules. The Proposed CAD System roster information should come across to the RMS and be linked to the personnel records so that a complete summary of all the incidents that a member has responded to can be obtained. The Proposed Solution should also be able to track and tie Exposure records, Near Miss records, Injuries, and Citizen Complaints to the Personnel and Incident data in the Fire RMS System. The Proposed Solution should also utilize this Fire specific personnel data to track training records and also be utilized for the issue and assignment of protective equipment. 1.7.5 FIRE PREVENTION PFD takes part in many fire prevention and fire protection activities. Fire Prevention is the inspection, education and enforcement division of PFD providing life safety services through code enforcement and inspections during the new business development process, general fire inspections, operating and special use permitting and complaint investigation. These activities include the documentation of: premise inspections, Permits, Fire Protection Systems, Hazardous Materials, Fire Alarms, and Hydrants. The Proposed Solution should allow for




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 51 of 137

the documentation and tracking of these Fire Prevention activities. This should include the ability to provide specific information about a premise to the Proposed CAD System so that first responders have the best possible information about the premise to which they respond. 2. RESPONSE REQUIREMENTS The only mandatory requirements for this RFP are listed in section IV SCOPE OF WORK subsection 2.1 MANDATORY REQUIREMENTS. There are no functional criteria that are considered “mandatory.” The full list is intended to determine the overall capabilities of the Proposed Solution, both in the current environment and in anticipating future requirements. 2.1 MANDATORY REQUIREMENTS The following two requirements are mandatory. Vendors that do not provide the requested information, or do not comply with all of the mandatory requirements, shall be deemed non-responsive. Please affirm all of the following along with providing the requested information in the response section identified for each requirement:

a) The Vendor shall have completed, in the past eight (8) years, the installation of one or more integrated Fire/EMS Department CAD and RMS solutions in a regional dispatch system. Vendor shall provide contact information for PFD’s use to comply with this requirement as requested in section IV SCOPE OF WORK subsection 9 QUALIFICATIONS AND EXPERIENCE item 9.1.1 Experience with Similar Sized Initiatives, Response ID 4.901.01.

b) Vendor shall have been in operation a minimum of ten years. The Vendor’s normal business activity

during the past five years will have entailed providing the scope of work listed in this solicitation. Vendor shall provide details demonstrating compliance with this requirement as requested in section IV SCOPE OF WORK subsection 9 QUALIFICATIONS AND EXPERIENCE item 9.1.3 Date Established.

2.2 INSTRUCTIONS Section IV SCOPE OF WORK contains the functional, technical, project, team, and other requirements for the PFD CAD/RMS Modernization project. Responses to requirements in this section will be used to score RFP responses for the Functional, Implementation, and References and Qualifications areas. 2.2.1 FUNCTIONAL AND TECHNICAL REQUIREMENTS Submittal Tab 1 must contain the fully completed responses to the functional and technical system requirements, located in ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET. The responses must be filled in using the provided Microsoft Excel workbook (provided on a portable-drive to attendees at the mandatory pre-proposal conference). Offerors must submit their responses to ATTACHMENT A in both printed and electronic formats. The electronic submission must be provided on the portable-drive given to the Offeror during the mandatory pre-proposal conference, using the provided Microsoft Excel workbook. In the event of a discrepancy between the two, the printed copy will take precedence. Please use the material presented in section IV SCOPE OF WORK subsection 1 INTRODUCTION as background information for the requirements in the FUNCTIONAL REQUIREMENTS WORKSHEET. These areas list functional and/or technical requirements for each of the required or desired, if so specified, software components: Computer Aided Dispatch; Fire Records Management which includes Incident Reporting (including NFIRS requirements), Personnel Data Management, Premise Data Management, Fire Prevention, and Training; Mobile Computer Terminal (MCT); Automatic Vehicle Locator (AVL); Geographical Information Systems




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 52 of 137

(GIS); and General Requirements common to multiple solution components. Also listed are specific interface requirements; multiple enterprise system interfaces; technical platform requirements including security, performance, and other non-functional requirements; and operational data requirements. Electronic copies of the spreadsheets are included with this RFP. Vendors must electronically provide detailed, function by function compliancy responses using the electronic spreadsheets, and also include a hard copy of their responses in their printed proposal. The Vendor shall indicate in the spreadsheets whether the functions exist in the current version of their product in the “Vendor Response” column. Drop-down boxes are provided to facilitate completion of the form. If so indicated in the spreadsheet, a description of the methodology for applying the functionality shall also be provided as a clarification in the space provided. For each item, enter one of the following values according to the offer being made.

Vendor Response Codes

Definition

A

Existing: The requirement will be met by proposed existing software that is installed and operational at other sites. An “A” response to any requirement signifies that the proposed system meets the requirement in a seamless manner. Indirect or implied solutions will not be coded “A”, nor will functionality that is a configuration option for the client.

B Configuration: Requirement will be met by configuring existing software and the configuration is included in the Proposed Solution. All configuration work specified under this response code must be fulfilled entirely by the vendor during the project.

C

Future Version: Requirement will be met by software that is currently under development or in beta testing. Vendors must agree to have the developmental functionality in productive use in another client site for at least six (6) months prior to installing the product in the PFD environment. All requirements marked by this code must be provided to PFD no later than the beginning of the functional testing period for the product.

D Third Party: Requirements will be met by the use of proposed software tools, such as a report writer, query language or spreadsheet, etc.

E Customization: Requirement will be met by major modifications to existing software or by new custom software programming.

F Not Available: Requirement cannot, and will not, be provided.

Clarifications regarding the numbered requirements specified in ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET must cite the specific Tab and File Number of the function being clarified. Note that any “Exceptions” taken for numbered requirements that have been asserted to be an available function will generally negate a "Function Available" statement, as indicated by the selection of Response Codes A through E, causing the requirement to be deemed non-compliant, but this does not necessarily mean the proposal will be rejected. When option E is selected, a price for delivering the customization must be provided in the Customization Costs tab of ATTACHMENT B - Cost Workbook. For line items that are NOT included in a feature as referenced section IV subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS (as identified by the presence of an RFP SECTION NUMBER in the line item), a separate price is required for each item that will be customized. The File Number from the line item in the Excel workbook for each line item with an “E” response must be included in the pricing worksheet. Each line should list the expense that the City should expect to pay in addition to the quoted prices in the other tabs of the Cost Workbook. Prices should include labor, licenses, travel, hardware, and any




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 53 of 137

other costs that will be incurred to deliver the customization. A cost for annual maintenance for each line item must be provided. 2.2.2 PHOENIX FIRE SPECIFIC CAD & RMS FUNCTIONAL REQUIREMENTS Submittal Tab 1 must also contain responses to all sections in section IV - SCOPE OF WORK subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS. Each subsection contains introductory information to be used for reference when producing responses. The introductory material is followed by a table with questions or statements of requirements. The introductory material should not be included in the response. Vendors should include only the tables from section IV subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS in their response. Each item in the tables requires a narrative response as described below. Please use the material presented in section IV SCOPE OF WORK subsection 1 INTRODUCTION as background information for the requirements in subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS. Introductory material in this subsection may include a table with a copy of the requirements from ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET that apply to the subject matter of each subsection. When applicable, requirements from ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET have been copied into an area of section IV subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS. These are cross referenced in the ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET under the RFP SECTION column for each of the copied requirements. This area includes requirements related to Special Dispatcher Routing; Tactical Radio Operator (TRO) Channel Assignment; Outbound Service Representative (OSR); Private Ambulance Provider Representative (PAPR); Emergency Medical Dispatch/Emergency Fire Dispatch (EMS/EFD) Protocols; Resource Suggestion Program; Roster Functionality; Incident Resource Management; Additional CAD Efficiencies; RMS CAD Data; NFIRS Reporting; Exposure Reporting; Hydrant Information Management; Premise Information Management; Protective Equipment Information Management; Training and Certification Information; and Additional RMS Efficiencies. For each item that is a statement of a requirement, Vendors must respond in the Vendor Response/Comments column with a narrative description of how the Proposed Solution (software, hardware, and/or services) meets (or does not meet) the requirement. For each requirement worded as a question, a narrative response is required in the Vendor Response/Comments column addressing the subject matter of the question. It should be noted that some questions include examples of the types of content that could be included in the response. These examples are NOT specific requirements, but are designed to illustrate the intention of the question. Clarifications regarding the numbered requirements specified in section IV subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS must cite the specific Response ID of the item being clarified. If option E is selected in the Functional and Technical Requirements workbook for any single requirement listed section IV subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS (as identified by the presence of an RFP SECTION NUMBER in the line item in the workbook), a price for the customization of the entire feature from section IV subsection 3 FUNCTIONAL AND TECHNICAL REQUIREMENTS must be provided in the Customization Costs tab of ATTACHMENT B - Cost Workbook. The RFP Section Number that is associated with the line item having an “E” response must be included. In this case, one price can be provided for the entire set of functionality as defined by the RFP section where the requirement is listed. It is not necessary to detail each File Number in the pricing worksheet. Each line should list the expense that the City should expect to pay in




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 54 of 137

addition to the quoted prices in the other tabs of the Cost Workbook. Prices should include labor, licenses, travel, hardware, and any other costs that will be incurred to deliver the customization. A cost for annual maintenance for each line item must be provided. Vendors should keep the following in mind when producing responses.

Provide responses to each requirement within the table column format.

Please do not include responses that contain a reference to the answer to another question or other documents as the sole response. Each question should have a narrative response included.

Include any additional information that may be helpful, either following the tables or in one of the tabs of the submittal. References to Internet documents without a copy of the document included in the RFP response will be disregarded.

2.2.3 SYSTEM ARCHITECTURE AND TECHNICAL DESIGN Submittal Tab 2 must contain responses to all sections in section IV - SCOPE OF WORK subsection 4 SYSTEM ARCHITECTURE AND TECHNICAL DESIGN. Each subsection contains introductory information to be used for reference when producing responses. The introductory material is followed by a table with questions or statements of requirements. The introductory material should not be included in the response. Vendors should include only the tables from Section IV subsection 4 SYSTEM ARCHITECTURE AND TECHNICAL DESIGN in their response. Each item in the tables requires a narrative response and may also require a response code. This area includes requirements related to the Sever Solution; Security Requirements; High Availability, Business Continuity, and Disaster Recovery; Database Software; Desktop and Connectivity; and Industry Standards. The tables in this section contain a column for a coded Vendor Response, plus a Comment column for a narrative response. Some items do not require a value to be entered in the Vendor Response column. These items are marked “Do Not Rate” in the Vendor Response column. This designation refers to the Vendor Response column only. A narrative response is still required in the Comments column for these requirements. For each item that requires a Vendor Response code, enter one of the following values according to the offer being made.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 55 of 137


Definition

A



C





Note that any “Exceptions” taken for numbered requirements that have been asserted to be an available function will generally negate a "Function Available" statement, as indicated by the selection of Response Codes A through E, causing the requirement to be deemed non-compliant, but this does not necessarily mean the proposal will be rejected. If option E is selected for any single requirement listed Section IV subsection 4 SYSTEM ARCHITECTURE AND TECHNICAL DESIGN, a separate price is required for each item that will be customized. The Response ID for each item having an “E” response must be included in the Customization Costs tab of ATTACHMENT B - Cost Workbook. Each line should list the expense that the City should expect to pay in addition to the quoted prices in the other tabs of the Cost Workbook. Prices should include labor, licenses, travel, hardware, and any other costs that will be incurred to implement the customization. A cost for annual maintenance for each line item must be provided. Independent of the Response Code column, each item in the tables requires a narrative response in the Comments column as described below. For each item that is a statement of a requirement, Vendors must respond in the Comments column with a narrative description of how the Proposed Solution (software, hardware, and/or services) meets (or does not meet) the requirement. For each requirement worded as a question, a narrative response is required in the Comments column addressing the subject matter of the question. It should be noted that some questions include examples of the types of content that could be included in the response. These examples are NOT specific requirements, but are designed to illustrate the intention of the question.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 56 of 137

Clarifications regarding the numbered requirements in Section IV.4 - SYSTEM ARCHITECTURE AND TECHNICAL DESIGN must cite the specific Response ID of the item being clarified. Vendors should keep the following in mind when producing responses.




2.2.4 TECHNICAL INTERFACES Submittal Tab 2 must also contain the fully completed responses to the Technical Interface Requirements, located in ATTACHMENT C – TECHNICAL INTERFACES LISTING. The responses must be filled in using the provided Microsoft Excel workbook (provided on a portable-drive to attendees at the mandatory pre-proposal conference). Offerors must submit their responses to ATTACHMENT C in both printed and electronic formats. The electronic submission must be provided on the portable-drive given to the Offeror during the mandatory pre-proposal conference, using the provided Microsoft Excel workbook. In the event of a discrepancy between the two, the printed copy will take precedence. These areas list functional and/or technical requirements for each of the required or desired, if so specified, software components: CAD Interfaces (27 items) and RMS Interfaces (19 items). Electronic copies of the spreadsheets are included with this RFP. Vendors must electronically provide detailed, function by function compliancy responses using the electronic spreadsheets, and also include a hard copy of their responses in their printed proposal. The Vendor shall indicate in the spreadsheets whether the functions exist in the current version of their product in the “Vendor Response” column. Drop-down boxes are provided to facilitate completion of the form. If so indicated in the spreadsheet, a description of the methodology for applying the functionality shall also be provided as a clarification in the space provided. For each item, enter one of the following values according to the offer being made.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 57 of 137


Definition

A



C





Clarifications regarding the numbered requirements specified in ATTACHMENT C – TECHNICAL INTERFACES LISTING and must cite the specific Tab and File Number of the function being clarified. Note that any “Exceptions” taken for numbered requirements that have been asserted to be an available function will generally negate a "Function Available" statement, as indicated by the selection of Response Codes A through E, causing the requirement to be deemed non-compliant, but this does not necessarily mean the proposal will be rejected. If option E is selected for any single requirement listed ATTACHMENT C – TECHNICAL INTERFACES LISTING, a separate price is required for each item that will be customized. The ITF# for each item having an “E” response must be included in the Customization Costs tab of ATTACHMENT B - Cost Workbook. Each line should list the expense that the City should expect to pay in addition to the quoted prices in the other tabs of the Cost Workbook. Prices should include labor, licenses, travel, hardware, and any other costs that will be incurred to implement the customization. A cost for annual maintenance for each line item must be provided. 2.2.5 IMPLEMENTATION AND SUPPORT Submittal Tab 3 must contain responses to all sections in section IV SCOPE OF WORK subsections 5 through 8 inclusive. Each subsection contains introductory materials that is to be used for reference when producing responses. The introductory material is followed by a table with questions or statements of requirements. The introductory material should not be included in the response. Vendors should include only the tables from Section IV subsections 5 through 8 in their response. Each item in the tables requires a narrative response. This area includes requirements related to Product Interfaces; Data Conversion; Implementation including Project Management, Product Configuration, Product Engineering, Product Testing, Product Installation, Post Installation Support, and Final System Acceptance; Ongoing Support; Training; and Documentation.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 58 of 137

For each item that is a statement of a requirement, Vendors must respond in the Vendor Response/Comments column with a narrative description of how the Proposed Solution (software, hardware, and/or services) meets (or does not meet) the requirement. For each requirement worded as a question, a narrative response is required in the Vendor Response/Comments column addressing the subject matter of the question. It should be noted that some questions include examples of the types of content that could be included in the response. These examples are NOT specific requirements, but are designed to illustrate the intention of the question. Vendors should keep the following in mind when producing responses.




2.2.6 QUALIFICATIONS AND EXPERIENCE Submittal Tab 4 must contain responses to all sections in section IV SCOPE OF WORK subsection 9. Each subsection may contain introductory materials that is to be used for reference when producing responses. Introductory material should not be included in the response. Vendors should include only the responses to requirements from subsection 9 Qualifications and Experience in their response. Introductory material may be followed by a table with questions or statements of requirements. Alternatively, the subsection may simply contain statements of requirements, a description of materials to be provided, or a listing of detailed information that the Vendor should provide in their response. This area includes requirements related to the Vendor Organization; Experience with Similar Projects; the Project Team and Key Resources; expectations of Vendor team roles, responsibilities, and availability; Transition Policies and Plans; and the types of References that should be included in the response. Subsection 9.5 requires a listing of Vendor References. The requirements in this subsection are intended to inform the Vendor of the desired characteristics of the references provided. The listing of references should be included in Submittal Tab 6 – REFERENCES using the list of characteristics from subsection 9.5 as a guideline. For the remaining requirements, each item that is a statement of a requirement, Vendors must respond in the Vendor Response/Comments column or in plain text with a narrative description of how the Proposed Solution (software, hardware, and/or services) meets (or does not meet) the requirement. For each requirement worded as a question, a narrative response is required in the Vendor Response/Comments column or in plain text addressing the subject matter of the question. It should be noted that some questions include examples of the types of content that could be included in the response. These examples are NOT specific requirements, but are designed to illustrate the intention of the question.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 59 of 137

Vendors should keep the following in mind when producing responses.

Provide responses to each requirement within the table column format or in plain text identified with the requirement subsection number.


Include any additional information that you feel may be helpful to us, either following the tables or in one of the tabs of the submittal. References to internet documents without a copy of the document included in the RFP response will be disregarded.

2.3 GLOSSARY OF FUNCTIONAL AND TECHNICAL TERMS

Glossary of Functional and Technical Terms

Acronym/Term Definition

12-Lead EKG See EKG.

ACD See Automatic Call Distribution.

Advanced Life Support (ALS)

A capability assigned to a team of highly trained individuals providing advanced medical help to patients in transit when needed. An Advanced Life Support team is typically composed of two paramedics (EMT-P) and one or more Emergency Medical Technicians (EMT-B).

Advised Incidents An Incident created just for documentation purposes. It isn’t routed to a decision dispatcher, no resources are assigned to it, and it is instantly closed.

AES See Automatic Extinguishing System.

Agency The provider of a particular service (e.g. fire, medical, etc.) for a jurisdiction.

Alarm Room Another description of the regional dispatch center location and/or dispatchers contained therein.

ALI See Automatic Location Identification.

ALS See Advanced Life Support.

Analog Simplex The type of radio system used by the Automatic Aid Consortium to communicate on Hazard Zone Incidents. The radio system is analog (as opposed to digital) and simplex (only one transmitter can be transmitting at a time).

ANI See Automatic Number Identification.

AOI See Available On Incident.

Automatic Aid Occurs when resources respond to Incidents without regard to jurisdictional boundaries.

Automatic Aid Consortium

The group of fire departments that are dispatched by PFD and respond to Incidents without regard to jurisdictional boundaries (Automatic Aid). It should be noted that there are members of this group who are not fully Automatic Aid. They provide and receive assistance with some members automatically, but with others it is only after an approval process has been completed (Mutual Aid).

Automatic Call Distribution (ACD)

A system that distributes incoming calls to a group of call takers. In an E911 emergency call center ACDs route incoming 911 calls to the first available call taker with the longest idle time.

Automatic Dispatch Occurs when an Incident is created that is configured to bypass normal Decision Dispatcher processes (select/review/dispatch). CAD determines the appropriate resources without review and immediately dispatches them.

Automatic Extinguishing System

Automatic fire suppression systems control and extinguish fires without human intervention. Examples of automatic systems include fire sprinkler system, gaseous fire suppression, and condensed aerosol fire suppression.

Automatic Location Identification (ALI)

A 911 enhanced electronic location system which automatically relays a caller's address when they call an emergency responder service such as 911, whether they call from a mobile phone or a land line.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 60 of 137


Automatic Number Identification (ANI)

A 911 function that provides the receiver of a telephone call with the number of the calling phone.

Automatic Vehicle Location (AVL)

Refers to a fleet of vehicles reporting their location to a central system, in this case a Computer Aided Dispatch system. The main purpose for real-time AVL reporting is so that the CAD system can recommend the closest most appropriate resource to an emergency event.

Available On Incident (AOI)

A term for a resource currently assigned to an incident that is available for dispatch to a higher priority Incident.

AVL See Automatic Vehicle Location.

AZ-PIERS See Arizona Pre-Hospital & EMS Registry System.

Arizona Pre-Hospital & EMS Registry System (AZ-PIERS)

Arizona's pre-hospital registry dedicated to supporting EMS providers in optimizing the care they provide to patients. EMS agencies are able to submit data to AZ-PIERS using their own electronic Patient Care Reporting (ePCR) system or receive FREE software from the Bureau of EMS and Trauma Systems (BEMSTS).

B Number

Department Code/Identifier used for Financial and location tracking of employees in the City of Phoenix.

Balance/Balance of Assignment

The difference between resources that are currently required and what are indicated in the response plan specified or response plan of the Call Type specified. Calculation of what resources are needed to fulfill the requirements not already assigned to the Incident are performed by the CAD system when the Balance request is selected by the Decision Dispatcher.

BC See Battalion Chief.

Basic Life Support (BLS)

A capability assigned to a team required to identify emergency situations, give first aid and transport a patient to the nearest hospital if necessary. The BLS team is given the task to give all the preliminary aids to the patient if necessary. If the situation calls for it, they can give the patients IV, medicines, and perform oxygen therapies. If more help is required an ALS team is requested to take over. Team providing EMT-B services as configured by the CAD administrator

Battalion Chief (BC) The rank and title of a subordinate fire chief or commanding officer in the firefighting command structure.

BLS See Basic Life Support.

C2 See Travel Code 2.

C3 See Travel Code 3.

CAD See Computer Aided Dispatch.

CAD Modernization Project

See Modernization Project.

Call For Service (CFS) Also referred to as an Incident, emergency event or call. The Call Taker creates a Call For Service (CFS) using a Computer Aided Dispatch (CAD) system.

Call Taker A specific function or role in the PFDRDC. Call Takers are responsible for answering 911 and other emergency lines. They are primarily responsible for entering Incidents into the CAD system.

Call Types/ Natures Refers to a word or code used by a dispatch center call taker when creating an Incident in a CAD system. A location and an initial call type must be entered by the call taker before an Incident can be created and dispatched. CAD uses the call type record and the location to link to a response plan designed for the call type and its location.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 61 of 137


Capabilities Codes that describe the skills, level of proficiency, and/or equipment that indicate the attributes of a resource. Capabilities are given to resources, vehicles and personnel and stored as a searchable attribute in a CAD system. These capabilities are looked for when fulfilling requirements by the resource suggestion program in CAD. Operators can also query for these capabilities as needed.

Cardiopulmonary Resuscitation (CPR)

An emergency procedure performed in an effort to manually preserve intact brain function until further measures are taken to restore spontaneous blood circulation and breathing in a person who is in cardiac arrest.

Centers for Disease Control and Prevention (CDC)

The leading national public health institute of the United States.

CDC See Centers for Disease Control.

Central Arizona Life Safety System Response Council (CALSSRC)

A group comprised of Chiefs from Fire Departments and Fire Districts across Central Arizona that participate in an Automatic Aid System.

CFS See Call For Service.

CFS Status Indicates the general state of an Incident (e.g. Waiting Dispatch, Routine, Working Fire, All Clear, and Closed).

Clear Channel A digital, trunked radio channel that is designated for use exclusively for Incidents that have a need for unrelated traffic on that channel to be kept to a minimum.

Computer Aided Dispatch (CAD)

Computer system that typically consists of a suite of software packages used to initiate public safety Incidents, dispatch resources to those Incidents, and maintain status of responding resources assigned and not assigned to Incidents. CAD is generally used by 9-1-1 emergency dispatch operators in a centralized public safety call center, as well as by field personnel utilizing mobile data computers (MDCs). Services performed by a CAD system include call input, call dispatching, call status maintenance, event notes, field resource status and tracking, and call resolution and disposition. CAD systems also include interfaces that permit the software to provide services to dispatchers, call takers, and field personnel with respect to control and use of radio and telephone equipment, as well as alerting systems.

Computer Room A room or set of rooms that contains appropriate environmental, power, heating, ventilation, air conditioning, and communications equipment required by large groups of computer systems.

Consortium See Automatic Aid Consortium.

Contagion A disease that can be passed from one person or animal to another by touching, physical contact, exchange of bodily fluid, etc.

Contract The legal agreement executed between the City and the contractor.

Contract Representative

The City employee or employees who have specifically been designated to act as a contact person or persons to the contractor, and responsible for monitoring and overseeing the contractor's performance under this contract.

Contractor The individual, partnership, or corporation who, as a result of the competitive process, is awarded a contract by the City of Phoenix.

Cover A term used by PFD, In a scenario where a dispatched resource is unable to respond to an Incident for mechanical or any other reason and needs to be “covered”. This is done by dispatching another resource of the same capability to the Incident.

CPR See Cardiopulmonary Resuscitation.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 62 of 137


Cross Staffing/ Cross Manning/ Shared crew/ Co-manning

Term used by the PFDRDC to indicate when a single crew is responsible for two or more vehicles at a station.

CSR See Customer Service Representative.

Customer Service Representative (CSR)

A specific function or role in the PFDRDC. CSRs are responsible for answering incoming non-emergency lines and supporting the other functions in AHQ as necessary.

Database System (DBS)

The software that manages the transfer of information from the CAD system to a data warehouse application (e.g. Oracle, SQL, etc).

DBS See Database System.

Decision Dispatcher (DD)

A specific function or role in the PFDRDC. Decision Dispatchers are responsible for reviewing, modifying, approving and dispatching fire department resource requests related to Incidents.

Deficiencies Resources or capabilities that are required for an Incident but have no available resources to fulfill those needs.

Digital Trunked The type of radio system used by the Automatic Aid Consortium to communicate on Non-Hazard Zone Incidents. The radio system is digital (as opposed to analog) and Trunked (all transmissions are repeated and broadcast across the entire system simultaneously).

Disaster Recovery (DR) Preparations for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster. Disaster recovery planning is a subset of a larger process known as business continuity planning and should include planning for resumption of applications, data, hardware, communications (such as networking) and other IT infrastructure.

Dispatch Group A set of resources assigned to a response area or call type (e.g. BR178 is assigned to a dispatch group associated with the Phoenix International Raceway response area and Central City Treatment Van is associated with Central City Treatment Center call types).

Dispatch Waiting Queue

The list of Incidents that need to be processed by the Decision Dispatcher.

Dispatch Warnings Notifications that alert dispatchers and MDCs when certain criteria is met during an Incident.

DR See Disaster Recovery.

e-Chris See PeopleSoft.

ECG See Electrocardiogram.

EFD See Emergency Fire Dispatch.

EKG See Electrocardiogram.

Electrocardiogram (EKG)

An (EKG or ECG) is a test that checks for problems with the electrical activity of your heart. An EKG shows the heart's electrical activity as line tracings on paper.

Electronic Patient Care Reporting (ePCR)

An electronic version of the forms used for data collection about a medical patient.

EMD See Emergency Medical Dispatch.

Emergency Deployment

A condition of the CAD system that indicates a different model must be used for allocation of resources on Incidents. Typically it involves an increased volume of activity and thus reduced requirements for certain fire and special operations incidents.

Emergency Fire Dispatch (EFD)

A set protocols to assist call takers while handling fire or other non-medical related emergencies.

Emergency Medical Dispatch (EMD)

A set protocols to assist call takers while handling medical related Incidents.

Emergency Medical Services (EMS)

A type of emergency service dedicated to providing out-of-hospital acute medical care, transport to definitive care, and other medical transport to patients with illnesses and injuries which prevent the patient from transporting themselves.

EMS See Emergency Medical Services.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 63 of 137


EMSystem An internet based application which tracks the statuses of various resources within the emergency medical care environment. Emergency Departments must communicate their ability to receive sick or injured patients to the pre-hospital care providers.

Emergency Medical Technician (EMT)

A term used to denote a health care provider of emergency medical services. EMTs are clinicians, trained to respond quickly to emergency situations regarding medical issues, traumatic injuries and accident scenes.

Enhanced 911 (E911) Support for wireless phone users who dial 911, the standard number for requesting help in an emergency. Since wireless users are often mobile, this enhancement allows the location of the user to be known to the call receiver.

Entity Relationship Diagrams (ERDs)

In software engineering, an Entity-Relationship Model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created using this process are called entity-relationship diagrams, or ER diagrams or ERDs for short.

Environmental Systems Research Institute (ESRI)

A geographic information system company located in Redlands, CA.

ePCR See Electronic Patient Care Reporting.

ERDs See Entity Relationship Diagrams.

ESRI See Environmental Systems Research Institute.

FDC See Fire Department Connection.

FDID See Fire Department/District Identification .

Federal Information Processing Standard (FIPS) Code

A Federal Information Processing Standard (FIPS) code which uniquely identifies states, counties, and places, in the United States, certain U.S. possessions, and certain freely associated states

Fire Department Connection (FDC)

A physical connection point to building fire suppression system for use by first responders.

Fire Department/District Identification (FDID)

A unique five-character identifier assigned by a state agency to identify a particular fire department within the state, in accordance with requirements from the National Fire Incident Reporting System. This identifier may also identify the county, fire district, or other jurisdiction in which the fire department is located. Numerals or alphanumeric characters must occupy all five spaces in this field.

FIPS Code See Federal Information Processing Standard Code

Final Acceptance A milestone in the implementation of the Phoenix Fire CAD/RMS Modernization Project that marks the completion of the implementation phase of the project.

Fire (agency) Phoenix Fire Department

Fire (Incident category) The category of Incident that relates to combustible materials (fuel), a heat source, and their detection and resolution (e.g. check smoke, working fire, fuel spill, wires down, etc.).

Fire Alarms A system with a number of devices working together to detect and alert people through visual and audio appliances when smoke/fire is present.

Fire Department City of Phoenix Fire Department

Fire Prevention The inspection, education, and enforcement division of PFD.

Fire Protection Systems A system that protects a building from fire damage (e.g. fire sprinkler system, Halon system for computer rooms, etc.).

First Alarm (1A) The highest level of an Incident that can be Balanced to. Any escalation of the Incident after that will require the addition of resources as Greater Alarms. See Balance and Greater Alarm for more details.

First Responder An employee of an emergency service who is likely to be among the first people to arrive at and assist at the scene of an emergency.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 64 of 137


Follow Me A function of an MDC map application that indicates whether or not to keep the focus of the map on the resource and, if assigned, the location of the Incident in the field of view at all times.

GCS See Glasgow Coma Scale

Geo Fencing The ability for the map application (MDC or desktop environment) to define and display a geographic boundary. A mobile device crossing the defined boundaries may trigger events and notifications.

Geocode A translation system allowing addresses in textual form (i.e. 123 W Main Street) to be converted to X- and Y-coordinates. A CAD system can use those coordinates to find closest resources and pin point a location on a map.

Geofile A geographic reference file that may actually be composed of one or more separate component files. Geofiles are used by public safety systems for a variety of purposes including location validation, mapping, coordinate assignment, shortest path calculation, boundary assignments, and other geographic related functions. Geofiles typically contain topologically structured street networks with street names, valid addresses or address ranges, and other attribute information. Geofiles can contain point, linear, and polygon information such as landmarks, rivers, streams, and response areas.

Geographic Information System (GIS)

A system designed to capture, store, manipulate, analyze, manage, and present all types of spatial or geographical data.

GIS See Geographic Information System

Glasgow Coma Scale A neurological scale that aims to give a reliable, objective way of recording the conscious state of a person for initial as well as subsequent assessment. A patient is assessed against the criteria of the scale, and the resulting points give a patient score between 3 (indicating deep unconsciousness) and either 14 (original scale) or 15 (the more widely used modified or revised scale).

Go-Live A milestone on the project schedule that marks the beginning of general production use of the Proposed Solution.

Greater Alarm Indicators on an Incident of the need for the addition of a predefined set of resources. These resources are required in addition to any existing resources on an Incident. Greater Alarm levels currently used by the PFDRDC are two through nine (2nd alarm, 3rd alarm, etc.).

Hazard Zone The type of Incident that has an elevated risk of danger to First Responders (e.g. fire or special operations related Incidents). This applies to all Incidents that require a Self-Contained Breathing Apparatus (SCBA).

Hazardous Materials (Incident category)

A category of Incident call type as defined by the Central Arizona Life Safety System Response Council. These call types involve substances that could adversely affect the safety of the public or first responders.

Hazardous Materials (HazMat)

Solids, liquids, or gases that can harm people, other living organisms, property, or the environment. They are often subject to governmental regulations.

Hood

Self-contained restaurant fire suppression system that incorporates equally spaced discharge nozzles over the entire length of the kitchen hood.

Hospital Capabilities Services or functions that hospital can provide (e.g. pediatric trauma, cardiac, and burn center).

Hospital Status An indicator of the general state of a hospital or sections of a hospital (e.g. opened, closed, rotation, and diversion).

IBC See International Building Code.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 65 of 137


Inbound Service Representative (ISR)

A specific function or role in the PFDRDC. The ISR is responsible for answering inbound calls not distributed through the 911 Automatic Call Distribution (ACD) queue, including requests from outside agencies. (E.g. police communication centers, utility companies, airport towers and Sky Harbor communications, administrative and public customer service lines, hospital, ambulance and helicopter company lines, medical control line).

Incident An Incident is a Call For Service.

International Building Code (IBC)

A model building code developed by the International Code Council (ICC).

ISR See Inbound Service Representative.

Issue Reporting A system that the PFDRDC and its members use to submit problems/issues/errors for various technical teams in PFD to address.

IV See Intravenous Device.

Intravenous Device (IV) Medical implement used for delivering electrolyte solutions, medicines, and nutrients.

Jurisdiction A Jurisdiction is an area that is primarily serviced by an agency.

KIVA Permit Tracking System used by the City of Phoenix.

KNOX Box

A small, wall-mounted safe that holds building keys for fire departments, Emergency Medical Services, and sometimes police to retrieve in emergency situations.

LAT See Latitude.

Latitude

The angular measurement of a place north or south of the earth's equator, usually expressed in degrees.

LEAD See Lead Dispatcher.

Lead Dispatcher (LEAD)

A specific function or role in the PFDRDC. Lead Dispatchers are responsible for assisting the supervisor in managing the overall operations of the regional dispatch center.

Leave to Hospital (LV) A status used by the PFDRDC to indicate a resource is transporting a patient or patients to a hospital.

Life Support Levels The level of medical care provided by a resource. See ALS, BLS, PLS, and NLS.

LONG See Longitude

Longitude

The angular measurement of a place east or west of the prime meridian, as that of Greenwich, England, usually expressed in degrees.

LV See Leave to Hospital.

M5

FleetFocus M5 is a fully integrated, fleet management system that focuses on those areas critical to effective fleet management. Used by the City of Phoenix for Fleet Management

Map Extent The portion or area of a region show in a map. The limits of a map extent are defined in the coordinate system of the map. In Western culture, map extents usually have a rectangular shape, so they are defined with a minimum and maximum width and height. Map extents may be used to determine which map layers to turn on or off.

Map Layers A reference to a data source, such as a shapefile, coverage, geodatabase feature class, or raster that defines how the data should be symbolized on a map. On a road map, for example, roads, national parks, political boundaries, and rivers might be considered different layers.

MCT See Mobile Data Computer.

MDC See Mobile Data Computer.

MDT See Mobile Data Computer.

Medical Patch The connection of First Responders to hospital personnel via phone and radio systems.

Milestone A significant event related to an Incident.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 66 of 137


Mobile Data Computer (MDC)

Also referred to as an MCT (Mobile Computer Terminal) or MDT (Mobile Data Terminal). A computer device installed in an emergency response vehicle, running a suite of software packages to receive dispatch information from a CAD system, maintain current status with CAD, communicate electronically with dispatch center personnel and other first responder’s MDCs. Also used to perform various other types queries available from the CAD system. The device typically has a mapping software application as well to assist the responders to the exact location of the emergency.

Modernization Project A project undertaken by PFD to update/replace the aging CAD and RMS systems that are currently used.

Moodle A free and open-source software learning management system written in PHP and distributed under the GNU General Public License. Developed on pedagogical principles, Moodle is used for blended learning, distance education, flipped classroom and other e-learning projects in schools, universities, workplaces and other sectors. Moodle is used by the Phoenix Fire Department for online learning.

Move-Up The relocation of a resource to fill in temporary gaps in coverage.

Mutual Aid Occurs when resources respond to Incidents across certain or all jurisdictional boundaries only after an approval process has been completed.

National Fire Incident Reporting System (NFIRS)

A system established by the National Fire Data Center of the United States Fire Administration (USFA), a division of the Federal Emergency Management Agency. The System was established after the 1973 National Commission on Fire Prevention and Control report, America Burning, led to passage of the Federal Fire Prevention and Control Act of 1974 (P.L. 93-498), which authorizes the USFA to gather and analyze information on the magnitude of the Nation's fire problem, as well as its detailed characteristics and trends. The Act further authorizes the USFA to develop uniform data reporting methods, and to encourage and assist state agencies in developing and reporting data.

National Incident Management System (NIMS)

A standardized approach to cross jurisdiction and cross agency incident management developed by the Department of Homeland Security.

National EMS Information System (NEMSIS)

Provides the framework for collecting, storing, and sharing standardized EMS data from States nationwide.

NEMSIS See National EMS Information System.

Next Generation 911 (NG911)

A not yet fully realized paradigm shift in the way the public uses 911 services. NG911 services include the ability for the public to communicate with 911 operators through text messaging, media uploads and other advanced communications.

NFIRS See National Fire Incident Reporting System.

NLS See No Life Support.

No Life Support (NLS) A resource with No Life Support is an indicator the resource may not have any of the equipment or skills necessary to provide specific medical aid to a patient.

Non-Hazard Zone The type of Incident that has minimal risk of danger to First Responders (e.g. medical or non-emergency Incidents).

OpenVMS A computer operating system currently owned, maintained, and supported by Hewlett Packard.

OSR See Outbound Service Representative.

Outbound Service Representative (OSR)

A specific function or role in the PFDRDC. One of the main responsibilities of the OSR is to manage requests for resources that are not directly dispatched by PFDRDC’s CAD. Such as (utility companies, taxis, helicopters, police, some private ambulance companies, etc.). The CAD system helps keep track of these resources as they are requested and added to any Incident.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 67 of 137


Pathogen

Typically the term is used to describe an infectious agent such as a virus, bacterium, prion, fungus, viroid, or parasite that causes disease in its host.

PAPR See Private Ambulance Provider Representative.

Patient Transfer Report (XPT)

The form filled out by resources that transport patients to a hospital. The report contains info about the time it took to officially transfer the patient to hospital care and basic patient information.

PCR

A legal document that used to effectively document essential elements of patient assessment, care, and transport.

PeopleSoft

PeopleSoft, Inc. is a company that provides Human Resource Management Systems (HRMS), Financial Management Solutions (FMS), Supply Chain Management (SCM), Customer Relationship Management (CRM), and Enterprise Performance Management (EPM) software, as well as software for manufacturing, and (Rahim) student administration to large corporations, governments, and organizations. It existed as an independent corporation until its acquisition by Oracle Corporation in 2005. The PeopleSoft name and product line are now marketed by Oracle. PeopleSoft is used by the City of Phoenix for Human Resource Management under the name of e-Chris.

Phoenix Fire Department Regional Dispatch Center (PFDRDC)

A collection of systems (CAD, MDC, Station Alerting, etc.) and the personnel that use those systems.

PFD Phoenix Fire Department.

PFDRDC See Phoenix Fire Department Regional Dispatch Center.

Physical Resources A category of RMS functionality related to tracking assets, equipment, plant, and buildings, and their maintenance.

PLS See Single Paramedic Life Support.

PMI Project Management Institute.

PRC An American software company that developed the CAD system that is currently in use by PFD. PRC was purchased by Northrop Grumman in 2001.

Preempt To remove a resource from a lower priority Incident and assign them to a higher priority Incident. Preemption may be done automatically by the CAD system if a resource is Available On Incident (AOI).

Premise A tract of land including the structures on it.

Private Ambulance Provider Representative (PAPR)

A unique function assigned to a PFDRDC CAD workstation located at a remote dispatch center. Private ambulance requests assigned to this dispatch agency are routed to the PAPR workstation. Personnel located at this dispatch center manage private ambulance requests and interact with the PAPR workstation to indicate what resource has been dispatched to fulfill the request.

Project Milestone A significant accomplishment of work or delivery of a deliverable as listed on the project schedule, in the project implementation plan, or in the contract. May or may not be associated with a payment to the Vendor.

Project Schedule A listing of project tasks in Microsoft Project that is presented in text, in Gantt format, and in a roadmap view.

Project Management Institute (PMI)

A globally recognized a US not-for-profit professional organization for project management. The PMI provides services including the development of standards, research, education, publication, networking-opportunities in local chapters, hosting conferences and training seminars, and providing accreditation in project management.

Proposed CAD System The part of the overall Proposed Solution that relates to CAD.

Proposed RMS The part of the overall Proposed Solution that relates to RMS.

Proposed Solution The combination of all the technical parts of the Response to the RFP.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 68 of 137


PRV

A safety feature of a building fire protection system to prevent over pressurization of a standpipe.

PSAP Public Safety Answering Point.

PTI Legacy name for a form called “Patient Transport Information” whose use has been expanded. See Supplemental Caller Information.

RACI Project management tool for modeling decision making roles and responsibilities. Stands for “Responsible, Accountable, Consulted, Informed”.

Radio Call Alerts/ Paging

Messages sent to portable or mobile radios that trigger an audible and visual alert.

Radio Channel List A set of Tactical Channels that can be assigned to an Incident. Radio Channel Lists apply to a distinct response areas. Several lists (Clear, Analog Simplex, and Digital Trunked) may be necessary for each response area.

Radio Push to Talk Events (PTT)

Discrete transmissions performed by a radio associated with the radio system. These events can be triggered by keying up on a portable, mobile, or console radio.

RAPID Project management tool for modeling decision making roles and responsibilities. Stands for “Recommender, Approver, Perform, Input, Decide”.

Records Management System (RMS)

A software program that integrates digital information from a (CAD) computer aided dispatch system into a cohesive database. The RMS will collate information by 911 dispatchers, first responders and administrative personnel that will be used to generate reports to analyze performance and call volume of the system. RMS systems may contain several modules depending on the needs of the department to keep track of personnel, training, inspections, hydrants, building information etc.

Re-evaluate / Rethink Function of the CAD system used to recalculate the resource recommendation for a specific Incident.

Resource This term is synonymous with the word “unit” and typically refers to a response vehicle, its capability and the capability of the crew assigned to it. A CAD system dispatches resources to Incidents.

Resource List The set of resources assigned to an Incident including information about the resource such as location, capabilities, status, and sector assignment (see Sectors for more information).

Resource Routing The ability for the CAD system to provide road network navigation to a Resource’s MDC for an Incident.

Resource Status The current state of a resource. It can include general information and an indicator about the resource’s availability (e.g. Available on Radio (AOR), Available in Quarters (AIQ), Unavailable Mechanical (UNV MECH)).

Resource Suggestion / Unit Suggestion

A software program in a CAD system used to suggest resources automatically on an Incident based on the call type and location entered by the call taker. The resource suggestion program utilizes a response plan record associated with a call type and location. Response records can be very complex and are used to implement dispatch policies.

Response Plan A Response Plan is a predefined set of requirements that describe the policies of a jurisdiction.

RMS See Records Management System.

Roster A listing of personnel currently assigned to a resource.

Routeware A Danish software company that specializes in tools relating shortest path algorithms and routing. PFD currently uses RW Net Server 3 tools provided by this company.

SAP SE (Systems, Applications & Products in Data Processing)

A German multinational software corporation whose products allow businesses to track customer and business interactions. It is especially well-known for its Enterprise Resource Planning (ERP) and data management programs. SAP is used by the City of Phoenix for Asset and Inventory Tracking and Ordering.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 69 of 137


Scheduled Activities A planned non-emergency event that is entered into the CAD system that may trigger warnings to others entering Incidents in the vicinity. Scheduled Activities are associated with Call Types that determine radius and also which similar Call Types cause them to trigger.

Sectors Freeform groupings of resources that assist command teams with the management and distribution of those resources on an Incident (e.g. roof, west, triage). Analogous to NIMS divisions or groups.

Service Calls (Incident category)

A category of Call Type as defined by the Central Arizona Life Safety System Response Council. These call types are typically non-emergent and low priority (e.g. check welfare, open hydrant, etc.)

SIC See Standard Industrial Classification.

Single Paramedic Life Support (PLS)

A capability assigned to a team of highly trained individuals providing advanced medical help to patients in transit when needed. A Single Paramedic Life Support team is typically composed of one paramedic (EMT-P) and one or more Emergency Medical Technicians (EMT-B).

SIRE

Electronic Records and Document Management Solution used by the City Of Phoenix.

SkillSoft

Provider of online learning and eLearning solutions for global enterprises, small to medium businesses, government and education.

Special Call A request for additional resources on an Incident from First Responders.

Special Operations A category of Call Type that includes Hazardous Materials and Technical Rescue Operations.

Stage of Fire on Arrival One of four lifecycle phases of a Fire as noted by the first arriving resource. Stages are: incipient, growth, fully developed, and decay.

Standard Industrial Classification (SIC)

Four-digit numerical codes assigned by the U.S. government to business establishments to identify the primary business of the establishment.

Standpipe

A type of rigid water piping which is built into multi-story buildings in a vertical position or bridges in a horizontal position, to which fire hoses can be connected, allowing manual application of water to the fire.

Supervisor (SUPV) A specific function or role in the PFDRDC. Supervisors are responsible for managing the overall operations of the regional dispatch center. Some of those tasks include approving various changes to Incidents, monitoring all radio traffic for issues, and reviewing certain automatic notifications.

Supplemental Caller Information

Important information gathered and entered by a call taker related to an Incident. It is consumed and used by responding resources.

SUPV See Supervisor.

Synthesized Voice The digital recreation of human speech by a computer system. The PFDRDC uses synthesized voice to announce dispatches of Incidents over the radio and locally at fire stations through the station dispatch package system.

Tactical Channel See Tactical Radio Channel

Tactical Channel Threshold

See Tactical Radio Channel Threshold

Tactical Radio Channel A communication path (i.e. radio frequency, talk group) used by resources for communications while assigned to an Incident.

Tactical Radio Channel Threshold

The number of Incidents that can be assigned to a single tactical radio channel at the same time. Once the threshold is reached no more Incidents can be automatically assigned to that channel.

Tactical Radio Operator (TRO)

A specific function or role in the PFDRDC. TROs are responsible for managing communications on all Incidents assigned to their Tactical Radio Channel(s).




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 70 of 137


TAT See Technical Advisor Team.

Technical Advisor Teams (TAT)

The groups of subject matter experts who assist the Evaluation Committee with technical issues.

Technical Rescue The component of Special Operations that relates to the saving of life or property utilizing specialized tools and skills that exceed those involved in normal Fire and EMS Incidents (e.g. mountain rescue, confined space rescue, water rescue, etc.).

TeleStaff

Kronos Workforce TeleStaff is the automated scheduling solution that public safety organizations around the country rely on. It is used by the Phoenix Fire Department for daily staffing

Thread Type

The fire hose thread specifications for some local municipal fire equipment and hydrants may vary according to local specifications. These can generally be most easily identified by contacting the local fire department responsible for the hydrant. The most common thread used on fire equipment is National Standard Thread (NST), also known as National Hose thread (NH).

Travel Code An indicator of the method of travel of a resource. Code 3 (C3) indicates that the resource is using lights and sirens and abiding by the code 3 driving regulations. Code 2 (C2) indicates that no lights and sirens are being used and the resource is abiding by normal driving rules and laws.

Travel Code 2 (C2) A code to indicate the way a resource responds to an Incident. C2 indicates the resource is responding to the Incident without lights and sirens, driving at posted speed limits and following all traffic rules.

Travel Code 3 (C3) A code to indicate the way a resource responds to an Incident. C3 indicates the resource is responding to the Incident with lights and sirens and following standard operating policies set in place by the responding emergency Fire/EMS department.

TRO See Tactical Radio Operator.

U.S. Digital Designs (USDD)

The current provider of the station alerting systems for the PFDRDC.

USDD See U. S. Digital Designs.

Voice Group A specific function or role in PFD’s the PFDRDC. Voice Groups are responsible for making sure that all Incidents are announced over the dispatch radio channel.

Wireless Phase II For E911 Phase II, the wireless carriers deliver to the appropriate PSAP the telephone number of the handset originating the 911 call and the latitude and longitude of the call.

XPT See Patient Transfer Report.

Weapon of Mass Destruction (WMD or WoMD)

A nuclear, radiological, chemical, biological or other weapon that can kill and bring significant harm to a large number of humans or cause great damage to human-made structures (e.g. buildings), natural structures (e.g. mountains), or the biosphere.

WMD See Weapon of Mass Destruction.

WoMD See Weapon of Mass Destruction.

Work Breakdown Structure

A document that contains a hierarchical representation of the scope of work required in order to achieve project goals. Work is presented at multiple levels of granularity and may have a graphical representation. Typically includes estimates and lists the teams or team members responsible for completing the work.

3. FUNCTIONAL AND TECHNICAL REQUIREMENTS 3.1 PHOENIX FIRE SPECIFIC FUNCTIONALITY - COMPUTER AIDED DISPATCH (CAD) This section describes a set of functions that are critical to the operation of the PFDRDC and will be required in the final solution. PFD recognizes that there are alternative methods of satisfying these requirements. As part of




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 71 of 137

the response to this section, Vendors are encouraged to showcase unique advantages of their Proposed Solution. More than one approach to satisfying the requirements may be presented for each section. As is the case over the last 20 years of evolution with the current CAD system, PFD expects continuous improvement to be a focus from an operational perspective. Vendors should use their responses to the requirements below as an opportunity to demonstrate the method they plan to use to support future improvements as the CAD supplier for PFD. The responses in this section should demonstrate the flexibility, interoperability, and extensibility of their solutions. For convenience, a copy of the applicable requirements from ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET has been included in each section. NOTE: There is no “Vendor Response” column shown in the copied requirements tables. Responses to the individual requirements should be submitted with APPENDIX A – FUNCTIONAL REQUIREMENTS WORKSHEET. For this section (3.1 PHOENIX FIRE SPECIFIC FUNCTIONALITY – COMPUTER AIDED DISPATCH (CAD)), a response is required ONLY for items where a Vendor Response/Comments column is available. 3.1.1 SPECIAL DISPATCHER ROUTING PFDRDC currently manages a high volume of Incidents daily. In order to maintain efficiency, PFDRDC divides management of each Incident amongst several dispatch operators. Each division of an Incident is referred to as a dispatch function. PFDRDC’s current list of dispatch functions are: Call Takers, Decision Dispatcher (DD), Tactical Radio Operator (TRO), Inbound Service Representative (ISR), Outbound Service Representative (OSR), Private Ambulance Provider Representative (PAPR), Customer Service Representative (CSR), Lead Dispatchers (LEAD), and Supervisors (SUPV). A typical Incident will route from Call Taker to Decision Dispatcher to Tactical Radio Operator. 3.1.1.1 Automatically Assigning Tactical Radio Channels PFDRDC requires a solution that will automatically assign a tactical radio channel to an Incident based on rules described in this section. The Proposed Solution shall assign a tactical radio channel to an Incident as the Decision Dispatcher selects an Incident and before it is dispatched. Alternatively, if the Incident is configured for Automatic Dispatch, the Proposed Solution must assign a actical radio channel before resources are dispatched. PFD and the Automatic Aid Consortium operate using two separate radio systems. One radio system is designated for fire or Hazard Zone call types. The other system is designated for medical or non-Hazard Zone call types. PFDRDC requires a solution that will assign a tactical radio channel to an Incident based on the type of call and the location of the call. Once the Incident has been assigned to a tactical radio channel, the Proposed Solution must route the call to the Tactical Radio Operator (TRO) who has been assigned to that tactical radio channel. The TRO will manage the Incident to its conclusion. Any geocoded location in CAD shall be linked to one or more tactical radio channel lists. See ATTACHMENT E - CURRENT SYSTEM APPLICATION CONFIGURATION SETTINGS – TACTICAL CHANNEL LIST tab. A Tactical Radio Channel list is assigned to a geographic area and can be defined by a GIS polygon feature. Attributes in this polygon may contain multiple lists of tactical radio channels. Multiple lists are defined for most areas. The particular tactical radio channel list CAD uses will be determined by the Incident type. 3.1.1.2 Channel Administration This section describes the overall elements of the tactical radio channels and the functions needed to manage tactical radio channel lists. There are no required responses for this section. This list is provided as background. The remaining requirements in section 3.1.2 depend on the existence of this functionality.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 72 of 137

File # Priority Requirement

B.8.06.1 C The CAD system shall automatically assign a tactical channel to each CFS, before or at the time when resources are assigned to a CFS for dispatch.

B.8.06.2 C Tactical channels - The CAD system administrator shall be able to define as many tactical channels as desired. Tactical channels shall have the following attributes. (see Attachment E "Full Tac Channel List" tab for the complete tactical channel list.)

B.8.06.2.1 C Name - (e.g. A1, A2, K3, K4, etc.)

B.8.06.2.2 C Availability - (e.g. enabled/disabled)

B.8.06.2.3 C Assignment Count - Channel is currently assigned to this many Incidents. Note: value is managed by CAD in real-time.

B.8.06.2.4 C Assignment Threshold - The maximum number of CFS's that can be concurrently assigned to this tactical channel.

B.8.06.2.5 C CAD shall consider the following when assigning a tactical channel to any CFS.

B.8.06.3 C Location - The location of the CFS shall provide multiple "pre-configured" tactical channel lists. Tactical channel lists shall be assigned to geographic areas and may be represented in GIS polygon features. Every geographic area in the scope of CAD must be represented by at least one tactical channel list.

B.8.06.4 C CFS type - The type of CFS will determine which tactical channel list (provided by the call's location) to assign from. If the CFS type indicates a tactical channel list that is not defined for a particular location, use the highest priority tactical channel list (e.g. each list will have a priority level defined by a CAD administrator.) (see Attachment E "Sample Tac Channel List" tab for an example of a channel list.)

B.8.06.4.1 C Tactical channel list priority - The priority of the tactical channel list. If a call type record points to a list that is not defined, use the highest priority list instead.

B.8.06.4.2 C Tactical channel list type - Each tactical channel list shall have a type. And the type shall determine the assignment behavior. The following are two types of assignment behaviors required.

B.8.06.4.2.1 C Type 1 (Preferred Order) - This type of list contains a set of tactical channels in order of preference (e.g. primary, secondary, tertiary, etc.). This is to say, assign the primary tactical channel in this list unless the primary channel is unavailable. If the primary channel is unavailable assign the secondary channel unless it is also unavailable then assign the tertiary channel and so on... Note: If all channels in the list are unavailable, assign the primary channel.

B.8.06.4.2.2 C Type 2 (least used preferred) - This type of list contains a set of ordered tactical channels, however the tactical channels are preferred based on current levels of use. This is to say, assign the tactical channel in this list that is currently assigned to the least amount of calls for service. Note: If two or more channels in this list are equal in least used value, assign the channel that is of the highest order preferred.

B.8.06.4.3 C Number of tactical channels in a list - Each tactical channel list shall be able to contain a number of tactical channels defined by a CAD administrator (typically 4 or 5 are defined in a list). The list can only contain tactical channels that have been define by a CAD administrator. (see Attachment E "Sample Tac Channel List" tab for an example of a channel list.)

B.8.06.4.4 C The availability of a tactical channel - Each tactical channel defined, shall have an "Availability" attribute (e.g. enabled/disabled). When a tactical channel is unavailable, CAD shall no longer assign that tactical channel to any CFS. Except, if all other tactical channels in the list are unavailable, then use the primary tactical channel.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 73 of 137


B.8.06.4.5 C The assignment threshold of a tactical channel - Each tactical channel defined shall have a threshold value. The threshold value shall indicate the maximum number of calls that can be concurrently assigned to that channel. If that channel is assigned concurrently to its threshold value or more, do not assign this channel to another CFS, use the next available channel in the list.

B.8.06.4.6 C Managing the availability of a tactical channel - Any authorized dispatcher shall have the ability to alter the availability of a tactical channel as desired. CAD shall not assign a tactical channel if it is altered as unavailable.

3.1.1.3 TRO CHANNEL ASSIGNMENT Given the requirements stated in each section below, please answer the following questions describing the conceptual design and user experience that would be proposed to meet these requirements. Submittal of multiple conceptual designs is acceptable and even desired. The following describes requirements for a dispatch operator signing into the system as a Tactical Radio Operator (TRO):


B.3.03 V CFS tactical channel assignment vs. workstation tactical channel control: Each CFS shall automatically be assigned to a tactical channel by CAD (See B.8.06 Automatically Assigning Tactical Channels for details). The following describes functions a TRO shall be able to perform in order to see and control a CFS assigned to a tactical channel. TRO workstations are assigned to tactical channels and are responsible for any CFS assigned to those tactical channels. A workstation that is assigned to control a tactical channel will receive notifications as calls for service are assigned tactical channels by CAD, additionally the CFS shall be displayed on the workstation's monitor. TRO workstations are responsible for any calls for service that are assigned to any tactical channel that CAD workstation controls.

B.3.03.1 V Query for tactical channels assigned to workstations: A TRO shall be able to query the system to see tactical channels that have been assigned to all CAD workstations.

B.3.03.2 V Assigning tactical channels to workstations: A TRO shall be able to re-assign tactical channels from one CAD workstation to another as desired.

B.3.03.3 V Multiple tactical channels: Multiple tactical channels may be assigned to any one CAD workstation as desired. The number of assigned tactical channels per workstation will be based on TRO staffing levels.

B.3.03.4 V Must be assigned: All active tactical channels, defined by the CAD administrator, must be assigned to CAD workstations. An active tactical channel cannot be de-assigned from a CAD workstation without being reassigned to another CAD workstation. (see Attachment E "Full Tac Channel List" tab for all tactical channels.)

B.3.03.5 V TRO dispatcher sign off: A TRO shall not be able to sign off a CAD workstation if that workstation has any tactical channels assigned to it. The TRO shall have two options before signing off. Another TRO shall be able to sign on to that CAD workstation and assume the role, thus assuming control of tactical channels assigned to the CAD workstation. Or another TRO from another CAD workstation may gain control of the tactical channels assigned, thus allowing the TRO to sign off the CAD workstation.

B.3.04 C Transferring a CFS to another tactical channel: The TRO shall be able to transfer any one CFS from one tactical channel to another.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 74 of 137


B.3.05 C Notification of a CFS tactical channel transfer: When the TRO transfers a CFS to another tactical channel, CAD shall notify all resources assigned to the CFS of the new tactical channel assignment via MDCs.

B.3.06 C Transferring a CFS to another tactical channel of another tactical channel list: There are multiple tactical channels lists used by PFDRDC, each list contains a set number of tactical channels that may be assigned to a CFS by CAD. Tactical channel lists are configured by the CAD administrator. CAD will determine, based on CFS type and CFS location, the correct list of tactical channels to assign from. (See B.8.06 Automatically Assigning Tactical Channels for details). The TRO shall have the ability to transfer a CFS from one tactical channel list to another.

B.3.07 V Transferring all CFSs assigned on a tactical channel to a different tactical channel: The TRO shall have the ability to transfer all calls for service assigned on one tactical channel to another.

B.3.08 V Altering a tactical channel: The TRO shall have the ability to disable/enable a tactical channel as desired. Disabling a tactical channel prevents CAD from assigning another CFS to that tactical channel until it is re-enabled.

TRO Channel Assignment Conceptual Design Proposed Solution Specifications

Response ID Requirements Vendor Response/Comments

4.301.01 What mechanism or design pattern will be used to ensure that CAD assigns the appropriate tactical radio channel based on the criteria described above?

4.301.02 Describe the data entities that will be involved with implementing the automatic assignment of tactical radio channels to an Incident.

4.301.03 Provide a diagram of the software components that will be used to provide this capability and their placement in the Proposed Solution.

4.301.04 Describe how the CAD administrator can enable and configure this capability.

4.301.05 Describe the procedures and commands that would be performed by dispatch workstation users once the capability is configured.

4.301.06 Describe any alternate workflow that can handle the functionality in a better way.

4.301.07 Describe the capability of the Proposed Solution to integrate with third party software to provide this functionality (if not available in the base product).

3.1.1.4 OUTBOUND SERVICE REPRESENTATIVE (OSR) The OSR function is a radio support position responsible for initiating outbound requests for services from outside agencies (e.g. utility companies, taxis, some private ambulance companies, helicopters, police departments, etc.). Outside agencies provide a service on an Incident and need to be tracked. These resources are not directly dispatched by the CAD system. To minimize workload on the TRO and the Decision Dispatcher, requests for these resources shall route to the OSR function. The OSR has multiple responsibilities including but not limited to:

Monitor radio channels for TRO support

Creating and monitoring medical patches




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 75 of 137

Coordinate (helicopter, private ambulance, utility company, etc.) response requests

Monitor EMSystem for hospital status and availability

Mass Casualty Incident Alerts

Call taking When a request for a utility company (e.g. gas or electric) is made over the assigned tactical radio channel, the Tactical Radio Operator (TRO) will initiate a request for that utility company via the CAD system. Because utility companies are resources not dispatched directly by CAD, this type of request is routed to the OSR's request queue. The operator assigned to the OSR function receives an alert, selects the request from the queue and proceeds to coordinate by phone with the utility company to fulfill the request. The OSR manages the status of the requested resource as contact is made and as the utility company indicates to the OSR they are responding. Given the requirements stated below, please answer the following questions describing the conceptual design and user experience that would be proposed to meet these requirements.


B.8.01.7.2 C Resources such as (utility companies, taxis, some private ambulance companies, helicopters, police departments, etc.) shall be tracked when requested and documented in CFS history.

B.8.01.7.3 C Any request for a resource flagged as "managed by the OSR" is to be routed to the OSR's request queue. Examples of resources that may be flagged as "managed by the OSR" are (“Gas and electric power companies”, taxis, some private ambulance companies, helicopters, police departments, etc…)

B.8.01.7.4 C The assigned OSR operator shall receive an alert notification as requests are put into the OSR's request queue. The queue shall be prioritized based on the configured priority of the resource.

B.8.01.7.5 C If there are requests for the OSR that are not acted upon by a pre-determined amount of time (as configured by the CAD administrator), indicate to anyone monitoring the incident, the request has been made but has not been acted upon.

B.8.01.7.6 C Resources flagged as "managed by the OSR function" shall behave in a different manner (see B.8.11 Special Resource configurations for more detail). Resources configured as "managed by the OSR function" shall include a priority and additional contact information. The contact information shall be shown to the OSR. The priority assigned to the resource shall determine its place in the OSR's request queue.

B.8.01.7.7 C The OSR shall have the ability to indicate when contact has been made and the request is satisfied. The OSR shall have the ability manage the status of the requested resource.

OSR Channel Assignment Conceptual Design Proposed Solution Specifications


4.302.01 What mechanism or design pattern will be used to ensure that CAD routes the request for resource types (stated above) to the OSR function?

4.302.02 Describe the data entities that will be involved in implementing the OSR function.

4.302.03 Provide a diagram of the software components that will be used to provide this capability and their placement in the overall system.





Phoenix, AZ 85003 Phone: (602) 262-7181


Page 76 of 137

OSR Channel Assignment Conceptual Design Proposed Solution Specifications



4.302.06 Is there any alternate workflow (which you want to suggest) which can handle the functionality in a better way? If so, please describe your ideas


3.1.1.5 PRIVATE AMBULANCE PROVIDER REPRESENTATIVE (PAPR) The PAPR function is unique in that it is assigned to a remote CAD workstation located at the dispatch center of a private ambulance company. Private ambulance requests, typically requested by the TROs are sent to the appropriate PAPR workstation, in an effort to minimize the workload on the TRO and the decision dispatcher. Personnel from that private ambulance dispatch center manage the request. The private ambulance dispatch personnel use a special command to attach their assigned resource to the Incident. Given the requirements stated below, please answer the following questions describing the conceptual design and user experience that would be proposed to meet these requirements.


B.8.01.8 C Private Ambulance Provider Representative (PAPR(x)) 1, 2, 3, etc.: The PAPR(x) function is unique in that it is assigned to a remote CAD workstation placed in the dispatch center of a private ambulance company. Private ambulance requests from this provider are then managed by personnel from that dispatch center. This function is assignable only by a CAD administrator.

B.8.01.8.1 C A special private ambulance resource may be created in CAD (see B.8.11 Special Resource configurations for more detail) and flagged as managed by PAPR(1) or PAPR(2) or etc. (the number (1) represents a particular private ambulance company)

B.8.01.8.2 C Any request for a resource flagged as "managed by a PAPR(x)" is to be routed to the proper PAPR's request queue.

B.8.01.8.3 C The assigned PAPR operator shall receive an alert notification as requests are put into the PAPR's request queue.

B.8.01.8.4 C Resources flagged as "managed by the PAPR(x) function" shall behave in a different manner (see B.8.11 Special Resource configurations for more detail).

B.8.01.8.5 C A timer shall be created as requests are put into a PAPR(x) queue. If the request is in the queue for longer than a configurable amount of time notify the supervisor group.

PAPR Channel Assignment Conceptual Design Proposed Solution Specifications


4.303.01 What mechanism or design pattern will be used to ensure that CAD routes the request for resource types (stated above) to the PAPR function?




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 77 of 137

PAPR Channel Assignment Conceptual Design Proposed Solution Specifications


4.303.02 Describe the data entities that will be involved in implementing the PAPR function.



4.303.05 Describe the procedures and commands that would be performed by the dispatch workstation users (remote and local) once the capability is configured.



3.1.2 EMERGENCY MEDICAL DISPATCH/EMERGENCY FIRE DISPATCH (EMD/EFD PROTOCOLS) PFD develops and continually updates a set of EMD and EFD protocols. These protocols can be applied to any Call Type conceived and modified differently for any jurisdiction using that call type. The appropriate protocol shall be presented to the Call Taker after location verification and after an initial Call Type has been entered. The call entry process is interrupted only if an EMD or EFD record is found and is flagged to be shown to the Call Taker prior to call entry. If the EMD or EFD record is flagged to be shown after call entry, it must not interrupt the call from being submitted. PFD considers these protocols to be a set of guidelines and the Call Taker must be able to submit the call at any point in time without being required to respond to all questions in the series. EMD and EFD protocols typically consist of a mixture of post entry and pre-arrival guidelines. The call taker may be prompted by the protocol to submit the call. Based on an answer to a question, the call taker may be prompted to perform a specific action without being required to respond to all questions in the series (e.g. a typical action would be to change the call type or response type, see below in yellow). The post entry guideline is typically a set of key questions and instructions.

The presentation of a typical EFD/EMD record may be in the following formats.

For a call type of HOUSE (House Fire) the following EFD record shall be displayed.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 78 of 137

Send Call < ----------- This record will typically be flagged as "present to the call taker after call entry" Key Questions: 1) Is everyone out of the house? If NOT ……………………………………………………………………………………… Balance to a Working Fire How many people are trapped inside? If multiple …………………………………………………………………………………… Balance to a MED1A Where in the house are they? 2) Is anyone injured? If Yes …………………………………………………………………………………….… Special Call ALS AMB 3) What part of the house is on fire? 4) How large is the house? Multi-story? Pre-Arrival Instructions: 1) Get everyone out of the house now 2) location to meet with the Fire Department 3) Close the door as you leave the house 4) Do not re-enter the house for any reason

For a call type of ILL (Ill person) the following EMD record shall be displayed.

Key Questions: 1) What kind of problems are they having? Consider other appropriate call type code. 2) Are they having pain radiating to arm/jaw? ………………….YES. Change call type to ILLA 3) Passing or vomiting blood? ……………………………………YES. Change call type to ILLB 4) Do they have any major medical problems that could be contributing to this? (diabetes, heart disease, stroke, Kidney failure) ………………………………………………………YES. Change call type to ILLA 5) Severe weakness? ……………………………………………..YES. Change call type to ILLA 6) Post surgery? ……………………………………………………YES. Change call type to ILLA 7) If patient with flu-like symptoms, especially fever: 7a) Has the patient traveled to Africa within the last 30 days? ………YES. Ask question 7b 7b) Which country in Africa? If answer includes Guinea, Liberia, or Sierra Leone ………………. Change the call type to HAZ Tell patient not to leave the area. Send Call ………………………………………………………………………………………Send Call 8) Anyone in the residence have any contagious diseases? Pre-Arrival Instructions: Reassure that help is on the way. Keep patient in comfortable position. Nothing to eat, drink, or medications. Gather all medications patient takes and have ready for paramedics. Any changes before we get there, call back.

Given the requirements stated below, please answer the following questions describing the conceptual design and user experience that would be proposed to meet these requirements.


B.8.14.1.1.1 C Any call type defined may have an associated EMD or EFD record.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 79 of 137


B.8.14.1.1.2 C Any call type may have a different EMD or EFD record for each jurisdiction.

B.8.14.1.1.3 C The EMD/EFD record, assigned to no jurisdiction will be the default record for all jurisdictions.

B.8.14.1.1.4 C The EMD/EFD record shall be displayed to the call taker after address verification and after the initial call type is entered. The call entry process shall be interrupted and the appropriate EMD or EFD is presented to the call taker.

B.8.14.1.1.5 C At any point in time, (after the EMD/EFD record is presented) the call taker shall be able to submit the call for dispatch without checking or clicking on each question presented in the record.

B.8.14.1.1.6 C The EMD/EFD record shall continue to be displayed to the call taker after the call has been submitted for dispatch.

B.8.14.1.1.7 C Any EMD/EFD record can be flagged as "present to the call taker after call entry". These records will not interrupt the call entry process but are still shown to the call taker providing guidelines for the CFS.

B.8.14.1.1.8 C Actions shall be easily performed from within the EMD/EFD record.

B.8.14.1.1.10 C

When a CFS type is changed using the EMD/EFD, display the EMD/EFD for the new CFS type.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 80 of 137

EMD/EFD Protocols Conceptual Design Proposed Solution Specifications


4.304.01 What mechanism or design pattern will be used to ensure that CAD presents an EMD or EFD record to the call taker based on requirements stated above?

4.304.02 Describe the data entities that will be involved in implementing the EMD/EFD functionality.






3.1.3 RESOURCE SUGGESTION PROGRAM The resource suggestion solution must optimize and efficiently utilize the emergency response resources belonging to 26 Fire/EMS jurisdictions and 2 private ambulance providers. These jurisdictions provide a variety of Fire and medical emergency services for their respective areas. Each jurisdiction needs to have the flexibility to dictate response policies for their designated areas. These jurisdictions operate within guidelines developed by what is known as the Automatic Aid Consortium. In general any Incident that is within the consortium’s boundaries will get the response designed for each jurisdiction’s area, using the closest (time or distance) capable resource from any jurisdiction within the Automatic Aid Consortium, regardless of jurisdictional boundaries. Dispatching policies may differ between each jurisdiction of the Automatic Aid Consortium. These policies go through periods of evolution based on the business requirements of individual jurisdictions. CAD is required to be highly configurable when it comes to building response plans. A CAD system with a highly configurable resource suggestion program manages these complex and highly dynamic response policies. This greatly removes the burden put on dispatch personnel to remember these policy differences that vary from one jurisdiction to the next. Examples of some of these response requirement policies are outlined below for reference.

Jurisdiction X requires one of their Battalion Chiefs to be suggested to any fire calls in another specified jurisdiction only if a resource from the Battalion Chief’s jurisdiction is selected for dispatch to that fire call.

Jurisdiction X requires a preference be applied to all their resources inside their jurisdiction (e.g. prefer their own resources anywhere inside their jurisdiction by some calculated time/distance amount over any other resource belonging to another jurisdiction).

Both Advanced Life Support (ALS) and Basic Life Support (BLS) resources can handle a BLS incident. However we would rather keep the ALS resource in service for use on Incidents requiring paramedic level




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 81 of 137

skills. To this end, CAD penalizes the ALS resource based on a configurable time or distance. Thus, the ALS resource will only be recommended for a BLS response if the ALS resource is appreciably closer than the closest BLS resource.

Conditional preferences and penalties: o For an ALS response we require a resource with an ALS capability and that a minimum of 4

personnel are required on this call. In this response plan CAD will initially penalize the BLS capability by some amount because we prefer an ALS capable resource.

o In a scenario where a 2 man ALS resource is the closest available and selected to satisfy the ALS requirement, the system shall continue to search for a resource with a full complement of personnel (4). This is because the response requirement included a minimum of 4 personnel.

o Having fulfilled the ALS requirement, we now need to penalize all ALS resources by some amount while searching for manpower (4). This minimizes the chance of selecting another ALS resource when not needed.

Some resources have specific capabilities that are only valid in specified jurisdiction(s). While other capabilities assigned to that same resource are valid in all jurisdictions.

Some resources have specific capabilities that are recommendable, however will not satisfy the requirement (e.g. this resource will be selected and dispatched because of the capability, however it will be backed up with another resource that will satisfy the requirement).

The requirements described below address a very wide range of factors that provide great flexibility when building a response plan. In consideration of the requirements stated below, answer the following questions describing the conceptual design and user experience that would be proposed to meet these requirements.


B.8.04.1 R Factors to be considered during resource suggestion: For the purpose of suggesting resources to any call for service. The following factors shall be considered by CAD's suggestion algorithm.

B.8.04.1.1 R A resource's name.

B.8.04.1.2 R A resource's status.

B.8.04.1.3 R A resource's type.

B.8.04.1.4 C A resource's calculated travel time and/or distance to the CFS.

B.8.04.1.5 C A resource's life support level.

B.8.04.1.6 I Capabilities assigned to a resource.

B.8.04.1.7 C Capabilities assigned to a vehicle associated with a resource.

B.8.04.1.8 C Personnel skills that are assigned to a resource (e.g. currently rostered on personnel).

B.8.04.1.9 C The number of personnel currently rostered on to a resource.

B.8.04.1.10 C The authorization of a resource to be used in a specified area/jurisdiction.

B.8.04.1.11 C The authorization of a resource's individual capability, a resource's individual vehicle capability, and a resource's individual personnel skill to be used in a specified area/jurisdiction. (e.g. One capability or personnel skill associated with a resource/person may be authorized in all areas/jurisdictions while another capability or personnel skill for the same resource/person is not).

B.8.04.1.12 C Resource types for a location - The location of a CFS shall specify pre-defined types of resources to be used for that location. such as, the ambulance provider, the police department, the utility company (gas, electric, etc.), etc.

B.8.04.1.13 C Additional requirements for a location - The location of the CFS may specify additional requirements. The requirements may be conditional based on Call type, Call category or Call response type.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 82 of 137


B.8.04.2 R Building Response Plans: The CAD system administrator shall have the ability to build response plans and assign those response plans to one or more call types. Response plans may be configured for each jurisdiction or geographic area within a jurisdiction by call type.

B.8.04.2.1 C Response plans shall have the following elements to be used by the suggestion algorithm.

B.8.04.2.1.1 R Name: Unique name or ID for each response plan.

B.8.04.2.1.2 R Alarm Level: The alarm level for this response plan.

B.8.04.2.2 C Closest Unit: A flag to indicate "send the closest fire department resource" even if that resource does not satisfy any of the response plan requirements. The suggestion algorithm shall only consider resources flagged as "able to be respond as the closest resource", configured by the CAD system administrator. A resource is considered closest and added to the resource suggestion, only if that resource is flagged as "able to respond as the closest" and does not satisfy any specified primary or secondary requirements, and is closer to the CFS by xx amount over the closest resource that satisfies a response plan requirement.

B.8.04.2.3 C Minimum Personnel Required: A response plan may specify the minimum number of personnel required. (e.g. add personnel currently on roster for each resource, consider only resources with the manpower capability.)

B.8.04.2.4 C Primary Requirements: The suggestion algorithm shall allow a resource to fill only one primary requirement.

B.8.04.2.4.1 C Primary requirements are processed first. If a resource satisfies a primary requirement, that resource shall be processed against all secondary requirements. That resource can satisfy as many secondary requirements as possible.

B.8.04.2.4.2 C Each primary requirement shall be checked in the order they are defined in the response plan.

B.8.04.2.5 C Secondary Requirements: The suggestion algorithm shall allow a single resource to satisfy as many unique secondary requirements as possible. After all primary requirements are processed, continue to satisfy any outstanding secondary requirements that are left.

B.8.04.2.5.1 C The following attributes (data elements) shall be available when defining a primary or secondary requirement.

B.8.04.2.5.2 C Count: specifies how many of this requirement.

B.8.04.2.5.3 C Type: requirement type (e.g. RN- a specific resource by name, RT- a resource of this type, C- a capability, S- a skill, etc.)

B.8.04.2.5.4 C Requirement: The actual requirement for the specified type.

B.8.04.2.5.5 C Deficiency flag: This flag shall be used to indicate what to do with the requirement if it is not found (e.g. I- ignore it, S- show it to the decision dispatcher, or T- track this deficiency on all CFS monitors).

B.8.04.2.5.6 C Jurisdiction: This requirement must be filled by a resource belonging to the CFS jurisdiction.

B.8.04.2.5.7 C Time of year and/or time of day: Add this requirement only if the CFS suggestion occurs within a specified time of year and/or time of day.

B.8.04.2.5.8 C Within a time/distance: Add this requirement only if the calculated travel time/distance of the resource is found to be within this specified time/distance value.

B.8.04.2.5.9 C Travel Code: When the specified requirement is found, add this travel code to the resource suggested.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 83 of 137


B.8.04.2.5.10 C Rotate this requirement: Consider all resources found with this requirement, suggest the available resource with the oldest time of dispatch, regardless of calculated travel time/distance.

B.8.04.2.5.11 C Conditional jurisdictional requirement for Command: Require the closest command officer from the specified jurisdiction, only if any other resources from the specified jurisdiction are suggested.

B.8.04.2.5.12 C System Mode: Add this requirement if the CAD system is found to be in a specified mode. (e.g. Heat mode, etc.)

B.08.04.2.6 C Preferences/Penalties defined in the response plan: Preferences and penalties are identical in structure and are differentiated only by a positive or negative value (Henceforth referred to as either a penalty or a preference).

B.08.04.2.6.1 C List of penalties: The response plan shall allow for a list of penalties and shall work by one of two methods described below.

B.08.04.2.6.1.1 C The general method: The resource suggestion algorithm shall apply all penalties to the entire resource consideration list before any of the resources are checked against any requirements. (Note: the resource consideration list is initially sorted by closest to furthest, i.e. determined by a road network routing solution)

B.08.04.2.6.1.2 C A conditional penalty: The response plan shall have the ability to configure a penalty to be applied in one way until the specified requirement is filled. Once the specified requirement is filled apply a different penalty (i.e. re-sort the consideration list) and then continue fulfilling requirements. (e.g. Penalize all BLS capability resources by an amount until an ALS capability is filled, then re-sort and penalize all resources with ALS capabilities by this amount, then continue fulfilling any outstanding requirements.)

B.08.04.2.6.1.3 C Defining a penalty: A penalty or preference shall be defined by the following elements.

B.08.04.2.6.1.3.1 C Type: the type of penalty. The following are different types.

B.08.04.2.6.1.3.2 C resource - a specific resource to apply a penalty or preference to

B.08.04.2.6.1.3.3 C resource type - a specific resource type to apply a penalty or preference to

B.08.04.2.6.1.3.4 C capability - a specific capability to apply a penalty or preference to

B.08.04.2.6.1.3.5 C personnel skill - a specific personnel skill to apply a penalty or preference to

B.08.04.2.6.1.3.6 C Name (ID): This is the name of the penalty. (e.g. if the type is "capability" this is the name of a specific capability. Thus resources found to have this capability receive the penalty)

B.08.04.2.6.1.3.7 C Penalty value: The actual penalty value, expressed as either a preference or penalty (e.g. -1 minute or +1 minute)

B.08.04.3 C Penalties defined outside of the response plan: The following penalties shall be configurable by a CAD administrator. These penalties are expressed outside of the response plan record. These penalties shall be applied to the initial resource consideration list by the suggestion algorithm before any response plan penalties and requirements are processed and filled.

B.08.04.3.1 C Penalties based on resource status: These penalties shall be applied if configured by a CAD administrator for resources found in various statuses, such as AIQ, AOR, AOV, etc. (e.g. different penalties may be applied to resources that are in these statuses. Available in Quarters, Available on radio, Available out of vehicle, Unavailable, Training, etc.)

B.08.04.3.1.1 C Jurisdictional preferences: A jurisdiction may want to apply a preference to all resources belonging to their jurisdiction.

B.08.04.3.1.2 C Jurisdictional penalties: A jurisdiction may want to penalize all resources of another specified jurisdiction.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 84 of 137


B.08.04.3.1.3 C Jurisdictional preference by resource type: A jurisdiction may want to specify a resource type from their jurisdiction to have a preference in their jurisdiction.

B.08.04.3.1.4 C Jurisdictional penalties by resource type: A jurisdiction may want to penalize resources of a specified type from another specified Jurisdiction.

B.08.04.3.2 C Global penalties for resources with no life support by type: For resources that have no life support capability, the CAD administrator shall be able to define a penalty for these resources by type of resource. (e.g. Cars may be penalized a few feet more than a Brush vehicle when at the same station)

B.08.04.4 C Special geographic area considerations: The following describes "special suggestion considerations by geographic area". These may require additional data elements configured at the geographic level in combination with additional data elements configured at the resource level. These elements are to be acted upon by the suggestion algorithm.

B.08.04.4.1 C For any specific geographic area, requirements and/or penalties may be defined independently of any response plan. These are to be added and part of any CFS response plan that may occur in a specified area. These requirements and/or penalties may be configured to always apply, or may be configured to apply conditionally based on the following. CFS category - Only if the CFS category is one of (e.g. Fire, Medical (ALS, BLS), Special Operations, etc.) CFS Type - Only if the CFS type is one of any system defined call type. CFS Response Type - Only if the CFS response type is one of any system defined response type. Time of Year and/or Time of Day - Only if within a date range and/or time range. Note: The suggestion algorithm shall process these geographic area requirements and/or penalties as part of the overall suggestion algorithm.

B.08.04.4.2 C Two resources assigned at the same station want to divide workload of a particular CFS category in their first due area geographically (e.g. resource #1 prefers to work fire category calls north of the station while resource #2 prefers to work fire category calls south of their station). This configuration should only affect those resources grouped in this way. All other resources considered outside of this group will satisfy requirements based on the design of the response plan. As for resources in this grouping, prefer the resource assigned to its preferred area by a specified amount (only for fire category calls).

B.08.04.4.3 C For any specific geographic area, restrictions based on medical capabilities and resource types may be defined.

B.08.04.5 C Suggestion algorithm: The resource suggestion algorithm shall consider all available and unavailable logged on resources.

B.08.04.5.1 C Get the resource consideration list: Resources shall be put into a list, ordered by closest to furthest based on calculated travel times or distances to the CFS. A road network routing solution shall be used to provide the ordered list of resources.

B.08.04.5.2 C Apply penalties: All penalties should be applied to the initial resource consideration list before attempting to fulfill any requirements.

B.08.04.5.3 C Start Processing: The re-ordered list of resources shall then be processed using the response plan requirements to determine the final resource suggestion. The ordered list of primary requirements should be processed first and for each primary requirement satisfied check to see if that resource can also satisfy any secondary requirements. After all primary requirements are satisfied, fulfill any outstanding secondary requirements that are left.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 85 of 137


B.08.04.5.4 C Special geographic area considerations: Any special geographic area considerations (penalties or requirements or restrictions) shall be part of the suggestion algorithm process.

B.08.04.5.5 C Check for conditional penalties: As requirements are being processed and satisfied, the list of resources may be re-ordered at any time during the suggestion algorithm, that is, if conditional penalties are defined for a requirement in the response plan.

B.08.04.5.6 C Balance of assignments: When a CFS is balanced, the call type or response type may be modified and the CFS is routed to the decision dispatcher queue. When selected, If additional resources are necessary, the balance suggestion will be shown to the dispatcher, reviewed, and subsequently dispatched. In this case the suggestion algorithm shall consider resources already assigned on the CFS when fulfilling any requirements of the "balance".

B.08.04.5.7 C Bypassed Resources: As requirements are being processed, if a resource would be able to satisfy a requirement (because it is found closest), however is unavailable (for whatever reason), this resource shall be put into a "resource bypass list". This "resource bypass list" shall be shown to the dispatcher when the final recommended suggestion is displayed. Additionally, after dispatching and before any dispatched resources arrive on-scene, if any bypassed resource becomes available, send a notification to the assigned TRO of the CFS.

B.08.04.5.8 C Deficiencies: As requirements are being processed, if no resources are found to satisfy a particular requirement. Obey the deficiency flag defined in the response plan for that requirement.

B.08.04.5.9 C Special Medical Capability Considerations:

B.08.04.5.9.1 C A resource with ALS or PLS or BLS capability can satisfy a BLS requirement.

B.08.04.5.9.2 C A resource with ALS or PLS capability can satisfy a PLS requirement.

B.08.04.5.9.3 C Two resources with PLS capability can satisfy a ALS requirement. (Restrictions may apply for specific resource types with PLS capabilities in specified jurisdictions)

B.08.04.5.10 C Performance: The entire resource suggestion process shall take no longer than 1 second. This includes the entire period from when the CFS is selected to when the full suggestion is displayed to the dispatcher.

Resource Suggestion Program Conceptual Design Proposed Solution Specifications


4.305.01 What mechanism or design pattern will be used to ensure that CAD considers all of the resource suggestion requirements stated above?

4.305.02 Describe the data entities that will be involved in implementing the resource suggestion functionality.


4.305.04 Describe how the CAD administrator can enable and configure Resource Suggestion.

4.305.05 Describe the impact of adding the described capability and future Resource Suggestion rules to the existing base package.

4.305.06 Describe the procedures and commands that would be performed by any users once the capability is configured.





Phoenix, AZ 85003 Phone: (602) 262-7181


Page 86 of 137

Resource Suggestion Program Conceptual Design Proposed Solution Specifications






Phoenix, AZ 85003 Phone: (602) 262-7181


Page 87 of 137

3.1.4 ROSTER FUNCTIONALITY PFDRDC requires that all first responders maintain a daily roster for safety and accountability. The roster is dynamic and needs to be maintained throughout each shift by the crew of each resource via the MDC. Given the requirements stated below, please answer the following questions describing the conceptual design and user experience proposed to meet these requirements.


F.6.0 Roster Functionality

F.6.1 C Roster: The mobile solution shall provide a form to indicate for any defined position the crew member assigned to that position during any particular time of day on any particular shift . (i.e., Captain, Engineer, FireFighter1, FireFighter2). (See Exhibit B for a screenshot of PFDRDC's current roster form.)

F.6.1.1 I The roster shall provide an IN/OUT feature for each crew member listed on the current roster form. At anytime during a shift, crew members may indicate their availability "IN or OUT" with the crew. (i.e., a single crew member may indicate at any time during their shift "OUT" of service and then subsequently at any time indicate they are "IN" service). This action shall be reported back to CAD and used by CAD for resource recommendation and additionally indicate the current staffing level of that unit.

F.6.1.1.1 I The roster shall indicate the radio ID currently assigned to each position of that resource. This ID is used by the radio interface to associate a resource and personnel to a portable radio.

F.6.1.1.2 R The ability to populate roster information from Telestaff. (Import automatically but don't accept without user approval)

F.6.1.2 I A submitted roster and any roster changes during a shift shall become part of the resource's history.

F.6.1.3 C The roster form shall have the capability to store and recall a default crew for each defined shift of that resource (i.e., A shift, B shift, C Shift).

F.6.1.4 I All submitted rosters are used by CAD's unit recommendation process when searching for available personnel skills (i.e., HazMat Specialist, Paramedic).

F.6.1.5 I Rosters shall be cleared by the system as defined by each jurisdiction based on shift change (i.e., Phoenix resources will have their roster cleared daily at 08:00, Goodyear will have their roster cleared every other day at 07:00 ).

F.6.1.6 I After the roster is submitted, CAD will respond with a message indicating current roster and a list of current capabilities assigned to the resources. The capability list shall indicate capabilities that are missing or added from the default capabilities of the resource.

F.6.1.7 C Ability to notify Command Officer, by text message or email, if a roster has not been submitted by a pre-defined time (i.e., by the time the resources go available on radio, or AOR).

F.6.1.8 I Ability to add ad-hoc individuals to a roster (i.e., civilians, riders, etc.). Shall be recorded in the resource history.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 88 of 137

F.6.1.9 I If a roster fails to be submitted by a predetermined time. Send a system defined message to the resources MDC whenever the resource indicates an available on radio (AOR) status, reminding the crew to complete their roster.

F.6.1.10 I For each resource as configured by the administrator, based on the skill capability of personnel rostered on, CAD shall send a message to the MDC when the life support level capability (ALS) or (BLS) may need to be changed based on the how many paramedics are rostered on.

Roster Functionality Conceptual Design Proposed Solution Specifications


4.306.01 What mechanism or design pattern will be used to ensure the desired roster functionality stated above?

4.306.02 Describe the data entities that will be involved in implementing the roster functionality.






3.1.5 INCIDENT RESOURCE MANAGEMENT PFDRDC requires a single display on the MDC to keep track of Incident resources as they are assigned, responding, staging and arriving on scene. Additionally, PFDRDC requires functionality that will manage resources based on tactical assignments. Both the TRO and MDC users require similar functionality. The tables below list the requirements from each of these perspectives. Given the requirements stated below, please answer the following questions describing the conceptual design and user experience that would be proposed to meet these requirements.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 89 of 137

File # Priority TRO Incident Resource Management Requirement

B.3.54 C Sector Assignments: Command officers on a call for service may group companies together to work in sectors to divide the CFS scene into smaller areas of command. Command officers will communicate with "Sector Officers" managing resources assigned to their sector. Most routine communications within a sector are conducted face-to-face between the Sector Officer and the Sector Members, thus reducing the overall radio communications. When effective sectors are established, Command can concentrate on overall strategy and resource allocation, allowing Sector Officers to manage their assigned resources and the tasks of their sector. The CAD system shall be used to keep track of sectors and resources assigned as Sector Officers and Sector Members. Resources may be assigned to a sector by a dispatcher (TRO) or from the MDC of a resource in command. Assigning a resource to a sector shall be considered an association and have no effect on the resource’s status. (e.g. a resource still has the status of on-scene and is associated with a sector.)

B.3.54.1 C Create Sectors and Assigning Resources: While assigned to a CFS, a command officer shall have the ability to create, or have the (TRO) create logical sectors and assign resources to those sectors. In CAD, a logical sector is defined by a single word, provided by the command officer, (E.g. ROOF, INTER, WEST, EAST, etc.) describing a general location or function on the event.

B.3.54.2 C CAD shall provide two methods for creating a logical sector and assigning a resource(s) to a sector as described below.

B.3.54.3 C Sector Officers: The TRO shall be able to initiate a function to create a logical sector and assign a resource to be the Sector Officer. The format of this function requires a resource name, sector name and an optional comment (e.g. [Sector Officer] E8 LOBBY, North Door < the function "[Sector Officer]" creates a logical sector called LOBBY and assigns E8 as the sector officer in charge with an additional comment of North Door). CAD shall allow only one "sector officer" per each logical sector name.

B.3.54.4 C Sector Members: The TRO shall be able to initiate a function to create a logical sector and add a resource to that sector. If the specified sector already exists, just add the specified resource to the sector as a Sector Member. The format of this function requires one or more resource name(s), a sector name and an optional comment (e.g. [Sector Member] E272 LOBBY, Assist E8). Many members may be assign to sectors. The TRO shall be able to remove the sector member assignments as desired.

B.3.54.5 C Record Sector assignments: All sector assignments shall be recorded in the CFS history.

B.3.54.6 C Removing sectors and assignments: CAD shall provide methods for removing sectors and assignments if desired.

B.3.54.7 C Be part of the Resource List Monitor: Sectors and assignments shall be part of the mobile Resource List Monitor and the Resource List Display described below. (see mobile functionality F.4.1 Resource List Monitor for more information)

B.3.55 C Resource List Display: The TRO shall be able to request a display with the following information for any active CFS.

B.3.55.1 C List all resources assigned to the CFS. The list shall be grouped by resource status. (e.g. dispatched, responding, staged, onscene, etc.)

B.3.55.2 C For each resource, indicate their status by color (i.e., responding, staged, onscene, etc.).

B.3.55.3 C For each responding resource, show the calculated time and distance to the CFS. Order these resources by calculated travel time.

B.3.55.4 C For each resource, list all displayable capabilities. Displayable capabilities are defined by the CAD administrator when creating capabilities.

B.3.55.5 C For each resource, indicate all requirement(s) a resource is satisfying on this CFS.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 90 of 137

File # Priority TRO Incident Resource Management Requirement

B.3.55.6 C Highlight a resource differently if that resource is not satisfying any response requirement. (Potential rouge resource added to CFS). Resources that assign themselves to calls may require approval.

B.3.55.7 C When the CFS alarm level becomes greater than 1, indicate resources that where added at alarm level 2, and then added at alarm level 3, etc.

B.3.55.8 C If a resource and its paired resource (co-manned) is on the CFS at the same time indicate this on the display.

B.3.55.9 C For each resource assigned to a sector, list the sector it has been assigned to. Resources assigned as sector officers shall be indicated differently than sector members. (see B.3.54.1 Creating Sectors and Assigning Resources above for more detail)

B.3.55.10 C For each resource, list the current roster members.

B.3.55.11 C For each resource, Indicate any roster exceptions (i.e., a resource has 3 crew members on the roster instead of the set default of 4).

File # Priority MDC Incident Resource Management Requirement

F.4.0 Command Officer Functionality

F.4.1 C Resource List Monitor: The mobile solution, when requested, shall provide an active monitor displaying the following information concerning the current call for service. (See Exhibit A for a screenshot of the current system's resource list.)

F.4.1.1 C Color-code definitions legend

F.4.1.2 C List all resources assigned to the CFS. The list shall be grouped by resource status (e.g. dispatched, responding, staged, onscene, etc.). Sorting and filtering of this list shall be available.

F.4.1.3 C For each resource, indicate their status by color (i.e., responding, staged, onscene, etc.).

F.4.1.4 C For each responding resource, show the calculated time and distance to the CFS. Order these rsources by calculated travel time.

F.4.1.5 C For each resource, list all displayable capabilities . Displayable capabilities are defined by the CAD administrator when creating capabilities.

F.4.1.6 C For each resource, indicate all requirement(s) a resource is satisfying on this CFS.

F.4.1.6.1 C Highlight a resource differently if that resource is not satisfying any response requirement. (potential rouge resource added to CFS). Reources that assign themselves to calls may require approval.

F.4.1.6.1.1 C When the CFS alarm level becomes greater than 1, indicate resources that where added at alarm level 2, and then added at alarm level 3, etc.

F.4.1.6.1.2 C If a resource and it's paired resource (co-manned) is on the CFS at the same time indicate this on the display.

F.4.1.6.2 C For each resource assigned to a sector, list the sector it has been assigned to. Resources assigned as sector officers shall be indicated differently than sector members. (see F.4.2 Creating Sectors and Assigning Resources below for more detail)

F.4.1.6.3 C For each resource, list the current roster members.

F.4.1.7 I for each resource, Indicate any roster exceptions (i.e., a resource has 3 crew members rostered instead of the set default of 4).

F.4.1.8 I list any ambulance transports that have occurred for this CFS. Display the hospital name for each ambulance transport.

F.4.2 I Creating Sectors and Assigning Resources: While assigned to a CFS, the command officer shall have the ability to create, or have the TRO create, logical sectors and assign resources to those sectors. In CAD a logical sector is defined by a single word provided by the command officer, (e.g. ROOF, INTER, WEST, EAST, etc.) describing a general location or function on the event.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 91 of 137

File # Priority MDC Incident Resource Management Requirement

F.4.2.1 I CAD shall provide two methods for creating a logical sector and assigning a resource(s) to that sector as described below.

F.4.2.2 I Sector Officers: CAD shall have a function to create a logical sector and assign a resource to be the Sector Officer. The format of this function requires a resource name, sector name and an optional comment (e.g. [Sector Officer] E8 LOBBY, North Door < the function "[Sector Officer]" creates a logical sector called LOBBY and assigns E8 as the sector officer with an additional comment of North Door). CAD shall allow only one "sector officer" per each logical sector name.

F.4.2.3 I Sector Members: CAD shall have a function to create a logical sector and add a resource to that sector. If the specified sector already exists, just add the specified resource to the sector as a Sector Member. The format of this function requires one or more resource name(s), a sector name and an optional comment (e.g. [Sector Member] E272 LOBBY, Assist E8 < the function "[Sector Member]" creates, if it doesn't exist, a logical sector called LOBBY and assigns E272 as sector member with an additional comment of Assist E8). Many members may be assigned to sectors.

F.4.2.3.1 R Drag and Drop sectors: Once a Sector has been created. The ability to drag and drop resources to a sector. (assigning resources to sectors this way instead of command line.)

F.4.2.4 I Record Sector assignments: All sector assignments shall be recorded in the CFS history.

F.4.2.5 I Note: Sector command(s) are typically executed from the tactical radio operator's (TRO) workstation assigned to the CFS. The command officer's mobile data computer shall be able to execute sector commands as well.

F.4.2.6 I Display Sectors on the Resource List Monitor: Once sectors and assignments have been created, they shall be displayed as part of the Resource List Monitor described above.

F.4.2.7 I Creating/Modifying Sectors: The command officer or the tactical radio operator(TRO) shall be able create/delete/modify sectors and assignments as needed.

F.4.2.8 I Command Officer Module Accessibility: The module allows sectors to be forwarded (used) on additional devices (i.e., from a mobile device to an iPad/tablet).

F.4.2.9 I Notify when a resources is adding to a CFS manually: Send a message to MDCs of a CFS when any resource adds themselves to a CFS manually.

F.4.2.10 I Notify Dispatch Supervisors when resources put themselves out of service, only for those resources configured by the administrator.

F.4.2.11 I Elapse Times: The ability to show elapse times based on milestone changes.

F.4.2.12 I Roster Display: Query and display roster information by district or jurisdiction.

Incident Resource Management Conceptual Design Proposed Solution Specifications


4.307.01 What mechanism or design pattern will be used to ensure the desired command functionality stated above?

4.307.02 Describe the data entities that will be involved in implementing the roster functionality.







Phoenix, AZ 85003 Phone: (602) 262-7181


Page 92 of 137

Incident Resource Management Conceptual Design Proposed Solution Specifications




3.1.93.1.6 ADDITIONAL CAD EFFICIENCIES PFD desires to consider all possible advantages of the Proposed Solution. While the CAD requirements of PFD have been described fully in this RFP (and attachments), it is understood that there may be additional opportunities or benefits that can be applied to PFD that have not yet been identified. Please use the response to this section to describe any additional advantages or benefits of the Proposed Solution that are not already requested elsewhere in this RFP.

Additional CAD Efficiencies Proposed Solution Specifications


4.308.01 Are there any current or future functions or features in the Proposed Solution that could be used by PFD to achieve efficiencies not addressed in the requirements?

3.2 PHOENIX FIRE SPECIFIC FUNCTIONALITY - RECORDS MANAGEMENT SYSTEM (RMS) The following sections describe requirements that are the highest priority for implementation of an integrated RMS and represent the planned initial scope of RMS for this project. PFD recognizes that there are alternative methods of satisfying these requirements. As part of the response to this section, Vendors are encouraged to showcase unique advantages of their Proposed Solution. More than one approach to satisfying the requirements may be presented for each section. PFD expects continuous improvement to be a focus from an operational perspective. Vendors should use their responses to the requirements below as an opportunity to demonstrate the method planned to support future improvements as the RMS supplier for PFD. The responses in this section should demonstrate the flexibility, interoperability, and extensibility of the Proposed Solution. The requirements that are included in each section below are a copy of subset of the full set of required functionality as described in ATTACHMENT A – FUNCTIONAL REQUIREMENTS WORKSHEET . NOTE: There is no “Vendor Response” column shown in the copied requirements tables. Responses to the individual requirements should be submitted with APPENDIX A – FUNCTIONAL REQUIREMENTS WORKSHEET. For this section (3.2 PHOENIX FIRE SPECIFIC FUNCTIONALITY – RECORDS MANAGEMENT SYSTEM (RMS)), a response is required ONLY for items where a Vendor Response/Comments column is available.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 93 of 137

3.2.1 CAD DATA All data that is generated and tracked during an Incident in the Proposed CAD Solution will transfer to the Proposed RMS. This transfer will take place when certain events are reached (e.g. when a resource leaves an Incident, an Incident closes, or some time interval during the Incident) during the Incident and response so that members can use RMS reporting functions, such as Incident and Exposure reporting while the Incident is still open. This is a necessary function so that resources that have already gone available off the Incident have an opportunity to report information without waiting until all resources are off the Incident. PFD requires that ad-hoc reporting will be available. This reporting functionality will allow any data field in the “CAD” data to be included in the reports. Additionally, the reports will allow for the data to be filtered or grouped on any data field in the CAD data. Summary reporting will available to meet the needs of reporting response statistics such as call taking time, total response time, etc. See EXHIBIT A – FUNCTIONAL REQUIREMENTS WORKSHEET, TAB D – FIRE RMS for a complete list of data elements required for the CAD Data.

Priority Requirement

D.1.1 Incident Reporting - CAD Incident Data

D.1.1.1 R Ability to capture the following CAD incident data. For the list of fields to capture, please refer to the spreadsheet.

D.1.1.1.22 R Ability to update incident call type and location information if different from initial incident dispatch

D.1.1.1.23 R Ability to Track whether an Incident had any of the following Incident Tags. For the list of incident tags, please refer to the spreadsheet.

D.1.1.2 CAD Incident Unit Data

D.1.1.2.01 R Ability to capture the following responder information (each unit). For the list of fields for responder information, please refer to the spreadsheet.

D.1.1.2.02 R Unit Times: For the list of fields for unit times, please refer to the spreadsheet.

D.1.1.2.03 R Transport Information: For the list of fields for transport, please refer to the spreadsheet.

D.1.1.3 CAD Incident Personnel Data

D.1.1.3.01 R Ability to track all of the following information about members on an Incident. For the list of fields to capture about members, please refer to the spreadsheet.

D.1.1.4 CAD Incident Data Interfaces

D.1.1.4.01 R Ability to Interface with GIS and Fire Department GIS System (ESRI)

CAD Data Proposed Solution Specifications


4.309.01 How does the standard Proposed Solution address the CAD Data requirement?

4.309.02 What configuration options are available to address the CAD Data requirement?

4.309.03 What aspects of the Proposed Solution need to be augmented to address the CAD Data requirement?

4.309.04 What are the configuration options for the frequency and triggering events that cause the transfer of incident data from CAD to RMS?




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 94 of 137

3.2.2 NFIRS REPORTING The Proposed Solution will allow first responders to submit an Incident disposition report that follows the standards specified by the National Fire Incident Reporting System (NFIRS). The Proposed Solution will allow these Incident reports to be filled out from the Mobile Data Computer (MDC) in the Fire Apparatus. The Proposed Solution will periodically generate the required files for an electronic submittal into NFIRS. PFD requires that ad-hoc reporting will be available. This reporting functionality will allow any data field in the “NFIRS Reporting” information to be included in the reports. Additionally, the reports will allow for the data to be filtered or grouped on any data field in the NFIRS Reporting information. Please refer to EXHIBIT A – FUNCTIONAL REQUIREMENTS WORKSHEET, TAB D – FIRE RMS and the NFIRS Version 5.0+ standard for a list of the specific information that will be tracked for NFIRS reporting.


D.1.2 Incident Reporting - Fire Incident Reporting

D.1.2.1 R Fire Incident Reporting features include the following. For the list of features, please refer to the spreadsheet

D.1.2.2 Fire Incident Reporting - Fire Data For list of fields for fire data, please refer to the spreadsheet.

D.1.2.3 Fire Incident Reporting - Structure Data For list of fields for structure data, please refer to the spreadsheet.

D.1.2.3.14 R Automatic Extinguishing System Present (No/Yes/Partial/Unknown), including. For details, please refer to the spreadsheet.

D.1.2.4 Fire Incident Reporting - Misc

D.1.2.4.01 V Allow Fire Incident Reports to be filled out from the Mobile Computer Terminals in the Fire Apparatus

D.1.2.4.02 I List of values for Action Taken/Area of Origin should be based on the Situation Found

D.1.2.5 Fire Incident Data Interfaces

D.1.2.5.01 I Ability to generate files for electronic submittal into the Nation Fire Incident Reporting System (NFIRS)

NFIRS Reporting Proposed Solution Specifications


4.310.01 How does the standard Proposed Solution address the NFIRS Reporting requirement?

4.310.02 What configuration options are available to address the NFIRS Reporting requirement?

4.310.03 What aspects of the Proposed Solution need to be augmented to address the NFIRS Reporting requirement?




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 95 of 137

3.2.3 EXPOSURE REPORTING PFD requires the tracking of personnel exposures to toxic/hazardous materials and infectious/communicable diseases. The Proposed Solution will allow First Responders to submit these exposure reports immediately following their completion of work on the incident. Exposure reports will be filled out from the MDC or from the station RMS computer. The exposure reporting data will be available to the Phoenix Fire Health Center and all participating agency members. This will provide a complete history of the members’ exposures over their career. PFD requires that ad-hoc reporting will be available. This reporting functionality will allow any data field in the “Exposure Reporting” information to be included in the reports. Additionally, the reports will allow for the data to be filtered or grouped on any data field in the Exposure Reporting information. Please refer to EXHIBIT A – FUNCTIONAL REQUIREMENTS WORKSHEET, TAB D – FIRE RMS for a list of the data elements that will be collected on the exposure reports.


D.2.3.2 R Ability to track Personnel exposure to Toxic/Hazardous materials (on mobile and network devices): For details, please refer to the spreadsheet

D.2.3.2.24 V Allow the entry of personnel exposures to Toxic/Hazardous materials from the Mobile computers.

D.2.3.3 R Ability to track Personnel exposure to Infectious/Communicable Diseases. For details, please refer to the spreadsheet

D.2.3.3.15 V Allow the entry of personnel exposures to Infectious/Communicable materials from the Mobile computers

Exposure Reporting Proposed Solution Specifications


4.311.01 How does the standard Proposed Solution address the Exposure Reporting requirement?

4.311.02 What configuration options are available to address the Exposure Reporting requirement?

4.311.03 What aspects of the Proposed Solution need to be augmented to address the Exposure Reporting requirement?

3.2.4 HYDRANT INFORMATION MANAGEMENT In order for PFD members to have the best possible information available when responding to an Incident, the Proposed Solution will provide hydrant information management. This information will include the location and capacity of all hydrants available for fire suppression. This will include the ability for First Responders to perform and document hydrant testing and report Hydrant problems. PFD requires that ad-hoc reporting will be available. This reporting functionality will allow any data field in the “Hydrant” information to be included in the reports. Additionally, the reports will allow for the data to be filtered or grouped on any data field in the hydrant information. Please refer to EXHIBIT A – FUNCTIONAL




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 96 of 137

REQUIREMENTS WORKSHEET, TAB D – FIRE RMS for all the information that will be include in hydrant information management.


D.4.6 Hydrants

D.4.6.1 I Ability to capture and maintain the following fire hydrant information. For list of fields to capture for hydrants, please refer to the spreadsheet

D.4.6.2 I Ability to maintain the following hydrant test information. For list of fields to maintain for hydrant test, please refer to the spreadsheet

D.4.6.2.05 I Ability to calculate flow rate given pressure readings

D.4.6.2.06 I Ability to maintain history of testing dates and results

D.4.6.2.07 I Ability to auto update CAD of results for inclusion in dispatching calls for service

D.4.6.3 Hydrant Reporting

D.4.6.3.01 I Ability to inquire into hydrant records. For details, please refer to the spreadsheet

Hydrant Information Management Proposed Solution Specifications


4.312.01 How does the standard Proposed Solution address the Hydrant Information Management requirement?

4.312.02 What configuration options are available to address the Hydrant Information Management requirement?

4.312.03 What aspects of the Proposed Solution need to be augmented to address the Hydrant Information Management requirement?

3.2.5 PREMISE INFORMATION MANAGEMENT Premise information that alerts anyone in the Automatic Aid Consortium to special issues that they may be facing while responding to an Incident is valuable in protecting firefighters, citizens, and property. The Proposed Solution will provide fire personnel (inspectors, firefighters, etc.) the ability to record and track information relating to premises in a particular location or area. This information could include, but is not limited to: the location of the issue associated with the premise, Fire Protection/Life Safety features onsite, any hazardous materials on-site, special premise alerts, and premise contact information. PFD requires that ad-hoc reporting will be available. This reporting functionality will allow any data field in the “Premise information” to be included in the reports. Additionally, the reports will allow for the data to be filtered or grouped on any data field in the Premise information. Please refer to EXHIBIT A – FUNCTIONAL REQUIREMENTS WORKSHEET, TAB D – FIRE RMS for the complete list of information to be tracked about a premise.


D.5.1 Premise Information

D.5.1.1 R Ability to capture and maintain building and occupancy information, including. For list of fields to capture for building and occupancy information, please refer to the spreadsheet

D.5.1.2 Inspection Reporting




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 97 of 137


D.5.1.2.1 R Ability to retain location history file with indefinite off-line retention period

D.5.1.1.54 R Ability to track new construction and inspections

D.5.1.1.52 R Ability to track Fire Prevention activity and occupancy history by business name/address

D.5.1.3 Responsible Party Information For details, please refer to the spreadsheet

D.5.1.4 Building Characteristics

D.5.1.4.1 R Ability to capture and maintain building characteristics information, including. For list of fields to capture for building characteristics, please refer to spreadsheet

D.5.1.5 Fire Protection/Life Safety Features

D.5.1.5.01 R The proposed Fire RMS includes the following Fire Protection/Life Safety-related functionality.

D.5.1.5.02 R Ability to capture and maintain fire protection features associated with a business, including For list of fields to capture for fire protection features, please refer to spreadsheet

D.5.1.6 Building/Occupancy Data

D.5.1.6.01 R Ability to display or print building/occupancy detail report For details, please refer to the spreadsheet.

D.5.1.6.02 R Ability to display or print occupancy history, including incident reports, 2 - Inspections, 3 - Permits, violations and citations, and correspondence and contact log. For details, please refer to the spreadsheet.

D.5.1.6.03 R Ability to print self-inspection materials for selected occupancies with variables from occupancy record including: For details, please refer to the spreadsheet.

D.5.1.6.0.5 R Ability to query into building and occupancy information. For details, please refer to the spreadsheet.

Premise Information Management Proposed Solution Specifications


4.313.01 How does the standard Proposed Solution address the Premise Information Management requirement?

4.313.02 What configuration options are available to address the Premise Information Management requirement?

4.313.03 What aspects of the Proposed Solution need to be augmented to address the Premise Information Management requirement?

3.2.6 PROTECTIVE EQUIPMENT INFORMATION MANAGEMENT The Proposed Solution will provide PFD with the ability to track all Protective Equipment issued to fire personnel. Proper tracking, inspection, and maintenance of protective equipment is imperative to the safety of the fire personnel responding to Incidents. The Proposed Solution will track detailed information about every piece of equipment as well as a history of any maintenance and inspections that have been performed on that equipment. The Proposed Solution will provide reporting to allow the PFD Resource Management Division to query the system for all equipment that is due for preventive maintenance and to whom it is assigned. Reports will be available to provide the PFD Resource Management Division with a quick way to identify all the members that would need to be contacted in the event of an equipment recall.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 98 of 137

PFD requires that ad-hoc reporting will be available. This reporting functionality will allow any data field in the “Protective Equipment” information to be included in the reports. Additionally, the reports will allow for the data to be filtered or grouped on any data field in the Protective Equipment information. See EXHIBIT A – FUNCTIONAL REQUIREMENTS WORKSHEET, TAB D – FIRE RMS for the detailed information that will be tracked on all protective equipment.


D.4.3 Equipment Data

D.4.3.1 R Ability to capture and maintain the following equipment inventory information (for ALL equipment): For list of fields to capture for equipment inventory , please refer to the spreadsheet.

D.4.3.2 Equipment Reporting

D.4.3.2.01 R Ability to Display/Print Equipment Details by Equipment ID

D.4.3.2.02 R Ability to Display/Print Equipment Details by Serial Number

D.4.3.2.03 R Ability to provide audit trail of deleted or archived equipment records (e.g., sold, surplus, destroyed, etc.)

D.4.3.2.04 R Ability to Display/Print Equipment List by Equipment Type

D.4.3.2.05 R Ability to Display/Print Equipment List by Employee

D.4.3.2.06 R Ability to Display/Print Equipment List by Vehicle

D.4.3.2.07 R Ability to Display/Print Equipment List by Station

D.4.3.2.08 R Ability to Display/Print Equipment List by Next Preventative Inspection Date

D.4.3.2.09 R Ability to Display/Print Equipment List by Next Preventative Maintenance Date

D.4.3.2.10 R Ability to Display/Print Equipment List by Purchased Date Range

D.4.3.2.11 R Ability to Display/Print Equipment List by In Service Date Range

D.4.3.2.12 R Ability to Display/Print Equipment List by End of Service Date Range

D.4.3.2.13 R Ability to Display/Print Equipment List Manufacturer

D.4.3.3 Equipment Interfaces

D.4.3.3.01 C Ability to Capture Equipment Information by Bar Code Reader

D.4.3.3.02 C Ability to Issue/Change Equipment Issue by Bar Code Reader

D.4.3.3.03 C Ability to Interface with City Asset System (SAP) and two way integration with other existing tracking systems (e.g. Electronic LSD).

Protective Equipment Information Management Proposed Solution Specifications


4.314.01 How does the standard Proposed Solution address the Protective Equipment Information Management requirement?

4.314.02 What configuration options are available to address the Protective Equipment Information Management requirement?

4.314.03 What aspects of the Proposed Solution need to be augmented to address the Protective Equipment Information Management requirement?

3.2.7 TRAINING AND CERTIFICATION INFORMATION PFD is required to track all training provided and acquired by its members. This training includes formal education, classes taken, certifications, and skills acquired. The Proposed Solution will provide a complete training records management solution for tracking this information. This system will automatically notify members




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 99 of 137

and their supervisors when certifications are about to expire. There are many specific reporting requirements that are mentioned in EXHIBIT A – FUNCTIONAL REQUIREMENTS WORKSHEET, TAB D – FIRE RMS. PFD requires that ad-hoc reporting will be available. This reporting functionality will allow any data field in the “Training and Certification” information to be included in the reports. Additionally, the reports will allow for the data to be filtered or grouped on any data field in the Training and Certification information. See EXHIBIT A – FUNCTIONAL REQUIREMENTS WORKSHEET, TAB D – FIRE RMS for the detailed information that will describe tracking of training and certifications.


D.3 Training

D.3.1 Education

D.3.1.1 R Degrees Earned (multiple) For more details on degrees, please refer to the spreadsheet

D.3.2 Certification

D.3.2.2 Ability to maintain employee license and certification information. For list of fields of employee license and certification, please refer to the spreadsheet

D.3.3 Ability to maintain employee skill information. For more details on employee skills, please refer to spreadsheet

D.3.4 Training Classes

D.3.4.1 Training Class Information. For more details, refer to the spreadsheet

D.3.4.2 Training Class Roster. For more details, refer to the spreadsheet

D.3.5 Recruit Evaluation Information For more details, refer to the spreadsheet

D.3.6 Training Reporting

D.3.6.1 Education Reports

D.3.6.1.01 C Ability to Display/Print Education history detail for any Employee

D.3.6.1.02 R Ability to Display/Print Employees by Degree

D.3.6.2 Certification Reports

D.3.6.2.01 I Ability to Display/Print Employees by Certification

D.3.6.2.02 R Ability to Display/Print Certifications by Employee

D.3.6.2.03 R Ability to Display/Print Certification Hours by Employee

D.3.6.2.04 C Ability to Display/Print Certification Expiration by date

D.3.6.2.05 R Ability to Display/Print Missing Certifications By District

D.3.6.2.06 R Ability to Display/Print Missing Certifications By Battalion

D.3.6.2.07 C Ability to Display/Print Missing Certifications By Employee

D.3.6.3 Certification Dashboard

D.3.6.3.01 R Ability to group employees into cohorts based on specialty, certification, organization, etc.

D.3.6.3.02 R Ability to create and display a dashboard of skills required by job/certification (that groups skills and classes to create a "program" or curriculum for each certification objective).

D.3.6.3.03 R Ability to maintain and track employee training class information to include the following (continuing education training - training types vs time vs type accumulated with rules for required training in each cycle):

D.3.6.3.04 R Ability for one class to be able to fulfill multiple certification requirements across different certification programs

D.3.6.3.05 R Ability to provide status of continuing education (CE) requirement compliance (with the ability to notify employee and training supervisor when expiration dates are approaching, when classes are missed, and when the next class will occur)




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 100 of 137


D.3.6.3.06 R Ability to report on status vs. reporting requirements (History of what courses in a date range are available, what must happen in order for the person to be compliant)

D.3.6.4 Skills Reports

D.3.6.4.01 R Ability to Display/Print Employees by Skill

D.3.6.4.02 R Ability to Display/Print Skills by employee

D.3.6.4.03 C Ability to Display/Print Skill Hours by employee

D.3.6.4.04 C Ability to Display/Print Missing Skills By District

D.3.6.4.05 C Ability to Display/Print Missing Skills By Battalion

D.3.6.4.06 C Ability to Display/Print Missing Skills By Employee

D.3.6.5 Class Reports

D.3.6.5.01 C Ability to Display/Print a Listing of all training classes and hours

D.3.6.5.02 R Ability to Display/Print a Class Roster for Any class

D.3.6.5.03 C Ability to Display/Print Classes attended by Any Employee

D.3.6.5.04 R Ability to Display/Print Classes by Date Range

D.3.6.5.05 C Ability to Display/Print Classes by Certification Type

D.3.6.5.06 R Ability to Display/Print Classes by Skill Type

D.3.6.5.07 R Ability to Display/Print Classes by Instructor

D.3.6.5.08 R Ability to Display/Print Instructor Hours by class and type

D.3.6.5.09 R Ability to Display/Print Missing Mandatory Classes By District

D.3.6.5.10 R Ability to Display/Print Missing Mandatory Classes By Employee

D.3.6.5.11 R Ability to Display/Print Missing Mandatory Classes By Battalion

D.3.6.6 Recruit Evaluation Reports

D.3.6.6.01 I Ability to Display/Print Evaluations of Recruits

D.3.6.7 General Reporting

D.3.6.7.01 R Ability to Display/Print Individual Training Summary or Detail listing

D.3.6.7.02 R Ability to Display/Print Monthly Training Summary

D.3.6.7.03 C Ability to Display/Print Ad Hoc reports

D.3.6.7.04 I Ability to enter and track mandated training requirements (e.g., NFPA, OSHA, etc.)

D.3.6.7.05 R Ability for agency to easily generate user-defined reports

D.3.7 Notifications

D.3.7.1 R Ability to Notify Employees when a Certification is Expiring

D.3.7.2 R Application produces warning messages and sends them to the employee, supervisor, and concerned managers

D.3.7.3 R Ability to generate notification of completed training classes (workflow notification process through central training management monitoring step)

D.3.7.4 R Ability to Notify Employees of Class Enrollment

D.3.7.5 R Ability to Notify Employees Missing a Mandatory Certification and notify supervisors and other monitoring managers (e.g. program manager)

D.3.7.6 R Ability to Notify Employees Missing a Mandatory Skill

D.3.7.7 R Ability to Notify Employees Missing a Mandatory Class

D.3.8 Training Interfaces

D.3.8.1 C Ability to Interface with City Personnel Systems (eCHRIS and PeopleSoft), and link to Skillsoft automatically

D.3.8.2 C Ability to Interface with Online Training/eLearning Tool (Moodle)

D.3.8.3 C Ability to integrate with other training systems as needed in the future

D.3.8.4 C Ability to configure automatic feed parameters for records transfer (e.g. xAPI data collection)




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 101 of 137


D.3Sy.8.5 C Ability to pull a result of queries as a list of employees into department wide communication medium (email or messaging facility)

D.3.8.6 C Ability to download query results to Excel

Training and Certification Information Proposed Solution Specifications


4.315.01 How does the standard Proposed Solution address the Training and Certification Information requirement?

4.315.02 What configuration options are available to address the Training and Certification Information requirement?

4.315.03 What aspects of the Proposed Solution need to be augmented to address the Training and Certification Information requirement?

3.2.8 ADDITIONAL RMS EFFICIENCIES PFD desires to consider all possible advantages of the Proposed Solution. While the RMS requirements of PFD have been described fully in this RFP (and attachments), it is understood that there may be additional opportunities or benefits that can be applied to PFD that have not yet been identified. Please use the response to this section to describe any additional advantages or benefits of the Proposed Solution that are not already requested elsewhere in this RFP.

Additional RMS Efficiencies Proposed Solution Specifications


4.316.01 Are there any current or future functions or features in the Proposed Solution that could be used by PFD to achieve efficiencies not addressed in the requirements?

4. SYSTEM ARCHITECTURE AND TECHNICAL DESIGN The Vendor will identify the computer hardware and system software platform required to install and operate the proposed application. If the application operates on many different platforms the Vendor must select a platform and submit it as part of the Proposed Solution. This is required to fully evaluate the Vendor’s Proposed Solution. Subsequent discussions may alter the proposed platform. This response must include Vendor’s preferred operating system, support, or utility software with appropriate release levels, operation requirements, connectivity requirements, and disaster recovery program. The City retains the right (i.e., option) to purchase any of the equipment, operating system software, databases, and third party software included in the Vendor’s Proposal directly from City sources. Should the City exercise its option to purchase any of the equipment, operating system software, databases, and third party software included in the Vendor’s Proposal, it will purchase only equipment and software meeting the Vendor’s specifications. Please address the proposed computer hardware and system software platform requirements, as indicated above, in standard paragraphs and diagrams as required. The City will designate locations for the system's




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 102 of 137

servers, interface gateways, and associated equipment in City facilities which contain appropriate environmental, power, HVAC, and communications equipment. 4.1 SERVER SOLUTION The City of Phoenix has standardized on Windows Server 2012 SR2 or later, Oracle Linux & Solaris, and Linux Redhat for server operating systems. The City also utilizes virtualization for Windows and Linux on VMware ESX and Solaris zoning on Sparc architecture. The City utilizes Hitachi storage infrastructure and Cisco for Layer 2-3 network infrastructure. The City’s strategy is to virtualize servers on existing infrastructure before procuring and implementing new, standalone server infrastructure. The City utilizes both Oracle and SQL databases for its large three tiered applications. Please answer the following questions in the table below.

Server Infrastructure Environment Proposed Solution Specifications

Response ID Requirements

Vendor Response Comments

4.401.01 Please specify any special systems requirements or physical hardware required by proposed computer hardware and system software platform solution.

Do Not Rate

4.401.02 Please describe the types of server environments required by the Proposed Solution (i.e. application, database, backup, web, reporting, etc. as required).

Do Not Rate

4.401.03 State the recommended processors (CPU) speed, number of and type, per server.

Do Not Rate

4.401.04 State the preferred recommended operating system (OS) software for each server type.

Do Not Rate

4.401.05 Proposed Solution provides advanced archiving and purging tools and features that may be used to distribute data to different database instances and on different storage infrastructure tiers.

4.401.06 Proposed Solution can integrate, “out of the box”, with industry standard tape management/system tools/backup. For example CommVault or Veritas NetBackup.

4.401.07 Proposed Solution supports Simple Network Management Protocol (SNMP) v3and monitoring and problem alerting

4.401.08 Does the Proposed Solution provide central administration and monitoring for reporting? If so, describe.

Do Not Rate

4.401.09 PLEASE NOTE: The City prefers that a system development environment is implemented that can be used to configure, load data, and test the Proposed Solution during implementation.

4.401.10 Please describe your typical environments setup as you move thru development, testing and cutover.

Do Not Rate

4.401.11 Identify the types and number of environments that will need to be created and maintained during the project implementation, cutover and post go live. Please describe how test, staging, and production

Do Not Rate




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 103 of 137

Server Infrastructure Environment Proposed Solution Specifications



environments will be kept separate and isolated for security purposes.

4.401.12 Please describe your database refresh process for each environment.

Do Not Rate

4.401.13 PLEASE NOTE: The City intends to purchase and install all server hardware, software and operating systems. The Vendor will be responsible for the installation of the Proposed Solution and working with City and PFD technical staff to establish the pre-production and production environments.

4.401.14 Please explain your process for installing application software and programs when the hardware and software is provided by City and PFD IT staff.

Do Not Rate

4.401.15 Please describe the steps taken to define and document the installation and setup requirements on servers and database environments.

Do Not Rate

4.401.16 Please describe your process for developing mutually agreed upon test plans to validate system environments.

Do Not Rate

4.401.17 Please describe your process for fine tuning the database environments (sizing, performance logs, audits, etc.)

Do Not Rate

4.401.18 Please describe your process for determining appropriate number of application and web servers.

Do Not Rate

4.401.19 Please describe the application platform used to develop the application (Microsoft .NET, Java, etc.) and other application dependencies (Microsoft IIS, Apache, etc.)

Do Not Rate

4.2 SECURITY REQUIREMENTS This section of the RFP is comprised of questions to ascertain knowledge about how security is architected and supported for the Proposed Solution. Vendor should respond to each of the following requirements in the table below. Please include any diagrams or additional attachments necessary to convey all relevant information.

Security Requirements Proposed Solution Specifications



4.402.01 Please describe your recommended security architecture over layer 2 (data link) and layer 3 (network) type distributed networks. Please describe data flows between client and server generically.

Do Not Rate

4.402.02 Describe TCP/IP ports and/or other protocols used by the Proposed Solution to transmit data.

Do Not Rate

4.402.03 Proposed Solution uses only secured protocols.

4.402.04 If any unsecured protocols are used such as HTTP, FTP, SMTPv2, or telnet, please provide business justification.

Do Not Rate

4.402.05 Describe the authentication and access method utilized by the Proposed Solution to securely authenticate and

Do Not Rate




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 104 of 137




authorize access to users of the Proposed Solution in a multi-agency/regional setting.

4.402.06 Proposed Solution has the capability for Active Directory authentication and access of City of Phoenix employees, while offering non-AD authentication for non-City of Phoenix employees (i.e. other external partner agencies)

4.402.07 Proposed Solution has the capability to utilize multiple Active Directory forests/domains for user authentication and access.

4.402.08 Proposed Solution has the capability to protect data in motion and at rest. Include details on encryption methods utilized to secure data.

4.402.09 Proposed Solution provides audit capabilities to monitor and report application level, privileged use and system changes. Please provide details.

4.402.10 Proposed Solution has the capability to provide multiple levels of secured system access for authorizing access to information or business application functions at different degrees.

4.402.11 The Proposed Solution shall not, under any circumstances, prohibit one user from reading or modifying an incident, resource, or resource activity record while another user has the same record open. For example, it shall be possible for a dispatcher to be reviewing an incident and assigning resources to that incident while another user is updating the same incident.

4.402.12 Proposed Solution enable secure connectivity and data exchange to/from Mobile Computer Terminals (MCTs) in the apparatus.

4.402.13 Vendor can demonstrate that there are adequate security controls and safeguards though third-party, independent auditing.

4.402.14 Vendor has a formal security incident response process for responding to security incidents, and notifying customers proactively throughout incidents. This may include vulnerabilities in the Proposed Solution.

4.402.15 All PFD data is housed in the continental United States. Please describe whether there would ever be any circumstances when PFD data would either traverse or rest outside of the continental United States.

4.402.16 Proposed Solution provides controls that protect the system from unauthorized user access/modification and outage due to attack. Please provide details.

4.402.17 Proposed Solution has the capability to centrally manage security configuration settings and changes for client software.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 105 of 137




4.402.18 Describe security event monitoring and alerting capabilities. What options are available for logging the application and platform to tie the Proposed Solution into the City’s Security Incident and Event Monitoring (SIEM) system, Splunk.

Do Not Rate

4.402.19 Describe the options for securing the system if a mobile device or computer that accesses the system is lost or stolen.

Do Not Rate

4.3 HIGH AVAILABILITY, BUSINESS CONTINUITY, and DISASTER RECOVERY PFD has two Fire Department Communication Centers separated by ~5 miles that serve to host front line and critical emergency response special systems (i.e. CAD, RMS, Dispatch, Audio Logging, Radio Communications, etc.). PFD models these two facilities after NFPA Standard 1221 Chapter 4 Communication Centers Standard. Please answer the following questions in the table below and include any diagrams or additional attachments necessary to convey all relevant information.

High Availability, BC/DR Proposed Solution Specifications



4.403.01 Proposed Solution supports a high availability hardware and software configuration within one single data center. Include any detailed requirements or architectural diagrams to explain. Please describe any additional details and/or diagrams.

4.403.02 Proposed Solution supports a high availability hardware and software configuration between multiple data centers. Include any detailed requirements or architectural diagrams to explain. Please describe any additional details and/or diagrams.

4.403.03 Proposed Solution provides for an Active/Active CAD configuration. Include any detailed requirements or architectural diagrams to explain. Please describe any additional details and/or diagrams.

4.403.04 Proposed Solution provides for an Active/Passive CAD configuration. Include any detailed requirements or architectural diagrams to explain. Please describe any additional details and/or diagrams.

4.403.05 Proposed Solution shall be available and fully functional to meet industry standard high availability uptime and agreed upon routine maintenance windows.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 106 of 137




4.403.06 The Proposed Solution shall respond to any user request from any device, excluding transactions which involve interaction with an application or system not supplied by the vendor and exclusive of network delay, within two seconds under the following load:

60 concurrent dispatch personnel logged on and operating normally

1000 mobile units logged on and operating normally

100 incidents pending or waiting for action

200 incidents active EXPLANATION REQUIRED: Vendors shall describe how they intend to demonstrate the ability of the Proposed Solution to meet these performance requirements.

4.403.07 The Proposed Solution does not have any scalability limitations, regarding quantity of concurrent users and devices interfacing with it. Please describe how the Proposed Solution scales to meet future capacity and performance needs.

4.403.08 Exclusive of network delays, the Proposed Solution shall refresh all status monitors, within one second of a status change or other transaction, which must be displayed on the status monitor.

4.403.09 Proposed Solution does not allow the failure of any single component to disable the entire system. Please provide additional details.

4.403.10 The Proposed Solution shall allow PFD to add workstations to the system without requiring the system to be restarted.

4.403.11 Proposed Solution is architected to provide automatic and seamless CAD system failover for all interfaces, MCTs, and CAD Workstations without losing session state data.

4.403.12 Proposed Solution DOES NOT require manual intervention for failover to take place.

4.403.13 Notwithstanding the above requirements, the Proposed Solution shall provide the capability to manually initiate a failover.

4.403.14 Please detail any system operations or processes that may prevent the system from meeting its response time objectives.

Do Not Rate




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 107 of 137




4.403.15 The proposed application shall not fail three or more times per annum for the same reason, regardless of the downtime associated with each failure. EXPLANATION REQUIRED: Vendors shall provide a reference to any installation of the vendor’s CAD software that has failed more than three (3) times, describe the failure(s), why the system(s) failed and the how the system(s) was/were recovered.

4.403.16 Please describe the methodology that will be used for measuring system response time. The City reserves the right to review and approve the methods used to measure system response time.

Do Not Rate

4.403.17 Proposed Solution accomplishes automatic failover by having a duplicate server available with access to all the data necessary and required to start at the point where the primary server stopped.

4.403.18 Proposed Solution provides a capability to continuously monitor CAD interfaces (e.g. equipment failures, device exceptions, and time-outs).

4.403.19 Proposed Solution, upon detection of system faults or failures, sends an appropriate message to the dispatch supervisor and designated dispatcher workstations, accompanied by visual and audible indications.

4.403.20 The Proposed Solution does not have any scalability and/or capacity limitations (hardware/software) that may hinder PFD’s in the future.

4.403.21 Proposed Solution capacity provides for the storage of a minimum of 365 days of history log data

4.403.22 Proposed Solution has a documented, tested, and proven Disaster Recovery plan that may be used by PFD to recover the proposed solution at an offsite location on similar infrastructure. Please provide details.

4.403.23 Does the long term technical support policy mandate maintenance window schedules for implementing updates or enhancements to the solution?

Do Not Rate

4.403.24 If so, describe the schedule and the potential impact to PFD in terms of time (hours/maintenance window). Will this maintenance plan be flexible and accommodate PFD’s business requirements and schedule (e.g. elections and associated technology freezes)?

Do Not Rate

4.403.25 Proposed RMS solution is capable of being cloud-based (e.g. on premise, hosted, hybrid, or all of the above).




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 108 of 137

4.4 DATABASE SOFTWARE The Vendor will identify the relational data base management system (RDBMS) and the associated query and reporting software being provided with a general description of the technical specifications and features of the software. Specifically, the Vendor must provide a comprehensive RDBMS environment which may include: RDBMS Software, Query / Report Writing Software, RDBMS Performance Tools, RDBMS Recovery Tools, and RDBMS Utility Tools. PLEASE NOTE: The City of Phoenix has standardized on Oracle 11g+ on Oracle Exadata Database Machine. In addition, the City also utilizes Microsoft SQL Server 2008 and 2012 clusters on HP server infrastructure. The City’s strategy is to utilize existing database architecture before deploying additional infrastructure. Please answer the following questions in the table below. Please address the proposed RDBMS, as indicated above, in the table below and in standard paragraphs and diagrams if and as required.

Database Software Proposed Solution Specifications



4.404.01 What are the databases, versions, and patch levels supported by the Proposed Solution as of September 1, 2015. Include a sequence of preferred databases supported by the vendor based on the most stable and best performing platform for the proposed solution.

Do Not Rate

4.404.02 What are the database CPU and memory resource requirements for initial configuration? Include an architectural diagram that illustrates the database architecture.

Do Not Rate

4.404.03 Proposed Solution is supported on Oracle 11G+ databases residing on an Oracle Exadata database machine.

4.404.04 Describe the optimum disk storage subsystem configuration to ensure optimum database read/write performance? Please specify RAID types, disk types and size, number of spindles, and IOPS requirements.

Do Not Rate

4.404.05 Proposed Solution supports industry recommended file standards for database server files.

4.404.06 Proposed solution supports Oracle ASM.

4.404.07 Proposed solution provides or can integrate “out of the box” with industry standard report writing/data distribution tools (i.e. business intelligence systems, SQL Reporting Services).

4.404.08 Please provide detailed license specifications (including version and module information) for all equipment, software, operating system, database, and other components required for the Proposed Solution. Include any preproduction licensing requirements as well.

Do Not Rate




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 109 of 137

Database Software Proposed Solution Specifications



4.404.09 PLEASE NOTE: The City requires the Vendor to provide Entity Relationship Diagrams (ERDs), data dictionaries, dictionaries, and other data documentation/schematics for the Proposed Solution

4.404.10 Vendor will provide ERD information.

4.404.11 Proposed Solution provides industry standard tools that can be used to connect to the underlying database.

4.404.12 Proposed Solution allows administrator access to the data access layer and is well documented.

4.404.13 Please state your database patching policy/schedule. Do Not Rate

4.404.14 Please describe how you stay current with the latest security patches related to your database environment.

Do Not Rate

4.5 DESKTOP AND CONNECTIVITY The Vendor will identify the approach for connecting the proposed server hardware platform with the client desktop allowing user access to the Proposed Solution. A description of the communication, network, and desktop components required to provide this connectivity is required. The Vendor must specify all software required to be resident on the user desktop to access the application. The Vendor must specify any hardware, software, or services required to connect server to the City’s network. Please Note: The City currently utilizes Windows 7 for its desktops and laptops. The City has standardized on Internet Explorer and Google Chrome for web browsers. The City security policies require the department to constantly test, patch and upgrade these environments based on Zero day notifications from the City’s IT Security and Privacy Office.

Desktop and Connectivity Proposed Solution Specifications

Response ID Requirements Vendor Response Comments

4.405.01 Proposed client software coexists and/or integrates with MS Office 365 and MS Outlook. If there are any exceptions, please specify.

4.405.02 Specify both minimum and recommended Windows end user device hardware/software requirements for running proposed client software. Include Windows versions, Microsoft patch level (i.e. Service Packs), physical memory, hard disk space and performance.

Do Not Rate

4.405.03 Specify both minimum and recommended network (LAN, WAN, WiFi, broadband) performance requirements for Windows end user devices that will run proposed client software.

Do Not Rate

4.405.04 PFD utilizes Verizon, AT&T, and Sprint broadband for MDC’s on apparatus. Specify broadband data

Do Not Rate




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 110 of 137



plan consumption trends/usage by proposed client software.

4.405.05 Specify Windows screen resolutions supported and not supported with proposed client software.

Do Not Rate

4.405.06 Proposed Solution client software on MDC will continue to function during broadband disruptions, resulting in disconnect with CAD/RMS. Please specify to what degree MDCs may or may not function and operate independently of CAD/RMS.

4.405.07 Proposed end-to-end solution requires third party “persistent network connectivity” software (i.e. NetMotion) to sustain uninterrupted communications between MDC and CAD/RMS. Please also specify whether other solutions may be needed to ensure quality of service between MDCs and CAD/RMS.

Do Not Rate

4.405.08 Proposed Solution utilizes different levels of security to restrict unauthorized access to sensitive and critical information, programs, and operating system functions.

4.405.09 Proposed Solution allows system administrators the ability to easily control user and supervisor access to meet multiple levels of security and access requirements.

4.405.10 Proposed Solution limits the operation of the CAD system software to authorized personnel by log-on/password control.

4.405.11 Proposed Solution is compatible with Symantec Antivirus software.

4.405.12 Describe how end user devices will be configured to connect to different backend systems (i.e. development, testing, staging, and production).

4.405.13 Specify Internet Browsers supported by Proposed Solution. Please specify versions

Do Not Rate

4.405.14 Please describe the capabilities and limitations of the Proposed Solution’s interface for performing system functions. For example are there differences between a full client and a web based GUI that PFD should be aware of?

Do Not Rate

4.405.15 Please describe in detail the process for planning, installing and testing the proposed client applications on PC-based workstations, MDCs, including all manually performed procedures (i.e., staff having to install or configure system components manually on each PC hosting the client

Do Not Rate




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 111 of 137



applications). Please provide installation documents.

4.405.16 Proposed Solution will allow for bulk migration of existing CAD user accounts so that CAD users may continue using current City logins/passwords. Please specify Proposed Solution’s user naming conventions and format(s) supported.

4.405.17 Provide a detailed explanation of the types of access, and any expected use of administrative access, required by the Vendor for ongoing support and maintenance of the Proposed Solution.

Do Not Rate

4.6 INDUSTRY STANDARDS The Vendor is instructed to review industry standards and identify any exceptions associated with enabling the Proposed Solution to efficiently and effectively operate according to design within the response time parameters identified in this Solicitation.

Industry Standards Proposed Solution Specifications



4.406.01 Proposed Solution complies with current NFPA and standard security practices, including a description of how the Proposed Solution encrypts data transmissions (particularly NFPA Standard 1221-13 Chapter 13 – Data Security).

4.406.02 Proposed Solution follows and/or complies with current APCO standards and software development practices, including how the Proposed Solution integrates with other Fire and Emergency Medical dispatch communication systems.

4.406.03 Proposed Solution has a defined process for notifying customers of known bugs and/or fixes.

4.406.04 Proposed Solution has a process for requesting, approving and tracking PFD-based modifications and customizations.

5 PRODUCT INTERFACES The Vendor will be responsible for developing design specifications addressing the required interfaces (see ATTACHMENT C – TECHNICAL INTERFACES LISTING). The Vendor will be responsible for interface construction and unit testing. The Vendor will be responsible for integrated testing of these interfaces/adapters after both sides of the interfaces are complete. The vendor will be responsible for support of the interfaces as part of long term system support.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 112 of 137

Current interfaces from the CAD and RMS systems are accomplished using custom built, point to point solutions. PFD requires standardization of these interfaces wherever possible and/or practical.

Product Interfaces Proposed Solution Specifications


4.501.01 Describe the methodology for completing design and other technical specifications addressing product modifications required for defined interfaces

4.501.02 Describe the tools used to accomplish two way data exchange between the Proposed CAD/RMS Solution and external solutions. Include descriptions of interfaces that are real time, event driven or scheduled.

4.501.03 Describe the process used to implement modifications to the base product code and unit test and system test the integrated product

6 DATA CONVERSION The Vendor will take primary responsibility for the conversion of PFD’s current CAD/RMS data to the Proposed Solution tables. PFD will participate and provide assistance. The current environment contains approximately thirty-one (31) years of CAD data, comprised of:

Most recent fifteen (15) month period of all incident/unit data

Twenty (20) years of legacy CAD (PRC/Northrop Grumman) data

Ten (10) years of pre-legacy CAD data (flat files)

Estimated volume of incident records: ~5-8 million PFD intends to minimize the volume and scope of data migrated to the bare necessities required to operate the software and support field functionality. In the interest of time savings, cost savings and risk reduction, a select set of data will be converted. The configuration data from the current environment is expected to be converted to the Proposed Solution. This includes static data such as resources, call type or nature codes, equipment/capabilities, and jurisdictions. Access to unconverted data will be implemented as part of a separate project. PFD expects to use a mechanism similar to the systems already providing access to legacy and archived data to make data from the current CAD system available. PFD seeks to implement a risk mitigation strategy to facilitate seamless deployment of the Proposed Solution. The plan under consideration is to create a live connection between the current CAD system and the Proposed Solution in the form of a CAD-to-CAD interface. This capability will allow flexibility in migrating the large user base to the Proposed Solution. The creation of a CAD-to-CAD interface would exclude the need for live data conversion scripts. Please use your knowledge of common migration needs, best practices, and the requirements of the Proposed Solution to describe the approach to be taken on the PFD project for each of the deliverables listed below.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 113 of 137

Data Conversion Proposed Solution Specifications


4.601.01 Describe the approach to data conversion. Include your methodology for producing a data mapping document, conversion specifications, and conversion reports.

4.601.02 Please list any tool or licensing costs required to convert the data.

4.601.03 Describe how PFD technical and business resources will be used to assist in delivering the converted data.

4.601.04 Describe the proposed process for conducting multiple mock conversions in non-production environments.

4.601.05 Describe the proposed approach to ensuring data quality, including pro-active data quality reporting, scrubbing, and data clean-up.

4.601.06 Describe the proposed steps for preparing the data conversion for production implementation, including dress rehearsal/mock conversion, production conversion, and post production support.

4.601.07 Please describe the approach for implementation of a CAD-to-CAD utility that has the highest likelihood of success with the Proposed Solution. Please include a price for both traditional Data Conversion scripts of Incident data and a CAD-to-CAD interface in your cost estimates. Please provide separate prices for each option, since they are mutually exclusive.

7 IMPLEMENTATION 7.1 PROJECT MANAGEMENT PFD will assign a Project Manager who will be responsible for managing and organizing the overall project. PFD's Project Manager will be responsible for the overall project plan, including project communications, budget management, project planning, issues escalation, and vendor management. The vendor Project Manager will be responsible for supplying a project plan for execution of the implementation of the CAD and RMS systems. PFD prefers that a formal project management methodology be applied to the project. A straightforward project plan that ensures monitoring, control, and tracking are addressed throughout the project is desired. The Vendor should demonstrate knowledge of industry standard project management practices. Responses to the following requirements, please attach any relevant examples or process documentation that is specific to the approach that will be used on this project. Any standard Project Management Institute (PMI) standards or other project management standards documentation need not be included.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 114 of 137

Project Management Proposed Solution Specifications


4.701.01 What project management related plans are typically included in your project management methodology? For example, is there a formal charter, change management plan, quality management plan, communications plan, and risk management plan included in your standard methodology?

4.701.02 How often is the risk assessment updated? What is the method of conducting the review and how are the results communicated?

4.701.03 How frequently are budget and schedule performance indicators updated? For example, is a budget “performance to plan” indicator provided in weekly or monthly status reports?

4.701.04 What level of communication is typical for your project teams? For example, do all team members participate in regular project team meetings? Does your team utilize collaboration or social networking tools to engage with each other on a project or technical topics?

4.701.05 Are project documents stored in a central repository that all Vendor team members can access? Will the repository be accessible to City project team leaders?

7.1.1 PROJECT TEAM The Vendor will provide all personnel required to successfully complete the proposed project activities and will identify specific individuals responsible for key positions. At a minimum, the project will have a project manager and a key staff member assigned to each of the following functional areas for the duration of the project:

CAD Implementation

Configuration Specialist

RMS Implementation

Mobile CAD Implementation Each team will remain intact through "Go-Live" and 30 days post "Go-Live". In addition to the Vendor project team, PFD recognizes that key PFD project team and business members are required in order for the implementation of the CAD and RMS systems to be successful. PFD would like to utilize a significant number of experienced and knowledgeable personnel from the business side of the organization, plus other subject matter experts as required, throughout the project. PFD envisions that these individuals would learn the core system and its configuration. These individuals could also be involved with developing test scripts and conducting unit, integrated and system tests, as well as acceptance testing. They could be involved in business process review, end-user training, and in system documentation. PFD would also like to utilize a significant number of its highly-skilled technical staff throughout the project. While some training on the new technology will likely be needed, PFD envisions that these technical individuals could participate with system set up, configuration, conversion, report writing, interface development and other City




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 115 of 137

integration. In addition, other City staff that support the systems to which the new CAD/RMS will interface will be called in and available to assist with those efforts. The goal of this higher level of involvement is to ensure full knowledge transfer, to mitigate risks associated with a more rapid implementation, and to reduce the costs of the implementation. Please describe the anticipated project team as requested below. Attach any diagrams that will help clarify the team structure.

Project Team Proposed Solution Specifications


4.702.01 Please confirm that project teams for CAD Implementation, Configuration Specialists, RMS Implementation, and Mobile CAD Implementation will remain in place for 30 days after Go-Live.

4.702.02 Provide a sample Integrated Project Team organization chart including key project staff, subcontractors, and reporting structure.

4.702.03 Provide a sample Project Roles and Responsibilities matrix – e.g. RAPID or RACI decision making responsibility chart.

4.702.04 Describe supplier project team roles and responsibilities for each key staff member and subcontractor, as they relate to the project.

4.702.05 Identify all internal and external communication paths, including within the Vendor’s project staff and between the Vendor and City project staff.

7.1.2 WORK PLAN As a measure to achieve full knowledge transfer, mitigate risks and reduce the cost of the implementation, PFD is suggesting a 24-month implementation timeframe and an additional six-month period of on-site support and assistance following go-live. The Vendor must review and confirm this timeframe or suggest other optimum timelines that more readily support the Proposed Solution, implementation approach, and City resource commitments. The Proposed Solution must include a work plan identifying activities and resources (internal and external) required for successful installation of the Proposed Solution components. PFD will provide management, technical, and user resources to be involved in the project effort based on the Vendor’s installation approach and associated activities. Vendors must list and describe the major project tasks proposed for the project including an overview of the work to be completed and the milestones achieved within each task. A graphical representation of the typical milestones included in an integrated CAD/RMS project with customizations and full implementation support should be included in the Vendor’s response.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 116 of 137

Work Plan Proposed Solution Specifications


4.703.01 Please provide a sample or template of the detailed Project Schedule and Work Breakdown Structure for the CAD Implementation.

4.703.02 Please provide a sample or template of the detailed Project Schedule and Work Breakdown Structure for the RMS Implementation.

4.703.03 Please describe the method used to co-ordinate with the project and resource management teams to update the status and tracking of actual work performed on task assignments.

4.703.04 Please provide a graphical or simple text roadmap of Project Milestones.

7.1.3 STAFFING Resource management planning is a critical function to ensure the smooth execution of tasks over the life of the project. PFD desires to understand the safeguards implemented by the Vendor to ensure that resource issues do not impact project performance.

Staffing Proposed Solution Specifications


Vendor Response/Comments

4.704.01 Please provide a sample resource management plan showing the Please provide a sample resource management plan showing the format and granularity of information tracked related to resource transitions during the course of the project. For example, provide the template that shows how resource levels, ramp time, transitions, and resource releases are managed on a monthly or quarterly basis.

4.704.02 Describe the approach used by your team to ensure that no single resource is a point of failure on the project. For example, describe redundant or overlapping skillset planning strategies, time off coverage planning standards, employee development and cross training philosophies, and time management practices when team members are assigned to multiple client projects.

The Vendor must provide estimates of the level that PFD business and technical staff must participate in the CAD/RMS implementation. Please provide estimated full time equivalent (FTE) staffing levels for each of the following areas for both Vendor and City project teams.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 117 of 137

Staffing Plan Vendor Response/Comments Response ID

RFP Section Project Area Vendor Staffing (FTEs) PFD Staffing (FTEs)

4.705.01 IV.5 Product Interfaces

4.705.02 IV.6 Data Conversion

4.705.03 IV.7.1 Project Management

4.705.04 IV.7.2 Product Configuration

4.705.05 IV.7.3 Product Engineering

4.705.06 IV.7.4 Product Testing

4.705.07 IV.7.5 Product Installation

4.705.08 IV.7.6 Post Implementation Support

4.705.09 IV.7.7 Final Acceptance

4.705.10 IV.8.1 Ongoing Support

4.705.11 IV.8.2 Training

4.705.12 IV.8.3 Product Documentation

4.705.XX <add additional rows as needed>

7.1.4 PROJECT EXECUTION The Vendor will be responsible for managing the execution of the implementation effort including project activities conducted by their personnel and subcontractors. Vendor Project Manager will work with PFD’s Project Manager to coordinate tasks and timing of involvement of City personnel assigned to the project for purposes of knowledge transfer. Activities will include, at a minimum: supervision; schedule administration; project coordination activities; time and expense management; status reporting; change control management; and quality management. The Vendor is required to periodically provide a written project status report to PFD's Project Manager and may be asked to attend formal status meetings with Project's Executive Steering Committee. The reporting period begins with the award of contract and continues through final system acceptance testing by PFD. Please acknowledge each of the following deliverables are included in your project execution management approach. Please add any relevant deliverables as appropriate to your approach.

Project Execution Response ID

Requirements Vendor Response/Comments

4.706.01 Describe your approach to managing a project using a blended Vendor/Client technical team to achieve project goals.

4.706.03 Development and maintenance of a comprehensive installation plan complete with all activities and resources required for successful product implementation.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 118 of 137

7.1.5 IMPLEMENTATION METHODOLOGY PFD would like to take advantage of the Vendor’s proven implementation approach to ensure a successful implementation into the business environment. A standard, proven approach that will be adapted to this project is desired to ensure training is effective, go live is smooth, and acceptance is completed in a timely manner. Please attach any process documentation or templates that will be used in the approach applied to this specific project. Processes and templates not specific to the supplier’s implementation methodology need not be attached.

Implementation Methodology



4.707.01 Please provide a sample CAD and RMS Implementation Methodology.

4.707.02 Describe your Business Process Impact and Change Management Methodology.

7.2 PRODUCT CONFIGURATION The Vendor will be responsible for providing the base software and preparing it for operation and access by the project team. The Vendor will be responsible for training PFD’s project team of approximately 30 administrative, super user, and technical persons in all aspects of the base product, and ensure correct set-up and configuration of the base product to accommodate PFD’s specific environment. The Vendor must supply a price listing for continued training of PFD’s project team in order to achieve a level of product proficiency.

Product Configuration Response ID


4.708.01 Describe how your project plan takes upgrades, enhancements, and patch releases of the base product into account during the implementation of the Proposed Solution.

4.708.02 Describe the opportunity for City technical staff to “factory test” the base product functionality prior to delivery at PFD?

4.708.03 PFD plans to install and configure the CAD solution at 2 sites concurrently as part of the initial deployment. Please describe your experience with deploying CAD across multiple physical locations. Please include a description of your experience with concurrent live systems (CAD-to-CAD) that are load balanced, hot failover with a watchdog, and peer to peer distributed configurations.

4.708.04 Describe your approach to ensure correct set-up and configuration of the CAD and RMS base products to accommodate PFD’s specific environment.

4.708.05 Describe the method for support of deployment of the configuration, and any incremental configuration changes, through PFD’s environments as the project progresses.

4.708.06 Describe how the correct functioning of the base CAD and RMS software will be demonstrated at critical integration points.

4.708.07 The cutover method for the Proposed Solution includes construction of a CAD-to-CAD interface with the existing system to facilitate acceptance




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 119 of 137

Product Configuration Response ID


testing and an interruption-free go live. Please describe your experience with the use of live connections between disparate CAD systems.

4.708.08 PFD intends to use a strategy of configuring the Proposed Solution to look and feel as similar as possible to the existing system during the initial deployment of the CAD system. For example, backgrounds, field positioning, control types, fonts and window behavior, keyboard commands, and any existing touch screen interactions should all behave in a manner consistent with the current system behavior. Please describe your experience with configuring the UI of the Proposed Solution to replicate the look and feel of the current system.

4.708.09 Describe the approach to test configurations in real world scenarios as the configuration options are implemented. How will your team ensure that all business scenarios are accounted for in the configuration process?

4.708.10 Describe your experience in working with customers who require significant enhancements. What is the approach you have used in the past to ensure configuration of the base package is compatible with the future enhancements?

4.708.11 Describe the process of training the appropriate City project and support teams in each of the CAD and RMS base products in order to achieve product proficiency during project start up and as team members are bought on board over the life of the project.

7.3 PRODUCT ENGINEERING The Vendor will be responsible for the identification, finalization, and documentation of PFD’s required modifications; the development of design specifications; the modification of base product code; and unit testing of the product. This will include the work effort associated with designing and developing any non-standard application program interfaces or integration points.

Product Engineering Response ID Requirements


4.709.01 Describe your process and level of City team member involvement for identification, finalization, and documentation of PFD required modifications.

4.709.02 What is the typical method of gaining buy-off and approval of development of design specifications?

4.709.03 What aspects of your products are engineered for modification of base product code and system integration? For example, does your product include an extensible data model? Are there pre-constructed web services that allow for custom data to be processed in the standard flow of the business logic?

4.709.04 What tools does your development team use to conduct unit testing of the product? For example, does your engineering team have a set of automated regression tests that can be used as a start for City customizations?

4.709.05 Describe your experience with joint development teams with customer technical resources.

4.709.06 Does your standard engineering process apply to all items in this RFP that have been marked as potential customizations?




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 120 of 137

Product Engineering Response ID Requirements


4.709.07 When third party applications that are part of the Proposed Solution require additional engineering, does your standard engineering process apply?

4.709.08 Describe the characteristics of the team that will be completing the product engineering work. For example, are all or part of your resources off-shore, contract, or in house? Does your team use Agile methods or traditional development processes? How will the development team interface with City technical and business experts?

7.4 PRODUCT TESTING The Vendor will be responsible for conducting a comprehensive systems test utilizing PFD’s environment and its data. Though the Vendor is responsible for all testing, verification testing by PFD must be allowed to take place. The acceptance test plan developed by the vendor must be accepted by PFD. The Vendor will develop a test plan outlining the testing approach, methods, data participants and other items required for successful product testing. The Vendor will assume responsibility for conducting a product integration test that tests the base system, subsystems, plus any modifications and interfaces. The integration testing is to ensure the delivered product modifications and product interfaces work to specifications and do not adversely impact the system as a whole. The Vendor will assume responsibility for conducting a product volume test to insure that the system meets PFD’s incident volume requirements. The Vendor will assume responsibility for conducting disaster recovery and fail over testing. The Vendor will provide resources for product fixes resulting from errors identified during the system testing process.

Product Testing Response ID Requirements Vendor Response/Comments

4.710.01 Provide a sample or template test plan outlining the testing approach, methods, data participants and other items required for successful product testing.

4.710.02 Describe your standard process for conducting a comprehensive systems test utilizing PFD’s environment and its data

4.710.03 Describe the participation method for including PFD in verification testing.

4.710.04 Explain your approach to product integration testing to ensure the delivered product modifications and product interfaces work to specifications and do not adversely impact the system as a whole

4.710.05 What method is used to conduct a product volume test to ensure batch and on-line performance meets performance and service levels? Are there any tools or special hardware or software required to complete these tests?

4.710.06 Explain how project team resources are allocated for product fixes resulting from errors identified during the system testing process




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 121 of 137

Product Testing Response ID Requirements Vendor Response/Comments

4.710.07 Describe the approach for testing dual site installation of the initial software according to the active/active or active/passive architecture requirements and as described in section 1.3.1, where the initial installation will take place at one site and a limited roll out will occur at the other site.

7.5 PRODUCT INSTALLATION PFD will review the final results of product testing and the mock production conversion to accept readiness of the system and approve production cutover. At least two, if not three, successful, mock production conversion will be required to go live. The Vendor, along with PFD, will stage all aspects of the system, develop a conversion schedule and conduct all cutover activities.

Product Installation Response ID Requirements Vendor Response/Comments

4.711.01 Please describe the standard implementation and cutover plan for the Proposed Solution. For instance, is there a template for go live that is a step by step task list for each of the CAD, Mobile and RMS applications including back-out procedure and cut of no return?

4.711.02 Describe the team that will be available to support PFD while it conducts a review of the final results of product testing and the mock production conversion to accept readiness of the system and approve production cut-over.

4.601.07 As described above in section IV.6 – DATA CONVERSION, PFD is considering the use of a CAD-to-CAD interface between the Proposed Solution and the current CAD system as a way to mitigate risk. Please describe how such a utility will impact the standard cut-over process. Include all the benefits and drawbacks that can be identified at this time.

7.6 POST INSTALLATION SUPPORT The Vendor will provide immediate production critical support for PFD during the first 120-180 days of operation, or a defined comprehensive period. In addition, the Vendor will meet daily or as required with PFD’s project team to perform a post installation review to identify production issues and develop an action plan and associated timeline to address and resolve these issues.

Post Installation Support Response ID Requirements Vendor Response/Comments

4.712.01 Describe the typical action plan and associated timeline to address post installation issues

4.712.02 The go live plan for the Proposed Solution will include a complex installation of a second dispatch center at a date no earlier than 90 days after initial go live. Please explain the support services for each site that your team can provide during the initial stabilization period,




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 122 of 137

Post Installation Support Response ID Requirements Vendor Response/Comments

transition to the operation of the second dispatch center, and stabilization of the second dispatch center.

4.712.03 PFD requires the Vendor to provide immediate production critical support on site at PFD during the first 120-180 days of operation. Please describe the team that will be present to provide the post installation support.

4.712.04 Please describe the post installation monitoring and control process, for example, does the plan include a post installation review and meetings daily or as required with the project team to identify and resolve production issues?

7.7 FINAL SYSTEM ACCEPTANCE Final system acceptance will be completed within a period of one hundred twenty to one hundred eighty (120-180) days following production cutover. Within that period PFD will measure performance of the system in accordance with predefined performance criteria. The project is not considered complete and the Vendor will not be released from their obligations until this final acceptance test is conducted and the system is formally accepted by PFD.

Final System Acceptance Response ID Requirements Vendor Response/Comments

4.713.01 The Vendor will agree to a period of between one hundred twenty days to one hundred eighty days (120-180) days following production cut-over. Please describe the activities and services that will be provided while PFD measures performance of the system in accordance with predefined performance criteria.

4.713.02 PFD requires completion of the following deliverables before final acceptance: operational training provided to City technical support staff, train the trainer sessions, and completed technical and end user documentation. Please describe how these deliverables will be integrated into the project plan.

4.713.03 The project is not considered complete and the Vendor will not be released from their obligations until the final acceptance testing is conducted and the system is formally accepted by PFD. Please describe the approach to development and execution of a final acceptance test plan.

8. SUPPORT 8.1 ON-GOING SUPPORT At a minimum, the Proposed Solution must include information and pricing associated with all aspects of ongoing support and maintenance activities. Identify all future upgrades over the next five years.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 123 of 137

Ongoing Support Response ID Requirements Vendor Response/Comments

4.801.01 Does the Proposal include information and costs associated with all aspects of on-going product support and maintenance activities?

4.801.02 Is this support based on a defined on-going maintenance fee? Describe your hardware support services. For example does the support include the following: data center operations, hardware maintenance, software maintenance, product help desk, product fixes, product enhancements; and regular product releases.

4.801.03 The production operation of the Proposed Solution will include a dual dispatch center configuration. Please describe your experience supporting such installations. Are any additional services required to support this configuration?

4.801.04 Are there fees for software updates?

4.801.05 How are updates, patches, bug fixes, and workarounds communicated and made available to clients?

4.801.06 Provide a copy of the source code to the City, either stored in the City’s program libraries or deposited with an escrow agent, for example: Licensee shall have the right to become beneficiary to the Software Source Code Escrow Agreement.

4.801.07 Provide a schedule of the telephone support options, fees, hours and procedures.

4.801.08 How does PFD request enhancements to be included in the base product? Describe the process of collecting input from the existing user base. How are these requests prioritized, approved, and included in product roadmaps, planning and implementation? How does PFD request enhancements to specific modifications?

4.801.09 Identify all future upgrades over the next year and history of upgrades for the last 3 years.

4.801.10 Please describe the internal quality assurance practices in place that are applied to standard product enhancements, periodic repair releases, and emergency repair releases or patches.

4.801.11 Please describe the pre-release field testing, early access program, or other customer facing acceptance/review procedures in place for releases and patches of the standard software system.

4.801.12 Please describe the training, release documentation, knowledge base or community forum resources available under the support plan. What are the technical, educational, and reference materials targeted for use by system and application support staff 1) during normal operation and 2) related to product patches and releases other than the initial implementation.

4.801.13 Please describe the process for discontinuation of support for prior releases of the Proposed Solution. How many major releases are you currently supporting? What is the standard policy for supporting releases past the end date of standard support?




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 124 of 137

8.2 TRAINING PFD expects the Vendor to provide train-the-trainer services for a group of about 150 operational employees, including CAD consortium employees. Train-the-trainer services and content must be targeted to support specific role based training. Following train-the-trainer delivery, training conducted by City trainers will include classroom instruction for all Call Takers, Dispatchers, training coordinators, Supervisors, and other identified end users. Training will ensure that all trained personnel fully understand the functional and operational use of CAD, mapping, AVL, Mobile, and RMS modules. Upon completion of the training program these individuals must be proficient in the system and able operate the Proposed Solution successfully. PFD intends to set up a training environment which will be utilized as a training simulator. This environment will permit users to access all CAD/RMS environments including the geofile/mapping system, resource table, Incident event table, and warning files. The training module will allow users the same command functions, forms and system features as authenticated users will have when logged on to the live CAD/RMS system.

Training Response ID Requirements Vendor Response/Comments

4.802.01 Give an overview of the training development and delivery process and how it is coordinated with the other key project areas such as configuration/engineering, integration, and testing.

4.802.02 Describe the services available related to development of business focused content you will provide for training. For instance, what consulting services are available for supporting PFD staff who are developing the business training curriculum and modules? How extensive are the initial training classes for the training development team?

4.802.03 Describe your training model. For example, what templates are pre-defined for CAD and RMS job roles, how are your train-the-trainer classes conducted, does your program include Online Learning Management System? Are PowerPoint presentations included? Include examples of past training programs conducted for clients as listed in section IV.9.5 VENDOR REFERENCES, if available.

4.802.04 Describe how you will evaluate the effectiveness of your training.

4.802.05 Describe the qualifications of your trainers and their expertise in our version (with customizations) of the software.

4.802.06 Describe your training support model for City trainers who are implementing the training program in the field (e.g. review of training presentations for accuracy, phone support, online chat support, email).

4.802.07 Describe how you will provide training for software updates.

4.802.08 Describe any limitations to your training model.

4.802.09 Describe the materials provided to support end user training including any training manuals, video tutorials, or knowledge base content that is included or can be developed for the application as implemented during this project.

4.802.10 Describe the ability to customize training materials. For example, can business process training be linked, merged, or referenced in the system’s training materials?




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 125 of 137

Training Response ID Requirements Vendor Response/Comments

4.802.11 Please identify the breakdown of training hours provided for train-the-trainer and system administration training.

8.3 DOCUMENTATION The Vendor will be responsible for providing system and user documentation for the base product. The Vendor will grant the right to make as many documentation copies for use by PFD’s employees as needed. In addition, as part of the ongoing license fee, the Vendor will provide one master and one copy of all documentation upgrades for all future system modifications and enhancements.

Documentation Response ID Requirements Vendor Response/Comments

4.803.01 Describe the documentation provided for use by the technical team to perform installation, configuration, and operational support of the hardware, operating software, and systems software pre-requisites for each environment.

4.803.02 Describe the approach taken to provide system administration documentation of the final configured and engineered application including system and software architecture, entity and database model and dictionary, and developer reference manuals for all interfaces.

4.803.03 Are acceptance test cases included as part of the system documentation?

4.803.04 Describe the method of delivery and ability to customize the user guide, user reference documentation and on-line, context sensitive help for users of the application software.

4.803.05 Describe the method of accessing online help, videos, and documentation from small form factor devices such as tablets and smartphones (e.g. browser, mobile application).

4.803.06 Describe the authentication process for access to online end user facing documentation, specifically

Is a per seat license required in order to access documentation?

Can unrestricted access to on-line documentation be granted to users outside the application server environment?

4.803.07 Describe how the standard end user documentation addresses

Error messages and recovery from errors

Role/security specific functions

Maintenance of parallel narratives based on business process differences (e.g. between agencies).

4.803.08 What services are available to assist with modification of the documentation to reflect the department’s customizations and business processes?

4.803.09 Is a printed copy of documentation available for all of the manuals related to the system?




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 126 of 137

Documentation Response ID Requirements Vendor Response/Comments

4.803.10 PFD requires electronic copies of documentation in MS Word format. What other formats are available, for example PDF, HTML, or a special application for serving documentation content?

4.803.11 What is included as part of the ongoing license fee in regards to updates to documentation for all future system modifications and enhancements?

4.803.12 Describe the process for reviewing, managing change, and submitting documentation deliverables for final acceptance by PFD.

9. QUALIFICATIONS AND EXPERIENCE 9.1 ORGANIZATION The proposal must fully describe the ability of the Vendor to complete the project on time and within the proposed cost budget, while maintaining the specified quality and scope. 9.1.1 EXPERIENCE WITH SIMILAR SIZED INITIATIVES PFD desires a vendor with experience deploying fire-centric dispatch systems that are multi-agency and multi-jurisdictional. It is desirable that the Vendor has deployed a system of similar size and complexity as the current Phoenix Fire CAD system. The proposal must fully describe the Vendor’s corporate qualifications and experience in completing multi-agency and multi-jurisdictional Fire CAD/RMS projects of similar type, size, scope, and complexity as specified in this RFP. NOTE: The questions below apply to specific projects. General business references may be supplied below in section IV.9.5 VENDOR REFERENCES. 2014 CAD Key Metrics:

1. Population served: 3.5 Million 2. Area: 2,500 square miles 3. Phone Volume: 778,402 4. Incident: 371, 049 5. Agencies/Jurisdictions: 28 6. Fire Stations: 100+ 7. Responding Vehicles: 600+ 8. Responders: 3,500+ 9. Support Staff: Approximately 700




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 127 of 137

Experience with Similar Sized Initiatives Response

ID Requirements Vendor

Response/Comments

4.901.01 Please describe 3 similar projects completed in the last 8 years and currently in production. Include the CAD key metrics for comparison.

4.901.02 In the projects cited as qualifying examples describe the ability to meet each project implementation date on budget. If the projected implementation date or budget was not met describe the corrective actions taken to complete the project.

4.901.03 Please describe the approach used on prior projects to complete co-development of new features currently included in the Proposed Solution, customizations currently under support with an existing customer, or other customer driven enhancements that are being used by an active customer.

4.901.04 For the projects cited as examples provide references and contact information for each agency.

9.1.2 FINANCIAL STATEMENTS Provide two (2) complete copies of your last three (3) years of audited financial statements or annual reports, or equivalent, in a separately sealed, clearly marked envelope. Be certain to identify company ownership (including fractional ownerships), investors, any information pertaining to the potential sale of the company, and any/all lawsuits. 9.1.3 CORPORATE ORGANIZATION

a) The Vendor must provide the following information regarding the corporate organization of the Vendor’s organization:

Official corporate or agency name

Business address (street address, city, county, state, zip code)

Mailing address if different than the business address

Facsimile number

Telephone number

Contact name, title, telephone, and email address (include mailing address information if different from the Corporate Headquarter address) of the Vendor’s main contact for the proposal evaluation process

Name, title, and contact information (telephone number, email address, mailing address, and facsimile number) of the individual authorized to bind the Vendor’s organization to the terms and conditions of the proposal

Date established

b) The proposal must identify the Vendor’s organizational structure by indicating which one of the following best describes the Vendor’s organizational type:

Private, for-profit corporation identifying the state of incorporation, Certificate of Authorization to Conduct Business, and the State authorization number.

Partnership, general partnership, limited partnership, or limited liability partnership.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 128 of 137

Sole proprietorship or individual.

c) The proposal must describe the level of corporate resources and availability, including depth of experienced personnel and technical resources that are available for the project (distinguish employees from independent contractors).

d) The proposal must identify the number of individuals employed by the Vendor and each subcontractor

either directly or under contract.

e) The proposal must provide evidence that the Vendor has been in business for at least ten (10) years, performing business functions directly relevant to the project.

f) If any part of the project work is to be subcontracted, the information above must be provided for each

proposed subcontractor. The proposal must provide binding letters of commitment from all subcontractors. Failure to provide these binding letters of commitment may lead to elimination of the Vendor from further consideration or considered a Breach of Contract if discovered after Contract signing.

g) Describe the makeup of the Vendor’s development tools and support staff. Provide resumes and

disclose whether the developers and support staff are full time employees, students or contractors.

h) Divulge what percentage of license revenue is set aside for product development, lifecycle and migration strategy.

9.2 PROJECT TEAM ORGANIZATION The proposal must include an organizational chart of the proposed project team. 9.2.1 VENDOR’S EXECUTIVE PROJECT SPONSOR The Vendor must designate an Executive Sponsor for the project that is ultimately responsible for the project and has sufficient corporate authority to obligate the Vendor’s organization to commit the necessary resources to complete the project on time, within budget, and in conformance with the requirements specified in the RFP. The proposal must include the Vendor’s Executive Sponsor’s full resume. 9.2.2 DESIGNATED PROJECT MANAGER The proposal must identify the designated Project Manager’s qualifications including detailed information regarding the designated Project Manager’s experience with Fire/EMS projects of similar size and complexity as PFD’s proposed Project. Please provide the following information for the designated Project Manager:

Detailed resume including name and title.

Current employer.

Percent of time dedicated to the project during the project’s duration.

Summaries of specific, relevant project experience.

Education/Training, including degrees earned and year. Three (3) business references capable of attesting to the individual’s ability to provide the type of services defined in the RFP.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 129 of 137

Identify and describe work performed by the designated Project Manager during the previous eight (8) years, which is related to the work of the project. It is highly desirable that the designated Project Manager is certified as a Project Management Professional (PMP) by the Project Management Institute (PMI). Please provide information about the Project Manager’s PMP certification, if applicable. If the Project Manager is not directly employed (i.e. is an independent contractor) by the Vendor, a binding offer letter, contingent only on the selection of the Vendor, must be included in the proposal. 9.2.3 PROJECT MANAGER DUTIES During the Project, the designated Project Manager must:

a) Be responsible for managing and updating the Project’s Schedule to reflect the current status of each project task and deliverable including all City, Vendor, and subcontractor tasks and deliverables.

b) Be responsible for ensuring that all System Contractor staff, subcontractors, and PFD Project Manager

are aware of scheduling and authorized project work plan changes.

c) Meet on a weekly basis onsite during the project’s implementation with PFD’s Project Manager and core project team to discuss any encountered problems, any mitigation action proposed or taken for encountered problems, and any project work plan and schedule updates.

9.2.4 KEY STAFF EXPERIENCE The Vendor shall provide résumés and three (3) references from previous fire/ems clients for all key staff members as listed in the implementation section of the RFP. Résumés for each person shall include the following information:

Current position with the Vendor

Years with the Vendor

Project position to be staffed

Education

Work experience, including past positions with the Vendor

Technical skills and qualifications relevant to the project

Specific description of experience in working with the proposed system, including experience in system design, installation, support, training, or management of Fire/EMS systems

If the Key Project Personnel are not directly employed (i.e. is an independent contractor) by the Vendor, a binding offer letter, contingent only on the selection of the Vendor, must be included in the proposal. 9.2.5 KEY STAFF ASSIGNMENT PRIORITY The Vendor shall warrant that any key staff members identified by the Vendor and accepted by PFD shall be dedicated to PFD’s project as that person’s primary assignment during implementation through final acceptance.




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 130 of 137

9.2.6 KEY STAFF CHANGE The Vendor shall warrant that any change in assigned key staff is subject to prior City approval in writing. This requirement will be waived if the key staff member leaves the Vendor’s employment. Vendors should recognize that changes in key project personnel will not be allowed subsequent to award of contract without written consent of PFD. Additionally, PFD reserves the right to approve any and all personnel changes or to request personnel changes as PFD deems appropriate during the course of the project. 9.2.7 LOCATION OF KEY STAFF OR PROJECT TEAM PFD prefers to work with a vendor that has key staff or project teams located near PFD and can be on site during working hours Monday through Friday. Vendors should provide a list that describes the geographic distribution of key staff members. If key staff members or project teams are available to work locally, please provide information regarding the duration of their availability. 9.2.8 POST IMPLEMENTATION STAFFING LEVELS The project implementation team will remain intact and on location for 30 days past "Go-Live" to facilitate a smooth transition to the new system and address any software or configuration issues. The time period may be reduced if PFD and Vendor mutually agree. CAD (Dispatch) Subject Matter Experts (SME) will be on-site to provide 24 x 7 assistance on the dispatch floor for 15 days after initial implementation to address the immediate needs of the dispatchers. One Mobile CAD SME will be available on-site 15 days after initial implementation to facilitate a smooth transition for field technical support staff and field users. 9.3 ADVERSE ACTIONS/POTENTIAL IMPACT State whether the Vendor is currently involved in any litigation, threatened litigation, investigation, reorganization, receivership, filing, strike, audit, corporate acquisition, unpaid judgments, or any other action that could have an adverse impact on the ability to provide the required RFP needs. If so, please provide the nature of the item(s) and the potential impact. State whether your firm has been unable to complete a contract, been removed from a contract, or been replaced during a contract period in the last five (5) years. If so, explain what happened and why. 9.4 VENDOR’S CURRENT CLIENT LIST The proposal includes a complete, current client list of the Vendor that includes the following information for each public safety client:

Government agency name

Current principal contact name, title, phone number, and e-mail address

Types of agencies served by the system (e.g. Fire, EMS, etc.)

Contract number, and signature date and/or cutover (go-live) date to operational use 9.5 VENDOR REFERENCES The proposal must include at least three (3) reference sites that are using Fire/EMS records management systems previously installed by the Vendor that are similar in nature and complexity to the Proposed Solution. The following information must be provided for each reference:




Phoenix, AZ 85003 Phone: (602) 262-7181


Page 131 of 137

Government agency name

Principal contact name, title, mailing address, telephone number, and e- mail address

Names of the agencies, jurisdictions, and departments supported by the system

Types of agencies served by the system (e.g. Fire, EMS, etc.)

Contract number and signature date

Original dollar value of contract and final or current contract value

System cutover (i.e., go-live) date to operational use

Scope of products and services provided

Software version, server / host operating system, and database management system and version installed

9.6 OTHER RELEVANT INFORMATION Submit any other information which documents additional skills or experience relating to the requirements of this RFP which you believe may be relevant, including brochures and descriptions.

SECTION V - SUBMITTAL



Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________

Page 132 of 137

Please submit one original, three (3) copies and one (1) electronic copy of the Submittal (Section V). Please submit only Section V and all other required documents, do not submit a copy of the entire document. This offer will remain in effect for a period of 365 calendar days from the bid opening date and is irrevocable unless it is in the City’s best interest to do so. Offerors pricing must be a firm fee. Unless otherwise and specifically provided, the price is all-inclusive and must include all necessary costs including, but not limited to, materials, labor, travel, copying costs, incidentals, equipment space, taxes, profit, insurance and any other items necessary to effectively conduct and complete the Scope of Work. The Contract shall be fixed price with price adjustments during the implementation period. Thereafter, annual maintenance costs will be capped at the amounts defined herein. PAYMENT TERMS Contractor offers a prompt payment discount of _______% _______ days to apply after receipt of invoice or final acceptance of the products, whichever is later. If no prompt payment discount is offered, enter 0 in the % space to indicate net 30 days, otherwise payment terms shall be 2% 20 days, net 30 days; effective after receipt of invoice or final acceptance of the products, whichever is later. Payment terms offering less than 20 days will not be considered in the price evaluation of your bid. Any prompt payment terms offered must be clearly noted by the Contractor on all invoices submitted to the City for the payment of goods or services received. EMERGENCY TWENTY-FOUR HOUR SERVICE CONTACT Name Telephone Number Alternate Contact Telephone Number




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________

Page 133 of 137

OFFER

TO THE CITY OF PHOENIX: The Undersigned hereby offers and agrees to furnish the material and or service(s) in compliance with all terms, conditions, specifications, and addenda issued as a result of solicitation and any written exceptions in the offer.

Arizona Sales Tax No.

Use Tax No. for Out-of State Suppliers

City of Phoenix Sales Tax No.

Taxpayer’s Federal Identification No. : If recommended for contract award, Offeror agrees to provide its federal taxpayer identification number or as applicable its social security number to the City of Phoenix for the purposes of reporting to appropriate taxing authorities, monies paid by the City of Phoenix under the awarded contract. If the Offeror provides its social security number, the City will only share this number with appropriate state and federal officials. This submission is mandatory under 26 U.S.C. § 6041A.

OFFEROR MUST BE IN COMPLIANCE AT THE TIME OF AWARD

Enter City’s Registration System ID Number Located at City’s eProcurement website (see SECTION I –

INSTRUCTIONS - CITY’S REGISTRATION)

Offeror has read, understands, and will fully and faithfully comply with this solicitation, its attachments and any referenced documents. Offeror certifies that the prices offered were independently developed without consultation with any of the other Offerors or potential Offerors.

Authorized Signature Date

Printed Name and Title

Company Name

Address

City, State and Zip Code

Telephone Number

Company’s Fax Number

Company’s Toll Free #

Email Address




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________

Page 134 of 137

ACCEPTANCE OF OFFER

The Offer is hereby accepted. The Contractor is now bound to sell the materials or services listed by the attached contract and based upon the solicitation, including all terms, conditions, specifications, amendments, etc. and the Contractor’s Offer as accepted by the City. This contract shall henceforth be referred to as Contract No. . The Contractor has been cautioned not to commence any billable work or provide any material or service under this contract until Contractor receives purchase order, or contract documentation.

City Clerk Approved as to form this 19 day of November, 2014

This document has been approved as to form by the City Attorney and is on file with the City Clerk. It need not be submitted to the City Attorney for approval unless the form document is altered.

CITY OF PHOENIX, a municipal corporation Ed Zuercher, City Manager

Jim Campion, Deputy Finance Director

Awarded this ______ day of _____________, 2015.

SECTION VI – ATTACHMENTS AND EXHIBITS



Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________

Page 135 of 137

ATTACHMENT A - FUNCTIONAL REQUIREMENTS WORKSHEET ATTACHMENT B - COST WORKSHEET ATTACHMENT C – TECHNICAL INTERFACES LISTING ATTACHMENT D – CURRENT SYSTEM DATA TABLE LISTING ATTACHMENT E – CURRENT SYSTEM APPLICATION CONFIGURATION SETTINGS EXHIBIT A – RESOURCE LIST




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________

Page 136 of 137

EXHIBIT B – ROSTER

EXHIBIT C – NEAREST HOSPITAL




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________

Page 137 of 137

EXHIBIT D – ACTIVE INCIDENTS MONITOR

Documents

CITY OF PHOENIX Procurement Division … OF PHOENIX Procurement Division REQUEST FOR PROPOSAL RFP 16-011 (AW) PHOENIX FIRE DEPARTMENT COMPUTER AIDED DISPATCH (CAD) & RECORDS MANAGEMENT