Chapter 10

Developing a Proposal Preparation Plan

Once you have completed a thorough review of the RFP and prepared the documents described in Chapter 9, it is time to develop a detailed proposal preparation plan. Planning is a pivotal junction in the proposal development process. As in most of life’s endeavors, the quality of the output is directly related to the effort invested in planning. For proposals, poor or inadequate planning is a sure formula for failure.

The small amount of time available to prepare a proposal makes it especially difficult to recover from a false start. Hence, one of the greatest opportunities to capture competitive advantage is through effective proposal planning. First-draft proposals frequently have a high scrap rate. Sometimes, as much as 90 percent or more of the first draft must be thrown out or redone. The usual culprits for this shortcoming are failing to organize the proposal properly and failing to address required topics. The result is loss of precious time and resources, plus an often devastating impact on proposal team morale.

Inattention to proposal planning, or the lack of good planning tools, practically guarantees you will prepare a losing proposal. At minimum, you will put yourself at a severe disadvantage competitively. The only hope in this case is that you will be competing with companies equally inept in the planning process.

Five documents represent the weapons in an effective proposal planning arsenal. The first three define the content to be included in the proposal:

• Proposal outline—A complete outline of the proposal, consisting of paragraph numbers and headings

• Proposal requirements matrix—A list of Section M evaluation criteria and all other RFP requirements for each proposal paragraph contained in the proposal outline

• Author guide—A storyboard process that specifies what is to be contained in each proposal section.

The other two documents support proposal management. Described in Chapter 11, they establish responsibility for every proposal task and define completion dates for each:

• Proposal responsibility matrix—Lists the person responsible for each entry in the proposal outline

• Detailed proposal schedule—Specifies duration and completion dates for each proposal activity.

Collectively these documents define the who, what, and when of proposal development. The preparation of each is described below. The order in which they are addressed is based on continuity of topic and not the order in which they would normally be developed. The proposal outline, responsibility matrix, and schedule are developed concurrently. The proposal requirements matrix and author guides are developed sequentially after the proposal outline is complete.

PROPOSAL OUTLINE

The government evaluation standards used to score your proposal are organized according to the instructions provided in Section L. Therefore, unless the RFP expressly directs otherwise, you must organize your proposal in exactly the same order as information is requested by Section L. This is one of few absolutes in preparing government proposals. Failure to follow this simple instruction may cause your proposal to be completely noncompliant.

For example, a client of mine lost an important program. They were shocked. They had far more relevant experience and were better qualified technically than the company that won. They also felt that they were slightly favored by the procuring agency, and their bid cost was lower. I was hired to analyze their proposal to determine why they had lost.

The answer was simple. They had organized their technical proposal according to the evaluation criteria contained in Section M of the RFP instead of the instructions of Section L. Technical proposal material was not located where the evaluators expected to find it. Moreover, much of the information requested by Section L was not provided because there were no corresponding evaluation criteria contained in Section M. This tragic mistake cost my client an important program and wasted valuable B&P resources in the process.

It may seem intuitive to organize your proposal according to the criteria the government will use to evaluate your proposal. There is just one small problem: This tactic almost guarantees a losing proposal. Do not deviate from the order of instructions provided in Section L unless the RFP specifically directs it. This does occur occasionally. Sometimes customers ask bidders to organize their proposals according to a statement of work (SOW) or a technical specification, but these are rare exceptions.

Authors often complain about following the order of Section L. They claim that the government-requested order of information is illogical. This is normally a valid criticism. Many times, the requested order of information makes writing difficult. Unfortunately, deviating from Section L to make writing assignments easy for authors has dire consequences.

Gain competitive advantage by presenting proposal information so that it appears where evaluators expect to find it and by making it easy to identify.

Creating an Overall Proposal Outline

The first step is to read the proposal preparation instructions contained in Section L carefully. These are variously referred to as “Instructions to Offerors,” “Proposal Preparation Instructions,” or “Proposal Instructions to Offerors.” Build an overall proposal outline based on the division of volumes and sections requested by Section L. Use the same volume and section numbering scheme contained in Section L. Figure 10-1 shows a sample Section L breakout of proposal volumes.

Figure 10-1. Sample RFP Section L Breakout of Required Proposal Volumes

The breakout in Figure 10-1 yields the following overall proposal outline:

To fill in the next level of detail, examine Section L to see if sections are broken out further. Figure 10-2 shows a sample breakout for Section 2 of Volume 1.

Figure 10-2. RFP Paragraph Headings for Section 2 of Volume I

In this case, specific RFP paragraphs are not numbered. Therefore, we will use the overall organization suggested by the RFP. The technical proposal is Section 2 of Volume 1. It consists of three subsections. Our proposal outline will follow the same order of topics, numbered accordingly:

The next step is to develop a detailed outline for each section. Section L instructions for the Training System Support Center (TSSC) are shown in Figure 10-3. To build the outline, follow the order of subjects and use the customer’s language to build paragraph titles. This will help evaluators find what they are looking for. Every Section L “should” or “shall” statement specifies a separate requirement. Keep this in mind to determine paragraph breaks in your outline.

Figure 10-3. Section L Instructions for Section 2: Training System Support Center

Figure 10-4 provides the proposal outline for the TSSC derived from the Section L instructions listed in Figure 10-3.

Figure 10-4. Proposal Outline for Section 2.2 Based on Section L Instructions

To illustrate the process, the first few sentences from Section L are as follows:

The proposal outline for these sentences becomes:

This process is continued until you have a proposal outline for each section of the entire technical proposal and other proposal volumes where an outline is appropriate. Note that paragraph headings closely correspond with the Section L language.

Include your company’s name, shown as “XYZ” in the example, in paragraph headings. This helps government evaluators associate the proposed approach with your company. This may sound trivial, and it probably is. However, evaluators tasked with scoring multiple proposals might get confused over who is proposing what.

Sometimes it is difficult to decide when a new paragraph level is required. For example, the Section L instructions for section 2.2.3 address multiple topics. I elected to include them as paragraphs under section 2.2.3. Another approach would to create separate sections for each (e.g., 2.2.4, 2.2.5, 2.2.6). The key in this case is traceability between Section L and your proposal. Sometimes a review of the Section M evaluation criteria will provide a clue for determining the proper level of organization.

In most cases, each sentence from Section L includes more than one topic or requirement. To illustrate, consider the Section L requirement of section 2.2.1:

2.2.1 The offeror should describe their approach and proposed resources to operate and maintain the TSSC.

At least two topics are requested:

1. Your approach to operate and maintain the TSSC

2. Your proposed resources to operate and maintain the TSSC.

If “operating and maintaining” the TSSC are separate processes, and each deserves a separate write-up, your proposal must address four topics—two for your approach and two for your proposed resources. Whether you allocate separate subsections for each is a judgment call. If the proposal section is short, say one page or less, a separate breakout may not be necessary. For the first draft it is better to take the outline to the lowest level to ensure you do not miss a Section L topic. Once you start writing, it will be clear where you can collapse multiple subparagraphs into a single paragraph.

The most important point is for your proposal to address every topic and item contained in the Section L sentence. Otherwise, this portion of your proposal may suffer a lower score or be judged as nonresponsive. Incidentally, the order of your proposal for this section is “approach” first and “proposed resources” second. This follows the order of topics provided by Section L.

Note from the sample proposal outline shown in Figure 10-4 that the Section L language is retained and shown in italics. I recommend that you retain this information in the proposal outline and in the first draft of proposal material. You will find that this helps authors focus on the primary topic to be addressed by each proposal section, which will enhance its responsiveness to the RFP requirements.

PROPOSAL REQUIREMENTS MATRIX

The completed proposal outline, based on Section L, provides the foundation for your proposal. However, you are not yet finished. Section L provides only the topics to be addressed by your proposal. Section M evaluation criteria must be integrated into your proposal. So must other RFP requirements to be addressed in each proposal section.

The proposal requirements matrix is just an extension of the proposal outline. It provides the author with all the RFP information necessary to write a responsive first draft. This matrix lists and correlates the information from Sections L, M, and others that should be addressed by each proposal section. Other RFP information may include segments of the SOW, special contract clauses, or specifications. If the RFP requires you to write your own SOW, the SOW should be correlated with the proposal.

Prepared by the proposal manager, the proposal requirements matrix provides a simple, convenient form to display the RFP requirements that need to be addressed by each proposal section. It saves authors the time and effort of looking up and organizing all the relevant RFP sections they need to prepare assigned proposal sections. It can also be used to support subsequent proposal reviews (see Chapter 15). Using a common reference to prepare and then evaluate proposal sections provides continuity between the different phases of proposal development.

Creating the Proposal Requirements Matrix

The starting point to develop the requirements matrix is the proposal outline. The next step is to analyze the evaluation criteria contained in Section M. Evaluation criteria must be correlated with their corresponding Section L instructions, contained in the proposal outline. Figure 10-5 shows the evaluation criteria for the Training System Support Center (section 2.2 of the proposal outline).

Figure 10-5. Section M Evaluation Criteria with Breakout of Criteria for Subfactor 2

Several points need to be made about Section M evaluation criteria. First, the detail and specificity of evaluation criteria differ enormously across RFPs. Some provide sufficient detail; others appear to be little more than a paraphrase of Section L. Second, the order in which evaluation criteria occur in Section M often does not follow the same ordering of topics contained in Section L. Therefore, you will have to analyze the evaluation criteria to determine their corresponding Section L requirements and where they need to be addressed in your proposal.

