How to Write Procedures without too many Details

[CATERAF]

Hi,

I'm really struggling to understand how to document procedures without going maddeningly into detail.

I've done my system map and a process interaction map which shows the main divisions of the company and how the processes interact between (and within) divisions. However, now I'm faced with delving deeper into the processes. I'm trying to break them down further and I'm really struggling with how to show it in a way that complies with ISO 9001 as well as being easy to interpret.

My understanding is that there is so much to include but how do I do that in a consistent way? i'm sure i'm probably going too deeply into it, but I don't want to miss anything that would hurt out ISO compliance either.

How do I know how much is too much?
How do I present the procedures/processes in a way that is simple (but involves all the information I need - e.g., who is responsible, assists, is consulted, is informed,what happens,when,why,how,equipment,approvals,etc? Is that too much to be defining for each individual little flowchart process (e.g., collect an order, 'developer checks-in code to CVS tracker')? Maybe I'm looking at it too deeply?

My boss likes flowcharts so I tried to do it in flowcharts but there are so many arrows going everywhere it's hurting my head.

Also, I'm faced with many procedures such as 'submit a ticket' for a suggestion of a new feature or when a bug is found, but this can be done at numerous different occasions (i.e., 6+). How do i slot that into the procedure?

I feel like I'm missing a piece of information that'd make the penny drop.
Can anyone offer some advice please?

Here's a link to an example procedure document that looks simple enough. How does it show enough information though?

 

[Pancho]

Re: Too much detail - how to define procedures!

Hi Cateraf! Welcome!

It would be tough to answer you specific questions about where to put the "submit a ticket" step for anyone not thoroughly familiar with your processes, but hopefully the following will shed some light on one possible way to attack the "how much detail" question.

Documentation (and processes) are never perfect, never done. The way to great documentation and quality is letting your processes and their documentation evolve together through continuous improvement. Though docs and processes should evolve together, processes have a head start over documentation. Companies do not need much documentation to produce acceptable quality when only a few folks do all the work. But to grow and improve quality, documentation is essential. Implementing ISO 9001 is a great way for docs to do some overdue catch-up with processes in a running organization.

Going into lots of detail in documentation has advantages and disadvantages: One advantage of detail is that you can achieve consistency in your processes and through it, better quality. The disadvantages include difficulty in writing good documentation, and difficulty, when you have lots of it, in organizing, maintaining, and keeping it accessible at points of use. The disadvantages often result in the unfortunate idea that it is best to have a minimal documentation system. This idea prevents many QMSs from becoming useful tools. Documents are written once to the minimum detail required to pass audit and not get in the way of "real" work. They are deemed to be correct, complete, permanent and authoritative -- and hardly ever looked at again. Soon they are obsolete or irrelevant.

But tools exist to write and organize documentation with more than minimal detail. Custom software, such as you are using, is one. Another is a wiki. Whatever tool you use, a key feature is hot-linking. Linking is usually under-appreciated and under-used. But a network of contextual links in your documents allows you to write once and use many. Your "submit a ticket" example could be a link to a work instruction on how to do so, instead of having to describe it in the purchasing process (or wherever else this task needs to be done). Linking also provides you with an incredibly effective way to organize a growing library of documents -- through a "small-world network" effect. Documents related to each other are always one click away, and all documents in the QMS are two or three clicks away, even when your system grows to thousands of docs.

As for the other disadvantage, difficulty in writing, that wont change. But wikis or good custom software will save versions and authorship, providing a "ratchet" mechanism that over time perfects documentation. Encouraging contributions from users makes the ratchet go faster.

So publish the documentation soon, imperfect. Let your users improve on it. With a good network of documents and rewarding contributions, your documentation will achieve an optimal level of detail, improve continuously with your processes, and become a true engine of excellence for your organization.

Good luck!

 

[CATERAF]

Re: Too much detail - how to define procedures!

Fantastic reply - thank you!

You answered many questions without even trying to do so.
We are actually using a wiki system and had planned to link everything, but how to do that is a little more tricky. For example, I'm using process maps to draw up every step because my manager likes the visual way of viewing things. I'll then add links to each step. But, i still need words to accompany that.

As you say though (and i had forgotten!), i can just add links instead of having to put statements like "refer to procedure X". This definitely makes it less cluttered which is what I was worried my words and detail would do. It's also good to hear that less words doesn't mean better. I mean, less can be more, but in our case, there's so much to detail that i just can't squish it into a small amount easily. We're a small company but each person can perform more than 5 or 6 job roles - we do a lot!

Have you used a wiki system for implementation? I ask this because there are few document control issues we haven't got sorted but I haven't known who to ask re: wikis.

Thanks again for your response - i was starting to go mad.

 

[Pancho]

Re: Too much detail - how to define procedures!

Have you used a wiki system for implementation? I ask this because there are few document control issues we haven't got sorted but I haven't known who to ask re: wikis.

Yes. Here are a couple of wiki discussions and articles that might help:

Using a wiki to implement a QMS.
Using a wiki for document control.

 

[sagai]

Re: Too much detail - how to define procedures!

Based on the information I have here, somehow having a kind of impression that you guys writing procedures based on your own expectation and as long as your boss is happy with the structure and content, it is just good.

I would suggest to consider ISO9001:2008 4.2.1. Note2 and to do a quick discovery in your organization to determine the level of details necessary to have in the procedures. That is the one that determines it.

Nevertheless, you are neither writing it for your own pleasure nor to make your boss happy.
The target audience should be happy and satisfied with the level of detail they find and they have to use these procedures.
It is not for regulators at the first place , it is for your organization.

Cheers!

 

[red66climb]

Re: Too much detail - how to define procedures!

I love the Wiki approach to documentation, but there is another model that might help answer this question...

Think about a GUI for software applications. You don't want to place too many functions on top, but you also don't want people to have to dig too deep to find the functions they need.

Find a way to capture metrics in your organization for how much detail people need. This quantitative approach will help you find the right balance on a case-by-case basis.

If you need a little detail, maybe an appendix or form will do. If you need a lot of detail, maybe a work instruction is more appropriate.

The genius of a Wiki system is that you have the ability to capture metrics real-time with minimal work. You can also request users to give you feedback in a more efficient way.

 

[Jeff Frost]

Re: Too much detail - how to define procedures!

Documenting a system can seem daunting in the beginning but in reality it can be very simple if you keep it in prospective.

• Make sure you read Chapters 1, 2, and 3 of the standards as it has very useful information like make sure your procedures meet customer requirements and the law in addition to the International Standard. And the definitions of words contained in ISO 9000 form part of the requirements of ISO 9001.
• Understand that all clause of the standard are linked in some fashion such as record retention requirements which is one of the six required procedures.
• Don’t just copy from the International Standard into your procedures. No one will understand it if you do.
• Start with the mandatory 6 procedures first and then create any needed additional procedures.
• Write to the level of the user of the document.
• Use flow charts if you can and augment them with written information as needed.
• Forms should contain sufficient information to allow the user to complete them without having to read the associated procedure each time. In other words, don’t put how to complete a form in the procedure.
• Don’t be a perfectionist. Spelling and punctuation error will occur so just live with it. Goal is to get the procedures completed, not to have them become collage thesis papers perfect in every way.

 

[Peter Fraser]

Re: Too much detail - how to define procedures!

Cateraf

As you say though (and i had forgotten!), i can just add links instead of having to put statements like "refer to procedure X".

Bear in mind that the Procurement example you posted is a printed process description, so it needs the words "refer to procedure X" etc to make it useable by a reader - if you publish the same process as html, the hyperlinks are all set up for you so that you can link to another process (or to a supporting document).

 

[Rickser]

One of the tools I used was a "Turtle Diagram". It helped me to organize my thoughts before beginning writing. Always list your "Outputs" first and work backwards if you use this. I have attached the one I use with it's explanation. Hope this helps.

 

[Randy]

How to write a procedure without too many details? Simple, keep out dribble, tripe, fluff and garbage...Just check out the attachment, simple procedure, simple process, satisfied customers