posted 23 September 1999 07:27 PM               

quote:

---

Subject: 4.4 Design Control
Date: Mon, 20 Sep 1999 07:32:56 -0700
From: "D., John"
To: "'Marc'"

We are preparing for a ISO 9001 audit in early November. Our Design Engineering manager has no structured documentation system but plenty of loose notes.

---

quote:

---

It has been extremely difficult to convince him that documentation, as described by the ISO standard, is the minimum expected from his department.

I have two questions:

1. Is there a engineering checklist available, one that has a guideline of progressive steps through an engineering design, verification and validation process that you can recommend.

---

quote:

---

2. If the engineering department does not approve in a developing methods that conform to the standard are there any other options?

Thank you for you time and great web site.

---

I would give the responsible manager a copy of 4.4 and tell him/her those are the requirements to meet. S/he doen't have a choice if your company plans to pass the audit. Typically this will come to a head when the registrar does a preassessment and the offending department 'fails' the audit.

I was doing an implementation some years ago. The plant manager told me that he didn't have to do mamagement review if he didn't want to and he didn't want to. I said fine. During the preassessment the auditors explained that compliance was not an option if they wanted to be registered. Yes - he complied before the registration audit.

It comes down to 'Who screwed up the registration?' if s/he decides that the ISO requirements do not apply to his/her department. I have no sympathy for 'head in the sand' people.

posted 29 September 1999 12:26 AM               

-----snippo----

Subject: Re: Q: Design Requirements (4.4.6 & 4.4.7) /Button/Scalies
Date: Thu, 16 Sep 1999 08:37:50 -0600
From: ISO Standards Discussion

From: Charley Scalies
Subject: Re: Q: Design Requirements (4.4.6 & 4.4.7) /Button/Scalies

> From: "John N. Button"
> Subject: Q: Design Requirements (4.4.6 & 4.4.7) /Button
>
> Perplexing questions came up at work with my colleagues and we were
> wondering what other people thought.
>
> 1) Based upon paragraph 4.4.6, is a design review always required,
> regardless of the item?

Yes, if you are designing the "item"

> It would seem that it is always required, based
> upon strict interpretation of the words in the Standard. But this would
> require a design review for a cap screw that holds something simple like a
> nameplate.

Are you designing the cap screw? The nameplate? The black box the nameplate goes on? The spacecraft the black box goes in?

> ISO does not seem to offer any flexibility in this area. Is
> this interpretation correct?

No as to the lack of flexibilty. You will note that the standard does not prescribe how you will review the design, whether it ill be done on the overall item or on each design component of the item, or when. You have all the flexibility that common sense provides to you. In the case of the cap screw, what is it's purpose as defined in the specs? What are the spec requirements it is to meet? Based upon the status of the design at the time of the review(s) can you determine that the design of the cap screw has provided for all these requirements? This design review might take all of 5 minutes or, if it's a cap screw that holds a nameplate on a black box in the the space shuttle, it might take a bit longer.

> 2) What is the difference between the actions required by Paragraph 4.4.6,
> Design Review and paragraph 4.4.7, Design Verification?

In the case of the simple cap screw, maybe none. It's OK to fulfill many requirements through a single activity, as long as all the purposes are served.

> Does not a design review meet the requirements for paragraph 4.4.7 in that
> it ensures that the design output meets the design input?

A "final design review" might include that. A "preliminary design review" probably wouldn't. How many design reviews you do, and when you do them, is your call to make and should be determined based on the needs of the particular design project.

> It appears that performance of a design review also satisfies the
> requirements for design verification. Is this correct?

It certainly could in case of the cap screw.

My final suggestion to you is not to "over read" the requirements of the standard. Read them as though they were intended to apply to your business activity, as though they are supposed to make perfect sense - because they do. Above all, understand the purpose of the design control requirements. What is it they are trying to accomplish?

posted 29 September 1999 12:34 AM               

