To give the proposal evaluators what they want, first you have to know what that is. Sounds easy doesn’t it? First you have to recognize that a customer’s organization may have more than one point of view, more than one preference, more than one agenda. The ones that matter most are the ones actually participating in the proposal evaluation, if you can determine who they are.
People in your organization bringing you information will interpret the client differently --- project managers, business developers, executives, and others all come with a different bias.
The RFP is supposed to tell you what the customer wants, but it often is not written by the evaluators, leading to circumstances where what the customer asks for is not what the evaluators actually want. Assuming the RFP is accurate it may be incomplete. I have seen RFPs with extremely detailed specifications for computer equipment that gave no clue whether the client was trying to centralize IT management at headquarters or empower its field offices. And you might get a different answer depending on whether you talked to some at headquarters or a field office. But opinions that count are the evaluators. Getting the wrong opinion can lead to bidding the wrong solution.
One major reason why you should be talking to the customer before RFP release is that the client may not talk to you at all once the RFP hits the street, and if they do answer your questions you can be sure it won’t be on a level that provides real insight. To effectively give the evaluators what they want you have to have a real understanding about the client’s environment, goals, and agendas.
On the vast majority of proposals I have worked on, the proposal team desperately wanted to give the evaluators what they wanted. Giving them what you want them to have is a recipe for losing, and most teams understand that. The problem is that knowing what they want requires insight above and beyond what is in the RFP. The only way to do that is to understand your client --- what are their goals, what problems do they face, do they have an internal consensus or competing factions, do they have preferences or bias, do they have constraints they have to work within, standards to comply with, or anything else that may affect their decision and may or may not be in the RFP?
If the RFP just came out and you’ve never worked with the customer before you can forget about getting this kind of insight into your submission. Get to know potential customers before RFP release. Build a list of questions such as those above and seek out the answers. When the RFP is released, you can look for ways to demonstrate your insight and stand out from the pack.