Wes Bucey said:
I like this. Any other comments from Cove members?
Since you asked...
I'm reminded of a quote from Blaise Pascal, in a long letter to a friend: "I would have written a shorter letter, but I didn't have time." (also sometimes attributed to Mark Twain)
And another from Truman Capote, upon being told that Jack Kerouac had completed
On the Road in a matter of a few weeks: "That's not writing, that's
typing."
If brevity is indeed the soul of wit, it can't be brevity for the sole sake of brevity. To make a piece of writing
concise takes effort and deliberation. I agree that quality manuals should be as short as possible, but there's a difference between editing and truncation.
IMO, the "manual" in question doesn't meet what I consider to be the two foundational purposes of a quality manual. A quality manual should,
- establish the requirement for the existence of a quality system that meets the requirements of [your standard here], and
- explicitly grant responsibility and authority to the individuals (or positions) who must design, build and maintain the system and,
- describe the expectations of management with regard to output.
Without at least those three things, the manual serves no useful purpose.
With regard to the process interaction diagram, don't we already know that there
is interaction between processes? The diagram shows this in a rather vague and noncommittal way, but doesn't say anything about
how and
why and
when processes interact or the significance of the interactions. Couldn't the diagram in the posted document be used in almost
any quality manual?
Most quality systems that fail do so because top management hasn't delegated authority to the people who have to make the system work, and hasn't adequately explained what's expected. The quality manual should be the foundational document of the system, and it should be top management's way of
firmly committing itself to the existence and maintenance of the system.