In This Chapter

Now that you have a strategy to guide your response, your next step is to launch the formal proposal creation process. The proposal documents you create will communicate your response to the customer. It is your strategically crafted case for why your company offers the best solution. This chapter focuses on the documents that support the proposal effort, not the actual proposal itself. Those are the technical, management, and cost/price volumes found in Chapters 16, 17, and 18. These documents are the ones you need to develop at the start of the effort so you can effectively and efficiently develop the proposal.

Here, you learn about developing a proposal plan that serves as a guidepost of sorts for the proposal itself. A proposal plan usually has several attachments, some of which are provided as samples in Appendix C. You also learn about documents you need to find in your company’s records or create, as well as materials you get from the customer or the public domain that you need to keep.

The proposal plan is the first formal document your team should create because it is the control mechanism for your proposal team’s activities. Without a proposal plan, you’ll surely get chaos.

The proposal plan is a living document that evolves during the proposal creation process so don’t feel you have to get it completely right the first time. As you create the plan, you’ll make estimates and wild guesses and sometimes even enter incorrect information without realizing it, all of which you can replace as you go along with the latest-and-greatest data and ideas.

This proposal plan outline gives you a high-level view of what should go into the plan.

To bring the proposal plan outline to life so that you can envision how your own team’s might look, we provide the elements of the proposal plan, and discuss each item.

Once you create your plan, you’re ready to pull together the core documents to support it.

The core documents are materials every proposal, without exception, must have. They form the heart of the proposal plan because they play critical roles in keeping you on track and focused for a successful proposal effort. You’ll see how this plays out as you read about each of the five documents, which are:

Each of these attachments has a two-digit index number at the far left. These numbers are very useful, so retain them in your own work. One large advantage to using these numbers is that the file structure within the folders lines up automatically, from 01 to 23. Any index numbers that are missing will show up immediately, making quality control easy.

You should use these document labels consistently, including the leading index numbers, across all the proposals you create. Consistency enforces discipline on your proposal teams and increases the efficiency of the teams.

The contact list is a list of all proposal team members. It is vital that each member of the proposal team, including any and all subcontractors, be on this list. Each member listing should have the company name (if more than one company is on the team), the individual’s name, their proposal team function (don’t use company job titles; use proposal team role title), work phone number, mobile phone number, home phone number (if you can get it), and e-mail address.

This document shows the milestones for each of the important events in the development schedule. Show milestones and not activities. If you show milestones, the activities will be clear. Show both historical (that is, achieved) milestones to put those in perspective to members who may be joining the team late and to show how many steps you’ve already taken to get to this point. The table that follows shows a sample proposal development schedule.

The last two entries in your schedule, the contract start date and the victory party date, are important. Never put out a proposal development schedule without both a contract start date (probably just an estimate) and a date for the victory party, even though these two dates may seem a long way off and might never even come to pass. But always put out a schedule that plans for success!

The only document in the proposal plan that is likely to be something you’ll also hand over to the customer with your final proposal submission is the executive summary.

Some solicitations require an executive summary. In that case, you must follow the instructions of the solicitation and deliver the summary exactly as required. However, more often, there is no specific requirement for an executive summary, but it’s a good idea to create one anyway both for your internal use and to submit to the customer. A well-constructed, communicative executive summary serves three purposes:

To create an executive summary, you can use templates from other proposals, archived photos or other visuals, action captions to show why you’ve included a text or visual in this document, and anticompetition themes wherever possible. Do not use any anti competition themes you’re unsure about.

Further, if the solicitation does call for an executive summary, you can use the following outline to create something with a different name so as not to confuse the customer with two documents having the same name. Call it “Solution Overview” or “Our Commitment to (the customer)” or something creative fitting that specific opportunity.

Perhaps you’ll never actually formally deliver this version to the customer as a part of the proposal, but you may still have an opportunity to use it with the customer, subject to the rule that everything be given to the customer through the customer KO.

The following list shows the typical format of an executive summary. All elements listed here may not be right for your proposal as this is only a recommended checklist. This list of components is just illustrative and not definitive. It is a starting point for your really creative people to build you one for a specific opportunity.

As covered in Chapter 8, proposal drivers are a topic in your early strategy meetings when you discuss the opportunity and the possibility that your company will become a candidate for bidding. This document has four simple questions about your solution. If you can give good answers to each of these four questions, you’ll likely be able to build a strong case for a contract award. If you have partial or weak answers, you must either take steps to improve your answers or seriously consider whether you can create a winning solution.

This document not only contains the outline of your proposal, as driven by the Section L instructions, but also assigns the responsibilities for each piece of the outline to an individual. (This applies when there really is a Section L. If the solicitation does not have a Section L, then substitute whatever instructions provided that dictate how your proposal must be organized.)

Make these assignments as specific as possible, to individuals rather than to organizations or groups of individuals. Proposal management should have a single point of first-line responsibility for each piece of your solution.

