The Case for RFPs (When Done Right...)

By Bud Porter-Roth at 2002-05-14 00:00:00 |

Introduction

An RFP is a tool used by governments and businesses to purchase products and services by promoting competitive proposals among vendors. Through this competitive process, vendors offer an array of potential solutions and prices and compete with each other to win business. Buyers evaluate the many different vendor solutions and pick the one that most closely fits their project requirements and budget.

In some industry sectors, RFP has become something of a dirty word, but I espouse RFPs as a vehicle that allows both the buyer and the vendor to establish a dialogue and to work from the same set of rules, requirements, schedules, and information. The opportunity to have this dialogue is an important element in the process because requirements are not always clear and the vendor, as the expert in a given solution, is allowed to question and interpret what is being request by the buyer. Conversely, the buyer has the opportunity to question and clarify issues in vendor proposals to ensure that the product fits the need.

Proposals, by their very nature, are a vendor's interpretation of an RFP's requirements. RFPs, therefore, should promote a diversity of thinking among vendors and encourage them to provide unique and different solutions.

RFPs are most useful when:

• Multiple (different) solutions are available that will fit the need
• Multiple vendors can provide the same solution with different implementation scenarios
• Exact solutions for the project cannot be clearly specified
• The project requires different skills, expertise, and technical capabilities from vendors
• The problem requires that vendors combine and subcontract products and services
• Lowest price is not the determining criterion for award
• Final pricing is negotiated with the vendor based on final schedules, products, implementation, training, etc.

When a vendor is awarded a project, both the RFP and the proposal become the foundation for a working relationship between the two companies. This relationship allows both companies to operate against the same agreed-upon solutions, requirements, and schedules based on the RFP and the proposal. It also provides both companies with a starting place when there is a need to modify the requirements, or the schedule, once the contract has started.

Getting the right mix of technical requirements, project/management requirements, and pricing is a complex task which requires that the RFP team not only clearly understand the "problem," but also understand the technology behind potential solutions.

Anatomy of an RFP

One of the most typical challenges vendors have in responding to an RFP is that the RFP has no basic outline to follow. Requirements can be "hidden" anywhere in the RFP and can sometimes be mistaken for general statements about the intended application. For example, in a paragraph describing who the users of a CMS system are (not the administrators or content providers), a requirement for a development tool is inserted.

The best defense against poor proposals is to have a strong well organized RFP that vendors can follow. Broadly speaking, a basic RFP consists of the following sections:

1. An overview or summary statement of the problem and the needs for the procurement -- similar to a sales proposal's executive summary
2. An RFP administrative information section
3. A section that provides vendors with definite technical requirements and information to enable them to understand the issues and write a firm proposal
4. A section that states the requirements for managing and implementing the project
5. Vendor qualifications and references
6. A section that allows vendors to put in information they feel is relevant although not required or requested in the RFP.
7. A section that specifies how vendors are to provide the pricing information
8. A contract and license agreement section that contains the purchase contract, non-disclosure agreements, and other legal documents
9. Appendices that contains bulky but relevant information such as network diagrams, technical requirements studies, and project plan outlines

Typical Pitfalls to Avoid

Below is a discussion of the most typical problems that befall companies when writing RFPs and selecting vendors.

1. Not enough time is spent on vendor education. Not all vendors are created equal. A vendor's greatest fear is that a solution has already been chosen and that they are wasting their time. This manifests itself when the RFP inadvertently favors a technology or solution because the team had the most education on that particular technology.



2. Poorly defined requirements. This is typically due to two basic reasons. First, see item one above. Second, not enough time is spent understanding and documenting the internal requirements. This results in requirements that are so broadly stated as to be meaningless to a vendor. A recent RFP I saw requested that the CMS support output to different formats and devices and when questioned as to what specifically was meant, the buyer compounded the mistake by requiring that the CMS support not only current formats, but any future formats that may be developed within the industry! ("Wow, so I might as well file for Chapter 11 right now and get it over with," said one would-be vendor respondent.)



3. Poor coordination among your key stakeholders. For example: did you forget to bring in the test group until after the contract was awarded? In one RFP I reviewed, much time was spent on describing the content developers, the content administrators, the IT group itself, but almost no time was spent describing the actual users of the system -- the people who would use the system to obtain the information they needed. When vendors questioned the RFP team about the "users of the system" the RFP team could not adequately define who a user was, what a user would do on the system, how many users they were, how many hits were expected, what the average length of time spent on the site would be, etc. In their haste to completely define the "solution" the RFP team forgot the audience. One RFP team member even ventured that since there was not a current system in place, she could determine who would use the system and how.



4. Providing requirements that can't be adequately defined and therefore proposed. This typically involves using requirement statements that are something like the one above that required vendors to support all existing formats (and these were not defined) in addition to possible future formats. Or, a common mistake is to require something like "all products should conform to all AIIM CMS standards". Without defining the specific standard or set of standards, many vendors will be absolutely clueless as to which standards they meet and which ones they don't meet. (And hence this typical response: "Oh to hell with it, say we meet them all -- they will never check anyway.")

Given ambiguous or unclear requirements, most vendors will simple say "yes" and if questioned will bring out all of the issues involved and make the matter so complex that it will never get resolved. This is in the spirit of, "Better to ask forgiveness then to ask permission" because once a vendor has been selected, there is little chance that they will be unselected.

Conclusion

Writing an RFP and reviewing proposals is a very resource- and time-intensive activity. The costs for writing and completing an RFP may be greater than $50,000 and may span a 6-month period. Given the significant investment involved, the RFP process should be thorough and must be allotted the proper amount of resources and time.

Sending out an RFP is only the first step in the project, reading proposals, establishing evaluation criteria, visiting reference sites, performing a live test demonstration, and negotiating a contract will all be steps toward a final selection.

Note that while your project may be significant to you, even in a down economy it may not be as significant to a vendor. Vendors are under no obligation to respond to your RFP if they feel it is poorly written, a technical "fishing expedition," not properly funded, or if there are opportunities that appear to be better than yours. Vendors will be selective when they receive multiple RFPs and will work only on the ones that appear to be winnable.

Remember that the advantages of using an RFP far outweigh the potential problems of dealing directly with vendors:

• An RFP requires the RFP team to examine the problems and issues in greater detail than would normally occur.
• An RFP forces vendors to create competitive solutions that not only respond to the RFP requirements but go beyond them thus providing additional value for a given price.
• An RFP that does not favor one vendor over another will allow all to compete fairly from the same set of rules and requirements.
• Because vendors are working from the same set of rules and requirements, it will be easier to understand the differences between proposed solutions..
• Having similar, but different solutions, facilitates the evaluation of competitive solutions.

Finally, note that the selected vendor becomes another member of your team and in some cases, almost part of your company. Build a vendor relationship on your mutual understanding of and agreement on the requirements and the work to be performed.