Online Technical Writing:

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 section 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.

Format for Documentation Proposals

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.

Components of Documentation Proposals

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 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
products, 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 develop. 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. Don't forget to include graphics
tools. 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 as well, 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.
Interested in courses related to this page Return to the main menu of this online
or a printed version? See the resources textbook for technical writing.
page.

Information and programs provided by hcexres@io.com.