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.
Subject:ISO 9000 and "art" From:Damien Braniff <Damien_Braniff -at- PAC -dot- CO -dot- UK> Date:Thu, 4 Dec 1997 15:02:24 +0000
ISO 9000 doesn't have to smother creativity. The last place I worked we
were more or less pushed into getting ISO 9000 by customers - other
suppliers have it, why not you? What we did was basically to try and keep
those procedures relating to software development as "vague/loose" as
possible (but tight where required). This basically meant keeping the
paperwork to a minimum while meeting the requirements of the standard.
Where much of the work was initiated in-house the "spec" often consisted of
1/2 pages in several "layers" - What the software will do; comprises
modules x,y and z. Module x does; inputs a,b,c and outputs f,g,h. This
was usually enough to "define" what was needed with it being left to the
programmers to decide the "best" way of doing it. To restrain over
exuberance there were regular peer code reviews and coding standards which
were adhered to. This gave maximum freedom to the programmers without
letting them go wild and provided enough of a specification for somebody to
pick up the work if people left, moved projects etc.
Where the job was initiated by an external customer we usually had little
say in the matter - "traditional" procedures were followed with full design
specification etc usually being required as part of the contract.