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.
Sue Heim's quick and heart-felt answer caused a twinge here.
To amplify a little on what she said:
>1. Writing for vapor ware (or products that do not yet exist).
>2. Writing for products in which the user interface has not yet
> been frozen ...
How about products that are not _defined_, wherein the review of
the documentation (even an outline) can deteriorate into a battle
that is really over what the product is/can be ?!
>3. Lack of formal specifications with which to begin writing.
>4. Informal development process whereby changes are implemented
> at the developer's whim, ...
How about products for which the (user) documentation becomes the
de facto specification -- and in which the sales/marketing people
want to promise the world, while the development folks staunchly
maintain that the less said, the better?
Ultimately, I think these situations can lead to frustration on
the part of everyone involved. As a writer and member of the
development team, I have sometimes felt that I was tacitly assigned
responsibilities such as those described above without the
opportunity/authority/go-ahead necessary to see them through.
Mike Beyries (beyries -at- csisdn -dot- com)
Technical Communications and Development Support
Information Resource Engineering, Inc. (IRE)
Mountain View, CA U.S.A. (415) 903-2589
This is *NOT* IRE's opinion
