Preparing a Request for Proposal

Note: This material was prepared with the assistance of Ed Tomko, Director of Consulting at Communication Resources, who also did extensive work testing it in the field.

1. What is an RFP?

An RFP, or Request for Proposal, is a document transmitted by a customer to one or more vendors to specify a desired system or service, and to request a proposal from the vendor for offering that system or service. Ideally, each proposal, returned to the customer in response to the RFP, will describe an adequate solution and quote firm prices which can be used in financial analysis.

The customer must then evaluate the proposals, both in terms of price and function, select a vendor, and supervise the implementation of the system. It all sounds simple, and when buying a relatively standard system whose properties are well known (such as a typewriter or milling machine), it is. But when one goes after a PBX, complexity sets in rapidly.

In the first place, a PBX is a sophisticated machine that can provide many features and services, some needed and some which should be actively excluded. Second, most PBXs do similar things, but in vastly dissimilar ways. Further, different names are often used for the same things, and different things have the same names. All this leads to a certain confusion, particularly at a time when so many of both vendor and customer personnel are encountering telecom for the first time.

Finally, a PBX is not something that one can buy and forget. It must continue to function for years, under the direct control of many station users who neither know nor care how it works, and it must be administered by the telecommunications department in such a way that changes, modifications, upgrades and additions can be made as required, with minimum cost and effort over the entire life of the system.

Thus the PBX RFP has several functions: it must specify to the vendor what the customer actually wants, and then it must elicit from the vendor an explanation of how a proposed system meets the customer^ needs as well as what it costs. The proposal obtained should contain all the required information in such a way that dissimilar PBXs and pricing approaches can be evaluated on an “apples to apples” basis over the life-cycle of the system.

Back in 1978, Business Communications Review ran a series of my articles called “Those Awful PBX Proposals.” At the time, they attracted considerable attention; they became the basis of BCR’s seminar “Understanding Modern PBX Systems” and the first edition of this manual. Unfortunately, they had little effect on the quality of proposals from vendors. One still finds vendors who apparently assume that customers select PBXs on the basis of the total mass of the proposal, whether it responds to the RFP or not, and who have mastered ingenious ways of making their price appear lower than the customer will actually have to pay. Some even offer with a straight face features and functions and entire systems that are still a gleam in the designers eye.

Unfortunately, proposals are not the only items at fault. Many customers (and sometimes their consultants), like some of the proposal-writers who will respond to them, feel that the bigger the RFP, the better. There have been RFPs that include the entire questionnaire from this manual PLUS those from its several competitors, all in one document. How a vendor could respond to such a massive RFP is hard to understand, but how the customer could actually evaluate the volumes of information elicited in a truly responsive proposal is even more mysterious.

One approach should be mentioned in passing. Some customers give each feature a maximum weight, and rate a system’s capability for that feature with a number between 0 and the maximum. The sum total of the weighting factors is then an “objective” evaluation of the system. This approach is particularly attractive to tax-supported institutions who know they will be sued by sore losers among the vendors unless they have an iron-clad method of evaluating non-cost parameters, but it has several pitfalls. First, a large number of unimportant items, apparently done well, can swamp a few vitally important requirements not done at all. And second, it is very nearly impossible to find out how a system really works by reading proposals; thus the weight attached to a given feature may turn out to be wrong. It is difficult, for instance, to find out that a system’s Uniform Call Distribution package will work only for calls coming in from some trunk groups but not from others, or that restriction is hierarchal and cannot control mutually exclusive regional access by different station-user groups.

But a fat RFP is self-defeating in another way. It costs a vendor money to respond to an RFP and, in any procurement, only one vendor can win. Thus it is only natural that vendors will respond most readily to RFPs where they feel they have a high probability of winning and, to a slightly lesser extent, where they can respond without incurring excessive cost. If an RFP asks for a vast amount of detail, costly to obtain, which suggests that the customer just may not know what is truly important, a vendor may be reluctant to respond completely or, indeed, at all.

Thus an appropriate RFP, which is minimal in size but still elicits the important facts while permitting accurate comparisons among competing systems, has a much better chance of providing the customer with real choice than a RFP that weighs 20 pounds and includes every feature ever heard of during the last 30 years.

