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.
I agree with Jack Shaw, I agree with him very very much.
ISO 9000 isn't the magic cure that many have thought it is.
While it's helpful in establishing a plan for quality, it really
does nothing to guarantee that the quality is built into
Many people who support ISO 9000 overlook one important
fact: the ISO 9000 requirements are based on a series of existing
documents, mainly used in military contracting. Essentially,
those of us who have worked in the US defense industry are
looking at ISO requirements, saying "Heh, weve been through
tougher." Then we laugh up our sleeves, knowing full well
what private industry is about to go through. It wont be fun.
ISO 9000 cant guarantee quality. If it did, those DOD
equivalents would guarantee quality in military products.
Remember the M-16s that jammed in combat in Vietnam?
Remember the wing cracks in the C-5A transport aircraft?
(Fixing that was a five billion dollar program) How about
the electronics problems in the B-1B? Or lots and lots of
NASA has a quality program thats much tougher than
ISO 9000. Remember the O-ring and the Challenger?
ISO provides a theoretical structure, but it still comes down
to individuals doing their jobs. If the people in those jobs
slack off, fail to do the inspections, and just sign the
paperwork, then the QA plan is just a waste of trees.
(Or magnetic coating on disks...)
What ISO -will- accomplish, however, is an enormous increase
in costs. In order to properly perform ISO type QA inspections
on tech manuals, you can expect to increase the size of staff by
10-15%. That figure, BTW, will also go across the board.
Youll need QA people to check the software, QA people to
check the hardware, QA people to sign off on the released
Now, these QA people dont work for free, of course.
As noted by many, the ISO requirements are for documentation
of procedures. Who maintains these procedures? If it's tech
writers, youre gonna need a lot more of them. In many
companies, however, its a new group (Industrial Engineering
in some places) that does nothing except write, file, and update
these procedures. Any time you come up with a new and better
way to make a product, all the applicable process documents
must be changed. If they aren't the ISO auditors are going to
have a cow at their next visit.
Industrial engineers dont work for free, either.
Filling out the paperwork, making sure the job is done correctly,
all of this takes time. You can double the amount of time for a task
if the paperwork is thick enough, at least thats my experience. (A
few weeks ago, I sent a pile of the GE manuscript checklists to
LaVonna. I think she went into shock when she saw them.)
And so it goes. Now tack in all of these increased costs, the salaries
of the people who dont work for free. Where does that cost go?
Into the final product. In other words, as I have said before,"ISO 9000
will solve the problem of the military buying $50 hammers, but only
because all hammers will cost $50." Or, in an example more relevant
to our purposes, the price per page of a tech manual will go up sharply.
The price of a jet engine tech manual for the US Navy is about $400
(repeat, Four Hundred Dollars) per page. Can anybody in private
industry top that figure? A huge chunk of that money was consumed
by the QA process. I can assure you it didnt go into the tech writers
Susan R. Kloster talked about her experiences over the past 18 months.
She said that the process of documentation will force you to look at how things
are done, and quality will improve. The final QA plans, however,
can be terribly stifling and restrictive. Style guides will become more
detailed, eventually rivaling MILSPECS. (Try reading MIL-M-38784,
just for a scare.) Why will this happen? Because historically, any set
of regulations becomes more, not less, restrictive with time. A year
down the road, you think of new things that should be added. Inspections
and requirements must be thrown in to make sure that "one time slip"
never happens again. Then the next year there is more, and the year after that
even more. The result is a thicker and thicker series of requirements.
As for paper vs. on-line procedures, in some ways it really doesnt matter.
You'll still need a lot of filing cabinets. Every manuscript, review
copy, comment sheet, and sign-off log you do will have to be preserved.
How else are you gonna prove that youve done all the things according to
plan? How do you prove to auditors what you've done without a
paper trail? These tasks that were formerly done with a smile and a handshake
now will be done with forms, checklists, and sign-off sheets.
BTW, although on-line procedures can be updated more quickly, in the end I
believe it wont make that big of a difference. The process of -changing- the
procedures ends up taking much more time than the process of printing and
distributing the new procedures, to a point where the extra time required
by printing wont make much difference in the end.
The upshot is that ISO 9000 -will- improve quality, but it will do so at a huge
cost. There was a lot of truth in the Dilbert comic strip a while back, where
one of the characters comments on a new quality program: "Manufacturing
defects are down 50%. Unfortunately, manufacturing productivity is also
ISO 9000 is still new enough and mysterious enough that it looks like a good
thing. Once we get involved in it, though, were going to find were shackled
by it and stuck with it for a long, long time
Thats my soapbox. My asbestos underwear is on. Comments, anyone?
rjlippincott -at- delphi -dot- com