Dear Design Engineer: I know you won’t read more than a few words of this, so I’ll get straight to the point.

Design planning is for your own good.

You can go back to what you are doing now, unless you want to know why.

My Design Story

You see, Design Engineer, I used to be a product design guy. This was a formulation industry and the product was a compound with a formulation which had some expected performance properties.

The sales department would come to me with the customer requirements.  I would prepare a preliminary formulation for quoting purposes, and if that was in the ballpark, would launch a project.

We’d do a couple of prototype batches, and if we saw one we liked, we’d send a small sample to the customers.

If the customers liked it, and the Sales Department thought it would work, and the pricing model worked, we’d try a plant batch or two in order to see if we could mix it. There were big mixers.

We’d send those batches to the customers, and if the customer liked it, we’d get a trial run order which was a little bigger. Sometimes, at some point, we’d get progressively bigger production-scale  orders.

At first it took several trials for me to get one to work, but as time went on, I got fairly proficient. There is an element of art to this.

The Plant Trials

I made it a practice to go out into the plant and monitor the run personally. I didn’t really have anybody to delegate the job to.  The material we made was process-dependent, that is to say, if the plant got the order of operations wrong, or screwed up the mixing conditions, the material didn’t meet the spec.

So I got an unhealthy exposure to polycyclic aromatic hydrocarbons,  as well as some dust. This is what the  business was. I had to make sure it was right.

Production Scale

So at some point, after we were confident everything was fine, we turned it loose to production, and some fraction of the time, it stopped “working.”

Why? Well, there are plenty of technical theories, which I won’t bore you with, but suffice it to say, that something changed.

What happened after that? The Blame Game.

The Blame Game

The plant manager at the time, who was entrenched and mediocre,  would call us all into the office, and basically say “It’s not working, it must be your fault.”

Side point, but important, was that this operation generated a lot of free dust, and you could tell who had been in the plant by who left footprints and there were never any footprints leading behind his desk.

Anyway, I would say, “It ran fine every time I followed it personally. How is it now that I didn’t follow it, it stopped working?  When your people mixed it without me looking over their shoulder it screwed up.”

It was like that every time. It wasn’t especially productive to argue. The plant manager was convinced it was my “fault” even when I went back out into the plant, re-mixed the material with me watching it, often it worked brilliantly.

Do-Over

This of course was in a non-ISO environment, years ago. If I had to do it over again, I would insist that the production department and also the plant manager sign off on the last set of test results (which we would call the verification step) and agree in writing that the material was fully “developed”, and take ownership of any subsequent screwup.

If, then, there was a problem there would at least be less “finger pointing.” I’d have said “you signed off on it, it must have been OK.” What that would have touched off would have  been higher scrutiny on the part of plant supervision, but that still would have been preferable.

It would have been a way to prove I did my job right.

So even though it would have been a nuisance, and slowed me down slightly, I would have been better off. The plant may have eventually started resisting some of these projects. But the whole development experience would have been better for me, and presumably we would have been better as an organization.

Captain Hindsight wins again.

Shared Consequences

So the moral of the story is, or was, that the ISO design requirements are all about communication, and otherwise protecting the Design Engineer. It’s a way for the organization to agree on the question “is the design good or not good” and the attitude toward the process would have been much healthier.

So, Mr. Design Engineer—

This ISO requirement is for your own benefit. I have lived this situation, and can assure you this is a better way.

Now, aren’t you glad you read this?

Sincerely

Jim

PS: Did you know I am author of a course on Udemy?

https://www.udemy.com/course/how-not-to-fail-at-iso9001/learn/lecture/34733460#content

And I will gladly share my vast experience at getting beaten on by production. Click my info.

https://jimshell.com/quality-systems-training/: Dear Design Engineer:

www.jimshell.com

Loading

Tags