During the evaluation process, it is up to the customer to make sure that his needs are met and understanding of the system and its pricing is complete. This involves not only comparing systems, but also comparing vendors and manufacturers to make sure that continuing support will be available. In also involves careful attention to the total pricing so that the “life-cycle” cost of the system itself, the trunks that connect it to the central office and other switches, maintenance, moves and changes, upgrades and adds are all included. Spreadsheets are useful tools at this phase (see, for instance, the article by Sanders and Herr in Business Communications Review, March-April, 1981).

Spreadsheets done the old fashioned way, on paper, are tedious and time consuming. It is far better to leave the actual calculations to a computer, using software such as BCR’s FAST program, Financial Analysis Software for Telecommunications. A good spreadsheet not only simplifies the analysis required for understanding costs, but it acts as a check-list to make sure that all important factors have been included in a uniform manner.

Another useful function that spreadsheet software can simplify is checking the cost information developed within proposals. A spreadsheet can easily be set up to identify the main cost items such as line cards, trunk cards, memory boards, etc., and multiply the quantity provided by the cost per item and then add up the total. This does several things. First, it gives a feel for the cost of making changes in the size of the system prior to or just after cutover. Second, it shows the difference in cost of the system as a whole and the cost of the individual parts added up; there is often a fair sized saving if equipment anticipated for growth can be installed and checked when the system is put in. Finally, such a spread- sheet helps make sure enough equipment is being offered to do the job, and that significant items have not been inadvertently (or puposely) omitted.

Because each system is different in terms hardware specifics, consultants often set up a checklist spreadsheet for each of the major PBXs they deal with regularly. This permits considerable detail in price and quantity checking, once the spreadsheet “template” has been established. Such spreadsheets are set up with different line items as required by different systems, but have the same subtotals and totals so that they can fit into the life-cycle financial spreadsheet in a uniform way. Some consultants call the former “cost sheets” because they check costs and quantities, and the latter “value sheets” because they provide the present value of after- tax cash flow.

Anyone not in the business of continually evaluating proposals will probably not find it worthwhile to develop separate cost sheets for every PBX. Consultants, however, will find the exercise useful; those with unbiased checking systems can be a big help to their clients who only occasionally purchase a PBX. The client should, however, be wary of vendors who offer “consultants” or consulting service free. Clearly, a consultant provided by a vendor, although perhaps highly qualified and thoroughly experienced, cannot be totally objective; such a person and his or her software work for the vendor, not the customer. In these days of caveat emptor, it pays to take the attitude that vendors have salesmen, not consultants.

Once a suitable system has been selected, the contract for its lease or purchase must be negotiated. This is a most important phase in the procurement cycle, and the reader is referred to Dick Kuehn’s excellent article in the January-February, 1980, issue of Business Communications Review or to his expanded book version, Interconnect: How and Why, published by the Telecom Library. Most contracts, particularly those written by the vendor, contain a clause to the effect that “this contract alone constitutes the agreement.” The customer should, of course, insist that the RFP and the proposal, plus all other correspondence, be made part of the actual contract. Because this is usually resisted by the vendor, the customer should make clear in the RFP the terms and conditions that will be expected, and thus exclude those vendors who do not wish to comply.

But this brings up the most important single point to keep in mind as you go through the procurement cycle: no specification, no RFP, no contract, no document of any sort can make a system do what you want, or, indeed, function in any way. All it can do is fix the blame when the system bombs. We simply have caveat emptor again and, in this age of deregulation, do not expect any help from the FCC or your state’s PUC. Your only recourse, if things are not as you wish, is to go to court. Except in very special circumstances, you cannot even apply the standard tactic used against public utilities for years: withholding payment until the system works. All too often, these days, a third party, with no responsibility of any sort to the customer, “owns the paper” and has a legal right to collect, independent of system operation.

Many people feel that litigation is vastly superior to regulation. But if your PBX does not work and the lawyers argue for two or three years, how do you survive in the meantime without telephone service? This may be one of the most important questions you’ll have to answer in any PBX procurement procedure. ALWAYS have a contingency plan to fall back upon.

[ Top ] [ Next ] [ Table of Contents ]

Copyright 2006 Lee Goeller. All Rights Reserved.