7.3.2 Design and Development Inputs clause - What is the record needed?

  • Thread starter Thread starter Rooch
  • Start date Start date
R

Rooch

Hey everyone!
I just finished with an Internal audit (I subcontract my internals) and had a finding against the 7.3.2 Design and Developement Inputs clause. I guess I should go back and state we are moving from QS to ISO registration, and will be having a pre-assesment audit in July. This was the first internal for the ISO9001:2000 QMS. Anyway back to the question...The finding stated "No evidence that the inputs to the design are being reviewed for adequecy, if they are being reviewed, the identity of the person performing the review is indeterminate".
The way I read the standard, the inputsrelating to product requirements shall be determined and records maintained. This would be in our business, bid specifications, contracts, Ford specificaations for specific types of equipment and anything we have to add to the input that we have learned from other projects. Basically bullit points a) through d) of the stadard.
Now it says they shall be reviewed, but i do not see that I need record of these reviews. They happen throughout the design process, at various stages of design.
Do I have this right, or am I confused?

Thanks to all. :thanx:
 
Elsmar Forum Sponsor
Sorry Ralph, I dont see that as any help.
Besides, I can not find them in the ISO standard, that say's I have to do that any more.
 
Rooch, what does your documentation say you will do?

7.3.2 Design and development inputs said:
Inputs relating to product requirements shall be determined and records maintained (see 4.2.4).....These inputs shall be reviewed for adequacy."

That addresses evidence being maintained for the review for adequacy. Pretty clear to me, at least, that records of the review are maintained.

If you have a copy of ISO 9004:2000, I strongly suggest you read what it written about 7.3.2 and how you could meet the requirements.
 
Last edited:
Hi Rooch,

We hold regular design reviews for new projects (in our case this means stamping tools), and get the persons responsible for the project (design engineer, project manager etc) to 'sign off' completed designs, verifying that the design is capable of producing the required product at the final design meeting (verification is required before authorisation is given to begin manufacture of any tooling).

Perhaps this would satisfy your requirement?
 
Thanks Phil and RCbeyette. I am thankful for your input, but I do not agree with you. If you look through the standard you continue to see the requirement "records of review" or "records of the results of.." shall be maintained (see 4.2.4). You see it in 5.6.1, 7.2.2, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.4.1, 7.6, but when you read 7.3.2 it says INPUTS RELATING TO PRODUCT REQUIREMENTS SHALL BE DETERMINED AND RECORDS MAINTAINED (see 4.2.4) and the inputs shall include, yada yada yada.
Then it says "these inputs shall be reviewed for adequecy".
Where does it say I have to maintain a record of this review?
It does not!
I have inputs to design determined and maintained, and if someone wishes to see them, we can get the project folder from the project manager and review them. We review inputs constantly! All the way through a project for many many different pieces of equipment we are manufacturing.
I feel that the nonconformity that was written stating that there were no records of review of the inputs for adaquecy, is not a valid finding.
I would still like to know what some of the other people think about this.
T :( hanks to everyone again.
 
The design inputs (bid specifications, contracts, Ford specificaations for specific types of equipment and anything we have to add to the input that we have learned from other projects) should be reviewed for incomplete, ambiguous or conflicting requirements by the same people in the regular design reviews and a record of this review kept.
 
Rooch said:
Then it says "these inputs shall be reviewed for adequecy".
Where does it say I have to maintain a record of this review?
It does not!
What evidence do you have that the inputs have been reviewed? Isn't this the issue? You're paying the auditor to look for evidence and he/she couldn't find any, apparently because there isn't any. What did you expect? You need to stop playing legalistic semantics games and understand that you're violating both the letter and the intent of the standard in this regard. Can't you think of any reasons that records of review might be important?
 
evidence? That is a lot different than a record! How else would I be able to supply the customer what he wants if there is no review of inputs. How would I determine verification points to check like, speed, lift height, paint color,etc (design output has met design input), or validation results.
The evidence abounds that inputs have been reviewed for adequecy, but the finding I received states that I have no record of the review of these inputs.
By the way, I am not playing games. There are no stupid questions, and I dont think you should be replying to people that they are playing games.
 
Rooch said:
evidence? That is a lot different than a record! How else would I be able to supply the customer what he wants if there is no review of inputs. How would I determine verification points to check like, speed, lift height, paint color,etc (design output has met design input), or validation results.
Some very experienced people have offered guidance, but you disagree, which is certainly your privilege. It seems that your argument is with the auditor, who seems to be expecting the review process to be more formal (which is the consensus, I think). Have you asked about his/her interpretation, and what it is he/she expected to see? Do you know of other instances where ad hoc review has been considered acceptable?

Rooch said:
The evidence abounds that inputs have been reviewed for adequecy, but the finding I received states that I have no record of the review of these inputs.
Auditors are supposed to look for system issues. You're saying that because things turned out well, everything that happened before then must have been OK, but that's not necessarily evidence that there's a plan. Everything is always OK, until something bad happens.

Rooch said:
By the way, I am not playing games. There are no stupid questions, and I dont think you should be replying to people that they are playing games.
My apologies.
 
Back
Top Bottom