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.
Wednesday, December 16, 2009
Monday, December 14, 2009
Perfect Execution or The Perfect Plan
I read a white paper some years ago, published by a well known global consulting firm, which stated something similar. The hypothesis, which was successfully argued, was that, "Perfect Execution delivers better results than a Perfect Plan."
The fundamental process for Lean Six Sigma (LSS) is DMAIC - Define, Measure, Analyze, Improve and Control. The essence of the American Express article is that, in corporate America, we sometimes get bogged down in the Analyze phase of any launch or implementation. We sometimes feel we need to know the minutiae of detail before we feel comfortable taking the risk of launch/implementation.
The fact is, that without risk, there is no reward. Referring again to LSS methodology, being risk averse completely bypasses the Improve phase of the DMAIC process. Beta testing, used by the IT industry, is in essence, a Pilot Project - something that is often used in the Improve phase of DMAIC. The purpose of pilot testing is to gather information not available by any other means. In other words, you are launching/implementing without all the data you need.
Collection of the data gathered by the pilot/beta test, allows you to tweak your process/product so that you can Control (read as "sustain") results and at some future date, Validate (another key component of the LSS methodology) the process/product.
Given this argument, it is far more important that the pilot/beta testing, be executed flawlessly. Execution is the most critical factor. Disciplined execution will provide all the data that is needed and much that was unexpected and which can also be used. It also places trust in the end user of the product or process, which gives them "skin in the game." This kind of leverage drives both the success and sustainability of the implementation/launch.
When doing investigations, which often use LSS tools (Fault Tree Analysis), it is far better to execute robust Root Cause Analysis, and appropriate Counter Measures, than it is to try and find every little reason why the Loss Event occurred. This approach (the perfect plan) can soon become counter productive. I'll share more on this in a later post about Draining The Pond. In the meantime, think about what will get you the results you desire...
Perfect Execution or The Perfect Plan.
The fundamental process for Lean Six Sigma (LSS) is DMAIC - Define, Measure, Analyze, Improve and Control. The essence of the American Express article is that, in corporate America, we sometimes get bogged down in the Analyze phase of any launch or implementation. We sometimes feel we need to know the minutiae of detail before we feel comfortable taking the risk of launch/implementation.
The fact is, that without risk, there is no reward. Referring again to LSS methodology, being risk averse completely bypasses the Improve phase of the DMAIC process. Beta testing, used by the IT industry, is in essence, a Pilot Project - something that is often used in the Improve phase of DMAIC. The purpose of pilot testing is to gather information not available by any other means. In other words, you are launching/implementing without all the data you need.
Collection of the data gathered by the pilot/beta test, allows you to tweak your process/product so that you can Control (read as "sustain") results and at some future date, Validate (another key component of the LSS methodology) the process/product.
Given this argument, it is far more important that the pilot/beta testing, be executed flawlessly. Execution is the most critical factor. Disciplined execution will provide all the data that is needed and much that was unexpected and which can also be used. It also places trust in the end user of the product or process, which gives them "skin in the game." This kind of leverage drives both the success and sustainability of the implementation/launch.
When doing investigations, which often use LSS tools (Fault Tree Analysis), it is far better to execute robust Root Cause Analysis, and appropriate Counter Measures, than it is to try and find every little reason why the Loss Event occurred. This approach (the perfect plan) can soon become counter productive. I'll share more on this in a later post about Draining The Pond. In the meantime, think about what will get you the results you desire...
Perfect Execution or The Perfect Plan.
Friday, December 11, 2009
A Writer Writes!
I have a favorite movie. It is a dark comedy starring Billy Crystal, who plays Larry, a bitter and frustrated would be author, teaching creative writing at the local community college. The movie is a hilarious dark comedy, but that's not the point of this post! At the end of each class session portrayed in the film, Larry finishes his class session by stating to his students, "A writer writes!"
I am currently in the process of studying a book. I say studying because at first I just read it. The book is entitled, "How To Run Seminars & Workshops," (Robert L. Jolles, Wiley, ISBN 0471715875). There is a section on writing, which states, "Planning to write is not writing. Thinking about writing is not writing. Talking about writing is not writing. Researching to write, outlining to write - none of this is writing. Writing is writing."
So now I have two paragraphs in this post about writing. Why, one might suppose, is that? Well here it is: You can execute an Investigation. You can do it using Fault Tree Analysis or some other methodology. You can identify Root Cause and the appropriate Actions to mitigate the Loss Event and prevent it's recurrence. You can involve SMEs and your Investigative Team members. At the end of the day, you will have to document your findings. For many people, this is sometimes the worst possible aspect of an investigation, made more so when the summary requires approval from various parties, each of whom has their own opinion as to style and grammer, and which can reject your summary for tawdry edits that often don't make sense.
There are a million reasons why we don't like to write. However, at the end of the day, if we do not write at one point or another, the investigation is incomplete. In order to truly complete the investigation, it needs to be "wrapped up in a bow," through documenting (read as "writing") the investigation.
Lead Investigators, or at least a member of the Investigative Team, is typically a writer. And the Root Cause Analysis, must be documented and summarized so a record exists for review in the future. If for nothing else, to enable prevention of the same issues in the future. You may not feel like your documentation is up to par, and perhaps it is not. At least not now. But the more you write, the better you get at writing.
Over the course of a 26 month period, I documented 115 Investigations, all requiring full Root Cause Analysis. Many suggest that I am an expert. However, I contend, if that is the case, it is only through the continued practice that took place from writing so many investigative summaries in so short a period of time. Anyone can develop this skill set if they have a mind to. It's not difficult, although you have to toughen up your hide and accept feedback from time to time. But this is no problem if you truly wish to excel. The key thing to remember is...
A writer writes!
I am currently in the process of studying a book. I say studying because at first I just read it. The book is entitled, "How To Run Seminars & Workshops," (Robert L. Jolles, Wiley, ISBN 0471715875). There is a section on writing, which states, "Planning to write is not writing. Thinking about writing is not writing. Talking about writing is not writing. Researching to write, outlining to write - none of this is writing. Writing is writing."
So now I have two paragraphs in this post about writing. Why, one might suppose, is that? Well here it is: You can execute an Investigation. You can do it using Fault Tree Analysis or some other methodology. You can identify Root Cause and the appropriate Actions to mitigate the Loss Event and prevent it's recurrence. You can involve SMEs and your Investigative Team members. At the end of the day, you will have to document your findings. For many people, this is sometimes the worst possible aspect of an investigation, made more so when the summary requires approval from various parties, each of whom has their own opinion as to style and grammer, and which can reject your summary for tawdry edits that often don't make sense.
There are a million reasons why we don't like to write. However, at the end of the day, if we do not write at one point or another, the investigation is incomplete. In order to truly complete the investigation, it needs to be "wrapped up in a bow," through documenting (read as "writing") the investigation.
Lead Investigators, or at least a member of the Investigative Team, is typically a writer. And the Root Cause Analysis, must be documented and summarized so a record exists for review in the future. If for nothing else, to enable prevention of the same issues in the future. You may not feel like your documentation is up to par, and perhaps it is not. At least not now. But the more you write, the better you get at writing.
Over the course of a 26 month period, I documented 115 Investigations, all requiring full Root Cause Analysis. Many suggest that I am an expert. However, I contend, if that is the case, it is only through the continued practice that took place from writing so many investigative summaries in so short a period of time. Anyone can develop this skill set if they have a mind to. It's not difficult, although you have to toughen up your hide and accept feedback from time to time. But this is no problem if you truly wish to excel. The key thing to remember is...
A writer writes!
Subscribe to:
Posts (Atom)