Why do we have quality departments? Even posing the question feels like a minor rebellion on my part, since "Quality" is such an integral concept in the business of producing things. For "integral" we can also read "taken for granted." Sometimes it can be good to tug at the tent poles of the status quo and see whether it collapses in a heap around us, or if we can move it somewhere more interesting.

This post isn't just coming from a theoretical standpoint, of course. I've had so many run-ins with colleagues from quality that I simply have to question that whole role. Too often have they acted as alarmist messengers and chasers of other peoples' actions whilst understanding neither the problem nor the product nor the processes that they are supposed to be monitoring - that is, seemingly doing nothing about it themselves. They don't add value, nor do they seem to save value - they transmit urgency. Unfortunately, transmitting urgency to the wrong sort of person (for example, me) is precisely the least good way of getting things resolved quickly and effectively.

So, whilst we all inherently understand the idea of producing things in ways acceptable both to customers and to our finances, do we really need quality departments, quality managers, quality engineers? I think we could be cannier about the whole thing - and ditch them totally.

The best way to do that would be to design an engineering company from scratch - alas, not something that I've ever done. But for me, the basic idea would be that the tasks that quality departments undertake can be distributed amongst other departments where those tasks make more sense.

The flip-flop question is this: is it better to decentralise those tasks amongst experts, or to collect them all under one roof and standardise? It may well be that the size of a company - tipping around a certain critical morass - is probably a key factor in this decision. But the prospect of ISO / TS audits should not be!

I work for a largish automotive supplier, and we have quality departments coming out of our ears: it's the world I live in. Deleting them (distributing them) would mean for me personally that I would need to get my designs, from material selection through to defining tolerances, just right; my colleagues in production would have to design their processes to produce within the parameters of the drawings and specs I give them and that all needs to be validated and monitored.

In other words, nothing: eliminating the quality department would have no effect on my key role, nor on the role of my friends in process engineering.

However, I'm forever getting involved in quality concerns, analysing returned or quarantined parts, performing root-cause analyses. This can help me understand our product better, but rarely have I had to change a design as a result of these investigations. Enfolding one or two of our colleagues from quality into our test and development organisation would mean that those defects could ben analysed as thoroughly as they are now, and lessons learned could be centralised, whilst freeing me to work on the next generation of products, which is what, I believe, I'm supposed to be doing.

Manufacturing will still need people and systems to check and to confirm that product meets requirements, both at any given instant and over time - that's for sure; such roles will never go away, but these days we can trust our production team's integrity to manage that by themselves rather than abdicating that responsibility to a separate department.

The role of a quality department as independent arbiter, a kind of internal auditor, remains an interesting point: can we be sure that Manufacturing, for example, will always be open and honest enough about things like tool release decisions and scrap rates when deliveries or performance indicators are on the line? Well, if we can't be sure then it would surely be beneficial to work on the culture of the company rather than to add layers of oversight. Again, it's a question of opportunity cost - would it be more effective for a company to pay people to police their own people, or to research and to produce things more effectively?

If we think (or click) back to my post on how Google tests software, we see that the key philosophy there is: the design of the product should include its testing and confirmation methods. So it should be the  product and process design engineers designing this together, which makes sense to me.

And where would the resources come from to ensure that product and process design could cope with that additional work? From the now redundant quality department, of course.

That leaves the audit side of things. Of course, nobody wants to be involved in audits at any stage. But since audits are a fact of life in many industries, the product and process design teams need to be involved in designing the business systems that they use on a daily basis to use, store, distribute and to archive work. And they should be responsible for proving that these ways work both in theory and are used in practice.

So, eliminating quality departments, partially reassigning them to design and development, is the obvious answer to all of this - yet quality departments seem to grow and grow where I am. Am I missing something obvious that would really justify the existence of quality departments? Or can we continue to "Think Canny" in this funny old business of engineering?

Who reads procedures?

