In This Chapter

The proposal your team will create as a solution to a customer’s solicitation can number in the hundreds or even thousands of pages, and those pages will go through many draft versions before everyone is satisfied with the final document. Proposals vary greatly in length, but a typical technical portion is 75 pages and the management portion, 50 pages. The cost portion is usually not limited. The customer leaves its length to the judgment of the offerors.

The final creation you submit to the customer is likely to be one hefty document. This means that keeping track of the various pages and parts and iterations during the creation and writing process can be a challenge. You also must work within page limitations set by the customer and can’t create a document so hefty that it’s too much to read. You must use those pages carefully. Creating proposals is inherently inefficient and expensive, so it’s important to keep focused on the process.

This chapter offers several ways to ensure tight text control, including creating and enforcing writing standards and conventions; using the dreaded intermediate documents; getting reviews from internal evaluation teams; holding another bid decision meeting; and tracking questions and answers you exchange with the customer.

The first step toward reining in the process is to assign someone on your team the responsibility of establishing and enforcing proposal creation standards. Usually the proposal manager takes on this responsibility, but anyone willing and able can do it. The typical large proposal has many authors, each with a unique style and idea of what makes a good proposal. So to create a one voice proposal with the appearance of one author requires the application of uniform standards to the entire proposal document.

In Chapter 12, two documents support good proposal writing. These are attachments to the proposal plan:

From that same list of attachments to the proposal plan, three other documents also act as guideposts to proposal writing standards and conventions:

Each of these helps you achieve the consistency among proposal sections that is a hall-mark of a well-written proposal.

The late Bud Wilkinson’s Oklahoma Sooners put together a winning streak of 47 football games between 1953-1957. Legend has it that someone asked the president of the University of Oklahoma what his own contribution was to the university. In reply, he said something like, “I’m trying to build a university that our football team can be proud of.” Correspondingly, you’d like to build a company that’s as good as the one described in your proposals!

The language you use in proposals is important, so another early step in setting writing standards is to identify some wording you should or should not use. Especially in page-limited circumstances, both precision and economy of words are necessary to make your case.

Here is a list of some “No-No Words” and the corresponding “Yes-Yes Words” you should use in their place:

Some offerors try to use these words to describe the amount of time a specific individual is going to give to this program, which is especially important when you are designating an individual with positive name and face recognition with the customer. This could be the program manager-designate, a senior engineer, or some other individual in a conspicuous position on your program team. “Committed” means nothing unless it is backed by the willingness to spend risk money (funds not provided by a contract but from company margin or profit). “Dedicated” is similarly not well defined. What does it mean? If you mean this individual is planning to work on this program and this program only, then say “full-time.”

Research leader—The no-no word is a description of this person’s function within the company. If the research leader is the program manager, then call him “program manager,” and don’t confuse the customer. The important thing to the customer is this person’s function on your program team.

In order to—The “in order to” contributes nothing except more words to this text. Do a word search for “in order to” and strike this phrase from your proposal.

Proposal, proposed—It may strike you as strange to take out “proposal” (in any form, such as “proposed”) and replace it with “plan.” The reason is simple: the whole thing is a proposal; what you’re submitting is a proposal. Using “proposal” leads to an unnecessary tentativeness in your writing. Good proposals are plans, and good plans are, in effect, proposals.

Consists of—Most often when you are tempted to say this, you really mean you’re not going to list everything in the text that follows. That’s why you’re much safer and more accurate to say “included.” You can do even better if you really do know all the elements in the list, in which case you can say, “The following seven items ….”

Utilize—This is a truly awful word. It’s pretentious and belongs on another planet. Just use “use.”

Overall—Where I come from, overalls are made of denim, and you put them on one leg at a time. You almost always mean either “total” or “high level” or even “overarching.”

Basis—The most common misuse of this word is something like, “meeting on a daily basis.” So just say, “daily meeting” or “meeting daily.”

Try, intend, purpose—As in, “we’ll try to …” or “we intend to … ” or “the purpose of this hardware ….” Never “try” or “intend” to do something. “Plan” to do it. The hardware doesn’t have a purpose; it actually does something, at least in your plan.

Whether the evaluators see your proposal by hard copy or electronically, the physical appearance is an important indicator of quality. So bring your team to agreement on the expectations for how the finished product will look. Most of the guidelines below apply to proposals submitted by hard copy, so if you’re submitting electronically, just disregard the points that don’t apply (such as weight of paper the proposal is printed on). Be aware, however, that even if you submit on a website or as an e-mail attachment, you’ll usually end up printing copies of your proposal on paper. You might submit copies to the customer along with the initial electronic version, distribute copies within your company, or take them with you to any oral presentation.

Many books have been written focused solely on principles of good writing. But when it comes to writing proposals for government contracts, a few key pointers stand out above all others:

The JIT training your team will go through as part of the kickoff meeting includes these and other principles.

Visuals show your solutions in a vivid and attention-getting way. Your objective is to have the evaluators quickly grasp the features and benefits of your solution. Then, the text re-emphasizes those points and seals the deal with the evaluators.

