Tag Archives: production

Lean Manufacturing: Weighing Theory vs. the POF

Many years ago I was in graduate school at Carnegie Mellon University, and signed up for the Ph.D. qualifying exams, “quals”, to be admitted to the program officially (I wrote about why I left the Ph.D. program a year later here). One of the topics available to be tested on was Manufacturing. This exam, for the most part, consisted of the panel holding up things and then asking you to come up with a way to make it. For the better part of two months after I signed up for the quals, everything I looked at was examined, considered, dissected, and mulled over… to the point where everyone I knew was sick and tired of my ruminations over salt shakers, paper clips, tires, and everything else I saw.

Binder Clips and More

So I stepped into the spotlight, and one of the panel members held up… a binder clip. I spent the next 30 minutes hypothesizing a way of making binder clips. As it turned out it was not the way – they enlightened me as to how they’re really made at the end of the session – but I’d come up with a viable method nonetheless. Since I still had 20 minutes, I was then quizzed on other things, including Lean Manufacturing.

One of the things “in the air” at the time was a discussion of Work-In-Progress, or WIP, and how there should – in theory – be zero WIP at any point in the line. The idea was that WIP would insulate bad processes from being found. Theory also stated that idle inventory that couldn’t be sold was not, in fact, an asset but a liability representing cash tied up (which I agree with). So, drive it to zero, let the problems come bubbling up, and then work to eliminate them. Fine and dandy, but doing so very likely would result in disruptions in the flow of products off the end of the line.

This prompted one professor to then ask “What about the customer’s POF?”


After asking what that acronym stood for, he said “Pissed Off Factor.” On the fly I discussed how the theory called for zero WIP, but the reality of most production these days was one where the customer worked to have replaceable suppliers – and so the supplier needed protection to ensure retaining the customer. My belief was that there should be some WIP and some end-of-line inventory to insulate the customer from any hiccups that might happen as the line was brought into a Lean state.

I passed the exam; but the cognitive clash between theory and practice led to my coining this quotation:

In theory, there is no difference between theory and practice. In practice, there is.

Fast Forward to an Application

While at Ford Motor Company in Sandusky, Ohio, I was tapped to be the initial Lean Champion in first bringing in Lean concepts to the plant. After doing some independent studying including reading the book The Machine That Changed The World, taking a course or three which included tours of several “showcase” companies willing to let people see what they were doing, and hearing the seminars by the Lean consultant hired by the company – a Professor from MIT who had won the Shingo Prize, among others – and who had developed a comprehensive set of Lean Guidelines for our use.

We were in the initial stages of designing the production lines for the Ford Focus headlight and, following hot on that, the newly-restyled Ford Taurus / Mercury Sable headlight. Although an initial line layout had already been done, I got permission to consider a total revamp. Thus, I got representatives from Industrial Engineering, the Equipment group, the New Model Launch Engineers, and so on, and locked them in a room with that MIT consultant for a one-day concentrated Lean course. The next day, with that consultant acting as a co-facilitator with me, we worked on trying to develop a new layout incorporating lessons from the seminar.

Mirror, Mirror

The result was astonishing. While I can’t, for confidentiality reasons, go into enormous detail, one key “earthquake” in line design philosophy made an enormous difference with multiple consequences. Until that moment, all lighting lines were set up with a two-shift philosophy: one shift would run right-hand lights, another shift would run left-hand lights. By definition, two shifts were required to send matched pairs to the assembly plants.

This earthquake-level shift was simple: two back-to-back lines running left and right hand lights simultaneously. Every pass through of the concept yielded further ripple effect improvements, in many respects coming from the functional doubling of TAKT time for each line. In the end, we saved over $1 million in capital equipment costs and reduced labor content by over $100K per year. Plus the duplication of the lines into back-to-back cells ensured capacity, even if reduced, if there were an issue with any of the critical equipment – an option not present in the “one big line” layout.

Square Pegs, Round Holes

One of the fundamental things taught was that in an ideal Lean line people act as the conveyor. A part would be taken out by a person, the next part put in, and the person would then carry the finished part to the next station. In the meantime, the machine would perform the operation and verify its own work. I came to admire the idea of autonomation, the term I learned for where the machine not only did the value-added actions required but then verified they had been done correctly. The idea being simple: zero defects passed on to the next station.