What, you don’t? Alright then, another question - who writes procedures? Ah, well, on that front, I have a confession to make: I do.

But hold on - if you’re not reading, why bother writing?

Let’s go back to the start, see what we’re dealing with. Procedures are company-internal documents that describe how things should be done. In that sense, the closest analogy I can offer is that, like the laws of the land (which I presume you, like me, haven’t read in their fullness), procedures form part of a distinct yet only subconsciously perceived scenery - barely noticed until you crash into them, or if a newcomer starts asking for directions.

That newcomer point is important: the bigger the company, the less likely it is that someone can naturally pick up and run with the workflows and networks of people and systems that combine to get things done. A start-up’s first instinct is not to write its procedures. Only when the company is established and has grown do such things begin to matter and procedures - instruction sets for beginners, for those lost in a maelstrom of work, or for those about to be audited - are written. (Rands in Repose has written a lot about transitioning from start up to big company, including and very eloquently about procedures and process in the software world)

So, I’ve written procedures. I’m not a prolific proceduralist, thankfully, and the ones that I’ve been involved in are hardly internal best-sellers*, but at least I can say that whilst novels they certainly are not, I have at least experienced some satisfaction at having the procedures approved and published.

Or perhaps journalism would be a better analogy than novels - when I was writing them, there was a real sense of urgency surrounding them. There was a sense of deadline, of needing to fix something that was broken.

But with a procedure? Which nobody will read? Hmm, that doesn’t quite add up. Unless people do read them. Some few, key people who then tell others how things should work - and those others more or less understand the intent and get on with it.

Until teams drift apart, new people come in and things get broken again.

Procedures - the making of

The key to remember is that procedures are principally a work in the written language, which means they always need some knocking back and forth and into shape - editing - at best within a small, motivated and expert working group. They are official documents, so they’ll need to be given their ID numbers and released into whatever system your company uses.

Procedures are also visual documents, so a certain design aesthetic is also worth investing some time in. Even if the only graphic in there is the workflow, it’s always worth trying to make it look and feel right by considering format, colours and alignment. If it looks shitty now, it’ll look shitty in three years’ time, and it will still have your name on it!

Procedures are structured documents, too, like technical reports: Introduction, Scope, Definitions, Resources involved, the step by step guide and the workflow should all be in there.

Structure, word and graphic need to be sound in logic and clear enough to read without frustrating or confusing a reader by descending into ever diminishing circles of definition (or spiralling up its own arse in grandiose sweeps of meaningless bluster. Ah, speaking of which, I’d better be moving on here…)

What is a good procedure?

A procedure is like a process flow, but for people. Do this, then that, inform this person, file that data there, fill out this form, review with that team, finish and get on with your lives. Like a good process flow, a good procedure should capture the steps, decisions and loops that result in a final product. A process results in a part, a procedure results in information. Both should maximise output and minimise waste.

Do procedures define or describe?

Companies generally muddle by, if we’re honest about it. There are things that need to be done and, buoyed by our honest and human sense of duty usually overriding any sense of “oh, let’s just forget it and do something fun instead”, we talk and email and chivvy and stress and eventually get things to a sufficiently complete state that we can move on to the next disaster.

Procedures formalise and idealise those inner workings of a company. Going back to the process analogy above, a procedure should be designed to maximise efficiency - in once sense, it is an engineered document (hopefully with decent spelling), in the sense that defines how things work in their optimum way.

So the question above is misleading: procedures do describe, but really they should define.

Are procedures a cure or a symptom?

One key reason for writing procedures is to correct course on some workflow that is sailing onto the rocks. Often, the rocks weren’t formally recognised before, so the new (or updated) procedure is effectively charting dangerous waters.

One of the biggest balances that a company has to manage, however, is resources. Even if we were all able to live and work on one project only, and all of our team members could do the same, tensions and bottlenecks would arise. With teams being involved in the multiple carousels of projects, individuals start think-feeling for themselves, taking on tasks that aren’t strictly theirs “to keep things moving”, while others try to keep low and out of the firing line. These tensions generate ever greater emotional potential.

