So you want to write a VoIP RFP

2005 is the year that voice-over-IP deployments displace traditional TDM as the voice system technology being deployed in American businesses. During 2004, VoIP shipments accounted for just under half the total (at 49.5%) with VoIP shipments exceeding TDM in both the third and fourth quarters (at 50.0% and 53.0% respectively--see table below).

This shift to VoIP deployments has been expected for some time, although the pace of reaching crossover surprised many, and there are others --perhaps in denial--who aren't quite comfortable yet with packet telephony and who are hoping against hope that it will go away. It's not going away, and sooner or later any enterprise or organization will have to come to grips with a request for proposal (RFP) or equivalent for VoIP acquisition. Certainly some have already been down this road, and what follows are lessons learned, general principles for those undertaking the journey and advice on avoiding a few of the inevitable potholes and landmines.

The following anecdote illustrates many of the "dos and don'ts" of a VoIP RFP.

A U.S. organization was considering moving to VoIP primarily to (a) reduce expenses and simplify support of voice operations, and (b) enable converged applications, including multimedia ones, for their users. Assisting in the process was the organization's primary IT consultant, who was responsible for many of their IT systems, their data networking and had also worked with the customer on a couple of VoIP trials. The trials verified that VoIP "fit" with the organization's people and business methods, and the consultant developed a business case that proved the economic viability of the organization's migration to VoIP. The next step was for the consultant to develop a detailed RFP for prospective solutions to the organization's needs. This was done with the help of an imported subject matter expert, and an RFP was drafted and coordinated with the customer organization. So far, so good; then the wheels fell off.

The consultant's project management for this VoIP effort was done by folks with IT and data networking backgrounds but with minimal understanding of voice and VoIP. (It should be noted that the customer's own IT shop had little expertise in VoIP and in the past had primarily outsourced legacy voice.) The possibility of a "train wreck" was further increased by placing very short time constraints on vendor interaction and selection, and by oversimplifying the implications of voice as but "another" data infrastructure application. Guess what? The accident looking for a place to happen--happened!

One of the most interesting--and humorous--aspects of this particular case was the handling of evaluation criteria. Every required item in the draft RFP, independent of level of detail, or hierarchical importance was given the same value. In other words, there was no weighting or prioritization of requirements. So for example, each individual phone feature had the same weight as a major system attribute. Accordingly "music on hold" had the same scoring value as a 5 9's availability! It's kind of like “Car and Driver” equating cup-holder aesthetics with drive-train specifications.

Other results and bitter lessons learned due to the project team's lack of VoIP background, oversimplification of the RFP tasks and haste in rushing to judgment on vendor selection were:

• Numerous vendors were alienated
• Viable solutions--and there are many today, including hosted and/or managed options and many diverse channels to provide them--were overlooked
• Project team lost sight of numerous longer-term benefits of VoIP, such as creating a platform for multimedia applications and other new capabilities
• Key differences between a VoIP RFP and one for a legacy voice system or one for a data network got lost in the shuffle.

Certainly mistakes like the above will happen in an environment of emerging complex technology such as VoIP and developing an RFP for its deployment. Going forward, the lessons from that episode and other "best practices" thinking leads to the following generic guidelines for your consideration:

1. VoIP may be the first "converged" application or IP communications application for your organization, but it won't be the last--video, wireless, collaboration and others are coming along soon, and sooner than you may realize. Think outside the (voice) box, and think platform/architecture rather than voice replacement only.
2. In your RFP, question vendors on their converged or overall IP network vision and how they will migrate your enterprise. See how they handle voice and whether it is "just another data network application" or is its uniqueness evident. Ensure that responding vendors demonstrate "cradle to grave" expertise and agility in VoIP and related voice and data technologies. Don't hesitate to request SLAs where you think they're appropriate.
3. Bear in mind the timeline and context of the RFP. You may want a staged scenario: business case, RFI, perhaps a VoIP trial, and then an RFP as the last step to procurement. Technology trials are no longer required for VoIP; the technology obviously works now, but the particular "fit" of VoIP and its attributes for your organization may need to be assessed.
4. Develop practical, measurable (where possible) evaluation criteria, and try for a "balanced" voice and data RFP evaluation team. Be sure that the evaluation criteria recognize the uniqueness of voice on data infrastructure--different than legacy voice and different from data networking. Costs will be included in your evaluation, of course, and be aware that VoIP can require new cost elements--like infrastructure upgrades--that may not be immediately obvious to you.
5. Think outside the box--it's no longer PBX or Centrex from traditional channels-numerous IP PBX options and hosted spins--managed and otherwise are available from a variety of sources and channels.
6. VoIP knowledge is not yet widespread, check out your "helpers." The pace and magnitude of VoIP deployment has created a gap in that there is not enough expertise "out there" to assist organizations that want to migrate to VoIP. Many promises of VoIP expertise from otherwise reputable external sources are empty. Spend the time and money to train your people and make informed decisions and avoid the "blind leading the blind," where you are paying for the "helpers'" VoIP learning curve.
7. Take your time about it, do the homework and enjoy the ride!

David H. Yedwab is the Executive Vice President of The Eastern Management Group and can be reached at dyedwab@easternmanagement.com.

Jay Brandstadter is an independent consultant affiliated with The Eastern Management Group. He can be reached at j.brandstadter@att.net.