Quality assurance procedures for technical writing?

Subject: Quality assurance procedures for technical writing?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 24 Jan 2001 08:35:39 -0500

Sylvia Braunstein reports: <<The QA manager told me that we would have to
establish procedures on how to perform QA for our technical writing
department. Does anybody have... recommendations?>>

Only your QA (quality assurance) manager can tell you your employer's
requirements; there's little point implementing something that we
techwhirlers suggest if your QA people have an entirely different idea of
what's required. So find out your company's requirements directly from that
manager and build your QA processes around those requirements. In fact,
enlist the aid of that manager; they'll find it much harder to reject what
you develop or criticize the results if they contributed to its development.
That being said, here are a few things you can do in any QA program for
documentation:

Accuracy: What you've written must be accurate, and only a review by the
developers can ensure that this is the case. Asking a colleague to run
through what you've written and check each claim against the actual project
goes a long way towards achieving this, but won't eliminate the need for a
review by the experts.

Completeness: Anything a user can see or use and subsequently ask questions
about should be documented. As is the case for accuracy, you can do some of
the testing for completeness by yourself, but you're also going to have to
enlist the aid of the developers--and particularly so if the product is
evolving and they're not keeping you informed of the changes.

Usability: Only your audience can tell you whether you've produced a truly
usable document. Until you can arrange for feedback from that audience, you
can produce something _more_ usable by having a skilled editor go through
what you've written, and by asking your training and technical support
departments to confirm that you've clearly answered all the most common
questions they receive.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

"Hart's law of gravitation: Deadlines are the documentation equivalent of
black holes: the closer the deadline approaches, the harder it becomes to
escape its pull, and the faster events accelerate in their rush towards the
deadline; at the technical communication equivalent of an "event horizon",
nothing escapes that pull. And the closer you approach a deadline, the
faster things are moving and the less time everyone has to react
appropriately."--Geoff Hart

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17)
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area.
http://www.pdfconference.com or toll-free 877/278-2131.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.


Previous by Author: Source code documentation systems?
Next by Author: Software usability: courses?
Previous by Thread: Re: Software Usability
Next by Thread: Re: Quality assurance procedures for technical writing?


What this post helpful? Share it with friends and colleagues:


Sponsored Ads