This document is perhaps the single most important one in the attachments to your proposal plan. This matrix accomplishes three distinct, but related, purposes:

To develop this outline and matrix, you’ll need to know the nitty-gritty details about the various sections of the solicitation—how a solicitation is typically structured and what it’s asking for. See Chapter 14 for introduction to this material and then details in Chapters 16, 17, and 18.

Noncore documents are optional ones depending on what’s needed for a specific opportunity. This list, in rough order of importance from most important to least, gives all the noncore documents in the proposal plan. The importance is always a matter of judgment and taste, and therefore the right answer varies from solicitation to solicitation. For example, for some solicitations, the Commitment Letter is very important, which moves it up the chain. For others, perhaps the Hot Buttons rises above its normal rank.

In this list, the items with an asterisk (*) are those derived from the solicitation. The content of all others is the proposal team’s choice.

Note that four of these noncore documents are driven largely by the solicitation. These are the attachments indicated by an asterisk (*). They must appear in the proposal plan because (sadly) no matter how many times proposal managers ask, request, cajole, entreat, beg, or threaten some members of the proposal team to read the important sections of the solicitation, that proverbial 10 percent fails to get the message. Including them or excluding them is a judgment call by the proposal management team.

The action item list tracks the items the proposal team needs to resolve. It is a living document that changes every day. And it’s the main document supporting the proposal team’s daily stand-up meeting.

The action list has seven columns:

This is a sometimes simplified version of Section M. Moreover, these can be value-added through your own team’s notations on the factors. For example, the owner of this one can solve the word problem as discussed in Chapter 14. This solution shows your own team’s best guess at the relative weights of the proposal parts, and this set of weights then influences the allocation of the (usually limited) page count.

As you have already formed the proposal team with assigned roles and responsibilities (see Chapter 6), now you are documenting the current version of those roles. Often, you will see changes in personnel during the proposal creation process as individuals take on new assignments and new folks come on. It is important to reflect these changes in this document and to change the contact list, correspondingly.

All solicitations let the offerors ask questions of the KO. The FAR requires that the KO respond to these questions (within reason) and to share both the questions and the answers with all prospective bidders. The companies asking the questions are never identified by name.

Most of the time, the solicitation contains a very clear format for the past performance submissions. Unfortunately, there is a frustrating inconsistency among agencies in these requirements. One agency asks for contract dollars but not manpower. Another procurement shop, within that same agency and sometimes within that same procurement shop, will ask for an entirely different set of statistics. This phenomenon causes an unnecessarily large burden on the offerors. In fact, large companies typically have staff members whose only function is to respond to requests for past performance. And even small companies must spend a lot of time and money tailoring their responses. So to solve this problem, at least partially, you should develop a comprehensive folder on all your contracts. This folder can then serve as a source document for these responses and cut done (but not eliminate) the necessity of data mining for each response.

The kickoff meeting is typically held about three to five days after the release of the solicitation. Sometimes there is more than one meeting: one upon release of a draft solicitation and another upon release of the final. For details see Chapter 14, but for now know the agenda for the kickoff meeting should be part of this set of documents.

Communication among team members is critical. For major efforts, the industry standard practice is a daily stand-up meeting. These are mostly held in the early morning, but when team members are scattered over time zones, set the time to accommodate as many members as possible.

The call-in process should involve at least an audio link, if not also a video link, which allows team members to see the same screen desktop available to the members in the meeting room. The prices for teleconferencing services allowing desktop sharing among team members are coming down rapidly. Both hearing and seeing the materials under discussion is best.

This document gives complete instructions for the call-in number and the required participant code. Limit the distribution of the host code to only a few individuals to minimize the danger of compromise of these meetings. But do make sure more than one person knows the host code in case the primary host can’t chair the meeting.

For major opportunities, the customer specifies a page limit by major section. Part of that page limitation is the specification of text margins, typeface and size, and which pages do and do not count against the page imitations. This formatting document must match the solicitation requirements. Where it is silent about formatting requirements, the proposal team makes its own decisions on format. For example, you may determine all visuals must have two labels: a horse title—which means if you show a horse, label it “Horse”—and an action caption or text that tells the story of the visual. (See Chapter 15.)

In long and complex proposals, written by many individual authors, this document provides helpful guidance on how the proposal team responds to certain solicitation requirements. For example, is the bidding team “Team XYZ” or “the XYZ Team”? This is simple enough, and either is correct, but mixing the two in the same proposal shows a lack of team discipline that is unsettling to the evaluators. And it’s unnecessary. It’s up to someone on the team, usually the proposal manager, the capture manager, or a senior editor, to provide top-down guidance.

Here’s a common situation. Let’s say the XYZ Team has four members: XYZ, Acme, Bluenose, and Cardiff Technical. On page 4 of the technical volume, the proposal speaks to the team members in that order, but on page 17 of the same volume, the order is: XYZ, Cardiff Technical, Bluenose, and Acme. And the visual in the management volume shows a third order. Any order can be correct, but using different orders is unnecessarily sloppy and can confuse the customer.

