Design - Simple System - ISO 9001 Clause 7.3 - Review vs. Verification vs. Validation

[Bob_M]

OK I've posted, read, and searched about design process/procedure before on the cove.
I'm trying to create a simple process / procedure / form that will cover the ISO requirements without creating to much paper work (like current system) and I'm getting stuck...
While working on THIS area I've been reading and re-reading the standard, samples, posts, and our own 1994 style forms, and I'm getting more lost and confused by the minute. (Manual is due 7/28/03 and Design procedure is past due in boss's eyes).

To start: Small company - metal stamping and spot welding, I'm Quality and Engineering, most designs are customer owned and controlled, we typically DON'T design anything from scratch, we may provide input to customers to assist them in updating THEIR design. We occasionally will modify some internal sub-component and have typically MANAGED that via an ECN (Engineering Change Control), Registar recommened that we NOT exclude design.

I'm just going to post MY understanding of the standard and please point my in the correct direction if I'm wrong...

7.3.1 Planning
If we have a "design" project, we should PLAN on how we will Manage the project (responsibilities, timing, reviews, etc). Rather straightfoward. I suppose this is simple enough if you do it on a regular basis. The form I'm working on has a Team Member Section and "Planning" section.

7.3.2 Inputs
We have to identify and record our inputs. OK we document and record/retain our ideas/drawings/suggestions/etc that are the driving force behind the design. No Big deal, we DOCUMENT our input whatever form it may be...

7.3.3 Outputs
We have to make sure out outputs meets our input requirements...
A simple example I understand is: The drawing created (output) must match the designs inputs and requirements. What if the input is a drawing?

7.3.4 Review
Now someone has to REVIEW the output, and document that they believe it matches the input. Seems simple but this is the start of my confusion... What if the person providing the input is also creating the output, reviewing, verifying, validating, changing etc... (seems like a waste of time/paperwork).

7.3.5 Verification
Now someone has to VERIFY the output and Document that they have VERIFIED it... Didn't we just do that during review? Is this typically verfication of a physical sample? If not it just seems like a repeat of review.

7.3.6 Validation
Now someone has to VALIDATE what has been reviewed and Document it... How many times do you need to recheck input vs. output (on a simple design)?????

I guess I'm confused about Review vs. Verification vs. Validation, and past posts reading has not clarified it enough for me...

7.3.7 Change
Ok I get this one, if they design changes, we need to redo all the reviewing, verifing and validating...

We have a seperate Engineering Change PROCEDURE that technically incorporates "designs" that are already in production.

Any guidance or additional tips/examples/suggestions are welcome.

Like I stated the harder I work on this the more confused I get. This is partly due to not having a "functional" design process even though we were certified to 1994:9001, also we haven't "designed" anything our self since BEFORE our certifcation to 1994.

I'm not as "freaked" out about handing NEW PRODUCT introduction and minor internal changes. I suppose those should/do fall under the "design" umbrella, but we've never really treated them like it...

Well thanks for any help.
If my rambling is totally confusing, we its the stress and deadlines fogging my mind.

Thanks Bob M

 

[David Hartman]

Bob,

Let me start with some questions that may help stimulate some out-of-the-box thinking.

1. Related to the use of "special" forms - How do the design projects get coordinated today (e.g. Use of email, memos, etc.)? If there are currently email communications taking place (as an example) have the author maintain a file of those communiques (your records). In-fact in every instance where a "record" of a comminique or review is to be maintained, look to what may be available currently. Don't re-invent the wheel!

2. You are quite correct that in simplistic designs the "review" and the "verification" activities may in-fact be one and the same. But you also might give consideration to having a peer review of the design - more than one set of eyes looking at the input requirements -Vs- the output.

3. Verification and Validation are NOT the same. Verification looks at paperwork (output -Vs- input). Validation looks at the product -Vs- input requirements (Does the product actually meet the customer's requirements?). This can be accomplished through first article inspection and/or testing of the product (or similar means).

4. Finally, include in your procedures allowances for heritage-based products, those that may not need to go through the entire Design & Development process (based on similar prior designs).

I don't know if I have answered all (or any) of your questions, but I hope this helps.

 

[Bob_M]

Your post does help some...
In response to your questions:
1) We currently are NOT designing anything... This is the majority of my problem - Lack of experience and practical use

The "special" form I mentioned is being created to eliminate the 6+ form that were created for our 1994:9001 certifcation - which are not being used and are repeative.

Minor product changes are typically handled with ECN (Engineering Changes Notices) Forms which act as a signoff sheet and task list. Those are initiated by ECR (requests) which are more or less the INPUT, which are reviewed and approved as appropriate.

2) OK I'm not crazy Review and Verfication can be the same task (depending on the scale of the design).