Because of the positioning requirements for several assembly operations, however, there remained an asynchronous pallet system. On top of that, some of the components, e.g., a wire spring, were exceedingly difficult to conceive of an automatic system to be able to install them. We did a cost-benefit analysis and it ended up being far, far more cost effective to have a stationary person working to do the component assembly than to develop a super-duper-and-by-definition-custom piece of equipment to accomplish the task. For these stations we did build in Poke Yoke capability instead of having the station downstream from the value-added operations; again, done under the idea of checking the work then-and-there, thus eliminating the risk of passing on a defect.

I made a pilgrimage to Dearborn to report to the company’s Lean Group about our progress. In attendance was that MIT consultant, whose reaction was totally opposite of what I expected. Showing enormous capital and labor savings, I expected our team to receive accolades; instead, that consultant blew up because we had not followed all of his guidelines to the letter.

Some people “got it” but some didn’t: Lean – like any discipline such as Theory of Constraints (which I still believe in whole-heartedly) – requires intelligent application, not mindless application of The Rules even when they don’t make sense.

Sanity Stock

As the line design and construction proceeded, I stepped aside as expertise spread and a more formal team formed. Comprised of representatives from across the company on a co-location assignment to watch and shepherd the development and implementation of the new lines and then take the knowledge back to their plants, they did an admirable job. And I was glad to be freed to pursue other projects. But I did still have one last contribution to make.

Theory said that parts should be packed and then loaded straight into the waiting truck. No WIP. But I asked “What can go wrong on the line?”, as in a serious disruption of production flow. The robot, which poured the glue joining the lens to the housing, was the most common piece of equipment that went down. “How long until it’s repaired?” Mean-Time-To-Repair was, IIRC, three hours. So I proposed we have a four-hour rolling stock of finished goods to protect us from such events.

From the shocked look of most of the team, and the horrified reaction of the MIT consultant who had come down to review the area, I must have been proposing we turn the entire plant into a flower farm. You could almost hear the scorn as they repeated the word: INVENTORY?

But there was a method to my apparent madness. Ford charged suppliers who didn’t deliver on time a staggering amount per minute that the parts were not there. Suppliers had been bankrupted that way. I argued that the carrying cost in both sunk cash, and space, was minimal compared to the consequences if we failed to deliver on time. I presented the math: the carrying cost of four hours of inventory vs. the financial consequences if we didn’t deliver on time. After all, it was not a matter of playing the odds. The robot would go down sooner or later, and without that inventory we would fail to deliver on time.

And the Winner Was…

After much debate, practicality won over theory. We had rolling inventory of finished goods at the end of the line.


  1. Lean is a great thing, but do it intelligently considering the uniqueness of your situation
  2. Rigid adherence to every guideline is a guarantee for failure
  3. Include a consideration of the POF in every decision


© 2014, David Hunt, PE

Fix the Problem IX: Three High-Scrap Issues on a Product Family

In Fix the Problem VIII I introduced a simple concept, requoted here:

You can only claim to have truly solved the problem when you understand it well enough to turn it on and then back off again.

I want to discuss three production problems, all on the same product family – but with three different root causes.


While working on a cost-reduction team at Ford Motor Company that focused on material and labor savings on existing products, we would occasionally be called upon to act as extra eyes on specific problems in the plant. I was asked to look at three different radiator lines and their “high fin” scrap rate.

Let me define “high fin”. In automotive radiators there are thin, flat tubes that carry the radiator coolant from one header tank to the other; heat gets conducted through the tube walls and into the corrugations made from thin aluminum sheet. This sheet – really an aluminum ribbon – is transformed into the corrugated fins by use of a star-shaped wheel that acts as a mandrel to form the up-and-down corrugations. Functionally, these fins wick heat from the tubes of hot coolant and provide a large surface area for moving air to remove heat from them, thus providing a heat sink.

These fins, in turn, are placed between the flat tubes; the headers that formed part of the coolant reservoir and manifold (which evens the flow distribution between tubes) are placed, the assembly compressed, and steel clamps put on to maintain the tension until the radiator is brazed. As a part of the brazing operation, there is a wash with soapy water that sprayed down onto the radiator face to remove grease and other contamination prior to the braze heat being applied.

In each of these products, fins were being knocked loose from between the tubes and then brazed in that out-of-position position. This was not repairable, resulting in a piece of scrap and a brazing cycle wasted.

First Steps