There are two logical solutions to this problem. After XYZ, the prime (always listed first), you can go either alphabetically (least likely to be offensive to any company) or in the pecking order of the subcontractors. Let’s say that Cardiff Technical is a company known and loved by the customer and your XYZ Team was really lucky to attract Cardiff Technical to your team. That’s a good reason to list Cardiff Technical first, followed by Bluenose (second most important), and then Acme (least important but on the team).

Your meetings with the customer (see Chapter 5) and other sources (such as the customer’s previous unhappy experiences) should tell you which subjects are of particular interest to them. For example, in telecommunications contracts, there has been a great deal of unhappiness among many customers with the way a new contractor takes over from the old (outgoing) contractor. When the customer suffers service discontinuities during the transition from the old to the new contractor, they lose valuable resources. The aggravation to the customer then becomes a hot button.

The responsibility for identifying those hot buttons lies mostly with the relationship manager and the capture manager. If your team knows the customer hot buttons and addresses your plan for mitigating the risks present in those activities, the evaluators will have a warm feeling about your plan. It’s good to turn the customer’s anxiety into confidence.

This letter is related to, but different from, the transmittal letter. This one is also seen by your customer. The substance of the letter is that you and your company or team is committed to the success of the program. It is addressed to the decision maker at the customer organization from his or her counterpart in your own organization, and TM signs the commitment letter. It is to your team’s advantage to obtain the signature of the highest-ranking individual possible in your company. If you are the CEO, it’s your job to sign the letter on the important bids.

This letter is optional but a good idea. It gives a name and face to the commitment of your company to solving your customer’s problem. People (your customer) buy people (you and your company) and not just companies.

The transmittal letter responds to the solicitation and is one of the few attachments to the proposal plan your customer sees. Typically, the letter responds directly to any concerns shown in the solicitation. Your contracts manager (CM) signs these letters. The best letters are brief and focused on the customer’s concerns, as expressed in the solicitation. Typically, the CO points out any deviations or exceptions you are taking to the requirements of the solicitation. It’s best to avoid taking deviations and exceptions at all. However, if you feel compelled to ask for exceptions and/or deviations from the specifications, you should do so only with great reluctance and humility and explain them in the letter.

Make this transmittal letter very formal, stating that you, the offeror, are now submitting these documents for the customer to review. For example, if the solicitation requires your offer to be open for 180 days, state here that your offer will, in fact, be valid for 180 days. The objective of this letter is to demonstrate compliance with the solicitation.

In proposals with multiple volumes and multiple authors (and all large proposals qualify on both counts), you’ll need a fact sheet. This document keeps track of specific facts used in the proposal. My favorite example is the number of employees in your company and the total number of employees on the team as a whole. Left without adult supervision, these quantities will appear in different volumes, and sometime within the same volume, as wildly different figures:

To resolve this through top-down proposal leadership, have a short meeting of knowledgeable and concerned individuals and get the facts straight; then communicate those to all involved.

Your customer wants to know the background and qualifications of the important individuals named to lead your program team. The evaluators want to do an apples-to-apples comparison of, for example, your program manager with the program managers of your competition. So giving a resumé template in the solicitation simplifies the evaluators’ job.

Unfortunately, formats vary greatly from solicitation to solicitation, so there is no standard resumé format. Your company may have a standard format, which is good news. The bad news is that you can almost never use that format in a proposal.

Furthermore, even if there were a standard format, you should at least consider tailoring the format you’ll use for a specific opportunity to match the characteristics and terminology of the resumé content to this specific opportunity.

Here’s an example. Let’s say the solicitation has four requirements for your program manager. Your program manager-designate has 31 years of experience and has held a wide variety of jobs involving a dozen major technologies in his career. The solicitation requires 15 years of professional experience and specific experience in any 3 of a laundry list of 15 categories. So from the list of 15, you pick this individual’s strongest 3 then rewrite the resumé to highlight the 3 chosen specific experiences.

I’m not now or ever advocating that you rewrite the resumé to include statements that are untrue or misleading. That is never a good idea. That said, it is fair and proper to emphasize the three specific experiences matching the solicitation. The idea is to make it easy on the customer’s evaluators to find the experience and to give your person a high score on meeting those requirements.

Customer documents are items you receive from the customer or that you find about the customer. These help your team keep track of everything you know about the customer and about the opportunity they’re offering. Customer documents typically include the following:

Do not mix any of your own documents with the customer documents. You‘ll find yourself tempted to mix briefings you’ve given to the customer, say right after you submitted your response to the RFI. Don’t do it. If you do, you may never be able to find it in all that snowstorm of customer documents.

This category, usually the smallest folder, has clippings from newspapers, trade journals, and professional journals. The most common other type of documents is the results of studies provided by third-party vendors.

The Least You Need to Know