Table of Contents COPY - Toronto · REQUEST FOR PROPOSALS: ASSET MANAGEMENT SOLUTION (AMS) ARTICLE 1.0 TERMINOLOGY RFP No. Page 4 of 154 1.0 TERMINOLOGY 1.1 References to Labelled

REQUEST FOR PROPOSALS: ASSET MANAGEMENT SOLUTION

(AMS) TABLE OF CONTENTS

RFP No. Page 2 of 154

Table of Contents RFP

1.0 TERMINOLOGY ................................................................................................................................. 4

1.1 REFERENCES TO LABELLED PROVISIONS ............................................................................................ 4 1.2 DEFINITIONS ..................................................................................................................................... 4 1.3 INTERPRETATION .............................................................................................................................. 9

2.0 PURPOSE ........................................................................................................................................ 11

2.1 INTRODUCTION................................................................................................................................ 11 2.2 CITY OF TORONTO GENERAL INFORMATION ...................................................................................... 11 2.3 BACKGROUND ................................................................................................................................. 12

2.3.1 Parks, Forestry and Recreation (PF&R) ............................................................................... 12 2.3.2 Current Challenges ............................................................................................................... 13

3.0 SCOPE OF WORK .......................................................................................................................... 15

3.1 OBJECTIVES ................................................................................................................................... 15 3.2 SOFTWARE SOLUTION ..................................................................................................................... 15

3.2.1 AMS Licensing Options ......................................................................................................... 16 3.2.2 Software Maintenance & Support Services and Warranty .................................................... 17 3.2.3 Software Maintenance ........................................................................................................... 18 3.2.4 Support Service Levels ......................................................................................................... 18 3.2.5 Service Reporting .................................................................................................................. 24 3.2.6 On-Site Technical Support .................................................................................................... 24 3.2.7 New Products ........................................................................................................................ 25 3.2.8 Software Documentation ....................................................................................................... 25 3.2.9 Reference Hardware Platform ............................................................................................... 26

3.3 PROFESSIONAL SERVICES ............................................................................................................... 27 3.3.1 IT Service Management ........................................................................................................ 27 3.3.2 Installation, Configuration and Implementation Services ...................................................... 28 3.3.3 Migration Services ................................................................................................................. 29 3.3.4 Integration Services ............................................................................................................... 30 3.3.5 Training Services ................................................................................................................... 30 3.3.6 AMS Pilot Implementation - PF&R ........................................................................................ 33

3.4 PROJECT ACTIVITIES AND DELIVERABLES ......................................................................................... 34 3.4.1 Phase 1 – Project Initiation .................................................................................................... 34 3.4.2 Phase 2 – Requirements Validation ...................................................................................... 34 3.4.3 Phase 3 – Prepare Design Documentation ........................................................................... 34 3.4.4 Phase 4 – Build/Implement Solution ..................................................................................... 35 3.4.5 Phase 5 – Monitored Deployment ......................................................................................... 37 3.4.6 Phase 6 – Final Acceptance .................................................................................................. 38 3.4.7 Ongoing Enhancements ........................................................................................................ 38 3.4.8 Project Management ............................................................................................................. 38 3.4.9 Mandatory Requirements ...................................................................................................... 40 3.4.10 Documentation Requirements ............................................................................................... 40 3.4.11 Functional, Non-Functional and Technical Requirements .................................................... 41 3.4.12 Implementation Requirements .............................................................................................. 41 3.4.13 Warranty Period, Ongoing Support and Maintenance .......................................................... 42

4.0 PROPOSAL EVALUATION AND SELECTION PROCESS ........................................................... 44

4.1 SELECTION COMMITTEE .................................................................................................................. 44 4.2 SELECTION CRITERIA ...................................................................................................................... 44

4.2.1 Stage 1 – Initial Evaluation: Mandatory Requirements ......................................................... 44 4.2.2 Stage 2A – Detailed Evaluation ............................................................................................. 45

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) TABLE OF CONTENTS


4.2.3 Stage 2B – Interviews, Product Live Demonstration and Presentation ................................ 45 4.2.4 Stage 3 – Cost ....................................................................................................................... 47

4.3 SELECTION PROCESS ...................................................................................................................... 47 4.4 SCHEDULE OF EVENTS .................................................................................................................... 48 4.5 CLARIFICATIONS ............................................................................................................................. 48 4.6 EVALUATION RESULTS .................................................................................................................... 48 4.7 NEGOTIATIONS AND AGREEMENT ..................................................................................................... 48

5.0 PROPOSAL SUBMISSION REQUIREMENTS ............................................................................... 51

5.1 GENERAL OVERVIEW....................................................................................................................... 51 5.2 PROPOSAL DOCUMENTATION AND DELIVERY .................................................................................... 51 5.3 PROPOSAL CONTENT ...................................................................................................................... 52

Letter of Introduction ............................................................................................................................ 52 Table of Contents ................................................................................................................................. 52 Section 1 – Executive Summary .......................................................................................................... 52 Section 2 – Proponent Profile .............................................................................................................. 53 Section 3 – Experience and Qualifications of the Proponent .............................................................. 53 Section 4 – Proposed Staff Team and Resources .............................................................................. 54 Section 5 – Proposed Solution ............................................................................................................ 55 Section 6 – Workplan and Deliverables ............................................................................................... 55 Section 7 – Cost of Services (Total Proposed Price) .......................................................................... 56 Section 8 – Cost Control ...................................................................................................................... 58

APPENDIX A RFP PROCESS TERMS AND CONDITIONS ............................................................... 59

APPENDIX B AGREEMENT TERMS AND CONDITIONS .................................................................. 65

APPENDIX C STANDARD SUBMISSION FORMS ............................................................................. 72

APPENDIX D PRICE DETAIL FORMS ................................................................................................ 81

APPENDIX E PROPOSAL EVALUATION TABLE ............................................................................. 83

APPENDIX F REQUIREMENTS & PROJECT REFERENCE MATERIAL ......................................... 87

APPENDIX G ESCROW PROVISIONS .............................................................................................. 150

APPENDIX H SAMPLE LOGICAL DATA MODELS ......................................................................... 151

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) ARTICLE 1.0 TERMINOLOGY


1.0 TERMINOLOGY 1.1 References to Labelled Provisions Each reference in this Request for Proposal to a numbered or lettered “article”, “sub-article”, “section”, ”subsection“, “paragraph, “subparagraph”, “clause” or “subclause” shall, unless otherwise expressly indicated, be taken as a reference to the correspondingly labelled provision of this Request for Proposal (RFP). 1.2 Definitions Throughout this Request for Proposal, unless inconsistent with the subject matter or context. “Agencies, Boards and Commissions (ABC’s)” refer to bodies and organizations that have a direct reporting or funding relationship with the City of Toronto or Council. The list of current organization name and contact of agencies to be considered under this RFP is available from the City web site www.toronto.ca/abcc. “Agreement” means the executed written contract entered into between the City and the successful Proponent (Vendor) setting out the undertaking by the City and the Vendor to perform their respective duties, responsibilities and obligations as prescribed in the Agreement and includes the RFP, Addenda, Information for Proponents, all appendices, schedules, Drawings and includes such other documents as may be listed in the Agreement and any Change Orders and other amendments to the Agreement. It is used interchangeably with “Contract”. "Approval Process" means the process for approval of Deliverables as set out in article 4.7(7) of this RFP. "Asset Management Solution (AMS) refers collectively to the Project and any subsequent implementations of the Solution in other Divisions of the City or in the ABCs in accordance with the provisions of this RFP as the context requires. “BCA” means a Building Condition Assessment, a formal process by which City buildings are inspected, and deficiencies (necessary repairs/replacements) are documented, with cost estimates and timelines associated with each deficiency. “Business Hours” means the hours between 9:00 am and 5:00 pm (Eastern time zone), Monday through Friday, excluding statutory holidays. “Capital Asset” means a building or a fixed asset representing a component of a building, e.g. furnaces, roofing, air conditioners, etc. “Capital Budget Submittal” means a formal submission, made on an annual basis by City Divisions, to City Council in order to secure funds for Capital Projects. “Capital Planning” means the Design, Construction and Asset Preservation group within the City’s Parks, Forestry & Recreation Division. Asset Preservation is a group within Capital Planning responsible for maintaining most of the City’s portfolio of buildings, including preparation of the Capital Budget Submittals. “Capital Project” generally means a project whose value is greater than $50,000, and has an expected life span of at least ten (10) years. “City” means the City of Toronto. “Client” or “Clients” means the City business unit(s) that the Solution is being developed for.

VIEW

ING C

OPY

DO NOT S

UBMIT




“Commercially Reasonable Efforts” means the taking by any person or entity of such action as would be in accordance with reasonable commercial practices as applied to the particular matter in question to achieve the result as expeditiously as practicable; provided that such action shall not require that such person or entity incur unreasonable expense. “Confidential Information” means:

a) All information of a party to the Agreement that is of a proprietary or confidential nature,

regardless of whether it is identified as proprietary or confidential or not, and whether recorded or not, however fixed, stored, expressed or embodied, which comes to the knowledge, possession or control of the other party to the Agreement under the Agreement, including all information to be transmitted, stored or processed on any network or computer system;

b) Any information that the City is obliged not to or has the discretion not to disclose pursuant to law

or statute such as the Municipal Freedom of Information and Protection of Privacy Act, the Personal Health Information Protection Act, or any other municipal, provincial and federal legislation;

c) Any information that the City is required to keep confidential, including any information of third

parties, including any suppliers of any products or services provided to the City; d) All information relating to intellectual property rights including copyright, trade secrets, processes,

formulae, techniques, plans and designs, computer programs, computer codes whether source code or object code, and all related Documentation and financial information related hereto which is proprietary to or in the possession of a party to the Agreement, and that the other party to the Agreement may have access to for purposes of the Agreement;

e) Any information comprising the databases of the City or the procedures and operational protocols

and information relating to the operations of the City and that the Vendor may have access to for purposes of the Agreement; and

f) All data, formulae, preliminary findings, and other material developed in the performance of the

Services.

“Configuration” means a set of tasks required in order to activate functionality without any Customization. Support for configuration shall be included in the Proponents standard support and maintenance service. “Council” means Toronto City Council. “Customization” means any required software change(s) that a Proponent must make that results in a modification or creation of any proposed application source code in order to meet the City’s Functional Requirements. "Cut-over" occurs when any site scheduled for implementation of the Solution is promoted to the Production Environment. “Deadline” or “Closing Deadline” means the Deadlines identified in the Notice to Potential Proponents and Article 4.4 Schedule of Events as it relates to questions and closing Deadlines. “Deliverables” means the Deliverables as defined in Articles 3.4 of this RFP. “Development Environment” means the set of processes, programming tools and physical infrastructure required to create, build or modify the Solution. “Division” means an administrative unit of the City.

VIEW

ING C

OPY

DO NOT S

UBMIT




“Documentation” means any communicable material that is used to describe, explain or instruct regarding attributes of an object, system or procedure, such as its parts, assembly, installation, maintenance and use. "Documenting" means the preparation and supply of documents or supporting references or records “Effective Date” means the date that the City and the Vendor agree in the Agreement shall be the effective date of the Agreement. “Executive Advisory Committee” means the City staff working on the Project with the responsibilities described in Article 3.4.8.1 (4). "Final Notice of Acceptance" means the final written notification by the City to the Vendor confirming the completeness and adequacy of the Solution following successful completion of the Monitored Deployment, at which point the Warranty Period shall commence. “Functional Requirements” means the requirements set out in Appendix F.2 of this RFP and any additional proposed functional requirements in the Proponent’s Proposal if accepted by the City all as validated in accordance with Article 3.4.2 Phase 2. "Go-live" refers to the event whereby every site scheduled for implementation of the Solution is completely promoted to the Production Environment. Go live may be a single event or may involve multiple cut-overs, all in accordance with the Project Plan. “Hands-on Demonstration” refers to a component of the Presentation and Demonstrations phase of the evaluation process whereby members of the City’s evaluation team will get to sit down and use the Proponent’s proposed Solution, under the guidance of the Proponent. It is akin to a “mini training session.” “HTTP” means Hypertext Transfer Protocol; “HTTPS” means Hypertext Transfer Protocol over Secured Socket Layer "ICIS" means Installation, Configuration and Implementation Services. "Implementation Period" refers to the time period during which all of the phases in the Project Plan as set out in Article 3.4 occur. “Implementation Requirements” means the requirements set out in Article 3.3 and Appendices F.6, F.7 and F.8 of this RFP and any additional proposed implementation requirements in the Proponent’s Proposal if accepted by the City. “Internet” means the worldwide network of computers commonly understood as the Internet. "IP" means Intellectual Property is a term referring to a number of distinct types of creations of the mind for which property rights are recognised. Common types of intellectual property include copyrights, trademarks, patents, industrial design rights and trade secrets in some jurisdictions. “IT” means information technology in general. “I&T” means the Information and Technology Division of the City.

VIEW

ING C

OPY

DO NOT S

UBMIT




“Knowledge Transfer” means the process by which the Vendor provides training with respect to the Services that augments the knowledge and experience of the City Personnel and user groups, including access to reports, information sessions and meetings and includes to a thorough, hands on review of the methodologies and tools employed by the Vendor with the appropriate City Personnel for the purpose of City Personnel acquiring the skills to manage the ongoing day to day operations, improvements and future implementations. “MFIPPA” means the Municipal Freedom of Information and Protection of Privacy Act, (Ontario), provincial legislation that governs access to public information and the protection of personal information and privacy. "May" and "should" used in this RFP denote permissive (not mandatory). "Module" refers to a part of a software program or to a self-contained hardware component as the context requires. "Must", "shall" and "will" used in this RFP denote imperative (mandatory), meaning Proposals not satisfying imperative (mandatory) requirements will be deemed to be non compliant and will not be considered for contract award. “Non-Functional Requirements” means the requirements set out in Appendix F.4 of this RFP and any additional proposed non-functional requirements in the Proponent’s Proposal if accepted by the City. “Notice of Acceptance” means a written notification by the City to the Vendor confirming that the City has accepted the completeness and adequacy of the Deliverables specified in such notice. “Out-of-the-Box” means features that are available as part of the Solution immediately on installation and require no Configuration or Customization. “Party” means either the City or Vendor as the context requires; and Parties means both the City and the Vendor. “Personal Information” means any information about an identifiable individual that is governed by applicable federal or provincial privacy laws and regulations, and includes any information which may be considered “Personal Information” under the Personal Information Protection and Electronic Documents Act (Canada) (“PIPEDA”) or which may be subject to MFIPPA or PHIPA. “Personnel” means with respect to any party, the party’s employees, contract personnel, representatives, invitees, members, volunteers, officials and agents. In the case of the Proponents, it includes directors, partners, subcontractors, subcontractors and third party service providers and in the case of the City it includes its Members of Council, Mayor and officers. "PF&R means the City's Parks, Forestry and Recreation Division. “PHIPA” means the Personal Health Information Protection Act, 2004; provincial (Ontario) legislation that governs the collection, use and disclosure of personal health information within the health care system. “Preferred Proponent” means the Proponent that's Proposal, as determined by City staff through the evaluation analysis described in the RFP, provides the best overall value in meeting the City’s requirements, and may be recommended for negotiations in accordance with article 4.7 of this RFP. “Production Environment” means the set of processes, software and physical infrastructure required to operate the Solution on an ongoing basis. “Project” means the Asset Management Solution (AMS) for the City implemented for the PF&R Division as detailed in this RFP.

VIEW

ING C

OPY

DO NOT S

UBMIT




“Project Manager” means the main contact person at the City or the Vendor, as the context requires, for all matters relating to the management of the Project as detailed in this RFP. “Project Plan” means the detailed workplan satisfactory to the City to be provided by the Vendor within two (2) weeks from the Effective Date of the Agreement and includes the plan for the design and implementation of the proposed AMS. “Project Working Group” means the City staff working on the Project with the responsibilities described in Article 3.4.8.1 (5). “Proponent” means a legal entity that submits a Proposal in response to a formal Request for Proposal. “Proposal” means an offer submitted by a Proponent in response to a formal Request for Proposals (RFP), which includes all of the Documentation necessary to satisfy the submission requirements of the RFP. "Requirements" means the City's the Functional, Technical and Non-Functional Requirements collectively. “RFP” means this Request for Proposal package in its entirety, including all Schedules, Appendices and any bulletins or Addenda that may be issued by the City. “Scripted Demonstration” refers to a component of the Presentation and Demonstrations phase of the evaluation process whereby Proponents will follow a script provided by the City, and demonstrate the aspects of their Solution’s functionality requested in the script. “Services” means all Services and Deliverables to be provided by a Vendor as described in this RFP. “Solution” means the Asset Management Solution (AMS) including the Deliverables and Services meeting the City’s Functional, Technical and Non-Functional Requirements, as set out in this RFP. "Staging (QA/Testing) Environment" means the set of processes, tools, and physical infrastructure required to simulate the Production Environment for the purposes of conducting various types of testing. “SOGR” means State of Good Repair, the standard to which City buildings and fixed capital assets must be maintained. “System” means the software component(s) of the Solution, inclusive of any additional features, interfaces or modules identified by the Proponent as being necessary components of the Solution. "Asset Management Solution (AMS) refers collectively to the Project and any subsequent implementations of the Solution in other Divisions of the City or in the ABCs in accordance with the provisions of this RFP as the context requires. “Technical Requirements” means the requirements set out in Article 3.2.11 and Appendix F.3 of this RFP and any additional proposed technical requirements in the Proponent’s Proposal if accepted by the City. “Training Environment” means the set of processes, tools, and physical infrastructure required to simulate the Production Environment for the purposes of training.

VIEW

ING C

OPY

DO NOT S

UBMIT




“Total Price” means the Total Price as set out in the Agreement and accepted by the City, and constitutes the total compensation payable to the Vendor for all Services to be performed under the Agreement and includes any additional amounts payable for approved changes in the Services as provided for and authorized in the Agreement, and is the complete and all-inclusive amount payable by the City to the Vendor for all Services to be completed under the Agreement in accordance with the method, manner and conditions of payment stipulated in the Agreement. “Total Proposal Price” means the Proposal price for the Project as set out in Appendix D Price Detail Forms of this RFP. "UAT" means User Acceptance Testing. “Vendor” means the successful Proponent with whom the City enters into an Agreement. "Warranty Period" has the meaning set out in Article 3.4.12.

1.3 Interpretation

(1) Where in this RFP a reference is made to the express written agreement, approval or consent of the City, it shall be understood that the City shall not be deemed or construed to have agreed to any stipulation, Requirements, exclusion, limitation or other term or condition set out in a Proposal that deviates from a provision set out in any of the Agreement documents, unless that deviation is expressly confirmed in a formal executed Agreement or in a written and express amendment to such Agreement.

(2) Where there is a reference to a matter requiring the consent or the approval of the City, such

consent or approval, any conditions thereof, or the denial of same shall be deemed to be exercisable by the City in its absolute discretion.

(3) The City shall not be bound by any oral representation or communication whatsoever, including

but not limited to any instruction, amendment or clarification of this RFP or any of the Agreement documents, or any information, advise, inference or suggestion, from any City Personnel concerning the Proposal’s submissions, the RFP, the proposed Agreement or any other matter concerning the Agreement or the Project. No City Personnel is authorized to orally alter any portion of the RFP. In addition, the City shall not be bound by any written representation whatsoever concerning any matter concerning the RFP, the Agreement or the Project unless executed by the person designated and authorized in accordance with City Policies, the Agreement or in accordance with a direction or authorization of City Council.

The Proponents release and waive all claims whatsoever in negligence, in equity or otherwise with respect to any oral or unauthorized representations or communications.

(4) The Agreement documents will be complementary and what is required by any part thereof

shall be considered as being required by the whole. In the event of a conflict or inconsistency the order of precedence shall be, in descending order of priority, as follows:

(a) the Agreement; (b) the Schedules to the Agreement; (c) the RFP; and, (d) the Vendor’s Proposal.

(5) Proposals will be called, received, reviewed, accepted and processed in accordance with the

terms of this RFP and the City of Toronto Municipal Code, Chapter 195 – Purchasing. The Municipal Code can be found on the City of Toronto’s web site at http://www.toronto.ca/legdocs/municode/index.htm.

VIEW

ING C

OPY

DO NOT S

UBMIT




Related policies and procedures can be found at http://www.toronto.ca/calldocuments/policy.htm. By submitting a Proposal for this RFP, the Proponent agrees to be bound by the terms and conditions of these by-laws, policies and any amendments thereto, as fully as if they were incorporated herein.

(6) In this RFP and in the Agreement, unless the context otherwise necessitates,

(e) any reference to an officer or representative of the City shall be construed to mean the person holding that office from time to time, and the designate or deputy of that person, and shall be deemed to include a reference to any person holding a successor office or the designate or deputy of that person;

(f) a reference to any Act, bylaw, rule or regulation or to a provision thereof shall be deemed

to include a reference to any Act, bylaw, rule or regulation or provision enacted in substitution thereof or amendment thereof;

(g) all amounts are expressed in Canadian dollars and are to be secured and payable in

Canadian dollars; (h) all references to time shall be deemed to be references to current time in the City; (i) a word importing only the masculine, feminine or neuter gender includes members of the

other genders; and a word defined in or importing the singular number has the same meaning when used in the plural number, and vice versa;

(j) “shall”, “may”, “herein”, “person”, “writing”, “written”, “surety”, and “security” shall have the

same meaning and effect as given in the Interpretation Act, R.S.O. 1990, as amended; (k) “including” means “including but not limited to”; (l) the words “acceptable”, “approval”, “authorized”, “considered necessary”, “directed”,

“required”, “satisfactory”, or words of like import, shall mean approval of, directed, required, considered necessary or authorized by and acceptable or satisfactory to the City unless the context clearly indicate otherwise;

(m) any words and abbreviations, which have well-known professional, technical or trade

meanings, are used in accordance with such recognized meanings; (n) all accounting terms have the meaning recognized by or ascribed to those terms by the

Canadian Institute of Chartered Accountants; (o) the headings to each article and section are inserted for convenience of reference only

and do not form part of the Agreement; and (p) all index and reference numbers in the RFP or any related City document are given for the

convenience of Proponents and such must be taken only as a general guide to the items referred to. It must not be assumed that such numbering is the only reference to each item. The documents as a whole must be fully read in detail for each item.

1.4 RFP Process Terms and Conditions

This RFP process is governed by the terms and conditions in Appendix ‘A’– RFP Process Terms and Conditions.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) ARTICLE 2.0 PURPOSE


2.0 PURPOSE 2.1 Introduction

(1) The purpose of this Request for Proposals (RFP) is to select a qualified Proponent to

implement a pilot enterprise Asset Management Solution (AMS) that supports financial planning and project tracking for State of Good Repair (SOGR), land acquisition, and new construction / replacement of facilities.

(2) The City wants to acquire and implement an enterprise Solution with little or no Customization

that can meet to meet the objectives of the City described in Article 3.1 and the Functional, Technical and Non-Functional Requirements described in this RFP in Article 3.2.11 and Schedules F.2, F.3 and F.4. In addition, the Solution should be flexible enough to deal with future changes in requirements.

(3) This RFP seeks a Proponent who will provide software technologies and professional services

delivered by a team with proven competencies in order to implement a pilot AMS that is consistent with the terms of this RFP. The AMS should:

a. Address the business goals and technical objectives expressed in this RFP; b. Integrate into the City’s technical environment to leverage the City’s existing

infrastructure; c. Integrate with other City and 3rd party Vendor systems through a flexible Service Oriented

Architecture (SOA) on an Enterprise Service Bus; d. Provide a scalable and extensible Solution that will accommodate future growth so the

Solution can, subsequent to the pilot AMS, be implemented in other divisions of the City and accommodate future Functionality as additional Requirements emerge and as changes are made over time.

(4) The scope of this RFP is to implement the pilot AMS in Parks, Forestry and Recreation

Division. (5) It is the intent of the City to enter into an Agreement with a Vendor who is an acknowledged

market leader, and who can demonstrate their experience and expertise in delivering, implementing and supporting similar Solutions to large organizations such as the City; and who demonstrate that they have the expertise to configure and/or customize an Asset Management System(s) to meet the Functional, Technical and Non-Functional Requirements.

(6) It is desirable for the City to contract with a single Proponent who can provide the required skills

and expertise to work with the City during the entire Project so that all the objectives and the Functional, Technical and Non-Functional Requirements can be achieved consistently and efficiently.

(7) The Agreement for the pilot AMS shall be for a fixed fee and the Total Proposal Cost should not

exceed the RFP budget unless through amendment or change order (for which the Agreement will provide a specific methodology).

(8) This RFP process is governed by the terms and conditions in Appendix A – RFP Process

Terms and Conditions. 2.2 City of Toronto General Information (1) Toronto is Canada's largest city and sixth largest government, home to a diverse population of

about 2.6 million people (the fifth most populous municipality in North America). As Canada's economic capital, Toronto is one of the top financial centres in the world.

VIEW

ING C

OPY

DO NOT S

UBMIT




It is also one of the world's most diverse cities by percentage of non-native-born residents, as about forty-nine percent of the population were born outside of Canada.

(2) Because of the City's low crime rates, clean environment, high standard of living, and cultural

diversity, Toronto is consistently rated as one of the world's most liveable cities by the Economist Intelligence Unit and the Mercer Quality of Living Survey.

(3) Toronto has won numerous awards for quality, innovation and efficiency in delivering public

services. Toronto's government is dedicated to prosperity, opportunity and liveability for all its residents.

(4) The City is currently composed of 46 Divisions, and a workforce of approximately 33,000 full-

time equivalent positions. The Divisions are grouped as service "Clusters" wherein there are commonalities in the business conducted and services provided: social, economic and cultural; physical infrastructure and land development; and, internal corporate services.

(5) The City's organizational model places increasing emphasis on horizontal collaboration across

program areas to deliver on Council's priorities, strengthen oversight capacity and support the City as an order of government and provide for better informed decisions City-wide. It is important for the Toronto Public Service to have the information and information technology tools they need to effectively do their day-to-day jobs.

(6) For the purpose of this Project, these tools refer to the City’s business systems, existing and

proposed, which enhance thoroughness, work performance, and the management of data and critical business outcomes. The business of the City is driven by legislated business requirements, and addresses Council and Divisional policy directives.

2.3 Background (1) Currently, business areas in the City manage their asset information and capital planning

projects to varying degrees of effectiveness. The intent of the AMS is to provide the City business areas with tools and processes to facilitate improved capital planning, and enable a holistic approach to management of its assets through their entire life cycle in a comprehensive and consistent manner.

(2) The AMS implementation planned through this RFP should demonstrate that the proposed

AMS will facilitate individual business operational efficiencies and meet the objectives and challenges of the early adopters of the Solution at the Parks, Forestry and Recreation (PF&R) Division.

2.3.1 Parks, Forestry and Recreation (PF&R)

(1) Parks, Forestry and Recreation (PF&R) existing assets are valued at $5.5 billion which includes 7,527 hectares of parkland, 580 km of trails and pathways, 63 indoor and 59 outdoor pools, 183 water play areas, 40 indoor arenas and 51 artificial ice rinks, 134 community centres, 5 golf courses, 858 playgrounds, 4 stadiums and 265 tennis courts and sports pads.

(2) The Division's current state-of-good-repair (SOGR) backlog as of December 31, 2011 is about

$240 million or 15% of the $1.5 billion asset replacement value. The SOGR backlog is projected to be over $360 million or 19% of the asset replacement value by the end of 2016.

(3) Annual capital plans forecasts for the next ten years range from $65 million to about $100

million.

(4) Currently, PF&R has multiple asset management systems that track and manage its assets and capital projects, including:

VIEW

ING C

OPY

DO NOT S

UBMIT




a) ActiveNetwork CLASS: a community recreation programming, permit and payment

application for PF&R’s Community Recreation Branch that includes a list of Divisional facilities;

b) SAP-RE/SAP-PM: a work management system for PF&R’s Parks Branch that includes a list of Parks and Recreation physical assets;

c) Transportation Maintenance and Management System (TMMS): a work management system for PF&R’s Urban Forestry Branch that includes a list of street-based trees;

d) Capital Asset Management Planning (CAMP) system: an asset management system for PF&R’s Parks Development and Capital Projects Branch that helps manage the lifecycle of the physical assets for State of Good Repair (SOGR) planning, identify Capital Project work, prepare capital budget submissions and track the construction and development of new and renovated physical assets. The system includes a list of Divisional facilities; and

e) CLEAN system: a development permit tracking system for Parks Development and Capital Projects Branch that tracks parkland levies (parkland dedication or cash-in-lieu) for the intent of creating new parks and includes a list of land and funds for new parkland.

2.3.2 Current Challenges

(1) The main challenges inherent in the status quo are:

(a) There is no consolidated view of all of PF&R’s assets; (b) PF&R does not have a single asset management Solution to help manage the lifecycle of

its physical assets; (c) The yearly funding allocation provided by City Council is invariably less than the amount

required to address all of the Capital Projects identified for the upcoming year; (d) Changes to funding allocations, shifting priorities and emergency projects are a

permanent part of the landscape at the City of Toronto; and (e) CAMP, an in-house developed Microsoft Access database(s), has limited forecasting

functions. Such functionality would enable PF&R staff to understand the potential future impact of deferring (or not deferring) Capital Projects. The ability to examine multiple future funding scenarios, and understand the potential implications of each one, would be very valuable to the PF&R staff making the decisions about which projects to pursue, and which projects to defer; and

(f) CAMP has no integration with CATOR (the City’s capital funding system) or PF&R's work management system.

(2) Those challenges speak to the City and Division’s need for a flexible and robust AMS, which

will enable it to manage all of the Division’s assets, and nimbly react when unexpected changes occur, and plan for optimal use of scarce dollars. Currently, the manual processes involved in using the multiple databases are not flexible enough to adequately accommodate changing conditions; exhaustive manual processes must be repeated whenever a change occurs. The preparation of the annual Capital Budget Submittal often becomes an extremely labour-intensive and time-consuming process as a result.

(3) Refer to Appendix F.5 – Building Condition Assessment Process Map and Appendix F.6 –

Capital Planning Process Map for further background on the main business processes that AMS is expected to manage and accommodate.

(4) The Asset Management Solution will result in improved decision making through (1) better

planning and prioritized spending for the renewal of physical assets using lifecycle planning principles, (2) assessment of the performance of an asset against a pre-determined standard, and (3) evaluating projects on a number of criteria to ensure that funds are spent appropriately.

VIEW

ING C

OPY

DO NOT S

UBMIT




(5) The Asset Management Solution will replace two PF&R's legacy, in-house custom-build

applications, Capital Asset Management Planning (CAMP) and CLEAN systems. The new Solution will support PF&R’s comprehensive inventory of assets, and be integrated with the City's capital planning system, CAPTOR.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) ARTICLE 3.0 SCOPE OF WORK


3.0 SCOPE OF WORK

3.1 Objectives (1) The purpose of this project to acquire a pilot enterprise asset management Solution that

supports financial planning and project tracking for State of Good Repair (SOGR), land acquisition, and new construction / replacement of facilities, with initial deployment to one Division and future implementation in other City Divisions or ABCs as the City may determine using a separate RFP process for each new implementation(s).

(2) The City wants to acquire and implement an enterprise Solution with little or no Customization that: (a) Addresses the current challenges and business objectives of the City as described in

Section 2.4.2; (b) Is a secure, MFIPPA-compliant Solution; (c) Is fully integrated with all functionality but it could be consolidated from two (2) or more

systems, each of which addresses a certain area of functionality. (d) Meets the mandatory, and if possible Desirable, Functional, Technical and Non-

Functional Requirements described in this RFP in Article Schedules F.1, F.2, F.3 and F.4;

(e) Is a flexible Solution that can accommodate future Functionality as additional Requirements emerge and as changes are made over time;

(f) Is a scalable and extensible Solution that will accommodate future growth so the Solution can, subsequent to the pilot AMS, be implemented in other divisions of the City;

(g) Seamlessly integrates into the City of Toronto’s technical environment and will leverage and use the existing infrastructure as identified in Appendix F.5 – The City’s Existing I&T Infrastructure; and

(h) Integrates with City and other 3rd party Vendor systems.

(3) The Vendor will provide both a software Solution and professional services. Software requirements are listed in section 3.2, Professional Services are listed in section 3.3.

(4) The scope of this RFP is to implement the pilot AMS in one City Division: Parks, Forestry and Recreation Division. Implementation requirements for PF&R are listed in Appendix F.6.

(5) To project manage the Solution in phases and address at a minimum the following: (a) Phase 1 – Project Initiation; (b) Phase 2 – Requirements Validation; (c) Phase 3 – Prepare Design Documentation; (d) Phase 4 – Build/Implement Solution; (e) Phase 5 – Monitored Deployment; and (f) Phase 6 – Final Acceptance.

Specific Project Activities and Deliverables are described in Section 3.4.

3.2 Software Solution

The City expects that the proposed Solution will predominantly be Out of the Box software and not a software Solution yet to be developed or requiring extensive Customization to meet the Requirements and Deliverables.

VIEW

ING C

OPY

DO NOT S

UBMIT




The City is seeking a software Solution that can be configured and tailored for City specific uses. Should the proposed Solution require Customization to satisfy the Requirements and Deliverables described in this RFP, Proponents are to detail in their submission, in the Proposal Evaluation Tables, the specific Requirements that would be enabled through such Customization. Each Requirement requiring Customization to enable the capabilities requested in the Proposal Evaluation Tables will not receive the maximum score possible for that Requirement. For greater clarity, it is the City's expectation and assumption that the City's Software license rights will extend to use in Development, Production, Test and Training Environments and that no additional license fees will be payable for the use of any Software component of the Solution in these environments. While only a single Proponent can respond to this RFP, a Proponent may sub-contract the delivery of Functionality or capabilities required under this RFP to other providers or manufacturers. All costs required to deliver the Functionality and capabilities being sought in this RFP, and to provide tight and seamless integration, are to be included in the response to the RFP. Proponents should provide details of all costs inclusive of but not limited to development, testing, integration and deployment of the proposed Solution in the Price Detail Forms in Appendix D. The AMS is to be made available to the City at the most recent non-beta and fully tested versions and Releases available on the market. Where more than one module is required, the proposed AMS must work together seamlessly for common ends.

3.2.1 AMS Licensing Options

The City prefers a AMS which is licensed on either a perpetual individual license or a perpetual enterprise license basis. If the AMS is made available under an individual license model, the Solution should consist of:

(1) User Licences (2) Power User Licenses (3) Administrator Licenses (4) Server Licenses

If the AMS is made available on an enterprise license model, the Solution should consist of:

(1) Enterprise User Licenses (2) Enterprise Power User Licenses (3) Enterprise Administrator Licenses

