Design Control 4.4 - Design Engineering manager has no structured documentation

Marc

Fully vaccinated are you?
Leader
Design Control 4.4

Subject: 4.4 Design Control
Date: Mon, 20 Sep 1999 07:32:56 -0700
From: "D., John"
To: [email protected]

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

Marc

Fully vaccinated are you?
Leader
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
 

Marc

Fully vaccinated are you?
Leader
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
 

Marc

Fully vaccinated are you?
Leader
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
 

Marc

Fully vaccinated are you?
Leader
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
 
A

Andy Bassett

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
 

Marc

Fully vaccinated are you?
Leader
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.
 
D

Don Winton

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.
 

barb butrym

Quite Involved in Discussions
I like to keep design simple and give the engineers a little controlled freedom. They review the input and agree on a plan based on complexity, and similarity to other previous designs...publish using MS project....project manager keeps a 'project book' with copies of the stuff you did according to the plan and all communications...MS project is on line and available for review only. YA keep project on "track changes" (provides a history of changes and updates..then print one after changes) Reviews are done according to the plan...always prior to purchase of tooling and pre release..as well as what ever else the PM decides. Copies of print outs and drafts become part of the book, drafts have rev control by mark up sign/date between reviews, and rev # after each review.

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.

[This message has been edited by barb butrym (edited 03 October 1999).]
 

Marc

Fully vaccinated are you?
Leader
Design Control

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

***list of work instructions***
 
Top Bottom