3) So Validation typically refers to PHYSICAL review of a product. This helps clear up some confusion.

4) I'll have to make sure I don't forget that part!!

Thanks...
Additional input/comments are welcome.

 

[M Greenaway]

Bob

If I were you I would claim exemption from these requirements - you say you dont design, so dont design !

 

[Bob_M]

Bob

If I were you I would claim exemption from these requirements - you say you dont design, so dont design !

Well I've drafted a very BASIC design project "planning and record sheet" that just covers ISO's requirements.
We have an Engineering Change Procedure in place already (and have had for a while).
I plan on creating a short design "procedure" that outlines the bare requirments and heavily refer to our EC procedure.

I'll talk with our registrar during our Pre-Assessment about excluding it.
Its going to be very hard to "audit" our "design" process when we almost never design... But then again it can depend on how you define "design"...

 

[howste]

Attached is a copy of a "New Product Development Form" I helped create for a small nutritional products company. It basically has all of the information they need to develop new product. It includes inputs, output, reviews, verification, and validation. They don't have a procedure - only the form. It may give you an idea of a way that one company has done it. The company that uses it was certified to ISO 9001:2000 last year.

 

[Bob_M]

Attached is a copy of a "New Product Development Form" I helped create for a small nutritional products company. It basically has all of the information they need to develop new product. It includes inputs, output, reviews, verification, and validation. They don't have a procedure - only the form. It may give you an idea of a way that one company has done it. The company that uses it was certified to ISO 9001:2000 last year.

Interesting and inspiring.
Thanks.
Even though the form it self can't be applied by our company, it does give me some good ideas on how to make a simple
New Design / Modified design or product check list that covers ISO, our basic needs, and actually might work as a record of proper review prior to use...

Hmmm... If only I had more time to get everything PERFECT... Guess that's what continual improvement is for...

 

[howste]

The idea of the form was to keep it simple and try to capture all of the required records for 7.2.1 & 7.3 in one place. This obviously won’t work with more complex designs, but it sounds like the designs you do are fairly straightforward. The first column captures the design inputs (requirements), and the second captures the design outputs. Compare them side-by-side and you have done your review.

 

[Bob_M]

The idea of the form was to keep it simple and try to capture all of the required records for 7.2.1 & 7.3 in one place. This obviously won’t work with more complex designs, but it sounds like the designs you do are fairly straightforward. The first column captures the design inputs (requirements), and the second captures the design outputs. Compare them side-by-side and you have done your review.

Yes I agree nice simple way (for that application) to take care of design and product introduction.

Our bloated system is not well organized and used way to many forms. Considering it was based on QS-style requirments I understand why.

Thanks again for the idea. Our bloated system does work and is not used, but I can trim it down to an easy to use design/introduction form I don't see much of a problem "keeping" design in our system. From a certain point of view, Product Introduction SHOULD follow all the same steps as designing regardless who designed the INPUT.

Now I just need time to work on it... (Maybe after the manual...) Argh!

 

[dbzman]

Daxed and Confused

Hi everyone!

I'm a little confused on this Verification Validation thing.

I work for a Heat Treating company (Heat Treat metal parts), and I'm trying to get this right.

Verification: Testing to Specification, Paperwork.

Validation: Testing to customer performance req.

When we develop a new process to heat treat a part we look at the customer input (specifications, metal parts, etc) and determine the output (work order, procedures, etc).

When we perform a test run to see if the process works we test the parts to spec (Verification). When we develop the heat treating process we may look a similier jobs to determine the right process (Validation).

When are we actually performing Verification and Validation. I was under the assumption that Validation came before Verification.

Where am I missing the boat.

If Verification is paperwork then where does the testing of the part come in?

If Validation is testing why compare to other jobs?

As you can see I'm having a little trouble fitting the two in. Everytime I think I have an understanding I read something else that confuses me.

Thanks for any help given!


Mike W