Enterprise Server Licenses

Perpetual End User and Perpetual Power User Licenses – The Vendor is to make available and provide, when ordered, an End User or Power User License for each Module that comprises the AMS. Each End User or Power User License is to be a perpetual license that grants a single user license rights to the complete AMS to perform their business using the Functionality and tools provided through the Solution.

Perpetual Administrator License – As required to meet the Requirements of this RFP, the Vendor should make available and provide when ordered an Administrator License that permits a single technical/administrator user to access or use one or more Modules to which the license relates. Each Administrator License should be a perpetual license that grants a technical administrator license rights to administer any or all aspects of the AMS.

VIEW

ING C

OPY

DO NOT S

UBMIT




Perpetual Server License – As required to meet the Requirements of this RFP, the Vendor should make available and provide when ordered a Perpetual Server License in respect to one or more Modules and to use such Modules on a single instance of hardware, computer or other device on which such Modules can be installed, deployed or used. Perpetual Enterprise End User and Perpetual Power User Licenses – The Vendor should make available and provide, when ordered, an Enterprise End User or Power User License for each Module that comprise the AMS. The Enterprise End User or Power User License is to be a perpetual license that grants an unlimited number of End Users or Power Users license rights to the complete AMS to perform their business using the Functionality and tools provided through the Solution. Perpetual Enterprise Administrator License – As required to meet the Requirements of this RFP, the Vendor should make available and provide when ordered an Enterprise Administrator License that permits an unlimited number of technical administrators to access or use one or more Modules to which the license relates. The Enterprise Administrator License should be a perpetual license that grants any number of technical administrators license rights to administer any or all aspects of the AMS.

Perpetual Enterprise Server License – As required to meet the Requirements of this RFP, the Vendor should make available and provide when ordered an Enterprise Server License in respect of one or more Modules and to use such Modules on an unlimited number of instances of hardware, computer or other device on which such Modules can be installed, deployed or used.

Proponents are to provide price details for both licensing models in the Price Detail Forms provided in Appendix D.1a, Appendix D.1b, Appendix D.1c and Appendix D.1d. When pricing the AMS under the above licensing models Proponents are to take into account the description of City Roles as described in Section 3.3.5.1 City Roles.

Wherever possible Proponents should provide details for any pricing volume discounts that may be available under the “per user” model. Furthermore, in their response, Proponents are to detail current pricing and offer price commitments into the future.

The eventual Vendor shall treat the City as it would its Comparable Customers. The Vendor’s prices, including warranties, discounts, incentives and benefits for any products or services provided to the City are and will be and will continue to be throughout the implementation of any part of the AMS and any support periods equivalent to or better than the terms offered by the Vendor to any of its Comparable Customers for a Solution of like quality or quantity. The City may, at any time, review prices offered by the Vendor for its products and services to ensure the Vendor’s compliance with this requirement (which shall form part of the resulting Agreement) and the Vendor shall provide any information requested by the City in connection with such review. If it is found that the Vendor’s pricing is higher, the Vendor will align and rebate its pricing retroactively to reflect the lower pricing.

3.2.2 Software Maintenance & Support Services and Warranty (1) Once the City has provided a Final Notice of Acceptance of the Solution, a minimum one (1)

year Warranty Period shall commence. All components of the Solution will be covered during the one (1) year Warranty Period, during which time Software Maintenance, as described below in Section 3.2.3 and Software Support as described below in Section 3.2.4 will be provided by the Vendor at no additional cost to the City.

(2) In the event of any breach of this warranty, the remedies available to the City shall include, but not be limited to:

(a) The Vendor restoring the Deliverable to the same level of performance as represented and warranted in the Agreement;

(b) The Vendor repairing or replacing the Deliverable with a Deliverable conforming with the Requirements;

VIEW

ING C

OPY

DO NOT S

UBMIT




(c) The Vendor granting or securing for the City or its authorized agent permission to make any modifications necessary to make the Deliverable compliant with the Requirements and arranging for any necessary waivers of moral rights or other intellectual property rights to make such modifications.

(3) Upon execution of the Agreement, at the request of the City, the Vendor will enter into a Source Code Escrow Agreement for the Solution with the City and a third party escrow agent in a form satisfactory to the City.

(4) The Warranty shall survive cancellation or other termination of the Agreement.

(5) At the end of the Warranty Period, the City at its sole discretion may renew the Software Maintenance and Support Services provided for in the Agreement for four (4) additional one (1) year periods for the price in the Proposal. The City shall authorize such renewal by issuing a Purchase Order or Contract Release Order to the Vendor.

(6) In addition, the City may in its sole discretion choose to call upon the Vendor to provide on-site technical support for services that are not otherwise included in the Warranty, see Section 3.2.6 below.

3.2.3 Software Maintenance Software Maintenance is to include the provision of: (1) All modifications made by the Vendor to each of the Modules comprising the AMS that correct

errors (e.g., bug fixes and patches); that increase the speed, efficiency, capacity or ease the operation of the AMS; and that provide additional capabilities or functions.

(2) All enhancements made to each of the Modules comprising the AMS and by the Vendor including new versions and releases.

(3) All modifications and enhancements to Customizations, if any, made to satisfy the Requirements described in this RFP and required to maintain the proper functioning of Customizations as the AMS is modified and enhanced as described above.

The City at its discretion may choose not to deploy versions and will only be required to deploy new versions within 2 years of their release if the new version does not limit the City usability of the Solution. The Vendor will continue to provide software maintenance for the version provided for the Solution for at least 10 years following the release date of such version.

3.2.4 Support Service Levels The City intends to perform first level support for all aspects of the AMS immediately following Final Acceptance and will triage and attempt to resolve any issues encountered prior to initiating calls to the Vendor. However the Support Services offered by the Vendor should permit a limited number of the City’s authorized power users and technical administrators, not to exceed Five (5) authorized power users and five (5) technical administrators, to make an unlimited number of inquiries and should not be limited to a specific number of incidents, inquires or responses. These Support Services will be made available by the Vendor as detailed in Section 3.4.7 City Quality Assurance & Testing, Monitored Cutover and Support. The following support services are to be provided: (1) A toll free 1-800 telephone access and a single dedicated service and support email address to

a service desk agent (single point of contact for trouble reporting);

VIEW

ING C

OPY

DO NOT S

UBMIT




(2) Instant access to round-the-clock information and online help via web (i.e.; support notes to assist with troubleshooting, technical tips, how to avoid common pitfalls, bug reports and status of reported bug). Any support services offered through the Vendor’s electronic channels should be kept current and up-to-date;

(3) Escalation to certified service technicians or relevant subject matter experts for incident resolution; and

(4) An escalation path with connections to company executives for chronic or high priority issues.

The Vendor is to assign adequate resources to the City to resolve any incidents. The Vendor is to agree to assign a technical account manager along with a backup to ensure that clients always have access to an authorized person to resolve any issues. The technical account manager along with other resources assigned to the City are to be responsible for gaining an in-depth knowledge and understanding of the AMS specific business rules and requirements as well as gaining knowledge of the City infrastructure. The technical account manager is to use this knowledge to manage the delivery of all support services required under the Agreement and is to work with the City’s client over the telephone and if required on-site to ensure support requirements are met. The technical account manager’s responsibilities should include, but are not limited to:

(1) share AMS related technical information with City Personnel;

(2) use knowledge gained to design and improve support service plan;

(3) proactively provide support services and allocate resources to mitigate risks associated with the AMS implementation;

(4) provide an enhanced level of monitoring and alerting, security checks, performance checks and network health check reviews;

(5) finalize an incident escalation process with the City and be responsible for escalating and monitoring any unresolved issues;

(6) Pre-arrange schedules for releases and enhancements

(7) provide a Service Improvement Plan for services that breach in three consecutive months;

(8) provide reports on support and service management for the following as requested:

(a) Provide post mortem reports with corrective actions and steps to prevent re-occurrence (permanent Solutions) of incidents

(b) Provide post mortem reports with corrective actions and steps to prevent re-occurrence (permanent Solutions) at the request of designated City of Toronto Personnel

(c) Provide performance reports monthly, quarterly, annually and as requested by the City of Toronto

(d) Provide updates for ongoing or active priority one incidents as described in further detail in Section 3.1.4.2.1 Support Service Level A, Section 3.1.4.2.2 Support Service Level B and Section 3.1.4.2.3 Support Service Level C – unless set at lesser frequency by the City of Toronto

When an incident is reported, the Vendor is to record and provide the City’s authorized technical user with a unique incident number. The Vendor is to provide updates regarding specific incident(s) and maintain on-going communications with service desk Personnel until the incident has been resolved.

VIEW

ING C

OPY

DO NOT S

UBMIT




The Vendor is ultimately to confirm with the City’s authorized technical user(s) for affirmation that the incident has been resolved prior to closing the incident. The City can request a Service Improvement Plan (SIP) for systemic issues as required. Proponents are to provide Support Services price details based as close as possible on three possible support service levels as described in further detail in Section 3.1.4.2.1 Support Service Level A, Section 3.1.4.2.2 Support Service Level B and Section 3.1.4.2.3 Support Service Level C. Proponents are to populate the corresponding price details corresponding to the three Support Service Levels (A, B and C) in the Price Detail Forms provided in Appendix D.1a, Appendix D.1b, Appendix D.1c and Appendix D.1d. Proponents are not expected to create custom support packages, but should match their current support services to the following three levels – and indicate any gaps as appropriate in Appendix F.4, 6.1.25. 3.2.4.1 Support Service Level A The Vendor is to provide support and service desk services (to respond and resolve Incidents) based on the four (4) Severity Levels described below. Incident and problem prioritization is to be deemed by the City based on the following definitions:

Incident Priority

Priority Definition Service Level

Priority 1

Priority 1 is defined by a mission critical situation occurring in a live production environment. Priority 1 Incidents will be declared when a component of the AMS is totally inoperable causing total system failure and/or automatic unrecoverable data loss.

Acknowledgement Time is a max of fifteen (15) minutes from the inquiry being made by the City. Resolution Time is within one (1) hour from Acknowledgement Time.

Provide updates as to status/progress. Every twenty (20) minutes Priority 2

Priority 2 is when one or more of the AMS’s critical Functionality is not operating, partial loss of operability (e.g., records capture, access control, records search and retrieval, audit logging, failure of application logic enforced by configurable business rules etc.). These situations are usually controllable with a work around established.

Acknowledgement Time is a max of fifteen (15) minutes from the inquiry being made by the City. Resolution Time is within two (2) hours from Acknowledgement Time.

Provide updates as to status/progress. Every thirty (30) minutes Priority 3

Priority 3 is when the AMS Mass Broadcasting Functionality is inoperable (if applicable to the proposed Solution)

Acknowledgement Time is within four (4) hours from the inquiry being made by the City. Resolution Time is within the reported Business Day from Acknowledgement Time.

Provide updates as to status/progress. Every two (2) hours Priority 4

Priority 4 is when one or more of the AMS’s non-critical Functionality is not functioning properly (e.g., not being able to create report(s), not being able to change role of an existing user(s) etc.) and has little effect on the larger business continuity.

Acknowledgement Time is within one (1) Business Day from the inquiry being made by the City.

VIEW

ING C

OPY

DO NOT S

UBMIT




Incident Priority


Resolution Time is on the second Business Day from Acknowledgement Time.

Provide updates as to status/progress. Every eight (8) hours Priority 5

Level 5 is when AMS Client requests for information (i.e. need advice on AMS, planning, installation, requested a report on number of incidents, requests for information / questions etc.)

Acknowledgement Time is a within the first Business Day from the inquiry being made by the City. Resolution Time is within five (5) Business Days from Acknowledgement Time.

Provide updates as to status/progress. N/A Service Desk Availability

The Vendor’s service desk agent is to be available 24 x 7 x 365, including Ontario holidays, Eastern Standard Time and should answer the City client on the first call on most occasions.

The Vendor’s service desk agent is to be available 24 x 7 x 365, including Ontario holidays, Eastern Standard Time and should answer the City client on the first call on most occasions. Expected level of response to first call is ninety-five percent (95%) of the calls. Average speed of answer ninety percent (90%) of calls answered within one hundred and twenty (120) seconds. Two (2) minutes average telephone response for call placed to the Service Desk ninety percent (90%) of the time.

3.2.4.2 Support Service Level B The Vendor is to provide support and service desk services (to respond and resolve Incidents) based on the four (4) Severity Levels described below. Incident and problem prioritization is to be deemed by the City based on the following definitions:

Incident Priority


Priority 1

Priority 1 is defined by a mission critical situation occurring in a live production environment impacting more than thirty (30) percent of users. Priority 1 Incidents will be declared when a component of the AMS is totally inoperable causing total system failure and/or automatic unrecoverable data loss.

Acknowledgement Time is a max of four (4) hours from the inquiry being made by the City. Resolution Time is on the next Day from Acknowledgement Time.

Provide updates as to status/progress. Every four (4) hours

VIEW

ING C

OPY

DO NOT S

UBMIT




Incident Priority


Priority 2

Priority 2 is when one or more of the AMS’s critical Functionality is not operating, partial loss of operability (e.g., records capture, access control, records search and retrieval, audit logging etc.). These situations impact more than twenty (20) percent of users and are usually controllable with a work around established.


Provide updates as to status/progress. Every four (4) hours Priority 3


Acknowledgement Time is a max of eight (8) hours from the inquiry being made by the City. Resolution Time is on the second Day from Acknowledgement Time.


Level 4 is when AMS Client requests for information (i.e. need advice on AMS, planning, installation, requested a report on number of incidents etc.)


Provide updates as to status/progress. Every eight (8) hours Service Desk Availability

The Vendor’s service desk agent is to be available 8 am to 6 pm, Three Hundred and Sixty Five (365) days a year Eastern Local Time and should answer the City client on the first call on most occasions.

Expected level of response to first call is ninety-five percent (95%) of the calls. Abandoned percent less than five percent (5%) Average speed of answer ninety percent (90%) of calls answered within one hundred and twenty (120) seconds. Two (2) minutes average telephone response for call placed to the Service Desk ninety percent (90%) of the time.

3.2.4.3 Support Service Level C The Vendor is to provide support and service desk services (to respond and resolve Incidents) based on the four (4) Severity Levels described below. Incident and problem prioritization is to be deemed by the City based on the following definitions:

VIEW

ING C

OPY

DO NOT S

UBMIT




Incident Priority


Priority 1

Priority 1 is defined by a mission critical situation occurring in a live production environment impacting more than thirty (30) percent of users. Priority 1 Incidents will be declared when a component of the AMS is totally inoperable causing total system failure and/or automatic unrecoverable data loss.



Priority 2 is when one or more of the AMS’s critical Functionality is not operating, partial loss of operability (e.g., records capture, access control, records search and retrieval, audit logging etc.). These situations impact more than twenty (20) percent of users and are usually controllable with a work around established.






Level 4 is when AMS Client requests for information (i.e. need advice on AMS, planning, installation, requested a report on number of incidents etc.)


Provide updates as to status/progress. Every eight (8) hours Service Desk Availability

The Vendor’s service desk agent is to be available 8 am to 6 pm, Three Hundred and Sixty Five (365) days a year Eastern Local Time and should answer the City client on the first call on most occasions.

Expected level of response to first call is ninety-five percent (95%) of the calls. Abandoned percent less than five percent (5%) Average speed of answer ninety percent (90%) of calls answered within one hundred and twenty (120) seconds. Two (2) minutes average telephone response for call placed to the Service Desk ninety percent (90%) of the time.

VIEW

ING C

OPY

DO NOT S

UBMIT




3.2.5 Service Reporting The Vendor is to prepare the following and other similar service reports monthly and quarterly and will provide such reports to the City in electronic or hardcopy format as directed by the City. The Vendor should review the service report and performance metrics with the City on a monthly basis. (1) Incident Metrics

(a) Unique incident number; (b) Client name (City/Division/Business Unit/Division/contact name); (c) Severity level of incident; (d) Total tickets opened (sorting based on incident severity levels); (e) Active tickets opened; (f) Ticket number assigned; (g) Date opened; (h) Site affected; (i) Technician assigned; (j) Trouble details reported; (k) Status; (l) Resolution details; (m) Date closed.

(2) Incident Summary

(a) Percentage of Incidents within acknowledgement (b) Percentage of Incidents resolved within target (c) Service Improvement Plans resolved on schedule

(3) Performance Improvements

(a) Post mortem reports with corrective actions and steps to prevent re-occurrence (permanent Solutions) for all priority one incidents as described above

(b) Post mortem reports with corrective actions and steps to prevent re-occurrence (permanent Solutions) at the request of designated City of Toronto Personnel

(c) Performance reports monthly, quarterly, annually and as requested by the City of Toronto

(4) Performance Reporting

(a) Telephone performance: calls handled, average response time (based on target), abandoned percentage, percentage of calls handled of first contact

(b) System availability measured monthly (c) System response times measured monthly for each system functions (d) Known issues, bugs, enhancements, and releases with forward schedule (e) Change management (f) Successful Changes (g) Failed Changes (h) Backed out Changes (i) Cancelled Changes

3.2.6 On-Site Technical Support After Final Acceptance of the AMS, the City, in its sole discretion, may require some ad-hoc on-Site Technical Support related to services which are not covered by Warranty, Software Maintenance or software Support and are available at the City's option after the Final Acceptance of the AMS. The Vendor is therefore to make available, at the City discretion and option, the following ad hoc on-site technical support Personnel upon request by the City:

VIEW

ING C

OPY

DO NOT S

UBMIT




(1) AMS database administrator; (2) AMS system administrator; (3) AMS software engineer.

For the purposes of evaluation only and to provide guidance to the Proponents, the City has chosen time block scenarios during which the Vendor would make this on-site technical support available in time blocks of 50, 100 or 200 hours. Purchased hours will be valid for one year from the date of purchase at the prices detailed in the Price Detail Form in Appendix D6. These on-site technical support Personnel should be available if and when required based on a per diem (7 hours a day) rate. If such on-site technical support is required by the City, the Vendor is to report and measure the usage of these blocks of time in actual time. The City makes no guarantee of the value or volume of such ad-hoc on-site technical support, nor does it assure exclusivity. 3.2.7 New Products

The Vendor should make available to the City new products, as they become available, that are in scope of the AMS and which support the AMS (i.e. that provide additional Functionality to existing products). New products will be subject to the requirements set-out in this RFP, and in the resulting Agreement with the Vendor. 3.2.8 Software Documentation

The Vendor is to provide current, complete and accurate documentation and manuals required to operate and to maintain the AMS. The Vendor should provide one (1) copy of all relevant documentation and manuals in both electronic format (e.g., online, CD) and paper format for the AMS. The format of any electronic documentation should be supported by the proposed AMS and the City’s authoring tools. The documents in electronic form should be reproducible at the City’s discretion so that all City Personnel using AMS have access to the full level of documentation required to effectively meet their needs. All costs related to such documentation should be included in the license costs and subsequently in the maintenance costs specified in this RFP. The following is a list of the documents and manuals required: User Manual The user manual should illustrate and provide instructions for all system functions, including screen and report layouts. This documentation is to instruct the users on how to use the AMS functions and features in clear non-technical language with examples based upon the City’s implementation of the AMS. Power User Manual The power user manual should illustrate and provide instructions on how to manage configurable elements of the proposed Solution such that a business area can define or redefine business workflows, better control access, assign approval levels, define roles and assign users to roles such as approvers for approval levels, for all application functions. This documentation is to instruct power users on how to configure and manage AMS capabilities and features with clear examples based upon the City’s implementation of the AMS. Technical and Administrator Manual The technical and administrator manuals should document all aspects of the system to enable the Personnel assigned to the technical administrator roles to be able to take full advantage of the AMS (as required) to operate and administer the software and hardware at a technical administrator level.

VIEW

ING C

OPY

DO NOT S

UBMIT




This documentation should include instruction on installation, integration, configuration, security implementation, workflow management, quality assurance, operation, support as well as management and control of the AMS. The document should detail: (1) All application/system configuration specifications, procedures and functions, including screen

and report layouts based upon the City's implementation of the AMS.

(2) Applications installation procedures including screens capture and configuration setting of all AMS components on City's development, testing, training, and production environments.

(3) The various environments to describe all connections to databases and integrations to other City systems as well as the processing logic for each module.

(4) Hardware and software as well as performance tips, backup and recovery and Security routines.

(5) Include operations guide, support and diagnostics manual to provide the minimum but not be limited to the following procedures and information:

(a) Recommendation of any regular operation process required to maintain the effective performance of AMS

(b) System & applications startup and shutdown procedures (c) System & applications backup and restore procedures (d) Application error codes and description and fix recommendation (e) Configuration database detailing configuration at all levels and for all environments of the

Solution (f) Knowledge base to be employed to deliver support services

(6) System and technical specifications for all Customizations, interfaces, processes, data models and information flows. This documentation should be geared toward a system administrator type individual who would be responsible for the configuration and maintenance of servers, repositories, integration interfaces, security, metadata setup and support.

(7) Source code and supporting documentation, for any Customized components.

(8) The software migration process for the base product set up and configuration, e.g. security matrices, workflow processes, and metadata.

(9) The software migration process for any customized modules and interfaces.

3.2.9 Reference Hardware Platform To effectively support and assess the Total Cost of the proposed AMS, the City requires that Proponents recommend a hardware infrastructure that can support the proposed AMS while demonstrating compliance to the City’s environment and existing infrastructure. It is important that the hardware proposed be able to integrate within the City’s infrastructure so when making a recommendation of the hardware, Proponents are to take into consideration all information provide in this RFP including but not limited to user counts in the Price Details Forms in Appendix D, the Requirements expressed in the Proposal Evaluation Tables in Appendix E as well as the AMS Reference Material provided in Appendix F. Please note that the hardware infrastructure recommended must support an AMS which will operate seven (7) days a week, twenty-four (24) hours per day with an expected 99.5% availability (with the exception of two (2) four (4) hour weekend maintenance windows per week).

VIEW

ING C

OPY

DO NOT S

UBMIT




Proponents, should therefore, as part of their response: (1) Provide a hardware infrastructure recommendation and reference architectures to support the

AMS in a development, testing, training and production Environment.

(2) Specify the quantity and type of hardware as well as any other components that would comprise part of the “infrastructure” required to meet the technical and performance Requirements of this RFP.

(3) Provide hardware sizing based on assigned resources (CPU, memory and storage) in either a virtualized (VMWare ESX, Solaris Container or Logical Domain, AIX Logical Partition) or a shared hosting environment.

(4) Provide all the details necessary to ensure that the City can acquire the specified hardware and infrastructure (including but not limited to Oracle, SQL Server, WebSphere, WebMethods, Domino, Citrix, Xmedius Fax, ViewDirect), in a fully functional manner.

Proponents are to populate the Price Detail Form Appendix D.6 with details of the hardware infrastructure and associated costs. Please note that The City plans to use its own procurement processes to acquire the hardware proposed to implement the AMS; however, the City reserves the right to request that the Vendor purchase the proposed hardware and infrastructure components at the prices detailed in the Price Detail Form in Appendix D.6.

3.3 Professional Services

The Vendor is to provide professional services in but not limited to the following areas as required to implement the AMS:

(1) IT Service Management (2) Installation, Configuration and Implementation Services (3) Migration Services (4) Integration Services (5) Training Services

3.3.1 IT Service Management The City employs the Information Technology Infrastructure Library (ITIL) therefore the Vendor is expected to work with the City to provide software and services to the City in accordance with the City’s practices in the areas of:

(1) Change Management; (2) Configuration Management; (3) Release to Production; (4) Service Level Management; (5) Incident Management; (6) Problem Management; (7) Request Fulfillment.

Proponents, in their response to this RFP, should outline their approach to leveraging Information Technology Infrastructure Library best practices based on ITIL V3 and outline their approach for coordinating and for integrating any in-house processes during the Service lifecycle. Proponents are requested to pay particular attention to detailing the Services they plan to offer.

VIEW

ING C

OPY

DO NOT S

UBMIT




3.3.2 Installation, Configuration and Implementation Services The Vendor is to offer complete Installation, Configuration and Implementation Services (ICIS) for the software forming part of the Solution. The Vendor also is to offer guidance, assistance and support during the Installation, Configuration and Implementation of the infrastructure according to the reference architectures recommended. 3.3.2.1 Hardware Installation, Configuration and Implementation Services As described in Section 3.1.7 Reference Hardware Platform, Proponents are to propose hardware and other infrastructure components along with a reference architecture to support the AMS. The Vendor, as part of ICIS, should be prepared to assist the City, when requested, during the City’s installation, configuration and implementation of the hardware infrastructures and integration of all components with other City operational infrastructure and management tools. To facilitate with all activities and tasks associated with the City’s installation, configuration, implementation, testing and troubleshooting, the Vendor is to: (1) Provide detailed architectural documents. (2) Provide detailed documentation, installation scripts and configuration parameters specifying the

version and configuration details of all components of the Solution, including but not limited to the operating system, file systems, storage, disk partitioning as well as network configuration, firewall and other security related rules, system and user accounts and permissions.

(3) Provide detailed documentation specifying the resources (CPU, memory, disk space...) required for each component of the Solution.

(4) Provide a plan describing all steps necessary to ensure that the Solution's hardware installation and integration within the City’s infrastructure environment is fully functional and compliant with City policies, procedures and standards.

(5) Provide detailed instructions on an as needed basis on how to install and configure servers, workstations and devices as well as troubleshoot issues related to the installation and configuration of the hardware infrastructure which may impede the full deployment of the Solution.

3.3.2.2 Software Installation, Configuration and Implementation Services The Proponents are to detail and describe all activities and tasks that are required to ensure that AMS software (including all Modules and components) is fully functional in the City’s environment. The Vendor is to provide ICIS to include, but not be limited to, all activities and tasks associated with installation, configuration, implementation, testing, troubleshooting as well as the development and delivery of contingency plans and Knowledge Transfer. The ICIS should be provided by professionally trained software specialists who have been trained specifically on AMS Software and who have specialized training and working experience in the activities and tasks required for ICIS. Such activities should include, but are not be limited to: (1) Planning, which includes assessing/analyzing the City’s computing environment (hardware and

software) and developing a plan that outlines all of the installation, implementation, configuration & integration, testing/troubleshooting activities, including time frames, required to ensure that ICIS are delivered on time. The plan should also include a contingency plan to restore the City’s environment back to its original state in the event of technical failure. Plans should also include City and Proponent roles, responsibilities and accountability during ICIS. In the event of any difference of opinion, the Proponent should have a dispute resolution mechanism/process in place and should include it in the ICIS plan.

VIEW

ING C

OPY

DO NOT S

UBMIT




(2) Installation, which includes the activities required to make the Software fully operational in the City’s computing environment and to meet, at minimum, the Solution’s recommended minimum software/hardware installation requirements. The scope of installation services includes the physical installation of software onto a specific computer system.

(3) Configuration includes, but is not limited to, setting/implementing the parameters and values that enable effective operation of the Software by all users, including effective operation within the City’s computing environment; setting operational defaults; interconnecting the Modules that comprise the AMS and implementing operational settings so that the Modules function in concert; configuring business rules; implementing advanced operational settings to meet desired levels and modes of operation; and verification that the Software meets or exceeds the minimum Requirements set out in this RFP.

(4) Testing/troubleshooting includes the activities required following the installation, configuration and implementation of the Software. Such activities include testing of the Software (including all Modules) so that the AMS is fully operational in the City environment. In cases where the AMS is not functioning properly in the City environment, it includes troubleshooting to determine the cause of problem and resolving the problem to ensure that the Software is fully functional in the City environment.

(5) Knowledge Transfer may be accomplished via a variety of means including, but not limited to, formal and informal training, documentation, demonstrations, walkthroughs, mentoring and coaching so that specific City Personnel members may be capable of performing AMS installation, implementation and configuration. The Vendor is to develop and deliver a strategy specific to Software ICIS detailing its approach and activities to ensure Knowledge Transfer from the Vendor to City Personnel throughout the implementation phases. The City environment should not be impacted by ICIS activities performed by the Vendor. If the City’s environment has been impacted due to the installation, configuration and implementation, the Vendor should restore the City’s environment back to its functional original state (i.e., prior to the commencement of ICIS activities).

3.3.3 Migration Services The Vendor is to offer a range of Migration Services to the City with the goal of migrating data from legacy applications. It is expected that data migration to the proposed AMS will be accomplished after cleansing and verification of the data by the City. Subsequent to cleansing and verification, migration is to be executed using one or more extract, transform and load steps. To facilitate this work the City will provide the Vendor a list of the entities defined in the City’s logical data model that need to be populated by data migrated from these legacy applications. The City will work with the Vendor to ensure that all data is appropriately migrated to the AMS using the following steps: 3.3.3.1 Data Verification and Cleansing The City has identified the data to be migrated to the AMS and is currently in the process of validating and cleansing this data in the legacy applications. This work will continue until cleansing is complete. 3.3.3.2 Data Extraction The Vendor, as per this RFP, will work with the City to develop an integrated strategy and plan to address the migration of the validated and cleansed data from the legacy applications to the AMS. The City, when requested by the vendor, will perform the necessary data extraction from legacy applications, in an agreed upon format, for subsequent transformation and loading into the AMS by the Vendor.

VIEW

ING C

OPY

DO NOT S

UBMIT




3.3.3.3 Data Transformation The Vendor will work with the City to determine the appropriate mapping of data into the AMS’s physical data model, and transform the data ensuring compliance with data requirements as expressed in the logical data model and accompanying data dictionary, and maintaining referential integrity and consistency within the AMS. The City will assist the Vendor as required during this activity. 3.3.3.4 Data Loading and Testing The Vendor will load the data into the AMS in a user acceptance test environment and will work with City Personnel to ensure that migrated data has been appropriately cleansed, extracted, transformed and loaded in manner consistent and compliant with the AMS. The above steps are to be repeated as many times as necessary as described above then repeated in conjunction with other cutover activities into the production environment. 3.3.4 Integration Services The Vendor is to provide integration service to the City which will include configuring both direct and enterprise bus service integrations for bulk file transfers (asynchronous) and real time (synchronous) interfaces. The Vendor is to provide integration services to perform development, testing and deployment of the integrations above as part of the AMS The AMS is expected to have an open architecture to enable integrations through loosely coupled interfaces and is to provide application programming interfaces that expose Functionality through service interfaces from the AMS for use and consumption by external systems. Currently, the City has invested in webMethods Integration Server as their platform for integration. The AMS application programming interfaces are to be exposed through an Enterprise Service Bus preferably using webMethods Integration Server to leverage prior investment, and to build further capacity for future integration. The provided application programming interfaces are to be based on industry interface standards and be supported, stable and proven (used in existing integrations). 3.3.5 Training Services The City plans to become self sufficient in the business and systems operations of the Solution during the course of implementation of the AMS. To accommodate City Personnel training and Knowledge Transfer, the Vendor is expected to provide City specific Knowledge Transfer and role based targeted training on the City’s AMS throughout the life cycle of the implementation. Knowledge Transfer can also be delivered through formal and informal training. (1) Informal training may be accomplished using a variety of means including, but not limited to,

providing detailed documentation, demonstrations, walkthroughs, mentoring and coaching so that the specific City Personnel, assigned to roles, will be capable of performing all aspects of AMS installation, implementation, configuration, testing, support and management as required by their roles (as described in Section 3.3.5.1 City Roles).

(2) Training on the other hand should be delivered in a modular format (e.g. beginner,

intermediate, advanced) and specifically target City roles (as described in Section 3.3.5.1 City Roles) and must account for the City’s specific implementation of AMS. Training via electronic channels should be available at City locations. Training modules should include an assessment that trainees can complete at the conclusion of each level before advancing to the next training level.

To this end, the Vendor will be required to develop and deliver a strategy detailing its approach to Knowledge Transfer and training activities to include a “train the trainers” approach.

VIEW

ING C

OPY

DO NOT S

UBMIT




Any approach offered by the Vendor should ensure complete training and Knowledge Transfer from the Vendor to City Personnel so that City trainers can provide further training as the Solution is implemented throughout City divisions. The Vendor’s training and Knowledge Transfer strategy should include a training plan detailing among other things, the number of sessions, specific class schedule, number of training days per participant and the acceptance criteria for evaluation. It is important that the plan include methods of assessing the outcome of the Knowledge Transfer; and measurements of the demonstrated capability of City Personnel to fully support the Solution after each implementation. The Vendor is to provide material to evaluate training effectiveness for the City’s AMS through participant feedback and pre or post assessments. The evaluation should confirm that City Personnel or trainees who receive training or Knowledge Transfer have the necessary skills and abilities to perform their new roles. The Vendor will be required to provide City trainees with all relevant training materials which may include participant guides, facilitator guides, slides, handouts for exercises and any pre or post training assessments, in both hard and electronic copies. Soft copies of all documentation required for Knowledge Transfer subject areas (see examples below) should also be provided to technical Personnel to support Knowledge Transfer subject areas as described below. The Vendor should make all such training material available to the City in hard copy and electronic formats for use by the City as it sees fit. The City will have the right to duplicate training materials for use within the City and the City may modify the training to brand it and generally modify it to account for City specific needs. The City may request that the Vendor review the changes made by the City. The training materials and documentation will be provided to trainees and to City trainers at no extra cost. The Vendor is to provide a full-time training resource such as a training manager to report to the City's designated training lead throughout the implementation of AMS to organize and implement the training plan, including making any required changes to the number of training sessions for each target audience group. The training manager is to work with the City on the most suitable timetable for training activities. 3.3.5.1 City Roles The Vendor is to provide training services for the following City roles: Basic End User - The Vendor is to provide training services to train trainers of End Users of the Solution thus enabling End Users to operate the Software at an End User capacity, taking full advantage of the Solution’s End User Functionality (excluding those specific to enabling Power Users to perform special responsibilities, which are covered through Power User training). Proponent should provide a minimum of two (2) days of Basic End User training on a per user basis. Power User – The Vendor is to provide training to City trainers of Power Users of the Software who are to be assigned special delegated responsibilities by an Administrator (e.g., for controlling workflows, accessing audit data, generating system reports, implementing business rules pertaining to particular sets of records, or more specifically adding new metadata fields, administering Security classifications, freezing documents, restricting access to Records and Documents, administering hardcopy record charge-outs and charge-ins, providing final authorization of records transfers and disposals, or deleting Records). This training should enable a Power User to operate the AMS to take full advantage of the Solution’s Functionality. Proponent should provide a minimum of two (2) days of Power User training on a per user basis. Managers and Supervisors – Managers and Supervisors are to be considered as another

type of Power Users and the Vendor is therefore to provide or arrange for training services targeted to those supervisors and managers of the business units. Proponent should provide a minimum of one and half (1 and 1/2) days of Manager/Supervisor training on a per user basis.

