1. Underestimate the difficulty of proposal preparation and assign the wrong people to the team.
“Writing a proposal is easy — anyone can to it. Who is better qualified to describe our proposed program than our engineers and specialists who developed it? They write technical reports all the time. Proposals are no different.”

WRONG!

Writing a losing proposal is easy; writing a winning proposal is tough! Program developers will describe what they want to tell about their program, not what the proposal evaluators want to know. They will write ten pages if they know ten pages, but only one page if that’s all they know, even though the evaluators need ten pages to be sure that your company knows what it is doing. Proposal organization, format, presentation, wording, and first impressions are all important and comprise a unique discipline in which most technical and management people are not trained. Technical people don’t speak “proposalese.” You need people who know how to plan, organize, and write.

2. Start late.
“We can’t start working on the proposal yet, we haven’t seen the RFP and haven’t gotten top management’s approval to bid. Starting the proposal without an RFP would just waste time and money. Anyway, everyone is busy.”

WRONG!

It generally takes at least 45–60 days to prepare a first class competitive proposal, longer if the proposal is complex and more than one volume. Do it in less time and you will likely miss many subtle points that can make the difference between a win and another loss. Well-organized, easy to read, effective proposals are written in a calm, organized atmosphere, not in a 20-hour a day panic with major changes crammed in at the last moment. Start early, talk to the customer, and show him that you are interested and that he and his program is important to you. Get a draft statement of work (SOW) to start focusing your program and your proposal. If you can’t get a draft SOW, then write your own straw man SOW to work against and discuss with your customer; he may even use some of your ideas in his RFP.

3.  Jump at targets of opportunity you find in FedBizOps.
“This FedBizOps** announcement is just what we want. We haven’t been talking to the customer, but this request for source qualification is just what we are interested in. We’ll get the RFP, and if it looks good, we’ll bid. We’ll win by submitting a great proposal and a low price!”

WRONG!

Although low price frequently wins after a Best and Final Offer has “leveled” the offerors technically, your proposal must score within the competitive range even to be eligible for pricing competition. Usually, someone has already been working closely with the customer. No one is better qualified to write the winning proposal than the offeror who helped the customer write the RFP in the first place. If that wasn’t you, price won’t matter — you will probably lose.

4.  The RFP isn’t what the customer really needs; we know and will tell him.
“The RFP is just a guide. The customer doesn’t know what he really needs, so we will tell him in our proposal. The customer knows us and knows we do good work. Furthermore, our ideas are so good that they will literally sell themselves.”

WRONG!

Tell the customer what he really needs when you are working with him before the RFP is released, and help him to write the RFP. The customer must acquire the new system in an incredibly complex environment of congressional oversight, political pressures, inter-service rivalry, intradepartmental demands, total funding and funding profile constraints, and diverse technical and operational requirements. Furthermore, the RFP must meet stringent regulations of policy, content, format, and wording. It is a three-way compromise among what the customer really wants, what he can sell to his superiors, and what the can afford. Don’t rub his nose in it with your proposal. Make him want you by offering him what he asks at a better price and with less program, schedule, and cost risk than any other offeror. Prove to him that his government career is safer with you and your program than with any other offeror. Also, beware the “innovation trap;” “innovation” is frequently read as R-I-S-K.  And be aware, the customer CAN’T award to a bidder whose bid is not responsive to the SOW.  If he did, he would be inviting a protest from the losing bidders who did bid to the SOW, and one of them would likely prevail. 

5.  Don’t follow the stupid RFP. Tell your story the way you want.
“We will respond to the Statement of Work and the Specification, but whoever wrote the RFP just didn’t know what he was doing. We will organize our proposal to better tell our story and give the evaluators a “correlation matrix” to find what they need. We don’t need to worry about Evaluation Factors for Award — evaluation is their job.”

WRONG!

Evaluating proposals is worse than writing them. The evaluation team is usually divided into panels for each evaluation area (technical, management, and so on). They may also be further divided into the various disciplines suggested by the RFP Section M specific evaluation criteria factors, such as Airframe, Flight Controls, Software, Subcontract Management, training, etc.

Usually, no one evaluates the entire proposal. Evaluators first skim through the proposals to get their “flavor,” and to get an idea of the “norm.” Then they go through them again for scoring, using either a numerical scale , symbols, or words. They don’t read the proposals from cover-to-cover to score them, but look for specific answers to the specific questions in their Source Selection Plan. Those questions relate to the evaluation “standards,” which are the almost never specifically identified in the RFP. They are not the areas, factors, or subfactors usually given in the RFP Section M, but are subsets of the Subfactors. For each specific evaluation factor or subfactor the SSP defines the factor or subfactor, and then lists the minimum acceptable levels of compliance that the evaluators look for. The standards may be deduced from excruciating analysis of the entire RFP. They may be either quantitative or qualitative, and usually relate to specific requirements from the SOW or specification. The evaluators then typically score this compliance using such assessment criteria as “Understanding the Problem,” “Compliance with Requirements,” and “Soundness of Approach.” The evaluators may also apply the RFP Section M “General Criteria,” such as Risk and (for Army proposals) MANPRINT, across the entire proposal. The easier you make it for the evaluators to find those answers, the better they will feel about you and the less likely they will score your proposal “non-responsive” or “non-compliant.” Fanatically following the RFP Sections M and Statement of Word will improve your score by helping to ensure that you respond to all the evaluation standards, but you must structure your proposal in accordance with Section L. Correlation matrices sound great, but don’t really work in practice. Superior answers give you no points if the evaluators can’t find them.

As noted in the opening paragraph, these are only a few of the many “losing proposal” traps that companies can fall into. Maybe you’ve already “discovered” these on your own, or maybe you’ve come up with a few original ones. Either way, most proposal traps can be avoided, providing you take proposals seriously. Very seriously