In all three cases I got the last three months’ worth of scrap data to look for trends, and had scrap items put aside at the end of the line for me to look at, with the time and date of the exit from the braze oven written on them. I also had an intern temporarily assigned to me, and had them – on one shift per day (ideally this should have been for all three shifts, but it wasn’t practical) – watch the radiators going into the braze oven to see if we could determine where in the process stream from raw material to end product the defects were occurring. (Note: no high fins were seen going into the braze oven; this point, first made in Fix the Problem II: Medical Blister-Pack Punctures, is important – knowing where a problem starts to be seen can be a critical clue in identifying the root cause.)

Radiator One

This particular instance is shown on a portfolio page, here.

The most important thing was that over the last three months the fallout rate was getting worse. Something was clearly going in the wrong direction, so I started here. The next thing was that I put the radiators in a row, by time and date. I also graphed the data; my hope was to see if there were any shift dependencies or pattern in the locations of the high fins. They appeared to be random in both time and location.

Time for basics. What holds the fins in place until they’re brazed?

Looking at the prints there was an interference between the nominal fin height and the gap formed by the tubes. In other words, after the fixture compressed everything, the fins were compressed like springs, pushing against the tubes with friction holding them in place (thus the need for the braze bars to hold the compression). Clearly, something was not holding them in place, and not doing so in an apparent random fashion.

I polled some colleagues about the problem to get outside perspectives. What could be causing this? We did an Ishikawa fishbone diagram, went through a few Five Why exercises, and the dominant factor implied something was awry dimensionally (something could have changed in the material, too, but this seemed the best first-guess approach especially as there were similar products with no issue); so what dimensions would be critical for this function? I had a pretty good idea, of course, but I wanted other minds’ input to make sure I didn’t miss anything. The consensus was that three dimensions were the critical ones:

  1. The center-to-center distance on the aluminum headers into which the tubes were inserted prior to brazing.  This was an inspected dimension.
  2. The outside-surface-to-outside-surface of the flat tubes.  Again, this was an inspected dimension.
  3. The top-to-bottom distance of the corrugated fins.  Once more, this was an inspected dimension.

But what did the data say about these? For the header dimensions and the flat tubes, these were spectacularly consistent, with high process capabilities as indicated by their CpKs. But the fins were another matter.

We had a laser system that would measure the peak-to-peak dimensions of the corrugations. The way it worked was that a fin would be put in, and the data would be aggregated into an average and recorded. I wanted the raw data, and measured several fins and then graphed them: height as a function of position along the length of the fin (which comprised, perhaps, 80-100 peak-to-peak dimensions). And then I stared at those graphs.

Sometimes, all that’s necessary to solve a problem is “sit and stare” and let intuition and your subconscious work. In a EUREKA! moment I said “There’s a cycle in there.” So I took the data and – manually – did a best-fit sine wave, finding that the height of the fins was going up and down with a cycle every 26 corrugations.

Clearly the flat ribbon coming into the fin-making machine didn’t have a pattern in corrugations; there no were corrugations at that point. Similar to my example, here, I “walked the line” to find where the corrugations were formed by the fin machine. Then I went to the maintenance guys, those people who knew the equipment, showed them my sine wave, and asked what might be causing the 26 cycle. Immediately they replied “the star wheel”. The star wheel was what formed the corrugations, having 26 teeth.

Fortunately, the maintenance foreman was a sharp cookie; he had the machine shut down and taken apart. What they discovered was that the bearing on which this star wheel rotated was deteriorating, and said deterioration was introducing an eccentric motion as the wheel spun while it formed the corrugations. The bearing was replaced, everything aligned, and we started up again.

I redid the measurements – no cycle at all. CpKs were much better. Most importantly, high fin scrap fell to zero. To prevent this from happening again, the fin measurement procedure had an alert callout added for when the CpK started to drift above a given limit; standard SPC practice to alert the technician that the process was going out of control. The machine maintenance plan was also modified to include periodic alignment and bearing checks.


  1. Averages have their uses, but lots of information can get washed out by relying on them without examining the raw data.
  2. Using the five-why process, in this case to drill down to dimensional variation (a basic engineering fundamental), was instrumental in identifying the root cause.
  3. Intuition again played a key role, as did leveraging the different perspectives and experience sets of other people.
  4. Identification of where the problem was happening – somewhere inside the brazing process – was also a key datum.

