About Technology Plus

The Gotcha’s of IP Telephony

 

Introduction:

IP (Internet Protocol) Telephony is not just a platform for voice services. It provides the platform that can improve business processes and efficiencies. With the shift to IP-based telephone systems, businesses face a new and increasing set of challenges in the purchase, implementation and support of these systems.

Manufacturers of traditional PBX systems are shifting all product enhancements from traditional TDM (Time Division Multiplexing, or “Digital”) PBX’s to IP based systems. Whether you are purchasing a new phone system or upgrading an old one, an IP system will ensure that your system is technologically sound and prepared to grow into the future.

IP Telephony is a paradigm shift for both voice and data disciplines. When planning and implementing an IP Telephony solution, a company or organization should address the issues identified in this white paper, all of which are critical for a successful deployment.

The critical areas include the following:

  • Identification of Business Goals and Requirements
  • Evaluation of Existing Network Infrastructure
  • RFP (Request for Proposal) Development
  • Individual Organizational Issues
  • Simple Problem Resolution
  • “As-Built” Documentation
  • Change Management

 


Identification of Business Goals and Requirements:

In the purchasing process, identification of business and user requirements is critical. IP Telephony provides a platform that will integrate voice and data. This combination can provide efficiencies and capabilities to an organization or business that can result in increased revenues and even act as a business differentiator. Identification of potential long-term requirements, and including these as options in the RFP, is essential. With the integration of the voice and data disciplines, requirements must include more than traditional voice requirements. Based on identified business goals, technology goals should be identified.  An example of how the technology can support the business is identification of potential workflow and process changes that can result in efficiencies through automation. IP Telephony can be an enabler providing support for the business goals. The requirements should address the expectations of users and the company because of the potential impact on system architecture and vendor expectations.

The requirements document must be detailed and made an integral part of the RFP.  Lack of RFP details will result in costly and unnecessary change orders during the implementation, and, once the system is installed, unexpected costs and potential component replacements.

 

Evaluation of Existing Infrastructure:

As part of the data gathering process in the requirements phase, it is necessary to evaluate the existing data network, network architecture and communications infrastructure. The infrastructure evaluation should include all communications equipment rooms and spaces to ensure that power, cooling systems and equipment have been installed or modified to meet the needs of IP Telephony. In addition, the communications cabling and data network should be evaluated. It is critical to evaluate the existing data network and equipment to ensure that they can be integrated to provide optimum reliability. The data network will become the lifeblood of an organization’s communications infrastructure, carrying both voice and data. Depending on the results of the evaluation of the data network and associated infrastructure, there may be significant cost to replace or upgrade equipment, spaces and cabling. The costs identified must be considered as part of the IP Implementation. If the network and cabling do not meet vendor and industry standards and requirements, system reliability and voice quality can be negatively impacted.

 

RFP Development:

When developing the IP Telephony RFP, in addition to the traditional areas that are typically addressed, several additional areas will have an impact on the implementation and support of the IP system. Identification and detailed breakdown of optional equipment, long-term requirements, maintenance, and support of the IP system and components integration must be included in the RFP.

Optional Equipment plan for current and future projects is important part of RFP development. The identification of functional options that may either be implemented initially or in the future can impact the initial system architecture and specific components. Proper RFP development will help prevent avoidable equipment replacement or costly upgrades when future needs become apparent.  An example of a potentially problematic initial configuration would be the sizing of a specific server based only on initial system requirements. When future options are installed, the server may not have the capacity needed for those options. By factoring in potential and specific future requirements, an option could be included to provide for a larger initial server size to avoid having to replace it in the future, when the option is implemented.

A second important area to consider is maintenance and support. Determine how support will be handled, by whom, and at what annual cost. This is one of the big “gotchas” in IP Telephony systems deployment.  Aside from a very basic system, most solutions (regardless of the IP Telephony manufacturer) will have multiple vendors and manufacturers as part of the solution. If a detailed maintenance program is not identified, the customer may find themselves in the middle of a finger-pointing, maintenance problem quagmire.   

Another area that the RFP needs to address is the cost of long-term maintenance. Unlike the traditional TDM PBX, IP-based systems will require system software upgrades on a regular basis, just as is the case with computers today. These upgrades will result in maintenance costs and requirements that were not a part of traditional TDM PBX costs.  These higher maintenance costs should be included in the overall system cost quotation.   The total system maintenance cost for a minimum period of five (5) years should clearly and unambiguously be identified in the RFP response.

A complete picture of the network infrastructure (e.g. data network equipment models and configuration, existing cabling infrastructure description, and 802.11 wireless equipment) should be included in the RFP so that vendor responses can detail any necessary upgrade or replacement costs required to have the vendor support the system on a “five-nines” basis. A network assessment should always be included in the selected vendor’s statement of responsibilities.

Integration with other existing or new system components should be detailed. Examples of components to be integrated might include a call accounting system or, in a call center environment, a specific reporting system or call recording system.

 

Development of the Statement of Work:

Once a vendor is selected, the vendor should provide a detailed Statement of Work (SOW) as part of the purchase contract. This detailed SOW is critical for a successful and efficient implementation. When done properly, the SOW will eliminate any surprises and disappointments regarding expectations by either the vendor or the purchaser.

The SOW should address timeframes and deliverables, both from the vendor team and the purchaser. The breakdown of the vendor’s responsibilities, as well as, the purchaser’s responsibilities and deliverables should be identified. It is critical that the SOW be as detailed as possible. The SOW should also conform, as closely as possible to the RFP.  Any departures from the RFP must be done by mutual agreement between the vendor and purchaser.

