RE: Necessity of Doc Plans for a Single Chapter or Section

[Michele Marques <MarquesM -at- autros -dot- com>]

Mike Starr writes:

> I'm with Andrew. In 16 years as a technical writer, the 
> closest I've come to creating a doc plan is making a list of the projects
that 
> needed to be worked on and assigning them some sort of priority order. My 
> feeling is that the amount of time and effort required to produce a 
> credible doc plan would consume probably 80% of the amount of time and
effort 
> it would take to just do the work. [...]

The amount of work in creating a doc plan depends on what is included in the
plan. The necessity for the plan depends on whether certain groups or
individuals will require parts of the documentation before all of the
documentation for the project is complete.

A doc plan does not necessarily have to be long and formal. A doc plan may
include:
* list of deliverables
* time-table for deliverables
* requirements (e.g., access to design docs, access to application)
* specifications about the deliverables

Depending on your project, you might not include all of those elements in
your doc plan. Sharing the doc plan (or parts thereof) with relevant parties
can help with early buy-in to the project and uncover additional issues
(e.g., certain groups need a particular deliverable early. Once the doc plan
is agreed on, it provides an overview/road-map of what you need to
accomplish & when. 

Of course, a doc plan, does not require the formal title "doc plan" - it
might just be some e-mails to your boss and other relevant parties about the
documentation issues for the latest project.  A plan could be as simple as:
in the first two weeks you will receive all design docs and create documents
for customers about the upcoming new version; when the developers have
something ready for QA you will have a draft of docs also ready for QA; and
on the release date the final docs will be completed.  

Also, if you have a plan that works, you may be able to re-use it with few
modifications for similar projects. For example, if you work for a company,
you might find that the same doc plan / workflow works for all upgrades to
the product.  

If you have a plan that works, then of course that plan can be adapted for
smaller updates, but you don't want to spend more time on the plan than you
would on the docs!

------------------------------------------------------------------------
Michele Marques, Technical Communicator
AUTROS Healthcare Solutions, Inc.
marquesm -at- autros -dot- com <mailto:marquesm -at- autros -dot- com> 
 
This material is intended for the use of the individual
to whom it is addressed and may contain information that
is privileged, proprietary, confidential and exempt from
disclosure. If you are not the intended recipient or the
person responsible for delivering the material to the
intended recipient, you are notified that dissemination,
distribution or copying of this communication is strictly
prohibited. 
If you have received this communication in error,
please contact the sender immediately via e-mail and destroy this message
accordingly.


  

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you 
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of 
your book. What are you waiting for? http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.