Every visual has two labels: a “horse title” (if it’s a picture of a horse, say “horse”) and an “action caption.” The action caption says, in words, the message the visual gives. Unfortunately, many SMEs begin their response to a request for describing an important point in support of the proposal creation with a hand-drawn visual. They sketch something out and then begin to explain the meaning. This is conceptually wrong. The right way is to start with the action caption and build the visual around that, because it’s the message that’s important, not the sketch.

Why do we even use visuals? Let’s start with the old saying, “A picture is worth a thousand words.” That’s one reason. Another is that you’re almost always page-limited, and you need to use every trick in your book to get your message across within the fewest number of pages. But the rule is that you use visuals to reinforce the materials in the text and vice versa. It’s at best confusing and distractive to have one set of messages in the text and another in the visuals. They should match and complement each other. Be aware that different evaluators work differently; some are visual learners and some are text learners. Your messages should be consistent for either type.

Your proposal team members are likely to bring different skills and interests to the table when it comes to writing proposals. But many of them will have writing included as a part of their responsibilities. Some may even have little or no experience in proposal creation. By the time you and your team are ready to start writing, the members should have had at least the Just-In-Time (JIT) training included in the kickoff meeting. That is actually only the minimum amount of training needed to do the job. Many team members are going to need additional guidance in order to be solid contributors to the proposal creation process.

Your technical people are often only reluctant participants. These folks would rather be doing what they are good at: engineering, scheduling, finding the best network solution, building something no one else thought could be built, or working at almost anything other than proposal writing. So your team’s task, and maybe your task, is to encourage those reluctant participants. But remember to be reasonable about your expectations concerning their writing abilities.

Leverage their contributions; exploit their strengths, and ignore or shore up their weaknesses through other personnel, such as professional writers. Encourage these individuals to do the thinking, and create versions of visuals to tell their story. Don’t expect nonprofessional writers to deliver Pulitzer Prize-quality writing. It’s just not going to happen.

Progress toward a complete version of the proposal is not a smooth process. It’s a complicated process that doesn’t typically go smoothly.

Plan before you write. Don’t be deceived by thinking you can just start writing without a plan. If you do, you can be surprised by the difficulty of finishing the task, in spite of apparent easy going early.

Let’s say you have a 60-day time frame for your proposal. Your inexperienced author has 20 pages to write. At the end of the sixth day, he has two pages written. That seems good. Ten percent of the time has passed, and he has 10 percent of the text done. He’s right on track. Hardly. What he’s done is the easiest 10 percent. What happens at the 50 percent mark when the going gets rougher? The fifth and sixth pages are not so easy. The lesson here is to plan and then write.

Be quick to praise, and slow to criticize the writer’s work. Limit the writer’s time responsibilities, and focus his attention on activities he can understand and embrace, even if not enjoy. Have the authors help create graphics, with the help of a graphic artist, or explain a relevant technical point to a technical writer. The result can be much better than relying solely on technical people to “write.” No one does anything right the first time. Remember, proposals do not spring forth from nothing into final form, but are created a page at a time.

There are two classes of proposal plan documents (see Chapter 12):

No one likes developing intermediate documents. Many team members, particularly those relatively new to proposals, are frustrated by the requirement to build the proposal through a structured process. These folks want to jump right in, write their sections, and go on their way. Unfortunately, this simply doesn’t work. That would be like trying to build an extra bedroom on the second floor of a new home without worrying about the basement, the foundation, and all the supporting structure.

Before launching into the creation of text solutions, the authors (see The Responsibility Assignment Matrix in Chapter 12) must first devote time in planning their part of their solution by producing a document for review by other team members (peers, supervisors, and other reviewers).

Some sections of solutions will be better suited to an outline, and others to a storyboard form. The common element is that your authors should begin by creating a review document (outline or storyboard) matched to their individual assignments.

The storyboard is a great tool for converting an idea to a source document to guide a response. These come in a variety of forms, all designed to allow the storyboard creator to describe the required response (or better, “solution”) using bullets, graphics, tables, and other devices. Upon review and approval of the storyboard, the authors then have the go-ahead to convert those ideas to text.

Creating proposals is an iterative process. You begin with a high-level outline as supplied by 05 Outline and RAM, a proposal plan attachment. Using that framework, you and your team develop more detailed outlines and/or storyboards. Immediately, your team will experience problems with the control of these various documents. Someone will ask, “Who has the latest version of Section 3.12?” This can be a serious problem unless your team practices good version control.

It’s a rare achievement to do something right the first time, so your proposal will likely go through many versions until it’s a quality finished product ready to submit. One way to ensure a great finished product is to have qualified people review and evaluate various versions as you go along. The trick is to get the right kinds of evaluations at the right time by the right evaluators to achieve an increase in the quality of the versions.

Evaluation teams come in six types, each of which we describe in the order it is typically used. These teams usually work on a 60-day turnaround time basis, with days being calendar days, not work days. (By the way, we use the terms “review” and “evaluation” interchangeably here. Different teams use different terms, so get used to hearing both.)