Radiator Two

Unlike the first radiator, there was a definite and specific location to the high fin: it always happened right next to the side-rail Z-notch that was in the top and bottom rail forming the outside of the radiator, and it did it across all shifts; nor was there any change over the months indicating this was a chronic problem. Let me discuss the Z-notch.

The side rails were aluminum C-channel rails whose long center flat was brazed to the fins. In each rail was a stamped cutout, called the Z-notch. It created enough structure for handling and processing, but at the end of the line, the remaining material would be cut so that as the radiator heated and cooled there was a place in the rail allowing it to expand and contract freely – like heat expansion joints in a bridge. The high fins in this case were always, always, always at this location.

Since this problem was not observed across other lines, the question to answer was “What’s different?”

This ended up being very simple; I went to the prints – usually my first stop in any problem-solving exercise. Was the material different? No. What about other parameters? The length, one of the things that defines the stiffness of a beam, was “in the pack” of other side rail lengths. Nothing sticking out there. And the cross-sectional dimensions of the C-channel were identical to the others as this raw material was used across virtually every line. But as it turned out, the Z-notch was a different design than the others.

Looking at the geometry, the stiffness of the remaining material at this joint – the moment of inertia that quantified the stiffness of that rail at that point – was less than half what it was in any other design. In essence, that lack of stiffness formed a hinge point, allowing the forces from the compressed fins pushing outward to deflect it more, thus lessening the retention force on the fins – so that the force of the cleaning spray could knock it out.

I checked downstream with the operation to see if changing the Z-notch would impact them; no. I then approached our Design group, pointed out the differences, and asked if we could do a trial run with a standard Z-notch design. A week’s worth of test pieces were made, the appropriate trial forms signed, and a run was made. High fins disappeared with no impacts downstream – as checked for beforehand. Based on my findings and the successful trial, an ECO was written.


  1. In looking at a problem occurring on one product of a multiple-product family, the very first question while working through the possibilities should be “What’s different?”
  2. As with the dimensional analyses above, engineering fundamentals – in this case, an application of my Strength of Materials course – were essential to understanding the issue.

Radiator Three:

As with radiator two, the high fins would always occur right next to the side rails. However, there was one key datum that stuck out: they only happened on one shift out of three. One compression-assembly machine, but – obviously – three different operators. Therefore, in Ishikawa parlance, the likelihood was that it was a man (of man, machine, material, method, measurement, mother nature) that was the first thing to be investigated.

Under the guise of “just poking around” I stayed late on the second shift to watch the operator out of the corner of my eye. He, like the others, worked diligently… but there was one key difference in how he worked. (“What’s different?”) All the other operators would place the radiators on the conveyor belt, while he dropped them. But although he was dropping them, it was only from a few inches.

Getting permission from the foreman on the first shift, I did a few tests to drop the same radiator onto the belt. And nothing. This was interesting. I did some drop tests with other radiators, and nothing there as well. Clearly the drop was a difference, but not the determining difference.

So I talked with the operators; asking “What’s different about this radiator?” I was thinking that there might be some subtle difference, but all the operators I spoke with, on two shifts, had no comments. A review of the prints didn’t show anything obvious. And a key question, which had to be handled very diplomatically, was “What was different about this operator?”

As it turned out, he was a new hire, having been brought on within the past year; all the other operators were veterans with years of experience. Why did this make a difference?

As I’d mentioned in the introduction, steel clamps were put on to hold the tubes and fins compressed until the brazing operation could fuse them together into a solid piece. In talking with the operators, one casually mentioned that the clamps, called braze bars, had to be installed through small positioning notches in the C-section side rail, and had to go through both sides. If they didn’t go through, placing them on the conveyor could create a force that could distort/damage one of the C-section sides “especially if the radiator were dropped” since they were always put on a conveyor with the braze bars underneath the radiator. AHA!

I spoke with the second shift foreman, who had a discussion with the operator. He was not aware that the braze bars had to go through both sides of the side rail notch. Most of the time he got it right, but sometimes he didn’t – and not knowing how critical it was – would then drop the radiator on the conveyor. (Likely he had been told but merely forgotten.) The impact of the drop would be passed through the misaligned braze bars, distorting the side rails and allowing decompression of the fin.

