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.
punit shrivastava asked:
> Hi All,
> I have got the opportunity to work towards achieving
> Documentation Quality
> and Standardization in my documentation team.
> Would someone guide me on the following:
>
> - What all we cover in deciding Quality of documentation?
> - How do we go ahead with it?
>
> Please note that our organisation already has all other
> measures (Style
> guides, QA Team and documentation guidelines) in place. The
> effort is to
> improve the output quality within the team.
One measure of the quality of a completed document is how many errors or
omissions are discovered by people who must use the document.
If you can arrange that someone in Engineering Test / Validation, or in
QA be tasked to perform their tests using your document, rather than
their own detailed test-cases, they will soon highlight some things that
need fixing.
You and they get to discuss and to decide whether (say) 10 occurrences
of a particular spelling error, throughout the document constitutes one
defect or ten defects.
Obviously, spelling errors are the least of your worries, but it was an
easy example.
The tester would also report all occurrences where the document or help
was incomplete, or failed to adequately instruct them as to what to do
next. They could also be asked to make occasional checks while going
through procedures to see if they can readily find out _why_ they are
performing a given procedure (if explaining the why is considered
important for your docs).
As well, you can solicit reports from Sales and Sales-Engineering
personnel as to how well the documents work as a sales tool - do they
make it look easy and reasonable to configure, manage, and use your
product?
Similarly, you can scan the current and historical record of Customer
support calls/tickets, to determine what documentation deficits are
reported (either by direct customer complaint or by the Customer Support
rep noting that the call would not have occurred if the docs had
included such-and-such a piece of information, or if that existing piece
of information had been easier to find. The customer support database
will also show trends of improvement or... ahem... disimprovement in the
completeness and efficacy of your docs.
As others have mentioned, if this is a sincere effort to seek real
improvement, nobody will be dismayed that the above measures are
long-term, showing results after months and years. If the goal is just
to show some boss or some auditor that your group has "quality
processes" just like the other groups, then that's a different thing and
must be approached differently.
I've always thought that the goal of good customer documentation is to
minimize service calls and to be an asset to the sales force. The
former is measurable by the Customer Support organization. The latter is
more subjective, but can be reported as opinion by the sales
organization.
If you must provide internal (to your group) measures of quality, then
you must have some kind of consistent, methodical review of the docs
against the stated goals for those docs, and your measure is the report
of how many errors or requests to rework are generated. Success is
simply having fewer such reworks the next time. Soon you run into Zeno's
paradox. :-)
- Kevin
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
