Re: TECHWR-L Digest - 17 Jul 1994 to 18 Jul 1994

["Christopher M. Fisher" <Christopher_M_Fisher -at- ANDERSEN -dot- COM>]

> In fact, having departmental standards for document titles,
> art, formats, and standard, *legally binding* language save
> me from useless work and let me concentrate on what I
> ought to be doing in the first place.

[NOTE: I'm coming into this discussion a little late.  Apologies all around if
I'm rehashing old points here...]

Your point is well-taken; the hallmark of a mature process is that it must be
repeatable.  And it's true that having a good set of proven standards often
saves a lot of precious project time.  On the other hand, I don't know if I can
agree 100% with your statement that "Standards equal consistency."

By following any set of standards, you are basically allowing yourself to
concentrate less on certain parts of your process; this is all very well and
good, and is certainly essential when you have limited time to complete a job,
but taking attention away from _any_ part of what you are doing has the
potential to introduce new (unforeseen) errors.  To borrow a software
developer's metaphor, when you spend less time in the analysis and design
phases, you often need to spend more time catching bugs in the testing phase.

Your thoughts on continuous improvement were very much on target.  The trick is
(1) to structure your standards so that the users perceive them as flexible and
NOT the "final word" on the process, (2) to continue to encourage process
innovation and experimentation (and documentation of any successes!), and (3)
to establish a feedback loop with the users to ensure that the standards remain
usable, current, and effective.  I also tend to distrust standards on
principle; a process must be repeatable, but any process that is not regularly
injected with new life will inevitably wither and die.

           --Christopher M. Fisher, Andersen Consulting