VIEW

ING C

OPY

DO NOT S

UBMIT




Executive/Senior Management – Executive and Senior Management Personnel are also to be considered as other types of Power Users and will require training services targeted at providing them with training that is to enable them to take full advantage of the Solution’s Functionality in order to operate the AMS at an executive level. Proponent should provide a minimum of one and half (1 and 1/2) day of Executive/Senior Management training on a per user basis.

Technical/Administrator Users – The Vendor is to provide direct training services that enable the technical, administrator and quality assurance Personnel to install, implement, perform configuration tasks and test the AMS thus enabling them to understand and take full advantage of the AMS. Training services are to ensure that the skills and knowledge required to understand, test, operate and support the Solution for the various technical Personnel has been adequately delivered. This training should include instruction for all facets of installation, integration, configuration, security implementation, workflow management, quality assurance, operation of hardware (such as scanning equipment), support of the AMS as well as management and control of the Solution. Knowledge transfer should include the provision of all documentation and blueprints created and used for installing, implementing, configuring, supporting and testing the Solution in the City’s computing environment (e.g., documentation that would provide all the activity/details on how the Solution was installed and configured in the City’s environment). Proponent should provide a minimum of three (3) days of Technical/Administrator training on a per user basis. City's Service Desk and Desktop Support teams – Service Desk and Desktop Support

Personnel are to be considered as another type of Technical/Administrator Users and the Vendor is to provide and arrange for direct training of the City's Service Desk and Desktop Support teams and to City trainers of Service Desk and Desktop Support. This is to include Orientation to the Solution, integration, typical service desk/ desktop support issues and resolutions, FAQs, escalation procedures, and Knowledge Transfer. The number of sessions, specific classes, and the number of training days per participant should be provided in the Training Strategy and Training Plan documents and as agreed upon by the City. Proponent should provide a minimum of three (3) days of Service Desk/Desktop Support training on a per user basis.

3.3.5.2 Training Methods The Proponents are to provide the City with all available options for Training Services. Options may include any of the following methods: (1) Classroom training at City location;

(2) Web-based training using Proponent hosting services or City hosting services; and

(3) Self-paced training or computer based training.

Where applicable the ideal training method(s) should be identified to accomplish Knowledge Transfer in specific subject areas and for each method, the Proponent is to specify Solution requirements for all PCs and/or related technologies in city classrooms where training could take place. The Vendor is to provide each trainee a copy of the training materials as described in Section 3.2.5 Training Services for each module completed. Training guides and associated documents should include step by step instructions for all relevant functions, and screen shots specific to the City’s AMS as appropriate. Classroom training - The Vendor should provide the City with the option of in-person instructor based classroom training at a City site or at a Vendor site within the Greater Toronto Area.

VIEW

ING C

OPY

DO NOT S

UBMIT




Training at Vendor site, if required, should be in a classroom environment accommodating 10 – 12 participants. Facilities should include a PC for each participant and instructor with a projector or large monitor to view the instructor's screen. Facilities should be in the Greater Toronto Area with easy access for parking or TTC. Web-based training - If this option is available, the Vendor should provide web based live interactive training sessions using the Proponent’s hosting service, an online lab service within the City or a City hosting service. The Vendor should provide any interface and/or software required to connect to the live training session/website so the training is accessible to City trainees from City locations. The Vendor’s Instructor is responsible to schedule and coordinate the training sessions with the attendee. These web based live interactive training sessions should include the following:

(1) Training sessions should be delivered by a certified instructor;

(2) Training should be accessible from the City’s desktop using internet browser and telephone;

(3) All training materials should be delivered to the attendee a minimum of 5 Business Days prior to the start day of the training;

(4) Each trainee should be provided with a log-on user ID and password;

(5) Contents (course material) should be identical to that provided for classroom training and online training;

(6) Training session should be Interactive with the Instructor;

(7) The live online interactive environment should allow the trainee to ask questions throughout the course and receive immediate answer/feedback.

Self-paced training or computer based training - If this option is available, the Vendor may provide web based self-paced training sessions using the Vendor’s virtual training labs for trainees who prefer hands on training and learning at their own individual pace. These self-paced training sessions should include the following:

(1) Ability to learn in a virtual lab environment, using internet browser;

(2) Online training is self-paced and has step-by-step instructions for learning and performing specific tasks;

(3) Contents (course material) are identical to that provided for classroom training, online interactive training and self-paced training;

(4) All training materials are delivered to the trainee before the trainee starts the self-paced training.

3.3.6 AMS Pilot Implementation - PF&R (1) The Asset Management Solution shall be configured to meet Parks, Forestry and Recreation

(PF&R) Division’s Installation, Configuration and Implementation Services (ICIS) Requirements that are listed in Appendix F.6

(2) The Asset Management Solution must interface with the City’s capital planning system, CAPTOR.

(3) Prior to Go-live, information will be migrated from PF&R’s existing systems to the Solution including:

VIEW

ING C

OPY

DO NOT S

UBMIT




(a) CAMP, (b) CLEAN, and (c) SAP – PM / RE.

(a) Prior to implementation in production environment, the Vendor will develop training materials for

both computer-based and instructor-led, classroom training and provide train-the-trainer classroom training as detailed herein.

3.4 Project Activities and Deliverables 3.4.1 Phase 1 – Project Initiation (1) The Vendor, at a minimum and based on their proposed approach, will be expected during the

Project Initiation phase to:

(a) Work with the City to review the business objectives and overall Statement of Work; and (b) Provide a detailed Project Plan within two (2) weeks of the Effective Date for the design

and implementation of the proposed Asset Management System (AMS) Solution.

(2) The following are the minimum Deliverables for Phase 1 – Project Initiation:

(a) A detailed Project Plan which contains the detailed tasks and timelines to complete the Services in accordance with the specifications and Requirements of the Agreement. The Project Plan will include:

i. A consolidated view of the assigned City and Vendor resources and the effort required to carry out all of the related activities, tasks and Deliverables for the Project;

ii. Information for all Project resources to ensure that they have a clear understanding of the activities and tasks that they are responsible for performing to ensure timely completion of the Project; and

iii. Sub-plans for other activities such as deployment, integration, training, Knowledge Transfer, data migration and testing.

3.4.2 Phase 2 – Requirements Validation (1) The Vendor, at a minimum and based on their proposed approach, will be expected during the

Requirements Validation phase to:

(a) Work with the City to allow the City confirm the Functional, Technical and Non-Functional Requirements to be implemented;

(b) Document the details of the Requirements; and

(c) Conduct validation sessions with City staff to validate the detailed Requirements.

(2) The minimum Deliverable for Phase 2 – Requirements Validation is a detailed and comprehensive document setting out validated Functional, Technical and Non-Functional Requirements.

3.4.3 Phase 3 – Prepare Design Documentation (1) The Vendor, at a minimum and based on their proposed approach, will be expected during the

Prepare Design Documentation Phase to:

(a) Confirm the hardware infrastructure required by the City to support the proposed Solution;

VIEW

ING C

OPY

DO NOT S

UBMIT




(b) Conduct, as necessary, sessions with City staff in order for the Vendor to document the overall Solution Design;

(c) Assisting the City in the completion of Privacy Impact Assessments (PIA), Threat Risk Assessments (TRA) and Vulnerability Assessments (VA) which the City will contract out to third party service providers; and

(d) Document the Solution Design.

(2) The following are the minimum Deliverables for Phase 3 – Prepare Design Documentation:

(a) A detailed Solution Design Document which describes all aspects of how the Vendor’s proposed Solution will be designed and implemented; and

(b) A detailed Technical Design Document, either as a stand-alone document, or as a component of the Solution Design Document.

3.4.4 Phase 4 – Build/Implement Solution (1) The Vendor, at a minimum and based on their proposed approach, will be expected during the

Build/Implement Solution Phase to:

(a) Build and install the Solution, which, at a minimum, includes:

i. Working closely with dedicated City technical staff during the entire Project to provide skill and Knowledge Transfer for all aspects of the integration of the Solution with the City’s existing infrastructure;

ii. Assisting in the installation and Configuration of the hardware and operating system (if any) for the Solution with City’s technical staff;

iii. Assisting the City’s technical staff in developing a lab (which will hold the Development Environment and the Staging Environment) for functional testing of the features of the Solution;

iv. Installing the Solution in the Development, Training and Staging Environments with the participation of City technical staff; and

v. Performing any Customization and/or Configurations as required with the participation of City technical staff.

(b) Test the Solution, which, at a minimum, includes:

i. Ensuring that prior to integration of the proposed Solution with the City’s infrastructure, it is thoroughly tested in the Testing/Training Environment to ensure proper functionality and acceptable performance;

ii. Providing test criteria for review and approval by the City prior to performing Solution testing;

iii. Testing the Solution, with the participation of City technical staff, to ensure all of the Functional, Technical and Non-Functional Requirements have been met and that the Solution is functioning properly;

iv. Providing sample testing criteria for user acceptance testing (UAT) by the City; v. Providing training to City staff on how to perform UAT; vi. Assisting the City in conducting the UAT for a minimum four (4) calendar week

UAT period as detail in the table below:

VIEW

ING C

OPY

DO NOT S

UBMIT




Deficiency Severity

Severity Description Impact on UAT

Major Disastrous, severe or significant consequences for the Solution with no immediate workaround. Testing functions cannot be fully completed.

Four (4) week UAT restarts from zero once the deficiency has been fixed.

Minor Small or negligible consequences for the Solution. Simple workarounds typically exist.

Four (4) week UAT period halted mid-stream while deficiency is fixed. Upon fix, UAT period will continue again, for a minimum of two (2) weeks, even if there are less than two (2) weeks remaining in the original four (4) week UAT period.

Cosmetic Trivial defects that cause no negative consequences for the Solution. Typically related to appearance as opposed to function.

Four (4) week UAT period halted mid-stream while deficiency is fixed only if deficiency takes more than four (4) hours to fix. Upon fix, UAT period continues to its conclusion.

If the Vendor is unable to correct any major or minor failure(s) within three (3) of the UAT period(s), or if more than three (3) failures of the same type (excluding cosmetic) occur within the UAT Period, the City may deem the Solution to be a total failure and at its option may terminate the UAT period and terminate the Agreement. In such event, the Solution shall be returned to the Vendor and the Vendor shall forthwith repay to the City all payments it has received pursuant to the Agreement (plus interest commencing on the day of the termination at a rate of prime plus 2 percent per annum). Conversely, if the Vendor does correct any error(s) or failure(s) and if more than three (3) failures of the same type do not occur within the City Acceptance Testing Period, or in the event that the City elects not to exercise its right of termination as set out herein, then the Vendor shall be entitled to receive a notice of waiver of the termination rights from the City in respect of such UAT period and the Project will proceed to Phase 5.

(c) Provide training to City staff, which, at a minimum, includes:

i. Executing the proposed “end user” training plan provided in response to Requirement 7.4.2 in Appendix F.4;

ii. Executing the proposed “power user” training plan provided in response to Requirement 7.4.1 in Appendix F.4;

iii. Executing the proposed System Administrator training plan provided in response to Requirement 7.4.3 in Appendix F.4;

iv. Executing the proposed technical training plan provided in response to Requirement 7.4.4 in Appendix F.4; and

v. Providing all training manuals, system manuals, testing scripts, results as the case maybe for the City’s review, and once approved, for the City’s use.

(d) Upon the successful completion of UAT, provide support throughout the

promotion/launch of the Solution into the Production Environment, which, at a minimum, includes:

i. Identifying any work related to the build and/or implementation of the Solution that could negatively impact or interfere with the normal operation of the City’s infrastructure, and performing that work outside of Business Hours;

ii. Providing a “back-out” or “restore” plan in order to deal with any unforeseen problems that might arise during the build and/or implementation of the Solution; and

VIEW

ING C

OPY

DO NOT S

UBMIT




iii. Providing adequately trained staff on-site during the build and/or promotion/launch of the Solution, to deal with any difficulties related to the Solution that may arise.

(1) The following are the minimum Deliverables for Phase 4 – Build/Implement Solution:

(a) Successful design, build, implementation and testing by the Vendor of the Solution;

(b) Delivery of test scenarios and criteria for all stages of testing

(c) Successful completion of UAT;

(d) Data migration of Asset Management information;

(e) Successful Cut-over and implementation in the Production Environment;

(f) Completion of all training and delivery of all training material and related Documentation;

(g) Provision of all Documentation objects described in Article 3.4.10; and

3.4.5 Phase 5 – Monitored Deployment (1) The Vendor, at a minimum and based on their proposed approach, will be expected during the

Monitored Deployment phase to:

(a) Provide adequate on-site support (working with City Staff) during Business Hours, perform any fixes as necessary to ensure the Solution is free of errors or malfunctions, and achieve a safe and trouble-free integration with the City’s infrastructure. In the instance of an error or malfunction which renders the Solution inoperable, the City requests same day response time from the Vendor.

(b) Provide during Business Hours on-call technical support which shall include telephone and help desk support/call tracking and management. The Vendor should log, track and manage all calls to ensure they are not lost, forgotten or neglected.

(c) Provide documentation of any and all errors or malfunctions that occurred and the steps taken to fix the errors or malfunctions, including any and all information pertinent to the cause of and fix for the given error or malfunction.

(2) The following are the minimum Deliverables for Phase 5 – Monitored Deployment:

(a) Conduct periodic (daily/weekly/bi-weekly/monthly) status report meetings

(b) Delivery of periodic deployment status / audit reports

(c) Reports / Meetings should include a production appraisal/review of, but not limited to:

i. System Performance ii. Security Management iii. Configuration iv. System Interfaces v. System Capacity vi. System Logs, Incidents vii. Change Requests

(d) Conduct at a minimum 1 System Recovery exercise

VIEW

ING C

OPY

DO NOT S

UBMIT




(e) Delivery of a production baseline report

(f) Completion of an application / physical system configuration audit

In addition to the foregoing minimum requirements and Deliverables, the Vendor will be expected during Phase 5 to deliver such other requirements which are specific to PF&R as set out in Appendix F.6.

3.4.6 Phase 6 – Final Acceptance (1) The Vendor, at a minimum and based on their proposed approach, will be expected during the

Final Acceptance phase to acquire approval of the Solution from the City by issuing a Final Notice of Acceptance of Solution.

(2) The following is the minimum Deliverable for Phase 6 – Final Acceptance:

(a) Completion of all Vendor responsibilities to permit the request for a Final Notice of Acceptance of Solution from the City; and

(b) Receipt of a Final Notice of Acceptance from the City.

3.4.7 Ongoing Enhancements (1) Throughout the term of the Agreement, the City may require the Vendor to develop

enhancements to the Solution not covered under the standard support and maintenance agreements. The City and the Vendor will agree on a change order process as part of negotiations.

(2) Enhancements that exceed the Total Price, impact milestones and/or the milestone payment schedule or represent a significant change in scope or cost as determined by the appropriate City authority and approving body will require an amendment to the Agreement, and/or will follow the change order process.

(3) The Vendor will provide a breakdown of each activity as per Section 7 – Cost of Services (Total Proposed Price)

3.4.8 Project Management 3.4.8.1 City Responsibilities

(1) The City will assign a minimum of one (1) Project Manager for the Project and that person will

be responsible for:

(a) Serving as the key contact for the Vendor; (b) Approving the Vendor’s Project Plan; (c) Providing clarifications and instructions to the Vendor throughout the Project; (d) Monitoring the Vendor’s delivery of the Services; and (e) Providing overall direction, management and leadership of the Project for the City.

(2) The City will assign staff members to the Project to provide existing information to the Vendor related to business processes.

(3) Wherever possible, the City will provide the Vendor with work space, computers and

telephones. Limits to this provision may be imposed by the City, at its sole discretion, depending on the number of resources proposed by the Vendor.

VIEW

ING C

OPY

DO NOT S

UBMIT




(4) The City plans to use its own procurement processes to acquire the hardware proposed to implement the Solution; however, the City reserves the right to request that the Vendor purchase the proposed hardware and infrastructure components at the prices detailed in Appendix D Price Detail Forms. The City will have an Executive Advisory Committee that will be responsible for:

(a) Approving all Deliverables and assuming responsibility for the overall direction of the

Project; (b) Acting as the primary decision making body to oversee and to provide overall strategic

direction for the Project Working Group; (c) Acting as the primary authority for all decisions relating to the Solution’s design,

methodology, architecture and implementation, as required; (d) Acting as primary liaison with senior City corporate representatives, senior Vendor

representatives and with senior representatives of outside community agencies and organizations, as required;

(e) Acting as the primary authority for approval of Change Orders and amendments to the Agreement; and

(f) Acting as primary authorities for, and providing all approvals for all outgoing publications or communications regarding the Project.

(5) The City will have a Project Working Group that, under the direction of the City Project

Manager, will be responsible for:

(a) Acting as liaison with the Vendor for the purpose of designing, developing, testing, training and implementing the Solution, and coordinating all Vendor activities and results;

(b) Assisting the Vendor in the investigation, Documentation and consultation for the formal business analysis of the relevant business processes;

(c) Making recommendations to Executive Advisory Committee regarding necessary changes to business practices affected by the implementation of the Solution;

(d) Assisting the Vendor in determining the impacts on the Clients, City staff, and/or any other impacted community agencies, organizations or individuals;

(e) Leading and/or assisting in the implementation of the Solution and ensuring a smooth transition of all affected business practices and protocols; and

(f) Reviewing and making recommendations to Executive Advisory Committee regarding all aspects of the Solution and its impact on the division and/or the City as a whole.

3.4.8.2 Vendor Responsibilities

(1) The Vendor will assign a Project Manager to coordinate the delivery of the Services with the

City’s Project Manager, and that person will be responsible for:

(a) Submitting a detailed Project Plan satisfactory to the City within two (2) weeks of the Effective Date of the Agreement;

(b) Providing regular written progress reports to the City Project Manager at a minimum of once weekly and more frequently if the situation so warrants, including meeting/interviewing with City staff throughout the Project as required;

(c) Serving as the key contact for the City;

(d) Co-ordinating the delivery of the Services, and identifying City resources that may be required to work on the Project, specifying skill sets, dates and work hours; and

(e) Updating the Project Plan as required for the approval of the City’s Project Manager, ensuring that all activities remain on track and that the Services and Deliverables are completed within the timeframes and boundaries described by the Agreement.

VIEW

ING C

OPY

DO NOT S

UBMIT




(2) The Vendor will take direction from the City’s Project Manager throughout the Project. (3) The Vendor will be responsible for managing and/or replacing their Project staff assigned to the

Project when so requested by the City, as it deems necessary, and for whatever reason. No Vendor Personnel assigned to, or working on the Project will be removed by the Vendor from the Project without the City Project Manager’s prior written consent unless the removal is beyond the control of the Vendor. The replacement of staff shall not entitle the Vendor to any increase in the Total Price.

(4) The Vendor will require written Notice of Acceptance for each Deliverable from the City before it

can produce an invoice for payment for such Deliverable. (5) The Vendor will cooperate with the City and provide full disclosure in the completion of a

Privacy Impact Assessment (PIA), Threat Risk Assessment (TRA) and a Vulnerability Assessment (VA) at appropriate times throughout the Project to be determined in consultation with the City.

3.4.9 Mandatory Requirements (1) Mandatory Requirements for the AMS Project which require Proponent acknowledgement are

contained in:

(a) Appendix F.1 – Mandatory Requirements Compliance Tables

(b) Appendix F.2 – Functional Requirements Compliance Tables - Section 2.1 and Section 2.2

(c) Appendix F.3 - Requirements Compliance Tables - Technical Requirements, Section 3.1 to Section 3.5

(d) Appendix F.4 – Non-Functional Requirements Compliance Tables , Section 4.1 to Section 4.4

(2) Failure in acknowledging or completing any of the mandatory requirements will result in automatic disqualification.

3.4.10 Documentation Requirements (1) The following statements represent Mandatory Documentation Requirements that will only

come into effect for the successful Proponent (i.e. the Proponent that becomes the Vendor).

(2) The Vendor must provide all Documentation required to operate and to maintain their proposed Solution, and this requirement shall form part of any Agreement. Vocabulary should be consistent throughout the manuals; a consistent appearance is also required. It is not required for Proponents to include the required Documentation with their Proposal.

(3) Hard and soft copy versions of all requested Documentation will be provided by the Vendor as part of the implementation. The format of any electronic Documentation must be supported by the proposed AMS Solution and the City’s authoring tools. Such Documentation must be current, complete and accurate.

(4) Documentation provided by the Vendor will include a User Manual which illustrates and provides instructions for all system functions, including screen and report layouts. This Documentation should instruct the users on how to use the AMS functions and features with clear examples.

VIEW

ING C

OPY

DO NOT S

UBMIT




(5) Documentation provided by the Vendor will include a System Administrator Manual which documents the specific system administration functions available in the Proponent’s proposed Solution.

(6) Documentation provided by the Vendor will include all application/system configuration specifications, procedures and functions, including screen and report layouts. It will also fully document the development environment for the system, including a description of all connections to the databases as well as the processing logic for each module.

(7) Documentation provided by the Vendor will include recommended hardware and software selections as well as performance tips, backup and recovery and security routines.

(8) Documentation provided by the Vendor will include an operations guide and diagnostics manual.

(9) Documentation provided by the Vendor should include system and technical specifications for all customizations, interfaces, processes, data models and information flows. This Documentation should be geared toward a System Administrator-type individual who would be responsible for the configuration of servers, repositories, integration, APIs, security setup, and sustainment.

(10) Documentation provided by the Vendor should include source code and supporting Documentation, for any customized components.

(11) Documentation provided by the Vendor should include the software migration process for the base product set up and configuration, e.g. when upgrading to a new version or applying a patch.

(12) Documentation provided by the Vendor should include the software migration process for any customized modules and interfaces.

3.4.11 Functional, Non-Functional and Technical Requirements (1) The Vendor should provide a Solution that addresses the following:

(a) Functional Requirements (identified in Appendix F.2 – Functional Requirements Compliance Tables, Sections 2.1 to 2.4) including Project Management Requirements and Reporting Requirements;

(b) Technical Requirements (identified in Appendix F.3 – Technical Requirements Compliance Tables, Sections 3.1 to 3.10) including Infrastructure and Deployment, Security and Privacy, Identification, Authentication and Authorization, Audit, Vulnerability Management, Integration and Design Requirements; and

(c) Requirements (identified in Appendix F.4 – Non-Functional Requirements Compliance Tables, Sections 4.1 to 4.3) including Proponent Project Team & References, Knowledge Transfer, Installation & Implementation and Training Requirements.

3.4.12 Implementation Requirements (1) The Vendor should provide a Solution that addresses the following:

(a) Implementation Requirements (identified in Appendix F.6 – Implementation Requirements – PF&R, Sections 6.1 to 6.5) including Installation, Configuration and Implementation (ICIS), Migration, Integration and Training Requirements;

VIEW

ING C

OPY

DO NOT S

UBMIT




3.4.13 Warranty Period, Ongoing Support and Maintenance (1) Once the City has been provided with a Final Notice of Acceptance of Solution, a minimum one

(1) year Warranty Period shall commence. All components (including items such as: 3rd party software or open source products) of the Solution must be covered during the one (1) year Warranty Period, during which time maintenance and support as described below will be provided at no additional cost to the City.

(2) The Vendor must provide at no additional cost to the City, any and all updates to software components during the Warranty Period. This includes but is not limited to, application software patches and other code updates as required.

(3) Work may be performed at the City location or remotely. If remotely, the Vendor’s support Personnel shall execute the City’s Remote Access Agreement.

(4) At a minimum, the Vendor will provide phone support with coverage during Business Hours, with two (2) hour mean response time, during the one (1) year Warranty Period.

(5) The Vendor will provide the specific level of support chosen by the requesting Division from the list of support options as set out in the Vendor's Proposal in response to this RFP.

(6) Throughout the duration of the Agreement as part of support and maintenance of the Solution the City and all Users will be entitled, at no additional cost, to new versions of the software that may be issued from time to time.

(7) The City defines new versions as new software release versions or updates of the Application that contain either enhancements to the Application or corrections to deficiencies where the Application does not perform according to Documentation.

(8) The Vendor will be required to provide a guarantee that all patches, upgrades, enhancements or new software versions will be made available to the City, at no additional cost, and will be compatible with all customizations made by the Vendor to their Application in order to meet the Requirements outlined in Appendices F.2 and F.3 of this RFP.

(9) At the City's sole discretion, the components of the Proponent's proposed Solution must be maintained current with the Vendor's released and supported products, during the one (1) year Warranty Period.

(10) Proponents must agree that at the City's sole discretion, various components of the Vendor's Solution, covered during the one (1) year Warranty Period may be removed with thirty (30) days notice to the Proponent or added with seven (7) days notice to the Vendor.

(11) In the event of any breach of this warranty, the remedies available to the City shall include, but not be limited to:

a. The Vendor restoring the Deliverable to the same level of performance as represented and warranted herein;

b. The Vendor repairing or replacing the Deliverable with a Deliverable conforming with this representation and warranty; and

c. The Vendor granting or securing for the City or its authorized agent permission to make any modifications necessary to make the Deliverable compliant with this representation and warranty and arranging for any necessary waivers of moral rights or other intellectual property rights to make such modifications.

VIEW

ING C

OPY

DO NOT S

UBMIT




(12) Upon execution of this Agreement, at the request of the City, the Vendor will enter into a Source Code Escrow Agreement with the City and a third party escrow agent in a form satisfactory to the City and containing terms and conditions substantially the same as those set out in Appendix G – Escrow Provisions.

(13) In each case, so as to minimize interruption to the City's ongoing business processes, with time being of the essence, and to be done at the Proponent's sole expense, the Proponent must represent and warrant that any restoration, repair or replacement made pursuant to Articles 3.4.12 (9) a) or b) will not corrupt any data of the City or introduce any viruses into any of the City's systems.

(14) This warranty shall survive cancellation or other termination of the Agreement resulting from the City's acceptance of the deliverables.

(15) At the end of the Warranty Period, the City at its sole discretion may renew the support and maintenance services for four (4) additional one (1) year periods. The City shall authorize such renewal by issuing a Purchase Order or Contract release order to the Vendor.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) ARTICLE 4.0 PROPOSAL EVALUATION & SELECTION PROCESS


4.0 PROPOSAL EVALUATION AND SELECTION PROCESS 4.1 Selection Committee (1) All Proposals will be evaluated through a comprehensive review and analysis by a Selection

Committee, which will include members from Parks Forestry & Recreation, Emergency Medical Services, Pension, Payroll and Employee Benefits, Information & Technology and other relevant City staff and stakeholders.

(2) The Selection Committee may, at its sole discretion, retain additional committee members or advisors.

(3) The aim of the Selection Committee will be to select one (1) Proposal which in its opinion meets the City's requirements under this RFP and provides the best overall value to the City, but the Proposal selected, if any, will not necessarily be the one offering the lowest fees or cost (pricing). Pricing is only one of the components that will be used to determine the best overall value for the City.

(4) By responding to this RFP, Proponents will be deemed to have agreed that the decision of the Selection Committee will be final and binding.

4.2 Selection Criteria 4.2.1 Stage 1 – Initial Evaluation: Mandatory Requirements (1) A high-level view of the overall evaluation scheme that will be used to determine the Preferred

Proponent can be found in Appendix E – Proposal Evaluation Table.

(2) Proposals will be reviewed to assess compliance with the Mandatory Requirements. Proposals failing to comply with all of the Mandatory Requirements will be rejected. Proponents must:

a. Submit their Proposal in accordance with Article 5.2 including the mandatory forms

(Appendix C – Standard Submission Forms); b. Provide acknowledgement that they have the right to represent, sell, license, deliver,

install, train in the use of, service, maintain and support the Solution and provide the City with any ownership rights as detailed in Requirement 1.1.1 in Appendix F.1;

VIEW

ING C

OPY

DO NOT S

UBMIT




c. Provide acknowledgement that they have read, understood and comply with the requirements of the RFP including Appendix A – RFP Terms and Conditions and Appendix B – Agreement Terms and Conditions, as detailed in Requirement 1.1.2 in Appendix F.1;

d. Agree to provide audited financial statements for the past two (2) years for public companies, or a letter from a financial institution confirming the Proponent’s financial viability and solvency as a going concern for private companies as described in Requirement 1.1.3 in Appendix F.1; and

e. Provide pricing as detailed in Section 7 of Article 5.3.

4.2.2 Stage 2A – Detailed Evaluation (1) The City will commence the Stage 2 evaluation process for all Proponents that achieve a score

of “PASS” for all elements of Stage 1 – Initial Evaluation: Mandatory Requirements (Pass/Fail).

(2) Stage 2A – Detailed Evaluation shall be based on multiple criteria, including:

a. Proposed approach and Solution – demonstration of a clear understanding of the Scope of Work and presentation of a logical methodology for achieving the Deliverables defined therein;

b. Demonstration of relevant experience, qualifications and success in comparable assignments as per Article 5.3 Sections 2 and 3 and Appendix F.4;

c. Calibre of specific professional services team proposed for this assignment – specific implementation, training and technical skills and relevant work experience on projects of similar size and scope as per Article 5.3 Section 4 and Appendix F.4; and

d. Demonstrating that the proposed Solution meets the Functional and Technical and Requirements of the City as per Article 5.3 Section 5 and Schedules F.1, F.2 and F.3.

(3) Proponents must meet a minimum threshold of sixty-five percent (65%) against the Functional,

Technical and Non-Functional Requirements, in order to advance to Stage 2B – Presentation and Demonstrations.

(4) Additionally, Proponents must meet a minimum threshold of seventy percent (75%), or 750 out of 1,000 against the entire Stage 2A – Detailed Evaluation in order to advance to Stage 2B – Presentation and Demonstrations.

(5) In the event that fewer than two (2) of the Proposals achieve the required minimum overall score of seventy percent (75%), during Stage 2A, the City, at its sole discretion, may create a short-list comprised of up to three (3) high-scoring Proponents that met the minimum threshold described in Article 4.2.2 (3).

4.2.3 Stage 2B – Interviews, Product Live Demonstration and Presentation (1) The City may create a short-list comprised of Proponents that met the minimum scoring

thresholds from Stage 2A – Detailed Evaluation, in accordance with the process and methodology described in Articles 4.2.2 (3), (4) and (5). The short-listed Proponents will then participate in Stage 2B – Presentation and Demonstrations, which consists of Scripted Demonstration, a presentation and a “Hands-on” Demonstration.

(2) The City will provide the short-listed Proponents a set of pre-defined scripts for the activities that comprise Stage 2B – Presentation and Demonstrations. The Stage 2B evaluation will then commence approximately one (1) week later.

(3) The demonstration can be conducted on the Proponent's own devices as long as the Proponent can confirm that the application will work on the City’s server/network if successful.

VIEW

ING C

OPY

DO NOT S

UBMIT




(4) Any specific Proponent representatives designated by the Selection Committee in its invitation to the Proponent should where at all possible attend any presentations and demonstrations scheduled as part of this evaluation process.

(5) The representatives of a Proponent at any presentations or demonstrations are expected to be thoroughly versed and knowledgeable with respect to the requirements of this RFP and the contents of its Proposal, and must have the authority to make decisions and commitments with respect to matters discussed during presentation and/or demonstrations, which may be included in any resulting Agreement.

(6) Where the staff team proposed by the Proponent is an important element in the selection criteria, the staff team proposed should be present for the interviews/demonstration and presentation.

(7) No Proponent will be entitled to be present during, or otherwise receive, any information regarding any presentations and/or demonstrations with any other Proponent(s).

(8) The City will be under no obligation to advise those Proponents not receiving an invitation to participate in Stage 2B – Presentation and Demonstrations until completion of the evaluation and selection process.

(9) Proponents will be expected to provide a location which should be within the boundaries of the City of Toronto for the purposes of conducting the demonstrations and presentation that comprise Stage 2B – Presentation and Demonstrations. Procurement and/or provision of all facilities, equipment, materials, infrastructure or any other type of resource required for the Proponent to participate in Stage 2B – Presentation and Demonstrations will be the sole responsibility of the Proponent.

(10) Short-listed Proponents should prepare a short presentation to be delivered if possible by the proposed team leads. Individuals will be expected to answer questions after the presentation. At the end of the presentation, Proponents will provide a soft copy of the presentation (Microsoft PowerPoint or Adobe Portable Document Format) to the City.

(11) Proponents will be expected to demonstrate “Out-of-the-Box” functionality during the Scripted Demonstration. Areas where additional components, Customization, Configuration or third-party components will be required should be covered by the Proponent, and Proponents will be expected to explain the level of effort and/or amount of time and/or cost that would be required to perform such necessary Customization(s) and/or Configuration(s), and/or acquire such necessary additional or third party components.

(12) Proponents should, at a minimum, be prepared to demonstrate the:

a. Asset data model of the proposed Solution; b. Building Condition Assessment functionality of the proposed Solution; c. Capital planning and forecasting functionality of the proposed Solution; and d. Reporting functionality of the proposed Solution; and e. Integration of the proposed Solution with CAPTOR.

(13) The above list is not exhaustive, but rather illustrative, to give Proponents an example of what

the City expects to see during the Scripted Demonstration phase. The Scripted Demonstration will be akin to a “canned demo,” whereby the Proponent demonstrates for the Selection Committee how certain functions are performed.

(14) The “Hands-on” Demonstration, will, for all intents and purposes, be a “mini training session,” where individuals from the Selection Committee will attempt to perform basic functions with the Solution.

VIEW

ING C

OPY

DO NOT S

UBMIT




A script of what types of activities will be included in the “Hands-on” Demonstration will be provided to Proponents along with all other materials distributed to Proponents in preparation for Stage 2B – Presentation and Demonstrations. Proponents will be expected to review the script for the “Hands-on” Demonstration and prepare to “coach” or “train” the participating members of the Selection Committee on how to navigate the Solution and perform the required functions. Selection Committee members will be looking for ease of use, look, feel and flexibility when using the Solution during the “Hands-on” Demonstration. Proponents will be scored based on: how intuitive and easy to use user interface is (are the screens and dialog boxes clearly laid out? Are the menus and toolbars easy to understand and navigate?), the number of mouse-clicks required, ease of navigation, ease of accessing the data required to fulfil the given function, and the quality of the graphs/reports.

(15) The Presentation and Scripted Demonstration will be used by the Selection Committee as a mechanism for confirming the scores achieved by Proponents during Stage 2A – Detailed Evaluation, while the “Hands-on” Demonstration will be individually scored, as detailed in Appendix E – Proposal Evaluation Table.

(16) Detailed reference checks will be conducted at this stage for the purpose of verifying information set out in Proposals or claims made in presentations and/or demonstrations.

4.2.4 Stage 3 – Cost

(1) Scores for the cost criterion will be calculated as follows:

