Reading the RFP

- If you are responding to a request for proposal, then you need to read the RFP. Sounds like a no-brainer, doesn't it? Of course, you have to read the RFP so you know what your proposal will be about. So that seems like common sense, but you need to READ the RFP, capital R-E-A-D. Not just a cursory reading. A thorough, multiple time, by different people kind of reading. Let's look at a couple "Why should I READ," all caps, "the RFP?" reasons: to find discrepancies, confusing questions, and complete information or unclear terminology, to learn if your proposal's content will be strictly fixed or will you be able to include a more innovative, creative solution? A thorough reading is also necessary so you will know exactly what to include. The request for critical information for the proposal may be scattered throughout various sections of the RFP. Also as you read, you may find key phrases being used over and over. Take a hint and use those in your response language. In one proposal, the words "design development" and "engineering process" were used multiple times. Obviously, those are important to the company. So framing your responses with those words will show the reader that you understand the concerns and maybe, even subliminally, have an impact. Our design development procedure will begin with or the complete engineering process is transparent, and another big "Why?" read is that failure to complete all parts and submit everything that's requested or to follow all the specific instructions will result in the proposal being, in proposal technical writing terms, non-responsive. In other words, your proposal will be disqualified. If the RFP does not include sections specifically asking for possible additional solutions, then don't give them. Do, however, be expansive with the answers you do give to the requested questions. Numerous software companies sell software programs advertised to analyze a scanned RFP, and identify questions and requirements, and fill in the information from your company's internal knowledge base. Even though these programs might have some value, as with any software programs, don't assume that they work perfectly. It's important that a human be part of the process. The other thing to think about for using or not using one of these programs is that each proposal needs to be adapted to the specific requirements identified. Be sure it doesn't sound too boring or polite. Here are some tips to help you as you read that request for proposal. Make a list of the lettered sections in an outline form and determine the intent of each section. As you later gather information, you can even label it C, P, Q, whichever section it fits. For example, certifications go in "C." Price information is labeled "P." Qualification request identify with a "Q." Then get out those post-em notes. Make notes, such as, "Ask Nan to find this information" or "Gene, how do you interpret this question?" "Al, we need to decide how to respond to this." Whatever will help jog your memory. The next time you or someone else reads through the RFP, you won't spend extra time looking for bits of information that you remember seeing, but now can't locate or have different readers duplicating efforts. As you've already started to brainstorming a list of who should do what, and if after the initial reading the arrangement of sections doesn't make sense to you or they don't flow the way you think, reorder them until a sequence that's easier for your company to follow. For example, maybe Section B includes the purpose and objectives in the necessary requirements are given in Section E. Tying the requirements with the purpose and objective may make more sense to the way you organize things. So yes, the RFP should be read, READ carefully several times so you have a strong grasp of the entire request.