This was the missing element. After being made aware (again, more likely reminded) of how critical this was, along with an explicit instruction to place, not drop, the radiator, the issue went away. I did design plastic lead-ins and got them mounted on the machine as a trial. The theory was that an operator could put the braze bars into the lead-ins and literally drop them in; the lead-ins would align everything so that the operator could not do it incorrectly. It worked, but the operators didn’t like them so they removed them.

  1. When faced with a shift-dependent problem the very first thing to be considered should be operator error.
  2. Had this not been the root cause, some kind of environmental issue – would have been the next thing to be considered; since things like temperature, light level, and being aware/awake can be affected by shift schedules, even when people are accustomed to their off shift schedule.
  3.  The ideal solution, when faced with an operator-dependent problem, is to engineer it out.  But all the best efforts are naught if the operators don’t like the solution and remove it.

© 2014, David Hunt, PE

Fix the Problem XIII – The Problem Toggle

(Author’s note: The “L” key on my computer – old one, new one finally ordered – was not working, and I missed it while posting this.  Apologies for the multiple revisions getting all the Ls into place in the title and link…)

While at Ford Motor Company, our group’s manager found a book that he thought was so good he recommended it to everyone, and even paid for our individual copies.  This book, Manufacturing Solutions for Consistent Quality and Reliability, was excellent.  But the book made one fundamental point about problem solving – whether in performance of a product or a process – that has stuck with me ever since (paraphrased):

You can only claim to have truly solved the problem when you understand it well enough to turn it on and then back off again.

With this in mind I’m going to review two instances from my career where this happened.  (I will revisit this theme in future essays to discuss more case studies.)

Plasma Cutting Torch: Mysterious Leaks in the Field

This particular torch was part of a plasma cutting system; I was the Manufacturing Engineer in charge of the torch area, and working on identifying the root cause of field failures was one of my responsibilities.  This particular torch had a significant rate of return; these returns, responded to by sending a new torch, was a large part of my department’s total warrantee cost.

The issue was that the problem could not be duplicated. We would receive the torch which, according to the customers, would have coolant leaking out the front “business end” of the torch.  No matter what we did, we couldn’t get returned items to do it in our lab.

Lesson One: Unless you can duplicate the failure, in order to experiment with what does and does not trigger it, you are flailing in the dark.

So one day we get a torch back where we’ve been told the coolant is gushing out in a waterfall.  We go to our own test machine, connect everything up, turn the coolant flow on… and nothing (like always).  We exchange parts of the system for new ones.  Nothing.  Go back to the original, returned pieces.  Nothing.  Try as we might with permutations of new parts and returned parts, we cannot duplicate the reported failure.

Let me take a moment to say that I trust intuition.  Something was nagging at the back of my mind.  I couldn’t even quantify it, but something was bothering me.  Just as the technician was about to turn off the coolant flow, I said “Hold it, I want to try something.”  I reached over to the torch, grabbed the retaining cap that threaded on and which held everything inside, and started to turn and loosen it.  I had barely touched it when coolant started to jet out of the opening.

I tightened it.  Nothing.  I started to turn it, and again, coolant flowed copiously.  AHA!  I tightened it to its hard-stop and made a mark.  Then I slowly started to loosen it until, like a floodgate opening, the flow started again.  I marked that too.  It took, maybe, a 0.25” of distance, as measured on the outside diameter, to make this difference.

Armed with this information I went to the prints and calculated that – going from memory – the axial translation of the cap being unscrewed was on the order of 0.020”.  This information was passed to the Design group, which found that the issue was design-related (details omitted for confidentiality reasons).  Designs of a few, key components were tweaked and prototypes made.

The result: The redesigned torch wouldn’t leak despite backing the cap off double what I had done.  After the change, warrantee returns started to drop dramatically as the redesigned torch was propagated into the customer base.

Lesson two: Intuition and hunches are often based on a subconscious stew of disparate facts coming together.  While you shouldn’t just go with them – a systematic approach like an 8D Problem Solving Process is needed – don’t ignore those tickles at the back of your mind.

One other thing to note.  In retrospect these symptoms and the “no problem found” status made sense.  Plasma cutting is often a dirty environment with grit, metal chips, etc., around.  Likely what happened is that people took off the cap while changing the consumables – the “razor blades” – putting it down in such a way that grit got onto the surface that was supposed to be flush with the surface that provided the hard stop when installing the cap.  This created an inadvertent shim that coupled with the design issue to create the leak.  In the process of being shipped to us the grit would fall off, removing that inadvertent shim and resulting in a torch that would function as intended with no problem.