(a) The lowest cost Proposal receives 20 points; and

(b) The remaining Proposals are assigned points based on the following formula:

20 Pr 'Pr

Cost Proposal Priced Costoposalsoponent

Lowest

(2) The foregoing formula will be used for the purpose of selecting a Preferred Proponent in whole or

part, at the discretion of the City and with whom the City may enter into negotiations.

4.3 Selection Process (1) The Selection Committee will score the Proposals using the evaluation scheme outlined in

Appendix E – Proposal Evaluation Table.

(2) If a Proposal fails to comply with any of the Mandatory Requirements, the Proposal will be rejected.

(3) The Proposal that achieves the highest total aggregate score for Stage 2A – Detailed Evaluation (Article 4.2.2), Stage 2B – Presentation and Demonstrations (Article 4.2.3) and Stage 3 – Cost (Article 4.2.4) will be considered for recommendation as a Preferred Proponent. In the event of a tie total score, the Proponent achieving the highest score during Stages 2A and 2B (i.e. with the Cost portion removed) will be considered for recommendation as the Preferred Proponent.

VIEW

ING C

OPY

DO NOT S

UBMIT




4.4 Schedule of Events (1) The timeline of key events is scheduled as follows:

EVENT DATE & TIME

RFP issue date: August 14, 2012 Proponents Meeting (Question and Answer session) August 20, 2012 – 1:00pm Deadline for written questions: August 31, 2012 – 4:00pm Release of final addendum (if any): September 4, 2012 Closing date: September 10, 2012 – 12:00pm Evaluation expected to be completed: October 15, 2012 Selection of Preferred Proponent: November 1, 2012

(2) This schedule is subject to change by the City and appropriate notice in writing of any changes

will be provided where feasible.

4.5 Clarifications (1) As part of the evaluation process, the Selection Committee may make requests for further

information with respect to the content of any Proposal in order to clarify the understanding of the Proponent’s response. The clarification process shall not be used to obtain required information that was not submitted at time of close or to promote the Proponent’s company.

(2) The Selection Committee may request this further information from one (1) or more Proponents and not from others.

4.6 Evaluation Results (1) Upon conclusion of the evaluation process, a final recommendation will be made by the

Selection Committee to the appropriate City staff member and/or City Council.

(2) Proposal evaluation results shall be the property of the City and are subject to MFIPPA. Evaluation results may be subject to public release pursuant to MFIPPA.

(3) Proponents should be aware that Council and individual Councillors have the right to view the responses provided that their requests have been made in accordance with the City’s standard policies and procedures.

4.7 Negotiations and Agreement (1) The execution of any Agreement will be at the absolute discretion of the City. The selection of

a recommended Proponent will not oblige the City to negotiate or execute an Agreement with that recommended Proponent.

(2) Any award of an Agreement resulting from this RFP will be in accordance with the by-laws, policies and procedures of the City.

(3) The City shall have the right to negotiate on such matters as it chooses with the Preferred Proponent without obligation to communicate, negotiate, or review similar modifications with other Proponents. The City shall incur no liability to any other Proponent as a result of such negotiation or alternative arrangements.

VIEW

ING C

OPY

DO NOT S

UBMIT




(4) During negotiations:

(a) The scope of the services may be refined;

(b) Issues may be prioritized;

(c) Responsibilities among the Proponent (including all staff and sub-consultants provided by the Proponent) and the City, may be settled; and

(d) Any issues concerning implementation may be clarified.

(5) Any Agreement must contain terms and conditions in the interests of the City and be in a form satisfactory to the City Solicitor. If the Agreement requires City Council approval, then the final Agreement must contain terms and conditions substantially as set out in the Council report authorizing the Agreement. Any Agreement will incorporate as schedules or appendices such part of the RFP (including addenda) and the Proposal submitted in response thereto as are relevant to the provision of the goods and/or services.

(6) The terms and conditions set out in Appendix B – Agreement Terms and Conditions shall be

incorporated in any Agreement entered into with the recommended Proponent. These terms and conditions are mandatory and are not negotiable. Note however, that any Proponent wishing to request that the City consider any changes to the mandatory terms and conditions set out in Appendix "B" or to any requirements must follow the process outlined in section 5 of Appendix "A".

(7) The Agreement shall contain an Approval Process for Deliverables substantially as follows:

(a) The Vendor will send a Deliverable Acceptance Request Form to the City Project

Manager for each Deliverable or group of Deliverables. Unless otherwise provided in the Agreement, the City shall provide either its Acceptance by release of a Notice of Acceptance of applicable Deliverable(s) or rejection within ten (10) Business Days of the date of receipt of a Deliverable or a group of Deliverables, unless expressly provided otherwise in the Project Plan approved by both parties acting reasonably. The City will use reasonable efforts to provide its Acceptance or rejection within a shorter timeframe.

(b) The Vendor shall submit any Deliverable required under the Agreement in sufficient time

to allow for the complete review and acceptance of the Deliverable by the City and appropriately schedule the Deliverable to allow for any revisions or corrections that may be necessary before acceptance by the Project Manager. Whenever an accelerated time for Acceptance is required to avoid impacting the Project Plan, the Vendor will ensure that the City has sufficient advance notice to allow for such acceleration, whereupon the Project Managers may agree on a shorter time for Acceptance.

(c) If the City notifies the Vendor of any errors or deficiencies in any Deliverable prior to the date by which the City is to provide Notice of Acceptance of any Deliverable hereunder, the Vendor will promptly correct such errors and deficiencies, and the City will have five (5) Business Days after the delivery of the corrected version of the Deliverable or such other period as is agreed to by the Parties to provide Notice of Acceptance of such Deliverables to the Vendor;

(d) The delivery by the City of a Notice of Acceptance with respect to any Deliverable or group of Deliverables will not affect the right of the City to require the Vendor to remedy any errors or deficiencies in any Deliverable that are discovered by the City at any time following delivery of the Notice of Acceptance.

(e) Under no circumstances shall any Deliverable be "deemed" to be accepted.

VIEW

ING C

OPY

DO NOT S

UBMIT




(8) If any Agreement cannot be negotiated within sixty (60) business days of notification to the

Preferred Proponent, the City may, at its sole discretion, terminate negotiations with that Proponent and negotiate an Agreement with another Proponent or abort the RFP process and not enter into any Agreement with any of the Proponents.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) ARTICLE 5.0 PROPOSAL SUBMISSION REQUIREMENTS


5.0 PROPOSAL SUBMISSION REQUIREMENTS 5.1 General Overview (1) The City has formulated the procedures set out in this RFP to ensure that it receives Proposals

through an open, competitive process, and that Proponents receive fair and equitable treatment in the solicitation, receipt and evaluation of their Proposals. The City may reject the Proposal of any Proponent who fails to comply with any such procedures.

(2) Proposals are expected to address the RFP content requirements as outlined herein, should be well ordered, detailed and comprehensive. Clarity of language, adherence to suggested structuring, and adequate Documentation is essential to the City’s ability to conduct a thorough evaluation. The City is interested in Proposals that demonstrate efficiency and value for money. General marketing and promotional material will not be reviewed or considered.

5.2 Proposal Documentation and Delivery (1) The Documentation for each Proposal:

(a) Must be submitted in a sealed envelope or container (submissions made by fax, telephone, electronic message or telegram will not be accepted) displaying a full and correct return address.

(b) Should be double-sided, minimum ten (10) point font, with unlimited appendices.

(c) Must consist of one (1) original (clearly marked as such on its first page) and six (6) full photocopies of:

(i) A Main Proposal Document as described below in Article 5.3, including all attachments and appendices as required (mandatory);

(ii) Form 1 (Proposal Submission Form) completed and signed by an authorized official of the Proponent (Appendix C – Standard Submission Forms) (mandatory);

(iii) Form 2 (Policy to Exclude Bids from External Parties involved in the Preparation or Development of a Specific Call/Request) completed as indicated (Appendix C – Standard Submission Forms) (mandatory);

(iv) Form 3 (Restrictions on the Hiring and use of Former City of Toronto Management Employees for City Contracts) completed as indicated (Appendix C – Standard Submission Forms) (if applicable);

(v) Form 4 (Environmentally Responsible Procurement Statement) completed as indicated (Appendix C – Standard Submission Forms) (if applicable);

(vi) Form 6 (City of Toronto Customer Service Training Requirements: Contractors, Consultants and other Service Providers (If Applicable);

(vii) Form 7 - Non-Discrimination Policy, and (viii) Requirements (Mandatory, Functional, Technical and Non-Functional)

Compliance Tables (Appendices F.1 to F.4) (mandatory).

(d) Should include one (1) electronic (soft copy) version of technical portion of the Proposal, as editable Microsoft Word 2003 and Excel 2003 files (unlocked and unprotected) and also with PDF files (locked and protected), on two (2) identical USB storage keys, CD-Rs or similar media marked or labelled with the Proponent's name.

VIEW

ING C

OPY

DO NOT S

UBMIT




The USB, CD-Rs or similar media should accompany the original printed version of the Proponent's response. In the event where there are deviations between the original hard copy, the additional hard copies, and the soft copy, the hard copy identified as the "original", shall prevail.

(e) Must be delivered no later than the Closing Deadline to:

Chief Purchasing Official Purchasing and Materials Management Division 18th Floor, West Tower, City Hall Toronto, ON, M5H 2N2

(f) Two-Envelope System

The documentation for the Cost of Services Submission:

i) Must be PACKAGED AND SEALED IN A SEPARATE ENVELOPE labelled Cost of Services (submissions made by fax, telephone, electronic message or telegram will not be accepted) displaying a full and correct return address;

ii) Must consist of One (1) original, clearly marked as such on its first page, and Two (2) copies of Appendix D (Price Detail Forms) completed as indicated.

No cost information shall be included in the body of the technical portion of the Proposal (in both hard or softcopies) or it will be rejected.

(2) Delays caused by any delivery service (including Canada Post and courier) shall not be

grounds for any extension of the Deadline, and Proposals that arrive after the Deadline will not be accepted.

5.3 Proposal Content The Proposal should contain the following items, in the same order as presented below: Letter of Introduction (1) Introducing the Proponent and signed by the person(s) authorized to sign on behalf of, and bind

the Proponent to, statements made in response to this RFP. This should contain the same signature(s) as those of the person(s) signing the submission forms.

Table of Contents (1) Include page numbers and identify all included materials in the Proposal submission. Section 1 – Executive Summary (1) Proponents should preface their submission with an Executive Summary that describes in plain

terms how their recommended Solution addresses the City's objectives as outlined in Article 3.1, how they plan to address and meet the Mandatory, Functional, Technical and Non-Functional Requirements referred to in Appendix F Requirements & Project Reference Material, and how they plan to meet the Deliverables as outlined in Article 3.4.

(2) The Proponents must also acknowledge that they have read, understood and comply with the

requirement of the RFP specifically as it relates to Appendix A – RFP Process Terms and Conditions and Appendix B – Legal Terms and Conditions.

(3) The Proponent must acknowledge compliance with the Mandatory Requirements by

completing the Mandatory Requirements tables located in:

VIEW

ING C

OPY

DO NOT S

UBMIT




(a) Appendix F.1 – Mandatory Requirements Compliance Tables

(b) Appendix F.2 – Functional Requirements Compliance Tables - General Functional Requirements (Mandatory)

(c) Appendix F.3 - Requirements Compliance Tables - General Requirements – Technical Requirements (Mandatory)

(d) Appendix F.4 – Non-Functional Requirements Compliance Tables - Proponent Project Team and References (Mandatory)

(e) Failure to indicate compliance with each and every Mandatory Requirement located in Appendix F.1, F.2, F.3 and F.4 will result in automatic rejection of the Proposal.

Section 2 – Proponent Profile (1) Proponents should have staff, organization, culture, financial resources, market share and an

installed base adequate to ensure their ongoing ability to deliver and support the proposed total Solution throughout its useful lifetime, including the ability to provide timely response and service to the City over the period of the Project and any Warranty Periods.

To permit the Proponent to be evaluated fully as a viable and sound enterprise, the City requests certain information with respect to the Proponent. The information Proponents are requested to provide is described in Requirement 7.1.1, located in Appendix F.4 – Non-Functional Requirements Compliance Tables. If the Proposal is being presented by a Proponent that is a member of a consortium, provide a description of the relationships between consortium members. Please note section 2 of Appendix A regarding consortiums and the requirement that there be a single Proponent.

Section 3 – Experience and Qualifications of the Proponent (1) It is important that the Project be undertaken by a Proponent who can demonstrate specific

knowledge of, and experience in performing similar work for projects of comparable nature, size and scope. In particular, the Proponent should demonstrate the following in its Proposal:

(a) Its experience in providing and implementing a similar Solution in a minimum of one (1)

of: (i) The public sector for a municipal/local government entity of size and complexity

comparable to the City; or (ii) The public sector for either a federal, provincial or state entity; or (iii) The private sector.

(b) The capacity of the Proponent to understand the Functional, Technical and Non-

Functional Requirements, as well as the goals and objectives of the Project as set out in this RFP;

(c) Its experience with other similar projects in the appropriate areas of responsibility as specified in this RFP document; and

(d) Its experience with respect to the overall discipline of project management. (2) Please note that where the skills/expertise/experience are being provided by a subcontractor or

other legal entity apart from the Proponent, the Proposal that does not include the information requested in this Section 3 for each such subcontractor or other entity will not be awarded full marks during the evaluation process. In providing references, Proponents agree that the City can contact the individuals provided as part of the evaluation process. The City will make its

VIEW

ING C

OPY

DO NOT S

UBMIT




own arrangements in contacting the references. Substitution of references will not be permitted after the close of the RFP.

(3) Proponents must be able to carry on business in the Province of Ontario and must be in

compliance with all requirements imposed by the laws of Ontario and the laws of Canada applicable in the Province for the performance of the agreement.

(4) There must be no actions, claims, suits or proceedings pending or, to the Proponent’s

knowledge, threatened against or adversely affecting the Proponent or any of its proposed subcontractors in any court or before or by any federal, provincial, municipal or other government department, commission, board, bureau or agency, Canadian or foreign, that might affect the Proponent’s, or its proposed subcontractor’s, financial condition or ability to perform and meet any and all duties, liabilities and obligations as may be required of the Proponent under any future agreement.

(5) There must be no construction or mechanics or other liens, encumbrance, third-party security

interest or other rights outstanding in regard to the Solution or any part thereof or installation, and software and any supplies provided therewith must pass to the City in accordance with the terms of the agreement free and clear of all such liens, encumbrances and third-party security interest or other rights.

(6) No staff person or representative of the City shall have any direct or indirect beneficial interest,

whether financial or otherwise, in the Vendor or any of its approved assignees or subcontractors or in their performance of the services.

(7) Financial viability of the Proponent will be a factor regarding the evaluation and in determining

the recommendation of the award, and as such, Proponents must agree to provide the following information in the Proponent’s Proposal: Audited financial statements for the past two (2) years for public companies, or a letter from a financial institution confirming the Proponent’s financial viability and solvency as a going concern for private companies.

(8) In providing references, Proponents agree that the City can contact the individuals provided as

part of the evaluation process. The City will make its own arrangements in contacting the references. Substitution of references will not be permitted after the close of the RFP. A Proponent may not use the City as a reference.

(9) The City will make its own arrangements in contacting the references. Proponents should

ensure that references have given their contact information of their own accord, and as such will be able to provide candid responses to the City’s Selection Committee members at the time of the reference checks.

(10) References will only be contacted by the City if the Proponent’s Proposal enters Stage 2B –

Presentation and Demonstrations of the evaluation process, as described in Article 4.2.3 and Appendix E – Proposal Evaluation Table, and then only after the City has communicated to the Proponent that it intends to contact the references.

(11) Proponents should use the responses to Requirement 7.1.2, located in Appendix F.4 – Non-

Functional Requirements Compliance Tables to form the basis of Section 3 – Experience and Qualifications of the Proponent.

Section 4 – Proposed Staff Team and Resources (1) It is important that the work be undertaken by the Vendor’s team member(s) who can

demonstrate specific knowledge of, and experience in, performing similar work for projects of comparable nature, size and scope to the Scope of Work described in Article 3.0.

VIEW

ING C

OPY

DO NOT S

UBMIT




Refer to requirements 7.1.3 and 7.1.4, located in Appendix F.4 – Non-Functional Requirements Compliance Tables for details regarding what information Proponents are requested to provide in this Section.

(2) The Proponent should submit signed consent forms authorizing the disclosure of personal

information to the City, or its designated agent(s), for any résumés that are submitted. The Proponent will accept all liability if consent forms are not provided or submitted prior to the disclosure of any personal information to the City.

(3) Key Vendor staff members (i.e. those with major areas of responsibility) must be named, with

accompanying indication of guaranteed availability for the Project. Continuity of key Vendor staff will be required, with a contractual obligation for substitutions only with full written approval of the City. At a minimum, the City requires that the proposed Account Manager and the Project Manager be designated as key staff members.

Section 5 – Proposed Solution (1) In order to determine the extent to which the proposed Solution meets the City’s Mandatory,

Functional, Technical and Non-Functional Requirements and confirms the Proponent’s understanding, the following should be provided in the Proposal:

(a) Proponents should provide a detailed explanation of the reasons why they are

recommending the Proposed Solution; (b) Proponents should submit the Functional and Technical Requirements Compliance

Tables in Schedules F.2 and, F.3, which contain the City’s Functional and Technical Requirements for the Asset Management System ;

(c) Proponents are encouraged to provide additional comment in the column provided in each of the Compliance Tables in order to identify how their Solution addresses a given requirement, including any other relevant information pertaining to their response to a given requirement;

(d) Proponents should provide any additional detailed functions/characteristics/ specifications of their proposed Solution that they believe would be beneficial to the City in the long run; and

(e) Proponents should provide a summary of risks/problems/issues that may be encountered based on prior installations and how they can be mitigated.

Section 6 – Workplan and Deliverables (1) Work Plan General

(a) It is important that the Project is started and completed in an efficient and effective manner. The Proponent is requested to provide:

(i) A detailed work plan indicating the project method, schedule, Gantt chart, tasks,

and Deliverables; (ii) Sub-plans for other activities such as deployment, integration, training, Knowledge

Transfer, data migration and testing; (iii) An estimated overall timeline of the Project, including an indication of when

Proponent could commence work; (iv) Key dates for major Deliverables that should be clearly defined in the Proponent's

detailed work plan. (v) Sufficient detail for the Selection Committee to evaluate the value of the effort

expended.

(b) State assumptions regarding roles and involvement of the City and the estimated amount of their time involvement.

VIEW

ING C

OPY

DO NOT S

UBMIT




(2) Project Management Plan and Procedures

(a) The Proponent should include in its Proposal a detailed description of your proposed plan, policies, and procedures for managing this Project. Specifically, describe processes for communications with City management and Project staff, escalation procedures for issues, and problem resolution. Discuss all planned recurring meetings, management reports and other contract oversight processes.

(3) Deliverables

(a) The Proponent should include in its Proposal a description of how it proposes to

complete the Deliverables described in the following sections:

3.4.1 Phase 1 Project Initiation; 3.4.2 Phase 2 Requirements Validation; 3.4.3 Phase 3 Prepare Design Documentation; 3.4.4 Phase 4 Build/Implement Solution; 3.4.5 Phase 5 Monitored Deployment; and 3.4.6 Phase 6 Final Acceptance.

Section 7 – Cost of Services (Total Proposed Price) The Proponent must complete and submit the Price Detail Forms as described in Appendix D – Supplementary Submission Forms. To be submitted in the Cost of Services envelope as per section 5.2 (1) (f) above. Below is a list of the Price Detail Forms to be used by Proponents: 1. Appendix D1a, D1b, D1c and D1d Price Detail Forms for AMS Functionality, Annual Maintenance &

Support Services for End Users, Power Users, Administrators and Servers. 2. Appendix D2a Price Detail Form for List and Cost of AMS Customizations, D2b Detail Form for List

of AMS Configurations. 3. Appendix D3 Price Detail Form for AMS Professional Services Costs. 4. Appendix D4 Price Detail Form for List and Cost of AMS Reference Hardware. 5. Appendix D5 Price Detail Form for Optional On-Site Technical Support. These forms are for informational purposes only. Two Price Detail Forms are calculated and derived from the above Appendices. Proponents are not to modify or enter any information into these two forms. These are: 1. Appendix D6 - Proponent Total Cost which presents Price Details and the Total Cost of

Proponent's AMS. The Total Cost calculated on this appendix should equal the Total Proposal Cost.

2. Appendix D7 - Evaluation of Proponent Costs which presents Price Details and calculates the Proponent's AMS Costs for Evaluation Purposes based on two (2) Scenarios across five (5) years. These Costs will be used in the Cost Evaluation Stage described in the RFP.

(1) Pricing

(a) When submitting prices, all prices quoted must include all labour, profit, other overhead,

materials, equipment, licences, analysis, travel, accommodations, communication, transportation and delivery costs (courier, long distance charges, and so on), staff time, City/Vendor meetings (as and where deemed required by the City), disbursements and any/all other operational costs and fees associated with the Services. The City shall not be responsible for any additional costs.

VIEW

ING C

OPY

DO NOT S

UBMIT




(b) The City prefers that the assumptions used by a Proponent in preparing its Proposal are kept at a minimum and to the extent possible, that Proponents will ask for clarification prior to the Deadline for Proponent Questions rather than make assumptions. Where a Proponent's assumptions are inconsistent with information provided in or required by the RFP or are so extensive that the Total Proposal Price is qualified, such Proponent risks disqualification by the City in the City's sole discretion.

(c) Harmonized Sale Tax (HST) must be applied to the prices submitted where specified in the relevant sections of the call document or in the Price Schedule provided in the call.

(d) Payments will be made to the Vendor on the basis of the Total Price and payment milestones as identified and agreed to in the Agreement.

(e) Depending on the nature and extent of the Solution proposed, the City reserves the right to purchase Solution components over time, if necessary, due to potential budgetary pressures the City may face.

(f) All parts and items on the Price Detail Forms must be priced for the entirety of Services to be provided. If insufficient information is provided to permit the Selection Committee to evaluate the Proposal, the Selection Committee, in its sole discretion may deem the Proposal as non-compliant and invalid. If any part or item on the Price Detail Forms is not priced and is required for the Proponent's Solution, the price for such part or item shall be deemed to be zero dollars ($0).

(g) In the event of mathematical errors found in the pricing pages, the unit prices quoted shall prevail. Extensions and totals will be corrected accordingly by City staff and adjustments resulting from the correction will be applied to the Total Proposed Price quoted.

(h) Prices submitted in a Proposal shall be firm for the duration of the RFP process, including the successful negotiation of an Agreement and the term of any resulting Agreement.

(i) All prices should be stated in Canadian currency. In the event that prices are quoted in US dollars, the total fixed flat rate (lump sum) will be converted on the day of the opening to Canadian dollars for purposes of evaluation. Any subsequent award will be based on that conversion rate. Vendors quoting prices in US dollars will assume all currency risk.

(j) The City shall not be responsible for any additional costs, except those formally approved by Change Orders or amendments to the Agreement in accordance with the Agreement.

(k) The Proponent must be solely responsible for any and all payments and/or deductions required to be made including but not limited to those required for the Canada Pension Plan, Employment Insurance, Workplace Safety and Insurance, and Income Tax.

(l) The Proponent shall be solely responsible for all costs including but not limited to wages, salaries, statutory deductions and any other expenses and liabilities related to its own personnel, sub-contractors, suppliers and their respective personnel.

(m) All invoices must clearly Ontario Harmonized Sales Tax (HST), and must also include the Proponent’s GST Registration Number.

(n) Without restricting the generality of the foregoing, the Proponent acknowledges that, if it is a non-resident person, payments to the Proponent, as a non-resident person, may be subject to withholding taxes under the Income Tax Act (Canada). Further, unless the Proponent, as a non-resident person, provides the City with an official letter from Canadian Customs and Revenue Agency waiving the withholding requirements, the City will withhold the taxes it determines are required under the Income Tax Act (Canada).

(2) Optional and/or Additional Pricing

(a) Proponents must clearly indicate in their Proposals and on the Price Detail Forms

specific Services and products which are additional or optional and which are excluded from the Total Proposal Price for Services.

(b) Proponents must include an hourly fee schedule for all levels of the Proponent’s professional, managerial and clerical staff with respect to services not included in the Services (e.g. Customization services) and rates for disbursements.

VIEW

ING C

OPY

DO NOT S

UBMIT




(c) A detailed cost summary of exclusions along with justification for the need must be provided.

(3) Payment Terms and Discount Schedule

(a) Proponents should propose payment terms. The City’s standard payment terms are sixty (60) days from the receipt of the invoice. The final payment terms may be subject to further negotiation.

(b) Proponents should also propose any prompt payment discount terms. Note: Discount for prompt payment cannot be earlier than fifteen (15) days from the receipt of

invoice by the City of Toronto, Accounting Services Division. (4) Invoicing and Reporting Specification Requirements

(a) Proponents should include a description of the accounting practices to be used in billing the City for Services rendered, indicating any volume discounts or alternate pricing. The description should refer to payment milestones based on Deliverables, and effective cost-containment strategies should also be included.

(b) When submitting an invoice to the City, the relevant approved Deliverables/milestones being billed should be detailed on the invoice and any separate Documentation evidencing approval by the City of such Deliverables should be included with the invoice.

(c) The City Project Manager’s name and work locations should be included on each invoice.

(d) The purchase order or blanket contract number issued to the Vendor in relation to this Project should also be referenced on each invoice.

(e) Proponents should provide details as to how they can meet the requirements of this section.

Section 8 – Cost Control (1) Section intentionally left blank.

VIEW

ING C

OPY

DO NOT S

UBMIT

REQUEST FOR PROPOSALS: ASSET MANAGEMENT SOLUTION (AMS) APPENDIX A


APPENDIX A RFP PROCESS TERMS AND CONDITIONS A.1. Proponent’s Responsibility A.2. Prime Proponent A.3. Questions A.4. Addenda A.5. Exceptions A.6. Omissions, Discrepancies and Interpretations A.7. Incurred Costs A.8. Post-Submission Adjustments and Withdrawal of Proposals A.9. No Collusion A.10. Prohibition against Gratuities A.11. Acceptance of Proposals A.12. Verification A.13. Conflicts of Interest A.14. Ownership and Confidentiality of City-Provided Data A.15. Ownership and Disclosure of Proposal Documentation A.16. Intellectual Property Rights A.17. Failure or Default of Proponent A.18. Publicity A.19. Governing Law

VIEW

ING C

OPY

DO NOT S

UBMIT



A.1 Proponent’s Responsibility

(1) It shall be the responsibility of each Proponent:

a) To examine all the components of this RFP, including all appendices, forms and addenda; and

b) To acquire a clear and comprehensive knowledge of the required services before

submitting a Proposal.

c) To become familiar, and (if it becomes a successful Proponent) comply, with all of the City’s Policies and Legislation set out on the City of Toronto website at www.toronto.ca/tenders/index.htm

(2) The failure of any Proponent to receive or examine any document, form, addendum,

Agreement or policy shall not relieve the Proponent of any obligation with respect to its Proposal or any Agreement entered into or Purchase Order issued based on the Proponent’s Proposal.

A.2 Prime Proponent

(1) A Proposal by a consortium of two or more legal entities having no formal corporate links may be submitted, but only one entity must be shown as the Proponent and be prepared to repre-sent the consortium to the City by executing the Agreement, acting as the primary contact, providing the required Letter of Credit and taking overall responsibility for performance of the Agreement

(2) Where a Proposal is made by a prime Proponent with associate firms working with or under

the prime Proponent in either a sub-contracting or consortium relationship, it is required that those associate firms be named in the Proposal.

A.3 Questions

(1) All questions concerning this RFP should be directed in writing to the City employee(s) designated as “City Contacts” in the Notice to Potential Proponents.

(2) No City representative, whether an official, agent or employee, other than those identified

“City Contacts” are authorized to speak for the City with respect to this RFP, and any Proponent who uses any information, clarification or interpretation from any other representative does so entirely at the Proponent’s own risk.

(3) Not only shall the City not be bound by any representation made by an unauthorized person,

but any attempt by a Proponent to bypass the RFP process may be grounds for rejection of its Proposal.

A.4 Addenda

(1) If it becomes necessary to revise any part of this RFP, the revisions will be by Addendum posted electronically in Adobe PDF format on the City’s website at www.toronto.ca/calldocuments. Proponents and prospective Proponents SHOULD MONITOR THAT SITE as frequently as they deem appropriate until the day of the Deadline. Only answers to issues of substance will be posted. The City reserves the right to revise this RFP up to the Closing Deadline. When an Addendum is issued the date for submitting Proposals may be revised by the City if, in its opinion, determines more time is necessary to enable Proponents to revise their Proposals

VIEW

ING C

OPY

DO NOT S

UBMIT



(2) All Proponents must acknowledge receipt of all Addenda in the space provided on the Proposal Submission Form.

(3) The City’s Purchasing and Materials Management Division will make reasonable efforts to

issue the final Addendum (if any) no later than two (2) days prior to the Deadline. A.5 Exceptions to Mandatory Terms, Conditions or Requirements

(1) If a Proponent wishes to suggest a change to any mandatory term, condition or requirement set forth in any part of this RFP, it must notify the City in writing not later than three (3) days before the Deadline. The Proponent must clearly identify any such term condition or, requirement, the proposed change and the reason for it. If the City wishes to accept the proposed change, the City will issue an Addendum as described in the article above titled Addenda. The decision of the City shall be final and binding, from which there is no appeal. Changes to mandatory terms and conditions that have not been accepted by the City by the issuance of an Addendum are not permitted and any Proposal that takes exception to or does not comply with the mandatory terms and conditions of this RFP will be rejected.

A.6 Omissions, Discrepancies and Interpretations

(1) A Proponent who finds omissions, discrepancies, ambiguities or conflicts in any of the RFP Documentation or who is in doubt as to the meaning of any part of the RFP should notify the City in writing not later than three (3) days before the Deadline. If the City considers that a correction, explanation or interpretation is necessary or desirable, the City will issue an Addendum as described in the article above titled Addenda. The decision and interpretation of the City shall be final and binding, from which there is no appeal. No oral explanation or interpretation shall modify any of the requirements or provisions of the RFP documents.

A.7 Incurred Costs

(1) The City will not be liable for, nor reimburse, any potential Proponent or Proponent, as the case may be, for costs incurred in the preparation, submission or presentation of any Proposal, for interviews or any other activity that may be requested as part of the evaluation process or the process for the negotiation or execution of an Agreement with the City, as the case may be.

(2) The rejection or non-acceptance of any or all Proposals shall not render the City liable for any

costs or damages to any firm that submits a Proposal. A.8 Post-Submission Adjustments and Withdrawal of Proposals

(1) No unilateral adjustments by Proponents to submitted Proposals will be permitted. (2) A Proponent may withdraw its Proposal prior to the Deadline any time by notifying the City

Buyer designated in this RFP in writing. (3) A Proponent who has withdrawn a Proposal may submit a new Proposal, but only in

accordance with the terms of this RFP. (4) After the Deadline each submitted Proposal shall be irrevocable and binding on Proponents

for a period of one hundred and twenty (120) days. (5) If the City makes a request to a Proponent for clarification of its Proposal, the Proponent will

provide a written response accordingly; this shall then form part of the Proposal.

VIEW

ING C

OPY

DO NOT S

UBMIT



A.9 No Collusion

(1) No Proponent may discuss or communicate about, directly or indirectly, the preparation or content of its Proposal with any other Proponent or the agent or representative of any other Proponent or prospective Proponent. If the City discovers there has been a breach at any time, the City reserves the right to disqualify the Proposal or terminate any ensuing Agreement.

A.10 Prohibition against Gratuities

(1) No Proponent and no employee, agent or representative of the Proponent, may offer or give any gratuity in the form of entertainment, participation in social events, gifts or otherwise to any officer, director, agent, appointee or employee of the City in connection with or arising from this RFP, whether for the purpose of securing an Agreement or seeking favourable treatment in respect to the award or amendment of the Agreement or influencing the performance of the Agreement, including without restriction enforcement of performance standards, or expressing appreciation, or providing compensation, for the award of an Agreement or for performance of the City's obligations there under or for conferring favours or being lenient, or in any other manner whatsoever.

(2) If the City determines that this article has been breached by or with respect to a Proponent,

the City may exclude its Proposal from consideration, or if an Agreement has already been entered into, may terminate it without incurring any liability.

A.11 Acceptance of Proposals

(1) The City shall not be obliged to accept any Proposal in response to this RFP. (2) The City may, without incurring any liability or cost to any Proponent:

a) Accept or reject any or all Proposal(s) at any time; b) Waive immaterial defects and minor irregularities in any Proposals; c) Modify and/or cancel this RFP prior to accepting any Proposal; and d) Award a contract in whole or in part.

(3) The City is relying on the experience and expertise of the Proponent. The City reserves the

right to disqualify any Proponent who has given inaccurate, incomplete, false or misleading information in the sole opinion of the City.

A.12 Verification

(1) The City reserves the right to verify with any Proponent or with any other person any information provided in its Proposal but shall be under no obligation to receive further information.

(2) If, in the opinion of the City, any Proponent has clearly misinterpreted the services or

underestimated the hours or value of the services to be performed as reflected in its Proposal content and submitted price/fees, or all or any or any combination of them, then the City may reject its Proposal as unbalanced (i.e., not representative of the scope of the services).

VIEW

ING C

OPY

DO NOT S

UBMIT



A.13 Conflicts of Interest

(1) In its Proposal, the Proponent must disclose to the City any potential conflict of interest that might compromise the performance of the Work. If such a conflict of interest does exist, the City may, at its discretion, refuse to consider the Proposal.

(2) The Proponent must also disclose whether it is aware of any City employee, Council member

or member of a City agency, board or commission or employee thereof having a financial interest in the Proponent and the nature of that interest. If such an interest exists or arises during the evaluation process or the negotiation of the Agreement, the City may, at its discretion, refuse to consider the Proposal or withhold the awarding of any Agreement to the Proponent until the matter is resolved to the City’s sole satisfaction.

(3) If, during the Proposal evaluation process or the negotiation of the Agreement, the Proponent

is retained by another client giving rise to a potential conflict of interest, then the Proponent will so inform the City. If the City requests, then the Proponent will refuse the new assignment or will take such steps as are necessary to remove the conflict of interest concerned.

(4) Proponents are cautioned that the acceptance of their Proposal may preclude them from

participating as a Proponent in subsequent projects where a conflict of interest may arise. The successful Proponent for this project may participate in subsequent/other City projects provided the successful Proponent has satisfied pre-qualification requirements of the City, if any, and in the opinion of the City, no conflict of interest would adversely affect the performance and successful completion of an Agreement by the successful Proponent.

