Writing solid unified communications RFPs and negotiating with VARs: A complete guide

Read our step-by-step guide to writing and developing an RFP for your unified communications deployment, as well as negotiating witih UC VARs.

This Content Component encountered an error
This Content Component encountered an error

Writing a unified communications (UC) RFP
  Making UC decisions
  UC analysis
  Considering endpoints and connections
Working with the VAR: Before and after the UC RFP
  Recommendations when working with a VAR
  Creating an RFI
  Creating an RFP
  Choosing a VAR

There are many decisions to make before any enterprise moves to unified communications (UC). In many cases, the UC procurement process will involve changing from a legacy PBX to an IP PBX. Moving to UC will also force management, organizational and cultural changes in the enterprise.

This tip series includes many RFP preparation suggestions and recommendations for the enterprise. Read all of them to ensure you have covered them. Some may not apply; others may be new ideas.

The first tip is to assign a single project manager for the entire procurement before anything is done. Ensure this project manager has the responsibility as well as the authority to do the job. Since UC contains so many communications-related functions, the procurement team should also include members who are subject-matter experts, such as call center, telephony, Web conferencing and video personnel.

The second part must address needs analysis. Here are some thoughts:

  • What do you have in place?
    Do an inventory of what you have, so you know what may be replaced. This inventory should be an appendix in the RFP.

  • Looking ahead -- how many years?
    Are you looking for a three-, four- or five-year system? Technology is changing so fast that five years would be the maximum lifetime for any procured system or software.

  • How much IPT and UC do you want to deploy?
    UC has many components. You may want to phase in the UC components, so make this clear in the RFP.

  • Which legacy components will be retained?
    Most enterprises cannot afford a complete forklift change. Determine which existing components are not candidates for replacement, and define them in the RFP.

  • Is the ICT organization ready?
    Just moving the telephony function into the IT organization is not good enough. The new Information and Communications Technology (ICT) group must be reorganized if UC implementation is to be successful. This reorganization should occur before the RFP is written. It should be done before the needs analysis.

  • Do you need outside help?
    Moving to UC is not an upgrade. UC is designed to increase productivity. UC may not be your enterprise's IT strength. There are seminars, consultants and sometimes conference programs that could help you move to UC effectively and efficiently. This is not yet an area for IT certifications. UC benefits will vary greatly by enterprise and users within the enterprise.

  • Go with the incumbent or competitor?
    Do consider working with your incumbent ICT providers, such as Cisco, Avaya, and so on. They have UC solutions. You should, however, still consider writing an RFP. Writing the RFP will force you to consider many aspects that may be overlooked. If yours is a public institution, you will have to go competitive, and an RFP is essential.

Moving to UC is not a replacement technology. Most likely the enterprise will be replacing the legacy TDM telephone switch with an IP PBX. This IP PBX will probably be the foundation for UC implementation. You still want all the features and functions that exist with the legacy PBX. List the features and functions used in the RFP. Here are more considerations for the RFP creation:

  • Hybrid or pure IP solution?
    You have three choices. Upgrade your existing legacy PBX to IP; buy a hybrid PBX that is part TDM and IP; or buy a pure IP PBX. There are cost, risk and cash flow issues to consider in addition to the technical requirements.

  • New integration with other systems
    As you move to UC, connecting to systems like Microsoft's OCS or IBM's Sametime servers will probably be necessary. There will be other application systems that need to be integrated. Determine these integrations, and include all the existing and planned integrations in the RFP.

  • Support of part or all of the UC menu
    o The UC menu is long. IP telephony is absolutely required. Which of the following functions are to be included and delivered -- and to whom -- must be decided before writing the RFP:

    • Voice and audio conferencing
    • Video conferencing
    • Web conferencing
    • Instant messaging (IM)
    • Chat (on-demand or persistent)
    • Mobility
    • Call center

  • IT issues that drive procurement
    Now that UC will be part of IT, other factors will come into consideration. These will include disaster/recovery, reliability, security, software upgrades and maintenance, staff and user training, and professional services. All will be part of the UC RFP.

  • Migration strategy
    You do not just plug in UC and expect it work. You have to consider how to introduce the UC functions, expand the IP network, change the desktop operation and measure the productivity improvements. Develop a cautious migration plan in advance. Then, when the bids come in, look at the vendors' migration plans to see whether you need to make changes. Do not be too ambitious, or you will go over budget and/or fail.

