What is a Request for Proposal? When is an RFP appropriate and how should the RFP process be used? What does a vendor expect to see in an RFP from an institution? What should an institution expect from a prospective vendor in response to an RFP? What criteria go into the final vendor selection process? This paper describes the content and the effort that goes into a successful RFP process on both the client side and the vendor side.

Keywords: Request for Proposal, RFP, project management, project planning, procurement

Introduction

As with any complex project, it takes forethought to put a Web site together. Writing an RFP is a good way for an institution to focus on its goals and to extract the essence of those thoughts into a clear direction of how to achieve those goals. When properly written, the Request for Proposal is a powerful tool for selecting the most appropriate vendor and solution, for establishing honest straightforward relationships, and for accelerating the contract process. However, the biggest source of confusion for vendors (and disappointment for institutions) is probably the poorly written RFP. The thoroughness and accuracy of your RFP is what the vendors will base their proposals on. It is therefore essential that your institution create an RFP that will attract wellthought-out and reasonable proposals that will set the basis for a comfortable future working relationship.

What is an RFP?

An RFP is a standard tool used by institutions to purchase services though a competitive process that offers an array of solutions and prices. A typical RFP is a 20-30 page formal written document describing the scope of a given project. It includes the pertinent information that vendors need in order to provide a comprehensive proposal and represents a certain amount of time, resources, and money in order to communicate an understanding of the needs of the institution.

RFPs are typically sent out after identifying a short list of preferred vendors, making prior contact with those firms, and often after a nondisclosure agreement (NDA) has been signed. Many reputable design firms have a policy against responding to RFPs that arrive without some form of prior communication.

Ideally, RFPs should be sent out a minimum of eight weeks before the established submission date. Crafting creative, detailed proposals takes time and it is to the institution's advantage to allow vendors ample time to hold internal brainstorms, do research, and work through the cost estimate.

An RFP is an appropriate tool when choosing one firm among several that your institution would be happy to work with. It should not be used to qualify groups, to obtain speculative design work, to plan your budget, or as a "fishing expedition" for ideas in place of thinking through the project beforehand. It is apparent to experienced design firms when they have received what Siegel (1997) refers to as a "shotgun RFP" by an unprepared institution that has made no prior contact and is likely sending the RFP to 20 other firms in the hopes of obtaining a design direction. Speculative design work is in neither party's best interest. It is off-putting to vendors and results in design for design's sake instead of design in the context of your institution's project. It is, however, appropriate to give vendors an opportunity to express their creativity in some way. For example, ask them to provide short case studies of previous projects showing how they arrived at the solutions.

In addition, vendors are under no obligation to respond to an institution's RFP if they feel it is poorly written, not properly funded, or hints at the fact that the institution has already selected a design firm and is simply fulfilling a bid requirement. Busy firms receive one to three RFPs a week. Because of the substantial time and resources involved in providing a thorough proposal, vendors must be selective and respond only to the ones that appear to be "winnable."

Key Ingredients of an RFP

The RFP provides a structure for institutions to put their project requirements into so that vendors can understand and use the information to create a response. It spells out how the project should be implemented, what the first steps will be, and how the institution will measure success. Some Web projects focus more on technical backend expertise and some on design skills, but, broadly speaking, a basic RFP for a Web project should consist of the following sections:

Confidentiality Statement

The confidentiality statement lets the vendor know that the information contained in the RFP is proprietary and should not be shared with other institutions, vendors, etc. Many institutions bypass the NDA requirement mentioned previously by simply including a statement of confidentiality. Your institution's legal department should be consulted on this.

Project Overview

The project overview includes the administrative information related to your project, such as a brief background of your institution, a brief description of the project, the project budget; and any project deadlines, such as when the proposal is due and when a selection will be made. The project description should briefly describe what you are trying to accomplish in the form of Mission, Goals, and Objectives, and what the overall experience of the site will be. Institutions should have a clear vision of what the visitor experience should be like, but may not necessarily know the explicit details of how the experience will be developed. The description should also discuss the intended outcomes and how success will be measured.

The project overview should also address budget. The budget should be revealed to the prospective vendors so that they can give honest estimates of what they can deliver. You know what your institution is willing and able to spend: share that to get an appropriate bid. Provide a range, if not the exact dollar figure, to give the vendors the opportunity to show examples of what can be done in each range or in phases.

