" We evaluate the services that anyone renders to us according to the value he puts on them, not according to the value they have for us "

-Friedrich Nietzsche (1844 -1900)

A Request For Proposal (also called in commonwealth countries as an "invitation to tender") is the beginning of the selection process for procuring of services/products from vendors. The Request For Proposal (RFP) approach has been used by the IT industry for several years. This approach allows the purchaser to focus on actual functional requirements rather than being confused with the various technologies supplied by vendors. Time is well-spent defining mandatory requirements and gives a clearer understanding of how & which technologies will achieve the RFP goals

RFI

A vendor's response to an RFP is based on the prospective customer's statements about what resources and results will satisfy its requirements. The RFP should not only help the buyer select a vendor, but also help both the customer and vendor precisely clarify what the product or service must do. A Request For Information (RFI) may be needed when project goals are unclear. An RFI outlines a very broad need and asks for information & ideas. Your organization can subsequently issues an RFP, based on what it receives from its RFI.

L1 not the winner

The conventional process is for a client company to define the scope of work, and for the contracting company to submit a quotation based on it. With such a model, the only possible differentiator between competing companies is price. For complex services/products (as most of them are today), it could mean comparing oranges to apples. L1 should not be on the basis of lowest offer alone. It should be lowest, valid, eligible and technically acceptable.
However a RFP that does not award the contract on a L1 basis needs to define the metrics & set benchmarks and deliverables that can be measured so that the vendors are assured of a fair deal. Suppliers must have prior knowledge of the criteria for vetting the proposals and must be given reasons that explain and justify the particular allotment as well as the basis of conclusion.

RFP clarifications

Vendors will inevitably have questions about the RFP and its contents. While many companies hold general meetings in which vendors can ask their questions in an open forum, thereby permitting all bidders to hear questions and responses, vendors are often reluctant to query the RFP in front of their rivals for fear of betraying their strategies. Thus questions remain unanswered, possibly affecting the resulting proposal. Better to establish a process and deadline for submitting questions anonymously and in writing, and explain the procedure somewhere in the RFP document. Not providing enough clarifications would lead suppliers adding in for contingencies, bloating the final bid amount.

Define the deficiency or need

An RFP should integrate business, financial, technical and legal considerations.
Does your company want to maximise revenue? Increase market share? Reduce costs? Strengthen customer relationships? Improve supply chain management? Increase internal productivity? While these goals are not mutually exclusive, you must prioritize up front or risk devoting resources to the wrong projects.

It's just as important that the RFP explain how you will achieve those goals. This entails good old-fashioned project planning, a discipline IT organizations thrive at. For example, a detailed timeline is key; this timeline should include phases, milestones and deadlines - including penalties associated with missing those deadlines.

A business goal centric RFP demands ability to provide services/products that affect business processes positively rather than to system functionality. Drafting a RFP on processes as opposed to a functional checklist can be a bit difficult on vendors who may be otherwise technically competent and could have responded better to a 'traditional' RFP. However, a vendor that can align its offerings to your business processes is the one that can partner you in the long run.

To RFP or not?

A badly prepared RFP is the first step towards a failed project. Indications of a bad RFP start with vendors calling/mailing lots of questions, the quotations varying a lot from each other & the bids submitted being much higher than the approved budget. The project is most likely to be a mess.

There is a school of thought that does not believe in RFPs. There are many organizations which do not issue them & there are a few IT vendors which do not respond to them (as a matter of policy). They feel the problem with RFPs is that far too much time is spent defining requirements. At the end of it, most RFPs are vague descriptions of what the organization wants. Requirements start getting clearer only when an application gets deployed. The time spent on writing RFPs should be utilized in putting together rough prototypes and mock-ups to get an idea of how the users of the system want it to be. Another approach is to benchmark against similar systems (if existing) that run in other organizations.

The advantages of a good RFP are well known though. Defined processes for working with RFPs are a foolproof way to ensure that the organization enjoys the benefits of the document.

The Federal Acquisition Regulations (FAR) at http://www.arnet.gov/far/ is a good reference source. Many companies follows several minimum Federal Acquisition Regulation (FAR) clauses.

your comments on the article

contact the author

Share this newsletter!
If you know colleagues who would be interested in this newsletter, please direct them to http://www.webizus.com/newsletter.html

To unsubscribe from the monthly newsletter, click on the link below to e-mail your request to us. YOU WILL RECEIVE NO FURTHER NEWSLETTERS from Webizus Technologies if you do.
newsletter@webizus.com?subject=unsubscribe

Webizus takes your privacy seriously. To learn more about Webizus' use of personal information, please read our Privacy Policy at http://www.webizus.com/privacy.html

Disclaimer:
Webizus through the content published makes no warranties or guarantees about the products/ services represented or about the articles presented in the newsletter. The articles by various authors are entirely their own opinion. Webizus holds no responsibility to any damage or loss incurred in any form to any person or organization due to the publication of any of the issues.

Copyright ©1999-2002, Webizus Technologies, All Rights Reserved.

For more information mail us on info@webizus.com

Contact us today for a demonstration of how we can cut down your costs and improve your business:
Email us at: info@webizus.com or call us at +91-9821634476 / +91-22-55910132

Download our corporate profile