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.
Subject:RE: Issues about documentation process/management From:Melissa Nelson <melmis36 -at- hotmail -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 13 Jun 2008 08:55:16 -0400
Wow I can feel your pain! I have been having the same type of issues. Last week I got called to a meeting with a production manager and HR because I goofed up some documentation and I looked at them and just said "I am surprised I do not make more mistakes!" My issues sound eerily familiar to the ones you are describing. I could never convince anyone to do "documentation meetings" (picture developer rolling his eyes) so I have insisted that I am invited to all meetings concerning what will be in the future products, no more changing products without informing me and then getting annoyed at me for not making those changes in the documentation. If your manager will not have documentation meetings, considering asking if you can attend any or all meetings that have to do with the product you will be documenting.
Wishing you luck and hoping you wish me the same. SIGH!
Melissa
> Date: Fri, 13 Jun 2008 14:29:42 +0300> From: sylvia -dot- braunstein -at- gmail -dot- com> To: techwr-l -at- lists -dot- techwr-l -dot- com> 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?> > Thanks,> > Sylvia> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> > 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 melmis36 -at- hotmail -dot- com -dot- > > To unsubscribe send a blank email to > techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com> or visit http://lists.techwr-l.com/mailman/options/techwr-l/melmis36%40hotmail.com> > > To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com> > Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit> http://www.techwr-l.com/ for more resources and info.>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-
