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: the tech writing 'process' From:Hilary Phillips <hilary -at- CYGNUSPR -dot- DEMON -dot- CO -dot- UK> Date:Tue, 11 Nov 1997 09:57:34 -0000
Hi,
I'd recommend a very good book on the subject: Writing Better Computer Documentation by R John Brockmann. It is published by Wiley in New York but I managed to get it here in Scotland, so you shouldn't have so much difficulty. It'll take you through all the stages of documentation development.
The problem that remains however, is persuading an organisation to commit to the time and resources required to take this approach. As a freelance, I struggle with this issue all the time and will be interested to hear other views on how to deal with this.
I hope it works out.
Hilary
----------
From: Laurah Limbrick[SMTP:laurah -dot- limbrick -at- MCI -dot- COM]
Sent: 10 November 1997 20:27
Subject: the tech writing 'process'
Hi techwhirlers:
I've just joined a group at work that is trying to define process.
The two tech writers have been placed in the program manager group,
which in turn is part of the support organization (along with
the business analysts). The rest of the department consists of
the development organizations we support. Our manager is also
new to the group, and has asked the two of us to develop a tech
writing process.
We've come up with a high-level draft, but were wondering how
others approach it. The main idea behind our initial draft is
that we be involved in a project from its inception, instead of
the last minute requests we frequently receive. We want to be
more than document formatters; we want to be considered an integral
part of the software development process.
For example, what we want to get away from is the idea that someone
would fill out a form for TW assistance and we would provide an LOE.
We feel that this puts us in the role of typists, not writers.
If we are involved from the beginning in determining the type
and number of documents, and are actually developing the docs,
this would never be necessary.
We are responsible for all the development documentation, the
operations guides, on-line help (when necessary) and web page
maintenance.
We would appreciate any ideas or insight you all have on this.
Any process you follow, formal or informal, would be helpful to
us.
