The entries stored on this page are also available at my blogger site http://allygillcouk.blogspot.com which has additional features which may make the material easier to read and filter.


Quality - What's It Really All About?

I've spent a lot of time recently (far too much I fear) looking and occasionally participating in some of the LinkedIn Quality Forums. Most of these have been the ISO 9001 type forums rather than domain specific. With ISO 9001 being a generic quality standard, it’s not surprising that the participants in these forums come from all walks of life, from aerospace to telecoms, from supply chain managers to certification body auditors, and from quality directors to quality engineers. Occasionally there are people like myself - who are primarily involved with knowledge workers.

The biggest take-away I’ve had from these forums is that consensus amongst quality professionals is rare, that tempers seem to flare far more than in other forums I frequent (including some of the ‘agile’ oriented groups) and that you could lock a group of quality folk in a room for a month and they’d still be no closer to defining what quality really is!



So, if there’s so much discord between people who actually spend their lives and earn their keep from working in quality, what chance do the rest of us have. I include myself as one of the rest of us quite deliberately as these days I think of myself as a business person who happens to have some hands-on understanding of quality matters in some very specific situations - namely the IT industry and more specifically in software development.

Looking for a standard definition doesn’t really get us very far. I’m not even going to bother with a dictionary definition because it’s so vague but here’s Wikipedia’s entry:

Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-inferiority or superiority of something; it is also defined as fitness for purpose. Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people. Consumers may focus on the specification quality of a product/service, or how it compares to competitors in the marketplace. Producers might measure the conformance quality, or degree to which the product/service was produced correctly. Support personnel may measure quality in the degree that a product is reliable, maintainable, or sustainable. A quality item (an item that has quality) has the ability to perform satisfactorily in service and is suitable for its intended purpose.

The clue as to the problem is clearly stated in the second sentence which is so important that I’ll quote it again.

Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people.

My experience of quality is mostly internally facing, supporting the group of people who collectively have responsibility for developing the IT product or service, be they managers, developers, testers, analysts or even salespeople, HR, and finance. This is my set of primmary customers, and there is usually some interaction or interface with a client side quality person. The products I have traditionally had responsibilty for are the processes, artifacts, workflows, data and tools that my customers need to be able to produce the best products they can for their customers.

It’s been evident for many years that trying to apply traditional product and manufacturing quality tools in a knowledge working environment is somewhat futile. Conceptually, there are great ideas that can be applied in both manufacturing and knowledge based industries. A great many quality principles can be applied universally, but principles, ideas and tools need to be aligned closely to the environment they are to be used in. In other words, they are almost always contextual.

An inspection process (let’s not get involved for now about whether inspection is a good or bad thing) in the software development environment is very different to the inspection process on an automotive production line. Six Sigma out of the box, doesn’t work well in the software development environment - if for no other reason than the original principles were designed to work with highly repetitive automated processes where human interaction is much less than when developing software which is highly dependent on individuals. We have a similar situation where Lean Manufacturing ideas applied to an office environment without some serious tailoring and adaptation leads to the type of nonsense I described in my previous post where desks were marked out with the 'optimised' positions for computers, keyboards, mice, telephones, etc. regardless of whether a person was right or left handed.

Ultimately, it doesn’t matter too much if there isn’t consensus between quality folks coming from different contexts. What’s important is that people in the same organisation have a consistent view of what quality means in their very specific context. I’m not talking about the slogans and banners that seem to adorn so many office corridors and walls, but a real shared understanding of what is expected from your people when it comes to quality in the workplace, and an up front statement of what your people can expect from their quality department. And then we all need to act and behave accordingly.

If we work on the old adage that "quality is everyone’s responsibility", then this is the very least we can do.



Comments
For other entries click here