A.14 Ownership and Confidentiality of City-Provided Data

(1) All correspondence, Documentation and information provided by City staff to any Proponent or prospective Proponent in connection with, or arising out of this RFP, the Services or the acceptance of any Proposal:

a) Is and shall remain the property of the City; b) Must be treated by Proponents and prospective Proponents as confidential; and c) Must not be used for any purpose other than for replying to this RFP, and for fulfillment

of any related subsequent Agreement. A.15 Ownership and Disclosure of Proposal Documentation

(1) The Documentation comprising any Proposal submitted in response to this RFP, along with all correspondence, Documentation and information provided to the City by any Proponent in connection with, or arising out of this RFP, once received by the City:

a) Shall become the property of the City and may be appended to the Agreement and/or

Purchase Order with the successful Proponent; and b) Shall become subject to the Municipal Freedom of Information and Protection of

Privacy Act ("MFIPPA"), and may be released, pursuant to that Act.

(2) Because of MFIPPA, prospective Proponents are advised to identify in their Proposal material any scientific, technical, commercial, proprietary or similar confidential information, the disclosure of which could cause them injury.

VIEW

ING C

OPY

DO NOT S

UBMIT



(3) Each Proponent’s name at a minimum shall be made public. Proposals will be made available to members of City Council on a confidential basis and may be released to members of the public pursuant to MFIPPA.

A.16 Intellectual Property Rights

(1) Each Proponent warrants that the information contained in its Proposal does not infringe any intellectual property right of any third party and agrees to indemnify and save harmless the City, its staff and its consultants, if any, against all claims, actions, suits and proceedings, including all costs incurred by the City brought by any person in respect of the infringement or alleged infringement of any patent, copyright, trademark, or other intellectual property right in connection with their Proposal.

A.17 Failure or Default of Proponent

(1) If the Proponent, for any reason, fails or defaults in respect of any matter or thing which is an obligation of the Proponent under the terms of the RFP, the City may disqualify the Proponent from the RFP and/or from competing for future tenders or RFP issued by the City for a period of one year. In addition, the City may at its option either:

a) Consider that the Proponent has withdrawn any offer made, or abandoned the

Agreement if the offer has been accepted, whereupon the acceptance, if any, of the City shall be null and void; or

b) Require the Proponent to pay the City the difference between its Proposal and any

other Proposal which the City accepts, if the latter is for a greater amount and, in addition, to pay the City any cost which the City may incur by reason of the Proponent’s failure or default, and further the Proponent will indemnify and save harmless the City, its officers, employees and agents from all loss, damage, liability, cost, charge and expense whatever which it, they or any of them may suffer, incur or be put to by reason of such default or failure of the Proponent.

A.18 Publicity

(1) The Proponent and its affiliates, associates, third-party service providers, and subcontractors shall not release for publication any information in connection with this RFP or any Agreement without prior written permission of the City.

A.19 Governing Law

(1) This RFP and any Proposal submitted in response to it and the process contemplated by this RFP including any ensuing Agreement shall be governed by the laws of the Province of Ontario. Any dispute arising out of this RFP or this RFP process will be determined by a court of competent jurisdiction in the Province of Ontario.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX B


APPENDIX B AGREEMENT TERMS AND CONDITIONS B.1. Compliance with Laws B.2. Non-Exclusivity B.3. Confidentiality B.4. Indemnities B.5. Intellectual Property Indemnity B.6. No Assignment B.7. Sub-Contractors B.8. Personnel and Performance B.9. Independent Contractor B.10. Insurance B.11. Warranties and Covenants B.12. Third Party Software B.13. Ownership of Project Documentation B.14. Payment Schedule B.15. Termination Provisions B.16. Right to Audit Note to Appendix: The terms set out in this Appendix shall be incorporated in any Agreement entered into with the successful Proponent. These terms are mandatory and are not negotiable.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX B


B.1 Compliance with Laws

(1) The Vendor will be required to comply with all federal, provincial and municipal laws and regulations in performing any Services including, without limitation, the Occupational Health and Safety Act and the Workplace Safety and Insurance Act, 1997, or any successor legislation, as applicable, and to provide to the City, upon request, periodic reports confirming such compliance.

B.2 Non-Exclusivity

(1) The awarding of an Agreement to a Vendor shall not be a guarantee of exclusivity.

B.3 Confidentiality

(1) The Vendor shall treat as confidential all information of any kind which comes to the attention of the Vendor in the course of carrying out the Services and shall not disseminate such information for any reason without the express written permission of the City. The Vendor may be required to enter into a detailed confidentiality agreement in a form satisfactory to the City Solicitor.

B.4 Indemnities

(1) The Vendor shall from time to time, and at all times hereafter, well and truly save, keep harmless and fully indemnify City of Toronto and any of its Members of Council, Mayor, officers, employees, agents, representatives, invitees, members, volunteers, successors and assigns from and against any and all manner of claims, demands, losses, costs, charges, actions and other proceedings whatsoever which may be brought against or made upon any of them and against any loss or damages suffered or incurred by the City arising from or relating to any physical injury, including death, or any loss of or damage to tangible property, caused by the Vendor, its employees, agents or subcontractors or any entity for whom it is in law responsible, or arising from or arising from or relating to any statutory obligations of the Vendor; and

(2) The Vendor shall also fully defend, save harmless and indemnify the City from and against any

loss or damages suffered or incurred by the City from or arising out of the performance or rendering of, or the failure to perform or render, or the failure to exercise reasonable care, skill or diligence in the performance or rendering of the Services save and except that to the extent that any liability arising pursuant to this section is not covered by proceeds of the insurance required to be maintained by the Vendor pursuant to Article B.10 of this Appendix, the Vendor’s liability to the City shall not exceed an amount equal to the total amount payable hereunder by the City to the Vendor and in no event shall the Vendor be liable to the City for any indirect or consequential damages. The limitation of liability in this section does not apply to the indemnities required by Articles B.4 (1) and B.5 or to a breach of Confidentiality as required by Article B.3 of this Appendix.

B.5 Intellectual Property Indemnity

(1) The Vendor shall indemnify and save harmless the City of Toronto, its Mayor, Members of Council, officers, employees, and agents from and against any losses, liens, charges, claims, demands, suits, proceedings, recoveries and judgements (including legal fees and costs) arising from infringement, actual or alleged, by the Solution, its use or misuse, or by any of the deliverables developed or provided or supplied under or used in connection with the Services (including the provision of the Services themselves), of any Canadian, American or other copyright, moral right, trade-mark, patent, trade secret or other thing with respect to which a right in the nature of intellectual/industrial property exists.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX B


B.6 No Assignment

(1) The Vendor shall not assign any part of the project which may be awarded to it under the Agreement without the prior written consent of the City, which consent shall not be unreasonably withheld. However, such written consent shall not under any circumstances relieve the Vendor of its liabilities and obligations under this RFP and the Agreement.

B.7 Sub-Contractors

(1) The Vendor shall be solely responsible for the payment of every sub-contractor employed, engaged, or retained by it for the purpose of assisting it in the performance of its obligations under the Agreement. The Vendor shall coordinate the services of its sub-contractors in a manner acceptable to the City, and ensure that they comply with all the relevant requirements of the Agreement.

(2) The Vendor shall be liable to the City for all costs or damages arising from acts, omissions,

negligence or wilful misconduct of its sub-contractors. B.8 Personnel and Performance

(1) The Vendor must make available appropriately skilled workers, consultants or subcontractors, as appropriate, and must be able to provide the necessary materials, tools, machinery and supplies to carry out the Project.

(2) The Vendor shall be responsible for its own staff resources and for the staff resources of any

subcontractors and third-party service providers. (3) The Vendor will ensure that its personnel (including those of approved sub-contractors), when

using any City buildings, premises, equipment, hardware or software shall comply with all security policies, regulations or directives relating to those buildings, premises, equipment, hardware or software.

(4) Personnel assigned by the Vendor to perform or produce the Services or any part of it, (including

those of approved subcontractors) may, in the sole discretion of the City, be required to sign non-disclosure Agreement(s) satisfactory to the City before being permitted to perform such services.

B.9 Independent Contractor

(1) The relationship of the City and the Vendor is one of owner and independent contractor and not one of employer-employee. Neither is there any intention to create a partnership, joint venture or joint enterprise between the Vendor and the City.

B.10 Insurance

(1) The Vendor shall be required to purchase and maintain in force, at its own expense (including the payment of all deductibles) and for the duration of this Agreement, the following policies of insurance, which policies shall be in a form and with an insurer acceptable to the City. A certificate of these policies originally signed by the insurer or an authorized agent of the insurer must be delivered to the City prior to the commencement of the Vendor’s services:

a) Professional Liability (errors and omissions coverage) for the performance of Services by

the Vendor providing that the policy is:

i) In the amount of not less than one million dollars ($1,000,000); ii) Extended to infringement of copyright and other intellectual property, including

misuse of trade secrets;

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX B


iii) Not to be construed as a limit of the liability of the Vendor in the performance by the Vendor of the Services under this Agreement; and

iv) Notwithstanding anything to the contrary contained in this Agreement, kept in full force and effect for a period of time ending no sooner than TWO (2) YEARS after the termination or expiry of this Agreement, as the case may be.

b) Comprehensive General Liability, provided that the policy:

i) Is in the amount of not less than two million dollars ($2,000,000.00), per occurrence; ii) Adds the City of Toronto as additional insured; iii) Has provisions for cross-liability and severability of interest as between the Vendor

and the City of Toronto, broad form contractual liability, contingent employer's liability, employers liability, products and completed operations liability; non owned automobile liability and personal injury liability; and

iv) Provides for thirty (30) days' prior written notice of cancellation or material change.

(2) At the expiry date of the policy, the Vendor shall provide original signed Certificates evidencing renewals or replacements to the City prior to the expiration date of the original policies, without notice or request by the City.

B.11 Warranties and Covenants

(1) The Vendor represents, warrants and covenants to the City (and acknowledges that the City is relying thereon) that any Deliverable resulting from or to be supplied or developed under the Agreement will be in accordance with the City’s Functional, Non-Functional and Technical Requirements (as set out in the RFP) and, if applicable, will function or otherwise perform in accordance with such requirements.

B.12 Third Party Software

(1) Where the City is in possession of software containing or constituting confidential proprietary information belonging to third parties, the Vendor shall not, except in the usual incidental manner genuinely necessary for the intended use of such software on the equipment of the City:

a) Analyze, copy, decompile, disassemble, translate, convert, reverse engineer or duplicate

any physical embodiment or part thereof, or permit any person to do so; or b) Divulge to any unauthorized person the ideas, concepts or techniques, or make any other

improper use, of such software. (2) The Vendor shall fully defend, save harmless and indemnify the City from and against any loss

or damages suffered by the City as a result of any failure by the Vendor, its officers, directors, partners, contract personnel, agents and employees or any of them to comply with the provisions hereof.

(3) Should the Vendor include third party components within the Solution, the Vendor must secure

the rights to use and repackage third party components and pass on those rights to the City without additional charges.

(4) The City will own all intellectual property rights, including (without limitation) copyright, in and to

all deliverables provided by the Vendor and its subcontractors. B.13 Ownership of Project Documentation

(1) All information, data, plans, specifications, reports, estimates, summaries, photographs and all other Documentation prepared by the Vendor in the performance of the Services under the Agreement, whether they are in draft or final format shall be the property of the City.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX B


B.14 Payment Schedule

(1) A payment schedule satisfactory to the City shall form part of the Agreement. (2) No fees or reimbursable expenses shall become payable to the Vendor pursuant to the

Agreement other than pursuant to one or more signed schedules. (3) The Vendor shall submit invoices in such detail as may be required by the City, and the City

reserves the right to require further proof or Documentation from the Vendor in respect of services performed or expenses incurred by the Vendor and the Vendor shall provide, without delay, such further proof or Documentation.

(4) If the City does not approve of the Services which are the subject of the invoice, the City shall

advise the Vendor in writing of the reasons for non-approval and the Vendor shall remedy the problem at no additional cost to the City before the City shall be obliged to pay the invoice or any part of it, as the case may be.

(5) The Vendor shall be solely responsible for the payment of all personnel costs including statutory

and otherwise (including without limitation subcontractors and suppliers and their respective personnel) made available by it and used for performance of any of the Services.

B.15 Termination Provisions

(1) Failure of the Vendor to perform its obligations under the Agreement shall entitle the City to terminate the Agreement upon ten (10) calendar days’ written notice to the Vendor if a breach which is remediable is not rectified in that time. In the event of such termination, the City shall not incur any liability to the Vendor apart from the payment for the goods, material, articles, equipment, work or services that have been satisfactorily delivered or performed by the Vendor at the time of termination.

(2) All rights and remedies of the City for any breach of the Vendor's obligations under the

Agreement shall be cumulative and not exclusive or mutually exclusive alternatives and may be exercised singularly, jointly or in combination and shall not be deemed to be in exclusion of any other rights or remedies available to the City under the Agreement or otherwise at law.

(3) No delay or omission by the City in exercising any right or remedy shall operate as a waiver of

them or of any other right or remedy, and no single or partial exercise of a right or remedy shall preclude any other or further exercise of them or the exercise of any other right or remedy.

(4) Upon termination, all originals and copies of data, plans, specifications, reports, estimates,

summaries, photographs, and other documents that have been accumulated and/or prepared by the Vendor in performance of the Agreement shall be delivered to the City in a clean and readable format.

B.16 Right to Audit

(1) The City may audit all financial and related records associated with the terms of the contract including timesheets, reimbursable out of pocket expenses, materials, goods, and equipment claimed by the Contractor. The Contractor shall at all times during the term of the contract, and for a period of two (2) years following completion of the Contract, keep and maintain records of the work performed pursuant to this Contract. This shall include proper records of invoices, vouchers, timesheets, and other documents that support actions taken by the Contractor. The Contractor shall at his own expense make such records available for inspection and audit by the City at all reasonable times.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX B


B.17. Occupational Health and Safety a. The Vendor shall comply with all federal, provincial or municipal occupational health and safety

legislative requirements, including, and without limitation, the Occupational Health and Safety Act, R.S.O., 1990 c.0.1 and all regulations thereunder, as amended from time to time (collectively the "OHSA").

b. Nothing in this section shall be construed as making the City the "employer" (as defined in the OHSA) of

any workers employed or engaged by the Vendor for the Project, either instead of or jointly with the Vendor.

c. The Vendor agrees that it will ensure that all subcontractors engaged by it are qualified to perform the

Services and that the employees of subcontractors are trained in the health and safety hazards expected to be encountered in the Project.

d. The Vendor acknowledges and represents that:

i. The workers employed to carry out the Project have been provided with training in the hazards of the Project to be performed and possess the knowledge and skills to allow them to work safely;

ii. The Vendor has provided, and will provide during the course of the agreement, all necessary personal protective equipment for the protection of workers;

iii. The Vendor’s supervisory employees are competent, as defined in the OHSA, and will carry out their duties in a diligent and responsible manner with due consideration for the health and safety of workers;

iv. The Vendor has in place an occupational health and safety policy in accordance with the OHSA; and

v. The Vendor has a process in place to ensure that health and safety issues are identified and addressed and a process in place for reporting work-related injuries and illnesses.

e. The Vendor shall provide, at the request of the General Manager or his designate, the following as proof

of the representations made in paragraph d(i) and d(iv):

i. documentation regarding the training programs provided or to be provided during the Project (i.e. types of training, frequency of training and re-training); and

ii. the occupational health and safety policy. f. The Vendor shall immediately advise the General Manager or his designate in the event of any of the

following:

i. A critical injury that arises out of Project that is the subject of this Agreement; ii. An order(s) is issued to the Vendor by the Ministry of Labour arising out of the Project that is the

subject of this Agreement; iii. A charge is laid or a conviction is entered arising out of the Project that is the subject of this

Agreement, including but not limited to a charge or conviction under the OHSA, the Criminal Code, R.S.C 1985, c. C-46, as amended and the Workplace Safety and Insurance Act, 1997, S.O. 1997, c. 16, Sched. A, as amended.

g. The Vendor shall be responsible for any delay in the progress of the Project as a result of any violation or

alleged violation of any federal, provincial or municipal health and safety requirement by the Vendor, it being understood that no such delay shall be a force majeure or uncontrollable circumstance for the purposes of extending the time for performance of the Services or entitling the Vendor to additional compensation, and the Vendor shall take all necessary steps to avoid delay in the final completion of the Project without additional cost to the City.

h. The parties acknowledge and agree that employees of the City, including senior officers, have no authority to direct, and will not direct, how employees, workers or other persons employed or engaged by the Vendor do work or perform a task that is the subject of this agreement.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX B


B.18. Workplace Safety and Insurance Act The Vendor shall be in good standing with the Workplace Safety and Insurance Board (“WSIB”) throughout the term of this agreement. If requested by the General Manager or his designate, the Vendor shall produce certificates issued by the WSIB to the effect that they have paid in full their assessment based on a true statement of the amount of payrolls. If the Vendor is considered by WSIB to be an independent operator without coverage, the Vendor shall provide a letter to that effect from the WSIB. B.19. Accessibility Standards for Customer Service Training Requirements The Vendor shall require all applicable Personnel (including those of its subcontractors) to fulfill the training requirements set out in the City's policy on Accessible Customer Service Training Requirements for Contractors, Consultants and other Services Providers. B.20 Letter of Credit (1) The Vendor shall be required to guarantee the performance of its obligations under any Agreement

with the City by means of an unconditional, irrevocable letter of credit. The letter of credit will be provided by the successful Proponent before the start of any negotiation of the Agreement and shall be held by and available to the City for the period ending one year after expiry of the pilot AMS Project or earlier termination of the Agreement.

(2) The letter of credit shall be in an amount equal to 100% of the Total Price associated with the

provisions of the Equipment and Services being provided under Schedule A - Statement of Work, or any subsequent Statement(s) of Work or such lesser amount as the City, in its sole discretion, may determine. If necessary, the letter of credit shall be automatically renewed on an annual basis at the start of each year during which Services are provided and shall be held by the City until the completion of the Services and Deliverables set out in the applicable SOW and up to one (1) year thereafter. Any letter of credit must be in a form acceptable to the City and must be executed by a Canadian Chartered Bank listed in Schedule “I” or “II” to the Bank Act (Canada).

(3) The following conditions must be incorporated in any letter of credit:

(a) the place of banking must be named and the letter of credit must be redeemable within Toronto;

(b) the letter of credit must indicate it is issued subject to the Uniform Customs and Practices for Documentary Credits, ICC Publication No. 500 (UCP500);

(c) the documents required for cashing must be indicated precisely; (d) the letter of credit must be payable to the City of Toronto, and the City may draw upon it; and (e) the expiry date must be indicated. If necessary, the letter of credit must automatically renew

unless the letter of credit provides that the issuer will advise the City in writing at least thirty (30) days prior to the expiry date or dates that it will not renew and that, if so advised, the City may immediately draw upon the letter of credit.

B.21 Master Agreement The Vendor acknowledges and agrees that, in its sole discretion, and after the completion of a successful pilot AMS as set out in this Agreement, the City may choose to roll-out the AMS to other City Divisions and Agencies, Boards and Commissions. The City and the Vendor agree that the methodology for roll-out to other City Divisions will be by amendment and addition of a new Schedule (SOW) to this Agreement which shall then be the Master Agreement for all further roll-outs by the Vendor and the parties will be bound by its provisions. None of the Master Agreement's terms and conditions will change unless by agreement in writing by both parties. For the ABC's, this will be done by way of separate agreement between the ABC(s) and the Vendor incorporating the terms, conditions and pricing of this Agreement as may be appropriate.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX C


APPENDIX C STANDARD SUBMISSION FORMS FORM 1: Proposal Submission Form – Mandatory FORM 2: Policy to Exclude Bids From External Parties Involved in the Preparation or Development of a

Specific Call/Request – Mandatory FORM 3: Restrictions on the Hiring and Use of Former City of Toronto Management Employees for City

Contracts – If Applicable FORM 4: Environmentally Responsible Procurement – If Applicable FORM 5: Notice of No Submission – If Applicable

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX C


Form 1 – Proposal Submission Form

Request For Proposal No. 3405-12-3117 Asset Management Solution (AMS) CLOSING: September 10, 2012 I/WE HEREBY SUBMIT MY/OUR PROPOSAL FOR THE PROVISION OF THE GOODS AND/OR SERVICES AS DESCRIBED WITHIN THE REQUEST FOR PROPOSAL DOCUMENT FOR THE ABOVE NAMED PROJECT. I/WE HAVE CAREFULLY EXAMINED THE DOCUMENTS AND HAVE A CLEAR AND COMPREHENSIVE KNOWLEDGE OF THE REQUIREMENTS AND HAVE SUBMITTED ALL RELEVANT DATA. I/WE AGREE, IF SELECTED TO PROVIDE THOSE GOODS AND/OR SERVICES TO THE CITY IN ACCORDANCE WITH THE TERMS, CONDITIONS AND SPECIFICATIONS CONTAINED IN THE PROPOSAL DOCUMENT AND OUR SUBMISSION. I/WE AGREE THAT THIS SUBMISSION IS BEING MADE WITHOUT ANY COLLUSION OR FRAUD. ACKNOWLEDGE RECEIPT OF ADDENDA BY NUMBER AND ISSUE DATE: ADDENDUM NO. ___________________ DATED _____________________ ADDENDUM NO. ___________________ DATED _____________________ ADDENDUM NO. ___________________ DATED _____________________ ADDENDUM NO. ___________________ DATED _____________________ SUBMITTED BY: ________________________________________________________ (PROPONENT’S FULL LEGAL NAME) ADDRESS: ________________________________________________________ TELEPHONE NO.: _____________________ FAX NO.: __________________________ DATE: _____________________ ________________________________________________________________________ SIGNATURE OF AUTHORIZED SIGNING OFFICER ________________________________________________________________________ PRINTED NAME OF AUTHORIZED SIGNING OFFICER THIS FORM MUST BE SIGNED AND SUBMITTED WITH YOUR PROPOSAL OR YOUR PROPOSALWILL BE DECLARED INFORMAL. VIE

WIN

G COPY

DO NOT S

UBMIT


(AMS) APPENDIX C


Form 2 – Policy to Exclude Bids From External Parties Involved in the Preparation or Development of a Specific Call/Request

To ensure Fair and Equal Treatment in its competitive procurements, the City of Toronto will undertake to: Disallow bidders/Proponent from submitting a bid to any Tender, Quotation, or

Proposal call in which the bidders/Proponent has participated in the preparation of the call document; and

A bidders/Proponent who fails to comply will result in disqualification of their response

to the call/request. Did you, the Proponent, assist the City of Toronto in the preparation of this Request for Proposal call? Specify: Yes _________ No _________

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX C


Form 3 – Restrictions on the Hiring and Use of Former City of Toronto Management Employees for City Contracts

The purpose of this Policy to ensure that former City of Toronto management employees who took part in a separation program or received a retirement package, are prohibited from participating in contracts directly or indirectly related to the City of Toronto or its special purpose bodies for a period of two years starting from an employee’s separation date. Former employees covered by this policy are prohibited from participating in contracts directly or indirectly related to the City of Toronto or its special purpose bodies for a period of two years starting from the employee’s separation date. This would include, but not be limited to, for example, the following roles: As an independent contractor/consultant; As a contractor/consultant on City Project Work for a company/firm (but, the firm may

compete); or As a contractor/consultant on City Project Work for a company/firm that has been sub-

contracted by another company/firm. Former City of Toronto management employees who took part in a separation program or received a retirement incentive are prohibited from participating in contracts directly or indirectly related to the City of Toronto and its special purpose bodies for a period of two years starting from an employee’s termination date. Notes: (1) Adopted by Council at its meeting of February 4, 5, & 6, 1998, Report No. 2, Clause No. 2 of the Strategic Policies and Priorities Committee, and (2) Revised by City Council at its meeting of November 26, 27, 28, 2002, Report No. 14, Clause No. 6, Administration Committee. Respondents are to state the name(s) of any former City of Toronto management employee(s) hired/used by your firm, if any, who have left the employ of the City or its special purpose bodies within the last two (2) years. Specify: _________________________________________________________________ This policy will be considered in the evaluation of all submissions received by the City of Toronto. For further information contact: Manager, Corporate Purchasing, Policy & Quality Assurance 18th Floor, West Tower, City Hall, (416) 392-1302 VIE

WIN

G COPY

DO NOT S

UBMIT


(AMS) APPENDIX C


Form 4 – Environmentally Responsible Procurement Statement The City of Toronto Environmentally Responsible Procurement Policy encourages bidders to also offer products/services that are environmentally preferred. Environmentally preferred products/services offered should be competitive in cost, conform to specifications, performance requirements and, be suitable for the intended application as determined by the using department(s). Environmentally preferred products/services are those such as durable products, reusable products, energy efficient products, low pollution products/services, products (including those used in services) containing maximum levels of post consumer waste and/or recyclable content, and products which provide minimal impact to the environment. An environmentally preferred product is one that is less harmful to the environment than the next best alternative having characteristics including, but not limited to the following: Reduce waste and make efficient use of resources: An Environmentally Preferred Product would be a

product that is more energy, fuel, or water efficient, or that uses less paper, ink, or other resources. For example, energy efficient lighting, and photocopiers capable of double sided photocopying.

Are reusable or contain reusable parts: These products such as rechargeable batteries, reusable

building partitions, and laser printers with refillable toner cartridges Are recyclable: A product will be considered to be an Environmentally Preferred Product if local facilities

exist capable of recycling the product at the end of its useful life. Contain recycled materials: An Environmentally Preferred Product contains post consumer recycled

content. An example is paper products made from recycled post consumer fibre. Produce fewer polluting by products and/or safety hazards during manufacture, use or disposal: An EPP

product would be a non hazardous product that replaces a hazardous product. Have a long service life and/or can be economically and effectively repaired to upgraded. Bidders shall if requested, provide written verification of any environmental claims made in their bid/Proposal satisfactory to the City of Toronto within five (5) working days of request at no cost to the City. Verification may include, but not be limited to, certification to recognized environmental program (e.g., Environmental Choice Program [ECP]), independent laboratory tests or manufacturer's certified tests, Only proven environmentally preferred products/services shall be offered. Experimental or prototype products/services will not be considered. For a copy of the City of Toronto Environmentally Responsible Procurement Policy, visit the website at: www.toronto.ca/tenders/environment.htm State if environmentally preferred products/service is being offered: YES ______ NO ______ State briefly the environmental benefit of the product/service offered: ________________________________________________________________________ ________________________________________________________________________ ________________________________________________________________________

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX C


Form 5 – Notice Of “No Submission”

REQUEST FOR PROPOSAL NO. 3405-12-3117 Asset Management Solution (AMS) CLOSING: September 10, 2012

IMPORTANT - PLEASE READ THIS It is important to the City of Toronto to receive a reply from all invited Proponents. There is no obligation to submit a Proposal; however, should you choose not to submit, completion of this form will assist the City in determining the type of services you are interested in submitting a Proposal in the future.

INSTRUCTIONS: If you are unable, or do not wish to submit a Proposal on this Request for Proposals, please complete the following portions of this form. State your reason for not submitting a Proposal by checking applicable box(es) or by explaining briefly in the space provided. It is not necessary to return any other Request for Proposals documents. 1. We do not offer this service. Other reasons or additional comments: 2. We do not offer services to these requirements.

3. Unable to offer services competitively. 4. Cannot handle due to present commitments.

5. Quantity/project too large. 6. Cannot meet delivery/completion requirements.

7. Licensing restrictions. Do you wish to participate in Request for Proposals for services in the future? YES ______ NO ______ For City’s use only - Do not write in this space Company Name:

Address: Signature of Company Representative: Position: Date: Tel. No.:

Fax No.:

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX C


Form 6 – City of Toronto Customer Service Training Requirements: Contractors,

Consultants and other Service Providers – If Applicable

City of Toronto Accessible Customer Service Training Requirements:

Contractors, Consultants and other Service Providers (Accessibility Standard for Customer Service, O. Reg. 429/07, AODA 2005)

The City of Toronto supports the goals of the Accessibility for Ontarians with Disabilities Act (AODA), 2005 and is committed to providing equal treatment and equitable benefits of City services, programs and facilities in a manner that respects the dignity and independence of people with disabilities. Under section 6 of the Accessibility Standard for Customer Service, O. Reg. 429/07 (Appendix A), established by the AODA, the City of Toronto must ensure that employees, volunteers and all other personnel, including third party contractors, who deal with members of the public or other third parties on behalf of the City or, who participate in developing City policies, practices or procedures on the provision of goods and services receive training on accessible customer service. All personnel must complete training that meets the requirements of the Accessible Customer Service regulation and includes:

An overview of the AODA Understanding the requirements of the Regulation How to interact and communicate with persons with various types of disabilities; How to interact with persons with disabilities who use an assistive device or require the assistance

of a guide dog or other service animal or the assistance of a support; How to use equipment or devices available on the provider’s premises or otherwise provided by the

provider to people with disabilities to access goods or services; and What to do if a person with a particular type of disability is having difficulty accessing the provider’s

goods or services. Third party contractors and other service providers are to ensure that training records are maintained, including dates when training is provided, the number of personnel who received training and individual training records. Contractors are required to ensure that this information is available, if requested by the City of Toronto. Access an e-learning course: The training requirements can be fulfilled by completing the e-Learning course “Serve-ability: Transforming Ontario’s Customer Service”, which can be found on the Ministry of Community and Social Services website: http://www.mcss.gov.on.ca/mcss/serve-ability/splash.html For more information: How to comply with the Accessible Customer Service Standard at: www.accessON.ca/compliance Requirements of the Accessibility Standards for Customer Service (Ontario Regulation 429/07): www.e-laws.gov.on.ca/html/source/regs/english/2007/elaws_src_regs_r07429_e.htm

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX C


Sup

plie

r N

umbe

r

Com

pany

/Org

aniz

atio

n N

ame

Dat

e

Form 7 – Non-Discrimination Policy

Declaration of a Non-Discrimination Policy The City of Toronto requires all firms or organizations who supply goods and services to the City and its Agencies, Boards, Commissions and Special Purpose Bodies, to adopt and to post a Non-Discrimination Policy that ensures that the: Organization/firm upholds policies which prohibit discrimination and which protect the right to be free of hate activity based on race, ancestry, place of origin, colour, ethnic origin, disability, citizenship, creed, sex, sexual orientation, gender identity, age, marital status, family status, receipt of public assistance, political affiliation, religious affiliation, record of offences, level of literacy or any other personal characteristics by or within the organization.

Check if organization/firm has previously completed and filed the form with City: Yes No If yes, please do not complete the form. If no, please complete the form.

Please type or print where applicable Legal Firm Name Common or Business Name (if different)

Address of Principal Place of Business Mailing Address (if different)

Tel. No. Fax No. Tel. No. Fax No.

Name of Chief Executive Officer/President Name of Employment Equity Official:

Position Title: Position Title:

Signature of Authorized Official: Date:

Check if Firm is more than 50% owned by* (check all that apply): Aboriginal Peoples/First Nations Of Canada People with Disabilities Racial Minorities Women Not Applicable

Office of Equity, Diversity & Human Rights 100 Queen Street West City Hall, 14th Floor, West Tower Toronto, ON M5H 2N2

Uzma Shakir Director Tel: 416-392-1108 Fax: 416-696-4174 ushakir @toronto.ca www.toronto.ca

City Manager’s Office Joseph P. Pennachetti, City Manager

For

Offi

ce U

se o

nly

PO

LIC

Y D

EC

LA

RA

TIO

N

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX C


* Please see reverse for explanation of definitions The information requested on this form is, collected pursuant to Clause 6 of Corporate Services Committee Report 11, adopted by Council on July 29,30 and 31, 1998 and Clause 2 of Corporate Services Committee Report 19 adopted by Council on December 16 and 17,1998. Its purpose is to verify that your firm has adopted the Non-Discrimination Policy and to compile statistics for the purpose of monitoring the equal opportunity designated group status of the ownership of firms. If you have any questions about this declaration, please contact the Director of Equity, Diversity and Human Rights at 416-392-1108. Multi-Lingual Line call 311 and TTY 416-338-0889.

Please return completed form to the address shown above (Private Sector Firms)

Definitions: Aboriginal Peoples/ First Nations of Canada: A person is an Aboriginal person if he or she is a member of the First Nations (status

and non-status Indians), Inuit (Aboriginal peoples from Arctic Canada) and Métis (mixed First Nation and European ancestry).

Person With A Disability: A person is a "person with a disability" if the person has a persistent physical,

mental, psychiatric, sensory or learning impairment that substantially limits one or more major life activities and,

(i) the person considers himself or herself to be disadvantaged in employment by reason of that impairment, or -

(ii) the person believes that an employer or potential employer is likely to consider the person to be disadvantaged in employment by reason of that impairment.

Racial Minority: Also called racialized people or visible minorities, a person is a member of a racial minority because of his or her race or colour. Racial minorities include African Canadian/Black, East Asian, South East Asian; South Asian, West Asian or Arab and

others that have bi-or multi-racial origins.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX D


APPENDIX D PRICE DETAIL FORMS Appendix D - Price Detail Forms consists of multiple EXCEL spread sheets contained in the provided workbook. Below is a description of all the Price Detail Forms required for this RFP. Proponents are to submit the Price Detail Form(s) according to the instructions set out herein. Below is a list of the Price Detail Forms to be used by Proponents: 1. Appendix D1a, D1b, D1c and D1d Price Detail Forms for AMS Functionality, Annual Maintenance &

Support Services for End Users, Power Users, Administrators and Servers. 2. Appendix D2a Price Detail Form for List and Cost of AMS Customizations and D2b Detail Form for

List of AMS Configurations. 3. Appendix D3 Price Detail Form for AMS Professional Services Costs. 4. Appendix D4 Price Detail Form for List and Cost of AMS Reference Hardware. 5. Appendix D5 Price Detail Form for Optional On-Site Technical Support. These forms are for informational purposes only. Two Price Detail Forms are calculated and derived from the above Appendices. Proponents are not to modify or enter any information into these two forms. These are: 3. Appendix D6 - Proponent Total Cost which presents Price Details and the Total Cost of Proponent's

AMS. The Total Cost calculated on this appendix should equal the Total Proposal Cost. 4. Appendix D7 - Evaluation of Proponent Costs which presents Price Details and calculates the

Proponent's AMS Costs for Evaluation Purposes based on two (2) Scenarios across five (5) years. These Costs will be used in the Cost Evaluation Stage described in the RFP.

General Instructions that apply to all Price Detail Forms: Proponents are to follow these general instructions for all Price Detail Forms:

a) Under no circumstances may the Price Detail Forms be altered in any way other than by insertion of the required information in the cells provided. If the Price Detail Form is altered in any other way, the Proponent's Proposal may be disqualified.

