9/23/2005

Who is responsible for quality?

I had the pleasure this week of speaking at a chapter of ASQ (American Society for Quality). I chose a topic which is near and dear to me: Roles and Responsibilities. Applying that topic to this venue meant speaking about quality.

I felt I had a big challenge going into a group of quality professionals because both my book and my consulting practice help organizations strive for excellence and that is part of what quality professionals try to accomplish as well. I was heading into their home turf. I was going to preach to the converted.

The way I approached it was to discuss what I would try to accomplish with product development engineers. I asked them to suspend belief and maybe they could use some of my philosophies and techniques to their advantage. With me being the only thing between them and dinner, I was pleased by their interest, excitement and acceptance of the talk.

So who is responsible for Quality? The answer is obviously everyone. If you ever cordon off responsibility for quality to some group you will not achieve quality in your product.

I am also, as I say in my book, a firm believer in having one owner for each task or goal (they may delegate pieces but they must make it happen). So, who is responsible for Quality in a product? The answer is the person responsible for developing the product. No finger pointing, no blame and very simple.

This is a leadership thing. Your leaders must make quality a priority and legitimize time. The must set expectations that everyone must do their part and be held accountable. Without these critical pieces, you will not achieve quality in your product.

So what does this mean on a practical basis? Here is one example that I try to implement in each company I participate in: exhaustive functional unit tests. I require the engineers development products be responsible for the basic tests that prove what they developed works. Code cannot be checked in without those tests complete, run, working and code reviewed just like the product itself.

What does this accomplish? It pushes quality earlier in the cycle, makes it easier to get a quality product and enables accountability. It is hard. It is different. It is effective.

How does this affect accountability? Imagine, if you will, a salesman who sells a lot of product but his customers never pay or we have no idea if they ever pay. There is a reason why commissions are paid out on receipt of customer payment. The same thing goes for software. If a developer codes away and never proves their software works then they are not completing their job and the value to their company is significantly reduced.

More later ...

No comments: