Attention quality pros, review and comment on the following question/concern:

I was auditing "Design and development" and while reviewing ISO 9k2k, requirement 7.3.2 (Design and development inputs) at the engineering function, I observed that the inputs were qualitative and not quantitative, in other words the requirements in the document stated inputs such as: market need, build a collator, build a pneumatic application tool, design, etc. I did not see any quantitative specs such as numbers and tolerances, specifications addressing with a number a certaing customer need to be met.

What can you comment about the above. Can companies doing design enter qualitative inputs, or is it up to the customer, " that's how we do things here" about compliance? my idea is that systems must improve, yet, I don't want to over react and p---off the engineering manager because of the lack of quantitative inputs.
Thanks,

Irrespective of what ISO 9001 states and how one interprets the design input requirement, you know your engineering process is dysfunctional.

Reminds me of the famous cartoon:

can you expand a bit further on your comment please, it is of interest to me to get objective opinions based on fact and experience about my question.

But, 7.3.2 a, states: functional and performance requirements, (the req does not state that quantitative specs are to be defined) comment?

I'm hard pressed trying to find where "Quantitative" is a requirement.

Irrespective of what ISO 9001 states and how one interprets the design input requirement, you know your engineering process is dysfunctional.

Reminds me of the famous cartoon:
http://bp2.blogger.com/_cJlO4iDMRPY/RzsB1XEIgKI/AAAAAAAAAIo/6yC7_HIW9MA/s1600/what-the-customer-actually-wanted.jpg

:topic:

I was unable to open the link. Is it still alive?

Stijloor.

I double-checked for my own sanity, but the word "quantitative" isn't in the standard.

Mark

Attention quality pros, review and comment on the following question/concern:

I was auditing "Design and development" and while reviewing ISO 9k2k, requirement 7.3.2 (Design and development inputs) at the engineering function, I observed that the inputs were qualitative and not quantitative, in other words the requirements in the document stated inputs such as: market need, build a collator, build a pneumatic application tool, design, etc. I did not see any quantitative specs such as numbers and tolerances, specifications addressing with a number a certaing customer need to be met.

What can you comment about the above. Can companies doing design enter qualitative inputs, or is it up to the customer, " that's how we do things here" about compliance? my idea is that systems must improve, yet, I don't want to over react and p---off the engineering manager because of the lack of quantitative inputs.
Thanks,

Juliov,

Some organizations use the Quality Function Deployment (QFD) process to convert the Voice of the Customer (VOC) which in many cases consist of qualitative data into clearly defined design goals (quantitative data).

When conducting an audit, you should look for this. The purpose of design review is to verify that the design output meets the design input requirements. Even though the ISO 9001:2000 standard does not use this (qualitative-quantitative) terminology, design and development activities are much easier to monitor and track (audit) if the data is available in a more quantitative format.

But whatever type of data is available is what we should use. Auditing is many times not what we like to see, but what the company decides to use. And if it meets the intent and purpose of the D&D process...what can we say?

Stijloor.

Attention quality pros, review and comment on the following question/concern:

I was auditing "Design and development" and while reviewing ISO 9k2k, requirement 7.3.2 (Design and development inputs) at the engineering function, I observed that the inputs were qualitative and not quantitative, in other words the requirements in the document stated inputs such as: market need, build a collator, build a pneumatic application tool, design, etc. I did not see any quantitative specs such as numbers and tolerances, specifications addressing with a number a certaing customer need to be met.

What can you comment about the above. Can companies doing design enter qualitative inputs, or is it up to the customer, " that's how we do things here" about compliance? my idea is that systems must improve, yet, I don't want to over react and p---off the engineering manager because of the lack of quantitative inputs.
Thanks,

I'm with Sidney. While the standard does not require the inputs to specifically be quantitative, and I would be willing to accept beneficial qualitative inputs, the examples you cite are silly...The sound like something they tossed together for ISO audits. Not meaningful, useful and effective inputs.

It could be an NC, at minimum would be an audit trail leading to an OFI or NC. Does not seem like they get it. I would explore their understanding and intention.

Randy, I was referring that the inputs to 7.3.2 a, this company use are qualitative. I know that there is no requirement asking for "Quantitative" inputs, however, inputs in a quantitative form could be best for a design that meets customer needs.

Helmut and Stijloor comments above address this topic and it appears that while auditing 7.3.2 any form that best suits the organization should be fine and no NCs could be issued, as long as the company "says what they do, and do what they say"

It appears that some companies also don't know much about D&D, other than design by experience the correct methods are not used. Add hoc?

Hello Mark, see my reply to Randy addressing your same concern. Thanks.

Randy, I was referring that the inputs to 7.3.2 a, this company use are qualitative. I know that there is no requirement asking for "Quantitative" inputs, however, inputs in a quantitative form could be best for a design that meets customer needs.

Helmut and Stijloor comments above address this topic and it appears that while auditing 7.3.2 any form that best suits the organization should be fine and no NCs could be issued, as long as the company "says what they do, and do what they say"

It appears that some companies also don't know much about D&D, other than design by experience the correct methods are not used. Add hoc?