Finally, in some cases evaluation criteria contained in Section M will not appear to correlate in any meaningful way with Section L. This is especially problematic. You may need to integrate other RFP requirements, such as the SOW, into your proposal outline to see the correspondence between the contents to be provided in your proposal and the corresponding evaluation criteria. Or you may need to apply your knowledge of the customer and the problem being solved to fully interpret evaluation criteria. If every effort fails to discern the relationship between the requested proposal content and the evaluation criteria, consider submitting a written question of clarification to the government.

Regardless, it is up to you to determine the proper correlation. Lacking a clear understanding of the evaluation criteria and their relationship to your proposal increases significantly the risk that your proposal will be nonresponsive to RFP requirements. This can be disastrous if one of your competitors has the key.

Sometimes, RFPs contain evaluation criteria that are not included as topics in Section L instructions. Notice that Item 6 in Figure 10-5—”Offeror’s proposed maintenance plan for the ABC System”—is not contained in the Section L instructions. (Compare with Figure 10-3, in which there is no Section L topic for the proposed maintenance plan referred to in Section M.) When this occurs, you must integrate the evaluation criteria into the proposal outline even though there is no corresponding Section L requirement. Otherwise, you will fail to address an entire evaluation criterion. This alone could cost you the competition. For the present example, we would add a paragraph, 2.2.8 “XYZ’s Proposed Maintenance Plan for the ABC System,” to the proposal outline and the Proposal Requirements Matrix.

Figure 10-6 shows the proposal requirements matrix after evaluation criteria have been integrated into the proposal outline. Note that the matrix includes a column for “Other RFP Requirements.” These are additional RFP requirements that further define the content and focus of the proposal section. Other requirements can be derived from the SOW, specifications, CDRLs, and Section H special contract clauses. Note also that the SOW entry concerning equipment availability occurs for proposal section 2.2.2, “Overview of XYZ’s Maintenance Approach to Meet the 95% Availability Requirement.”

Figure 10-6. Proposal Requirements Matrix for a Portion of Section 2.2

The sample proposal requirements matrix shown in Figure 10-6 illustrates the point but is deceptively simple. Some Section L headings will have multiple “Other Requirements” that must be addressed by that proposal section. Figure 10-7 shows a portion of a more robust proposal requirements matrix. It includes relevant SOW and CDRL requirements. (Note: You may have a dozen requirements for a single Section L proposal paragraph, so even this example is relatively simple.)

Populating the “Other RFP Requirements” column of the matrix is by far the most challenging task. You must review other RFP documents to determine where those requirements will be addressed in your proposal. For example, you must match Section L and M topics with the corresponding requirements in the SOW. Begin by comparing SOW requirements with the topics contained in the first two columns of the matrix. Based on this comparison, decide where the SOW requirement should be addressed. Copy the requirement into the appropriate right-hand column. After you finish with the SOW, repeat the process for any other relevant RFP documents, such as a product specification. Review CDRLs and Section H to see if they contain requirements that must be added to the matrix.

Do not be alarmed if you discover that some RFP requirements in the SOW or specification do not appear to have a home in the proposal requirements matrix. Sometimes, proposals need not address every RFP SOW/specification requirement—just those in which the customer is interested. Nonetheless, having leftover requirements provides us with a decision point: Should we expand our proposal outline to address these requirements, or can we safely ignore them? This is a difficult judgment.

Here is my general guidance: If the leftover requirement is something you are certain the customer cares about, integrate it into your proposal outline. Otherwise, leave it out of the proposal. Here is another case where knowing your customer pays off.

To mitigate the risk of being wrong, build a compliance matrix for the SOW and specification. Include them in a non-page-limited portion of the proposal. Reference them in your technical proposal and state clearly that you comply with all SOW/specification requirements. Alternatively, if you are foolish enough to be noncompliant, you must identify those areas in your technical proposal.

Figure 10-7. Sample Proposal Requirements Matrix

Some will argue it is safer to just address all SOW and specification requirements in your proposal. Unfortunately, nearly all proposals are page-limited, some severely so. Taking up page count to address a topic for which there is no corresponding Section L or M requirement might be unwise. It could cause you to waste space explaining something the customer is not interested in at the expense of material that will contribute to your proposal score.

Notice from the sample matrix in Figure 10-7 that adding other requirements provides additional insight into the topics that must be addressed by your proposal. They will also require an expansion of the proposal outline to accommodate them. Just remember, Section L is the driving requirement. Everything must be organized with respect to the topics requested by Section L. For this example, we might add three subparagraphs under proposal section 2.2.3, “Project Status, Control, and Reporting System,” to address the three SOW requirements. Note I included CDRLs in the list of other requirements. As a rule I always address CDRLs and their delivery dates in my technical narrative.

