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.
Dividing really big projects is a workable plan, but each
project needs to have one lead writer managing content,
assignment of work and schedule. The lead does not
necessarily have to be the most senior writer available.
Decisions about what is "best" for the user and the
"importance of documentation" need to be made by
someone who is familiar with both the product and the
user. This will usually be someone in Marketing, or
whoever is designated as the "product owner" (the
person who's rear end is most on the line if the
product bombs on the market); it will almost never
be the engineers or programmers. Another decision,
possibly the most important one, is what is most
important *in* the document. If you don't have the
time or resources to document everything that every
person wants documented, you need to prioritize the
topics and start deleting things from the bottom of
the list until you reduce it to something you can do
without compromise the "quality" of the items at the
top of the list.
Issue regular status reports on the progress of the
documentation and what corrective action is needed
to address issues. These reports should be directed
to the "product owner," whether that person is your
boss or someone else.
Your deadlines should be the result of hashing out
what the "product owner" believes is most critical
and what you and your team believe is achievable.
After achieving that balance, the document deadline
should be as critical as the product deadline.
Gene Kim-Eng
----- Original Message -----
From: "SB" <sylvia -dot- braunstein -at- gmail -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Sent: Friday, June 13, 2008 4:29 AM
Subject: Issues about documentation process/management
>I am not sure that I will or want to remain in this position but while I am
> still in it, I would like to figure out the following:
>
> 1. My boss wants the writers to be responsible per projects. However, the
> size of some documents is just way too big to handle, especially if they
> have to be delivered in a short period of time. So, I suggested that for the
> larger projects (800 pages), we should divide the project among the writers
> in a reasonable manner so that the projects can be done on time. I believe
> that having one writer work on one large document by him/herself is a recipe
> for failure mainly because of the size, unless the writer is given a very
> long time to do it, which is never the case. So, what should I recommend?
>
> 2. What is best for the user? One large pdf file or several files.
> My concern is that when giving several files, it may look like it is not a
> single product. However, maybe one file may be hard for the user to manage?
> Any input on this?
> 3. There are some serious problems with the current quality of the
> documentation as a result of lack of time and personnel - We need to decide
> about the importance of documentation. Our company is growing and I wanted
> to know how long it should take per writer to write let's say a 200 page
> document from scratch or do a major rewrite with an existing backbone,
> assuming that some sections can be relatively complex. What is considered a
> reasonable estimate of time per writer, per page? In our company, we are
> given a date and expected to deliver by then because the documentation is
> part of the product delivery. If we have lots to do and not enough
> personnel, is is reasonable to ask the writers to sacrifice on quality and
> focus on contents first? If not what should be done?
> 4. Should I expect my boss to set the documentation priorities and to
> have a weekly meeting on the status of the documentation? Not sure why but
> he cancelled the weekly meetings and he does not have much time nor interest
> in dealing with the documentation issues.
> 5. Is it unreasonable for me and too demanding to request that a writer
> meets a deadline even it it means sacrificing quality considering the
> situation?. Or should I insist that my company delivers quality and let my
> them deal with the consequences when projects that are not done as a result
> of lack of time and personel?
>
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
