Happy Holidays

I will be on hiatus the last two weeks this year.

Unfortunately, there will be no posts on my blog site until 04 January.



Until then, I wish you a warm and happy holiday season, filled with joy for you and those you love.

All the best.

Douglas E Dawson

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.

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.

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!

Could You Please Show Me Your ID?

The organization I work for requires an ID card to enter the network of buildings that make up our campus. I am a person of routine. My wife often refers to it as OCD, but I prefer to think of it as routine. To some degree, we are creatures of habit.

At any rate, on this particular morning, my commuter vehicle was in the garage for maintenance, so I had to drive another vehicle. I forgot to transfer my parking pass from the commuter vehicle to the one I was temporarily using. I had to stop at the front gate and ask for a temporary parking pass.

"Could you please show me your ID?" the security guard politely asked.

"Sure, hang on a minute," was my reply as I started digging my wallet out of my back pocket. No sooner had begun search for my wallet, that I became painfully aware that my morning routine had somehow been disrupted and I had left my wallet on my dresser. I commute an hour each way and I plead with the guard, now somewhat suspicious, that I for me to run back home for my wallet, would constitute and additional two hours of drive time for me, and two hours of lost productivity for the organization.

Suspicion had evolved to impatient indifference and I was waved on to the security desk at the main entrance. Once I got there, it took nearly an hour to get through all the red tape that would allow me to get to my desk and grind out value for the organization. But I made it. Finally.

What does this have to do with investigations? As you build your Fault Tree Analysis, you need to give each hypothetical cause in your growing tree a value. This value is called a Fault ID. The Fault ID helps investigative team members, approvers and stakeholders understand the relationships of the various faults hypothesized to be potential root cause, as well as potential relationships they may have one with another.

Top line, or First Order hypotheses have a value represented as a whole number beginning with zero or one and progressing from there. Secondary or Second Order hypotheses have a decimal value of one place, such that any hypothesis subordinate to a First Order hypothesis would be as 1.1 for the first hypothesis, 1.2 for the second and so on. Tertiary, or Third Order hypotheses are separated by decimal as a delimeter and follow the same convention as the Second Order hypotheses. In other words, Fault ID subordinate hypotheses to Fault ID 1.1 above, would be 1.1.1, for the first tertiary hypothesis, 1.1.2 for the second tertiary hypothesis, and so forth. This convention is true also for Quaternary and Quinary subordinate hypotheses.

For an example of a partial Fault Tree showing Fault IDs, look at the image below.

When you think of order of magnitude, as you build your Fault Tree, it can become very large and quite cumbersome. This is where the Fault IDs of the various hypotheses becomes most important. Keeping track of these hypotheses, and seeing the potential Interactions that exist are key a successful investigation. Particularly if it is a large scale investigation.

The Fault ID has additional value I'll save for a later post. The point of this post is to explain what, exactly, a Fault ID is and how it is used. Below, you can see an image of what a Fault ID looks like. Just remember that when you are building your Fault Tree Analysis, someone interested in your investigation, perhaps an Investigative Team member, a Stakeholder or an Approver, may ask you...

Could you please show me your ID?

Were You Entitled, or Was The Title Won?

NOTE: The title of this post is also a link to the article referenced within the post.

I recently received a post (see link above) regarding "Learned Helplessness", which is defined as "where people 'learned to behave helplessly, even when the opportunity is restored for them to help them self by avoiding an unpleasant or harmful circumstance.'" Unfortunately, I see "Learned Helplessness" too much in business and community. I believe our culture has evolved from the independent self-sufficiency exemplified by the puritanical contingent of our country's forefathers, to a culture of entitlement (read as "helpless").

I work with and teach others to take ownership for who they are and the results of their actions. This is often times difficult when people have been entitled too long, but told they are performing well (read as "vanilla" not "balanced" feedback) in spite of the evidence of their labors. I have a 2X2 Capability Awareness matrix I use to help illustrate the entitlement mindset. It is sometimes difficult for people to accept, but once they do, they are on the road to recovery.

Ultimately, the fundamental flaws of our economy right now are evidence of this mentality. Unfortunately, it does not just evidence itself with the "less fortunate." Learned Helplessness is often enabled in the executive suites, by group think, or what I like to refer to as Cognitive Myopathy. At other times it is enabled by lack of integrity and professional courage.

In short, Learned Helplessness has pervaded every facet of our society in pandemic proportions. Sounds pessimistic doesn't it? I, however, am an optimist. I believe that armed with the correct knowledge, delivered by those with the professional courage to render the appropriate balanced feedback, that most people will want to do the right thing and to feel good about, rather than justify themselves. Given this assumption, I believe also that ours is not a hopeless state. As stated in my prior post, good investigators are generally also good leaders. They have to leverage leadership to gather, assimilate, collate and make sense of all the data that exists around the Loss Event and then identify and develop Actions for the Root Cause. If you are doing investigations, and not exemplifying the characteristics of a good leader, you are in danger of a less than complete investigation. In order to accomplish a good investigation, you have to work at leadership, and as such, solicit the help and support of other. An attitude of Entitlement or Helplessness, will only scare of the support you need to be successful.
So when you are done with the investigation, ask yourself...Were you entitled, or was the title won?

