A request for proposal or RFP is the modern name for a bid or tender document, asking prospective vendors to bid to provide goods and services, mostly services. The term RFP is used most often in the tech industry. The government and associated sectors still prefer the term tender. An RFP is required when there is more than just price fixation involved in a deal. Typically, RFPs are sent out for project-oriented work that may involve requirement analysis, design, execution, training, management, upgrades and so on. Most organizations will have to generate RFPs at some stage of their existence. Some may need to do it frequently and some only once in a while. Large and established organizations will have standard formats for preparing an RFP or a tender document. This article is aimed at startups and other organizations that do not generate RFP’s routinely, but nevertheless need to create one for that big project.

When do you need a detailed RFP?
You need a detailed RFP when there is a large service component in the offering you are seeking. If what you are seeking is a standard off-the-shelf component like a pump or a bus, then your RFP can be short and to the point, setting out the basic specs and the number of items you need and asking for price quotes. Service elements like customization, installation, training, management, servicing and maintenance, modifications during lifecycle etc introduce variables that different vendors would execute differently using different resources, components and even technologies. That is where you need a detailed RFP.

One of the key objectives of an RFP document is to make these widely differing offerings comparable on as common a set of parameters as possible, so that you can make an informed choice. The other key objective, of course, is that you communicate as clearly as possible to prospective vendors, your requirements, reducing ambiguity to the minimum.

A good RFP document is one that will clearly set out what you expect the vendor to deliver and under what conditions and time frames. It will also tell the prospective vendor why you are seeking the goods and services set out in the RFP and what your objectives with it are. This will help the vendor understand your needs better and to align their offerings with that need. An RFP document also sets out your process and time lines for finalizing a vendor and wherever possible, expected budgets. This provides the vendor with the clarity required for how best to marshal his resources and even whether they have the ability and the willingness to take on your project.

Finally, an RFP is one of the most detailed communications that will go out from your organization to current and prospective partners. Thus, it is an important tool in creating an impression about your organization in them. To that extent, a complete and well-written RFP that is neatly and professionally presented goes a long way in producing a professional image about your organization.

Before you start writing the RFP
An RFP is not something that you wake up one fine morning and start writing. A lot of homework has to be done to understand what exactly is it that you need and what the market offerings are before you start writing an RFP. You need to also understand where all your requirements differ from standard market offerings, because the RFP after all is about filling those gaps.

An RFP document is a combination of the technical, financial and legal requirements, communicated well, of your project. So, it is highly advisable that a team of people bring these skills (yes, including English skills) into writing an RFP rather than leave the responsibility to some junior techie (or senior financial expert for that matter).

Step 1. Defining your business need
One of the major pitfalls of an RFP arises out of this combination of needs—technical, financial and legal. The document could well turn out to be a treatise of technical, financial or legal requirements, leaving out the original reason for which it is being crafted —the business need.

So, the first step to writing a good RFP is to define your business need as clearly as possible. “Create a web 2.0 website,” is short and sweet, but defines no business need. “Create a website that will enable users to search and buy holiday packages as well as review them,” is equally bad. “We are in the business of providing holiday-related services, primarily holiday packages to exclusive destinations. Our website is our primary interface with our customers, who come from across the globe. It has to attract prospective customers, retain existing ones and enable transactions and feedback from them. We expect to do 500 transactions a day at an average value of Rs 10,000 a transaction. We expect to grow this five-fold in the next two years,” is a much better statement of business need and not only tells prospective vendors what your business looks like, but also gives them an idea of the the scale and scope of what they are expected to do, as well as other players they can compare you with.

Step 2. Defining the scope of work and duration
Once the business need is defined, we move on to what exactly do you need the bidder to do? Do you have a design that you want them to execute? Or is design part of what they are supposed to do? Are they supposed to create and hand over to you or are they expected to run it for you? What about training your personnel to work with it? And documentation? One of the important factors that many people forget to include in their RFPs and then end up paying extra for transferring from your current setup and systems to the new one. Let's say that you are creating the RFP for that holiday packages site we just spoke about.

