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.
ISO documentation (was RE: a little respect for "unvalidated"--a real world example
Subject:ISO documentation (was RE: a little respect for "unvalidated"--a real world example From:"McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com> To:David Neeley <dbneeley -at- gmail -dot- com>, "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 23 Sep 2009 10:17:58 -0400
David Neeley said:
[snip]
> (I
> will leave whether the ISO process stifles innovation and embeds
> existing inefficiencies for another day).
The last time I went through that exercise, we went to great lengths to document everything that everybody did (at Ericsson, late '90s). The standard was that the auditors could button-hole anybody at all, ask 'em what they did and, most importantly, ask 'em how they knew that's what they were supposed to do. The victims were supposed to be able to point to documents - often written by themselves.
SOME fudging and tweaking of procedures had to take place during the run-up to the audit, so that certain chasms (of procedure as well as documentation) were bridged, but we tried to restrain the urge to make wholesale changes until the ISO effort reached fulfillment.
As you suggest, they weren't validating whether our processes and procedures were good and efficient and productive; they were validating that those procedures hung together, were justified (by documented connection to other procedures, in-bound and out-bound), and didn't leave any orphans.
After the 9001 cert was received, the documentation remained as a description of "what we do" (forests of trees died...), and as a point of departure for "how do we improve that?" People were still into that Kaizen stuff in those days. But the point was that you can't really fix complicated issues until you know what's actually happening today (and why). For that reason, we were admonished to document what we actually did, versus some ideal process or procedure. Or, I always admonished others to do that, since I was one of the "get us ready for ISO 9001" troops - alas, my whip saw over-use and fell into tatters.
- KevinThe 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.
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
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-