The completed proposal requirements matrix is the single most valuable document in the proposal planning process. Properly prepared, it identifies all RFP requirements that must be addressed by your proposal and where they should be addressed. This practically ensures you will respond to all evaluation criteria and standards in your proposal, which is a key ingredient of a winning proposal.

AUTHOR GUIDE

The proposal outline provides a topical outline for the entire proposal. The proposal requirements matrix expands that outline by integrating evaluation criteria and other RFP requirements into the outline.

The next step in the planning process is to determine the specific content of each proposal section. The importance of this step cannot be overemphasized. It is the foundation on which your proposal is built. If the foundation is faulty, the entire proposal will suffer. The magnitude of such an error is placed in context when you consider that failing to submit a responsive, compliant technical proposal is the single greatest contributor to losing proposals.

There are a host of techniques to support this stage of proposal development: annotated outlines, writing scenarios, storyboards, writing guides, etc. Each has its own set of proponents. Many proposal books and seminars claim that their approach is superior to all others. Some even guarantee success if you just follow their recommended approach. In reality, all approaches have the same goal: Prepare compliant and responsive proposal sections that produce high marks from government evaluators.

My preference is to build what I call an author guide. As the name implies, it is a tool intended to help authors plan what they will include in each proposal section. It consists of two sheets. Sheet 1 is prepared by the responsible author. It replicates the information from the proposal requirements matrix and leaves space for the author to develop a more detailed outline of the proposal section, including key points to be made. It also provides space to list any recommended graphics to support the proposal section narrative. Sheet 2 provides space for things like section themes, bid strategies, and features/benefits, and a section to identify potential areas of proposal risk and the actions you have taken (or will take) to mitigate those risks. Most authors will need help completing Sheet 2 unless they are seasoned proposal veterans. Typically, the proposal manager provides any needed assistance.

Initially I have authors complete only the first sheet of the author guide. Once they have completed a draft that is responsive to all RFP requirements, they can turn to the task of integrating themes, bid strategies, discriminators, features/benefits, and other elements that will enhance the proposal.

Sheet 1 of the Author Guide

Sheet 1 of the author guide is shown in Figure 10-8. The top portion of the guide restates the RFP requirement, which is derived from the proposal requirements matrix. The remainder of the sheet provides space for the author to prepare a detailed section outline and to define any supporting graphics.

Figure 10-8. Sheet 1 of the Author Guide with Sample Information Shown in Italics

The first task in developing a detailed outline is to analyze the Section L instructions carefully. What information is the customer asking for? What are the important components of a responsive reply? Translating the Section L instructions into an outline and then into proposal narrative may appear to be a simple, straightforward undertaking. It is not. Getting proposal authors to write proposal sections responsive to RFP requirements is among a proposal manager’s greatest challenges. It is also among the most important.

Two exercises to help authors complete Sheet 1 of the author guide follow. They are especially beneficial when your team includes relatively inexperienced proposal authors.

Dissecting Section L Requirements

Have authors break each Section L sentence into its component parts: subject, verb, object, and topic. For example:

The offeror shall describe their approach to data management.

Subject: offeror (that’s you)

Verb: shall describe

Object: approach to data management

Topic: data management

So, the author needs to focus on the proposed approach to data management. Some of the value of this exercise is the attention required by the author to break up the requirement into its component parts. This focus alone can be beneficial. Now the author needs to decide what information to include in each subparagraph. A useful technique is to have authors analyze the verbs used in the Section L instructions.

Analyzing Verbs Used in Section L Instructions

Verbs used frequently in government RFPs include:

• Describe

• Discuss

• Explain

• Identify

• Provide

• List

• Submit

Each verb suggests a slightly different set of information. For example, describe normally requests more extensive information than list. Figure 10-9 lists typical verbs and suggests the connotation of each. Ask authors to analyze the verb used in the Section L statement as a way of helping to determine what information to include. The most important part of this exercise is to force a detailed analysis of the RFP requirement and the information being requested by the customer.

Figure 10-9. Typical Section L Verbs and Their Connotations

I do not imagine that customers spend a lot of time selecting the right verbs to include in Section L instructions. Nonetheless, paying attention to verbs can help focus your response.

When the RFP asks you to “describe” something, you should create a word picture that communicates the essential elements of what is being described. To describe an object, you might state its purpose or function and then list its key attributes or features. Here is a simple example to illustrate this point:

Describe your automobile.

Its primary purpose is transportation. Key attributes include make, model, year, and perhaps color. If we wanted to add additional information, we might include things like automatic transmission, air conditioning, six-disc CD player, automatic windows and locks, cruise control, etc.