From: [email protected]
Subject: Re: Q: Design Requirements (4.4.6 & 4.4.7) /Button/Kozenko

> 1) Based upon paragraph 4.4.6, is a design review always required,
> regardless of the item? It would seem that it is always required, based
> upon strict interpretation of the words in the Standard. But this would
> require a design review for a cap screw that holds something simple like a
> nameplate. ISO does not seem to offer any flexibility in this area. Is
> this interpretation correct?

Element 4.4.6 requires your quality system to have established "formal, documented reviews of the design" ... "At appropriate stages..." so there's plenty of flexibility there, no? Design review functions to keep all design input parties communicating. Just imagine no design review meetings at all, picture the worst case, then work backwards from there to plan "appropriate stages" for design review meetings (so you could probably be safe in skipping the cap screw holding a nameplate, things like that).

> 2) What is the difference between the actions required by Paragraph 4.4.6,
> Design Review and paragraph 4.4.7, Design Verification? Does not a design
> review meet the requirements for paragraph 4.4.7 in that it ensures that
> the design output meets the design input? It appears that performance of a
> design review also satisfies the requirements for design verification. Is
> this correct?

Follow me on a quick "big picture" walk through: Contract Review (4.1) refines requirements for the contract so they're not ambiguous. Sometimes, design requirements are expressed as "performance" requirements (like, "I want a TV that receives antenna and cable") so that's made clear in contract review, and it becomes a Design Input requirement. Design Review (4.4.6) keeps the procurement side of the house from cutting corners on costly components for such TV so that it will meet the Design Input requirement of being able to receive antenna and cable (where a less expensive component may cancel good performance under antenna use). Design is accomplished formally with documented Design Input and Design Output requirements, and after all planned Design Reviews are accomplished and (hopefully) all design work is formally documented, the Design Output is examined against the planned Design Input to make sure there's a "match" (or, Verification) for each requirement. In this example, there might have been a lot of theory behind the design input / output decisions related to components use, for antenna and cable reception on our TV, so a prototype might be constructed and tested which, in this example, would be Design Validation (4.4.8). (Usually Validation can be accomplished without prototypes, but for this ditty I just couldn't resist ).

NOTE: If you think this is all complicated, you're right -- it is, and doubled by the fact that it has to be documented under each sub-clause of 4.4. For any typical firm seeking Registration ( at least, up till now ) the difference between ISO9001 and ISO9002 is often one or more extra audit days solely on 4.1. Maybe now a few more list members will understand why 9002 is so popular -- it's often half the price of 9001 at the same firm !!!

posted 29 September 1999 12:37 AM               

From: "Hankwitz, John "
Subject: RE: Design Requirements (4.4.6 & 4.4.7) /Button/Hankwitz

> From: "John N. Button"
> Subject: Q: Design Requirements (4.4.6 & 4.4.7) /Button
>
> Perplexing questions came up at work with my colleagues and we were
> wondering what other people thought.
>
> 1) Based upon paragraph 4.4.6, is a design review always
> required, regardless of the item? It would seem that
> it is always required, based upon strict interpretation
> of the words in the Standard. But this would require a
> design review for a cap screw that holds something
> simple like a nameplate. ISO does not seem to offer any
> flexibility in this area. Is this interpretation correct?
>(snip)
>
> J. N. Button
>

If you design it, you review it, twice. The size and scope of that review could vary with the size and scope of your design. You need to design your design process to vary with the design being done.

As an example, when we need to design a new product, our process mandates the use of a full project plan, usually created with planning software. This will include detailed tasks, deliverables, timelines, resources, and so on. We mandate a minimum of eight Design Reviews conducted at prescribed stages of the design. A designated list of Design Review attendees is specified to make sure all the proper individuals are involved. Formal Design Review forms are required to document every aspect of the review meetings.