As stated above, the SOW should be based on the RFP requirements and the purchaser’s expectations, including data gathering, system design, testing, implementation, system acceptance, maintenance and support. The SOW should also have a detailed project schedule showing time frames and responsibilities.

The SOW should address responsibility for station reviews, placement of phones and other telephony devices including specific system impacting information required from the purchaser’s network team. Any cabling, network or other items or components that the purchaser will be providing, or is contractually obligated to supply, change or modify should be identified.  These items should be identified in the SOW negotiations or may come later as part of a Change Order.


Multi-Vendor Environment:                                                                                      

In the IP telephony environment, a complete solution will typically include multiple products from multiple manufacturers, and in most cases, multiple vendors partnering to implement a particular solution. The implication for the customer is that even though the total solution was sold by one vendor, that vendor must depend on its staff to work with some products that are new and on which they have only received rudimentary training. Additionally the vendor selling a complete solution will often be dependent on a vendor partner(s) to implement a portion of the solution. The lead vendor in these cases will typically lack the experience to manage the other vendors, especially when there are challenges during the implementation and, later, in the support period. As a result, the customer is placed in the middle (good old finger-pointing). We have seen this time and time again. The customer does not have the time or the expertise required to solve the problem. In these cases, it is best to involve a subject matter expert (consultant) who is on call to answer questions and propose solutions.

 

Integration Complexities:

Another challenge that occurs with IP implementations is the complexity of configuring multiple products into an integrated system. When different products are integrated or connected together via the data network, the connecting architecture is completely unlike the traditional TDM system which uses tie lines or a CTI (Computer Telephony Integration) link. IP Telephony connectivity via the data network can involve very complex configuration issues. Both customer and vendor take a big risk if they do not spend the time and effort to get very detailed information identifying existing and new required configurations. A simple vendor questionnaire completed by the customer without expert assistance is not good enough. The result can be implementation and system problems that are unnecessary, expensive, and again result in finger-pointing.

 

Organizational Issues:

Another “gotcha” from the customer standpoint concerns internal organizational issues and responsibilities. IP Telephony integrates data and voice together. However, the typical organization has a staff that works independently in the voice and data disciplines and has not worked together as closely as they will be required to do with IP Telephony. We often see that the network and data staff when upgrading or making changes to their network and desktops may not be as sensitive to user requirements as will be required when voice is added . Although the data network is critical, voice users have different expectations for voice than they do for the data network. Looking at how an organization works together is critical to having the reliability and uptime required to satisfy the end user community. The change management process is vital. An application or network upgrade needs to be evaluated for its impact on and compatibility with the IP Telephony system.

 

Simple Problem Resolution:

IP Telephony “gotcha” centers on how a vendor addresses a system problem. An easy traditional way to fix a problem, particularly one that is not well documented, is to reboot the server. Although the reboot doesn’t fix the problem long-term, it may fix the immediate problem. For the technician the problem is gone, but for the customer it may return again and again. Log files can be used to collect information, but they can slow down the server. If a server is rebooted, and the information is not written to disk (which is typical), the information is lost. The vendor must have the expertise or be willing to quickly go to the manufacturer’s support organization obtain the expertise required to quickly resolve the particular issue(s), when required.  Provisions for this type of support should be an integral part of both the RFP and the SOW.

 

Testing:

With IP Telephony, detailed implementation testing is critical. Call center and unified communications testing, both by the vendor and customer, is a must. Detailed test plans ensure the applications are working properly. Call center implementation requires load testing. In complex environments, a testing environment should be part of the initial system implementation, and should also allow the customer to test future system and application changes before implementing them on a live system.

 

“As-Built” Documentation:

A critical aspect of the installation is a complete set of “As-Built” documentation from all the different vendors integrated into one manual.

One part of the documentation should be a logical diagram showing how systems are connected together, what runs on each server, and what components are included in the server.  A second part should document all network addresses and system passwords. This documentation should be produced in both hard and soft copy format.  At least one copy should be kept in a secure place away from the system location in the event of a catastrophic event (e.g. fire or flood).

To guard against the possibility of vendor failure or system obsolescence, the customer should also request, and the vendor should agree, to hold a copy of the system source code in escrow in the event that the vendor should choose to withdraw system support or cease operations entirely.

 

Change Management:

To have traditional “five-nines” reliability, the customer must develop and implement a structured change management process. This process includes defined procedures to manage the IP Telephony system, the data network, data security, and any other applications that are implemented with IP Telephony.   The combining of multiple applications from multiple vendors demands a more comprehensive level of documentation, version control management and system updates to properly track and account for and effectively manage the interaction of multiple systems and applications.

 

Summary:

IP Telephony is a paradigm shift from traditional voice systems.  The shift from a self contained system to a multifaceted communication and collaboration tool requires a higher level of management, training and process control.  The issues discussed in this paper with specific emphasis on the following will lead to a successful implementation:

  • Identification of Business Goals and Requirements
  • Alignment with VoIP features, functions and add-in applications
  • Evaluation of Existing Network Infrastructure
  • Capacity and reliability to support both voice and data
  • Organizational Management
  • Clear definition of roles and responsibilities
  • Statement of Work (SOW)
  • Detailed roles and responsibilities
  • Detailed schedule
  • Service Level Agreement (SLA)
  • Establish responsibility for Problem Resolution and Escalation
     

Communication and awareness of the potential pitfalls of enterprise level Voice over Internet Protocol (VoIP) Unified Communications systems are essential to addressing the “gotcha’s” early and often during the design, selection, acquisition and implementation process.  This will result in a smoother project with fewer unnecessary change orders and effective coordination between vendors. 

 

Howard Feingold is the President and Founder of Technology Plus, a technology and communications infrastructure consulting firm.