This is where procedures form the “laws” of the company. He should be doing this, she should be doing that, but only when given this signal or that information. They should serve to de-escalate things. If they can’t, then it’s a clear sign that the respective teams aren’t set up correctly for that combination of tasks.

Ghost protocols

Eventually, all of these new definitions and workflows become the new day-to-day and procedures are no longer referred to. Or or those new spangly ways of working fade into disuse, yet their respective procedures remain, sitting in (often a bewildering array of) libraries somewhere, gathering digital dust, crumbling as entropy attacks their bits and bytes.

The dust is kicked up by everybody’s favourite bugbears, audits. As audits suddenly loom (which they tend to do), links are checked and if they still work, are distributed, some conscientious colleagues bookmark them and may even scroll through the procedures themselves. They generally won’t read them, though.

Occasionally, an auditor will prudently validate his job description and note a discrepancy between a job done and a procedure. Hands will be wrung, failure to comply noted and efforts made to be better in the future.

By that stage, though, procedures are usually dead. They lie in state - Lenin’s waxy visage springs to mind, though without his enduring popularity. Perhaps three people in my company know where to find them. Everybody else who needs to know anything about how things should run simply ask me directly - or kind of muddle by.

Anything, of course, being preferable to reading and understanding procedures. Although: at least procedures don’t get irritable if you consult them.

*I would normally put a number to this, but we’re just upgrading our SharePoint database, and stats have been switched off. I don’t know if they’ll be reset when they’re available again. I’ll update as and when I know.

December. Time of cheer and good will to all colleagues, rushing for presents, updating projects, Glühwein, clearing out inboxes, eating far too much chocolate, finalising reports and… 

And getting audited. 

Yes, we were audited this week and one of my projects was in the spotlight. It was all going swimmingly until the auditor heat-seekingly locked on to one particular thread of my project that wasn't really parcelled up and tied with string - ironically enough, the DFMEA.

Being shown up as lax in my own project was certainly embarrassing, one of those half-expected shocks to the system; I felt a bit like a child hoping rather than expecting not to be found out about those stolen chocolates. I was hoping rather than expecting to be able to skim over that the incomplete DFMEA (structure present and correct, values not), knowing that it was a weakness without really having polished it off beforehand. I was found out, and rightly so: that’s the reason audits happen.

We were marked down for it, of course, and I’ll have to get things back into shape sharpish.

Reading those words of mine just above (“that’s the reason audits happen”), I surprise myself with how true they ring.

Have I finally come to accept them? And if so, how do I accept them? Gladly, or grudgingly?

For years I’ve harboured a deep suspicion, a dislike of audits and what they stood for. For me, they stood for engineering by checklist, for doing rather than thinking, for rewarding completeness rather than innovation and - for the vast majority of my auditing experience - huge cleaning up operations for close to zero benefit.

When is something that is good enough not good enough? When it’s being audited.

I have experienced both sides of auditing; I have audited and have been audited. From being part of an auditing team, working alongside quite an enlightened auditing colleague, I understand that the mindset of an auditor should be a positive one, aiming to help the subject improve by pointing out the weaknesses and working on agreements to correct those weaknesses before they lead to genuine failures. This mindset should match that of the auditee. When both see the positives that can come out of the (like FMEAs) negative messages, then things are heading in the right direction.

Nevertheless, audits are a not insignificant burden on everybody involved. Couldn’t we just wish audits, along with PPAPs, away?

Well, not easily: auditing is a multi-billion dollar industry in its own right, valid across a whole spectrum of industries, and it’s a difficult edifice to start chipping away at. But even so: wouldn’t our engineering lives be so much more enjoyable without them?

