THE METROPOLITAN WATER DISTRICT
OF SOUTHERN CALIFORNIA
Amendment No. 2
Request for Proposal for
TELEPHONE SYSTEM REPLACEMENT PROJECT
RFP No. 856
To all prospective respondents to Request for Proposal (RFP) No. 856, for which Proposals are to be received by The Metropolitan Water District of Southern California (Metropolitan), at its Union Station Offices, 700 North Alameda, Fifth Floor, Room 5-113, Los Angeles, California 90012, until 3:00 p.m. (PDT), July 7, 2008.
I. The information given in Amendment No. 2 are official revisions and responses to questions submitted by prospective respondents for clarification, and are hereinafter incorporated into RFP No. 856.
Page 2 – Minimum Requirement (1.3), revised as follows:
Revised From:
“Further, the Respondent must be fully certified by the manufacturer at the highest dealer certification level (e.g., Platinum, Gold, Elite, Premier etc) at the time of the RFP response submittal date of June 5, 2008 and for the entire duration of the Telephone System Replacement Project…”
Revised To:
Further, the Respondent must be fully certified by the manufacturer at the highest dealer certification level (e.g., Platinum, Gold, Elite, Premier etc) at the time of the RFP response submittal date of July 7, 2008 and for the entire duration of the Telephone System Replacement Project.
Page 4 – Request for Clarification
Revised to provide an additional clarification date as follows:
· Respondents may ask additional questions for clarification until
Saturday, June 14, 2008, 3:00 p.m. PDT.
Page 14 – Critical Communication Application illustration
Revised to reflect Jensen and Medium sites to have redundant call controller and ACD/Call Management to Lake Mathews and E911 System to Union Station. See revised illustration attached on page 44.
Page 21 – Call Center Capabilities (1.3), revised as follows:
Revised From:
Call Center Agent Capabilities: The following section identifies the call center agent functionality that the Respondent is required to provide with the proposed solution:
1. Agent log-ins to queue and skill sets using a unique agent ID
2. Manual, Automatic, and Forced Agent Answer
3. Calls waiting, longest call in queue and other real-time split info displayed on the agent phone or on the agent desktop (“dashboard’)
4. Separate call handling treatment for DID and ACD Calls
5. Wireless Headset Compatibility
6. Multiple ACD Groups/Skills per agent (Agent can support more than one ACD group or skill simultaneously)
7. Priority call handling
Virtual or Mobile Agent - Agent can log-in to any telephone and their agent properties will automatically apply
Supervisor Assistance – Agent can contact Supervisor for assistance by pressing a one button while engaged on a call
Remote Agents using soft client application at their home or remote site can “log in” to their ACD split and receive calls.
Revised To (correct numbering scheme):
Call Center Agent Capabilities: The following section identifies the call center agent functionality that the Respondent is required to provide with the proposed solution:
1. Agent log-ins to queue and skill sets using a unique agent ID
2. Manual, Automatic, and Forced Agent Answer
3. Calls waiting, longest call in queue and other real-time split info displayed on the agent phone or on the agent desktop (“dashboard’)
4. Separate call handling treatment for DID and ACD Calls
5. Wireless Headset Compatibility
6. Multiple ACD Groups/Skills per agent (Agent can support more than one ACD group or skill simultaneously)
7. Priority call handling
8. Virtual or Mobile Agent - Agent can log-in to any telephone and their agent properties will automatically apply
9. Supervisor Assistance – Agent can contact Supervisor for assistance by pressing a one button while engaged on a call
10. Remote Agents using soft client application at their home or remote site can “log in” to their ACD split and receive calls.
Page 25 – Call Center Capabilities (2.12.7), revised as follows:
Revised From:
5. All Metropolitan personnel on the new Unified Messaging platform must be able to access their messages, leave messages, create distribution lists, receive notification of message delivery, and use the system's features from either local/remote telephones or local/remote PC devices.
Revised To:
5. All Metropolitan personnel on the new Unified Messaging platform must be able to access their messages, leave messages, create distribution lists, receive automatic notification of message delivery via a message waiting indicator on IP Phones and audible tone on phones without waiting indicator lights, and use the system's features from either local/remote telephones or local/remote PC devices.
Page 54 – 4.2 Submittal, revised as follows:
Revised From:
“1 CD containing the proposal in a single file PDF Format”
Revised To:
“1 CD containing the proposal in PDF format and all attachments in separate files in their native format (e.g., Excel)”
Attachment D – MWD VOIP RFP Systems and Services Summary
Revised to include the following:
Jensen Filtration and Medium Sites shall have a redundant call processing server for high reliability.
II. Questions asked and answers given:
Q1. Is it ok for us to convert this into Word format?
A1. No, Respondent must use Attachment F.
Q2. Section 4.3, item 4, lists the items and order for a vendor's response. We can certainly do this and follow the sequence of the sub-items A through S, but would you like all the other sections included in our RFP response also, maybe with an acknowledgement of each section, e.g., "Understands", "Understands and complies", etc.?
A2. Please respond as requested in the RFP.
Q3. For the medium sites you have specified you want an LSP on page 13 and in the drawing on page 14, but on page 33 you specify it as a high reliability system. Please confirm which is correct.
A3. To clarify, "Medium" sites and Jensen Filtration shall have IPT Systems designed with High Reliability functionality. Addendum No. 2 will reflect this clarification.
Q4. UPS on page 31 section 2.12.14 you ask us to leverage new battery plants at many locations. Can you specify which locations are capable of being leveraged? If you show that the site is currently "equipped" with the same UPS as you are specifying can we assume that we can leverage it? Can you provide more info on currently "equipped" if we will need to decide if we can leverage the current system?
A4. While new battery plants may exist at various Metropolitan facilities (and in the course of implementation leveraged as appropriate wherever possible), for your RFP response, please configure your system designs to assume new UPS units will provided at each site by the Respondent as specified by the RFP. All costs for the new UPS equipment (including labor and maintenance) must be included in Attachment A.
Q5. You are requesting the re-use of the current call accounting system. Is the connection a Serial or IP connection?
A5. All Siemens PBX systems have a Pollcat buffer box that connects to the telephone system via a SMIOC (System Monitor Input/Output Card) port for the collection of call records at that site. This SMIOC connection between the PBX and call accounting system or Pollcat device is made via an RS-232 cable (serial connection). The call detail records collected in the Pollcat device are then transmitted over the WAN (IP) to the call accounting server located at Union Station. Today, the following Metropolitan locations have Pollcat devices installed and operational:
Union Station
Mills
Mathews
Jensen
Diemer
Diamond Valley Lake
Sacramento
Skinner
Hinds
Iron Mtn.
Gene Camp
Eagle Rock
Soto
Weymouth
Q6. Page 11 states that Metropolitan is networked via CoreNet software. Are you referring to Siemens proprietary protocol called CoreNet IP?
A6. Yes.
Q7. It is mentioned in the RFP that you will be ordering the network services. [Respondent] actually provides network service analysis and ordering of the lines, T1”s, MPLS network etc. Will you be issuing an RFP for this part of it? If not how can we become engaged in bidding on the network services?
A7. Please refer to the scope of work to determine if the services as listed are services that your firm would provide.
Q8. We would like for our refurb department to bid on the buyback but we need an inventory of what you currently have. Can this be provided as an addendum?
A8. At this time, Metropolitan Telecomm team is developing a detailed inventory of existing Siemens/Rolm system and station equipment. It is anticipated that this inventory will be completed and distributed to the Respondents no later than June 20, 2008.
Q9. Is this RFP written for a specific phone system i.e. 3Com or Cisco? If it is will other Vendors still be considered?
A9. Metropolitan is interested in reviewing all proposed solutions with the intent of selecting the best possible system based on the criteria established in the RFP.
Q10. Will you consider using the telephony manufacturer’s unified messaging platform as the voice store, rather than Microsoft Exchange 2007 for this purpose, if all other Unified Messaging requirements can be met?
A10. Please respond indicating your ability to comply with this RFP requirement.
Q11. Will you consider using the telephony manufacturer’s Unified Messaging platform as the message store if the vendor shows evidence that using Microsoft Exchange as a message store is unreliable?
A11. Please respond indicating your ability to comply with this RFP requirement.
Q12. Will you consider using the telephony manufacturer’s Unified Messaging platform if it can be shown that it is more reliable, resilient, highly available, and energy efficient than Microsoft Exchange server approach?
A12. Please respond indicating your ability to comply with this RFP requirement.
Q13. What is Metropolitan’s Business Continuity Strategy for a reliable, resilient, highly available Unified Messaging platform?
A13. UM has not yet been deployed. As such, Metropolitan has no formal UM Business Continuity Strategy statement at this time. Metropolitan is interested in understanding the system uptime metrics (e.g., Mean Time to Failure and Mean Time to Repair) for Respondent’s proposed Unified Messaging System.
Q14. What are your requirements for a reliable, resilient, highly available Unified Messaging Platform?
A14. Metropolitan has not formally developed these requirements specific to a Unified Messaging Platform. Metropolitan is interested in understanding the system uptime metrics (e.g., Mean Time to Failure and Mean Time to Repair) and resiliency capabilities for your proposed Unified Messaging System.
Q15. What are your Green Initiative requirements for a Unified Messaging platform?
A15. Metropolitan has not formally developed “Green Initiative” requirements specific to a Unified Messaging Platform. Metropolitan is interested in understanding how your proposed Unified Messaging has a positive impact on the environment and contributes to global sustainability.
Q16. What is your Unified Communications Strategy across management and professionals that will be dependent upon the Unified Messaging platform to do their work and respond to a crisis (natural, or man-made)?
A16. Metropolitan has not developed a formal Unified Communications Strategy that specifies the interdependence between UM and management and non-management employees.
Q17. Does the manufacturer’s Unified messaging platform have to be integrated to the MS Exchange platform? At what level?
A17. Yes. Metropolitan seeks a unified message store for email and voice mail within a single system platform (Exchange) for its messaging architecture
Q18. What middleware integration technologies are currently in use by Metropolitan?
A18. As written, the question is too vague to respond to.
Q19. Can text messaging and alerts on the phone be substituted with text messages and alerts on the desktops (HP Vista, etc.)?
A19. No.
Q20. If a user receives a voicemail, is an e-mail notification required to their desktop and/or mobile device to check their voicemail?
A20. No, this functionality is not a requirement.
Q21. In the interest of opening up the RFP to more vendors, will you eliminate the requirement of requiring text-based messages from being transmittable to any IP phone’s display?
A21. No, this is a functional requirement.
Q22. Can this particular requirement be met with an OCS messaging platform?
A22. This question is not applicable to the RFP or this project.
Q23. Can this particular requirement be met with a PC based IM clients?
A23. This question is not applicable to the RFP or this project.
Q24. In regard to ALL 21 must have requirements, is this particular requirement equally important, more important, or less important?
A24. The “Must Have” requirements are just that; requirements that Metropolitan has determined are critical to their business operation. As such, Metropolitan will be keenly interested to see which Respondents are capable of meeting these Must Have requirements,
Q25. Will the manufacturer be automatically eliminated if they cannot meet a “Must Have” requirement?
A25. No.
Q26. Is it acceptable to Metropolitan for the respondent to propose an alternative to a “Must Have” requirement?
A26. Respondent must first demonstrate that it is able to meet these critical requirements before considering alternatives. Only after answering all RFP questions or requests for information should the Respondent consider proposing alternatives.
Q27. Please reference page 16, Section 2.12.0.14. Please clarify “certified integration” with Microsoft Exchange 2007 and OCS 2007. Specifically, who would grant the certification?
A27. Metropolitan seeks to understand if the Respondent has conducted formal integration and system performance testing with Microsoft to verify the ability of its proposed unified messaging system to fully integrate with Microsoft Exchange 2007 and OCS products. In this case, Microsoft would certify that the unified messaging system can in fact, interoperate with Exchange or OCS 2007 applications.
Q28. Please reference page 17, Section 2.12.1.2. In the interest of opening up the RFP to more vendors and implementing open standards based future proof technology, will you consider making the SIP protocol a current mandatory requirement, rather than a future upgradeable option?
A28. Not at this time. Please demonstrate your firm’s ability to meet the requirements as described within the RFP specification.
Q29. Please reference page 17, Section 2.12.2.5. Please clarify that standard fax machines utilizing analog station ports will be assumed to be using standard fax protocols that are known to be compatible with VoIP networks. (i.e. V.17, V.29 are generally considered to be compatible, but V.34bis ‘Super Group 3’ is generally considered not to be 100% compatible).
A29. The Respondent may assume that any fax machines currently deployed by Metropolitan that will use an analog station port will be compatible with the VOIP network.
Q30. Please reference page 17, TABLE under 2.12.2.6. In the interest of opening up the RFP to more vendors, will you delete the requirement to have phones receive group broadcast text messages (e.g. via XML)?
A30. Not at this time. Please demonstrate your firm’s ability to meet the requirements as described within the RFP specification.