To apply this principle to your proposal, start by listing the object’s purpose or function and its key attributes. Organize them from general to specific, and then decide what level of detail you want to include in your response.

Describing a process or system is slightly different. Unlike objects, processes lack physical features. To describe a process, consider listing the person or organization responsible for the process, identify its purpose, list key inputs and outputs, and identify major phases, components, or steps. Use this information to organize your response.

Yet another approach is to identify the “who, what, where, when, why, and how” of the process. Consider another simple example:

This becomes the basis for your detailed outline. You then would use this information to prepare your response. Here is an example of what such a response might look like:

RFP questions are normally far more complex, but the basic principles still apply. Keep in mind that these exercises are just tools that help identify and organize information to include in your response.

The “who, what, where, when, why, and how” exercise can also be used to develop the framework for responses to RFP questions that ask you to “explain” or “discuss” an object, process, or system. A different strategy is required for verbs like identify, list, or submit.

When the RFP asks you to “identify” something, it usually means the customer wants you to name, classify, or catalogue the object of the question. The basic response to a request to “identify” is to provide the information requested and then decide how much embellishment you need to add. For example:

Section L: Identify the quality standards that will be used for the Delta program.

Response: We plan to use ISO 9001 quality standards on the Delta program.

This is the simplest response possible. In most instances, more information would need to be added to fully satisfy the evaluator reading this section of your proposal. If you are asked to identify an approach, process, or method, you will need to expand the scope of your response.

Verbs like list and submit typically require even less information. For example:

Completing Sheet 1

Once authors have a general understanding of the information being requested by the RFP, they can use their technical or subject matter knowledge to further expand the outline and identify important points to be included in the proposal response. The detailed outline must also integrate the requirements contained in the evaluation criteria and other relevant RFP requirements. If a graphic or illustration will be used in the proposal section, that should be noted on the author guide.

The detailed outline should be captured on Sheet 1 of the author guide and reviewed by the proposal manager or the technical volume manager. Ideally, this will occur before the author starts writing. However, this is not always practical. In such cases, review the outline as soon as possible and make any necessary corrections. When authors have more than one assignment, consider reviewing each outline as it is completed rather than waiting for the author to complete all the outlines.

A practice that can be helpful to other authors is to post completed author guides on a wall in the proposal area. This practice permits other authors to see the information being provided in other sections that might impact the content or focus of their sections. It also allows proposal and technical volume managers to see a complete summary of the technical proposal content.

Sheet 2 of the Author Guide

I recommend completing a first draft proposal section before you attempt to integrate themes and bid strategies. You can cram all the themes, discriminators, and “grabbers” you want into a proposal, but it will likely be a loser if you fail to respond completely to all RFP requirements contained in the proposal requirements matrix.

Experience suggests that most people assigned to work on proposals have a hard enough time just writing a responsive proposal section. Asking them to develop convincing themes and identify discriminators, in addition to addressing all RFP requirements, generally is too much. The result of such an approach is typically a proposal section that includes a lot of hype and very little substance.

Section themes, discriminators, and information that integrate your bid strategy into the proposal are indeed important attributes of a winning proposal, but first things first. Start with a compliant, responsive section and then add all the “bells and whistles.” A responsive, well-written proposal without all the extras is capable of winning. A nonresponsive proposal with all the extras will rarely produce a winner.

Once a proposal section is responsive to RFP requirements, begin integrating information that will enable you to gain competitive advantage. There are three general sources for this information. The first source is your bid strategy, developed during the pre-proposal phase and refined to reflect specific RFP requirements. The second source is your specific approach to satisfying the customer’s requirements, which is embedded in your proposed response to RFP requirements. The final source of information is your understanding of customer needs, desires, fears, and biases; the need being solved by the contract; and what is important to include in the proposal.

The starting point is to complete Sheet 2 of the author guide, shown in Figure 10-10, for each proposal section. Some of this information is derived directly from your bid strategy and assessment of competitors. The remainder is generated by integrating what you know about the customer and performing a feature-benefit analysis of what you are offering.

Figure 10-10. Sheet 2 of the Author Guide

The primary purpose of Sheet 2 is to identify information that will enable you to maximize the score your technical proposal receives. It specifically focuses on achieving technical strength ratings, avoiding technical weaknesses, and achieving a low proposal-risk rating. Go back and review the “Technical Evaluation” section of Chapter 3. It will help remind you of the importance of the information contained in Sheet 2 of the author guide.

Developing Proposal Themes

A theme is a message you want to communicate to the customer. It can be a special point, an emphasis, a unique or superior benefit to the customer, a supported claim, or a way of highlighting a strength or a competitor’s weakness. Focus on developing themes that give you a competitive advantage or neutralize a competitor’s strength.

