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.
STC has sponsored this research on this topic. Ginny Redish and Judith
Ramey conducted it, and they published their results in a May 1994
report to STC called "Measuring the value added by technical
communicators". It has chapter titles like
Measuring how professional technical communicators add value
A good user's guide means fewer support calls and lower support costs
How the process and organization can help or hinder adding value
I searched STC's web site for information on ordering this report, and I
didn't find it...which of course doesn't mean they don't have it...but
if they don't you might try contacting Ms. Redish or Ms. Ramey directly.
Hope this helps.
-Connie Winch
Technical Writer
Macola, Inc.
cew -at- macola -dot- com
> -----Original Message-----
> From: Carol Van Natta [SMTP:CVANNATT -at- ITC -dot- NRCS -dot- USDA -dot- GOV]
> Sent: Wednesday, March 04, 1998 8:42 AM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Documentation seminar -Reply
>
> Warren, I think you're putting the cart before the horse, as it
> were. Your proposed seminar is about process, when it
> sounds like you really ought to be first talking about value.
>
> I'd also like to suggest that you get management involved,
> because if they don't see the value (i.e., cost benefit) in
> good-quality documentation, all the seminars in the world
> won't change your situation. Right now, the company has it
> easy -- they dump it on you and forget about it. You'll have to
> come up with some fairly powerful reasons why they should
> take on the extra work of planning, reviewing, etc.
>
> You need to educate everyone on the benefits of
> documentation (other than "users expect it" and "the
> competition does it"). Do research on whether it reduces
> service or support calls, or influences big-customer buying
> decisions, or whatever. Once you've made your point and
> gotten buy-in on the fact that good, planned documentation
> is more profitable than rushed, error-prone documentation,
> _then_ you can talk process and procedure.
>
