Create the Draft Proposal

Now that the assignments are made, contributions will start trickling in. You will need a way to keep track of them and integrate them into one master document.

In the old days, the proposal manager created a "control document" that no one was allowed to touch. The manager was the only person who could add or delete content, because multiple hands touching the document exponentially increased the chances of messing it up. If you are creating proposals using your word processor and perhaps a basic automation tool that handles the cut-and-paste function, you will still need to maintain a control document. However, there are more advanced software systems available that manage all of the various contributors' input, keep it from clashing or overwriting, and provide you with the ability to see the entire project simultaneously. This is the kind of basic productivity tool you should invest in if you typically work as a team on proposals.

Figure 8-4 shows the most efficient sequence in which to write. Start with the executive summary. Sometimes people think they should write the executive summary last, thinking that it is supposed to serve as an abstract or pr cis of the entire proposal. However, that isn't the function of an executive summary. Rather, it is intended to provide an overview of the business case for the top executives. It summarizes the client's key needs and desired outcomes, offers a high-level presentation of your solution, presents a couple of key differentiators, and outlines your basic value proposition. You should be able to write this content as soon as you've held your kick-off meeting. By getting it done right away, you give everyone else a model for both style and thematic positioning to which they can refer as they work on their assignments.

Figure 8-4: The Order in Which to Write.

Next, write the introductory paragraphs to each major section of your proposal or have your contributors write them. These paragraphs contain the most general information about the section and can be written even if the details of the technical solution have not been finalized. In addition, they are areas where you want to emphasize your win themes. By having your contributors write them first, you can make sure each of them is on the right path. Here's an example of what the introductory paragraphs to a section might look like:

The following section addresses the specific features of our software and how users can customize the interface to meet their own requirements or preferences. Specifically, this section discusses the tools included in the standard package that make it easy for a user to modify the view of data. These tools reduce the time it takes to locate and process data, thereby increasing productivity.

This section also discusses how a system administrator can enable users to make modifications at the desktop level or can make modifications that affect the entire enterprise. This capability allows you to match the software to your specific work environment and requirements, eliminating the need for customization and reducing the amount of time the administrator spends configuring the product for individual users.

As you probably noticed, these paragraphs are not merely descriptive. Instead, the last sentence of each paragraph states a key win theme for this particular proposal, namely that the software can improve productivity because it contains unique time-saving features.

Next, write the basic description of your solution. You may need to fill in gaps later, but get as much of it done now as you can. Once you have completed the solution description, with all of its features and benefits identified, you can move on to develop the highly detailed content—the actual response to the RFP questions or requirements, the substantiation sections, and the cost section.

Here are some additional tips on getting the first draft done quickly and efficiently:

1. Assemble all your materials, including any research you did on the client, notes from sales calls, your requirements checklist, any reusable text that might be appropriate for the proposal, and so on.

2. Review the research you did into the decision maker and evaluators, and then try to write as though you were speaking to those individuals. How would you say this if the two of you were in a conversation? That's pretty much how you ought to write it.

3. Write quickly. Don't stop to edit while you are writing. This is one of the biggest mistakes people make. It's so easy to "fix" things on a word processor that people start fiddling with their text before they're more than a few lines into it. Soon they've lost their train of thought, perhaps even got themselves blocked.

4. Start writing on the part you find easiest or most interesting. You do not have to write the document in the same order the reader will see it.

5. For each section or major part of your proposal, try to move from general to specific, from introductory paragraphs and main ideas to supporting details.

6. If you cut and paste boilerplate or reusable text, revise it to match the win themes you are using in this proposal. Above all, make sure it doesn't contain the wrong client's name!

7. Use personal pronouns—"we," "you"—not third person or oblique references. Call the customer by name—that is, use the company's name throughout the proposal. Never refer to the customer as "they."

8. Challenge the acronyms and jargon. If in doubt, leave it out and use something simpler. (Using the customer's jargon and acronyms is permissible.)