Initially, yes - they would be. We would be freed up again to design and develop as we know best: we know what our products are supposed to achieve and how to get them to that stage, even if not every Excel list has been filled out to the n’th degree en route. We could potentially become more like Google, where “...in the innovative and fast-paced world that [the Google developer] lives in, you get what you get.” (From How Google Tests Software)

We would have more money and time to spend on D&D, too, not having to pay those auditing firms their crust or having to spend all of those man-hours preparing “just in case it’s audited”.

But let’s look at it another way. Let’s say we want to start using a lower-cost supplier, more than likely in the old Eastern Bloc or somewhere (usually very large) in Asia. What are these companies like? Can we entrust our intellectual property, our quality and our good name to them? What better starting point could there be than searching for a certificate alongside customer references? (well, it’s true that there are differences in auditing rigour in China, even amongst the financial big four, as The Economist magazine writes)

Audits cannot guarantee a good name, nor necessarily a good engineering company: there are firms with certificates on their walls that I wouldn’t wish on our fiercest competitors. In the same way that financial audits have missed gaping holes where the subjects have been playing the game better than they have - like Lehman Brothers, Enron and, it seems, Autonomy  - quality audits can almost be guaranteed to miss something big from time to time.

Even the auditors themselves get themselves in a muddle - our December date with auditing destiny came about when the auditing company missed a submission deadline. This swiftly became our problem when our certificates were due to expire and our emergency re-audit date last December became our annual date. Thanks, we appreciate it!

So, what are audits good for, then? Qui bono? For starters, audits are a reassuringly expensive starting hurdle to business: my industry - automotive - and many others have gotten themselves into a standardised twist, whereby an ISO / TS 16949 certificate is a prerequisite for supplying to an OEM. It’s a pay-to-play move gives potential customers a guide that the company won’t royally mess things up when they start a supply relationship.

Audits also place a burden of duty and therefore responsibility on companies and their employees – from management right down to lab technicians – to get things right. Not only to “get things right” but also to “design things right”. This applies both to the product itself and to the process of how you get the product into a customer’s hands. Ideally, an audit should be imperceptible other than having to make some coffee for a visitor and answering a few questions. Why should you have to prepare if you are living the systems that you have declared fit for your own purpose?

Umm, too much other stuff to do, perhaps? Not enough time to focus? Not enough mental energy left for yet another list-trawl?

Well, if audits and all the stuff that we have to prepare for them really are a burden, then - again, ideally - they should become the impulse for genuine improvements in the way we work, in the way we communicate and collaborate. All of that form-filling, report-writing and change log management should have a genuine purpose, even if it is occasionally completed in the grudging spirit of passing an audit. All of these items are part of the company's index of information. When we change and update those forms, we are changing history, improving it. It's about creating a legacy, hopefully one of that will make sense of our successors' past.

The one thing that can make audits bearable is for everybody involved to treat it as a human thing - checks and balances are inevitably required whenever human endeavour is at work, so go with it. Let the auditors ask the good questions and let them discover how you work - even I with my DFMEA fail this time around will have shown that overall we’re working well and are going in the right direction. So, I’ll take that “nonconformity” hit and try to improve on managing my projects along with managing everything else, and let’s see if we can find some mental space to put to use on streamlining our work so we can do better next time.

And so back to my initial question: do I accept audits gladly or grudgingly? Well, of course it’s still the latter, but at least it means that I aim to keep them as low profile as possible: for that, though, I’ll need the support of my management – and I can assure you that the audit result was a wake-up call for them, too. Perhaps better things will come of it (or perhaps more oversight and review meetings – still, they’re a way of switching the focus to projects).

One final note on all of this: I don’t recall ever hearing anything about audits when I was studying engineering at university. That’s something that should change (perhaps it has, already), as they are a real, if occasional and generally unloved, part of this engineering life. If the next generation of engineers know what’s in store for them, they’ll know to focus on how they work as well as what they actually work on.