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?

Engineers, like lawyers - hold on, I didn't just write that, did I? Well, it's a valid thought, so I'll press on. Engineers, like lawyers and other animals, can be classified into distinct genera and species, depending on the path we take within our chosen vocation.

As soon as I had, whilst at school, settled on engineering as the subject I wanted to study and practice, it was clear to me that I was much more of a "boffin" type than a "hacker". I was always uneasy about mending things, more confident about designing and working things out - so I opted for aerospace engineering. After graduation I went to Ford (emphatically not an aerospace company, despite its history and current CEO). There, I spent some time working in Manufacturing Engineering. I enjoyed the challenge, at times, but I wanted out, back to component and design engineering.

Who cares how it's made?

Now, my job is (should be) to develop and upgrade product so that it does what it is supposed to, when it is supposed to do it under all conceivable conditions. Whilst it sounds almost blasphemous to say it in these enlightened days of openness and collaboration, I don't necessarily care how it arrives at that point, as long as the how of its making doesn't affect the if of its functionality, or its cost too much.

Of course, this means that I do have to care about the process, as it more often than not does affect the product in clear or in subtle ways. So I talk to our process and manufacturing engineers.

Who are, of course, also design engineers.

I suppose we have all settled into a kind of shorthand for engineering titles, as the word "design" is redundant. There are those who design and develop product, those who design and develop the process, and those who design and develop the equipment to be used in the process to make the product designed at the outset (process product design, or something like that!).

By and large, from my experience, process and manufacturing engineers are cut from a different cloth to product engineers. They can work together, but rarely does one stay in the other's shoes for long. At the extremes, you could envisage the gnarly manufacturing engineer and the soft white-handed product engineer - of course, these types meld and merge, but the tendency is there, I feel.

And we talk.

Silos or troughs

Whether I "get to" talk to these colleagues, or "have to" depends on personalities - which, fortunately, engineers don't have - but where I work, we are distinct groups that need to be brought together on a project by project basis; we need to jump those famous silos to work together, rather than always being together, feeding from the same trough - perhaps "collaborating freely" would be a better turn of phrase.

Our means of communication is still principally email, alas. Our offices are close enough to walk to, but all too often, simply waltzing into each others' enclosures means a disruption of some sort. We're all busy people, who need to try and focus on some one thing at a time. Disturbances from outside, whilst of course important, mean a reshifting of focus from some other, hopefully equally important, activity. So to minimise the growling, we email or invite each other to short meetings, which is really the best method to have disparate minds alight on the one subject for a few quality minutes.

So, we have feasibility reviews, we cooperate on FMEAs (still too infrequently), we sketch, we negotiate (more often than not on tolerances), and we make, measure, test, update and approve our product.

We work together, in short.

Ideally, I should embed myself in their world so that my designs flow and interact as smoothly as possible with theirs, and their reflect the functions that the product needs to have. In small, dedicated teams, that could work, but currently it's all about snatching time to work on one thing rather than another: even were I to share a desk with them, all we'd be doing is shouting over each others' telephone calls.

So I'll stick to my "ivory tower" (as of course they call it), for the time being.

In praise of process

But from that tower, from behind this screen, I want to place on record my respect for my engineering cousins in process design. These are colleagues who get to play with robots, with sorting and sequencing machines, with presses and with tool designs; these are people who have a very rich and very different mind to my own.

I haven't the faintest clue how to design and specify a press or a hopper bowl that will position and place fitting after fitting into an assembly rig so that they are all applied - firstly at all, and secondly in the correct orientation.

In some many cases, it is the process people who give one company a slender advantage over another - either through holding dimensions and quality better than anybody else, or by bringing costs down to an attractive level for everybody concerned. In the automotive world that I know, most contracts involve a year-on-year price reduction clause. This assumes that as a product achieves maturity, scrap levels are reduced, efficiency in increased and waste is minimised. These are valid assumptions to make, but the work towards achieving those goals in an economic way is principally down to the process and manufacturing engineers.

So really this post is about acknowledging the diversity within our own world of Engineering and letting it be known that I have the utmost respect for the guys and gals who, much more than Getting Things Done, Get Things Made.

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.

Yesterday, Thursday, being a bank holiday (at least in my state of Baden-Württemberg), today was a classic German "bridging day". One day's holiday resulting in a four-day weekend is simply too good a ratio to miss for most Germans, and I had also planned to take advantage of the bridge.

But with so much going on in so many frantic ways, with so much on my plate and buzzing in my head, I felt it was better to ensconce myself in a quiet, colleague-free office and get some work done.

I was disappointed to to see upon my arrival an office full of colleagues who had had similar thoughts, all chatting away about a colleague's house-build project, architects and unreliable builders. I skulked off and found an empty manager's office nearby, docked my laptop there with my own peripherals, left my cordless phone on its station and closed the doors. I spent the morning trudging through drudgery (hello, PPAPs) and then the afternoon working on DFMEAs and updating my presentations for the training I'll be giving in Detroit in a few weeks' time.

It was great. I didn't need to plug in my headphones, nor did I end up continuously distracting myself with the internet. I simply worked, ticking off my "Big Three" tasks for the day, plus a few "Notable Nuisances" as the hours ticked comfortably by.

It all comes back to environment. As I hinted in my post about Engineering Things Done, I cannot work effectively in an open plan office. There are always people on telephones, colleagues discussing work or debating which is the cheaper internet provider. Sometimes it's good to get involved in the community aspect of work, that's certain - they're decent people, and I'll need their support at times, too, so I daren't become a recluse - but I need peace and quiet to work properly.

I suspect that most engineers would be better with flexible environments. We're knowledge workers, so need time and space to think. Even when we're dragged into quality mud-fights and validation testing, our minds should be at peace so that we can maintain our "switchability" between big picture and detail.

So - individual offices for engineers? That would be impractical. But the ability, both physically and culturally, to switch environment and context is important and needs to be cultivated.