Lastly, you need to consider the endpoints and connections that will be used:

  • Legacy analog and digital phone
    Which are going to keep operating and not be replaced?

  • Non-phone devices
    There will still be non-phone connections. There will be fax machines, security devices, TDD and alarms that need to be supported.

  • What level of IP phone?
    There are basic, business and executive level IP phones that must be selected. Do you want 1Gbps IP phones? Plan for the PoE use and LAN switch upgrades.

  • Softphone use
    How far do you want to deploy softphones? Do you want the IPT vendor version or the Microsoft version?

  • PSTN connections
    Should the enterprise consider operating T1 and PRI PSTN connections or migrate to SIP trunking or a combination?

  • Dial plan
    The restructuring of the enterprise dial plan is commonly pursued when moving to IPT. Define the existing and proposed dial plans in the RFP.

  • Endpoint migration
    Eventually, most of the legacy phones will be retired. Define this migration plan in the RFP because it has an effect on the use and purchase of gateways.
  • Working with the VAR: Before and after the unified communications RFP

    In previous decades, the enterprise dealt with the TDM switch vendor. Today, the value-added reseller (VAR) or system integrator (SI) takes the lead in dealing with the enterprise. Unless yours is a very large enterprise, government agency or service provider, you will have to work with a VAR, not the system vendor. How the enterprise and VAR develop a relationship influences the success of any project, especially a unified communications project.

    There are several recommendations when initially selecting the VAR.

    • Have the vendor recommend the VAR. Get Cisco, Avaya, Nortel, Siemens or another vendor to select the VAR that will work with you. This ensures that the VAR will receive support from the vendor. A problem with a VAR can then be brought to the attention of the vendor for resolution.
    • Have only one VAR per vendor, if this is possible.
    • Look at the geographic support of the VAR. A local sales office does not mean local support. Is the concentration of support a drive away or a flight away? The farther away the support organization, the longer the response time. If a lot of travel by the VAR is required for the UC implementation, this will cause the proposal cost to increase vs. a local organization.
    • When a budget is formalized by the enterprise, take the budget amount in dollars and expand it by 50%. Compare the expanded budget amount to the annual revenue of the VAR. If the expanded budget is greater than 5% of the VAR's annual revenue, then the VAR's financial strength should be reviewed. The problem is that if the enterprise holds back payment to the VAR, the holdback may seriously affect the VAR's viability. You do not want to cause severe financial distress to the VAR. You want financial leverage, not a financial club to be used against the VAR when there is a problem.
    • Limit the number of RFP respondents to six VAR proposals or fewer. Three VARs should be the minimum number of respondents. Public institutions have to open the bidding to anyone, where 10 to 20 proposals are submitted, some with the same products. Try to eliminate most of the VARs until you have about six adequate proposals.
    • Prepare a presentation to inform the VAR of the project goals, plans and scheduling. Meet with each VAR separately. Plan on a half to a full day of presentation and time for questions and answers.
    • If Microsoft Office Communication Server (OCS) or IBM's Sametime are to be part of the UC solution, contact Microsoft and IBM to gain their backing for the selected VAR(s). When considering the choice of OCS or Sametime, understand that they are very different products with different goals. Each UC vendor has its own approach to integration with OCS and Sametime. See Choices in Unified Communications: Comparing Microsoft OCS 2007 to IBM Lotus Sametime 8.0. (hyperlink title http://www.nojitter.com/showArticle.jhtml?articleID=206501947)

    The enterprise may not be sure of the direction to take for UC and may not have adequate vendor knowledge of the UC products. A request for information (RFI) is for information only, not for solicitation of a proposal. The RFI is usually issued when the customer wants to learn what is offered.
    The RFI can also be used to inform the vendors and VARs of a possible project. An RFI does not mean there will be UC procurement. Have the VAR present the information contained in the RFI to the enterprise RFP team writers. There should be no cost to the enterprise for the RFI preparation or presentation. The RFI should be short (10 pages or less) and include:

    1. Description of the enterprise's business.
    2. Intended departments to be served with the UC implementation.
    3. Expected value of the UC features.
    4. Description of the existing voice environment.
    5. Description of the existing data network environment.
    6. Intended solution(s).
    7. Single vendor product or mixed vendors, e.g., Avaya and OCS or Cisco and Sametime preferences.

    The descriptions of the existing environments:

    1. Should have an accurate inventory of systems, devices, network connections and locations.
    2. Should provide changes included, especially for the data network for the next three years.
    3. Should be useful for the migration plan.
    4. Should contain traffic information and network utilization.
    5. Should not contain the enterprise's present costs.

    An enterprise should take a team approach to the preparation of the RFP. There should, however, be one person in charge of the RFP creation and project. Distributed authority can create stalemates. The VAR will see the stalemates as an enterprise weakness and use the disagreements to push the implementation and costs to its benefit. A unified team should be composed of one or more members from:

    • Telecom operation and administration
    • Data network architect
    • Call center manager
    • Relevant applications software staff
    • Computer operations

    When preparing the RFP:

    1. Define technical terms at the beginning.
    2. List questions for the proposal responses.
    3. Avoid narrative as part of the requirements.
    4. Require formatted responses.
    5. Provide details of the present environment in appendices.
    6. Include terms and conditions.

    There should be meetings with the selected VARs before issuing the RFP. Meet with each VAR separately. Use members of the RFP team to prepare and present the elements of the RFP to the VAR. Be sure that the VAR understands the proposal process, response format and schedule. Too many VARs try to change the response rules by providing their own boilerplate document. Make sure the VAR will conform to the format required. You may even threaten to disqualify the VAR's proposal if it does not meet the format. Inconsistent proposal formats make it difficult for the enterprise to compare proposals.

    Selecting the final VAR is just as important as the product proposed. Look for these elements for the qualification of the VAR:

    1. VAR financial size when compared to the price procurement.
    2. Experience in the product(s) proposed.
    3. Expertise (especially in working with the enterprise's industry).
    4. Ability to provide support and maintenance to all locations.
    5. Product certifications: which ones and how many employees certified?

    Seven questions to consider when selecting the winning VAR:

    1. Does the VAR meet all the important RFP requirements?
    2. Does the VAR understand the enterprise goals and objectives?
    3. Will the VAR have the ability to support the project?
    4. Can the enterprise form an alliance, a partnership, with the VAR?
    5. Can the VAR effectively allocate the required resources and talent?
    6. Will there be open communications among the alliance partners, customer, VAR and vendors?
    7. Will the C-level executives support the selection?
    This was first published in May 2009

    Dig deeper on Developing a UC Strategy

    Pro+

    Features

    Enjoy the benefits of Pro+ membership, learn more and join.

    0 comments

    Oldest 

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    -ADS BY GOOGLE

    SearchMobileComputing

    SearchNetworking

    SearchTelecom

    SearchITChannel

    SearchEnterpriseWAN

    SearchExchange

    Close