Procedures Only Grow; They Never Shrink.

[normhowe]

Have your procedures grown like cancer? Are they filled with double checks and verifications because of previous errors. Worst of all, are those errors still happening? Here's good video from Scientific American that explains why and what you can do about it. I'd appreciate hearing your thoughts.

 

[Mike S.]

This is a good reminder for us all.

In one of his books, Tom Peters calls this common growth of procedures, requirements, rules, etc. "grunge" and IIRC suggested having someone in the org responsible for grunge removal/reduction because typically it only grows and never shrinks.

I think it is not always possible to to reduce, remove, simplify, but it should always be considered.

 

[mattador78]

This is a good reminder for us all.

In one of his books, Tom Peters calls this common growth of procedures, requirements, rules, etc. "grunge" and IIRC suggested having someone in the org responsible for grunge removal/reduction because typically it only grows and never shrinks.

I think it is not always possible to to reduce, remove, simplify, but it should always be considered.

Im dealing with a customer at the moment whos end user is part of the Nuclear industry and he is ripping apart my procedures and datacards demanding more from us. His end user is also one of our customers direct and has no such requirements from me when providing work directly, I'm standing fast and telling him to go back to his end user and say that my initial and current procedures for work is all i will offer, still waiting to hear back from him.

 

[Jim Wynne]

This is an interesting subject, and the tendency to add rather than subtract is a real thing, except not so much in the area of QMS documentation. In my experience it's not common for documents to be added unless there's a new need for them. The big problem in this area is not too many documents, but too many words in the existing documents. Too many people who write QMS documentation seem to believe that it's necessary, in order to sound serious and official, to use turgid, legalistic prose and the passive voice rather than the active. This inevitably results in wordiness and lack of clarity. Here is a passage from the George Orwell essay Politics and the English Language, and the essay should be required reading for all quality managers:

I am going to translate a passage of good English into modern English of the worst sort. Here is a well-known verse from Ecclesiastes:

I returned and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.​

Here it is in modern English:

Objective considerations of contemporary phenomena compels the conclusion that success or failure in competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account.​

​

The latter example is what we often see in QMS documentation, and there's nothing to be done about it short of burning it down and starting over.

I've made it a habit, when writing almost anything, to go over the first draft with the goal of removing unnecessary words (and there are always unnecessary words) and trying to follow Orwell's further advice from the same essay:

i. Never use a metaphor, simile or other figure of speech which you are used to seeing in print.

ii. Never use a long word where a short one will do.

iii. If it is possible to cut a word out, always cut it out.

iv. Never use the passive where you can use the active.

v. Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.

vi. Break any of these rules sooner than say anything outright barbarous.

We should remember as well that the map is not the territory. A written procedure isn't the process that it represents. Sometimes when processes change it becomes necessary to change the documentation, or even write new documentation when the process itself is new. What we normally think of as a "procedure" should be a simple explication of the design of the process, and processes shouldn't be allowed to design themselves.

 

[Mike S.]

Well if Mr. Picky Customer wants to pay for custom procedures to suit him, you can always give 'em a quote....

 

[gpainter]

Good people and training.

 

[Tagin]

I've been pondering how to rewrite our documentation. It's not overly verbose, but its sometimes difficult to get people to read pages of text, even if its just one or two pages. We came from a system of just Visio flowcharts with textboxes added on over time to add needed detail. It required a good deal of handwaving to get through audits due to its sparseness. Auditors like our current documentation, but I'm toying with the idea of something in the middle that is more likable to the actual audience - our employees.

I've found PowerPoint very useful for telling a story - even to myself - with it's slide structure, and SmartArt and graphics support. So I wonder if I can use it for our QMS docs to strike a balance between verbosity and inadequacy. I suppose I could rewrite the existing Word docs to somewhat emulate that PowerPoint style, but I'm not sure it will be the same.

 

[John Broomfield]

Our organizations as systems are evolving from work by humans assisted by machines to add value to work by machines adding most of the value. This explains why workers now share less of the added value (unless they own the machines).

A.I. will eventually replace the documented parts of our systems.

Our flowcharted procedures may act as blueprints to help accelerate this change.

 

[Sidney Vianna]

Our organizations as systems are evolving from work by humans assisted by machines to add value to work by machines adding most of the value.

That's exactly right. In the developed world, more and more processes are being automated, what tends to improve performance and consistency, while minimizing mistakes. But I find hugely disheartening that people still review and analyze documentation as a self-standing matter. Documentation is a component of business processes definition. Many times, the PROCESS gets more complex due to internal and/or external reasons. Documentation does nothing but define how processes should be run and when new risks are introduced, the process needs to be re-defined.

Documents don't exist in a vacuum. Failure to understand that is a clear symptom of a failure to understand the "process approach".

 

[indubioush]

Great video. I love shrinking procedures. One of my favorite things to do.