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: Who dreams up these things? From:"Tim Altom" <taltom -at- simplywritten -dot- com> To:"TechDoc List" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 29 Sep 1999 16:29:37 -0500
I'm in agreement with Tony here. Process is merely a set of boundaries to
guide the overall enterprise in a given direction. I'm reminded of my
college English classes where some students hubristically insisted on
writing totally free-form poetry that was, in their view, utterly unfettered
by the stupid mechanical limitations of rhyme or meter. The results were
almost always forgettable. The instructor pointed out in vain that rhyme and
meter were there as secure backdrops that actually released creativity,
rather than stifling it.
Processes, when done properly, accelerate progress. They ensure that the
tech comm'er is informed about changes, and that changes are controlled.
Processes make sure that everyone is kept in their respective loops, and
that there are quality standards to which the entire organization must
submit. Processes include the adoption of style guides, so that decisions
about usage, terminology, layout, structure, and many other things are
pre-decided, not left to DAWG, and so that different writers don't collide
more often than necessary. Processes permit the creation and use of metrics
for success, so you know when the project's goal is actually reached. They
free the writer to do write, rather than chasing wild geese.
Without these process decisions, chaos reigns. In many cases the chaos is
tolerable and controllable, but in others it becomes a barrier to success.
At some point, DAWG becomes counter-productive. When that happens, the
anti-process free souls must adapt or seek another chaotic environment.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar Method(TM)
"Better communication is a service to mankind."
317.562.9298 http://www.simplywritten.com
>I create documentation for complex software products. I see the same old
>thing over-and-over-and-over again: design efforts very poorly coordinated.
>All other Technical Writers that I know see the same thing. (I do
volunteer
>work within my local STC chapter and know a lot of Technical Writers.)
>
>A fellow STC member calls this lack of coordination: DAWG
(Design-As-We-Go).
> No formal processes to ensure that modules are properly partitioned and
>integrated; just 'assume this and assume that' and cram this new module
into
>the existing mess (i.e., the system) any way possible.
>
>The result of DAWG is very predictable: software that is held together with
>'chicken wire and bubble gum'(i.e., because design efforts where not
>properly coordinated, the creations of the individual designers don't work
>well when tied together.)
>