Wait a minute, if you read my post #8, I did not say any form is OK, and no NC's could be issued! I said the ones mentioned sound like they are not effective, and were just thrown together. It is an audit trail, and would likely lead to an NC or at least an OFI. But, I would have to audit further before I could decide that.

"say what they do, and do what they say" was overrated and simplistic 10 years ago, and is completely outdated today. Systems must be effective, not just compliant with some procedure. Many of the NCs I write are because a process was not effective, not just basic compliance.

Hello Helmut,

What do you mean by "willing to accept beneficial qualitative inputs", thanks

qualitative and not quantitative,

I think this is red herring.

Try some Dr. Phil on it "How's that working out for ya?"

If they are making tons of money, gaining market share, customers are happy, designs launch on time, with few errors, and have few warranty problems...then "Just walk away Renee"

<Classic song by The Left Banke 1966 - I was 7 building tree houses - where were you?>

But if there are problems, Dr. Phil says "you might want to try something different!"

As was suggested, this response would definitely cause me to dig. It just doesn't sit right.

If they are making tons of money, gaining market share, customers are happy, designs launch on time, with few errors, and have few warranty problems...then "Just walk away Renee"

<Classic song by The Left Banke 1966 - I was 7 building tree houses - where were you?>
.

:topic:

Caster,

Sorry, I could not resist.....

The Four Tops did it too, but I like this version better.

6uqBTzfcIk4

Stijloor.

Hello Helmut,

What do you mean by "willing to accept beneficial qualitative inputs", thanks

I would accept a client defining whatever design inputs they wish, qualitative, or quantitative. I think either could be acceptable if they are meaningful. The ones cited by the OP as examples however, sounded silly, not meaningful.

Attention quality pros, review and comment on the following question/concern:

I was auditing "Design and development" and while reviewing ISO 9k2k, requirement 7.3.2 (Design and development inputs) at the engineering function, I observed that the inputs were qualitative and not quantitative, in other words the requirements in the document stated inputs such as: market need, build a collator, build a pneumatic application tool, design, etc. I did not see any quantitative specs such as numbers and tolerances, specifications addressing with a number a certaing customer need to be met.

What can you comment about the above. Can companies doing design enter qualitative inputs, or is it up to the customer, " that's how we do things here" about compliance? my idea is that systems must improve, yet, I don't want to over react and p---off the engineering manager because of the lack of quantitative inputs.
Thanks,

There is not enough presented here to make a good evaluation, but it sounds like you are trying to bend the standard to your concepts. There is no requirement for "quantitative" anywhere is 7.3.

Design activities can vary widely from one company or industry to another. Some design activity will by nature be quantitative and others will not.

As in many things in the standard, the true test is effectiveness. In design, effectiveness is evaluated during review, verification, and validation.

There can be a difference between what an auditor would like to see or even expect to see, and what the standard requires. Auditors should always apply the test of "what does the standard say" while auditing and running across something that doesn't seem right.

All in all what still doesn't sit right with my opinion is the fact that
7.3.2 a: says "functional and performance requirements"
what do we understand then by functional and performance reqs? about a couple of examples. There seems to be a wide interpretation and very subjective interpretation of the req among us in quality. Any examples out there? thanks,

All in all what still doesn't sit right with my opinion is the fact that
7.3.2 a: says "functional and performance requirements"
what do we understand then by functional and performance reqs? about a couple of examples. There seems to be a wide interpretation and very subjective interpretation of the req among us in quality. Any examples out there? thanks,

The bottom line is that the standard allows the company to define what the requirements are.

If the company chooses to define it "quantitative or qualitative" for design input then where would they be wrong?

I really don't think, in my opinion, that there would be any NC's issued, unless the procedures lack the requirements. I would probably identify it as an OFI.

I am not quite aware of what the product was when the auditor asked for quantitative design input. If it is some manufactured product there would most likely be some quantitative aspect to the specification that form the customer requirement (design input) e.g. dimensions, weight, volume, speed, intensity of light, sound/noise, finish etc. The point is to see whether the reply or the evidence provided appears credible irrespective of whether the standards specifically mention quantitative or qualitative inputs. We need to look at the intent of the standard.

I know of cases, both as a consultant and as an auditor, where the companies do not want to give the details of design input (also about design verification/validation) in the belief that they would be giving away some design secrets. In this case it is a question of allaying their apprehensions that is needed, yet one can even indirectly confirm that the company does take into account the important design input requirements.

I feel what is required is a proper judgment on the part of the auditor to ask questions that may uncover what design inputs would be involved for a given requirement.

Good luck!

All in all what still doesn't sit right with my opinion is the fact that
7.3.2 a: says "functional and performance requirements"
what do we understand then by functional and performance reqs? about a couple of examples. There seems to be a wide interpretation and very subjective interpretation of the req among us in quality. Any examples out there? thanks,

Hello Juliov,

Simple example:

Functional: A detailed description of what the product is supposed to do. Its intended functions.
Performance: A detailed description of how long it is supposed to last. Its duration/longevity.

Stijloor.