Draining The Pond

My father-in-law owns a farm in Preston, Idaho (famous for the film, “Napoleon Dynamite”). There is a small creek (pronounced “crick” in Preston) that intersects the property and feeds a small pond in the center of the property. The story is sometimes told of when the pond had to be drained.

It seems there was some obstruction to the pond effluent. The pond had a small concrete dam with a steel plate flood gate. The flood gate was opened and the pond drained so the obstruction could be removed. As the pond drained, an old rusty Model A Ford began to appear. Once the water level passed the Ford, and as the pond continued to drain, an old refrigerator was seen. After the pond was completely drained, the Ford, refrigerator and other junk in the bottom of the pond were chained to the tractor and pulled out. The pond was then refilled.

Not long ago, I got the opportunity to drain the pond at work. I was assigned an investigation, the purpose of which was to find why we were not able to correctly account for some units of very expensive product. As I pursued the investigation, it was discovered that the operators had just a few seconds to count over one hundred units of product and that this was done about every 2-3 minutes. The counter measure was to create a template, that would be placed over a tray (or case) of units, to see if they looked correct. Voila! Problem solved.

What?! But, wait a minute! You say that there is still a problem with the accountability? Yep, you guessed it. I was assigned another investigation for the same thing not long after the first investigation. So I dug a little deeper this time. The data I analyzed showed that the templates for counting the units of product worked well on the large units, but because the small units were in presentations of nearly 600 units, it was difficult for operators to tell if the count was correct or not. Hence, the potential for an erroneous count was still there. The counter measure implemented at that point was the introduction of an automated visions system that would use a computer and camera to do the counting, taking out the potential for Human Error. Finally! Glad that’s over.

Hold on now! I just got done fixing this problem. It can’t still be happening, can it? Another investigation assigned for the same thing, yet a few weeks later. When will the bleeding stop? In this investigation, I learned there was a new step in the process for additional testing to ensure oxygen content of the product was less than 1%. Final unit accountability of the product was completed before this step was executed. The problem was that a failed unit would be rejected, thus changing the count. This was not accounted for in the planning phase for implementation of this new step in the process; fixed yet again.

Process improvement is often referred to as Draining The Pond. It is the process of looking for incremental improvement rather than betting on big step changes. As you improve productivity through process improvement, you find other opportunities for improvement. The beauty of Fault Tree Analysis, is that you can capture several gaps in the process – junk in the pond – simultaneously by creating a visual of all the hypothetical gaps.

When I was doing these investigations, I was not disciplined in using Fault Tree Analysis in this way, but it would have helped prevent the non-value added activity of doing multiple investigations for the same issue. That is not to say that Fault Tree Analysis will be the end all, be all for any issue. I have been involved in investigations that used Fault Tree Analysis, which did not capture all the potential gaps for the Loss Event. However, capturing more gaps in an investigation, rather than fewer, is a more efficient way of…

Draining The Pond.