Real Estate

Facilitate the real estate buying or selling process with our online applications.
Buy/Sell Co-Op
Buy/Sell Condo
Buy/Sell Home
          1031 Exchange

Form your corporation, limited liability corporation, or limited liability partnership online.
Form a Corporation
Form a LLC
Form a LLP

Protect your businesses trademark. Apply for a trademark with our online application.
Register a Trademark
        Trademark Search
        Trademark Monitor

Refer this Site


How to Create the Optimal "Request for Proposal" (RFP)

By Jay Hollander

Jay Hollander, Esq. is the principal of Hollander and Company LLC,, 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.


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.

  Bookmark     Save


Home   |   About Us   |   Contact    |   Sitemap   |   Search   |   Terms of Service, Privacy Policy and Disclaimer   |   Clients Rights

© 2000-2023 Hollander and Company LLC. All Rights Reserved.
By using this web site you agree to the following  Terms of Service, Privacy Policy and Disclaimer

Thank You

Thanks for your interest in our articles. Kindly assist our efforts to bring you more relevant information by providing your name and email address below to be added to our newsletter and email distribution list. You will then click through to your article. Rest assured, we do not give out your information to unrelated third parties, as provided in our privacy policy and you can unsubscribe upon receipt of any unwanted newsletter or informational email from us.

Your Name

Email Address

Security code

Submit and View Article