Old fashioned management systems had (have?) a very rigid structure of documentation. This spiralled down from the very hierarchical top with an insanely boring policy written by a quality or safety manager and moving down through vast numbers of unintelligible procedures, instructions and forms. Each was developed from an inflexible locked down template with awkward fields such as purpose, scope, definitions, acronyms, responsibilities and so on. Finally there may be a small paragraph that described how to do something. They were usually conceived in the very odd mind of an undiagnosed autistic engineer who failed basic English. And these are documents that are meant to communicate something! In fact, it is much more than that – we need to ensure that our target audience not only fully understands the content but can execute it flawlessly – no way!
Policies are meant to state an organisation’s position, direction or intent with respect to a topic as expressed by the boss (not a quality manager!). They should stem from the organisation’s principal purpose – say what you mean in simple, plain English. If your purpose is to make money, don’t be frightened to say so – ‘a fair return for owners or shareholder’. Try to be unambiguous – don’t use fluffy marketing speak – shiny, glossy, fantastic quality! These words are meaningless. Be specific – what about ‘meeting or exceeding agreed requirements’. Now define or commit – ‘to do this, we will….’. As a final ‘quality’ check, ask yourself who is the audience of this document? Will my workers understand what I just said?
There used to be a requirement for a Quality or Safety Manual – this made good sense in terms of having available a descriptive system roadmap. Although, you’d have to think that if you need a roadmap you’ve blown the simple system design and construct rule. In practice no one ever read these manuals unless a client requested them at tender, and even then they probably weren’t looked at properly anyway! Thankfully the standards no longer require this type of document. It is interesting though to see a number of organisations trying to update their old manuals with the front end requirements of the new Standard. Suddenly new sections appear such as ‘context’, ‘interested parties’ etc. What a complete waste of time. This new information is very dynamic and will require constant update if it is to be of use to an organisation. It has no place in an old quality manual that’s for sure! Consider a slimmed down business plan template – reference out to where this stuff actually lives. Now the leadership team (and others) might actually use it.
ISO defines procedures as a “specified way to carry out an activity or a process”, with a very important added note – “procedures may be documented or not”. Traditionally procedures define responsibility with the usual who, what, when, where and how. Ensure they do not contain fluffy marketing spiel, are direct and to the point. They should simply describe a process or part process. In the Annexure SL world they should clearly describe the expected success outcome and if possible a measure of this success (KPI). They need to include resources, responsibilities, inputs, outputs, acceptance criteria and methodology. Ideally, consider who the supplier and customer is (internal/external) and any inherent risks and opportunities. Also consider defining the process owner and the target audience. Often a number of procedures may collectively constitute a process. By defining the desired success outcome this procedure is now auditable for effectiveness. Finally, consider how you intend to communicate this knowledge packet to your target audience. There will be a large element of competency in this. You will expect your target audience to be able to flawlessly carry out this procedure, therefore just telling workers about it in a toolbox meeting might not cut it. High risk industries use the well proven competency driven adult learning principal of theory, test, practical, observation…it makes sense. Keep them simple, to the point, use visual aids and ensure people understand and can execute them, otherwise you are wasting your time and money. Annexure SL enable some lateral thinking here – why not convert your old fashioned procedure into front-end competency modules? Reduce repetition, duplication and overlap, say it once at a the very beginning of an employee’s tenure. These can be controlled, updated and are always on tap for relearning or referencing. This approach also eloquently meets the wonderful but baffling knowledge clause in the new 9001:2015 Standard.
Work Instructions are an old favourite and will always exist. They are specific task based documents that do not specify responsibility. Think of the simple step 1-2-3 instructions on the side of the pump when you fill up for fuel or how to fill in a data entry page in SAP. Anyone can do it if you follow the precise steps. Do not add fluff or anything that is not a step – no guidance, no support information – this belongs elsewhere…
Finally we should chat about guidance documents. These are generally more casual and informal and contain all that superfluous ‘knowledge’ that you have always wanted to write down somewhere. Seriously a well-constructed guidance document library can support the organisational knowledge requirements, be a useful reference library and is generally not auditable.
If your system has evolved over time with a succession of owners, it is likely that it has become fragmented, duplicated and not very useful. Consider the incredible opportunities offered by the new Standards to ‘re-package’ your precious knowledge into an effective delivery vehicle.