Internally-developed RFP/RFB/RFQ process

In an attempt to streamline product acquisition costs and evaluate multiple vendors, many entities will choose to develop an internal RFP, RFB, or RFQ (Request for Proposal, Request for Bid, or Request for Quote, respectively). Although each of these terms have a slightly different meaning, for the purposes of this guide they will be considered the same.The internal process typically begins with data collection which may include the following:

• Number of handsets
• Type of handsets (basic, office, manager, executive, specialty – wireless, conference, etc.)
• Currently utilized features – listed out and itemized
• Telephone services connected to the system
• Required third-party integrations such as paging, door entry, audio-on-hold, etc.
• Required system functions such as call accounting, hunt groups, ACD, etc.
• Required third party products, such as headsets
• Desired future growth capacity

Once the basic design data is verified, the RFP developer would typically assemble a decision-making team. This team is ideally comprised of representatives from each major department to discuss the current system operation and desired changes that would help increase productivity. It is helpful to have a source of knowledge in this process that can connect desires with applications available within the technology, though a clear wish list can be interpreted by most competent integrators.

Developing the RFP document need not be a laborious task. There are many RFP templates online that are available as a free resource or for a minimal fee. The information you request in the RFP should be what you need to comprehensively evaluate each bidder.

There is an outdated belief that an RFP should be 40-60 pages in order to be accurate. While there may be occasions when this level of detail is essential, do not create volume for the sake of volume. It will only increase the complexity of the process for the bidders, and will equally increase the effort required by your team to distill the added information. Convey the information about your known requirements, and request the information that is important for your selection. All final processes will include references, interviews and product demonstrations which will allow you to dig deeper in your analysis.

Many public entities have a process in place already for distributing RFPs, and your purchasing department may currently have means of advertising such requests. If not, there are third-party websites that will promote RFP’s to the technology community, much in the way you might upload a job posting to a recruiting site. It is advisable to release your RFP at least one month before your desired response deadline.

During this process, you should also consider these helpful activities:

• Hold a mandatory pre-bid conference for all bidders wishing to respond. Announce the time and location of the conference as you release your RFP. This will give you a chance to assess your field, set and clarify expectations, and prevent last unexpected last-minute bidders from disrupting and confusing your process.
• Create a public forum for bidders to submit and receive responses to all bidding questions. Your goal will be to ensure that all quotes are as equal as possible in scope, and that all information is shared available among all bidders.
• Identify a clear cutoff date and time for bidders to submit questions. The cutoff date and time for bid submissions should be equally as clear.
• Develop, in advance, a process to select a first round of cuts to keep your workload manageable.

• Predetermine the number of product demonstrations you wish to entertain. Keep in mind that bidders offering the same product may have entirely different methods of designing and implementing that product. Don’t assume that similar hardware means a similar approach.
• Develop evaluation criteria and a grading scale for the responses (and eventual demonstrations) including vendor experience, thoroughness of design, understanding of your needs, competence of personnel, solution features and benefits, and, of course, total cost of purchase and ongoing support. (For technology solutions it is common to specify that cost is only one of the grading criteria that will be used. It is useful to assign a weighted scale at the outset.)
• Assemble a product review team consisting of people with needs and desires

representative of the entire organization to view all the finalists’ demonstrations

and participate in the evaluation process.

Vendor-assisted RFP/RFB/RFQ process

If you have been referred to a specific vendor, or have developed a relationship with a vendor who has been professional in their conduct and follow-up, you may consider seeing if they will help you in developing your RFP. Many established vendors have access to RFP templates that they are more than willing to share. A solid vendor will have confidence in their own recommendations and will want to assist you in securing competitive bids that are consistent with the scope of work you require. There is an inherent bias in this resource, but knowing that fact at the onset allows the information provided to be properly filtered.

Given the effectiveness of the help and insight a vendor can provide, there may be justification in having them complete some of the legwork for your RFP. This, however, should be provided to you at a discounted rate given that their input will almost certainly be skewed to their own offerings. This option is only recommended if you have a reason to trust a specific vendor and would consider them as a strong competitor for your business. It is also important to make sure the vendor is aware from the start that this help will not guarantee them the final contract.

Although this can be a cost-effective method in completing your technology RFP, there are a few potential downsides to this approach:

