Hello

Ok. There seems to be some issues with my design control issues. My design guy in the toolroom says the system is too complicated. Perhaps that's why he wears velcro shoes....

Anyway, I need a very simple procedure to perhaps explain this better. I was pretty proud of my procedure/form. I have a form that he can follow the process along and fill in as he completes steps. I have attached it for you guys to take a look at. (Design Data Sheet). Any advice would be most appreciated.

Thanks guys!

FG

who does design control? What does he do it now ? How does HE want to meet the requirement? Does he know and understand the requirement for evidence? Does he understand verification and validation? The procedure and form should reflect his thoughts, not yours. I personally like the form, but leads me to many questions on the V&V stuff.

Does he think it ties his hands...I would guess yes. How about a basic MS project chart template he can change?

Barb

The procedure is his! I am huge on letting the employees draft their own procedures and I always have them review them before I issues them. He has approved this. There is a flow chart (I have attached it to this message) for his operations manual. It's starting to look more and more like he is lazy and stupid. Bad combination. I kind of think he just doesn't understand it. Although, he says that he does. There are some underlying employee issues here too but I won't go into those.

Thanks BArb!!

FG

design, for me, is one of the toughest nuts to crack...not because of the requirements, but because of the nature of the beast. Engineers are "mathematical, creative and visual" people to various degrees and to a fault...by nature...thats what makes them good at what they do......and what works here today may not tomorrow. This is by no means a hit on engineers........ Just my opinion looking in. SO that in mind...how can we help? Well as I said my favorite is a project management tool template with all the shalls required and the extras as optional...it keeps them in control, but lets them be creative. Their understanding of teh standard is probably not the same as yours...it never is....the key is to somehow get buy in by making it a tool that helps them.......

Hi

Project Management Tool huh? Do you use something like that in your workplace? If so I would like to see sample please. Is it kind of like my Design Data Sheet that I attached a few messages up? That tells them what they need to do and then sign off and date when the step is copmplete. They are expected to attach copies of meeting minutes, drawings etc as evidence all these things really did happen. I don't know how to make this any easier.

Engineers got nothin' on toolmakers!!!!

FG

toolmakers.......hmmmm forgot about them, they fit the same mold, I agree

I use MS Project. I am a consultant so i don't have one that is mine...I helped to develop many..... but usually let the engineer do it (it helps the buy in!!!!!) i will look around my archieves for a draft. Basically We take a completed complex design and work backward....listing what was required, what one would expect to see in the file as a minimum and a wish list. The chief project engineer takes the template and adds or deletes steps as he plans the design, he puts in the details, milestones etc as it applies to each design....and assigns responsibility...once the task is completed on the chart, the record is placed in the file. Updates to the plan are automatically tracked and visable on the network. Each project is a notebook and the table of contents is updated with each entry into the folders. Each company has its own set of criteria and review requirements based on product complexity....so I never bothered to keep one.

FG,
Do you need to have design development requirements which are scaled to the size of the job?
You don't have to apply all the design control requirements of a $25 million job to a $100 job.

I'll email you some procedures and a form that might give you some ideas - unfortunately I haven't got one that'll fly for you straight of the bat.

PS - that flow chart...was...(how do I say ugly in a nice way?)...um...perhaps needs to be better customised to the needs of the user.

I agree its quite lean, but is presented with a detailed procedure...so it appears to be an overview/summary to show the shalls are covered.....Or that is what i read into it....LOL

I just had a brain storm........perhaps that is where all the discussion of flow charts not being allowed as procedures comes from......????????????

David

I'm crushed.... y y y y you don't like my flow chart????? LOL Yes it's a little lean but there are procedures that go with it. I just attached the flow chart. Plus I figured simplicity would be key with these guys...

Can you guys give me your definition of the difference between verificaiton and validation? That seems to be a real bone of contention.

David- thanks for the stuff you sent. I just skimmed thru it, but it looks like it will be helpful.

Thanks.

FG

Hiya FG...

FWIW... these are how I am defining verification & validation:

Verification - matching the output process to the design specification to ensure specs are met.

Validation - testing the physical output to ensure it meets the established design criteria & specifications.


Make sense? I can try to elaborate with examples if you like.

Cheers!!!

Hi
I have gone through ur design data sheet. But i could not understand whether this sheet is used to review ur product design in case of any abnormality is observed on shop floor or its regular design review format.

Please let me know in details what problem ur facing and how actual user want to change the system. Being QMS professional our motive is to make user friendly system and a system which looks very good but not friendly to actual user.

If u send me more details and process flow for this system i will try to resolve ur problem.
Kapoor

Fire Girl,

Perhaps I'm reading into your Tool makers concerns, but let me ask a few questions.

If I understand correctly your tool maker probably receives a request for a new tool (Through what media? - email, a paper doc, phone call, etc.). If that is true, then that is your record of the "initial design review" and input definition.

If the tool maker initiates further discussions with the requestor (once again via email, phone, etc.) then that is your design input review (obviously a record of the phone calls would have to be documented somehow), but some designs are going to be simplistic enough that a formal review is not necessary (and your process should state that).

Create design should be easy, if the tool maker has the design documented somewhere (which I would hope occurs, else all that info is lost and has to be regenerated every time). To meet the requirement all that is necessary is to ensure that the media used for documenting the design is somehow dated (maybe electronic timestamp for e-media).

Output review and verification are accomplished in a single step by the toolmaker looking at the design document and ensuring that he has captured what was required. For audit purposes how is this proven: Did he continue to manufacture the tool? (If yes, reveiw/verification were acceptable; If no, then he must have made changes to the document.)

Why would he have to add a step in each of these cases to document all of this activity on a separate document, other than for the ISO auditor's benefit? If there is no other reason, then your system should somehow recognize what is being done without that separate step. Your NOT in business to please the ISO auditor!

Any current thoughts, folks?

In my last position, I had a similar "issue". He was an old school engineer who couldn't shake the thought that ISO was the flavor of the month. I couldn't convince him, but eventually I gave up. I realized that he was ALREADY doing all of the necessary steps; he just wasn't documenting them very well.

Instead of teaching this old dog a new trick, I used his current practice to show him what all of those ISO terms meant. "Inputs" are those details you write down in your ragged wire notebook while you are on the phone with a customer. "Outputs" (for our case) are the drawings, BOMs, and any instructions written when you are done (which could be identified as goals up-front). "Reviews" were done pretty much every day when this engineer and the production manager had lunch together. "Verification" was when he hobbled out to the production floor and checked to be sure that the assembler built it right. "Validation" was (for our case) when the customer called back and said Yea or Nay.

All of this could happen in a day, or 6 years, depending on the project. So, in order to harness the minor ISO stuff required, I gave him this attached (?) form to complete as a plan, which acted as a project folder cover page, too. He could pull out a folder, no matter what stage it was in, and identify important dates and information.

Of course, the critical part was the discussion.
Old school engineer = at least a year of discussions
Toolroom guy = Good bloody luck!

David

Can you guys give me your definition of the difference between verificaiton and validation? That seems to be a real bone of contention.

FG

Verification = Determining whether the design meets what the customer asked for (requirements).

Validation = Determining whether the design meets what the customer wanted (needs).

The difference resulting from performing these two actions is the stuff the customer forgot to / didn't know to ask for, most often from a user's perspective and not from a performance standpoint.

The best example I have/use for the design control processes is baking a cake:
Plan - the recipe
Inputs - the ingredients
Outputs - the cake
Design review - checking the stages of the consistency etc.
Verification - added all the ingredients, oven and correct temperature.
Validation- eating -the real test.