When a prospect presents you with a Request for Proposal (RFP), there are a number of factors to consider before you respond. IT consultant Chip Camden explains.
Larger prospects, especially government agencies, often follow detailed policies and procedures for procuring suppliers, including consultants. Sometimes the procedure includes a document called Request for Proposal (RFP). An RFP announces to potential suppliers that a company has a need and is in search of someone to fill it. Suppliers are expected to respond in a way that will inform the prospect's choice of vendor. Thus, the RFP usually includes a brief statement of the project, followed by a (usually lengthy) section of questions for suppliers. Here are guidelines for formulating an RFP response.
First, make sure you understand the process (not all entities follow the same flow).
- What is the deadline for responding?
- Is your response your only chance to provide input?
- Are you allowed to ask for clarification?
- Are they expecting a quote, or is the RFP just a screen, to be followed by a bidding process?
Find out what the prospect hopes to achieve with the RFP, so you can meet their expectations.
The project summary usually spells out the known requirements. The project plan must have already been firmed up enough to get some level of approval before sending out the RFP, but most of the details are likely to still be quite fluid. Read this section carefully to try to answer these questions:
- How much do they know about what they're trying to achieve?
- Are they prescribing specific implementations? If so, why? Might they be open to alternatives?
- How important is this project to their overall success? Are they committed to doing it, or are they just going through the motions?
Any information you can get out of the prospect will help, but often the RFP process stipulates limited contact in order to insure an equitable selection without favoritism. Sometimes you're allowed to submit a document containing questions about the RFP, but that becomes part of the project documentation, so be careful what you ask.
You may also be able to divine some of these answers from the kinds of questions they ask in the remainder of the RFP. Whatever topic their questions focus on the most will typically be what's most important to them:
- Technology: If the prospect asks many detailed questions about specific technologies, there's a good chance they've already committed to that path, or at least they would prefer it. They will then be seeking someone who is excited about that technology, not someone who wants to suggest something else. On the other hand, if they're asking about experience solving certain kinds of problems, then they may be more open to suggested alternatives. We all know that clients should specify what not how, but I've seen RFPs that specifically dictate certain database or operating system choices, as well as implementation strategies like SOAP. Whether that's because they're invested in that technology or simply want to appear buzzword-knowledgeable is something you may need to figure out. The best response here is "Yes, we can do that -- and we can advise on alternatives if you are interested," but only if you really can do both.
- Resources: Before selecting you as a vendor, the company wants to make sure you will devote enough time and resources to get the job done in the expected timeframe; they also want to know that you won't vanish mid-project. So, they may ask questions about the size of your company, how many clients you have, and how long you've been in business. These kinds of questions often intimidate small businesses and freelancers, but there's no reason why they should. Being small and responsive to client needs often means that you can get things done faster and better than the big boys, so don't respond defensively or try to appear bigger than you are. Focus on past successes, and affirm your commitment to your projects.
- Timeframe: Watch out for specific scheduling requirements. Sometimes those are merely intended to keep things moving, but in other cases they can be critical -- and a real risk of a failed project. Before committing on timeframe, make sure you can deliver.
- Price: RFPs sometimes include general budget parameters. If it's too small, say so -- don't try to shoe-horn yourself into their expectations. You know that estimates are hard enough to get right anyway, and they're almost never off in a good way. The number they throw out there may also be a good indication of how they see the complexity of the project. They may be astonishingly wrong, but it does indicate their perception.
Once you've gathered as much information as you can about what the prospect wants, then it's time to respond. Before you do, consider these two important questions:
- Do you have what it takes to do this job? Skills, experience, available time.
- Do you want to do this project? You'd better like it, because projects with an RFP are usually lengthy -- months or years, not weeks.
You'd be surprised how many people try to "win" on an RFP, without first considering whether that would be a good outcome. Once you decide that you can do the job and you want to do it, then you're ready to respond honestly and confidently.
More about RFPs on TechRepublic
- Finding and responding to RFPs: Tips for IT consultants
- How to respond to a corporate RFP
- How to work with nebulous RFPs from clients who don't know what they want
- Protecting your ideas in your RFP response