Should QA have Technical Competency

[John Broomfield]

You should be aware that there are technical aspects with regard to QA that people in engineering and purchasing--especially purchasing--might not be aware of. QA review of POs, especially for new products, is almost always a good thing. I can't tell you how many times I've encountered issues and delays because purchasing or engineering overlooked something important. Also, "Not my job" is almost never a good response to a request for help, regardless of the situation.

Jim,

I was not being asked to help.

Getting engineering to work with purchasing removed the need for checking the POs because of preventive actions in engineering.

Yes, the whole cross-functional team needs to be working together to deliver quality assurance; QA cannot do it alone.

We also used to say "there is no such thing as a quality problem" to stop the instinctive call for more checking or more inspecting by QA.

John

 

[Ronen E]

"Not my job" is almost never a good response to a request for help, regardless of the situation.

So, in the name of good mateship everyone should help with everything, when asked? I fail to understand how that would promote efficiency, effectiveness and identification of bottle necks / wrong practices. I do agree it sometimes promotes a more pleasant workplace, though

 

[Jim Wynne]

So, in the name of good mateship everyone should help with everything, when asked? I fail to understand how that would promote efficiency, effectiveness and identification of bottle necks / wrong practices. I do agree it sometimes promotes a more pleasant workplace, though

Here is the post from Mr. Broomfield that prompted my response:

QAPK,

If it is technical then is probably not QA's job. As a new Project Quality Manager on my first day I was asked to review purchase orders before issue to suppliers. I refused saying this was the job of Engineering and Purchasing left to work with Engineering instead of QA on getting the POs right.

Then I got on with QA's job of developing the project's process-based management system so it helped the multi-disciplinary project team to prevent problems as they collaborated to determine and fulfill the requirements.

Had QA been sucked into the myriad of (very interesting) technical work we would never have developed, audited and improved the project management system so everyone could deliver QA.

John

Note that Mr. Broomfield says that on his first day in a new position he was asked to assist with contract review and refused on the grounds that it was not his job, or at least that it was someone else's job. I'm sure that the story was condensed and that there was more to it, but the fact is that we're supposed to be helping to break down the siloes, not create or reinforce them, and there's always more than one way to help.
Help may be provided in the form of making people aware that there are conflicting priorities, and asking management to sort them out so that everyone is aware of everyone else's primary responsibilities.

Getting the product out the door in conforming condition is everyone's job, and everyone needs to be prepared to do what's necessary to make it happen.

 

[QAPK4E]

To me the technical side of quality needs to be at a point where quality can speek to the information at hand. This includeds discussions with engineering, purchasing, manufacturing, and all groups within and external to a company. Maybe a technical review by quality is not required as this should be correct when it comes from engineering, but....... How can you converse with a supplier on a corrective action with a technical issue? How can you create an effective quality plan without being able to read a drawing and understand the process. How do you identify what is important? How do you determine sampling, or measurement systems (at least approving)? Leave it up to engineering and manufacturing? Only if you have a company culture where quality is #1!