Do you have an existing site that has content that has to be transferred to the new one? If yes, will the new vendor have to do it or will it be the responsibility of someone else? If transferring content is part of the RFP, what are the conditions for the transfer? For example, you could want existing URLs to be preserved so that your search engine rankings and search engine marketing efforts are not wasted. You may want links from the outside world to be preserved or otherwise gracefully handled and so on.

Similarly, what is the end point at which the bidders role ends? Is it even supposed to end? Is that point defined in time or as a milestone or as a combination of both. For example, “this contract will end with the completion of the new travel portal and migration of all existing content and links”. Or, “this contract for creating and managing all technical aspects of a travel portal is initially for two years and is renewable at the end of that term.” When the bidders role ends, whom are they supposed to handover to? What all are they to handover at such end point? Example “On completion of the project, the vendor is to handover all management, control and documentation of the system to our internal technology team and get a proper sign off from them.”

Step 3. Defining the budget
Many organizations prefer to leave this unstated and to handle this during negotiations. There are benefits to this approach—the most obvious being that you do not have to spend time and energy figuring out how much the system will realistically cost—and the expectation is that with multiple vendors quoting, the quotes will tend to be around a figure that is the actual market cost for the project. But sometimes, this can go crazy. I have seen responses to RFPs from similar vendors that varied by as much as 90% in the quoted prices!

There are other arguments too in favor of at least defining a budget if not actually stating it in your RFP. The first of these is that the more you investigate the market to arrive at a realistic budget, the more your knowledge about potential offerings, vendors and their costs. This helps you subsequently during the negotiation stage. Second, this investigation will help set your expectations. What level and caliber of vendors can you afford? You may want the best in the world to build your application. But what if your budgets allow only for tier-two or tier-three vendors? Third, when you indicate a budget, you are giving a clear picture to vendors on what your expectations are and depending on how realistic your budgets are, how well versed you are with the project and its requirements.

Step 4. Who should be invited to quote?
This is a very critical question, and rather than focus on which names, we will focus on which class of players should be invited to quote. Naturally, you would be looking for vendors with experience in delivering similar projects. But it does pay to keep a look out for newer players with the ability to deliver. Newer players will not only give you better pricing, but will also be able to devote more top management resources to your project. On the other hand, you need to ensure that the bidders are not so raw that you end up doing their work for them.

If you decide to invite bidders from across industry tiers (to take an example from the software industry, if you were to invite say a global top 3, an Indian top 5, an Indian top 100, a local software firm and a set of freelancers to bid for the same project) you are setting yourselves up for confusion, if not disaster. For a small project the top tier players will not respond (unless there is the carrot of a larger one at the end of it), and for a large one the freelancers just would not be able to scale or provide the organizational support for. Also, the cost structures and delivery expectations from these players are so widely different that there can be no comparison between them.

Depending on the complexity of your project, your budgets and your service level requirements, you need to choose the appropriate tier of vendors to bid for your project. Another thing that you need to keep in mind is that large vendors tend to subcontract parts, if not all of the work, and could end up just doing project management. In many complex projects, including infrastructure projects (buildings, roads, bridges, ports, software infrastructure etc), you many not have any other option.

Key elements of an RFP
An RFP has five key elements

1. Overview and scope of the project
2. Vendor qualification
3. Technical and functional specifications
4. Financial considerations
5. Legal framework

We will now examine each of these in detail.

Overview and scope of the project
This is where you tell a prospective bidder about yourself, your business need for the project, an overview of what all it entails and the expected deliverables from the vendor and the project itself.

As this section is about you, it is easy to get carried away, filling it with irrelevant achievements, awards and biodata of key personnel. Desist. For all that you can provide links to your website.

Keep this part simple, elegant and to the point.

Vendor qualification
This section sets out what qualifications are required in a vendor who wants to bid for your project. Given that in most cases you are going to be inviting selected vendors to bid, do you need a vendor qualification section? Yes, of course. Even if all vendors bidding are known to you, you may not know their capabilities for the current project. So, it is essential to set out the required vendor qualifications. You may need your vendor to prove the ability to take on a project of this scale or show expertise in having handled work of a similar scope. You may need your vendor to have a certain financial size (turnover for the last three years or number of permanent technical and project execution staff) or to be located in a given geography. You may ask for a list of previous similar work and for references from past clients. You may also set out disqualifications, if any, for example, vendors who work with your competitors should not bid.

