Re: Should Quality folks be just policeman & policewomen?
So many good responses so far.
I picked up the remark that the people don't think the Quality group is technically inclined, and also not good in providing solutions. Indeed, quality auditing and resulting Corrective Action (CA) follows the Management by Exception principle by nature unless the QA person is more helpful in providing insight as to why this or that is helpful or risky.
How much technical understanding a QA people need depends on what the organization expects of them. If these people are expected to solve others' problems, the risk is that the QA person becomes responsible for the outcome in a process not in that person's control.
QA people can advise but execution and decisionmaking is up to the process people. QA people can use the basic QA Management Tools to help facilitate the problem solving process: a coach. These tools could sometimes be used in a meeting, and including representatives from various affected departments, where technically superior people and process owners/contributors can provide the input while the QA person asks the questions and uses the answers to execute the tools. Do this often enough and one could hope the process people can be steered toward adopting such tools for smaller level, day to day problem solving.
The resulting solutions thus belong to the process people where they belong, and the QA person has satisfied their wish to be more collaborating. In this manner, QA can problem solve without technical prowess.
It requires Corrective Action (CA) to be elevated from the police action, and even above the schoolteacher sense, although for things like documentation needs the CA really does look more like just a school assignment. And that's okay because the technically brilliant may not have a solid understanding about how to write a procedure that satisfies QA standards like ISO.
Yesterday I took a department's procedure, which was unclear on things like responsibilities, and made a bunch of notes on it that explained to the document's owner (test software department manager) what was needed. No need for him to guess and for us to push the thing back and forth until he got it right. Under old-style CA an auditor would be discouraged form teaching and such a hands-on approach but I feel it's a good time to move from cop to teacher. It's what my employer wants, which is especially important.
I wonder if your organization is sending mixed signals? Is the system set up through management for QA to behave in the Management by Exception mode and the process people are unhappy with the model? If so, the idea of coach/facilitator should be presented to management so everyone can understand the change QA is trying to make and why.
I hope this helps!
So many good responses so far.
I picked up the remark that the people don't think the Quality group is technically inclined, and also not good in providing solutions. Indeed, quality auditing and resulting Corrective Action (CA) follows the Management by Exception principle by nature unless the QA person is more helpful in providing insight as to why this or that is helpful or risky.
How much technical understanding a QA people need depends on what the organization expects of them. If these people are expected to solve others' problems, the risk is that the QA person becomes responsible for the outcome in a process not in that person's control.
QA people can advise but execution and decisionmaking is up to the process people. QA people can use the basic QA Management Tools to help facilitate the problem solving process: a coach. These tools could sometimes be used in a meeting, and including representatives from various affected departments, where technically superior people and process owners/contributors can provide the input while the QA person asks the questions and uses the answers to execute the tools. Do this often enough and one could hope the process people can be steered toward adopting such tools for smaller level, day to day problem solving.
The resulting solutions thus belong to the process people where they belong, and the QA person has satisfied their wish to be more collaborating. In this manner, QA can problem solve without technical prowess.
It requires Corrective Action (CA) to be elevated from the police action, and even above the schoolteacher sense, although for things like documentation needs the CA really does look more like just a school assignment. And that's okay because the technically brilliant may not have a solid understanding about how to write a procedure that satisfies QA standards like ISO.
Yesterday I took a department's procedure, which was unclear on things like responsibilities, and made a bunch of notes on it that explained to the document's owner (test software department manager) what was needed. No need for him to guess and for us to push the thing back and forth until he got it right. Under old-style CA an auditor would be discouraged form teaching and such a hands-on approach but I feel it's a good time to move from cop to teacher. It's what my employer wants, which is especially important.
I wonder if your organization is sending mixed signals? Is the system set up through management for QA to behave in the Management by Exception mode and the process people are unhappy with the model? If so, the idea of coach/facilitator should be presented to management so everyone can understand the change QA is trying to make and why.
I hope this helps!
).