b) No blank spaces are allowed wherever Costs are submitted. Proponents are to provide one (1) Cost in each field where pricing is required. Proponent is to indicate "0" when no Cost applies. Proponents shall not enter "same" or otherwise instead Proponents will enter the same figure in all respective cells. Proponents shall not include a range (e.g. $500 - $700) on any of the Price Detail Forms. Proposals that do not conform to these instructions or which do not provide the Costs as indicated in the Price Detail Form may be disqualified.

c) On some Price Detail Forms there are 2 areas to indicate separate Costs for year 1 and for years 2 - 5. Proponents are to record all Costs as requested on each form.

d) Spreadsheets will automatically calculate subtotals and carry values calculated to other cells for RFP Bid confirmation and Cost evaluation. Proponents should validate these calculations to ensure accuracy as all Rates are considered firm once submitted. Where there is a discrepancy between the hardcopy prices and the electronic copy prices, the hardcopy Costing Envelope marked as “original” will prevail.

e) Before submitting Costs on the Price Detail Form(s), Proponents should review and understand the terms and conditions described in the RFP.

f) Price Detail Forms (as per the instructions provided) are to be submitted in electronic format in Excel and Proponents are to provide soft and hardcopies as detailed in the RFP.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX D


g) All aspects of the Proponent's Costs to implement the proposed AMS which are to be charged to the City MUST be bid using the Price Detail Forms provided.

h) The Price Detail Forms must include all Costs for Modules/products and/or services that are required to comprise the AMS and that specifically address mandatory requirements as set out in the RFP. Evaluation of Proponent Costs will be on mandatory components only.

i) The Price Detail Forms may also include Costs for optional Modules/products and/or services that may address desirable requirements as set out in the RFP. These costs will not be evaluated as part of the Proponent Costs. However, however, the City reserves the right to purchase the proposed software components at the prices detailed in the Price Detail Forms.

j) The Proponent is to follow additional instructions as detailed in the notes section on each Price Detail Form.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX E


APPENDIX E PROPOSAL EVALUATION TABLE

Stage # Description Total

Weight 100%

Stage 1

Mandatory Requirements Stage 1 consists of a review to determine compliance with mandatory requirements, as outlined in Appendix F.1, Appendix F.2, Appendix F.3, and Appendix F.4. Only Proposals meeting the Mandatory Requirements in Stage 1 will be considered further.

Pass/Fail

Stage 2 Detailed Evaluation ofMandatory and Non-Mandatory

Functional Requirements, Technical and Non-Functional Requirements

1. Stage 2 is valued at 80% in the overall selection process. Proponents

must achieve a minimum threshold of 65% in three sub-stages (2A-1: Functional Requirements I, 2A-2: Technical Requirements II, and 2A-3: Non-Functional Requirements III) to advance to the next.

Although there is no minimum threshold for the Implementation Requirements (sub-stages 2A-4, 2A-5 and 2A-6), the scores will be summed with the three other sub-stages. Proponents must achieve an overall threshold of 75% on the combined scores. The total points for all sub-stages is 1,000 points, therefore Proponents must achieve 750 points out 1,000 points (75%) to advance to Stage 3.

Stage 2A will consist of a scoring by the City of each qualified Proposal for the following sub-stages 2. Sub-Stage 2A-1: Functional Requirements

(Appendix F.2 Sections 2.1 to 2.12 Weight 30%, 350 Points, 65% Threshold or 228 Points)

3. Sub-Stage 2A-2: Technical Requirements (Appendix F.3 Sections 3.1 to 3.5, Weight 25%, 200 Points, 65% Threshold or 130 Points)

4. Sub-Stage 2A-3: Non-Functional Requirements (Appendix F.4 Sections 4.1 to 4.4, Weight 25%, Points 250, 65%Threshold or 163 Points)

5. Sub-Stage 2A-4: PF&R Implementation Requirements (Appendix F.6 Sections 6.1 to 6.4, Weight 20%, 200 Points, 0% Threshold or 0 Points)

Please note that the points awarded to Stage 2A and sub-stages 2A1, 2A2, 2A3 and 2A4 may be adjusted based on the results of the Product Live Demonstration in Stage 2B.

80

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX E


Sub-Stage 2A-1

Sub-Stage 2A-1 Functional Requirements Evaluators will assess the proposed Solution’s adherence to the Functional Requirements in Appendix F.2 Sections 2.1 to 2.12 which is valued at 35% in the selection process. Please Note that the Functional Requirements in Appendix F.2 Section 2.1 are all Mandatory and that failure to meet a Mandatory Requirement will disqualify the proponent. The Functional Requirements in Appendix F.2 Sections 2.1 to 2.12 have a minimum pass mark of 65% and will be scored out of 350 points. Proponents that score a minimum of 228 points will be deemed to have met the minimum threshold and will be considered further. Proponents that do not achieve the minimum threshold will not be considered further. Proponents must submit Appendix F.2 Sections 2.1 to 2.12.

Sub-Stage 2A-2

Sub-Stage 2A-2 Technical Requirements Evaluators will assess the proposed Solution’s adherence to the Technical Requirements in Appendix F.3 Sections 3.1 through to 3.5 which is valued at 20% in the selection process. Please Note that the Technical Requirements in Appendix F.3 Section 3.1 are all Mandatory and that failure to meet a Mandatory Requirement will disqualify the proponent. The Technical Requirements in Appendix F.3 Sections 3.1 through to 3.5 has a minimum pass mark of 65% and will be scored out of 200 points. Proponents that score a minimum of 130 points will be deemed to have met the minimum threshold and will be considered further. Proponents that do not achieve the minimum threshold will not be considered further. Proponents must submit Appendix F.3 Sections 3.1 through to 3.5.

Sub-Stage 2A-3

Sub-Stage 2A-3 Non-Functional Requirements Evaluators will assess the proposed Solution’s adherence to the Non-Functional Requirements in Appendix F.4 Sections 4.1 through to 4.4 which is valued at 25% in the selection process. Please Note that there are Mandatory Requirements in the Non-Functional Requirements in Appendix F.4 Sections 4.1 through to 4.4 and that failure to meet a Mandatory Requirement will disqualify the proponent. The Non-Functional Requirements in Appendix F.4 Sections 4.1 through to 4.4 has a minimum pass mark of 65% and will be scored out of 250 points. Proponents that score a minimum of 163 points will be deemed to have met the minimum threshold and will be considered further. Proponents that do not achieve the minimum threshold will not be considered further. Proponents must submit Appendix F.4 Sections 4.1 through to 4.4.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX E


Sub-Stage 2A-4

Sub-Stage 2A-4 PF&R Implementation Requirements Evaluators will assess the proposed Solution’s adherence to the PF&R Implementation Requirements in Appendix F.6 Sections 6.1 through to 6.4 which is valued at 20% in the selection process. The PF&R Implementation Requirements in Appendix F.6 Sections 6.1 through to 6.4 has no minimum pass mark and will be scored out of 200 points. Proponents must submit Appendix F.6 Sections 6.1 through to 6.4.

Stage 2B Interviews, Product Live Demonstration and Presentation Stage 2B is the evaluation of a Live Demonstration for the remaining proponents who have passed Stage 2A; Please see Section 4.2.3 Stage 2B – Interviews, Product Live Demonstration and Presentation for more details. Only Proposals meeting the thresholds set out for Stage 2A will be considered for Product Live Demonstration. Each Proponent will be required to make one (1) live demo of its AMS. The purpose of the Stage 2B Demonstration is to demonstrate the AMS's ability to meet selected mandatory and rated requirements detailed within this RFP and Stage 2B evaluation will help confirm the ability of the Proponent’s Solution and resources to deliver the requirements in the areas selected. Stage 2B will be the evaluation of a live demonstration of the proposed Solution. Each Proponent will be scheduled for one day to make one (1) live demo of its AMS. The Stage 2B evaluation will validate the ability of the Proponent’s Solution to deliver the requirements in the areas selected for Demonstration and will assess the usability of the product based on Demonstration Scripts that will be provided to short-listed Proponents. Proponents who are invited to participate will be notified and provided with detailed information seven (7) calendar days in advance of the scheduled live demo. All Proponents will receive the same information, with the same number of days advance notification. After receiving an invitation to participate, the Proponent must identify to the City within three (3) business days, the Proponent location in which the live demo will occur which must be within the Greater Toronto Area. Details with respect to the agenda, length of the demonstration, list of requirements to be demonstrated, required attendees, etc. will also be provided in the Letter of Invitation. The City does however, reserve the right to include additional requirements from the RFP at the time of invitation. The evaluation conducted in Stage 2B will be used to further inform the scores assigned in Stage 2A. The results of the demo will be used as a mechanism to revisit, revise, confirm and finalize the Stage 2A scores. The Proponent must bear all costs associated with or incurred in the preparation and presentation of its Proposal including, if applicable, costs incurred for interviews or demonstrations.

N/A

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX E


Stage 3 (Selected Proponents only)

Cost Evaluation Upon completion of Stage 2B, the sum of all scores in all sub-stages within Stage 2A will be calculated and if the minimum thresholds described above are met then the Proponents sealed pricing envelope will be opened for price evaluation. Stage 3 carries a weight of 20% in the overall selection process and the "Proponent's Combined Average Cost" from Appendix D.1 – Summary Price Detail Form will be used in the calculation as follows

The lowest cost Proposal receives 20 points; and The remaining Proposals are assigned points based on the following

formula

25 Cost Proposal sProponent'

Cost Proposal PricedLowest

The foregoing formula will be used in part for the purpose of awarding contracts in whole or by part at the discretion of the City.

20

Total Points

100

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


APPENDIX F REQUIREMENTS & PROJECT REFERENCE MATERIAL 1. Appendix F.1 - Mandatory Requirements 2. Appendix F.2 - Functional Requirements 3. Appendix F.3 - Technical Requirements

4. Appendix F.4 - Non-Functional Requirements 5. Appendix F.5 - The City’s Existing I&T Infrastructure

6. Appendix F.6 - PF&R Requirements

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Appendix F.1 – Mandatory Requirements Compliance Tables (1) This Appendix contains the Mandatory Requirements for the AMS project. Proponents must

respond to the Mandatory Requirements using one (1) of two (2) possible responses:

Letter Code Response

Y Proponent complies with Requirement N Proponent does not comply with Requirement

(2) Mandatory Requirements with blank responses will be treated the same as “N,” which

corresponds to “Proponent does not comply with Mandatory Requirement.”

(3) Mandatory Requirements with responses other than “Y” or “N” will be treated the same as “N,” which corresponds to “Proponent does not comply with Mandatory Requirement.”

(4) Proponents who do not respond “Y” to each and every Mandatory Requirement in this appendix will have their Proposals declared Informal and will NOT be considered for further evaluation.

Mandatory Requirements (Section 1) Proponent Qualifications Req’t # Requirement Text Response

1.1.1 Proponents must have the right to represent, sell, license, deliver, install, train in the use of, service, maintain and support the products proposed, (including any Documentation to be provided in relation thereto), and the right to transfer to the City any required ownership, license rights, pass-through warranties and other ancillary rights for all proposed goods and services. In providing such products and services to the City the rights of any third-party must not be infringed or otherwise violated.

1.1.2 Proponents must acknowledge that they have read, understood and comply with the terms and conditions of this RFP, specifically as identified in Appendix A – RFP Process Terms and Conditions and Appendix B – Legal Terms and Conditions.

1.1.3 Proponents must agree to provide the following information: Audited financial statements for the past two (2) years for public companies, or a letter from a financial institution confirming the Proponent’s financial viability and solvency as a going concern for private companies. Proponents must provide this information upon request from the City within 10 business days.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Appendix F.2 – Functional Requirements Compliance Tables (1) This Appendix contains the Functional Requirements for the AMS Project.

(2) There is both mandatory and non-mandatory Functional Requirements for the AMS

project.

(3) The designations "M" or "D" on the requirements tables are detailed below:

Legend Description

D Requirement listed is "Desirable"

M Requirement listed is "Mandatory"

(4) Proponents should respond to the Functional Requirements via letter codes that correspond to

one (1) of seven (7) possible responses. Associated point values that will be attributed to each response are:

Letter Code

Response Points

B Functionality available through base product, Out-of-the-Box 5 C Functionality available through base product, with Configuration

required 4

A Functionality available through an optional/add-on component/module of the base product, with Configuration required

3

T Functionality available through a third party software product, with Customization and/or Configuration required

1

Z Functionality available through Customization 1 R Functionality not available until the next release of the base product 0 N Functionality not available Failure

(Mandatory Requirements)

0 (Desirable

Requirements) (5) Requirements with blank responses will be treated the same as “N,” which corresponds to

“Functionality not available”

(6) Responses other than “B,” “C,” “A,” “T,” “Z,” or “R” will be treated the same as “N,” which corresponds to “Functionality not available.”

(7) Responses with blank or "N" responses will be scored as 'Failure' For Mandatory items resulting in disqualification, and will be scored as '0' for Desirable items.

(8) In some cases, there may be “shades of grey” inherent in a response, such as “most of what’s being asked for is Out-of-the-Box, but one small aspect would have to be customized.” In such situations, Proponents are encouraged to take advantage of the “Details and Additional Comments” column on the compliance tables, so that the City of Toronto can properly understand the extent to which their Solution actually matches their chosen response code.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


(9) Responses of “C,” “A,” “T” or “Z” indicate that some level of Configuration and/or Customization

will be required in order to achieve the requested functionality within the Solution. As such, Proponents should provide an estimate of the expected level of effort and costs associated with the Configuration and/or Customization necessary in order to meet a given Functional Requirement. The following table indicates where Proponents will provide this information:

Response Location for Cost/Effort Estimate Information

C Appendix D.3, List of Configurations A Appendix D.3, List of Configurations T Appendix D.3, List of Configurations and

Appendix D.2 - Customizations & Costs Z Appendix D.2 - Customizations & Costs and

Appendix D.2 - Customizations & Costs

Failure to include this cost information for responses of “C,” “A,” “T” or “Z” will result in the City assuming that the Proponent has built such costs into its base price.

(10) Please note that the “Details and Additional Comments” section to the far right of each

requirement is provided to allow Proponents space to provide detailed information on how their Solution satisfies the City’s requirements. Proponents may use this space to provide a reference to the body of their Proposal where the details and additional comments may be found, or it may be filled in directly.

(11) The Functional Requirements are largely based on the Capital Planning business processes which are shown in Appendix F.5 – Building Condition Assessment Process Map and Appendix F.6 – Capital Planning Capital Planning Process Map. Understanding these processes will provide Proponents with insight into the processes and functions that the AMS is intended to manage.

(12) Appendix F.2- Functional Requirements (Sub-Stage 2A-1) represent 350 points out of a total of 1,000 points for all sub-stages.

Proposed System (Section 2.1) General Functional Requirements – Mandatory Req’t # Requirement Text Response Details and Additional

Comments 2.1.1 M The Solution must be an enterprise Solution

supporting multiple organization units.

The Asset Management System (AMS) must be a fully integrated with the following major functionality:

2.1.2 M manage information about physical assets, including Geographic Information System (GIS) or spatial data;

2.1.3 M manage creation of capital projects, plans and budgets for physical assets;

2.1.4 M plan and prioritize the renewal of physical assets using lifecycle planning principles;

2.1.5 M manage the capital expenditures associated with physical assets;

2.1.6 M manage and track project milestones and financial status;

2.1.7 M manage and track compliance issues and their appropriate action;

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed System (Section 2.1) General Functional Requirements – Mandatory Req’t # Requirement Text Response Details and Additional

Comments 2.1.8 M manage mobile field data collection,

inspections and assessments, including component condition, performance and compliance assessments;

2.1.9 M interface with the City’s current (CAPTOR) and future capital planning and budget (Public Sector Budget Formulation) systems;

2.1.10 M interface with the City’s Geospatial Data Repository (ESRI Geodatabase and Oracle Spatial);

2.1.11 M interface with the Division’s work management system (future requirement).

2.1.12 M The system must be able to manage and prioritize all asset capital projects, including: Legislated asset projects; Service improvement asset projects; Growth related asset projects; and State of Good Repair (SOGR) asset

projects.

2.1.13 M The system must manage a diverse inventory of assets including buildings, sports complexes, trails, bridges, playground equipment, equipment and trees.

2.1.14 M The system must support the City's logical asset data model (refer to Appendix “H”), a network model where each asset may have multiple parent and child assets allowing infinite relationships. For example, one trail segment may belong to both a provincial trail asset and a city trail asset. A parking lot may be associated with its supported building (from a capital projects perspective) but associated with a park (from an operational support perspective).

2.1.15 M The system must allow for asset spatial data. These objects may be point, line, area, or shape features.

Proposed System (Section 2.2) Asset Information Requirements – Mandatory Req’t # Requirement Text Response Details and Additional

Comments 2.2.1 M The system must support the collection and

management of a wide range of asset information, such as location, structure, type, uses, conditions, requirements and their associated costs, and related projects and plans.

VIE

WIN

G COPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 2.2.2 M The system must allow for an asset to be

classified into multiple categories both within the same or across different schemes. For example, an asset may be classified as both an outdoor ice rink (in the winter) and a tennis court (in the summer). A means of preventing double counting of assets and money will need to be accommodated.

2.2.3 M The system must allow for different audience-driven category hierarchies. For example, different hierarchies are required for capital projects, operational work orders, recreational programs, and public-facing views.

2.2.4 M The system must allow for large documents such as photographs, reports, drawings, and video be stored in and/or linked to the system.

2.2.5 M The system must allow for non-asset spatial objects, and limited tabular attributes, such as, but not limited to, administrative areas (such as city wards and service plan areas), road networks, watercourses, intersections, parcels, and named places. These objects may be point, line, area, or shape features.

2.2.6 M The system must be able to accommodate the addition of asset-category specific attributes (and their associated permissible values) without having to change either the database or screen design.

2.2.7 M A common record format is required to load new and updated asset, lifecycle event, condition assessment, index measurement, and project funding data from different sources. Procedures to load data from this CRF into the asset database, along with proper error handling, restartability mechanisms and scheduling, are also required. Consensus on the best format will need to be reached e.g. delimited, XML, etc.

2.2.8 M A common record format is required to extract asset data. May be the same CRF as in 2.3.11. Procedures to load data into this CRF from the asset database are required.

2.2.9 M The City will require the ability to add database objects to the asset database without compromising warranty or service maintenance agreements. These database objects will be limited to items such as views, triggers, and stored procedures. None of these database objects will create, change, or delete data from the asset database itself. The City will be responsible for the maintenance of these objects.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 2.2.10 M Full database documentation is required

including, but not limited to, physical data models and dictionaries, logical data models and dictionaries (optional), and technical specifications for the common record format population (both load and extract directions). Support for the purposes of understanding the database design may be required.

Proposed System (Section 2.3) General Functional Requirements – Desirable Req’t # Requirement Text Response Details and Additional

Comments 2.3.1 D The system should automate the capital budget

review and approval workflow process.

2.3.2 D The System should support budget planning and management for multiple Funding Sources: Reserve Funds; Development Charge Reserve Funds; Provincial Grants and Subsidies; Federal Grants and Subsidies; Capital from Current (CFC); Funds Secured Under 37, 42 and 45 of the

Planning Act; Donations; Other ( non-development charge

contributions, agreements, etc.); and Debenture Funding.

2.3.3 D The system should manage condition and sustainability information about facility assets and leverage that information to create capital projects, plans and budgets.

2.3.4 D The system should assist in development of a business case for renewal and capital programs.

2.3.5 D The system should assist in proactively managing capital assets renewals.

2.3.6 D The system should support grouping of requirements across facilities and sites to identify opportunities to bundle projects cost effectively, and reduce cost, time, redundancy and impact on ongoing activities.

2.3.7 D The system should support prioritization of projects across the portfolio, and combine projects into multi-year capital plans.

2.3.8 D The system should support prioritization of capital needs relative to one another and with respect to strategy.

2.3.9 D The system should create a consolidated, consistent view of capital needs to facilitate both short-term and long-term planning.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 2.3.10 D The system should support alignment of capital

spending plans with strategy, need and capital availability.

2.3.11 D The system should support definition of requirements at any level in the organization with multi-level cost categories.

2.3.12 D The system should allow definition of single or multi-year projects.

2.3.13 D The system should group and manage multiple capital requirements.

2.3.14 D The system should bundle condition requirements and create work packages for better control, tracking and scheduling

2.3.15 D The system should enable the planning, development and prioritization of facility projects.

2.3.16 D The system should develop accurate maintenance and capital budgets.

2.3.17 D The system should manage current operational requirements, and facility renewal forecasting and capital funding scenarios for capital project planning.

2.3.18 D The system should support definition and justification of capital requests based on ROI, operational impact and strategic relevance.

2.3.19 D The system should employ modeling tools to enable rapid and accurate estimation of the cost of capital asset renewal and replacement.

2.3.20 D The system should easily adjust industry-standard cost and lifecycle data in the models for highly precise renewal and replacement calculations.

2.3.21 D The system should employ modeling tools to allow estimation of system renewal costs and timelines based on a combination of both observed condition and asset age.

2.3.22 D The system should employ cost forecasting and scenario analysis tools to project long-term costs and graphically explore the impact of different funding levels on facility condition and the cost of capital over time.

2.3.23 D The system should generate multi-level financial modeling based on the deferred maintenance backlog, capital renewal and selected time frame.

2.3.24 D The system should be capable of analyzing and projecting funding for time periods up to 50 years.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 2.3.25 D The Solution should have a flexible business

rule component that will allow business rules and or parameter values to be added, removed or changed by the system administrators.

2.3.26 D The Solution should support calculation of Parks Levy Fee (parkland dedication or cash-in-lieu) and other development charges.

Proposed System (Section 2.4) Project Tracking Functional Requirements Req’t # Requirement Text Response Details and Additional

Comments 2.4.1 D The system should track the status of the

projects, including record and monitor milestone dates, project progress and status, procurement details, communication planning, financial tracking, land parcel accumulation tracking, asset inventory and tracking and park levy inventories and summary.

2.4.2 D The system should track inventory, labor and the progress of project execution through its capital planning system

2.4.3 D The system should support the ability to Benchmark Progress, and compare assets across a portfolio or against industry standards.

2.4.4 D The system should support the ability to configure industry-standard benchmarks, such as the Facility Condition Index (FCI).

2.4.5 D The system should allow the definition of critical metrics, such as system condition indices and benchmarks for mission adequacy.

2.4.6 D The system should provide an end-to-end, real-time view of the capital allocation and spending process.

2.4.7 D The system should centralize enterprise-wide capital spend management.

2.4.8 D The system should control capital spending against planned budget in real-time.

2.4.9 D The system should tie requisitions to budget allocations.

2.4.10 D The system should forecast cash flow with monthly and year-to-date forecasts and variances.

2.4.11 D The system should roll-up and track financial data by project.

2.4.12 D The system should reconcile capital plans with actual spending.

2.4.13 D The system should apply fiscal-year controls to multi-year projects.

2.4.14 D The system should manage variances and performance.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed System (Section 2.4) Project Tracking Functional Requirements Req’t # Requirement Text Response Details and Additional

Comments 2.4.15 D The system should generate budget

performance reports.

2.4.16 D The system should forecast cash needs and provide ongoing cost estimates.

2.4.17 D The system should configure and automate project workflow.

2.4.18 D The system should enable real-time flags and alerts based on business rules.

2.4.19 D The system should enable links to council reports, legal documents, surveys, appraisal reports, levy payment receipts etc.

Proposed System (Section 2.5) Mobile Data Collection Functional Requirements Req’t # Requirement Text Response Details and Additional

Comments 2.5.1 D The system should support mobile field data

collection.

2.5.2 D The system should support various asset information collection, including Geographic Information (GIS) data and inspections

2.5.3 D The system should synchronize data via any computer with an internet connection.

Proposed System (Section 2.6) Process Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.6.1 D The System should be capable of scheduling all

City buildings, facilities and physical assets for BCAs at user definable intervals, e.g. once every five years.

2.6.2 D The System should be capable of scheduling the multiple activities for each building, facility or physical asset receiving a BCA: Mechanical inspection; Architectural inspection; and Completion of BCA document.

2.6.3 D The System should be capable defining, storing and scheduling different activity types for each building, facility or physical asset receiving a BCA, as needed in the future.

2.6.4 D The user should be able to manually adjust the BCA schedule.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.6.5 D The System should provide functionality to

automatically move scheduled BCAs if a new one is added, e.g. in emergency situations, a BCA may need to be performed immediately, thus "bumping" every other BCA in the schedule by one slot. This functionality should be optional, i.e. the user should be able to decide whether to "auto-bump" the scheduled BCAs, or manually adjust the schedule.

2.6.6 D The user should be able to update the BCA schedule to indicate when a BCA has been completed.

2.6.7 D The System should record and store the date of all BCAs performed against an asset.

2.6.8 D The user should be able to assign relative inspection priorities to assets as part of the BCA scheduling functionality.

2.6.9 D The System should be capable of storing information relating to responsibilities for performing the following building, facility or physical asset services.

2.6.10 D The System should be capable of defining, storing and scheduling different activity types for each building, facility or physical asset receiving a BCA, as needed in the future: Health & Safety; Legislated; State of Good Repair (SOGR); Service Improvements & Enhancements;

and Growth Related.

2.6.11 D The System should maintain an "event history" for all buildings, facilities or physical assets, e.g. "Installed," "Constructed," "Inspected," "Repaired," "Decommissioned," etc.

2.6.12 D The user should be able to add free-form comments to "event history" records.

2.6.13 D The System should be capable of storing City-defined standard inspection checklists. Refer to Appendix F.7 - Sample Capital Planning Checklist for a sample inspection checklist.

2.6.14 D The System Administrator should be able to create and edit standard inspection checklists.

2.6.15 D The System should have the capability to track available space in a building or facility and plan for its usage.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.6.16 D The System should provide an on-site

assessment capability, e.g. portable computing devices with specific software allowing for capture of BCA information during the inspection, and then some method of linkage to the main System after the BCA inspection process. Any on-site assessment component of the system should be able to store inspection checklists, BCA templates, contact lists and drawings of floor plans or maps, and should be able to provide a "draw" feature so that BCA inspectors can mark-up the floor plans or maps while they are conduction their inspection.

2.6.17 D The system should enable the estimation of project costs based on current market conditions and permit flexibility in costing based on procurement.

2.6.18 D The system should calculate a standard index for building, facility or physical asset condition.

2.6.19 D The system should verify percentage used of the lifespan of building or asset components for facility conditional assessments.

2.6.20 D The system should roll up condition indices to buildings, facilities and physical assets.

2.6.21 D The system should assign component requirement categories. For example life-safety code compliance, building code compliance, functionality, building integrity, appearance, accessibility code compliance.

2.6.22 D The system should use industry standard codes.

2.6.23 D The system should support the ability to upload Building (or Facility) Condition Assessments (BCAs) completed by external contractors

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed System (Section 2.7) Data Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.7.1 D The System should track the following set of

attributes for each building or facility record: ID Name Alternate Name Street Number Street Number Suffix Street Name Postal Code Year of Construction Year of Major Renovation Renovation Comment Field Estimated Year of Disposal Heritage Designation Estimated Year of Disposal District Ward Former Municipality Map # Neighbourhood # Title Service Group Landlord Occupant Classification Strategic Importance Rating Gross Floor Area Replacement Value Contact Name

2.7.2 D The System Administrator should be capable of adding additional attributes to the building or facility record, as needed in future.

2.7.3 D The System should be capable of tracking the following set of core attributes across all capital asset types and components: Asset type; Condition; Manufacturer's life expectancy; Validated life expectancy (initially default to

same as Manufacturer's expected life expectancy, allow for future manual overwrite);

Year of installation; Recommended year of replacement

(calculated field, Year of install + Validated life expectancy);

Size and/or capacity; and Replacement cost.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.7.4 D The System should be capable of defining

custom asset attributes on the basis of asset type, which would exist on the asset record in addition to the core attributes.

2.7.5 D The System should be capable of defining additional asset types for potential future expansions of use (e.g. vehicles, parks and recreation facilities such as playgrounds, pools, trails, pathways, etc.)

2.7.6 D The user should be able to attach document files (e.g. digital images, CAD drawings, digital videos, MS Word files, PDFs, etc) to an asset, building or synopsis sheet record.

2.7.7 D The System should be able to store replacement cost estimates per square foot, based on the classification of the space being replaced (e.g. offices are $215/sq ft, workshops are $195/sq ft, etc).

2.7.8 D The System should be capable of allowing replacement cost estimates to be manually over-written in situations where the Capital Planning resource performing the BCA has knowledge that the System-generated replacement cost estimates are not accurate, e.g. with Heritage buildings.

2.7.9 D The System should be capable of tracking the square footage for multiple different "areas" identified within a building or facility, with the sum of the square footage of all identified areas equalling the gross square footage of the entire building or facility. E.g., a 5000 ft² building might have a 3000 ft² office area, and a 2000 ft² workshop area, and the System should be able to maintain that information.

2.7.10 D The System should be capable of calculating an estimated replacement cost for a building on the basis of the square footage of each area in the building, multiplied by the replacement cost per square foot for each area (which would be based on the usage classification for the given area).

2.7.11 D The System should be capable of employing industry standard benchmarks for determining facility condition, e.g. Facility Condition Index (FCI).

2.7.12 D The System should be capable of integrating with Reed Construction Data's RSMeans for the purposes of providing construction cost estimates.

2.7.13 D The user should be able to manually "over-write" construction cost estimates for a given piece of project work.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.7.14 D The System should maintain a record of the

initial construction cost estimates if manually over-written.

2.7.15 D The System should be capable of generating construction cost estimates based on actual historical costs recorded for similar pieces of work.

2.7.16 D The System should be capable of designating projects as "Capital" if the cost estimates exceed $50,000 and "Operational" for project under $50,000.

2.7.17 D The user should be able to modify the designation of "Operational" projects to "Capital," as some operational projects get included in the capital budget submittal.

2.7.18 D The user should be able to control the number of significant digits displayed by the System when representing dollar values (e.g. $25,500 could be represented as "26" [closest thousand], "25.5" [closest thousand with a decimal], "25,500" [closest dollar], or "25,500.00" [total amount, to the penny]). For different views of cost figures (e.g. 10-year plan cashflows vs. estimates on synopsis sheets) different levels of accuracy will be required.

2.7.19 D The System should maintain multi-year facility lifecycle plans for each building, indicating when planned capital work on its assets is intended to occur. These plans should automatically update whenever deferrals, accelerations, cancellations or changes to funding allocations occur.

2.7.20 D The System should be capable of preserving any City-defined custom fields, attributes, asset classifications or any other data elements, when System upgrades or patches are applied.

2.7.21 D The system should support tracking of immediate and long-term cost liabilities for building or facility component lifecycle renewal, deferred maintenance, code compliance and functional inadequacies based on industry-standard cost databases from RSMeans and expert cost models.

2.7.22 D The system should include a cost estimating system, with costs based upon RSMeans® Unit Costs, including local City Costs Indices. Costs shall automatically update annually.

2.7.23 D The system should generate a Facility Condition Index (FCI) that follows recognized industry standards. The information included in the calculation of the FCI must be adjustable by administrative users.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.7.24 D Cost models should accommodate multiple

formats for reporting. Suggested formats are; RS Means elemental, UNIFORMAT, trades breakdowns, building element breakdown.

2.7.25 D The system should support various baseline standard to establish building component life expectancies, including; BOMA, and ASHRAE.

2.7.26 D The system should accept existing building information.

2.7.27 D Current and historical information should be accessible throughout the life cycle of each capital asset. Existing data from various types of assessments (asbestos, seismic, loss prevention, etc) needs to be recorded in the application.

Proposed System (Section 2.8) Generation of BCA Document Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.8.1 D The System should be capable of storing BCA

reports and logically relating them to the building and/or "event history" records.

2.8.2 D The System should be capable of capturing the following information when creating a BCA report: Survey method and estimating Building Area Building Replacement Cost Building Description Synopsis Sheets for the following

categories of project work: a) Sitework b) Exterior Walls and Structure c) Windows and Exterior Doors d) Roofing e) Interior Finishes f) Elevators g) Barrier Free (e.g. wheelchair access

ramps) h) Environmental i) New construction j) Mechanical Systems k) Electrical Systems l) Security m) Other (e.g. Parks facility data)

Building's 10 year State of Good Repair (SOGR) Plan

Drawings and/or Plans City of Toronto Capital Project Rating

System

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments These different elements should be optional,

that is, not every BCA report will contain all of the above

2.8.3 D The System should be capable of storing and managing "synopsis sheet" objects (synopsis sheets are parts of a BCA report which describe recommended project work identified during a BCA inspection), which can be incorporated into a BCA report, but can also independently represent a "project" in the System.

2.8.4 D The System should be capable of defining additional categories of project work, as required in the future.

2.8.5 D The System should maintain "event history" records for changes made to any BCA component, e.g. if a Capital Planning resource overwrites a default replacement cost estimate, then an "event history" record should be generated, with a free-form comment explaining why the default replacement costs were over-written. This functionality will also be used to track changes to the estimated project cost, in order to understand why a project's final cost, for example, may have changed over time from the amount originally estimated.

2.8.6 D The System should be capable of capturing the following information when populating a synopsis sheet (i.e. when identifying project work during a BCA inspection): Project title Digital media files (e.g. photographs) Requested amount of funding Project location Feasibility study Scope of work Justification Consequences of not approving Project schedule Total project cost estimate, including detailed breakdowns by line item

2.8.7 D The user should be able to define when costs will be shared between more than one business unit for a given piece of project work defined via a synopsis sheet.

2.8.8 D The user should be able to use an existing BCA as the basis for a new BCA, e.g. when a new BCA has occurred for a building that has had a BCA in the past, it would make sense to use the old BCA as the starting point for the new BCA, modifying the sections that need to be modified, and then saving as the new BCA.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.8.9 D The user should be able to use an existing

synopsis sheet as the basis for a new synopsis sheet, e.g. when a piece of roofing work needs to be estimated for one building, the synopsis sheet for a roofing job at another building can be used as a starting point, modified, and then saved as a new synopsis sheet.

2.8.10 D The System should be capable of managing the peer review component of the BCA process (see Appendix F.5 – Building Condition Assessment Process Map for the as-is Building Condition Assessment process) via an electronic workflow.

Proposed System (Section 2.9) Generation of Capital Budget Submission Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.9.1 D For each project defined in the capital plan, the

System should be capable of storing information relating to each of the following: City Budget Guideline Capital Project

Rating System (reason for doing the project, with the options being: Health & Safety, State of Good Repair, Legislated/City Policy, Growth Related or Service Improvement & Enhancement);

