Re: What is quality?

[Jonathan Leer <jleer -at- MV -dot- MV -dot- COM>]

Your comments on quality and managing doc quality are interesting.  I wonder if
anyone has had much luck in tracking document performance.  I have been
writing as a contractor for a small firm and every document we develop includes
a Reader Comment card.  But nobody follows it up or has a plan for tracking
readers comments and needs.

I have found this so common in the marketplace.  The company developing the
product has writers write and produce supporting documentation post-haste
without any real consideration as to making the documentation a real money
maker (documents are still the necessary evil to sell the product but ask
marketing how much they project to make on selling the documentation and
they haven't the foggiest... engineering only knows the cost) or following
up the release of the document to make it a best seller amongst readers.

I believe that a product should be so good (or included fantastic embedded
help) that no documentation is shipped, or a sound plan is in place to
make the documentation a product in its own right, working with customers to
increase revenues and ship updates.

I hate being an add-on to make the sale.  No wonder technical writing gets
second rate treatment.  Many writers don't have a budget or revenue projection
to illustrate to management our bottom line worth to the firm.

Here's a quick story I heard last year to sum it up.  A high-tech company
had developed a nifty product.  Marketing and engineering believed that it
was so good and intuitive that minimal effort and expense for documentation
was considered.  The product hit the streets.  Within a short time it was
evident that good supporting documentation was required and lacking.  An
innovative technical writer (self-employed) quickly wrote an award winning
manual and sold it through one of the commercial high-tech book publishing
houses.  Much interest in the book was generated.  Before long, the high-tech
company realized its blunder and arranged a deal with the publishing house
to sell the best seller with its product, paying a much larger unit price than
if it had invested the time and $$ upfront itself.

Bottom line is that it would be nice to believe that a product can be
developed without requiring supporting documentation.  But as we all know,
this is practically impossible given the product development environment.
Consequently, to really improve documentation quality, revenue potential should
be included in the strategy as well as good old marketing following up to
give customers what they want.

Thanks for listening,
jon Leer