If the design firm is asking questions about the 'scope' of your project, they're trying to uncover your budget. Why not get the relationship off to a good start and tell them?

It is a waste of everyone's time if you describe something for a million dollars but know you can only spend $10,000.

It is also often a good idea to require potential vendors to let you know if they intend to bid on your RFP. This can be in the form of an e-mail, letter, or form that you supply, requesting return to you by a certain date. Porter-Roth (2002) provides further explanation and a sample notice of intent to bid for reference.

Target Audience/User Requirements

In order to develop a successful site, it is essential that you identify and describe your intended audience. Who are the site's main users, now and in the future? How comfortable are they with technology such as plug-ins, downloads, etc? How much traffic do you anticipate?

Design Requirements

The design requirements describe what you know about the "look and feel" of the site. What image are you trying to convey about your institution? Use descriptive words to describe this for the prospective vendor. Inform the vendors as to whether you have any identity guidelines/style guides they should be aware of, and if so, supply copyies. Let them know if there is a specific color palette and/or type treatment you prefer. If you know that you would prefer that Flash be incorporated or avoided, include this here.

Think about how much innovation/creativity you expect from the vendor. Are you completely open, or are you fairly set in your ideas and just need implementation? It is best to establish this from the beginning.

It is also helpful to include URLs of sites you like and dislike, explaining why, either here or in the Appendix.

Technical Requirements

The technical requirements section describes specific server software, operating systems, application servers, databases, etc. that must be accommodated. User connections speeds, browsers, and platforms should also be specified here. Make it clear that vendors should prepare their proposals with the specified environment in mind.

Functional Requirements

The functional requirements section outlines any preferences for or against specific technologies, identifies legacy systems to be taken into consideration, describes screen resolution and media types, calls out the need for e-commerce components and database-driven content, and provides an overview of the visitor experience. For example, if you know you want interactive features, describe them here and explain how you envision they will work. If you plan to include content that will need to be updated frequently, say so in this section so the vendor knows to describe administrative tools. The more detail here, the better. The RFP needs to provide enough information to let the vendor understand the issues and expectations and write a confident proposal.

Project Scope

As part of the pre-RFP activities, your institution's RFP team will have conducted a requirements analysis and determined the scope of your Web project. Requirements typically addressed in this section include content, tasks, and maintenance.

Content elements should be described in terms of the name of the feature, section, etc. and their related characteristics, such as HTML, database-driven, Flash, download, etc. When redesigning an existing site, it is helpful to approximate the number of pages on the current site so that the vendor gets an accurate view of the potential expansion or consolidation.

Tasks specify what your institution expects the firm to do, such as create the "look and feel," rework the information architecture, integrate any third-party software, create administrative tools, etc. Tasks should also describe what it is you do not expect the vendor to do, such as write copy, produce media elements, etc,. and describe what you will provide the vendor in terms of assets.

Maintenance addresses what your institution both can and can't handle post launch. If you know that individual departments will be taking control of their own content, then specify your admin tool needs here. If it is clear that your staff will need some additional help maintaining the site, then it is a good idea to describe your long-term needs and ask the vendor to price out a separate maintenance agreement.

Proposal Requirements

What do you want vendors to tell you about themselves in regard to your project? How do you want them to express this information? Institutions are entitled to expect a well-written proposal specifically geared toward their RFP. Boilerplate responses should be thrown out because the vendor who disregards your proposal requirements will most likely also disregard your project requirements.

Since the RFP team will be reviewing multiple proposals, it is helpful to specify how vendors should organize the information for easy comparison. The benefits of being able to compare proposals in a common format will make your job much easier when you are trying to select a qualified vendor.

Not all of the suggestions offered below will always be applicable to your RFP. Your team should modify these in any way that would help clarify your RFP.

In addition, keep in mind Porter-Roth's (2002) suggestion that the instructions "should be fair in their demands and that suppliers should not be required to shoulder unnecessary expenses as part of their proposals." Proposals should not require a disproportionate amount of work for the vendor in relation to the scope of the project and the size of the budget. Expect that the proposal is just the tip of the iceberg; it should show the institution that there is more where that came from. Realize that vendors respond to RFPs repeatedly for no pay and must therefore restrict spending undue amounts of time preparing them.

For exceptionally large projects, Morris (1998) suggests considering a paid pitch to offset the cost of preparing proposals, since quite a few proposals do not result in winning the bid.

Protocol for Submitting