A good theme is direct, addresses a program issue or customer concern, and can be supported by concrete evidence. Themes are integrated throughout the proposal. They often occur in volume, section, and subsection introductions, but not exclusively.

Themes can be divided into two general categories: common and unique. Common themes are statements that one or more of your competitors can make. They are important, but they might not yield much of a competitive advantage. For example, the benefit of an automated software requirements tool may be common if competitors use a comparable tool. It would still be an integral part of a discussion on requirements traceability, but it may not give you an edge on the competition, unless they forget to include it.

Unique themes, or discriminators, are statements unique to your company or proposed approach. They are based on particular advantages your company can offer or on distinct disadvantages of your competitors. They include key features of your proposed approach and the attendant benefits gained by your customer. Discriminators are vital, credible points meaningful to your customer. They provide the ammunition required to convince the customer that your organization is the best source for the contract.

Finally, themes can be categorized according to whether they are overarching themes or specific themes. Overarching or general themes implement program-wide bid strategies (as illustrated in Chapter 8). They carry a general message or emphasis that applies to every area of the proposal. Alternatively, specific themes apply to a selected portion of the proposal or a specific section or subsection. They most often apply to a specific aspect of your proposed approach. Features and their corresponding benefits, for example, typically are specific themes.

The starting point for specific themes is your bid strategy, which should have a theme for each customer key evaluation requirement (CKER). In addition, review your assessment of competitor strengths and weaknesses, plus your own strengths, with respect to the technical content of each proposal section and subsection. Combine this information with your knowledge of the customer and any peculiar or special RFP requirements. Your organization’s past and current experience and success performing comparable work are a great source of themes. In-place processes and systems, shown to be effective on similar programs, also provide rich ingredients for specific themes. Likewise, the relevant experience of people you are bidding to perform the contract can be used to fashion an important theme.

There is a remarkable sameness in competing proposals. Talk to anyone who has served on a government source selection team. What you will likely hear is that frequently there is no real difference between competing proposals. When that occurs, the award usually is made solely on the basis of cost. Lacking a compelling reason otherwise, the government always picks the low-priced bidder. Well-developed and strategically positioned themes help separate you from the rest of the pack.

Effective themes have three components: (1) a message, (2) proof or substantiation, and (3) benefit to the customer. The message is the theme statement. It contains the information or claim you want to convey to your customer. Proof is the information provided in your proposal to substantiate the claim. Perhaps the single greatest shortcoming of technical proposals is a preponderance of unsupported claims. Evaluators view unsupported claims as the dribble that falls from the south end of a northbound bull. It is better to have no claims than to fill your proposal with endless, unfounded boasts without support. The final theme component is to clearly state the customer benefit of your claim. Evaluators are instructed to evaluate only the information contained in the proposal. To ensure they get the point, clearly articulate the benefit of your claim or theme statement. Do not depend on the evaluator to make the cognitive leap from what you are proposing to the intended benefit. Recall that properly developed bid strategies include a theme statement, a clear statement of customer benefit, and a proof or substantiation component.

The example from Chapter 8 is repeated below:

• Theme: Our team experience in installing and integrating E-XB legacy systems mitigates the risk of system degradation due to potential interface problems.

• Benefit to Customer: Having Legacy Systems on our team, and as an integral member of our systems engineering and integration team, enables us to mitigate the risk of degrading the E-XB legacy systems. In addition, we will be able to maximize the potential effectiveness of the complete system, including the JTW modification.

• Proof or Substantiation: We will provide a copy of our teaming agreement with Legacy Systems and a copy of the preliminary JTW ICD with our proposal (normally as an attachment to a non-page-limited section of the proposal).

This information will need to be expanded and transformed into proposal narrative.

Identifying Features and Benefits

A primary source of specific themes is an analysis of the features of what you are proposing. Every part of your design, every system, every process—literally every aspect of what you are proposing—has a set of features. Figure 10-11 lists some general characteristics from which features can be derived.

Figure 10-11. Potential Categories to Identify Features and Benefits

Features are the attributes, characteristics, elements, or components that further describe the object or process being discussed. You can describe your car by listing its make, model, and year of manufacture. Its features are all the accessories that fully define the car. A sports car enthusiast might tell you about the size of her car’s engine, its horsepower, or the six-speed transmission and the rack-and-pinion steering. These are all features. The owner of a minivan, however, might be more likely to tell you about its seating capacity, its removable rear seats, and maybe its cargo-hauling capacity. Again, these are features. The features we talk about are those that have value or meaning to us. The features you communicate to your customers are the ones they considers important.