Program Influence (drop-down list of as-yet undefined options);

Liability/Risk (drop-down list of as-yet undefined options);

Building Profile (e.g. Core building, Heritage property, etc);

Political Influence (drop-down list of as-yet \ undefined options);

Public Perception (drop-down list of as-yet undefined options); and

Communication Plan.

2.9.2 D The System should have the flexibility to accommodate the prioritization of projects in a capital plan on the basis of City-specific criteria, i.e. not necessarily using industry-standard criteria. Some of the City-specific criteria could include things like the City Budget Guideline Capital Project Rating, Program Influence, Liability/Risk, Political Influence, Building Profile, Public Perception and others. The System should be flexible enough to enable the City to determine what kind of weighting would be applied to the City-specific criteria and how they would play a role in the prioritization exercise.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.9.3 D The user should be capable of manually over-

writing any project's relative priority when the System performs its "auto-prioritizations."

2.9.4 D When a new project is added the capital plan, and assigned a relative priority at the business unit and/or division level, the System should be capable of automatically incrementing the relative priority rating of all lower-priority projects.

2.9.5 D The System should use the response codes defined in Article F.2 (1) to describe how the System will combine two or more capital plans (for example, rolling up business unit level plans into a larger capital plan at the divisional level).

2.9.6 D The System should be capable of analyzing Capital Projects identified in the capital plan for a given year, and prioritize them on the basis of objective industry-standard weighted criteria, while not over-writing any user-defined relative priorities.

2.9.7 D The user should be capable of taking a "snapshot" of a capital plan at any time during the analysis stage, when projects are being moved around and different scenarios are being entertained, in order to facilitate the ability to "go back" to a prior configuration of the capital plan, if necessary.

2.9.8 D The user should be able to identify the set of Capital Projects that will comprise the contents of the formal Capital Budget Submittal from any version of a capital plan.

2.9.9 D The System should be capable of displaying on the screen the running total of the costs for all Capital Projects identified in a given year. If a project is deferred or accelerated, the total should be updated to reflect the change.

2.9.10 D The System should be capable of displaying on the screen the approved budget for the year. This number could be shown alongside the "running total" described in Requirement 2.8.9, with difference between the two numbers also shown.

2.9.11 D The System should be capable of displaying a running sub-total of the costs for all projects currently displayed on the screen. For example, if the list of projects for a given year has been filtered to show only those related to a particular client group, then the sub-total for that client group's projects should be displayed on-screen, alongside the two values described in requirements 2.8.9 and 2.8.10.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.9.12 D The System should have version-tracking

functionality for Capital Budget Submittals.

2.9.13 D The System should be able to track changes to project applicable year cashflows to formally approved Capital Budget Submittals (i.e. after Council has already approved the Capital Budget Submittal for a given year).

2.9.14 D The System should be capable of performing a "roll-over" function at the end of the fiscal year. All future year cashflows must be preserved (i.e. if $40,000 is specified for 2010, then it should stay as $40,000 in 2010 after the "roll-over"), but base project costs should be updated to reflect present-year dollars. For example, if a project is identified in 2008 as costing $10,000, with the entire cashflow occurring in 2009, the project cost would be listed as $10,000 (2008 dollars), with a 2009 cashflow of $10,200, due to 2% escalation (inflation). Once the "roll-over" has occurred, the 2009 cashflow stays at $10,200, but the project cost is no longer $10,000 (2008 dollars). It is now $10,200 (2009 dollars). When "rolling over," all Status 4 projects should be modified to Status 2. See Requirement 2.6.6 for information on project statuses.

Proposed System (Section 2.10) Forecasting Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.10.1 D The System should automatically determine the

impact on future year cashflows when funding allocations change.

2.10.2 D The System should be capable of performing "project levelling" over a user-defined period of time (e.g. five years, ten years, etc.), in order to ensure funding targets are not exceeded for any year within the period.

2.10.3 D The System should identify state of good repair (SOGR) and future funding request impacts created as a result of any automatic "project levelling" it performs.

2.10.4 D The System should be capable of generating multiple different scenarios, based on different decisions regarding capital spending allocations, e.g. the System should be able to illustrate "what if?" for various different potential decisions in real time.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed System (Section 2.10) Forecasting Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.10.5 D The user should be able to save any scenario

generated through the functionality described in Requirement 2.9.4 for future reference. The user should have the ability to use a saved scenario as the basis of a new capital plan.

2.10.6 D The System should be capable of presenting its capital forecasting scenarios on different bases, e.g. by building, by ward, by landlord, by building usage type, etc.

2.10.7 D The System should be capable of generating graphical depictions of overall building state of good repair (SOGR) based on changes to the approved funding envelope.

2.10.8 D The System should be capable of forecasting renewal investment rates required to maintain a building to a pre-defined level of state of good repair (SOGR) over time.

2.10.9 D The System should be capable of tracking the backlog of deferred work.

2.10.10 D The System should be capable of analyzing the backlog of deferred work and identifying its impact on future years' funding requests.

2.10.11 D The user should be able to define an "escalation factor" (rate of inflation) which is automatically applied to future year cashflows, and results in a re-calculation of all associated contingency costs and project management fees (see Capital Planning Requirements - Implementation) against the escalated cashflows.

2.10.12 D The System should "de-escalate" cashflows that have been accelerated (e.g. a cashflow in 2010 is accelerated to 2009), using the escalation factor described in Requirement 2.9.11.

2.10.13 D The System should apply an escalation factor of 0% to pre-approved funds, e.g. if Council approves $100,000 in 2009, and then the work is deferred to 2010, the dollar figure in 2010 should still be $100,000, not an escalated figure.

2.10.14 D The user should be able to define a different "escalation factor" every year, e.g. in 2008, all future, non-approved cashflows were represented with an escalation factor of 2%, but in 2009, all future, non-approved cashflows were represented with an escalation factor of 2.5%.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed System (Section 2.11) Implementation Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.11.1 D The System should allow project work to be

classified against a list of twenty-five (25) project categories.

2.11.2 D The System should be capable of supporting additional project categories in future, beyond those listed in Requirement 2.10.1, if required.

2.11.3 D The System should be capable of supporting project category consolidation, e.g. if two existing categories are "rolled up" into one larger category.

2.11.4 D The System should be capable of capturing the following information for each piece of identified project work: Project Title (mandatory) Project Photographs (optional) Funding Request (total estimated project

cost and year of expenditure) (mandatory) Project Location (mandatory) Feasibility Study (optional) Scope of Work (mandatory) Justification (optional) Consequences of not Approving (optional) Project Schedule (optional) Total Project Budget Cost Estimate (line

item breakdown of Funding Request) (optional)

Shared Costs Breakdown (optional)Site Visit by (name of inspector) (mandatory)

Reviewed by (name of reviewer/validator) (mandatory)

Date (mandatory) Note: “mandatory” and “optional,” in the context of this requirement refer to the optionality of these data attributes in terms of when a user is using the System and populating it with data. They are a not reference to Mandatory Requirements, as described in Article 3.2.9 of this RFP.

2.11.5 D The System should be capable of storing additional information for identified project work in the future, beyond what is listed in Requirement 2.10.4, if required.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.11.6 D The user should be able to assign a status to a

project, including, but not limited to: Status 1: Closed Status 2: Previously approved Status 3: Previously approved with change

in scope Status 4: Proposed new project with yearly

cashflow plan requiring full funding approval Status 5: Proposed new multi-year project

(approval of cashflow in current year only, but not for future years)

Status 6: Proposed new future year project (no cashflow in current year, and funding not approved)

Status 7: Proposed project cashflow no longer required in budget plan (with comments why project deleted)

Status 8: Proposed project cashflow no longer in budget, but may be brought back into plan in the future

2.11.7 D The authorized user should be able to "lock" a project so that the cashflows, and the years they will occur, cannot be altered, deferred or accelerated, except by another authorized user or the System Administrator.

2.11.8 D Only the System Administrator or an authorized user should be able to "unlock" a project that has been "locked" in the manner described in Requirement 2.10.7.

2.11.9 D The System should be capable of grouping multiple sub-projects under one master project.

2.11.10 D The System should be capable of un-grouping a sub-project from its master project.

2.11.11 D The System should be capable of generating "master synopsis sheets" for grouped projects, summarizing the costs associated with each sub-project underneath the master project.

2.11.12 D The System should be capable of defining sub-projects as sequential phases of a master project, which must be carried out in order. If deferrals or accelerations occur, the sequence must be maintained.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.11.13 D The System should be able to make

recommendations regarding the grouping of projects when they are occurring in the same location. For example, if plumbing work and electrical work are identified for one location, then perhaps they should be grouped together, to take advantage of the fact that the walls will be taken down, i.e. it would be inefficient to take the wall down, do the plumbing work, put it back up, and then take it back down a week later when the electrical work happens.

2.11.14 D When deferring or accelerating a sub-project that is grouped with other sub-projects, the System should be capable of prompting the user to defer/accelerate the sub-project only, or defer/accelerate all the grouped sub-projects together.

2.11.15 D The System should be capable of tracking projects at both the master project and sub-project level.

2.11.16 D The user should be able to add free-form comments to "project event" records.

2.11.17 D Project work will not always come into AMS via the BCA process. Users should be capable of defining project work in the System without a BCA, as projects sometimes arrive via divisional work orders, or due to an emergency (e.g. a roof collapsed).

2.11.18 D The System should be capable of identifying which business unit requested or identified a piece of project work.

2.11.19 M The System should be capable of designating a project manager for a given piece of project work, but project work can be identified without a project manager.

2.11.20 D The System should be capable of identifying the client group for a given project or sub-project.

2.11.21 D The System should be capable of calculating contingency costs for projects based on a pre-determined percentage (e.g. 10%) of the estimated project cost. This contingency fee must be re-calculated when/if escalations are applied to project cashflows.

2.11.22 D The System should be capable of calculating project management fees for projects based on a sliding scale methodology.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Additional Comments 2.11.23 D The System should be capable of maintaining

multiple schemes for calculating project management fees, on the basis of the business unit performing the work. E.g. Parks, Forestry & Recreation may use scheme #1 for calculating project management fees, but Toronto Water may use scheme #2, which has a different algorithm.

2.11.24 D The System Administrator should be able to modify the scheme for calculating project management fees.

2.11.25 D The System Administrator should be able to manually over-write an individual project management fee calculation.

2.11.26 D The System should be capable of including multiple contacts: Construction Coordinator, Supervisor, and manager.

Proposed System (Section 2.12) Reporting Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.12.1 D The System should provide a function (including

boolean search functions with support for wildcards) for querying its database.

2.12.2 D The System should provide a full-text search feature (including boolean search functions with support for wildcards) to allow the contents of BCA documents to be searched.

2.12.3 D The System should provide an ad-hoc reporting functionality.

2.12.4 D The System should provide the user with the option of storing an ad-hoc report in the System for future re-use.

2.12.5 D The System should allow for the creation of easily customizable reports.

2.12.6 D The System should be able to output reports to: 2.12.6a D On-screen preview; 2.12.6b D Adobe PDF format; 2.12.6c D Microsoft Word format; 2.12.6d D Microsoft Excel format; 2.12.6e D HTML format; 2.12.6f D Plain text format (e.g. comma-delimited,

fixed width, etc); and

2.12.6g D XML format. 2.12.6h D The City's Mapping software.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed System (Section 2.12) Reporting Requirements Req’t # Requirement Text Response Sign Off, Details and

Additional Comments 2.12.7 D The user should be able to search the System's

database at the capital asset level, e.g. users should be able to search for a particular elevator without first having to navigate from the facility level.

2.12.8 D The user should be able to modify the font size of any report.

2.12.9 D The user should be able to modify the page margins and orientation of any report.

2.12.10 D The user should be able to scale a report in order to help it fit within page boundaries.

2.12.11 D The user should be able to select the paper size for any report, including all standard sizes up to tabloid size (11" × 17").

2.12.12 D The user should be able to use a plotter to print any report, with widths up to 36" supported.

2.12.13 D The user should be able to select the range of months, quarters and years for a given report, e.g. 2011 - 2012, Q1 2013 - Q1 2017, January, 2013 - April 2013, etc.

2.12.14 D The System should be capable of printing reports directly from within itself.

2.12.15 D The System should be capable of generating charts and graphs relating to the data that it manages.

2.12.16 D The System should be capable of scheduling reports to run at user-defined intervals.

2.12.17 D The user should be able to specify the output format of a scheduled report.

2.12.18 D The System should be capable of automatically emailing scheduled reports

2.12.19 D The System should be capable of integrating with Crystal Reports Server XI.

2.12.20 D The system should generate standard and customizable reports that can easily be printed or converted into data files.

2.12.21 D The system should support graphical and tabular reporting mechanisms.

VIE

WIN

G COPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Appendix F.3 – Technical Requirements Compliance Tables

(1) This Appendix contains the Technical Requirements for the AMS Project.

(2) There is both mandatory and non-mandatory Non-Functional Requirements for the AMS Project are mandatory.

(3) The designations "M" or "D" on the requirements tables are detailed below:

Legend Description

D Requirement listed is "Desirable"

M Requirement listed is "Mandatory"

(4) Proponents must respond to the Technical Requirements using one (1) of two (2) possible

responses:



(5) In the Details or Additional Comments, Proponents should respond to the Technical Requirements

using text, charts, tables, graphs, diagrams or any other method required to comprehensively describe how Proponents will satisfy the stated Technical Requirements.

(6) Proponents may respond directly on the form, or, they may simply place a reference In the Details

or Additional Comments to the location in their Proposal where the response is located. (7) Proponents who do not respond “Y” to each and every Mandatory Requirement in this

appendix will have their Proposals declared Informal and will NOT be considered for further evaluation.

(8) Responses with blank or "N" responses will be scored as 'Failure' for Mandatory items

resulting in disqualification. (9) Responses that fully address all elements referred to in the text of the Technical Requirements will

be scored higher. Proponents should ensure that their responses contain the necessary level of detail for the City’s Selection Committee to properly evaluate the quality of the response.

(10) Where a Proponent’s response to a Technical Requirement involves some level of Configuration

and/or Customization, Proponents should provide an estimate of the expected level of effort and costs associated with the Configuration and/or Customization necessary in order to meet a given Non-Functional or Technical Requirement. Proponents should provide information relating to Configuration effort in Schedules D.2 and D.3, Table B – Configuration. Proponents should provide information relating to Customization effort in Schedules D.2 and D.3, Table C – Customization. Failure to include this cost information will result in the City assuming that the Proponent has built such costs into its base price.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


(11) All information technology systems implemented at the City of Toronto should conform to the City's

existing technology standards, and should be capable of operating within the City's existing information technology infrastructure, which is defined in Appendix F.5 – The City’s Existing I&T Infrastructure. However, as the pace that technology changes at continually increases, there is a risk that the content of Appendix F.5 may grow "stale" by the time actual systems implementation occurs, and newer versions of standard products, software and operating systems may be in effect. In such instances, the City is not bound by the older versions quoted in Appendix F.5, and may require any proposed solution to be compatible with the most current version of the City’s existing I&T infrastructure.

(12) The City of Toronto uses a proprietary application called CAPTOR for its capital budget approval process. Proposed Capital Projects are entered into CAPTOR, and then the various stages of approval are reflected within the application. Once the fifth stage has been passed (Council approval), the money is formally "approved" and can now be allocated to next year's capital budget. CAPTOR can produce text-format downloads which reflect what was approved, and for how much. CAPTOR can also accept text-format uploads at the start of the process, reflecting the proposed Capital Projects. Both the upload and download files have the same structure and format. In each instance, three files are required: project.txt, subproject.txt and components.txt. The relationship between these three files is described in Figure 1, shown below. The precise file format information is shown in Appendix F.8 – CAPTOR File Formats.

Figure 1: Relationship between CAPTOR Text Files

Project

e.g. Mechanical

RoofingSecurity

etc

These are like project “types,” although they are called “projects.” Many specific sub-projects belong to

each project.

Sub-Project

e.g.Mechanical – Fix boiler, City Hall

Sub-Project

e.g.Mechanical – Replace furnace, 112 Elizabeth

St

Sub-projects are actual specific

pieces of work that fall under one of the project “categories.” The two examples

shown are Mechanical sub-

projects.

Component

e.g.Mechanical – Fix boiler, City Hall –

Cash flow for salaries

Component

e.g.Mechanical – Replace furnace, 112 Elizabeth

St – Cash flow for contracted services

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Each sub-project has multiple components, which represent how costs are itemized and documented in CAPTOR. CAPTOR has four “parts”: A, B, C and D. Each Part has component codes associated with it that represent some manner of cashflow or cash allocation. For example, above, “cashflow for salaries” corresponds to Part A, component code 01. “Cashflow for contracted services” corresponds to Part A, component code 06. Each sub-project has multiple components under each of Parts A-D. For upload into CAPTOR, a project file must be loaded first, then a sub-project file, and then the components file must be loaded last (see Appendix F.8 – CAPTOR File Formats for detailed information on CAPTOR file formats).

(13) Appendix F.3: Technical Requirements (Sub-Stage 2A-2) represent 200 points out of a total of

1,000 points for all sub-stages. Proposed Solution (Section 3.1) Interface Requirements Req’t # Requirement Text Response Details and Additional

Comments 3.1.1 M The System must be capable of generating text

file outputs, including, but not limited to, files in accordance with the file formats shown in Appendix F.8 - CAPTOR File Formats. Proponents should provide cost estimates for this specific interface effort on Table C – Customization, in Appendix D.2 – Services for the Full Implementation.

3.1.2 M The System must be capable of reading in text files, including, but not limited to, files in accordance with the file formats shown in Appendix F.8 - CAPTOR File Formats. Proponents should indicate whether the interface(s) required to read the file formats specified in Appendix F.8 - CAPTOR File Formats is/are different, or the same as, the interface(s) proposed in response to Requirement 3.1.1. If the Proponent's proposed Solution requires different interfaces for satisfying Requirements 3.1.1 and 3.1.2, then a separate cost estimate should be provided on Table C – Customization, in Appendix D.2 – Services for the Full Implementation.

3.1.3 D Please describe the System's capabilities with respect to performing actions against the data objects (e.g. updating values) it maintains on the basis of information it receives via the text-file interface(s) described in Requirement 3.1.2.

3.1.4 D An authorized user should be capable of selecting where (i.e. destination folder) text file outputs get deposited after being generated by the interface described in Requirement 3.1.1.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed Solution (Section 3.1) Interface Requirements Req’t # Requirement Text Response Details and Additional

Comments 3.1.5 D The City has prepared a reference architecture

for Asset Management and defined the following provider operators and events. Please describe the System's capabilities with respect to performing the following events: Search Asset - Provide a listing of asset

records that match the provided search criteria (e.g., by geographic (proximity, geo-id, coverage), asset classification, asset attributes, or relationship to client/account/work order/case/service request reference provided);

Validate Asset Reference - Provide a valid/invalid determination response for a received Asset Reference Number, or other identifying asset attributes indicating whether or not the reference identifies an existing recognized asset;

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments Get Asset Record - Provide the primary

(e.g., “tombstone”) record for the asset based on the specified Asset Reference Number;

Get Asset Classifications - Provide classifications recorded for an asset identified by the specified Asset Reference Number ;

Record Asset Classification Change - Receive and record a classification change for an asset and record it for the asset along with the provided cross reference to the work order activities that resulted in the asset classification change (details TBD);

Record Asset Configuration Change - Receive and record details of a configuration change (change to a component of an asset) to an asset according to the asset record and apply the details of the configuration change to the asset along with the provided cross reference to the work order activities that resulted in the asset configuration change. (details TBD along with relationship to Record Asset Classification Change operation);

Get Asset Access Requirements - Provide the access or remove from service requirements for the referenced asset (e.g., remove from service request and approval required, In Situ asset access required, No In Situ asset access permitted);

Process Asset Remove From Service Request - Receive and process a remove from service request for an asset and process to determine approval or rejection. Result of approval is provided as published event “Remove From Service Request Approval Result”;

Record Asset Utilization - Receive and record reported utilization of an asset according to the unit types determined from the asset record and/or asset classifications (e.g., for a vehicle, number of kilometers driven) along with cross reference to the work order activities that incurred the utilization.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments Asset Classification Changed - This event is

published whenever a classification change has been recorded against an Asset and identifies the Asset Reference Number for event subscribers.

Asset Configuration Changed - This event is published whenever a configuration change (change to a component of an asset) has been recorded against an Asset and identifies the Asset Reference Number for event subscribers.

Remove From Service Request Approval Result - This event is published whenever a Remove From Service Request has been approved or rejected for an Asset and identifies the Asset Reference Number for event subscribers.

Proposed Solution (Section 3.2) Connectivity Requirements Req’t # Requirement Text Response Details and Additional

Comments 3.2.1 M The System must be accessible from different

physical locations connected to the City of Toronto's internal network.

3.2.2 D The System should be accessible via a web-based Intranet portal.

3.2.3 D The System should be compatible with all versions of Microsoft Internet Explorer from 6.0 onwards.

(1) Any laptops or handhelds used to capture inspection data on-site should not provide any real-

time connectivity to the main application, e.g. via wireless link. There is no requirement for wireless functionality.

Proposed Solution (Section 3.3) Security Requirements Req’t # Requirement Text Response Details and Additional

Comments 3.3.1 M Describe the architectural approach/design

used by the System to manage authorization to business functionality and logical access rights.

3.3.2 M Describe the architectural approach/design used by the System to manage and administer logical access rights.

Proponents should describe if, and how, their System meets Requirements 3.3.3 through 3.3.20.

3.3.3 D The System restricts assignment and revocation of multiple roles for a single user to the System Administrator only.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 3.3.4 D The System restricts the ability to define read

access to the System Administrator only.

3.3.5 D The System restricts the ability to define write access to the System Administrator only.

3.3.6 D The System restricts the ability to define delete access to the System Administrator only.

3.3.7 D The System restricts the ability to define create access to the System Administrator only.

3.3.8 D The System restricts the ability to define update access to the System Administrator only.

3.3.9 D The System restricts the ability to define execute access to the System Administrator only.

3.3.10 D The System restricts the ability to define print access to the System Administrator only.

3.3.11 D The System restricts the ability to define retrieve access to the System Administrator only.

3.3.12 D The System resolves conflicts in access privileges, defined at the resource level, (i.e. if a user's role has different access privileges for a resource and its resource type and/or resource group) by defaulting to the least privilege. For example, if Role A has read/write access to all resources belonging to Resource Group Z, but read-only access to Resource X, which is a part of Resource Group Z, then Role A will have read/write access to every resource in Resource Group Z except for Resource X. Describe the design of this function.

3.3.13 D The System is designed to require the successful entry of an ID/password combination before logical access is granted to business functionality proper.

3.3.14 D The System is designed to allow users to change their passwords as required.

3.3.15 D The System is designed to enforce mandatory password re-entry after a pre-determined period of inactivity.

3.3.16 D The System is designed with a password aging function that restricts re-use of previously used passwords.

3.3.17 D The System will only accept passwords that conform to a passphrase that is a minimum of eight (8) characters long, containing at least: 1 Uppercase alpha character 1 Lowercase alpha character 1 Numeric character 1 Extended ASCII character

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 3.3.18 D The System is designed with an audit log

function. Describe the high-level types/categories of system events logged as part of the native System build.

3.3.19 D Confirmation that the System can be modified to log site-specific events. Describe the types/categories of customizable information and events that can be captured.

3.3.20 D The System is designed with an auto-cleansing function for laptops or handhelds used to capture on-site inspection data. This data is auto-cleansed by the System after, and only after, the data captured during an on-site assessment has first been uploaded to the back-end database. Describe the design of this function.

3.3.21 D The System should confirm, via a message to the user, that information, key-entered on laptops or handheld devices, was successfully uploaded to the back-end database before being auto-cleansed from the device. Describe the design of this function.

3.3.22 D Describe the encryption scheme/approach used by the System to protect data at-rest on client-side devices.

(2) All information technology systems implemented at the City of Toronto should conform to the

City's existing technology standards, and should be capable of operating within the City's existing information technology infrastructure, which is defined in Appendix F.9 – The City’s Existing I&T Infrastructure. However, as the pace that technology changes at continually increases, there is a risk that the content of Appendix F.9 may grow "stale" by the time actual systems implementation occurs, and newer versions of standard products, applications and operating systems may be in effect. In such instances, the City is not bound by the older versions quoted in Appendix F.9, and may require any proposed Solution to be compatible with the most current version of the City’s existing I&T infrastructure.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed Solution (Section 3.4) Infrastructure Requirements Req’t # Requirement Text Response Details and Additional

Comments 3.4.1 M Proponents must provide hardware

infrastructure recommendations to support AMS for three (3) different environments: Development Testing/training Production While not mandatory, Proponents should consider incorporating the following two concepts into their hardware recommendations: Tiered architecture Support for virtualization Infrastructure recommendations should specify the quantity and type of hardware required to support the given infrastructure (including specifications on memory, CPU and disk requirements), as well as any other components that would comprise part of the infrastructure. In addition, Proponents should provide an estimate on the average number of "person-hours" required on a monthly basis to sustain and administer the recommended Production Environment hardware infrastructure.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed Solution (Section 3.4) Infrastructure Requirements Req’t # Requirement Text Response Details and Additional

Comments 3.4.2 M Proponents must demonstrate, using diagrams,

charts, text or any other form of Documentation, that each of the hardware infrastructure recommendations made in response to Requirement 3.4.1 are able to integrate with each of the elements of the City's existing I&T infrastructure listed below, and defined in Appendix F.9 – The City's Existing I&T Infrastructure. If there is no impact to a given element, or if the recommended hardware infrastructures do not apply to a given element, please indicate that. Network Infrastructure Platform Infrastructure: Strategic Network

Operating System (NOS) Platform Infrastructure: Strategic RDBMS Platform Infrastructure: Other Strategic

Products Storage Area Network Storage and High Availability Management Enterprise Backup Unicenter Enterprise Management Corporate Standard Desktop Configuration Corporate Standard Desktop Operating

System Internet Infrastructure: ISP Connection Internet Infrastructure: Security Internet Infrastructure: Public Services Internet Infrastructure: Private Services

(Internal) Internet Infrastructure: Support Services Internet Infrastructure: Standards for Web

Environment Internet Infrastructure: Standards for

Website Development Directory Services

3.4.3 M Proponents must demonstrate, using diagrams, charts, text or any other form of Documentation, that the recommended production infrastructure is scalable and extensible enough to support ten (10) full-featured AMS users ("power-users"), and up to one hundred (185) "end users" AMS users in the first year, and up to an additional thirty (30) "powers users", and six hundred (600) "end users" within three (3) years.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Proposed Solution (Section 3.5) Support Service Requirements Req’t # Requirement Text Response Details and Additional

Comments 3.5.1 M The vendor will provide a range of support

services, which align as close as possible to that outlined in Article 3.2.4.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Table A – Scalability Metric

Metric Name Target Metric Metric Definition

Capital Asset Projects 10x Scale 10 times the projected volume of capital asset projects.

Physical Assets 10x Scale 10 times the projected volume of physical assets.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Table B – Quality Level Metrics

Quality Level Metrics – Response Time Service Objectives/Targets Maximum time to authenticate a user <3 seconds

Mean time to search and display the results for a project <4 seconds

Mean time to search and display the results for an asset <4 seconds

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Appendix F.4 – Non-Functional Requirements Compliance Tables (1) This Appendix contains the Non-Functional Requirements for the AMS Project.

(2) All Non-Functional Requirements for the AMS Project are mandatory.

(3) Proponents must respond to the Non-Functional Requirements using one (1) of two (2) possible

responses:



(4) Mandatory Requirements with blank responses will be treated the same as “N,” which corresponds

to “Proponent does not comply with Mandatory Requirement.”

(5) Mandatory Requirements with responses other than “Y” or “N” will be treated the same as “N,” which corresponds to “Proponent does not comply with Mandatory Requirement.”

(6) Proponents who do not respond “Y” to each and every Mandatory Requirement in this appendix will have their Proposals declared Informal and will NOT be considered for further evaluation.

(7) In the Details or Additional Comments, Proponents should respond to the Non-Functional

Requirements using text, charts, tables, graphs, diagrams or any other method required to comprehensively describe how Proponents will satisfy the stated Non-Functional Requirements.

(8) Proponents may respond directly on the form, or, they may simply place a reference to the location in their Proposal where the response is located.

(9) Responses that fully address all elements referred to in the text of the Non-Functional Requirements will be scored higher. Proponents should ensure that their responses contain the necessary level of detail for the City’s Selection Committee to properly evaluate the quality of the response.

(10) Appendix F.4: Non-Functional Requirements (Sub-Stage 2A-3) represent 250 points out of a total of

1,000 points for all sub-stages.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Experience and Qualifications of the Proponent (Section 4.1) Proponent Project Team and References Req’t # Requirement Text Response Details and Additional

Comments 4.1.1 M Proponents should provide the following

information about all of the firms/companies/sub-Proponents included in the Proponent’s proposal so that the City can evaluate the Proponent’s ability and stability to support the commitments set forth in response to the RFP: How long the company has been in

business? A brief description of the company size

and organization. How long the company has been selling

the proposed software to public and private sector clients?

The number of public and private sector installs of the proposed Solution, as well as the size of each (number of users).

The City, at its option, may require a Proponent to provide additional support and/or clarify the information provided, as part of this evaluation stage.

4.1.2 M Proponents must provide at least three (3) specific client references that are similar in size, nature and complexity to the Solution being proposed. Proponents should submit references for fully completed (live) installations. Proponents must describe the functional breadth of the software Solution for each client reference. Proponents must provide the following information for each of the three (3) references: Date of installation; Length of implementation; Name of client referenced; Description of the project, including the

full scope of services provided to the client (e.g. installation, support, training and/or project management);

Number of years dealing with the client; Name of client project manager; Address; Telephone and fax; and Email address. Reference checks will be performed for Proponents who make the short-list after proposal evaluations are complete. Proponents must not use a City of Toronto reference.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Experience and Qualifications of the Proponent (Section 4.1) Proponent Project Team and References Req’t # Requirement Text Response Details and Additional

Comments 4.1.3 M The Proponent must provide a high-level view of

the proposed team structure for the implementation of the proposed Solution. The team structure should, at a minimum, identify all of the relevant key positions, for example: Project Manager, Solution Architect, Testing Lead, Business Lead and Technical Lead, and their reporting relationships within the team. The provision of further detail beyond these key positions is optional at this stage, and will be required only once a successful Proponent is selected.

4.1.4 M For each position identified in the response to Requirement 7.1.3, Proponents should provide a minimum of two (2) candidates that the City may choose from to work on the implementations. If at any time the successful Proponent wishes to substitute a resource for one of the resources originally proposed, the proposed substitute resource must have similar or greater credentials/experience than the resources originally identified. The allowance for any such proposed substitution will be at the sole discretion of the City, and the City reserves the right to interview the substitute prior to engaging work on this assignment. Proponents must provide individual resumes/CVs for all proposed team members that include the following: Name and proposed role(s) for this

implementation; Total years experience working with asset

management technologies; Relevant education; Summary of pertinent experience and

qualifications; and Number of asset management

implementations, explicit role and duration for each implementation.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Workplan and Deliverables (Section 4.2) Knowledge Transfer Req’t # Requirement Text Response Details and Additional

Comments 4.2.1 M Proponents must describe their proposed

Knowledge Transfer methodology. How do proponents intend to ensure that City staff have the requisite skills and knowledge required to use, maintain and administer the proposed Solution? Responses must be detailed and comprehensive in their scope.

Workplan and Deliverables (Section 4.2) Implementation Plan Req’t # Requirement Text Response Details and Additional

Comments 4.2.1 M Proponents must provide a high-level

implementation plan, which describes the major activities involved in implementing their proposed Solution, including time and resource estimates. Plans that are more detailed, comprehensive and complete will be scored higher. The plan should address the Proponent's approach to implementation issues such as: Overall implementation methodology Installation and configuration of all

software required to form the proposed Solution, including the Development, Testing/Training and Production environments;

User authentication via e-Directory Configuration of the security profile Any Customizations that are required

during implementation, broken down by the number of hours estimated to perform the given Customization. Each piece of Customization should be individually specified.

4.2.2 M As part of the implementation plan, Proponents must provide the following types of test plan in their proposal. Plans that are more detailed, comprehensive and complete will be scored higher: Performance test plan, criteria and

procedures. Integration and system test plan, test

cases and scenarios. Security Testing System QA and product acceptance

procedures. User acceptance testing plan, test cases

and scenarios.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 4.2.3 M The City is looking to the Vendor to provide the

design, development, execution, coordination and management of all testing for the Successful Proponent’s implemented Solution. This includes unit testing, customizations, configurations, and integration of component Products, end-to-end system testing which includes integration to back-end systems, databases, enterprise application integration, user acceptance testing, performance, stress/load testing and penetration testing. (1) Provide a description of your approach for

testing each of the above that describes the basis for conducting the testing (example functional specifications, user acceptance scripts), processes that are followed, quality assurance measures put in place and acceptance procedures.

(2) The City will require the Vendor to develop all required test data in conjunction with the City that will be used for each type of testing. Describe the plan to develop and provide this so that it is reflective of the City’s information. a. Unit testing - to confirm that each

component of the Vendor’s total implemented Asset Management Solution performs as expected.

b. Functional testing - to confirm that the delivered software meets the business and technical functional requirements in this RFP.

c. Performance / Stress / Load testing - to confirm that the delivered software meets the performance and technical requirements such that that the Vendor’s total implemented Asset Management Solution performs its functions/tasks within specific response times under simulated load conditions that reflect the City’s Production Environment conditions.

d. Integration and System testing - to confirm that the delivered software fully performs end-to-end (the hardware, operating system Configuration), and it is successfully integrated within the City of Toronto’s computer network infrastructure and software environment.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments e. Successfully test the file transfer

processes between the Solution and other systems.

f. User acceptance testing / Parallel Testing - to confirm that the Vendor’s total implemented Asset Management Solution will allow AMS to conduct their business on day 1 without any issues/problems. That is, all functionality works as designed and to specifications.

(3) The City is looking for the Successful Proponent to develop all necessary test cases, scenarios and test data which are to be presented and approved by the City. Describe your approach in developing test cases, scenarios and test data.

(4) It is desirable that the Successful Proponent provide dedicated support and a dedicated technical team during user acceptance testing of the implemented proposed Time Asset Management Solution. The rationale for this is to mitigate any delays, reduce effort and time for City resources involved in this activity. Please describe how you will address this requirement.\The City expects that each functional suite/module/component will undergo rigorous testing before being placed into the City’s Production Environment. The Scheduling and Time Entry System will not be accepted until the last functional suite/module/component has undergone this testing and is accepted by the City. Please describe your approach in the situation where there is a staggering of any of the functional modules/components into the City’s Production Environment.

4.2.4 M Proponents must provide a high-level sustainment model, which describes the major activities involved in sustaining/maintaining the Solution, including resource estimates and skill sets.

VIE

WIN

G COPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Workplan and Deliverables (Section 4.3) Knowledge Transfer Req’t # Requirement Text Response Details and Additional

Comments 4.3.1 M Proponents must describe their proposed

Knowledge Transfer methodology. How do proponents intend to ensure that City staff has the requisite skills and knowledge required to use, maintain and administer the proposed Solution? Responses should be detailed and comprehensive in their scope.

Workplan and Deliverables (Section 4.4) Training Req’t # Requirement Text Response Details and Additional

Comments 4.4.1 M Proponents must provide a "power user"

training plan which describes: Any pre-requisite skills/knowledge

required to receive power user training; The content of the power user training

course(s); The number of hours or days required to

complete power user training; The proposed format/method of

delivering power user training; and Refer to Appendices F.6 and F.8 for

Training Requirements for PF&R and EMS.

4.4.2 M Proponents must provide a "end user" training plan which describes: Any pre-requisite skills/knowledge

required to receive end user training;

The content of the end user training course(s);

The number of hours or days required to complete end user training;

The proposed format/method of delivering end user training; and

Refer to Appendices F.6 and F.8 for Training Requirements for PF&R and EMS.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 4.4.3 M Proponents must provide a System

Administrator training plan which describes: Any pre-requisite knowledge/skills

required to receive System Administrator training;

The content of the System Administrator training course(s);

The number of hours or days required to complete System Administrator training;

The proposed format/method of delivering System Administrator training; and


Proponents must also provide an estimate of the average number of "person-hours" that a typical System Administrator would need to devote on a monthly basis to sustaining and administering the proposed Solution.

4.4.4 M Proponents must provide a technical training plan ("technical training" referring to back-end functions such as system maintenance, patch installations, system re-boots, etc) which describes: Any pre-requisite skills/knowledge

required to receive each course within technical training;

The content of the technical training course(s);

The number of hours or days required to complete each technical training course;

The proposed format/method of delivering technical training; and


4.4.5 Proponents must provide a "train-the-trainer" training plan which describes: Any pre-requisite skills/knowledge

required to receive train-the-trainer training; The content of the train-the-trainer training

course(s); The number of hours or days required to

complete train-the-trainer training; The proposed format/method of

delivering train-the-trainer training; and Refer to Appendices F.6 and F.8 for

Training Requirements for PF&R and EMS.

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F



Comments 4.4.6 M Proponents are expected to conduct the

proposed training inside City of Toronto facilities. However, if any of the proposed training will be held outside of City of Toronto facilities, then the preferred Proponent must provide training facilities within the City of Toronto boundaries. If training facilities are not available within the City of Toronto, then Proponents should separately itemize the costs associated with conducting training outside of Toronto (e.g. estimates of airfare and hotel costs per trainee).

VIEW

ING C

OPY

DO NOT S

UBMIT


(AMS) APPENDIX F


Appendix F.5 – The City’s Existing I&T Infrastructure

F.5 – The City’s Existing I&T Infrastructure F.5.1 Introduction

(1) This document describes existing and planned Corporate I&T infrastructure and strategic products.

(2) All new approaches and options provided and proposed should leverage the existing

infrastructure in place as well as planned upgrades and migrations. In addition all solutions should integrate with existing and planned management services.

F.5.2 Data Centre Services

(1) Corporate Information and Technology provides Data Centre facilities and services supporting I&T infrastructure for the I&T division and other City divisions. I&T occupies three Data Centres geographically within the City of Toronto, two of which are owned by the City (Don Mills, Tiffield Road) and the third (Laird Drive) is leased. All three facilities have redundant power, cooling, fire suppression, leak detection and the necessary security in place. This creates a highly available facility with an uptime of 99.9% to house critical network, server and storage infrastructure. These sites have a combined electrical capacity of 380 KVA and 6380 square footage.

(2) All moves, adds and changes that impact the Data Centre are processed through the Data Centre Management group. This internal group sets the standards for the Data Centres and strives to meet the TIA-942 standard. Products that the City has standardized on are Wrightline racks for servers, Cabletalk racks for network equipment and rack mountable intelligent APC power distribution units

F.5.3 Network Infrastructure

(1) CityNet is a single communication utility providing network services for IP based systems. CityNet comprises over 600 network sites, with the core composed around 7 major Civic Centres, the three Corporate Data Centres and 4330 Dufferin (Fire/EMS office). The Data Centres are connected via a 20 Gbps fibre ring. The other major sites are connected via high speed 100 Mbps/1 Gbps/20 Gbps Fast Ethernet/Optical Ethernet Wide Area Network Service.

(2) Remote sites are connected via HDSL or 10/100/1000 Mbps WAN fibre service. Most

WAN connectivity terminates at the communications hubs at the Don Mills and Tiffield Road data centres.

(3) Extranet connections are in place connecting the CityNet to various external organizations

(The Province of Ontario, The TTC, Toronto Police, etc.)

VIEW

ING C

OPY

DO NOT S

UBMIT

REQUEST FOR PROPOSALS: TIME AND ATTENDANCE MANAGEMENT SOLUTION (TAMS) APPENDIX F


CityNet Infrastructure

VIEW

ING C

OPY

DO NOT S

UBMIT

REQUEST FOR PROPOSALS: ASSET MANAGEMENT SOLUTION (AMS) APPENDIX F


F.5.3.1 Internet Services

(1) Internet access is provisioned by our Primary ISP via a dedicated 100 Mbps reserved connection. Current average (monthly) bandwidth utilization is about 90-100 Mbps. Business day usage averages over 90 Mbps. Additional outbound Internet service is handled by a secondary 150 Mbps ISP connection.

(2) Standards based Internet services are also provisioned to support the City's Internet presence.

a) SMTP mail gateways and Ant-Virus and Anti-Spam Scanning b) Domain Name Services (external). c) Domain Name Services (internal). d) Internal NTP Time Services. e) Bluecoat Proxy Caching System. f) Tumbleweed (SSH, FTPS based) File Transfer System. g) Accellion (HTTPS based) File Transfer System.

