Proposal Letter for Tutorial Service by vyl13661


Proposal Letter for Tutorial Service document sample

More Info
									Tutorial: Request for Proposals
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.

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

To top