Oh my – this topic could go on and on and on, but I am going to restrict myself to five.
Management write the processes and procedures. I guess they “have the time” to do it, and they know what they want the final document to look like, but do they really understand the process they are trying to document. They are often written in management speak rather than real life and then end up sounding like legal documents rather than aids to help the staff do the work. The read like a lack of care and something that was forced on the writer and just another thing ticked off a list of things to do.
A slightly better option is to have other people in the business write them, but often it’s a stranger to the process so just as bad as management writing them. They are done in a way that is like school work being handed in and the seeking of approval for long words and phrases being used, again nothing like the real life use of language and understanding. It still has the issue of the process documentation being incorrect and inconsistent and not being accepted by the people involved in the process.
One of the major problems with writing up processes and procedures is that they concentrate on how to do something and not necessarily why something needs to be done. People therefore do not question what they are doing and just get on with it. It is possible that a process was set up to solve a problem but things have moved on and that work is not needed any more, but because people are not questioning why, they are still being carried out.
Negative words are often used when document procedures and tell people what not to do rather than what to do. You know the story – if somebody says don’t think about the pink elephant, and then you find you are thinking about the pink elephant. A negative loaded procedure just puts the reader off and may not even start the task. A huge flow interrupter.
A boring format and text heavy is enough to put off people reading any kind of process or procedure guide. Procedures do need to have a template to capture the basics required such as procedure name, purpose, date, version, terms & definitions etc. But, most people learn visually so where is the harm in adding screen shots, pictures and flowcharts.
Having identified the common mistakes, you can easily see how to rectify them. Have the people that carry out the processes involved in getting them drafted as they have the knowledge of what happens. OK – you will want to review them, tweak them and make improvements. Always use positive language about what should be done and not “don’t do that” and try and include pictures of some kind. Above all, before committing them as final prior to maintenance routines, go out and do the process or procedure in accordance with what is written. You can see then what is relevant and if they actually make sense. With this, you can then play “what if” games and try and break the system or at least come out with documented scenarios to follow if that “if” happens. Above all, question why something is being done.