Unfortunately, many of these same mistakes have already made their way into the versions of proposals submitted to the customer.

Here are a few of MY rules that are frequently violated in draft – or even final — proposals:

  1. Describe all positions of persons in your organization in terms the customer will understand. Do not address your own organization, and call an individual "Section Manager"; call the person a "Task Manager", "Program Manager", or other label that is indicative of a function relevant to the customer. Don’t use occupational or job titles, such as "systems analyst"; use functions, such as "Cost Control Manager".
  2. Be clear about a list of subcontractors; if some are more important than others, recognize that difference by calling the first echelon "subcontractors", and lower ones "suppliers" or „vendors“. Use the same ORDER of subcontractors each time, in the text and in any tables, to list the other firms. If you supply extensive data for one subcontractor, and nothing for another, explain the difference in a way the customer can understand and accept; don’t make him guess, because he will almost certainly guess WRONG.
  3. If you wish to introduce a special label, or term of art, introduce it early, (not late) in the text. Clearly explain the term, why it’s used, and then reinforce its use in the remainder of the text. If it isn’t worth explaining clearly, the term isn’t worth using, and should be discarded in favor of a standard English term. Be sure to include all the customer’s terms of art in your proposal. Doing so in an example of playing back to the customer his own preferred solution.
  4. In an organization chart, use an action title, and customize the chart to show whatever point you make in the action title. Don’t include unnecessary details, as this will confuse the reader, and detract from the main point you wish to make. Don’t be afraid to leave some people or functions out entirely, or to group some together in a special way, that is meaningful only to this particular bid. You’re not trying to communicate with folks in your own organization; you’re trying to explain something to a customer.
  5. Under the general category of "Experience", there are at least two different ways of reporting, each with its positive and negative aspects:
    • The professional experience of the staff members being proposed, whether they got that experience at your company or elsewhere. This is "INDIVIDUAL experience".
    • The experience of your organization, without regard to whether anyone being proposed on this project participated, or whether anyone who did that work is still at your company or available to do the proposed work. This is "INSTITUTIONAL experience".

Please be clear about whether the customer wants INDIVIDUAL experience or INSTITUTIONAL experience, and respond accordingly. Don’t get caught being confused yourself; it only confuses the customer, and the confusion will have to be cleared up during the post-submission evaluation questions, and then you’re likely to be "swimming upstream".

  1. There are probably at least a dozen specific numbers that you will need to use throughout the proposal. For example, the proposed Program Manager has X years of experience, the company has Y employees worldwide, and your facilities represent an investment of over Z million dollars. If you haven’t already created a FACT SHEET for the proposal team, at least create one for me, so that when I find inconsistencies in the proposal, I can change the wrong numbers to right ones.
  2. Any reports you discuss as a part of your management process should tie to the relevant Contract Data Requirements List (CDRL). This makes the customer happy, because it makes the proposal easier to score, and forces the proposal team to prove that all required reports are discussed and priced. When discussing HOW you’re going to deliver these data items, use a simple chart, which is a Responsibility Assignment Matrix (RAM), relating the data item to the function or individual within the management structure with first-line responsibility for delivering that item.
  3. To avoid using your own jargon, mark all jargon terms in your proposal drafts with a Hi-Liter. Since the objective is to speak in the customer’s terms, and not your own, replace all those jargon terms with the customer’s language, or re-write those sections to eliminate the problem.

Summary

If your follow these eight rules, your proposals will receive higher grades from the proposal evaluators.