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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.