Outlining in detail how, when, and where you want the proposal delivered prevents unwanted follow-up calls and e-mails. Vendors should be told

If your institution already has a site, it is often helpful to create a secure project area with an electronic copy of your RFP, a Frequently Asked Questions (FAQ) section, and any other supplemental materials that might help the prospective vendors understand your project more fully.

Your institution might also consider accepting proposals in electronic format instead of requesting multiple bound hard copies to help ease the cost of responding to RFPs. Printing, binding, and postage makes up a large part of a vendor's annual operating costs.

Project Management

Vendors expect the RFP to specify who the institution's main project contact will be, who the key decision makers will be, and who the additional team members will be. Think about this carefully. Do you have an appropriately experienced project manager? Are you being realistic about your internal staff's capabilities? Be honest with the vendor about the amount of hand-holding you'll need so they can help fill in the gaps. Tell them how the tasks will be divided between your internal team and their team. Inform them of any third-parties (subcontractors, etc.) that will also be a part of the project.

Evaluation Criteria

Evaluation criteria are the agreed upon methods of measuring the proposals you receive. Vendors understand that their proposals will be judged against an established set of requirements. But does that mean that institutions should let vendors know exactly what the evaluation criteria are? Porter-Roth (2002) contends that there are two schools of thought on this: one that says vendors should be given few, if any, evaluation criteria; and another that says that vendors should be given as many as possible. The debate lies in the fact that evaluation criteria can influence how vendors respond to the RFP, possibly to the detriment of other requirements. Instead, Porter-Roth (2002) recommends including "hints" relating to business goals and objectives that are broad enough to apply generally but do not reveal the evaluation criteria specifically.

Both Porter-Roth (2002) and Siegel (1997) offer sample evaluation matrixes which may be helpful for objectively deciding on a vendor.

When it comes to pricing, institutions should expect that vendors reply realistically and should not write off more "expensive" vendors without a discussion. A good vendor will tell you if your budget and/or schedule are unrealistic. Don't punish them for that – dialogue about what and how changes can be made, and clarify any false assumptions or misunderstandings. After all, you get what you pay for. Vendors may say they can complete your project for the amount of money you have and in the timeframe required, but then once you sign the agreement and begin work, every suggestion you make becomes a costly change order.

Check references and credits carefully. Don't automatically go with the large firm or the "household name." Look for the team that will give you the most innovation and passion for your dollar. Find out what the vendor's team actually did on their prior projects. Oftentimes the portfolios of the larger firms will seem impressive, but the people who created their featured projects may be long gone. Do your homework; don't be afraid to ask questions.

It is also a good idea to have a face-to-face meeting as part of the evaluation process to make sure that the chemistry is good. If you have fun with the vendor, a positive feeling is guaranteed to translate to the final product.

Schedule for Review

Establish a schedule for review and make your best effort to stick to it. Let the vendors know when the proposals will be reviewed, when the successful candidate will be notified, when you will begin contract negotiations, when you expect to begin the project, and when the site is expected to go live. Be sensitive to the fact that vendors need to schedule staff and resources to complete your project in the prescribed timeframe. Being indecisive about selecting a vendor or kicking off a project inconveniences the vendor and makes your organization look unprofessional.

Appendix

Include any additional relevant materials such as drawings, charts, graphs, style guides, and URLs of sites you like and dislike (with explanations) in an appendix.

Getting from Here to There – What goes into preparing an RFP

Writing RFPs are resource and time-intensive! Porter-Roth's (2002) Reverse Planning Calendar indicates that it is not unusual for the process to take over half a year from project start to site launch. An unorganized approach can take twice that long.

The typical tasks associated with writing an RFP can be broken down into pre-writing activities, RFP preparation activities, and post-RFP activities.

Pre-writing:

Post-RFP

Conclusion

A successful Web design project begins with a well-thought-out plan and a clear understanding of the requirements by both the institution and the vendor. Creating an RFP that accurately represents your needs in a manner that a vendor finds useful can take months and involves a good number of your resources. Investing the time upfront to write a comprehensive RFP will save you time and money in the development stage. It also expedites the contract process and establishes clear, honest communication from the outset of the relationship.

References

Porter-Roth, Bud. (2002). Request for Proposal: A Guide to Effective RFP Development. Addison-Wesley.

Siegel, David. (1997). Secrets of Successful Web Sites: Project Management on the World Wide Web. Indiana: Hayden Books.