Elsmar Cove Quality DiscussionsDesign Control 4.4 - Design Engineering manager has no structured documentationThe Cove Business Standards Discussion Forums More Free Files Forum Discussion Thread Post Attachments Listing Cove Discussion Forums Main Page
Design Control 4.4 - Design Engineering manager has no structured documentation
UL - Underwriters Laboratories - Health Sciences
Design Control 4.4 - Design Engineering manager has no structured documentation
Design Control 4.4 - Design Engineering manager has no structured documentation
Design Control 4.4 - Design Engineering manager has no structured documentation
Design Control 4.4 - Design Engineering manager has no structured documentation
Design Control 4.4 - Design Engineering manager has no structured documentation
Design Control 4.4 - Design Engineering manager has no structured documentation
Design Control 4.4 - Design Engineering manager has no structured documentation
Go Back   The Elsmar Cove Business Systems and Standards Discussion Forums > >
Forum Username

Elsmar Cove Forum Visitor Notice(s)

Wooden Line

Design Control 4.4 - Design Engineering manager has no structured documentation


Elsmar XML RSS Feed
Elsmar Cove Forum RSS Feed

Monitor the Elsmar Forum
Sponsor Links




Courtesy Quick Links


Links Elsmar Cove visitors will find useful in the quest for knowledge and support:

Jennifer Kirley's
Conway Business Services


Howard's
International Quality Services


Marcelo Antunes'
SQR Consulting, and
Medical Devices Expert Forum


Bob Doering
Bob Doering's Blogs and,
Correct SPC - Precision Machining


Ajit Basrur
Claritas Consulting, LLC



International Standards Bodies - World Wide Standards Bodies

ASQ - American Society for Quality

International Organization for Standardization - ISO Standards and Information

NIST's Engineering Statistics Handbook

IRCA - International Register of Certified Auditors

SAE - Society of Automotive Engineers

Quality Digest

IEST - Institute of Environmental Sciences and Technology

Reply
 
Thread Tools Search this Thread Rate Thread Content Display Modes
  Post Number #1  
Old 23rd September 1999, 07:27 PM
Marc's Avatar
Marc

 
 
Total Posts: 26,294
Quid Pro Quo Design Control 4.4

Quote:
Subject: 4.4 Design Control
Date: Mon, 20 Sep 1999 07:32:56 -0700
From: "D., John"
To: Forum_Mail@qs9000.com

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.
That definitely won't cut it. I'd have a serious talk with the person in that capacity if they didn't have a defined, documented system. Design activity is more than a little bit important. The person is living in the 1950's.
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.
I really don't have such a check list. Maybe one of the others here can help you out.
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.
The other option is to not register.

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.

[This message has been edited by Marc Smith (edited 23 September 1999).]

Sponsored Links
  Post Number #2  
Old 29th September 1999, 12:26 AM
Marc's Avatar
Marc

 
 
Total Posts: 26,294
Yin Yang

Some other design 4.4 info:

-----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

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

> 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?

Charley
  Post Number #3  
Old 29th September 1999, 12:34 AM
Marc's Avatar
Marc

 
 
Total Posts: 26,294
Covering Ass

Subject: Re: Q: Design Requirements (4.4.6 & 4.4.7) /Button/Kozenko
Date: Thu, 16 Sep 1999 09:16:14 -0600

> 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 !!!

David Kozenko
  Post Number #4  
Old 29th September 1999, 12:37 AM
Marc's Avatar
Marc

 
 
Total Posts: 26,294
Subject: Re: Design Requirements (4.4.6 & 4.4.7) /Button/Hankwitz
Date: Fri, 17 Sep 1999 13:48:57 -0600

> 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.

John Hankwitz
  Post Number #5  
Old 29th September 1999, 12:39 AM
Marc's Avatar
Marc

 
 
Total Posts: 26,294
Covering Ass

Subject: Re: Q: Design Requirements (4.4.6 & 4.4.7) /Button/Coffelt
Date: Fri, 17 Sep 1999 13:54:08 -0600

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?'.

Just my opinion - hope it helps.
Arline Coffelt
  Post Number #6  
Old 3rd October 1999, 07:18 AM
Andy Bassett

 
 
Total Posts: 278
I would also like to understand this element a little better, i am ashamed to admit that even after implementing ISO 9001 in several companies i feel that i have gotten this element passed the auditors 'on the fly' (maybe sometimes helped by the fact that the auditors are confused by the requirements).

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

------------------
Andy B
  Post Number #7  
Old 3rd October 1999, 11:08 AM
Marc's Avatar
Marc

 
 
Total Posts: 26,294
Covering Ass

I'm sitting here thinking about how to answer this. I sorta feel '...I know it when I see it...' but that doesn't help you. I posted these snippets from the list serve because I know this is often misunderstood. After many implementations I really can't think of a specific example.

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.

Inputs - Can be many things including RFQ, Qoute, acceptance (PO), print(s).
Outputs - Drawings, specs, instructions, software, servicing procedures.
Review - at least 2
Verification - Paper predictions
Validation - device tested in 'real' conditions.

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

I'll look for an example procedure.
  Post Number #8  
Old 3rd October 1999, 11:38 AM
Don Winton's Avatar
Don Winton

 
 
Total Posts: 484
Clown

Andy,

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 http://Elsmar.com/pdf_files/FDA_files/X03DESGN.DOC . It is a Word 6.0 document.

Regards,
Don

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

Lower Navigation Bar
Go Back   The Elsmar Cove Business Systems and Standards Discussion Forums > >

Bookmarks



Visitors Currently Viewing this Thread: 1 (0 Registered Visitors (Members) and 1 Unregistered Guest Visitors)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Forum Search
Display Modes Rate Thread Content
Rate Thread Content:

Forum Posting Settings
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Emoticons are On
[IMG] code is On
HTML code is Off


Similar Discussion Threads
Discussion Thread Title Thread Starter Forum Replies Last Post or Poll Vote
Design & Documentation of Control Systems and Procedures v9991 Document Control Systems, Procedures, Forms and Templates 11 1st October 2014 02:46 AM
Request for a Design Control Procedure or Process Flow for HVAC Design tonyjj Document Control Systems, Procedures, Forms and Templates 1 2nd May 2011 12:16 AM
What things go in Design Control Documentation for a 510k of Class II Medical Device Jennifer27 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4 25th April 2011 08:41 AM
Design control documentation provided in special 510(k) + FDA response celia4237 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2 10th December 2008 11:45 PM
Design Laboratory Notebook Procedure in your design control or quality system? sardonyx Design and Development of Products and Processes 3 3rd August 2005 01:43 PM



The time now is 03:25 PM. All times are GMT -4.
Your time zone can be changed in your UserCP --> Options.



Misc. Internal Links


NOTE: This forum uses "Cookies"