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.
Ron Sering CDS wrote:
>
> There is a dark cloud gathering over my cubicle. I am hearing
> rumblings that I will be responsible, as the Lone Tech Writer, for
> developing and maintain all systems documentation, such as system
> requirements, design specs, etc.
This is a good thing. Basically, it seems to me as though that we have
a company here that is trying to IMPROVE the efficiency, accuracy, and
effectiveness of its design documentation.
>
> This troubles me, as I feel that there are plenty of issues directly
> related to user documentation, such as improving the online help
> effort, researching and developing ways of making documentation
> available over the internet and on CD, to single-source or to not
> single-source, that I need to be working on. In my background, the
> programmers/engineers produce the design documents, which I use as a
> basis for developing the user documentation.
While I would share your concern with the "dropping" of user advocacy in
terms of the User documentation, you've just been promoted to a "really
big user advocate" because you now have input on the design... which
tragically is where most of the mistakes we have to write around as user
documenters come from. If you can take your same "user advocate" frame
of mind to the job of authoring design specs... your users will win in
the end.
This in turn can have a tremendous "spill over" into the effectiveness
of your documentation... especially if what you're documenting all of
the sudden becomes much more "user oriented" thanks to your
participation in the design.
I'd take this as a good step... and a recognition of your contribution
to your company's efforts in the past, as well as their belief in you to
be able to do this. The "level" that this takes you in terms of
professional respect from an engineering standpoint is IMHO very well
worth the extra work....
>
> What have been your experiences with systems documentation?
It was the best thing that happened to my technical writing career...
short of the day that an analyst at employer A came up to me and said "I
don't have time to figure this Windows Help stuff out. Can you do this
for me?"
go get em' ron!
making lemonade out of lemons... I'm:
--
****************************************************
Bill Bledsoe
Senior Technical Writer - CMS
Bill -dot- Bledsoe -at- cms-stl -dot- com or intlidox -at- anet-stl -dot- com
Prediction 4
"The people who are studying Tai Chi Chuan instead
of saving money are planning to beat us up and take
our stuff when we've retired"
Scott Adams - The Dilbert Future
****************************************************
If Bill Said it, Bill said it... Not CMS. Got it?
****************************************************
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html