Features are important, but people generally do not buy features. They buy benefits. Therefore, to sell, you must not only highlight features but also demonstrate how those features will benefit the customer. People do not buy cars. They buy transportation. They do not buy a 250-horsepower engine, but the ability to accelerate from 0 to 60 miles per hour in under five seconds or the ability to enter the freeway without risking their lives. Similarly, you do not buy an air conditioner, but the ability to maintain air temperature at a comfortable level when it is hot outside.

To transform a feature into a useable theme, you must link it to a benefit. In addition, the benefit must be of value to the customer, or you must persuade the customer that it is a benefit. Do not leave it up to the evaluator to guess or intuitively link a benefit to a proposed feature. Express it clearly. If possible, quantify the benefit.

To develop features and their corresponding benefits, review the content of each proposal section. Identify the features of any proposed hardware, software, system, interface, approach, or process being discussed. Sometimes it is more difficult to identify features for processes than for tangible objects. Yet processes have features, too. Ask yourself why you use this particular process rather than some other process or approach. Why did you select it? How are process results used? If you did not use this process, how would you accomplish the task? Have you used this process successfully on comparable programs? There are always aspects of a process that make it effective, efficient, more reliable, etc. These are candidate proposal features.

Developing themes from features is a three-step process:

1. List all features for product/process/plan/approach.

2. Identify the value/benefit of the feature.

3. State how the feature specifically benefits the customer or user.

For example:

• Feature: Electronic Ignition System

• Benefit: Ten percent less expensive than traditional ignition system and increases time between engine tune-ups from every 5,000 miles to every 15,000 miles.

• Benefit to Customer: Reduces total acquisition and support costs by 15 percent and requires equipment to be removed from service less frequently for maintenance.

Proposing a 5-gigahertz microprocessor may be a phenomenal feature, but it counts for naught unless it produces a meaningful benefit to the customer. Things that benefit you may not be of value to the customer. For each feature and benefit, ask yourself, “So what?” Answering this question may help you express the benefit of a feature to the customer. After you have completed the list of features and benefits, decide which ones to include in your proposal.

Reducing Proposal Risk

You can write a great proposal section, cram it full of compelling themes, and still lose if you receive a high-risk rating. Hence, one of the keys to writing the winning proposal is to convince the customer you offer a low-risk approach. (Section M specifies whether a formal proposal risk evaluation will be performed and often outlines the risk evaluation procedure.)

Risk is an important consideration even in cases where it is not formally evaluated. Regardless of formal evaluation criteria, it is always a good idea to convince the customer that you have considered and mitigated any potential risks that could jeopardize program success.

To conduct a formal risk assessment, government evaluators assign a risk rating based on your proposed approach and probability of accomplishing RFP requirements. Risk is assessed according to three risk ratings—low, moderate, and high—and it typically considers technical performance, schedule, and cost (see Chapter 3 for details).

Receiving a proposal risk rating of moderate or high can spell disaster for your technical proposal. Customers universally avoid risk unless there is a persuasive reason otherwise. Most often, winning proposals receive low risk ratings across all evaluation factors. There are exceptions, however.

Customers are usually more risk-tolerant for development programs, especially those involving new technology, than they are for service-type contracts. Furthermore, recall that proposal evaluation is always relative to what competitors bid. Everything else being even, you can win with a risky approach if it is less risky than that proposed by your competitors, or perhaps if the risk is offset with comparable customer benefit.

Proposal risk is not “real” risk but the perceived risk as assessed by source selection evaluators. Your proposal task is to convince them that you have taken the necessary steps to mitigate potential risks. Competitive advantage most often goes to the bidder with a low proposal risk rating. It may be acceptable to carry several areas with a moderate risk rating, but only if you can show clearly the benefits of such an approach.

Sheet 2 of the author guide has a space to record potential proposal risks and the actions you have taken to mitigate each risk. Read over your proposal section. Identify real or perceived risk areas related to your proposed approach and the RFP requirements. Try to put yourself in the role of the customer as you review your proposed approach. It is customer perception that counts here.

Once you have a list of potential risks, review them to determine which will be significant and meaningful to your customer. Do not list every conceivable risk. Otherwise, you may frighten evaluators by suggesting that everything you are proposing is risky. After you have culled the list to those that merit being addressed in your proposal, state what actions you have taken, or will take, to mitigate them to an acceptable level. Then integrate the risk reduction actions into the outline and technical proposal.

Through your pre-proposal interactions with the customer, you should already have a good idea of those areas the customer perceives as risky. Some typical sources of risk are listed in Figure 10-12.

Figure 10-12. Common Sources of Perceived Proposal Risk

Some RFPs specifically require you to address risk management, including providing a list of potential program risks and the steps you have taken to mitigate those risks. In such cases, bidders usually include a risk table in their proposal (see Figure 10-13). This satisfies the risk management requirement, but it alone does not eliminate the importance of integrating risk mitigation strategies throughout your proposal.

