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: What is quality? From:Fred Wersan <wersan -at- ZEUS -dot- MA30 -dot- BULL -dot- COM> Date:Thu, 30 Dec 1993 13:15:33 EST
----- Begin Included Message -----
From: Paul Sholar <pks -at- GENSYM -dot- COM>
Subject: Re: What is quality?
...
This leads me to a closing opinion. Every day I become more convinced that
what technical communicators do is, in the medium to long run, bound to
become a predominantly "out-sourced" activity. I think that there is probably
a good living to be made for persons willing to organize commercial ventures
that provide these kinds of "total" document-production services to
product-development companies.
Your comments are welcome.
Paul Sholar pks -at- gensym -dot- com
Senior Technical Writer
Gensym Corporation
Cambridge, Massachusetts USA
----- End Included Message -----
I sure hope you're right. Our documentation dept. has become part of a separate
business unit. We need to sell our services both internally and externally. If
we don't we're history.
Your other comments also have a lot of substance. Our quality policy says that
quality is conformance to customer requirements. I think the gist of many of
the comments that have come in on this thread is that customer requirements for
documentation may ask for a level of "quality" that is less than we think is
required, or may not specify the requirements well enough to measure quality.
Most of the requirements documents I see do not contain any requirement for
measuring the documentation against any particular standard of use. On the one
hand this provides a lot of freedom. On the other hand, it doesn't build into
the system an impetus to allocate resources for testing of manuals. I've tried
to do some usability testing on a recent project by getting questionnaires
sent out to customers. I even got one back. My first customer input. It's meager
but it's progress.
-----------------------------------
Fred Wersan
Bull HN Informations Systems
MA30/872A
300 Concord Rd.
Billerica, Mass. 01821
508-294-2322
f -dot- wersan -at- bull -dot- com
____________________________________