• A vendor-assisted RFP may be viewed as bias and unfair. This could result in fewer bid responses. It is common practice within the industry to acquire help in this fashion and choosing the proper resources can impact the outcome.
• Having one vendor primarily guide the design may discount potential solutions the vendor may not be aware of nor represent. It is always advisable in this method to encourage optional recommendations in the RFP response.

The more certain you are of your needs and the technology you wish to deploy, the more attractive this method becomes. It allows more time to be focused on your ultimate design and solution, and less time focused on product research. In many cases, the RFP development and analysis process can take more time than system deployment itself. This is a good idea if the needs are complex or unknown, but less effective for routine projects.

Outsourced RFP/RFB/RFQ process

For entities that do not have the internal resources to properly manage the acquisition of a new communications system, there are many market offerings that will outsource the entire process — from initial needs assessment through to vendor selection and implementation. This can be invaluable for organizations that do not have staff expertise in telephony, lack sufficient time in their project schedule, or require an unbiased evaluation and selection process.

For most organizations, a new telephone system acquisition happens every 8-12 years. It is not a process that is repeated very often, and when the need arises it is likely that all the information learned in the last such implementation is already obsolete. The variety of offerings that can fulfil the requirements of a “telephone system” have also expanded exponentially. The evaluation process that was effective five years ago is already long outdated.

Some of the key considerations that may motivate you to use an outsourced model include:

• Is the task at hand a primary function for your business? If not, don't waste valuable time on it. Do what you do well.
• Is there an advantage to do it in-house?
• Is it a specialized project you don't need to handle full-time? You will only buy one phone system every 10 years.
• Is it something someone else can do better and more efficiently?
• Are the costs of the outsourcing lower than what it would take in time and manpower to get it done in-house? Consider the potential costs that could additionally be incurred if lack of sufficient time or experience results in mistakes or delays.

It is estimated that the cost of outsourcing a phone system RFP are roughly 20% - 35% of the total project cost. Ensuring that you start the process with the right vendor is critical to the overall success of your project. When evaluating a RFP consultant for your project, consider:

• Experience of the vendor – This should be viewed in terms of your industry, your geography, your size of deployment, and your major functions. A good rule of thumb is to talk to 4 of their references who have conducted a project similar to yours within the last 18 months.

• Credibility of the vendor – How do they identify, acquire, screen, and select bidders for your RFP? It is very common for RFP consultants to know who the players are in their market. This can be an advantage, but should not be a limiting factor.

• Compensation – A reputable consultant will only accept compensation from the organization they are hired to help — yours. Any type of incentives offered to them based on prior relationships should be issued back to your organization as a credit.

• Scope of Engagement – It should be clearly identified what the consultant will do as part of the project and to what extent their resources are required. It can be as minimal as the RFP development, but can extend to providing support and oversight during the system conversion.

• Product Experience – It is helpful to understand which specific products and services the consultant has experience implementing. If there are any product preferences at the start of the relationship, they should be clearly discussed.

Determining which method will be best for your organization’s VoIP deployment

The method of acquiring your new system will ultimately be driven by your specific criteria and environment. Your decision for which route to take will determine the level of resources and involvement you will need to dedicate to the project, the total cost (in both money and time), and its path to success.

The most common criteria to consider when making your decision are:

• Deployment size – The larger the system, the more complex the comparison between proposed solutions may be. Without specific industry knowledge it may be hard to arrive at a fair apples to apples comparison between offerings.
• Purchase size – Many government entities require purchase options to be mandated for certain purchase amounts. For most systems a good rule of thumb for an on-premise telephony solution is between $300-$800 per user. While this is a large delta, it provides an idea of the scope of your needed deployment.
• Deployment complexity – The more changes, customization, and technology enhancements you find that you need, the more it may be necessary to involve experienced industry professionals in the process.
• Internal Resources – It is important to understand that each purchasing method has an associated “people cost.” It will be critical to find the optimal spot where internal capabilities are balanced with the required external resources. An internally developed RFP may overburden existing staff levels, while an outsourced RFP process may increase the cost of the project by up to 45%.
• Timeframes – As a general rule, the more time available to make a decision, the more options are available for the process. A pre-approved product purchase can be completed in a matter of a few weeks, whereas a formal RFP process typically requires 6-18 months.