Re: What is quality?

Subject: Re: What is quality?
From: Paul Sholar <pks -at- GENSYM -dot- COM>
Date: Thu, 30 Dec 1993 12:25:22 EST

I think that the most promising approach to the quality of products in
general, including software product documentation, is "quality is
conformance to specification." That is, the closer that a product's
implementation conforms to the product's "design," then the higher the
"quality" of that product. In turn, the more closely that a product's
design conforms to how the customer actually uses the product, the
higher the "quality" of the product's design.

In other words, the "quality" of a thing is a/the by-product of using
a certain approach to making that thing. The person (Deming?) who
authored the above definition of "quality" is obviously more concerned
with describing the process of producing quality products than with
describing product characteristics.

In my world, that of producing software product documentation, certain
tasks are required in order to "specify" a document. Several of us
in this mail list have described doc plans, customer surveys, reader
testing, etc. The Society for Technical Communication (STC) and other
organizations probably have an adequate handle on raising these issues
and educating technical communicators about these tasks.

Therefore, I think that the greatest constraint on the quality of documents
is how documentation projects are conceived and managed. I think that the
major organizations (such as STC) that support technical communicators have
not yet sufficiently raised the consciousness of (on the one hand) product-
development management and marketing management and (on the other hand)
readers of product documents to see:

* Customers want useful documents about the products they buy.

* Customers expect product-development companies to do a good job of
figuring out how to make these documents "useful." That is, if the
company presumes to know enough about what the customer wants to have
built a product, why doesn't the company also know enough about how
the customer will actually use the product to write documents that
appropriately describe the product?

* There are generally accepted ways of gathering the information that
supports a definition of a document about a product. Customers should
be better aware that these techniques exist and should expect product-
development companies to be performing those information-gathering (both
internal to the company and external) tasks before producing documents.

* The published document should state its own purpose (including the scope
of the document's information) and should state the practical benefits
to the reader of reading the document.

* The document should present the criteria under which its "quality" can be
assessed by the reader. (For instance, the document could state that
by using this document, the reader will become proficient at x, y, and z
tasks and will do so in a particular timeframe.) This sort of statement
invites a response from the reader, which should be incorporated in the
process of evaluating the document's "performance."

* A document's performance can only be assessed in the field, then that
assessment must be "fed back" to the authoring organization. This is
probably the least developed practice in the technical communications
field.

I have only read (STC journals) of organizations that practice this kind of
"total" approach to developing documents. I would guess that only large
organizations have the incentive and specialized resources to attempt to
follow this approach to developing documents. Most technical communicators
don't work in large organizations. (Is this a good assumption? What figures
do the STC and others have on this?)

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


Previous by Author: FW: Automated Mail Server Set up for FUNNE
Next by Author: [no subject]
Previous by Thread: Re: What is quality?
Next by Thread: Re: What is quality?


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


Sponsored Ads