|
How
to Create the Optimal "Request for Proposal" (RFP)
By
Jay Hollander
Jay Hollander, Esq. is the principal of Hollander and Company LLC, www.hollanderco.com, a New York City law firm concentrating its efforts in the protection and development of property interests relating to real property, intellectual property and commercial interests, as well as related litigation.
The content of this article is intended to provide general information relating to its subject matter. Providing it does not establish any attorney-client relationship and does not constitute legal advice. Personal advice in the context of a mutually agreed attorney-client relationship should be sought about your specific circumstances. Summary: A
good "request for proposal" -- or RFP -- can be the key
to a successful high-tech business relationship. But, many
purchasers of software and other products often fail to
create an RFP that will produce the results they desire.
This article explains how to create the optimal RFP.
Introduction
When
it comes to the license or purchase of large customized software
projects, the ubiquitous "request for proposal," or "RFP," is
at once one of the most commonly used and misused corporate
documents. To paraphrase the age-old question, "has ever
a document been so misunderstood?"
Thought
of as a vehicle for identifying and attracting the most
suitable vendors for an optimally structured and planned
project, many RFPs do exactly the opposite, usually reflecting
commonly made mistakes on the part of companies issuing
them. Even worse, neither the vendors who respond nor even
the company's own consultants will always remedy these
problems.
Nevertheless,
done well, an RFP is an indispensable tool for helping
visualize a project, and it also provides a concrete roadmap
for the company-vendor relationship.
Advance
Planning
So
what exactly makes for a good RFP?
First
and foremost, visualization. Many RFPs fail because the
issuing company and/or its consultant don't really know
exactly what they want in a clear and detailed way. While
some argue that it's the job of the vendor to bring this
detail to the process after hearing the company's broad
outlines, I say the opposite.
A
company cannot hope to know if it's gotten a vendor response
that meets its needs if it doesn't really know its own
needs inside and out. Knowledgeable people inside the organization
must be able to plot out exactly what the goal or vision
of the project is, as well as what it will look like when
it's done. What will it do? How will it perform when it's
finished? It's vital to devote time to define and outline
what the company really needs in the process and what a
successful outcome will be. This "scope development" stage
of the RFP process is a critical one, and companies must
commit themselves to devoting sufficient time and resources
to the task.
When
a company realizes that it may need help in working through
the issues of exactly what it wants -- and whether it's
reasonably available in the marketplace -- it enters the
consultant's arena. Consultants -- or the "bench," as they
are often called -- are supposed to help companies define
their goals in terms of what's available in the marketplace
and assist them in vendor selection and contract negotiation.
The value of -- and the need for -- a consultant is a hotly
debated one in the software industry and is worthy of its
own article, so for now, let's just discuss how any consultant
a company picks might best be used.
Consultant
selection is a project in and of itself. The trick to hiring
a good consultant is to find one that is knowledgeable
in an industry and knows its players but won't have any
loyalties to particular potential vendors. Ideally, the
consultant should be able to help the company define its
project, counsel it on how realistic the wish list is,
and either assist or write the RFP.
Consultants
should also assist in the vendor selection process, through
fielding vendor requests for information, analyzing vendor
proposals, requiring supplementation for inadequate responses
and, finally, recommending vendors and facilitating the
ultimate contract negotiations.
Whether
a company uses a consultant or not, there must be a "point" or
lead person who will be in control of the project. This
person can, of course, delegate aspects of the work, but
he or she must ultimately be responsible for bringing it
together.
For
the integrity of the process, it is often advisable that
the company make known that its RFP document is copyrighted
and cannot be redistributed without permission. Also, it's
increasingly common for companies to require confidentiality
agreements to be signed by potential vendors in exchange
for receiving the RFP. This goes a long way toward curbing
two often-encountered problems in the process. First, it
inhibits the known vendor practice of shopping the RFP
to freelancers and other independents to allow the vendor
to compete for a project it might not otherwise be able
to perform on its own. Second, it constrains such vendors
or freelancers from showing the company's project plans
to the company's present or potential competitors.
A
company must also set an example for the ultimate project
by setting forth a schedule for completion of the RFP process,
giving dates and deliverables for all stages of the competition,
including such things as:
when
responses are due when interviews of the resulting short
list of vendors will be held when any supplemental information
must be received when a decision will be made
The
Key Ingredients
What
about the actual RFP document itself? There are several
key criteria here.
All
RFP documents will require certain "boilerplate" information
about the vendor such as:
an
executive summary, containing a synopsis of the vendor's
project development approach and pricing structure the
vendor's corporate information concerning size, financial
stability and experience in the field a list of previous
clients for similar type of work
-
as
well as a detailed description of the development process
for the project
The
RFP document must also be structured in a way that allows
for easy and objective comparison between vendor responses.
The RFP cannot entirely solicit "essay" answers, but ,
instead, must be heavy on the "short answer" component
in terms of question style. Alternatively, ask for response
information to be provided in a format of your choosing,
to facilitate the work of comparing responses. Once an
acceptable format is set, insist that all questions be
answered and let it be known that non-conforming responses
will be rejected without further consideration.
One
of the most important challenges for an RFP is to require
concrete definable project terms and to hold the responding
vendor to those responses. This is done by clearly and
prominently requiring that the RFP and the vendor's responses
will be appended to, and constitute a part of, the ultimate
contract signed between the company and the selected vendor.
I
advise my clients to either require that responding vendors
attach their form of proposed contract with their response
or, better yet, attach the client's own contract, requiring
any responding vendors to assent to that form as being
acceptable in certain key areas, such as scope of warranty,
bug fix and tech-support schedules, confidentiality of
company information, intellectual property ownership, etc.
They should also be made to affirmatively agree that the
company's form of contract is otherwise acceptable in format
and scope for the rest of the issues. While there are many
factors on which to judge a particular vendor's response,
a company should carefully consider selecting a vendor
that cannot give comfort on these issues. To do this well,
of course, it is advisable that the company bring a knowledgeable
attorney into the picture, preferably one who has been
selected by the company and not by the consultant, again,
to ensure the integrity of the process.
Other
than the form of document, there are other vital considerations
in the RFP process.
Especially
in the customized software environment, one of the biggest
concerns is the problem of "vaporware," otherwise known
as advertising or offering a product that doesn't yet exist.
Many
software projects concern software that, while extensively
customized for a particular project, feed off an already
existing base product. One of the main jobs of the consultant
in this context is to verify how much or how little modification
will really be required to meet the company's needs. One
way to do this, of course, is to require a visit to a live
site of one of the vendor's clients to see the software
running "live." Merely observing a "demo" of screen shots
with no understanding of basic things like the software's
response time with a given database population, or the
flexibility of the product's underlying database structure,
will inevitably lead to frustrations down the road as the
company is confronted with limitations of the software
or its design that were not sufficiently understood before
selection.
There
must also be a concrete set of defined milestones and defined
deliverables to the extent possible. While it is not always
practical to insist on the complete list at the RFP response
stage, especially on complicated long term projects, it
is paramount that it be substantially in place following
interviews with short list vendor contestants and must
contain basic information like deadlines for initial and
final testing as well as the last acceptable date for "going
live" with the project.
Another
large factor is the financial viability of the vendor and
assurances of the availability of sufficient qualified
personnel to do the work in a timely manner and to stand
behind any problems that arise. The RFP document must solicit
enough information for the company to be able to make an
adequate assessment of the staying power of the vendor
since the company will be relying on its expertise not
only for the design and customization of the software but,
likely, its maintenance as well.
Lastly,
there must be a solicitation of specific information concerning
how inevitable snags in the development process will be
handled. Even though each company intends for its RFP to
be as comprehensive as possible, real world experience
suggests that they often are not. Either the company or
the vendor -- or both -- will likely be late in living
up to certain milestones. It is also likely that certain
unanticipated design changes will manifest themselves though
the course of the project.
As
a result, part and parcel of this task is to require a
defined protocol for handling delays, in terms of defining
a procedure for resolving problems and allocating financial
responsibility for them.
Despite
the best-laid plans, an RFP cannot address every detail
but what it can -- and must -- do is set the rules for
the game. A well-designed RFP will address all vital company
needs and require that responding vendors conform to the
company's methodology for dealing with them. It will require
a vendor to provide concrete answers to specific questions
and will insist that the vendor be accountable for those
answers by being incorporated into the final contract.
With
the help of a well-crafted RFP, and a properly selected
consultant and legal team, a company can go along way toward
minimizing the issues that are left for future negotiation
with a vendor and the problems that would otherwise arise
as a result of poor planning. Copyright © Jay Hollander, 2007. All Rights Reserved.
![]()
![]()
|
