Tutorial: Request for Proposals Introduction A Request for Proposals (RFP) is a solicitation for proposal. The nature and scope of the proposals is defined by the RFP. RFPs are used for many purposes. For example, an RFP may be used to solicit grant proposals. In telecommunications, a Request for Proposals is a document that spells out your requirements for services and/or equipment. It gives prospective vendors or contractors the information they will need to prepare a bid. In other words, it is a solicitation for a bid. The bid may include services such as installation as well as hardware and software. Typically, if you are restricting the process to any purchasing equipment or software, you will write a Request for Quotes (RFQ) which is usually just a list of the items needed along with any details required by your procurement process (e.g., warrantee, delivery details, payment schedule). RFQs are generally much simpler than RFPs. Writing an RFP is a tedious and laborious task. But in the long run, a well-prepared RFP will save you both time and money and will prevent future problems. Writing an RFP forces you to think about what you need in detail before you commit to making any purchases. It gets your ideas out in the open and gives others the opportunity to respond to your plans. Defining the Scope of the Project Writing an RFP should be seen as a process. You do not just write an RFP. You must research it, write it, and then use the RFP. The first step in preparing an RFP is to define the scope of the project. You will need to decide exactly what needs to be done and state it in an unambiguous manner. Are you buying equipment, contracting for the installation of equipment, ongoing services, or some combination? You will want to address each of these needs in detail in the RFP. You will need a detailed list of equipment. For example, for a switch, you’ll want to specify the number of ports, interface speeds, media requirements (e.g., copper, fiber, etc.), and any management requirements (support for SNMP, VLANs, etc.). Plan for expansion. You’ll also want to consider outsourcing at this point. Do you want to buy equipment to support dial-in access or do you want to outsource dial-in access? Is the equipment something you can install yourself? Will you need help or training? Depending on the nature of the services required, you may want to augment the RFP with a Service Level Agreement (SLA). If services are all you are interested in, an SLA may be more appropriate than an RFP. This should become clearer once you have defined your needs. Are there internal policy constraints that you will have to deal with? You’ll want to discuss the process with your purchasing department. State agencies, such as schools, may have a rigidly defined procedure for soliciting bids. You will also need to consider how to distribute the RFP once written. This may be dictated by procurement policies within your organization. Private organizations may have an advantage over public organization since they may be able to restrict who is allowed to bid thereby avoiding companies that they don’t want to work with. If are not constrained to an open bidding process, you may want to prepare a list of vendors that you will feel comfortable working with or that you have confidence in. Typically, three to five vendors will give you a manageable range of choices. However, you should discuss this with your legal department since there are pitfalls to this approach. It is also possible to make bidding a two-step process. Sometimes companies will have an initial qualification round. Potential bidders are contacted. Those that are interested can justify why they are qualified. The RFP is only sent to those companies with adequate justifications. You will certainly have budget constraints. You’ll want to come to terms with these as soon as you can. But don’t interpret these too rigidly. As the process advances, you may discover reasons to expand the project that would justify additional costs. For example, a data-networking project might be expanded to support VOIP, justifying the additional costs through other savings. While you will want to understand these constraints, you may not want to include them in the RFP. Parts of an RFP The organization of an RFP will depend heavily on its size and scope. Here is a basic outline for an RFP but there is nothing magical about this particular outline. Depending on your particular needs, you may want to move material from one section to another. For complex RFPs, you may need to subdivide some of these sections. Executive Summary The Executive Summary is a brief description of what needs to be done and how each need will be addressed. As the name implies, this is a brief summary, for the busy executive that wants to know what is done but may not have the interest or time to look at the details. Details will be given in subsequent parts of the RFP. The length of an Executive Summary will depend on the complexity of the project but it should be brief and to-the-point. General Information You might want to begin with a general or introduction to your RFP. For example, an explanation of the parts of your RFP can be helpful, particularly if you have an involved RFP. You should also describe the business objectives and technical objectives of the project. This, in-turn, may require that you describe the nature of your business or, at- least, any non-obvious constraints that your business may place on the project. Administrative Issues Next, you will need to explain the administrative aspects and mechanics of the bidding process. An RFP will need to include two schedules—one schedule for the administration of the bidding process, and a second schedule for the actual project itself. Typically the administrative schedule will be included under General Information or Administrative Issues while the schedule for the project will be included as part of the Technical Specifications or Contractual Issues. The administrative schedule will include the date the RFP is released, when proposal are due, when supplemental information may be required (e.g., a vendor presentations), and when the award will be made. You will need to clearly define how proposals should be submitted—where and to whom will they be sent—and how many copies are needed. Include a primary point of contact should vendors or contractors have questions. You will need to explain whether the process be public or private. For example, will you release or publish the proposals? Will you provide copies of one vendor’s questions to all other vendors? Some RFPs include a statement to the effect that all oral communications are unofficial. Finally, you may also want to include general information on how proposals will be evaluated. This can be very helpful to anyone preparing a bid, but you will want to be careful so that you don’t needlessly constrain yourself. Organization for Proposals If you are successful with your request for proposals, you will have a number of different proposals to sort through. This can be an absolute nightmare if proposals are organized in different ways and include or omit different pieces of information. Therefore, it is essential that you carefully define what you what included in the proposals and how the information will be organized. (Also, if a bidder can’t follow your directions when writing a proposal, you probably won’t want to work with them on the project.) What you want depends on your particular project. From a technical perspective, you may simply want sections that mirror the parts of your technical specifications. Even so, there are several additional sections that are typically included. Authorization: You will want something official, i.e., legally binding, along with the proposal, signed by an officer of the company. This is typically supplied as a cover letter to the proposal, i.e., a letter of transmittal. Budget: You will certainly want a budget. Keep in mind that the format and breakdown can vary considerably so be sure to specify any details that are important to you. Schedule: If you have carefully specified a schedule for the project, you may not need anything else. Even so, you may want the schedule repeated in the proposal for legal reasons. On the other hand, if you have left the schedule relatively open in the RFP, then you’ll want an explicit schedule in the proposal. Don’t forget about milestones and testing when specifying a schedule. Company Information: Unless you are working with major vendors or companies you are very familiar with, this can be essential. Information might include a description of the company and its history, references (i.e., previous clients for similar projects), information on personnel, or bonding and licensing information. You may want to include a separate section for contact information. Miscellaneous: These might include technical documents such as wiring diagrams and blueprints or anything else you think important for your particular project. Technical Specifications To an engineer, this is the heart of the proposal—where you specify what you need. Begin by giving an overview of your technical goals. This should be followed by a detailed description of the technical requirements and your current configurations. You should explain any technical constraints you are placing on the project. If a vendor understands the reasons behind a constraint, then the constraint may be less constraining. Requirements will necessarily be quite detailed. You may need to include blueprints, headcounts of users, geographical information, standards that must be met, etc. Of course, all this will depend on the nature of the project. Areas that you may want to consider include the following: Equipment: Don’t over-specify equipments. You should be specifying functionality, not model numbers. For example, you may needlessly constrain yourself if you specify a FuBar Model 2820X Switch when what you really want is a 12-port 10/100 switch. If you can give a generic specification and allow the contractor to select the individual models, you may save money. The downside to this approach is that you may want to standardize on a particular vendor. If you have nothing but FuBar equipment and all your personnel are trained on FuBar equipment, then life may be simpler if you stick with FuBar equipment. If that is the case, you will certainly want to include that constraint. Software: You will certainly want to be specific here. Remember, this will include software for all aspects of the project. While you are unlikely to overlook the OS requirements of your servers or the applications you use on a daily basis, you will also need to consider things like router software, security software, etc. Installation: You’ll need to decide how much you can do and how much you want to do. You will need to contract for what you can’t do or aren’t willing to do. Management/Maintenance: With many projects, there may be ongoing management. This can take many forms from the initial configuring equipment to ongoing fault management. Maintenance may include service contracts or scheduled services. And, don’t forget training. Contractual Issues The goal of an RFP is to enter into a contract that will lead to the completion of a project. In many ways, the RFP is a template for a contract, or, at least, part of a contract. You may want to include in your RFP any anticipated or standard terms and conditions. No doubt you are tired of hearing it, but with all of these concerns, what is included will depend heavily on the nature of the project. Evaluating The final steps are evaluating the proposals and selecting a contractor, negotiating a contract, and notifying the bidders that weren’t selected. We will only consider evaluation here. Evaluation may be a multi-step process involving multiple people within your organization or requiring additional information from other vendors. Ideally, the evaluation should be as objective as possible. This is important both to insure you get the best contract this time, but also so that vendors will be willing to bid in the future. Some organizations attempt to mechanize the evaluation process to eliminate subjective judgment from the process. One approach is to create a feature sheet listing all the requirements for the project. Each requirement is given a weight. (The list of requirements and weight should be determined before evaluating the bids. In fact, you may want to include them in the RFP.) Proposals are reviewed to see whether each requirement is addressed. The weighted sum of the met requirements is the compliance score for the bid. Each proposal is scored and the project is awarded to the vendor or contractor with the highest score. While a good idea in principle, this approach may be too formal for some projects. The requirement sheet, particularly the weights, is difficult to agree on. Also, there are many gray areas in compliance. Alternately, for some projects, all or most of the requirements may be deemed essential. Summary There is a lot more to writing an RFP than what has been presented in this brief tutorial. But you should have the basic ideas at this point. The best strategy is to start from existing, high quality RFPs. Since old RFPs may not really fit your needs, you may want to start with a set of RFPs and take the best, most appropriate features from each. If your organization routinely uses RFPs, there should be a number on file. Alternately, you can search the Internet for samples. There are plenty there if you take the trouble to look. Of course, the RFP is just the beginning. Now you have to complete the project. Sources There is a nice series of articles on writing an RFP by Deb Mielke starting at http://www.nwfusion.com/netresources/0518rfp.html. This document has borrowed heavily from that series. You can find a number of pages describing RFP on the Internet. Most tend to be brief and deal only with some of the problems you’ll face, but collectively, they can be quite useful. You can also find a number of examples of real RFPs on the Internet. Projects: Requests for Proposals For this project, you are asked to write two RFPs. Clearly, you should plan on doing the first one carefully and then adapt it to produce the second RFP. Each RFP should be reviewed from a technical, managerial, and legal perspective. The goal of this project is to introduce you to the process of writing RFPs, not to make you an expert. For the first RFP, you will be addressing the wiring needs of a building. You may assume the building is correctly wired for power and has appropriate conduits. (In general, this is a dangerous assumption!) You may also assume the build is empty. Your wiring proposal should address all telecommunication needs—both horizontal and vertical cabling, fiber as well as copper cabling, telephony as well as data-networking, and wiring standards and practices. However, you do not have to address external wiring. (In practice, this is something you would need to address.) For the second RFP, you will be equipping the building from the perspective of infrastructure. You will be buying equipment such as routers, switches, etc. You will not be equipping individual offices with computers, etc. unless there is some special need, e.g., a wireless access point in a room. (The RFQ will address this other equipment.) As with the first RFP, you should address both data and telephony. This particular RFP presupposes the successful completion of the project defined by the first RFP. You should attempt to produce a complete document, but particular emphasis should be placed on the technical aspects. You may use external sources and templates provided they are assiduously acknowledged. While there are no penalties for using these sources, you will not receive any credit for this project if you do not acknowledge them. You should also make all the changes required by these templates.