If you are not in a position to provide the design and if the design is also part of the project, then enough data should be provided so that all bidders design to similar specs. “The current expected load on the website for holiday-related services is 5000 unique visitors per day. We expect 500 of these to transact at the site and each transaction to have an average value of Rs 10,000. In two years, we expect these numbers to go up five times.”

In case you are just providing the data required for design, then you need to ensure that all the data required for design is provided. In the holiday website example, are you going to host photos and videos of the destinations? How many? What size? How many downloads do you expect? Are you going to be doing newsletters? How many? At what frequency? In the example for the road, what is the rainfall in the area like? Does the area experience flooding? How many bridges of what span and class is required and so on.

Functional specifications is another set of inputs you need to provide or explicitly ask the vendor to create. Basically, this is what the user experiences. In infrastructural projects, this will be the peripheral works—the lighting, the paints, the embankments, the landscaping, the sidings, the landings and so on. In software parlance, this is called the URS or user requirements specification—the screens, the navigation, the work flow and so on.

As part of the technical specifications, you will also indicate the tests that will be done at various stages during the project, including the final acceptance tests. In infrastructural projects, these by themselves can become a voluminous appendix.

Another important element to be defined here are the service level agreement (SLA) levels. These will obviously vary on a case to case basis. You should also define how these SLAs will be measured—usually by third-party measuring agencies or tools or by tools to be provided by the vendor. Penalties for breach of SLAs are detailed along with other financial parameters.

Financial considerations
This is the place where you ask the bidder to quote his price. Depending on the complexity of the project and the discrete elements involved, you could ask for a break up of the price for the different elements of the project like design, training, management, break-fix and so on. Besides just the price, you will specify many other related issues in this section. Given the global nature of companies, you may need to specify the currency or currencies in which payments will be made and how the exchange rates will be calculated, if applicable. You will specify how billing will be done—one time billing, billing against achievement of defined milestones, time-based billing, equal monthly payments and so on, as also in whose name the bill will be raised and to whom and where it will be submitted to.

You also need to set payment expectations correctly—for example, "payment will be made 45 days after receipt of your bill at our office, subject to defined project milestones being achieved.” You may also want to specify how you will make the payment—By cheque payable at par, by bank transfer, by bankers cheque, by charge to a credit card and so on. In case of cheque or draft, you could even go to the extent of setting down the mode of delivery—“Cheque in the name of vendor will be couriered from our office within 45 days of clearance of your bill by the projects division.”

SLA penalties are also defined here. Actual SLAs may be defined as part of the technical specifications. If you are not very sure about it or if there is a wide variation amongst vendors quoting for the project, you may leave it to the vendor to define SLA terms and penalties for breach. In this case, you have to explicitly state so. "As part of the bid the selected vendor will define (subject to mutual acceptance) acceptable SLA levels and penalties for breach of the same.”

It is the rare project that stays exactly to originally stated work. There is no way you can estimate beforehand all that is required to be done. Variations will happen as the project gets executed that will take the deliverables from the vendor beyond what was agreed to initially. In the software industry, they even have a nice term for this —change request. A change request means extra billing for the vendor. And if your RFP and project documents are not carefully done, the vendor could actually make a killing out of such change requests. So, if your RFP includes the project deliverables, you have to ensure that at least 85-90% of your needs are covered. Equally important, the mechanism for arriving at the costs for such change requests and for future additions and deletions will have to be part of the RFP. It can be as simple as stating that this mechanism will be worked out during actual negotiations (and remember to actually do so) or you can set out the actual mechanism for doing so.

If you know for sure that there will be some future additions/modifications, but are not sure about the quantum, then you should ask for unit price quotes for each of them.

If brought out items and services are a major component of your project costs and if the vendor is doing nothing but buying and supplying them, then, you need to take a hard look at how to cost for them. Remember that for all brought out items, the vendor may be adding a management fee and on top of that there a service tax (which may be offset-able).

That brings us to that inevitable item—taxes. Taxes can be a significant add-on to your project costs. So, your RFP has to be clear on whether the quoted prices are inclusive or exclusive of taxes. In the case of multi-country transactions, this could get even more complex.

Legal framework
RFPs (and their response) for large and complex projects, like say the outsourcing of a telco’s network provisioning or management for a decade will have legal clauses running into hundreds of pages attached to them. Even if your project is no where as complex, it is still desirable to have a basic legal framework included in your RFPs. This could be as simple as stating the effective jurisdiction—“All disputes arising out of this project shall be subject Indian laws and to the jurisdiction of the High Court of Karnataka.” You could also provide for dispute resolution mechanisms and arbitration methodologies as may be required.

Non-disclosure agreements are also part of the legal framework. If you are disclosing proprietary or confidential information in the RFP itself, then a non-disclosure agreement about the contents of the RFP should be signed before the vendor receives the RFP.

You should include information on how the contract can be terminated during its course and what is expected of the vendor in case the contract is so terminated. This could include handover of all project documentation and other material, transfer of project administration to a new entity etc

In some instances, an escrow agreement will be part of the legal framework. Escrow agreements come into the picture only when there is a maintenance obligation on the vendor. An escrow agreement is about entrusting proprietary vendor information relating to the project, like designs, source code, list of material used etc required to keep the project up and running, into the custody of a third party. This information will be released to you if the vendor ceases to exist or is otherwise unable to fulfill their obligations under the contract.

Presentation
The way you present the RFP has a big role in the image you will be creating about the level of clarity and professionalism in your organization. A well-written and professionally-presented RFP is easy to create. Just follow these steps.

First of all, the RFP should be neatly divided into the five sections defined earlier (though not necessarily in the same order) with elements of one not running into another section. Thus, parts of the technical or financial requirements should not come under, say, legal requirements.

Second, identify each clause with a heading that clearly states what that clause is about and uniquely number each clause and sub-clause so that vendors can easily refer to an item by clause number rather than quote it back in full.

Provide a table of contents right in the beginning, listing each item, its clause or sub-clause number and the page number. Most modern word processing packages can automatically create a table of contents for a document based on styles you apply to headings. Enable page numbering in the document so that it is easy for anyone to navigate through the clauses and sub-clauses of your document.

Provide enough clear space between sections and clauses for understanding. Ideally start a new section in a new page and if a new clause is starting at the end of a page, move it to a new page.

Create a cover page (first page) that sets out what the RFP is for. For example, “RFP for building a holiday packages web portal and maintaining it for a period of two years,” and the name of the organization sending out the RFP. The first page should also give the name and contact details of the person to be contacted for clarifications and the process for submitting bids. You could also indicate your budget on the cover page.

Finally, documents tend to get distorted when opened in a different word processor or even a different version of word processor. So, it is preferable to send out the RFP to the vendors as a pdf document. Most word processors can save to pdf format or you can use software like primopdf and print your document as a pdf.

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: +0

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