Does That Include Me?

NOTE: The title of this post is also a link to the article referenced within the post.

Good investigators are great leaders. They have to be. I've just only begun to realize how true that is. Attached to this post is a link to an article I recently read in a magazine I subscribe to. The article, entitled, "How To Build Great Leaders," discussed the value of developmental assignments as one of the tools that are used by organizations to build great leaders. My organization is on the list of the top 25 cited in the article. I have a colleague who has gone to Harvard Business School as a developmental assignment. I have several other colleagues who have been assigned overseas for three years for leadership development.

As I read through the article, I began to wonder why I was not getting some of these opportunities. And then I began to think about what I am doing for the organization now, and how I got there. But first, allow me to back up.

According to the article, developmental assignments are costly in that you leave a role in which you are being productive (read as adding value to the organization) and are assigned a role in which you are not necessarily being productive (read as learning or developing). In the latter case, a return on investment for the developmental assignment may not be realized for years after the assignment. Many times, these developmental assignments are grueling in terms of demand on time and other personal resources, because you have to really push the learning curve to keep up.

As stated above, I began to wonder why I was not getting some of these opportunities, but stopped short when I thought about what it was I was I am doing for my organization now and how I got here. Prior to my former role, I had been given a challenging leadership position (formal) at which I had been successful. I had asked specifically about further developing my leadership skills and was placed in an individual contributor role, the purpose of which was to focus on improvement of the process I would be supporting. I was in this role only six months before it became apparent that there were going to be numerous manufacturing deviations for some time to come. Although I had a team of peers I worked with, the responsibility of investigating and resolving these deviations fell to me.

In January of 2007, the organization implemented a new database for investigating deviations and storing all the details of each investigation. This system has queries that will enable anyone to identify how many investigations they have actually done. From 01 JAN 2007 to 01 MAR 2009, slightly over two years, I had performed 115 investigations requiring full Root Cause Analysis and supported several others. It was challenging and difficult. I often viewed myself as not much more than a technical writer. My focus got more narrow as time went on, such that all I was doing was these investigations. Long hours were put in to manage a nearly unbearable workload.

I was informed in NOV 2008, that I would soon have a new role and in MAR 2009, took the role I now have as a member of a team of individuals specifically tasked to investigate certain types of deviations called trends. We use Six Sigma tools (I'm a Green Belt) and other investigative techniques and impact is sometimes beyond the site I support. We are an eclectic bunch and have learned to work well together. We are just now preparing a year end presentation of our results for senior stakeholders.

How, you ask, does this relate to the article cited above? First of all, allow me to explain that there are formal leaders and there are informal leaders. Formal leaders have titles stating them as such. Informal leaders do not. Not everyone can be a Formal Leader. There is just not enough opportunities to go around. In any organization. Some people are Formal Leaders due to skill, talent, nepotism, favoritism, timing or any combination of these. Some are controllable, some are not.

On the other hand, everyone can be an informal leader. Allow me to repeat that one more time: EVERYONE CAN BE AN INFORMAL LEADER. Given this fact, then the equation for leadership changes a bit. I left a role as a Formal Leader to work for a time as an individual contributor. I was not able to utilize my skill set in the manner described in my job description, nor to my own personal expectation. I felt that I had left a role where I was productive. In my new role, I was productive, but not in a way I felt good about at the time.

After three years, and a lot of frustration, I was assigned my current role, also as an individual contributor. Admittedly, I was somewhat frustrated coming into this role, but then the clouds parted and angels began to sing. The work I had done over the previous three years, although unexpectedly, had helped me develop a skill set highly valued by the organization. My networking, investigative, communication and yes, leadership skills, had all improved significantly. This was not overt. I did not realize this until things started developing as I settled into this new role.

This was a significant learning for me. So when you hear about the fancy assignments overseas or at Harvard or MIT or whatever, perhaps you can step back and take a look at what you are doing right now and ask: Is what I am doing a developmental assignment in disguise? What can I learn from this role, frustrating as it may be, that will position me to be a better leader, formal or informal, in the future.

I believe that when things are painful, we are either growing, or missing a significant opportunity to grow. When things are easy, we are not challenged and when we are not challenged, we do not learn. If we don't learn, we may be cutting ourselves short on future opportunities. If you accept this as fact, then after you read the article above on organizations that build great leaders, and then ask yourself, "Does that include me?" The only answer is...

...YES!!!