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.
I don't mean to ask silly questions, but this is my first documentation
project. (Sort of).
The system I am trying to document is still very much under development.
<SNIP>
Can someone(s) give me some advice/techniques for how to handle this?
Detailed advice is much appreciated.
Sorry if this is a ridiculous question, but I am frustrated!
KEG
keg0 -at- atsoaa1 -dot- em -dot- cdc -dot- gov
==================END ORIGINAL MESSAGE================================
Karen:
Your question is neither silly, nor ridiculous. It is very frustrating! I'm
currently concluding the primary stage of documenting a product under
similar circumstances, so I have some observations and recommedations that
could help.
Insist, as much as possible,on participating in meetings where design,
functionality, etc. are decided. Ask questions! At least, demand to review
notes taken during that meeting. Make sure you get your hands on any
existing papers (spec sheet, marketing blurb, existing documentation, if
any, etc.) dealing with the system you are writing about. If available,
obtain a demo of the product (keeping in mind the final product may be
substantially different from the demo . . .). Try to regularly be in contact
with the head of the development team to obtain accurate and current
information and input. If this is not possible, try to locate someone who
can be a liason between you and the development team. In general, make sure
you are "in the loop" as much as possible, trying your best not wasting time
documenting modules, features, etc. that are known to be tentative.
Concentrate (if possible) on parts that are definitely "in" or "finalized."
(You might discover there are none!) Ultimately, as a last resort to pass
(maybe 'kill'!) time, concentrate (if applicable) on other aspects of the
documentation, e.g., graphics (if there are any in existance . . .), page
layout, or the manual's outline.
But possibly the most important thing is be sure whoever is in charge of
your project realizes what is transpiring: that you are waiting for
information! The onus should clearly be on the developers/programmers, etc.
and not you. (Be careful about this. It requires some tact . . .) Your
superiors may have other tasks you can do in the meantime. If they don't
suggest it, ask. It it surely as important to 'be' busy as it is to 'appear'
busy.
Hope this helps.
Harvey Kaniel
Technical Writer
LiveLink Systems, Ltd.
Jerusalem, Israel
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
