Project Management

Guidelines for formulating an RFP response

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

Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!


Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...


This is cool, Working on an RFP right now.


I disagree with some of your comments about the technology component of the RFP... "but I?ve seen RFPs that specifically dictate certain database or operating system choices".... A client should clearly specify what technologies they want to see used in "their" solution. Ultimately, it is the clients solution, not the vendors solution. If the client's existing IT infrastructure is built on certain technologies, it only makes sense to seek out a proponent who will use them. As an example, we are an almost 100% MS shop with Windows Desktop, Windows Servers, MS Exchange and MS SQL DB and we let proponents clearly know we want a solution that uses these components and technologies. If a vendor brought forward a solution that used Oracle DB, Lotus Notes, Adobe AIR and some SUN Solaris servers we would not be interested. How would a proposed solution from this RPF be supported. Two options. 1) $$Pay$$ the vendor (for ever and ever) to support it. 2) Acquire or invest in in-house expertise to support this new technology. $$$$$ In either case, the longer term cost of this RFP solution has just sky-rocketed. Bottomline... A RFP solution implementation should not singularly chanage or drive the direction of your technology infrastructure no matter how much a vendor thinks that their solution is the 'best solution'.


Interesting read as I deal with a lot of RFPs but I am the 'prospect' (never been called that before!). These points are pretty much spot on. Another piece of advice ... if the prospect gives you a rating model such as A - fully compliant, B - partially compliant, C - not compliant ... don't reply A unless you have the requirement fully met in an existing commercially available product i.e. not in development or beta testing (using software as an example). Don't put A all the way as we know you are fibbing and you will be found out ;-)

Sterling chip Camden
Sterling chip Camden

... I've never responded to an RFP in order to get a new client. But I have assisted clients who were responding to RFPs in their markets, and I hope you'll find my pointers generally applicable. Have you ever landed any new business from an RFP?

Sterling chip Camden
Sterling chip Camden

I agree with you that there have to be limits on what technologies can be employed, but in my experience this is often taken to extremes. "We're an MS shop" says that they won't even consider putting in one Unix server even if it could save them a ton of money. I'm not saying that going non-MS would be the right call, I just think that failing to weigh the option is not being diligent.

Sterling chip Camden
Sterling chip Camden

... I'm helping one of my clients fill out an RFP response and they're asking me "How can we find a way to answer A on this one. We really need an A here." My response is, "first, you have to have an A, and then you can put one down." It's like the dog chasing the car -- what would he do if he actually caught it?


I?ve written more than 20 RFPs for various clients, responded to way more than that, won more than my share mainly getting new clients, and assisted my RFP clients? managing their selected vendor?s (more frequently successful than usual) implementations many times. Unlike most RFP participants, I?ve had the inclination and orientation to take advantage of my experiences, coupling with my legal training to analyze the acquisition process, learn the right lessons, and refine them into effective repeatable methodologies that I use with clients, write about including my Discovering REAL Business Requirements for Software Project Success book, and teach in public and private seminars. Many if not most RFPs result in failed projects, which invariably are blamed on the selected vendor. As Chip?s article accurately implies, inevitable failure is created usually and unknowingly by the RFP issuer. Capable vendors stay in business in large part because they compensate for buyers? deficiencies; but this also builds many vendors? (somewhat deserved) reputations for over-reaching. The biggest cause of RFP failure is the buyer?s inadequate definition of their own REAL, business requirements, which are what the vendor should be proposing a product and/or service to satisfy. Instead the buyer tries to specify the expected product or system, which often turns out not to be what they actually need. Such mistaking a product/service for one?s requirements is common in the software (and other) industries but often is aggravated by RFPs. For instance, many buyers mistakenly assume the vendor will know their requirements, and too many (soon to fail) vendors fall into the trap of believing they indeed do know perhaps better than the buyer what the buyer requires. In other cases, RFPs are simply thinly-veiled efforts to get around an-intended-to-protect-them formal buying process, usually in order to buy a particular product the buyer already has decided upon, which too often turns out not to be what's really needed. The successful vendor responding to an RFP is one who not only wins the business but also delivers promised products and services that actually meet the buyer?s needs. I?ve found the key to vendor success starts with focusing on the buyer?s REAL business requirements, showing specifically how the vendor?s products/services will satisfy them, presenting an informed task plan that understandably will deliver on time and in budget, and then carrying through as promised.

Sterling chip Camden
Sterling chip Camden

That's what an RFP is for: find someone who can meet the buyer's requirements. Good points.

Editor's Picks