In this section you should also specify as clearly as possible how you will go about choosing whom to award the project to. You could for example say that you will follow a three stage process to shortlist parties for final negotiations—Vendors who qualify as per clauses given are shortlisted for evaluation of their technical bids. Vendors whose technical bids pass muster will have their financial bids evaluated and the lowest bidders will then be called for negotiations. Or you could say that all bidders who bid and qualify will be called on to make presentations about their solutions and for negotiations. Or you could, in cases where the technology is the same and is being defined as part of the RFP, say that only the lowest bidders will be called for negotiations and so on.

In response to this section, the vendor may choose to do what you were told to desist from in the previous section. Some vendors will try and kill you by the sheer weight of material they provide to prove their credentials and suitability for the project in hand. The way out of having to wade through all that is to ask specific questions in a questionnaire format.

Technical and functional specifications
This is the core of your RFP and will in all probability be the largest section.

There is always a debate on how much to disclose. I am personally on the side of disclosing as much as possible, so that there is no need for back and forth communication, with different bidders getting different pieces of information and no room for over provisioning or under provisioning, both of which will work to your disadvantage.

It is possible that you are defining the technologies, the designs and the loads and asking the bidders to execute according to design. It is possible that you are providing one or two of these elements and asking the bidders to create the rest as part of their bid or the project itself. The less the information you provide at this stage, the more the confusion and the more the variety of options you will get, leading to confused decision making. For example, if you just specify that you want a road made from point A to point B, different vendors would assume different material—mud road, gravel road, concrete road, bitumen surfacing, different loadings—single lane, double lane, six lane and even different distances, leading to complete confusion in decision making.

So, in this case, you need to provide enough design inputs. “A four-lane bitumen topped road is to be built from point A to point B as per the alignment given in the attached map. This road should be built as per relevant Indian standards for the following loading conditions,” or the actual design itself in order to get bids that are comparable with each other.

Comments (5)

Subscribe to this comment's feed

test
written by test, February 07, 2010

test nsd fsd fsd fs df sdf sd fsd fsdf s df dddddf dfdf

report abuse

vote down

vote up

Votes: +0

RFP - is live
written by G Shankar, December 19, 2009

I agree on the point that noone is interested to write an RFP. But, if you visit big corporates, there are many wastages due to undefined or wrongly defined projects.

How can one buy without defining what you want? When people fail to define this, they end up doing the procurement work on their own. The result may not be a commercially advantageous or risk free process.

Now, the trend is to dedicate someone else to write the requirement. You can eliminate RFP but still you will end up doing this with a different name :-)

report abuse

vote down

vote up

Votes: +0

How to Write a Good Request for Proposal (RFP)
written by Udit Chaudhuri, November 27, 2009

This is a very welcome article, on a dying competency.

It is amazing to see many administrators spending millions on capital equipment and techno-commercial services without doing their managerial homework, taking providers or vendors for granted.

In case of inputs required in a creative or NPD project, one needs to develop a brief.

report abuse

vote down

vote up

Votes: +1

Re: Ashish Kumar
written by Krishna Kumar, July 28, 2009

Hi,

Thanks for your comments. You are right. New product development can hardly be done on the basis of an RFP. But this article is not limited to web development :) While I have used software/ website development examples,I have also used infrastructure examples. RFPs are used not just in web development, but also in other industries and verticals.

How many infractructure projects can be done by Q&A and storyboarding via a functionality / priority matrix?

Even in web development, talking from a client perspective (as against a vendor / contractor perspective), the approach you advocate assumes significant elasticity of budgets, which in today's world may be an unaffordable luxury.

report abuse

vote down

vote up

Votes: +1

Founder
written by Ashish Kumar, July 25, 2009

KK - with due respect, I think the RFP process is obsolete. In today's Web 2.0 world, you dont create RFPs - you create questions, get these answered, create a functionality / priority matrix and get to storyboarding.

Creating a RFP for maintenance / support projects is fine, it just doesnt work in a new product development with need for agile development.

I feel this discussion is moot that way.

report abuse

vote down

vote up

Votes: +2