Lesson three: When troubleshooting, think about the environment where the failure is occurring.  Ideally, go and watch.  There’s nothing like seeing the precise situation for generating data, even if that data only goes into the aforementioned subconscious.

O-ring Rollout: Leak Failures in Manual Assembly Area

At the same plant where I first was given this book, one of the products was a carbon canister assembly that fitted into the fuel cell.  Functioning to absorb gasoline vapors coming off the fuel tank for emissions control, some of them had several hoses with male attachments that would be inserted into a female port.  The work time standard was strict and people pushed hard to meet it.  (Note that I have a portfolio page about this problem.)

At issue was the fact that the O-rings forming the seal at these ports would roll out of the groove they were in, creating a leak path.  This assembly defect was internal to the female port and so was not visible.  The first indication there was an O-ring rollout was that the unit would fail the leak test.  The unit would then be methodically disassembled until the rollout was found.  Then it was reassembled after reseating the O-ring, and retested.  As you might imagine, this was quite time-consuming (not to mention not value-added).

Having been asked to look into the problem, one of my first actions was to look at the Design Guidelines.  Since my Master’s Research was in Design for Manufacturing and Assembly, I had – stated immodestly! – a pretty good grasp of the dynamics of how things go together.  One thing I noticed was the design of the lead-in.  Although “perfect” from a molding standpoint, having a radius as a lead-in was not so great from an assembly standpoint.  The reason being is that the O-ring needed to slide along the surface without being “grabbed” by friction.  The governing equation is:

Arctangent(angle) < coefficient of static friction

With a visual:

angle image

Note that in no case will an angle greater than 45 work.

What I found, in a detailed examination, was that it was possible to misalign the male insert sufficiently so that the O-ring would hit on the part of the radius where static friction would dominate.  This would then “grab” the O-ring and, as the insertion progressed, it would roll out of the groove.

In a Design for Assembly analysis I’d written before on my blog I referenced Fitt’s Law.  I applied it in this case and found that it was a difficult task for a person to do reliably – which explained the high rework rate.  If I redesigned the lead-in to be a 30 degree chamfer, as shown in the portfolio page (referenced again for convenience), I essentially made it impossible to NOT get the O-ring on a sliding surface.  (NB: a 15 degree angle is my “perfect” recommendation for this situation.)

Lesson Four: Very often there is a Design issue at the root cause of a production problem.  Not always, of course – but in my experience the probability has been very high that Design is a contributor to the issue.  Note that Design is the foundation: Reliability, Functionality, and Quality all start with Design… one can have production issues even with a good design, but one cannot have good production with a bad design.

Based on my write-up we made an insert for the mold of the female port (fortunately the mold boss forming the core of the port was an insert that could be easily changed!) and tried it.  Leak failures from O-ring rollouts fell to nothing.  But there’s one more lesson… I got a call from the Design group asking me why I was proposing changing the design, including altering the Design Guidelines.  When I asked if he’d seen my write-up, he said yes.  When I asked if there was a problem with it, or with the results showing it worked, he snarled – literally snarled – through the phone: “You’re just a Manufacturing Engineer, what can you know?”.  Needless to say I was tempted to retort, but again returned to the successful results and appealed to his “We’re all one company, right?” spirit.

Lesson Five: People can get very protective of “their turf”; keep that in mind as you propose changes, especially if the changes are in someone else’s department.  (In retrospect I should have involved the Design group from the beginning to have them on the team and involved once I figured out this was a Design issue.  Thus I would have avoided turf battles, toe-stepping, and bruised egos.)

The Problem Toggle

In both instances changes were made that turned the problem off.  In both instances we understood the root cause well enough that if we had gone back to the old design, the problem would have returned… and why it would have returned.  In these two cases there was just one true “root cause”, Design, but in other cases I’ve experienced there were multiple factors that worked together to create the problem.

Only by systematically working through a formal process, often including tools like an Ishikawa Diagram which can be very useful, testing each identified possibility by duplicating the failure conditions to see if the change affected failure rates, can problems be declared solved.

Otherwise, solutions become a variant of “I’ve got everything just right; don’t touch anything!”  And that’s not a way to design and produce in today’s hypercompetitive world.


© 2014, David Hunt, PE