The black hat team plays the role of the “bad guys.” They can do a review at any time but certainly should do one either just before or just after the release of the final solicitation. Members of this team know the competition, and their objective is to assess the competitors’ strengths and weaknesses regarding technical management, past performance, and price range. Using this knowledge, the team then compares these strengths and weaknesses with your own strengths and weaknesses. The result of the evaluation should be strategies you can use to make a convincing case that your own solution is not only different from but also better than those of your competitors.

The green team evaluators focus on the financial, cost, and price aspects of the proposal, thus the name “green” for money. Their review usually begins five to seven days after the solicitation is released. This team is interested only in how the cost volume is progressing, giving only passing consideration to the technical or management aspects. It looks for opportunities to cut costs while still meeting specifications. In large companies, individuals from other divisions with cost knowledge and responsibilities are particularly effective members of this team.

Members of the green team should include the following people:

In addition, the team may take a look at about a half-dozen alternative technical and management approaches and decide (or at least provide analysis for a decision) which of these is the best approach to use for this opportunity.

The heart of this review is the creation of a seven-column table. Each column in the table represents a different case, which is a management, technical, or others (such as logistics or build vs. buy decision). In the stub column of the table, list and describe the characteristics of the solution. The final entry stub column is “Relative Cost.” In the first, or baseline, column for cost, enter “1.00” to signify that this is the column that will provide the nominal value of 1.00. Other entries in this row will be assigned numbers indicating an (imprecise) estimate, or guess, of the cost of that column, in relation to the base column. Be aware that these are often very rough estimates and not based on lots of detailed cost analysis.

At the top of each column, name the alternatives, the first case column being “Baseline.” The next column might be “Decentralized Program Management Office” or “Juniper Equipment” (for example, if Cisco is in the baseline case).

Think creatively long enough to develop as many as five to nine cases, each with a relative Rough Order of Magnitude (ROM) cost. Then on the basis of your best judgment of what the customer really wants to buy, choose the real company solution.

Assuming this is thoughtfully done, it is highly likely that one of the discarded cases is the solution of one of your competitors. If you know that, then you’re in a position to “ghost” that competitor’s solution and show that your solution is not only different from, but also better than, theirs.

The pink team is called pink because they’re not ready for red, as in a proposal that’s not ready to have the red pen put to it for a heavy-duty edit. This team usually does their review about 15 days after the solicitation release, and its members are typically in-house people at your organization but not members of your main proposal team for this effort.

This team’s review is at the storyboard or outline level. Typically, there is no text to review at this time. In fact, if there is text, that’s usually because it has been mined or borrowed from a past proposal. Upon the conclusion of the pink team’s review, the various authors should have an approved outline or storyboard and be turned loose to convert the ideas and approaches into full text.

Even though the red team’s review may be done mostly electronically with editing marks that may or may not show up in red, this team takes its name from the tradition of editing a document with a red pen. Or you can think of the name as representing the blood spilled at their review!

This team conducts an evaluation about 10 to 12 days before the proposal is due. Your desired standard for the red team version is that the version should be good enough to go to the customer, with some cleanup of visuals and resolution of minor conflicts between or among sections. The Red Team is also the last major opportunity to ensure compliance with customer requirements.

With purple being the traditional color of royalty, this team’s title is fitting for the top management (TM) reviewers. The purples review the proposal concurrently with the red team. The near-final version of the proposal is given both to top management in your own organization and the top management of your subcontractors. This team does not meet formally as the others do. Instead, you bring TM into the process in this way without allowing their membership in the concurrent red team. Having this team accomplishes two things: you keep TM off the red team (their presence on the red team can be so powerful it dominates the team, which you don’t want); and TM has the benefit of the then-current state of the proposal version, so that TM is fully prepared to help the proposal team take into account the red team comments.

The gold team is made up of important people who have the authority to approve the submission of your proposal. They may not be the very top management individuals but are usually the trusted lieutenants of TM. Their review is done two or three days before the proposal is due. This is well after the red team comments have been incorporated into the proposal version. This is the absolute last chance for your company to make changes before submission and typically includes last-minute decisions on cost issues. The trick is to make those decisions cascade through the balance of the proposal document, to ensure consistency among the volumes, and particularly to ensure that the cost figures match those in the other volumes.

You must keep careful track of the questions your CM has submitted to the customer, along with the customer’s responses to your questions as well as to those of your competitors.

Here’s a checklist of tips for why and how to track the answers:

In Chapter 4 we introduced you to the concept of bid decision points. The first three points came up in Chapters 4, 8, and 14. Now that you’ve read Chapter 15, you might find it surprising that you could get all the way to the process of starting to write the proposal and still be considering not bidding. But remember, the process of creating a solution and a proposal to submit is such a lengthy, expensive endeavor, that even if you bow out at this point after having invested considerable time and some money, you are still ahead of the game.

Now, as you’re on the brink of committing the bulk of the time and money required to create a large proposal, you face Bid Decision Point #4. Do you proceed with the plan and bid to win, or do you cease all efforts and try again another time?

TM is the final decision-maker on all bid decisions, including this one. At each bid decision point, TM decides: go or no-go. Sometimes these decisions are easy, and sometimes difficult. The best TMs listen carefully to all relevant proposal team members, but in the end, TM makes the decision.

The Least You Need to Know