Documentation Proposals

A documentation proposal is a proposal with most of the characteristics of a proposal, but with some additional characteristics that enable it to achieve its primary objective—getting a contract or getting approval to do a documentation project. See the chapter in this online textbook on proposals for discussion and examples of the common elements and design of proposals.

Like proposals in general, documentation proposals can be internal or external. Within organizations, documentation specialists may have to write proposals to establish the need for documentation to accompany a new product. Addressing external organizations, freelance documentation specialists write proposals to win contracts to develop documentation. It's this latter context that the following discussion addresses.

The following describes the individual sections to consider for inclusion in your documentation proposal. For your specific project, some may not be necessary; some may be better combined with other sections.

• Introduction. Keep the introduction short—announce that this is a proposal to develop documentation for such-and-such company's such-and-such product. Refer to a prior meeting or contact, or indicate your source of information about the project. Maybe state one of your main strengths to do the work. Provide a brief overview of what the rest of documentation proposal contains.
• Project description and scope. If your introduction did not provide full details, explain exactly what type of documentation you are proposing to develop for exactly what product, or parts of the product. Consider adding some scope sections—details to documentation you will not be providing.
• Documentation objectives. Use a bulleted list to state in terms of general categories what you expect users to be able to accomplish with the documentation you are proposing to produce.
• Audience description. Provide detailed discussion as to your assumptions about the readers of the proposed documentation. Define the audience in terms of the profile (characteristics such as experience, knowledge, attitudes, work environments) and needs (how they will use the product—their tasks).
• Task description. Explain which tasks you will document in the proposed documentation. Put these in a bulleted list with explanatory detail if necessary.
• Documentation outline. Develop an outline of the documentation you are proposing to write. This may seem similar to the task list, but you'll add book elements such as preface, table of contents, index, and covers.
• Development and media tools. Explain which tools you'll be using to develop the proposed documentation (for example, Adobe FrameMaker). Don't forget to include graphic tools (for example, GIMP). Explain how the documentation will be "delivered" to the audience: conventional printed books? online helps? web pages?
• Physical details of the proposed documentation. Present your best estimates on the page count for the proposed documentation. The most convincing way to do this is to estimate page count for each section (chapter)—even down to the level of subsection. List this information in a table. Since this detail repeats the outline, consider combining the two sections here. Also describe the proposed documentation in terms of page size, number of graphics, extra color, and so on.
• Development process and schedule. Present a schedule for the proposed work. In it, define several review dates including assumptions about dates that reviewers will be done with their reviews. This schedule can be set up either by real calendar dates or by amounts of time needed for each phase of the work. If relevant, explain how you will develop the documentation—for example, your assumptions about the availability specifications, usability-testing phases for the drafts, and so on. In your process and schedule, build in signoffs and approvals such that you get your client on record as approving the book design, for example. Specify "deliverables": for example, document design prototype, various drafts, reviews, final copy. Is the final deliverable a camera-ready copy? the electronic file set? PostScript files?
• Documentation team members. Provide miniresumes of your credentials as well as those of anyone else working on the project. Indicate skills, software, past projects, references, years of experience, and so on.
• Projected costs. Present a detailed list of how you will charge for the project. For example, estimate the number of hours you expect the writing to take and multiply it by your hourly writing rate. Estimate hours for editing, graphics, production, and supervision work, indicating their hourly costs as well. Add all this up so that the reader can see the total and see how you reached that total. Add some contingency plans here as well: for example, what if the project is delayed or even canceled? what if new requirements are added to the documentation? In this section, consider specifying when and how the client will pay you. Consider defining other expenses such as shipping, long distance phone calls, travel, etc.
• Conclusion. End with some cordiality and encouragement that the potential client contact to work out contract details. Remember that the proposal can act as a contract, but, more likely, your client will supply a contract with legal requirements carefully spelled out.

Like proposals in general, documentation proposals can be lengthy, bound documents or they can be a business letter under ten pages. For a lengthy, bound proposal, use the standard design of reports. Use transmittal letter, covers, title pages, tables of contents, abstracts, headings, lists, tables, graphics—the works!

If you're a freelancer, you'll probably use the business-letter approach to documentation proposals almost exclusively. Within the format of that letter, you use headings, lists, tables, graphics; but everything is on a much smaller scale.