Being devious about Deviations

If quality is doing “exactly what it says on the tin” (courtesy of Ronseal), what happens if you really don’t want to? What happens if you knowingly choose to do something else? Presumably that isn’t allowed?

Well, yes it is. Quality management shouldn’t be a straightjacket.

Of course, if you’re dealing with safety-critical applications or other high security, high safety, high risk or cost areas there are many restrictions and must-do activities – some aspects of quality aren’t up for negotiation – but sometimes it is highly appropriate to deliberately not follow the normal processes or standards. However, you should do this in a controlled way rather than just allowing anarchy.

The way to do this is called a ‘Deviation’ or a ‘Concession’.

The two are slightly different in that a deviation is before the event – you choose to do something not in the normal way or to the normal specification – whereas a concession is an acceptance of something that is already not to the normal specification. One way of thinking of it is ‘the supplier deviates and the customer grants a concession’. But this subtlety is often lost and, for many people, not worth worrying about; the key principle is that if you choose not to follow your normal path, do so in a managed, measured way.

So a common technique is to have a deviation (or concession) form, or electronic template, or database or other system that records what you are doing in a different way to normal, why, authorised by whom, and – most importantly – for how long… because a key characteristic is that deviations (I’ll stop adding “and concessions”, take that as read) are temporary. They are made to expire after a certain time period, or after a certain number of units are made or cycles of activity are complete, or after a predictable set of circumstances are met. Deviations are controlled, measured and time-limited changes. If you want to make permanent alterations you use change control; I’ll talk about that another time.

Typically, a deviation note contains:

• A reference number and date
• Who has raised / requested the deviation and who is responsible for implementing it
• The parts or processes or other things that are affected, and the quantities involved
• The normal standards or specifications or processes, etc, that would be used
• The reason for wanting to deviate from the norm
• What needs to change
• Actions to be taken
• When the deviation becomes effective (in terms of date, item serial number, relationship to other parts or material batches, customer demands, etc)
• When the deviation expires (in terms of date, item serial number, relationship to other parts or material batches, customer demands, etc)
• Any cost, time or risk impacts, or other consequences of the change
• Somewhere to record whether it has been turned into a permanent change
• Its status – Being considered? Rejected? Pending? Implemented? Expired? etc. (You may even want to record the change history of this deviation itself)
• An appropriate level of sign-off, to make it clear that the deviation has the understanding and agreement of staff at appropriate levels of responsibility… including quality management and possibly including the customer.

If you are designing your own system, the ability to add attachments is hugely valuable. You would also be wise to add the ability to automatically flag up the expiry of deviations, i.e. have the system send a message or email to the user when its expiry date is approaching.

Of course, you may already have a change control or Product Lifecycle Management system that has deviations and/or concessions built in but, if not, you don’t need to go out and buy an expensive integrated system, you really can do it yourself using Excel or Word or Access or any other simple document or database technique.

Finally, if you are introducing this facility into your processes, make sure it isn’t abused or over-used. Deviations should be the exceptions not the norm. Check they really are temporary and they really are time-expiring automatically and things then revert to normal. Check that expiry times are not excessive. Check that they are being signed off at the appropriate level and are being properly stored so that, if problems subsequently arise, you can back-track and understand what was done when and why.