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?

Loss Events & Losers

Nobody wants to be a loser. In order to not be a loser, an organization must understand what a Loss Event is. Understanding what a Loss Event is, will enable the organization to investigate the cause of the Loss Event, identify Root Cause, and the appropriate Action or Counter Measure(s) to correct the Root Cause. However, before any of this can happen, the organization must understand what a Loss Event is.

Simply put, a Loss Event, is where something is lost in the process of doing business. I don't necessarily mean the type of loss that would prompt you to go to the lost and found. Rather, the loss is typically measurable in monetary terms, for most businesses. Losses can be the dollar value of down time, defects, a safety incident; you can think of as many examples as there are companies in operation.

The problem is, that any loss event represents lost revenue to the organization. If the loss event is down time, then you have the cost of not producing product, the cost of replacing equipment that was damaged or in disrepair, the cost of labor during the downtime, etc. If the loss event is defects, then you might have the the cost of rework, lost opportunity cost if you cannot rework and have to scrap, cost of equipment or line time to do the rework, cost of overtime to execute the rework or manufacture replacement product, etc. If the loss event is a safety incident, you can follow nearly all the same paths for the cost involved, but you might have some different costs such as doctor's visits, workers compensation, etc.

The point is, that a loss event, in the simplest terms a business can understand, is the erosion of revenue and/or profits. In order to understand the cause of the loss events, organizations will employ formal Root Cause Analysis (RCA). I personally like to use a Fault Tree when doing RCA. Using RCA methodologies will drive the investigator to Root Cause. Knowing Root Cause will enable the appropriate Actions or Counter Measures. The appropriate Actions or Counter Measures will prevent the Loss Event from occurring again. Prevention of another, similar Loss Event provides an incremental increase in the revenue and profits of the organization.

Organizations that have not figured this out, or choose to ignore Loss Events, are Losers, (fiscally of course!)