TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Amy asked about proposing a documentation plan, which sounds like a good deal
to me. I wish we had a plan.
Specifically, she asked:
>I'd like to hear from those of you who work for academia producing
>documentation and those who have used documentation in academia. And
>anyone else who has an opinion. What areas need documenting the most?
>What documents get the most use? Do you have any info on how
>documentation decreased service and help calls? Any suggestions or
>comments on what should go into the proposal?
>Amy W.
>awelden -at- sosc1 -dot- sosc -dot- osshe -dot- edu
I would suggest preparing quick reference cards and short, self-contained
introductory modules for each of the popular systems and networks. Afterwards
you can worry about being comprehensive.
As far as what needs documenting the most, ask your local help desk or support
staff what generates the most questions and what the questions are. That is
where you need to start writing. I have strong feelings that the new
documentation I have been generating for the last year has significantly reduced
the help desk questions, at least the trivial ones. Now we get more difficult
ones, which is progress, I guess.
Right now the Internet module and anything about E-mail and Network News is hot
because people are just now getting on the network and finding out about the
possibilities. Our demands for system documentation depend on what classes use
which systems, which is something else you should investigate. No point in doing
documentation for a system which won't be used next year.
For the proposal, I would be as specific as possible. At least here our budget
is very tight, and only two things get funded--pressing needs and
administrator's pet projects. If you can get documentation into the second
category you will be very well off, but a good proposal can at least put
documentation into the first category. Use numbers--people-hours, pages of
documentation, and "estimate" the reduction in help desk questions.