Figure 10-13. Sample Risk Management Table Entry

Include clear statements about how you will mitigate potential proposal risks. Mitigation strategies must be tailored to the specific risk, program requirements, and customer. Some factors that help mitigate assessed risk are listed in Figure 10-14.

Figure 10-14. Ways to Mitigate Perceived Proposal Risk

Example of Risk Mitigation

A simple approach to mitigate potential risk, and avoid an unfavorable proposal risk assessment, is as follows: To mitigate the risk of [risk area goes here], we have [actions you have taken to mitigate the risk go here]. The actions taken must be described in enough detail to make the mitigation story believable.

Here is an example taken from a proposal in which we were bidding a system that required well over a million lines of software code:

We included a table showing for each computer software configuration item the amount of software required, the computer language, the amount of software we could reuse, and the amount of new software to be developed. We eventually received a low proposal risk rating and a technical strength for the software design portion of the evaluation.

Ghosting Competitors’ Approaches

Ghosting is a strategy to exploit a competitor weakness or counter a strength. Ghosting can cause the customer to view a competitor’s approach as less desirable or more risky than what you are proposing. Proposal risk offers an opportunity to develop a potential ghosting strategy.

If you suspect that a competitor is going to use a subcontractor to perform an important part of the contract, highlight the point that you are avoiding the risks involved with using subcontractors. This can be especially effective if the customer has experienced problems in the past where subcontractor performance has negatively affected program success. Highlighting a risk and presenting your mitigation strategy can also ghost a competitor that fails to identify the same risk, if that risk applies to the competitor’s approach.

Trade studies represent another way to ghost a competitor’s approach as being inferior to what you are proposing. Let’s say you are proposing computer “X” and a competitor is proposing computer “Y.” You conduct a trade study to evaluate candidate computers, including “X,” “Y,” and “Z.” The results show clearly that computer X represents the best choice. List the reasons you selected computer X and the reasons you rejected computer Y.

Because you control the study, you can set trade study evaluation criteria and weights to give the results you want. Besides, there should be some valid reasons why you chose computer X; include them in your proposal. By presenting trade study results, you can lead the customer to the same conclusion: Computer X is the right choice. Incidentally, conducting trade studies to validate your proposed approach is also an excellent risk mitigation strategy.

Ghosting can be used to highlight a competitor weakness. First, you can emphasize your strength, experience, or competence in a particular area and show how this is important to program success. Or you can point out how lacking this “strength” could jeopardize or undermine program success. Yet another way of ghosting is to point out why you are not proposing an approach that you suspect one of your competitors is proposing. For example:

• “We considered using chemical X in our process but abandoned it when we discovered it had led to the death of half the population of Pakistan.”

• “We use a reflected optics aim point system to avoid the safety hazards of a laser eye point system.”

• “Our system uses a collimated display, which avoids the inherent shortcomings of an uncollimated display, including safety of flight and degraded training effectiveness.”

Clearly, the first example above is my attempt at humor, but it makes the point. The second example comes from a situation in which we were the only bidder not proposing a laser eye point system. This was when people were very concerned about eye safety surrounding the use of lasers. Even though none of the systems were dangerous, we attempted to “ghost” those competitors proposing the laser eye point system.

Ghosting is about manipulating customer perceptions. It is a way of trying to stack the deck against your competitors. Manipulation does not mean being underhanded, nor does it suggest being dishonest. Honesty is an absolute in proposals. It is acceptable to exaggerate the truth, but not to invent it. Never lie in a proposal or claim something that is clearly false. Nonetheless, it is acceptable to present information that shows your organization and your proposed approach in the best possible light, much in the same way you would in a personal résumé. Within the boundaries of honesty, it is okay to present information in a manner that casts doubt on the approach or capability of competitors.

Enormous competitive advantage is the spoils of the bidder who successfully plans to prepare a completely compliant, responsive proposal that highlights themes and discriminators to sell the proposed solution. Seize this advantage through effective planning. Develop a proposal outline that perfectly reflects the Section L instructions. Integrate evaluation criteria and other RFP requirements into an easy-to-use proposal requirements matrix. Then prepare author guides to establish a proposal preparation blueprint based on this information. Integrate your bid strategy and key characteristics of your proposed approach into the author guide.

No aspect of the proposal development process is less forgiving than the planning phase. Fail here, and the prospects of winning are dim indeed. All too often proposal teams feel pressured to start writing. So they launch into a first draft response without a plan. This typically results in a huge scrape rate. Resist this temptation. Time spent planning will pay huge dividends when it comes to writing proposal narrative. Rarely will you hear people claim that the reason they lost a competitive bid was that their planning was too good.