(3) Internet Services are configured to separate Internal and External networks, with no provision on Internal clients for Internet DNS resolution or direct Internet connectivity. All client applications must be proxy aware to access Internet based services.

F.5.3.2 Security Services

(1) First level protection is provided by a stateful packet filtering firewalls. Security Configurations restrict traffic only to hosts in the DMZ (demilitarized zone) and the firewall. Other than SMTP, DNS, NTP, HTTP, all traffic is limited to outbound only.

(2) Second level protection is provided by another stateful packet filtering firewall. All standard protocols (HTTP, HTTPS, SMTP, DNS, NTP and SSH) are supported along with custom proxies for non-standard protocols.

(3) All internal access to servers in the protected networks are permitted only to authorized personnel by a secure encrypted tunnel via SSH (secure shell).

F5.3.3 Platform Infrastructure

(1) There are approximately 650 corporate mid-range to high-end servers housed in the City's three (Don Mills, Laird Drive, Tiffield Road) Data Centres. The Data Centre facilities all have redundant power, heating / ventilation / air conditioning (HVAC), and security infrastructure.

F.5.3.4 Strategic Network Operating System (NOS)

Network Operating System NOS Version Hardware SUN Solaris V10 or above SUN Microsystems IBM AIX V6.1 or above IBM pSeries Windows 2008 R2 SP1 or above VMware or Intel-based. Dell SLES (Linux) V10.3 or above VMware or Intel-based. Dell Oracle Linux V 5.5 or above Vmware or Intel-based. Dell

(1) All other NOS are considered as non-strategic platform.

F.5.3.5 Intel Server Consolidation/Virtualization

VIEW

ING C

OPY

DO NOT S

UBMIT



(1) The City has adopted a preference for "virtual first" with respect to any new Intel based services being introduced. The only exceptions should be where a virtual server is technically impossible. The City has chosen VMware vSphere ESXi v5.0 (or above) as its Intel Server virtualization platform running on Dell R720 (or above) at all three Data Centres. Vendors responding to RFP's/RFQ's should be prepared to support their submissions on a virtual platform, or be able to provide technical justification of why the proposed solution(s) can NOT run on a virtual platform.

F.5.3.6 Unix Server Consolidation/Virtualization

(1) The Unix server environment similarly adopts a primary virtualization strategy. Oracle Solaris is primarily used in virtualizing our IBM Websphere workloads. These Solaris servers (operating system instances) are provided on large SPARC hardware platforms (i.e. T4's, M5000's) as zones and/or containers.

(2) IBM AIX is primarily used in virtualizing our Oracle RDBMS workloads. These AIX server (operating system instances) requirements are provisioned by hosting them on large p-Series RISC hardware platforms (i.e. p770's) as LPAR's and/or MPAR's. Linux requirements are hosted on the VMWare environment indicated above.

(3) In exceptional cases where virtualization is not practical (i.e. software licensing issues) then stand alone hardware is used. This includes all of our Oracle RAC implementations where we deploy on dedicated non virtualized Oracle SPARC platforms.

F.5.3.7 Endpoint Protection

(1) The City uses Symantec Endpoint Protection (Version 11.6) on Windows Servers. F.5.3.8 Storage Services

(1) The City of Toronto has implemented Storage Area Networks (SAN) providing the levels of performance and availability necessary for Disk and Tape Storage devices to facilitate the mission-critical business operations. The SAN connects servers to the storage devices via multiple Fibre Channel Brocade Silkworm 48000 switches, configured as independent fabric SANs for High Availability.

(2) The Enterprise Storage infrastructure is comprised of over 700TB of disk storage at the three Data Centres, provisioned from the following storage systems:

a) HP XP 12000 & XP 10000 b) HP EVA 8100 & EVA 8400 c) NetApp FAS3140 & FAS3240 d) Centera

F.5.3. 9 Storage and High Availability Management

(1) It is a prerequisite for the City’s High Availability servers to be attached to disk storage over

the SAN utilizing dual Fiber-channel Host Bus Adapters (two physical cards, not two ports on one card) for SAN Path Failover and load balancing.

(2) The standard configuration for dual redundant paths has been implemented on Windows,

SLES 10, Sun Solaris and IBM AIX platforms. For path failover to function, the High Availability servers require multipathing software. Multipath failover solutions vary by platform in terms of implementation.

F.5.3.10 Enterprise Backup

VIEW

ING C

OPY

DO NOT S

UBMIT



(1) All platforms are backed up utilizing the Symantec NetBackup (6.x) solution. The solution is a Client/Server application that backs up data over a private IP network dedicated to high-speed backups. Systems not connected to the private backup network utilize the City’s Internal ‘public’ IP network. The backup window is weekdays from 18:00-7:00 and all weekend (Friday 18:00 – Monday 7:00).

(2) The Symantec NetBackup solution consists of one NetBackup Master server, and six NetBackup media servers that utilize 44 tape drive devices that reside within the following STK tape libraries, distributed at the three Data Centre locations:

a) L180 – Laird Drive b) SL 500 – Tiffield Road c) SL8500 controlled by ACSLS (Automated Cartridge System Library Software) – 703

Don Mills.

(3) The majority of the drives are LTO3 with a throughput of 324 GB/hr and a capacity of 400 GB uncompressed/800 GB compressed data.

(4) All NetBackup servers (Master, Media, ACSLS & BMR) reside on Sun Solaris platforms. The NetBackup client software is installed on all production, and most non-production, server platforms. The primary Master NetBackup server provides backup and recovery services to the majority of the systems at the three Data Centres, as well as a number of geographically remote servers. The primary NetBackup Master's catalog is replicated to DR site, which serves to expedite the recovery process.

(5) Symantec Bare Metal Restore (BMR) server is also part of Backup/Recovery infrastructure.

F.5.3.11 Enterprise Management

(1) The City of Toronto utilizes monitoring, measurement, tracking and reporting technologies

from Hewlett Packard. The product suite called “Business Technology Optimization” (BTO) includes four main technology suite components: Business Service Management, IT Service Management, IT Asset Management, and Configuration Management Database. The City has implemented version 9.x.

(2) Business Service Management (BSM) includes agent based, agentless, and integration solutions for monitoring of Business Services. It does so from the infrastructure level through to potential business impact to consolidate application, system, network, database and business transaction monitoring in order to assist in identifying reactive and proactive measures to help ensure health, performance and availability. Operational views of the business service are used to identify elements which are not operating properly and ensure necessary service staff can be alerted to provide resolution.

(3) Production OS platforms are managed using this technology to set thresholds for platform monitoring schemas to assist in early detection of potential problems to improve availability and enable proactive management

(4) All proposed Business Solutions should integrate into this technology either by using agentless tools to monitor them, or provide integration which interfaces in to the HP BSM solution suite.

(5) IT Service Management is used for the automation of creation and logging of Incident Management, Problem Management, and Change Management tickets, as well as other ITIL/ITSM best practices processes.

VIEW

ING C

OPY

DO NOT S

UBMIT



(6) IT Asset Management is used to discover IP based network objects as assets, track their procurement and life cycle, attach contracts associated with them including maintenance and support agreements, and provide regular auditable reports.

(7) Configuration Management Database (provided by the HP Universal Configuration Management Database – uCMDB) provides a central repository of information from each of these solution components through integration and federation of data.

(8) All proposed solutions should integrate with the HP BTO suite. This will include, but is not limited, to use of necessary protocols to discover and collect information including SNMP, WMI, SSH, SSL.

F.5.3.12 Operations Services (1) The Operations Support group administers the backup/restore tools, optimizes the

environment, and is responsible for ensuring backups are completed on a daily basis. Backup tapes are sent to a secure and temperature controlled offsite facility on a daily basis. Tape Inventory is tracked using SecureSync.

(2) Monitoring of servers and storage that are housed within the three Data Centres is done internally by a manned Control Room that operates 24x7x365. This group is also responsible for paging, problem escalation, restores and batch processing. After hours Service Desk requests are also processed by this team.

F.5.3.13 Directory Services

(1) The City of Toronto has implemented a Directory Service for the automated Identity

Management of computer user accounts. The Directory Service is based on Novell NDS eDirectory 8.8.5.3, Novell Identity Manager 3.5 & 3.61 DirXML technologies running on SUSE Linux Enterprise Server (SLES) 10 .

(2) The directory services environment consists of two separate directory Services.

(3) An external directory service (TOR-TREE) for authenticating outside clients such as citizens, businesses and other levels of government. The external directory service is used for the authentication to the City of Toronto Internet Web site to access secure, personalized Web services.

(4) An internal directory service (COT-IDENT-TREE) is used to manage approximately 27,000 computer accounts for all staff and non-staff that require access to City of Toronto computing resources.

(5) The COT-IDENT-TREE is a meta-directory hub and uses Novell Identity Manager connectors to provide complete automated management of associated userids in other connected computer environments. The directory service currently connects to and manages users in:

a) COT_TREE – the NDS file and print infrastructure b) Novell GroupWise - the corporate email system c) AD – the Active Directory environment which consists of 6 separate domains d) Oracle Internet Directory / TCHIS e) Solaris, Linux, and AIX systems

(6) The directory is updated bi-weekly with current SAP data using a flat file import into the directory. All modifications to user accounts are automatically synchronized to all

VIEW

ING C

OPY

DO NOT S

UBMIT



connected systems. The SAP HR system is used as the authoritative source of organizational and employment status information for City employees and this information is used to create / disable / modify employee userids in COT-IDENT-TREE.

(7) The internal directory service is responsible for enforcing consistent user policies for 27,000 identities across multiple environments. Policies such as the minimum password length and the password expiration interval are set centrally in COT-IDENT-TREE and automatically propagated out to the other connected environments. Additionally passwords are synchronized and disabling a user account in the COT-IDENT-TREE will immediately disable their access in connected systems.

(8) The directory also provides a high availability LDAP v3 service for the LDAP authentication of internal web applications.

(9) Any new corporate applications should provide a connection to the directory service for user authentication and account management.

F.5.3.14 Active Directory (1) The City of Toronto's enterprise Active Directory is mainly used for user management,

authentication, authorization and computer management for Microsoft based computers. It is a single forest directory containing an empty root domain and 6 child domains. Each domain represents a service cluster. There are a total of 26 domain controllers in various locations across the City's network. All domain controllers are running Windows 2008 R2.

(2) Provisioning of accounts and password management is managed in the City's Meta Directory (eDirectory) and synchronized with Active Directory. Group membership and AD specific attributes and configurations are managed within AD and not synchronized with eDirectory.

F.5.3.15 File Services

(1) The City provisions end user networked file services using Novell SLES/OES2. Servers

are organized into two separate eDirectory trees for organization purposes, one for general city usage (COT_TREE) and one for council (CNL_TREE). Replication is enabled with the City's eDirectory Meta Directory. All primary systems are deployed in 3 or 4 node clusters to provide high availability of hosted resources, mainly the network accessible volumes.

(2) COT_TREE consists of 50 TB of data in one 4-node cluster, six 3-node clusters and 17 standalone systems (36 systems total). In total, 100 volumes are hosted in clusters, and 62 are locally mounted on standalone servers.

(3) CNL_TREE consists of 10 TB of data in one 4-node cluster and one standalone system. Four NSS volumes are hosted on the cluster.

F.5.3.16 3rd Party Software (1) The 3rd party software used on the file system servers are McAfee Anti-virus, Symantec

Netbackup, Bluelance LT Auditor, CA Unicenter/HP BSM.

F.5.3.17 Desktops and Login Scripts

(1) Users login using Windows XP desktops across the city to access their files on the network drives. Each desktop has the Novell client installed and integrates login authentication with eDirectory credentials. The Novell client utilizes the NCP protocol to communicate with

VIEW

ING C

OPY

DO NOT S

UBMIT



Netware servers and NSS volumes for file transactions. Upon login, the Novell client has a login script that automatically maps certain drive letters (G, H, I, J, K, L) to specified NSS volumes depending on the user's context within eDirectory. This behavior is the same across both COT TREE and CNL TREE.

F.5.3.18 Desktop Environment

(1) The City's minimum installed configuration for a desktop Computer is:

a) 3 Ghz Core 2 Duo Processor b) 2 GB memory c) 80 GB Disk d) Integrated Video Controller e) Integrated 10/100/1000 network Interface f) 17" LCD monitor

(2) The City's minimum standard configuration for a mobile Computer is:

a) 1.6 GHz mobile Processor b) 1 GB memory c) 80 GB Disk d) Integrated Video Controller e) Integrated 10/100/1000 network Interface f) integrated 12.1" display

(3) Mobile and desktop computers are replaced on a 4 & 5 year lifecycle respectively, with

current hardware specifications. In 2010 new desktop deployments utilize Intel i5 processors, 4 GB memory, 250 GB disk, 19" LCD monitors. New mobile deployments are configured with Intel i3 processors, 4 GB memory, 120 GB disk.

(4) The City's current desktop operating system is Windows XP Professional SP3. The City will begin deploying Windows 7 in 2012. All proposed desktop software must be Windows 7 compatible.

(5) The standard productivity environment includes: Novell Network Client; Symantec Anti-Virus; CA Unicenter agents; Microsoft Office, Project and Visio 2007, Microsoft Internet Explorer 6.0*; Windows Media Player; Novell GroupWise messaging; Adobe Flash Player; Acrobat Reader and Writer 9; Sun Java; Microsoft .NET Framework.

(6) *The City will upgrade most Divisions to Internet Explorer 8 in 2011.

F.5.3.19 Enterprise Desktop Management

(1) The City of Toronto has implemented Computer Associates' IT Client Manager R12.5 Desktop Management Suite used in the management of desktop and mobile computers. The software suite is running on Windows 2008 R2 servers and contains the following main components:

(2) Software Delivery – Centralized management of installing, reinstalling, configuring, and uninstalling software

(3) Remote Control – Access, control, manage and modify remote servers, desktops and mobile systems.

VIEW

ING C

OPY

DO NOT S

UBMIT



(4) The City uses Symantec Endpoint Protection (Version 11.6) on Mac and Windows Computers to protect against virus and malware attacks.

(5) The City is currently implementing Symantec Endpoint Encryption and Symantec Endpoint Protection (Device and Application control) on all mobile computers.

F.5.3.20 Enterprise Printing

(1) The City of Toronto has over 2,500 Network and local printers. Most network printers can be reached via normal Windows driver, Novell NDPS or line printer daemon (lpd) printer management protocol. The bulk of these printers will support PCL5 or Postscript Level 2 output print protocols. The City is consolidating some workgroup printers into Multi-Function Devices.

(2) High Volume and Specialty Media printing is supported at Civic Centre Copy Centres supported by the Clerks Division Information Production units. City Hall supports three Oce Digital Presses, Metro Hall two, and North York, Scarborough and Etobicoke have one unit each. MICR cheque printing is supported by two HP/Troy MICR 4050 printers.

(3) Specialty media, high volume, and SAP originated printing is managed through an InfoPrint Manager [IPM] version 4.3 system, running under AIX 6.1 server technology. This system directly manages and formats print to about 800 network printers, MICR printers, and to the Oce Digital network in the Copy Centres controlled by Information Production. IPM also provides the Output Management System [OMS] interface to SAP, as well as XMI-enable call back daemons for managing SAP printing sessions in real-time.

(4) IPM can take traffic from other City workstation and server systems via a number of methods:

a) lpd protocol [including mainframe CA-Spool/VPS traffic] b) pdpr command line software for Windows, and UNIX [HPUX, AIX, Solaris and Linux] c) The IPSelect print port management service for Windows d) A City developed Java-class interface for Java programmers

(5) Print document formatting under IPM is handled by our PDFlib [Version 8.0] xml2PDF transform engine, combined with our PDF format wrapper technology. Application data [ASCII, PCLx, or other datastreams] is converted into XML for dynamic composing to PDF version 1.4 and above, using PDF templates and font embedding libraries.

(6) The PDF format wrapper, PDFlib facility, HTMLDoc, GraphicsMagick, and Ghostscript document transform and formatting engines are all available to other City systems, applications and servers via SSH2 compatible gateways.

F.5.4 Strategic Products

F.5.4.1 RDBMS

(1) The City's RDBMS platform for Business Critical and 24/7 applications is Oracle Enterprise and Standard Server editions (Version 11g Release 2) on a supported Unix based OS. The strategic high availability solution for Oracle databases is Oracle Real Application Cluster (RAC). In total, the City has 200 Database instances deployed on 69 servers.

(2) Microsoft SQL Server (2008 or above) is also supported for non business critical applications. There are approximately 20 Corporately managed SQL Server Databases.

VIEW

ING C

OPY

DO NOT S

UBMIT



(3) All other RDBMS products are considered to be non-strategic platforms.

F.5.4.2 Messaging

(1) The City uses Novell GroupWise 8 collaboration software solution for email, calendaring, task management and group scheduling for over 21,000 users. The environment is comprised of 28 post offices and 3 gateways running on 36 SUSE Linux Enterprise Server (SLES) 10 servers in 7 clusters with a total of 5.5 TB of storage. Every month 7.5 million internal messages are delivered, 2.5 million messages are sent to the Internet and 1.5 million received.

(2) The City plans to upgrade post offices and core infrastructure to GroupWise 2012 by Q12013. The desktop clients will be updated to Groupwise 2012 as part of the City's regular desktop lifecycle refresh.

(3) For email archiving and ediscovery the City uses SilverDane Archive Enterprise Edition for GroupWise.

F.5.4.3 Fax

(1) The City employs XMedius Fax v6.5.5 VOip fax server solution for centralized fax services. The system encompasses a primary and backup fax server and a dedicated rasterizer to manage 150 direct inbound numbers and one thousand users utilizing the desktop, web and SMTP clients.

F.5.4.4 Thin Client

(1) Citrix XenApp 6 provides desktop and business applications to remote access and Extranet users. A total of 20 servers host 30 core enterprise applications for 2300 users.

F.5.4.5 Report and Document Presentation

(1) The City utilizes ViewDirect for Networks v4.2 for document management and archiving of documents from legacy systems Client software. The environment contains 50 document repositories containing 500 GB of documents for 500 clients.

(2) ViewDirect will be upgraded to version 4.4 in Q4 2012.

(3) DocumentDirect for the Internet Is used for client presentation.

F.5.4.6 Web Application Environment

(1) The City supports internally developed and commercially supported J2EE applications in two independent and segregated web application environments for internal Intranet and public Internet use respectively. The environments are based on IBM WebSphere Application Server Network Deployment (version 6.1and 8.0) on Solaris 10 with applications deployed in 2-node clusters. Separate systems host IBM HTTP Server (version 8) instances on Solaris 10 configured with WebSphere plugins for forwarding of requests to application clusters.

(2) WebSphere Portal (version 7), Vignette Content Management (version 8.1), Lotus Domino (version 8.5.2) and Google Search Appliance (version 6.8) are also deployed into these environments.

VIEW

ING C

OPY

DO NOT S

UBMIT



(3) All primary Web based services are deployed minimally in 2-node configurations for High Availability and clustered via F5 BigIP Local Traffic Managers.

F.5.4.7 Enterprise Application Integration Platform

(1) The City uses Software AG WebMethods Broker (Version 8.2) and Integration Server (Version 8.2) as its common Enterprise Application Integration (EAI) platform. MyWebMethodsServer (Version 8.2) is used for administration and monitoring.

F.5.4.8 Telecom Platform

(1) The City of Toronto is currently contracted with Bell Canada under a five-year Large Organization Centrex (LOC) contract which is designed to work in a large multi-location, multi-wire environment served from 3 Bell Canada Digital Multiplex Systems (DMS) 100 central switches, incorporating 27,250 + subscribers across 1,400+ locations.

VIEW

ING C

OPY

DO NOT S

UBMIT



(2) Voice mail/messaging services are linked to the Centrex service utilizing four (4) City owned Octel voice mail servers (1 Octel 250 at Don Mills, 2 Octel 350 at Metro Hall, and 1 Octel 350 at City Hall). These voice mail servers are fully integrated with the Bell Canada DMS. The mailboxes (15,550) are managed by the assignment of dedicated ports from the four servers for 15,000+ users. This includes voice-enhanced call processing applications, auto attendant and forms applications for City Divisions and other Agencies, Boards and Commissions.

(3) The City also owns and uses one Call Centre Platform CCMIS (Call Centre Management Information Server) supporting 84 Queues and 964 Call Centre Agents all incorporated in one Bell Canada DMS 100. CCMIS is a tool for managing the Agents who handle ACD (Automatic Call Distribution) calls. It helps supervisors plan, manage, and monitor their ACD operation by collecting statistics on the performance of equipment and personnel.

(4) Voice Mail and Call Centre Servers include applications for Animal Services, Children Services, Court Services, Economic Development, Culture, Emergency Medical Services, Fire, Homes for the Aged, Human Resources, Legal, Municipal Licensing and Standards, Parks, Forestry and Recreation, Public Health, Revenue (Meter Reading), Shelter, Support & Housing Administration, Social Service Assistance, Solid Waste Management, Transportation Services, Toronto Water, and Tourism.

(5) All moves, adds and changes are processed with the Service Provider through the Voice Infrastructure Group. Internal software changes such as telephone number changes, internal moves, changes to long distance capability, forwarding and name changes are done internally. Voice Mail adds, moves and changes are also done internally.

(6) The City has started implementation of a Cisco based VOIP solution to replace the majority of Centrex lines.

VIEW

ING C

OPY

DO NOT S

UBMIT



Appendix F.6 - PF&R Implementation Requirements (1) This Appendix contains the Installation, Configuration and Implementation (ICIS), Migration,

Integration and Training Services for the Parks, Forestry and Recreation Division.

(2) Please note that the “Details and Additional Comments” section to the far right of each requirement is provided to allow Proponents space to provide detailed information on how the Vendor will meet PF&R's implementation requirements. Proponents may use this space to provide a reference to the body of their Proposal where the details and additional comments may be found, or it may be filled in directly.

(3) Appendix F.6: PF&R Implementation Requirements (Sub-Stage 2A-4) represent 200 points out of a total of 1,000 points for all sub-stages.

PF&R Implementation Requirements (Section 6.1)

Req’t # Requirement Text Details and Additional Comments

6.1.1 For the pilot, PF&R estimates about 200 AMS users made up of: 6.1.1a 185 End Users for mobile field data collection inspections

and assessments for assets, Project status tracking and reports

6.1.1b 10 Power Users for asset project prioritization and capital planning;

6.1.1c 4 system administrators; 6.1.2 PF&R estimates about: 6.1.2b 5,000 assets; 6.1.2a 11,000 projects; and 6.1.2b 70 unique business rules. 6.1.3 In consultation with PF&R, the Vendor will define a phased

rollout schedule for the Solution.

6.1.4 In consultation with PF&R, the Vendor will define the appropriate period for monitored deployment support. A minimum period of three months is expected.

6.1.5 In partnership with the City, the Vendor will provide business support between the hours of 8:00 AM and 5:00 PM, Monday to Friday.

PF&R Interface Requirements (Section 6.2)Req’t # Requirement Text Details and Additional

Comments 6.2.1 The Vendor will provide the mechanism to manually and

automatically bulk transfer upload and download data capability to AMS.

6.2.2 The Vendor will configure to extract, transfer and load data with the following City systems:

6.2.2a The Vendor will configure the Solution to interface with CAPTOR and batch transfer proposed capital project information to CAPTOR and to import approved capital project information from CAPTOR;

6.2.2b The Vendor will configure the Solution to batch update from external systems, like RS Means.

VIEW

ING C

OPY

DO NOT S

UBMIT



Data Migration Requirements – PF&R (Section 6.3) Req’t # Requirement Text Details and Additional

Comments 6.3.1 The Vendor will work with the City to validate data mapping of

Solution with other external systems, including: CAMP, CLEAN, SAP – PM / RE.

PF&R Training Requirements (Section 6.4) Req’t # Requirement Text Details and Additional

Comments 6.4.1 The Vendor will develop PFR-specific training materials for both

Computer-based and instructor-led, classroom training:

6.4.1a End-User 6.4.1b Power User 6.4.2 The Vendor will provide two (2) sessions of train-the-trainer

classroom training for a total of 24 end users.

6.4.3 The Vendor will provide one (1) session of classroom training for a total of 10 power users.

VIEW

ING C

OPY

DO NOT S

UBMIT

REQUEST FOR PROPOSALS: ASSET MANAGEMENT SOLUTION (AMS) APPENDIX G


APPENDIX G ESCROW PROVISIONS (1) At the time of signing the Agreement, or at a time agreed between the parties, Licensor shall

deposit an enabled source code version of the Software with all necessary passwords, software keys, or authorization strings (the “Source Code”) with the escrow holder (the “Escrow Holder’). Licensor shall update the Source Code with all new releases and updates and with any bug fixes or workarounds provided to Licensee. The annual escrow fees shall be borne entirely by Licensee. The escrow agreement for the Source Code deposit shall name Licensee as beneficiary and at a minimum shall provide for the release of the Source Code to Licensee upon the occurrence of any of the following release conditions (“Release Conditions”):

a) Any dissolution or liquidation proceeding is commenced by or against Licensor, and if such

case or proceeding is not commenced by Licensor, it is not dismissed within sixty (60) days from the filing thereof; or

b) Licensor becomes insolvent or admits its inability to or fails to pay its debts generally as they

become due; if any proceedings are commenced or taken for the dissolution, liquidation or winding up of Licensor; or if a trustee, custodian or other person with similar powers is appointed in respect of Licensor or in respect of all or a substantial portion of its property or assets; or if Licensor ceases to carry on all or substantially all of its business; or if any proceedings involving Licensor involving its bankruptcy or insolvency are taken under any legislation dealing with insolvency are taken under any legislation dealing with creditor’s rights; or Licensor makes any assignment or proposal in bankruptcy or any other assignment or proposal for the benefit of creditors, or

c) Licensor is in breach of its obligations:

i) To provide support in accordance with this Agreement, or ii) To provide the Software to Licensee without infringing a third party’s intellectual

property rights, Licensor shall have a thirty (30) day cure period to rectify any of the foregoing Release Conditions after the receipt of a written notice from Licensee. Where there is a dispute regarding the existence or occurrence of a triggering event for a Release Condition, the Software shall be immediately released to Licensee, and the parties shall resolve any dispute as to the existence of the conditions required to release the escrow material in accordance with the dispute resolution provisions of the Agreement.

(2) Upon the release of the Source Code to Licensee, Licensee shall only use the Source Code in

accordance with this Agreement and shall only use the Source Code internally or with Users for the purpose of providing maintenance, and support for, or to add functionality to the Software. Subject to the terms and conditions of this Agreement, Licensee’s contractors shall have the same limited rights to use the Source Code as are granted to Licensee under this Section, provided that no more than three unrelated contractors will be utilizing the Source Code simultaneously. All contractors shall comply with the terms and conditions of this Agreement when working with or assessing the Source Code.

(3) Licensor represents, warrants and covenants that the Source Code, and all new releases, updates,

bug fixes and workarounds deposited into escrow shall include all documentation and materials necessary for a competent programmer to compile, verify, maintain, and support the Source Code, and all without undue effort, and that no Licensor proprietary software is required to maintain and support the Source Code.

(4) Licensor shall, upon notice from Licensee, carry out such tasks in order to verify that the escrowed

materials are complete and functional and shall provide written proof of such verification to Licensee.

VIEW

ING C

OPY

DO NOT S

UBMIT

REQUEST FOR PROPOSALS: ASSET MANAGEMENT SOLUTION (AMS) APPENDIX H


APPENDIX H SAMPLE LOGICAL DATA MODELS

The City has prepared a Logical Asset Data Architecture, and has attached three sections (highlighted in bold): H.1 Asset (sample) H.2 Asset Role (sample) H.3 Asset Contact Mechanism (sample) H.4 Asset Location (sample) H.5 Asset Classification & Characteristics (Abstract) (sample) H.6 Asset Classification & Characteristics (Specific) (sample) H.7 Asset Component & Feature (sample) H.8 Lifecycle Event (sample) H.9 Condition Assessment (sample) H.10 Index Measurement (sample) H.11 Project Type & Funding (sample) H.12 Project Party & Contact Mechanism (sample) H.13 Project Location (sample) H.14 Construction Project - Project Tracking (sample) H.15 Development Project - Project Tracking (sample) H.16 Parks Project (sample) H.17 Document & Record Management (sample)

VIEW

ING C

OPY

DO NOT S

UBMIT



H.1 Asset (sample)

VIEW

ING C

OPY

DO NOT S

UBMIT



H.6 Asset Classification & Characteristics (Specific) (sample)

VIEW

ING C

OPY

DO NOT S

UBMIT



H.7 Asset Component & Feature (sample)

VIEW

ING C

OPY

DO NOT S

UBMIT