On the other hand, we often need to create a simple design to adapt an existing product to a specific customer need. A special bracket might be a good example. (We don't design cap screws to secure nameplates like you do, we purchase them) At least two design reviews are specified to be held for this simple type of design project. But now, the mandatory list of participants is reduced to those disciplines directly associated with this simple design. A simple Design Plan may now be hand written on the Design Request form. The Design Reviews may now be conducted using e-mail or notes from phone calls.

What I'm trying to say is that you need to design your systems to be flexible enough to handle all your normal situations. Think smart and creative. Above all, look beyond the requirements. Understand why the requirement is there, and what's it's real purpose is. Customer satisfaction, overall efficiency, preventing nonconformity, and profit all lie behind every word of every requirement. With this in mind, create a system that accomplishes all this for you. ISO 9000 is actually very flexible. Use it to serve YOU and your customers the best way possible.

Don't get caught up in the Standard's words. Understand what they mean. I often see companies mandate signatures on every quality record, or publish and control detailed lists of acceptable contractors because they don't understand what "approval" or "quality record" means. If your interpretation of a clause looks like too much is being required, it's usually because you don't understand what the requirement is, and/or why it's there.

posted 29 September 1999 12:39 AM               

From: Arline Coffelt
Subject: Re: Q: Design Requirements (4.4.6 & 4.4.7) /Button/Coffelt

John,

You might find the publication 'Formal Design Review' (ANSI/ASQC D1160-1995) very helpful, especially the descriptions of the various types of Design Reviews that can/may/should occur during the product life cycle. Simplicistically, if you think of a 'review' as a meeting (formal or informal) wherein you discuss/inspect/evaluate all of the requirements of the product (at whatever level of completion that it has achieved at the time of the review)....and the objective evidence of satisfaction of those requirements (e.g. test results, inspection reports, etc.) then this review could be considered as validating the product at this particular level. But the review is where you are 'doing' part of the validation activities...it is not validation itself.

As for validation - try reading ISO 9001 4.4.8 again (...conforms to defined user needs and/or requirements...). How are you demonstrating this in your Inspection/Test/Evaluation activities? In another time and place you might say 'does it meet Form..Fit..and Function?'.

In one place we always said -verification - 'did the engineer build what he said in the design spec that he was going to build'....and validation - 'did the engineer build what the contract said would be built and does it meet the customer's needs?'.

posted 03 October 1999 07:18 AM               

No matter how often i read element 4.4, i cannot completely understand what each section of the element is looking for. What i would like to see is a simple real life example of how each section of 4.4 can be satisfied, either in text format or a flow diagram. Does anybody out there have something like this?

Andy

posted 03 October 1999 11:08 AM               

Each company is quite different, yet alike (how's that for a statement?). Maybe something like:

Design and Development Planning - this would be APQP to QS folks. A defined process if you will.

O & T Interfaces - Procedures define who gets customer prints and such - defines responsibilities.

D Inputs - Can be many things including RFQ, Qoute, acceptance (PO), print(s).

D Outputs - Drawings, specs, instructions, software, servicing procedures.

D Review - at least 2

D Verification - Paper predictions

D Validation - device tested in 'real' conditions.

Design Changes - Same loop. Wgat varies is the re-entry point.

posted 03 October 1999 11:38 AM               

You may also want to check the FDA explanation of Design Control requirements. They are pretty much parallel to the ISO requirement, and their guidance document may help. Maybe not.

Try /pdf_files/FDA_files/X03DESGN.DOC . It is a Word 6.0 document.

Regards,
Don

------------------
Just the ramblings of an Old Wizard Warrior.

Check Out dWizard's Lair:
*** Dead Link Removed ***

posted 03 October 1999 07:29 PM               

Reviews show verification of design status/output to the input, as well as the quality plan. Validation when applicable is done either as part of the release, prototypes or after by the customer..again planned in the project time line.

Your procedure states what is minimum in the book and the plan. State soptions that may be used.... And of course assigns responsibilities very clearly. Templates are a plus.

I find the engineers buy into this easily as they don't feel that someone is telling them how to design.

posted 04 October 1999 01:31 AM               

Approved: __________________________________________________
title Name
Approved: ___________________________________________________
title Name
Approved: __________________________________________________
title Name
Approved: __________________________________________________
title Name
Approved: __________________________________________________
title Name

Change Record
Rev
Date
Responsible Person
Description of Change

Name
Initial Release

Distribution List
(list the departments that receive controlled copies)

1. Purpose
ð To control the design and development of new products.
ð To define the checks and balances applied to the design and development activity.
ð To control and verify the design of the products, assign design function responsibilities, define technical interfaces, ensure that the product meets the specified requirements, and verify that the design output meets the design input requirements.
ð To expose the product design to persons with viewpoints and opinions other than those of product design and development engineers.
ð To re-evaluate distributed products.
ð To maximize protection against oversight that might adversely affect product quality, safety, and efficacy.
2. Scope
This procedure applies to the development of all new products from the initial design to the release for manufacturing.

3. Responsibilities
***Job title*** approves the product specification for major new products, product revisions, and accessories.
***Department*** evaluates performance, durability, safety, reliability, and maintainability of the design under expected storage and operational conditions; verifies that all design features are as intended and that all authorized design changes have been accomplished and recorded; validates computer systems and software.
***Department*** provides initial product requirements, performance target values, and market utility assessments.
***Department*** ensures the availability of products and services required for the manufacturing and testing of the product.
***Department*** advises and reviews necessary testing and inspection requirements.
***Department*** ensures that sufficient personnel are available and suitable for the production of the product, and that an appropriate training program is instituted.
***Department*** ensures that the facilities, instrumentation, machinery, equipment, and services are available for the efficient production of the product.
***Department*** tracks revision levels and changes to preliminary drawings. ***Job title*** approves revisions to preliminary drawings.
***Job title*** coordinates:
ð the design and production of sketches, drawings, and layouts
ð the building and testing of models, prototypes, and pilots, including the acquisition of materials
ð the collection and recording of test data
ð any modifications to the product specification, if necessary
At all stages of development, ***team*** representing ***departments*** may determine whether to modify the product specification or change the design of the product based on test results.

4. Procedure

4.1 Review Team
See Contract Review xxx.
***Job title*** translates the customer's needs into technical specifications.
***Team*** composed of ***job titles*** reviews the specification and ensures it is producible, verifiable, and controllable.
***Team*** generates a design plan identifying activities and assigning responsibility to the activities. Those assigned to perform design activities meet company qualifications. ***Records of qualification*** are stored as Quality Records at ***location***.
***Team*** meets ***activities***.
***Records*** of ***team*** meetings are maintained as Quality Records. ***Job title*** maintains the records for ***length of time*** in ***location***.

4.2 Market Review
***Job title*** can initiate a concept for a new product. Features of a new product are based upon ***information***.

4.3 Product Definition
See Document and Data Control xxx.
***Job title*** develops preliminary drawings. ***Job title*** approves the preliminary drawings.
Customer requirements are incorporated into the design. ***Department*** communicates the requirements to the design team through ***activity***.
Design of product includes the applicable statutory and regulatory requirements to which ***Company*** adheres.
***Job title*** generates ***document*** to support the design. The documents are controlled and maintained by ***department***.

4.4 Qualify and Verify
See Quality Records xxx.
***Job title*** is responsible for testing the new design and records test results on ***name of form***. The ***name of form*** is maintained by ***department*** for ***length of time***.
***Job title*** reviews the test results and if required the preliminary design drawings are revised.
The preliminary drawings are released for a pilot run. ***Job title*** evaluates the pilot run.
The test procedures specify the following ***criteria*** and include: ***types of analysis***.
***Job title*** records the test results onto ***name of form***. The ***name of form*** is maintained by ***department*** for ***length of time***.

4.5 Final Review
A final review to determine if the product meets the requirements of the product specification is held by ***team***.
***Job title*** qualifies the pilot run determining if the product meets the requirements of the product specification.
Subcontracted, suitably qualified facilities are used for specialized testing.
The review includes ***criteria***.
The ***name of form*** releases the design to production. ***Job title*** approves the ***name of form***. The ***name of form*** is maintained by ***department*** for ***length of time***.

4.6 Requalification
Periodically the product is re-evaluated to ensure that the design is still valid with respect to all specified requirements. The review includes: ***criteria***.
Records of the re qualification are maintained on the ***name of form***. ***Job title*** approves the ***name of form***. The ***name of form*** is maintained by ***department*** for ***length of time***.

4.7 Revision Control
Design changes are given the same review as the initial design. ***Job title*** reviews changes and modifications to the design of the product. ***Job title*** revises the documentation.

5. Related Documentation
***record of meetings***
***design plan***
***form for qualification***
***test procedure***
***training records***

Contract Review
Document and Data Control
Corrective and Preventive Action
Quality Records
Training

posted 14 October 1999 01:02 PM               

Actually i have to be honest and say i am still struggling, i think maybe i am blinded by my usual environment (Automotive Motosport).

4.4.1 I can accept that a design procedure needs to exist blah blah blah
4.4.2 I can accept that some sort of design and development planning needs to exist. Whatever ISO wants, i usually ask for a Project Plan (Although these inevitably turn out to be a design and production time-plan).
4.4.3 Organisational and Technical Interfaces - In my environment this is too variable to define, in the procedure i just list all the interfaces i can think of and put in a get-out clause like 'where necessary'.
4.4.4 Design Input - Seems simple enough, a description of what we are trying to design (Although some cynical colleagues did once define a design input as 'Car should be as fast as possible'. I cant help but sympathise with them sometimes).
4.4.5 Design output - IE a drawing, and it appears that this should be checked. Against normal drawing standards i can accept, against a design input i have a problem, in most of the examples that i have seen the design input is a product of an engineer or marketing managers fantasy, and the design input is difficult to write until after the finished product can be seen (Maybe i am just unlucky with the products that i work with).
4.4.6 Design Review - My experience of design review is that it is taking place on an almost contiuous unofficial level. All the people involved are shocked when they are asked to fix a date and discuss all the necessary components. The best i have ever been able to do is get a Head Engineer to sign-off that design of the final product is complete. If its Christmas i might actually get him to compare it with the design input.
4.4.7 Design Verification - Err i think i have already done this Mr Auditor. What is wanted here.?????
4.4.8 Design Validation - Err what are we talking about here, could it possibly be testing the prototype. If so i have no problem. (Wouldnt it be nice if it said this more clearly in the standard)
4.4.9 Design Changes - No problem they have to be handled according to a consistent procedure.

Re-reading the above it seems my problem lies somewhere between 4.6, 4.7, 4.8. Fortunately the auditors must have the same problem, otherwise they wouldnt have approved so many of my companies (Or maybe it was that bottle of whisky....)

Marc
I have a couple of suggestions, during recent debates i have referred people to your site and told them to go through one of the threads.
It is a good sort of training. Do you think it is worthwhile to offer some sort of on-line training? ie i tell engineers to log on to a course for design review, they do some interactive training, answer a questionnaire and get an E Mail certificate. I suppose in some way it takes work away from the implementer/consultant, but it may also support him.

Although i suppose i am paid to interprete the standard, i know that i, and many of my customers can only relate to it through real-life examples. Is it worthwhile to set-up on your web-site 4 or 5 real-life examples for each element of ISO 9000? I dont mean the procedures themselves, as very often they are written in the same dry manner as the Standard itself.

Regards

posted 15 October 1999 10:09 AM               

quote:

---

Although i suppose i am paid to interprete the standard, i know that i, and many of my customers can only relate to it through real-life examples. Is it worthwhile to set-up on your web-site 4 or 5 real-life examples for each element of ISO 9000?

---