Preconceived Notions Get in Your Way with RCA

Preconceived notions very commonly get in your way with Root Cause Analysis. Here is a perfect example. In this picture you can plainly see that the people on the left are taller right? Look again... Maybe we did not have all of the facts at first. It seems that in the video there is more going on than we thought. Our notions of what a room is and how it is typically shaped do not hold true in this case. This irregularity, led us to a poor understanding of the situation. Many times we go after issues with our personal opinion of the problem and the solution predetermined and it blinds us to the truth of the matter. All the data must support the conclusion not just the parts that you like. I have seen these preconceived notions derail investigations time after time and, it is one of the reasons that I suggest not using subject matter experts as RCA facilitators in this blog. Check out this post for 5 ways to help prevent jumping to conclusions. Then let us know what thoughts and ideas you have for avoiding this common problem by listing them in the comments section below.

You Need to Stop Jumping to Conclusions... Oh Me Too. Here are 5 Tips.

Why do we jump to conclusions?

• Many times it requires no personal change...perfect.
• "It is what I know from my past" 
• It is a convenient answer that quickly explains away a problem. 
• In most cases it is also easier than taking time to understand the details and facts.

What drives this behavior?
Jumping to conclusions seemingly avoids or prevents the appearance of ignorance, and can squelch the emotional reactions of others."Don't get worked up, I already know what's wrong here and am working on it."
What can you do to stop yourself from jumping to conclusions?

1. Take time to listen and understand.
2. Collect and analyze the facts from multiple sources.
3. Set a goal to try and prove yourself wrong instead of working so hard to prove to others that you are right; especially, if you have a preconceived notion.
4. True analysis of all of the facts is key. If they are indeed facts and not assumptions then, by definition, they all have to support your conclusion. If they do not, then you are missing some detail or your assumptions might be in the way of the truth.
5. Use root cause analysis tools to help in viewing the facts and their relationships. Some of the Transitional RCA tools can be found here.

In the end, if you take time required and practice the restraint required not to jump to conclusions and really understand the situation you will not find yourself trying to defend a conclusion that you should never have leaped to to start with.

Lets go solve the world's problem one fact at a time!

Technical Subject Matter Expert Facilitating Your RCA? Stop It.

What is the number one thing that all technical subject matter experts possess besides large amounts of knowledge?
Opinions... followed by years of past history and possibly preconceived notions.
What makes them great as contributing RCA team members for problem solving, can be kryptonite to them as facilitators. Their history and expertise leads to three possible problems when they lead or facilitate an investigation:
1. They take the team down a road to their favorite conclusion that may or may not be based on all the facts discovered.
2. They are so respected as SMEs that no one will challenge their thinking or ideas with new ones.
3. They can be blind to facts that don't fit their paradigms.
Some offer an opinion from the leaders chair and then it is a race to prove that they are right. Don't get me wrong, there are extraordinary folks out there but, in general, most SMEs struggle with these problems when asked to facilitate an RCA. So why put them in this situation. Let a leader lead and an SME provide knowledge in a facilitated manner.
A good facilitator tries to create an environment where everyone on the team is providing ideas and input. They are not ignoring any of the facts even if they are inconvenient and they are working to drive the team to consider all the possibilities and solutions. Not every problem will be solved with an answer from the past, so facilitation becomes important to draw out these new, more effective solutions.
My experience says to separate the roles and have others from different parts of the organization facilitate. Then you can instantly watch your root cause analysis teams drive more failures from your site at a lower total cost of implementation.

Software Got You Stuck? Do Not Let RCA Applications Hold Up Your Root Cause Efforts

Let us be clear, root cause analysis is a way of thinking not a software application yet their are sites that are spending thousands of dollars and hundreds of hours learning software instead of solving problems. Software is not inherently bad but you don't need a sports car to learn to drive.
If you are getting started with your RCA efforts and software is part of your plan then be aware of these potential problems:
Software can limit team involvement: Facilitator is head down in the computer rather than up truly facilitating responses from the team.
Software can slow the flow of ideas especially if it is slow to create or move causes and links: time required to create or edit means other are waiting and forgetting points and causes.
Software can complicate reporting: The simplest and most effective reporting for most sites is the A3 style RCA report which will be the topic of the next blog post.
Computers create barriers between facilitators and the RCA team. If you have to collect the information directly to the software then you should consider a facilitator and a recorder or scribe.
If you can problem solve without the software or by capturing the information after the analysis then here are a few tips and benefits of a software free RCA.
Use sticky notes and a big blank wall or a white board. (3M's Super Sticky PostIt Notes work well)
This allows good group involvement by allowing them to write and share or verbally share and you capture the causes.This gives you two streams of causes in two different communication styles. If two people share the same or similar cause than you stack them and both participants know they were heard. This can be key to good facilitation.
With sticky notes you can start by understanding the sequence of events and include any time stamped data from PLCs, cameras etc. and then once you identify key event, or forcing functions as they are sometimes known, you can transition to fault and logic tree with ease. This will provide a better understanding of the systemic and latent causes of the key event.
With the very hands nature of the sticky method you can move and reorganize causal chains quickly and as you discover new causes they can be added with ease and with out huge disruptions to the flow of ideas. When you are done you simply take a quick picture of the analysis via the ubiquitous cell phone and paste this into your chosen report format.  These can then be shared with others electronically.
The point of today's post is not that software is bad. It is simply that it is not required to get started and make substantial improvements in your facility. Many of our student save hundreds of thousands of dollars for their sites using nothing more than the sticky notes and a sound root cause methodology. Once root cause becomes part of your business culture then you can capture, catalog, and share more effectively with the help of software but don't let it hold you back from the start.

Two Things Engineers Consistently Get Wrong

As I think back over the years of site assessments, reliability implementation, and coaching of facilities and engineers globally there are two concepts that consistently show up as weak areas with engineers in manufacturing environments.
The first is true in-depth "root causes" problem solving (this is different than the "engineers jumping to conclusions process" that many employ) and the second is relying on technical solutions rather than culture change to solve problems. They both go hand in hand but are only completed at a precursory level by many.
Let's first look at "root causes" problem solving. (There are more post on this topic here) I have put the quotation marks around it to say that I don't believe that all problems need to be addressed at lowest root causes levels but the problem should be understood to that level so that the engineer truly comprehends the systemic and latent roots or drivers of the problem. These base roots many time rest in the culture of the facility and must be known to truly lower risk of reoccurrence. Secondly there is never just one root cause as there are multiple things that must have existed and instantaneously happen to allow unwanted events to occur hence the "s" on causes. This is why five why and fish bones, which are great for creating a culture of problem solving, are not the tools of serious engineering problem solving. You need to be able to see all of the causal factors that came together to create the event and determine all the possible ways the problem could be addressed to insure a solution is selected that lowers the risk of re-occurrence, creates the best business case, and is sustainable in the long term. Many times engineers go after technical solutions like redesign when the best business case is in changing the culture or behaviors that led to the event.
This brings us to the cultural change piece that is so often ignored as an option. We as engineers are trained to think about technical solutions and therefor many times ignore the people or cultural solutions. Some examples of these technical solutions are replacing a lubricated bearing with a sealed bearing to prevent lubrication based failures or changing adjustable components to fixed designs to prevent operator set up issues. These may be good solutions at the micro level but when the problem is macro and you have 100s of assets and components with these issues and the cost to implement can increase significantly. In these cases educating the work force on lubrication practices and set up requirements, and the included systems and processes can be lower total cost solutions. Behavior change is hard and can take much time and focus but the quantity of defects that can be eliminated or prevented is extensive. So as an example if a bearing failed due to over lubrication and we replace it with a sealed bearing and remove the fitting, a very technical solution, we have eliminated that one failure point but if we tackle lubrication and and the cultural issue of precision maintenance as a whole we can correct lubrication issues more broadly and solve many thousands of over lubrication issues across the facility. We can still bring in technical solutions like UE Systems Grease Caddy to help ease the cultural change process but now we are focusing on causes that lie lower in the casual chain and more greatly reducing risk to the facility as a whole.
So in conclusion, if you are thinking about your personal development plan or that of your engineers you may want to consider developing a strong problem solving methodology that looks both deep into the problem and broadly into the contributing factors. It should have business case thinking weaved through out. It also needs a solid process for execution and follow up. It does not have to be complicated but you will need to provide the training required and ensure that your engineers can execute. And, they must consider the behavior or cultural change solutions with the technical solutions to the problems your facility faces. This will have substantial returns on your effort if you stay the course. Reach out to me if you want to hear the success stories others are having in this area.
shon@reliabilitynow.com

3 Things You Could Learn From Your Doctor About Reliability.

So when you go to the doctor you expect your problem will be addressed quickly, thoroughly, and at the lowest cost to you. You don't want to spend hours of downtime in the "waiting room." You want a root cause understanding of the problem and a strategy and the drugs to resolves the problem. You want to pay a standard amount deductible and get no surprise bills after the treatment. Operations and Shareholders should expect no less from the maintenance and reliability organization. We should use condition based tools and proactive methods to identify issues early before operations experiences downtime. We should use problem solving tools like root cause analysis to understand the cause of the pain and prevent re-occurrence. Shareholders would prefer that all work be planned and scheduled so that it can be performed at the lowest total cost.
Here are three more things that the doctor does that we should do as well.
When you arrive, the doctor seeks to understand any changes in your life. He checks your vitals and the basic details like weight. He looks for what has changed. When you arrive at a failed piece of equipment you should perform the root cause method called change analysis. You would look at what things have changed. It can fall into categories:

• What has changed (product mix, load etc)
• Who might have changed (new operators or maintainers, different conditions etc)
• How might have it changed (weather etc.)
• When did it change (run at a new time, different shift etc.)
• Why did it change (operations strategy etc.)

If you answer these questions then you can begin to understand the causal chains and root causes.
When you go to the doctor they don't just run one test with one technology. We should use multiple technologies to understand the health of our assets. We might use vibration, infrared themography, oil analysis, Airborne ultrasound as well as others. Using these tools together gives you a full picture of the health of the equipment just like the doctor's test gives him a picture of your health.
The last point I want to note is that the doctor or surgeon uses checklist for procedures. Many sites do not have nor want to create good procedures or checklist. These sites have told me that they do not need them because their craftsmen are skilled and experienced. My point is that the doctor has done common procedures hundreds of times and yet he, a skilled doctor, still uses a checklist. These checklist do not tell him how to tie a stitch but it does point out key measures commonly forgotten steps and verifies that all of his equipment that is used is returned.

Next time you are at your doctor think about what you see him do and how you can use that to professionalize our field.

Are You a Reliability Champion or Reliability Killer?

As I travel from plant to plant and facility to facility I see both Reliability Champions and Reliability Killers.
First, lets talk about the "bad guys." These are the people in the organization that are not necessarily against getting better but they do not "have the time" to make the improvements and certainly do not want to wait for others to either. These folks are quick to say "When is the asset going to be back up?" without asking "what caused the problem?" and "How do we prevent it from happening again?" These are the ones who will spend the companies money to buy predictive and precision maintenance tools but because of the learning curve, do not allow them to be used lest they slow down the repair process. Their goal is not to fix it right just to fix it again and preferably as fast as possible. During one extended visit to a site I watched the company spend a substantial amount of money on alignment equipment and training but as soon as the crafts tried to use them and took a few extra minutes the supervisor yelled at them "to get that stuff off there and use a strait edge. We have to get this line up!" He was a Reliability Killer.
So what does a Reliability Champion look like? They are still concerned with getting the equipment fixed but they allow that bit of extra time that can get us to root cause and improve the precision of the repair. They use your target business processes. They know if we take a little down time now then I prevent a lot of downtime in the future. Their definition of fixed is a permanent repair not one requiring baling wire, duct tape and a hammer. They like to fix it once and forget it (after it is recorded in the CMMS).
In the end the reliability killer can be neutralized and in some cases even converted to a champion. It starts with communication and the creation of awareness and then as the killer sees the error of his ways and why changing could benifit him then he can accept more knowledge that can used to correct the situation or at least stop the killing. It is not eazy but it is possible with a plan and the desire to communicate.
So which category do your leaders fit into? Are you the Champs or the Killers? What are your plans to change that?

Boeing Dreamliner, Root Causes, and Asset Infant Mortality

Boeing and their Dreamliners are taking a lot of heat over their faulty lithium ion batteries. They are dealing with the birthing pain of new technologies. They chose to move away from older style nickel cadmium batteries which have a huge weight disadvantage and a lower power density than the lighter lithium units. There is some speculation that the excessive heat and fire on two jets was caused by a bad batch of batteries but we will not know until the investigation and root cause analysis is complete. The key here is speculation and if you are a practitioner of root cause, speculation has only a small place in the process. You can start with it but in order to make an actionable finding it must be backed up with facts. What ever you do don't forget to concider that much of the speculation will be wrong and you have to keep an open problem solving mind. As of today Boeing has not been able to ascertain the root cause of the battery fire according to reports released yesterday. They have begun to propose design changes that address the symptoms of the root cause in order to mitigate there losses in the short term.  However I believe in the long term the FAA will hold Boeing to a root cause solution.

Regardless of the outcome, I believe we can learn from the event as it has unfolded. We know that according to the original Nowlan and Heap study, which became the foundation of Reliability Centered Maintenance, that 69 percent of the failure modes within our facilities or on our airplanes can be categorized as infant mortality. We also know that many of us, including myself in the early days, look to redesign as the first solution to many problems before truly understanding all of the root causes. If we put the two together then we can likely expect that if we use solely a redesign strategy then the introduction of more failure modes and  more infant mortality is a given. When we redesign to remove one known failure mode we stand a very good chance of adding many more unknown failure modes if we are not using a tool like Failure Modes and Effects Analysis or FMEA. When we redesign we very seldom make things simpler and therefor the more complex redesign comes with more points of failure. So please understand redesign is a valid solution but it should not be your go to solution within most facilities. In the spirit of wrapping it up the three take always from today's post are:

• Use root cause and don't be afraid of short term solutions but always have a long term plan for defect elimination or mitigation at the systemic and latent levels based on return on investment and risk thresholds.
• Redesign should not be your first choice in most failure investigations. Infant mortality and unknown failure abound in redesign decisions.
• Third if you are a root cause practitioner then you can not give in to speculation and rumors without data. Lets leave those to the tabloids and non fact based news outlets of which we have plenty.

To provide a historical perspective and a bit of data, the following quote was provided in an earnings conference call last week by United Continental Holdings Inc. Chief Executive Jeff Smisek. He defended the plane saying:

"History teaches us that all new aircraft types have issues, and the 787 is no different," Smisek said. "We continue to have confidence in the aircraft and in Boeing's ability to fix the issues, just as they have done on every other new aircraft model they've produced."

Designers and Re-designers must expect infant mortality and use tools like RCM, FMEA, and RCA to mitigate these problems and the risk that associate with them. What are you doing to reduce infant mortality in your plant?

Solving the Crime of Unreliability: Elements of a Process for RCA

I was recently watching a popular crime drama on TV and I noticed that they follow a very similar process when solving a crime that I do when solving a reliability problem in a facility.
The first thing the detectives do is identify questions they have that they would like answers to and then collect all the evidence they can to begin to answer those questions. Then they build a timeline to understand where things fit around the crime. Then they combine the evidence and the timeline together and identify the motives and the finally the suspects. I have over simplified all they do but the core process steps are still there.
Solving the Crime of Unreliability in a facility starts with identification of the questions and the evidence to be collected. Then just like the investigator the next step is the collection of said evidence. I suggest folks use collection kits to help categorize and capture the data in its entirety. There is a blog here about the kits I use and what they contain.
Early on I skipped the element of time and did not complete the timeline or sequence of events prior to the use of other tools. Over time I learned this was a mistake in many cases and cause me to miss details. In two recent RCA investigations that were completed by others and reviewed and refined later by me, we discovered whole new causal chains and missed causes related to rebuild and maintenance execution that was not identified in the initial investigation. This was due to the fact that the original RCA team focused on their preconceived notions and did not look at what happen just previous to the failure in the sequence of events. Completing the sequence of events opened their eyes. It will do two things for you: first it identifies other potential causes and second it clarifies the causes that you have already identified. Just as the crime scene investigators then take the time lines and evidence and begin to look at the relationships I do the same. I choose a tool like fault tree or logic tree, among others, to attack evidence in the sequence and to draw the connections and the causal chains.  
It you find the crime of unreliability has been committed in your facility then you may want to make sure you have included each of these steps in your RCA process.

Fish Bone Alone Doesn't Deliver Root Causes

Chances are, fish bone or Ishikawa diagrams alone will not get you to the root causes. I refer to the fish bone as basic root cause tool. They serve a purpose and they do enable root cause investigations but they do not necessarily have the power to be a stand alone tool.
Let's talk about why and then what they are very good for.
The reason they are not able to give you all the root causes comes from the way they are used. In general they produce a categorized list physical causes and human causes but they do not identify  causal chains or underlying systemic or latent causes. Many times they only feature the symptoms of these latent causes as the bones of the fish. If you choose to only use the fish bone you have the potential to miss many issues and the connections that tie them together. I have reviewed many of these diagrams where the real root causes were just under the surface of the list but never brought to light during the investigation.
The real focus for me is the return on investment and if my root cause program is driven by only fish bone than I am implementing more solutions trying to address all of the identified bones of the fish at additional cost and I am more than likely suffering reoccurring failures driving lost production and additional analysis cost.
So what do I use the fish bone for? Personally I like to use it in three ways first as a lead in to the FMEA when working with a group that may have not used that tool before. I would take the bones of the fish and transition them over to a spread sheet or FMEA tool. This can help me get folks engaged and help to began the population of the next tool.
The second way that I use the fish bone is to is as a brain storming tool where we can identify many things that could have caused the failure and then I assign the individual bones to groups and they go out and look for data to confirm or deny the existence of that cause. Then when the team gets back together to apply the next tool and pursue root causes and solutions we have data to keep the process moving.
The third reason that I use the tool is as a facilitation exercise for when I have a quite or boisterous root cause team or team members. In this situation we use stick notes and we all write and stick causes to the diagram. This give the less expressive folks and alternative in writing instead of speaking and it allows the expressive folks to see the sticky note and know they were heard. This can get a group to develop many more possible causes and then they can verify, investigate and eliminate with data producing a better lead in to the next more thorough tool in your root cause process.
So to wrap it up fish bone analysis is a tool that has its place in the root cause process but if you want the lowest total cost of solution you will need to couple it with other tools from your root cause tool box. To read more on root cause check out these post from the past.

What are your thoughts?

Preliminary RCA Reports Promote Failures

Numerous government agencies including the FAA create preliminary failure reports however like many other things our government does preliminary failure reports are a bad idea for businesses as they drive many bad behaviors including reoccurring failures.
If you are currently providing these "educated guesses" to your organization prior to the actual root cause analysis report then the best advise I can give is to stop as soon as possible. I know it is not quite that easy but, when these preliminary reports are issued the manager and those effected are quick to review them even though they are merely guesses at the causes and may not be based on real data. The second issue is that once your complete analysis report is generated with all of the contributing factors, full causal chains, solutions and the data to support them is released then no one is really interested enough to take the time to read them after all they have already seen the prelim. It is like trying to read a book after someone spoils the ending, it is just not worth the effort. If you issue the prelim that  means that major decisions that effect the business are made based off of a quick reviews of partial sets of facts and strait conjecture. This conjecture leads to repetitive failure. In fact, many of the preliminary reports are nothing more than regurgitation of past experiences and not the facts related to this situation and real proven data.
I know many of you feel the pressure to get a report out with in 24 hours but in most cases this is just not a reasonable request and if you can not immediately change that expectation your should at least be working toward it. If you need to have a fast turn around on your RCA investigations then streamline your RCA process to limit the number of analysis required per month, request more resources for each investigation, and/ or speed up the report creation process. One way to speed up the RCA process is to use our A3 RCA reporting process where you put all of the information from the RCA on an A3 size sheet of paper that is populated as you move through the analysis process not at the end. I don't have the space here to show the full document but for an example send me an email at shon@reliabilitynow.net.
The point is don't put out your reactive quesses at a cause if you can streamline your RCA process and put out a complete analysis in less than a week. Just like you can't get to excellence in reliability overnight you also can not complete an effective RCA in an overnight time frame either.

Democratic Root Cause Analysis?

So we had primary elections last week and it reminded me of an RCA process that a client just shared with me. I call it Democratic RCA among a few other things.  Let me describe it for you. The first step was to draw a "cause and effect" or fish bone diagram for the problem. Then they get a group together and add causes to each category. So far so good. This is a great way to get the team going, encourage participation and and cleans the palette, if you will, before you dive into the more advanced RCA tools. This is where things went awry. Once they finished the cause list for each branch or bone of the cause and effect diagram they then voted for the most likely causes and those became the root causes for their analysis. While democracy and the power of the vote works in government it has no place in root cause investigations. RCA is about facts not conjuncture. It is not about opinion unless you can show the data to back it up. This root cause popularity contest will lead to limited if any out of the box thinking and will be steered by the most convincing group member or members. Causes will become a reinvention of something that has occurred in the past and is comfortable to the team. This is not root cause analysis.
If the team wanted to use their fish bone they could have skipped the vote and divided the group up into sub teams that could attack each branch of the fish bone. The sub team could go out and look for evidence on each of the possible causes and then they could choose one of the other RCA tools like fault tree to perform a more in-depth analysis. Now the analysis would be based on the facts that the sub team brought back from the field not a voting process for the teams favorite solution. In the end, this data based process will allow for more open-minded solution development and better fact based results for the effort of the team.

Three Silly Secrets About Root Cause Analysis

Here are three not so closely held secrets that can help clarify a few of the points around Root Cause Analysis (RCA). I hope you find them enjoyable and they help you think about a few things differently.
There is no such thing as one root cause...
Why!?!

• The connected causes or causal chains as we call them continue forever in an infinite continuum moving out from the event. Lets say you were doing a root cause on your office mate tripping over your computer cord, and you took it to an extreme, if your office mate had not been born then the cord could not have been tripped over tripped by him today. Now we know you can not control your office mates parental breeding patterns in order to prevent the fall but the point here is that you can investigate and build well beyond your ability to effectively mitigate or eliminate the causes and you would still not be at the one root cause. The key here is to try to find the paths that lead to the systemic and latent causes and then take the time to evaluate solutions at that level for the best return on investment. This may mean that they may be out of your span of control but within the span of control of your managers or others allowing you to be successful.
• Rob Base and DJ E-Z Rock once said "It takes two to make a things go right" I would add "or wrong": With RCA those two things are existing conditions and instantaneous actions.  There are always at least two causes per one effect therefor it should be called Root Causes Analysis. Using the example from above there was a cord which was the condition and a walking office mate which is the action. When you consider both you can look for the hidden causes and lowest cost solutions as you drill down into the problem.

Cause and effect are the same thing...
How!?!

• The cause of the event or reason for the RCA is the effect of it's cause. 
• For example from above: Falling office mate was the effect of the action of walking across the floor. The action of walking across the floor was the effect of the action of you requesting help moving your monitor. In this example they are all effects rewritten they can all be causes. You requesting help with your monitor was the cause of your office mate walking across the floor and your office mate walking across the floor was caused of him tripping over the cord. The point is don't get hung up on either word. Use which ever you like the best to build the causal chains but to avoid confusion don't mix them together.

Root Cause Analysis reports create no return on investment...
What!?!

• You do not get a return on investment from a report. The return on investment comes from the implementation and verifications of the solutions. Why is this important? If I have to choose between spending all my time creating a beautiful report or spending my time ensuring implementation for the solutions then I choose the latter.

Thoughts?

Transitional Root Cause Analysis

When I discuss RCA I use a method called Transitional Root Cause Analysis or TRCA for short.

It is made up of 10 tools that can be explained and understood in a very short period of time.

In the next few minutes I will demonstrate both the simplicity and rules for use for 3 of the 10 and explain why we consider them transitional in nature.

In this blog we will use what I categorize as the tree methods. These are three tools that build out into a tree root like structure. So let's take a look: the first one is called the "5 why"  method. It is very common in industry today and is a very basic root cause tool. It is created simply by asking the question why multiple times to create one causal chain. It creates a simple main tap root to build off of.

Now, if we take the 5 why diagram and branch it out by adding more elements at each level then we get a better representation of all of the causes that come together to create an effect. This transition of the 5 why is known as a fault tree. This method allows us to easily see all factors that led to a failure, but sometimes we need to show a bit more information to make the graphic more meaningful. 

If for instance an effect can only occur when all of its causes exist at the same place and in the same moment in time then we use the word "and" at that junction of the roots. If we eliminate either one of the cause then we can eliminate the effect. On the flip side if either of the causes could precipitate the effect then the word "or" would be placed at the junction. This would be read as this or that could cause the effect above. This allows you to see that both possibilities must be addressed to prevent the cause.

These three tree methods transition from one to the next by adding one simple new feature as needed during the root cause process. First, we take a "5 why" and branch it to get the fault tree then we add in the "and and" or "or" to get logic tree. Three powerful tools that build on each other to get you to the lowest cost solution that mitigates the risk.The other Transitional tools work very much in the same way and allow us to use the right tool for the job instead of trying to use a screwdriver as a hammer.

If you would like to learn more about the Transitional method to RCA please send me an email and I will help you along.

Have Your Corporate Metrics Become a Time Sponge?

The corporate quest to standardize metrics can become a time sponge absorbing countess hours and distracting facilities from the real focus of bottom line performance improvement.  Today's blog is about discovering how to keep KPIs from soaking up all of your precious time and focusing on driving changes in behavior not just the numbers.
There are metrics and Key Performance Indicators (KPI) standardization efforts happening all over the world. They are happening in plants and corporate offices as well as within organizations such as The Society of Maintenance and Reliability Professionals and the European Federation of National Maintenance Societies. Many of these groups and other authors have spent endless pages defining these metrics. While I believe their work is incredibly valuable for individual facilities to understand their current state, what I commonly see is the documents they produce only lead to further internal corporate argument. Some companies have spent years and countless hours on the quest to define metrics like Overall Equipment Effectiveness (OEE) even with the standards that already exist in the market. It becomes a discussion of what time goes into the calculation, what time is out, what speed is the best demonstrated throughput, how do we define quality product and so on. At the end of the day an apples to apples comparison of different sites can be tough if the metric cannot be pulled from a standard data source such as the ERP, EAM, or Profit and Loss (P&L) statements. The EAM data is also suspect unless many of the steps of the business processes have been standardized from site to site to provide consistent data.  I believe one solution is to get it close but don't take the effort to argue through all the details and then compare sites on a delta basis. So instead of reporting just your percentage OEE or any other metric, report and focus on the change in the value from quarter to quarter or month to month. If we all agree that the goal is to improve then let's compare the efforts to improve not just the numbers. If one site is able to increase their OEE by a full point in one quarter then do an RCA to understand why and learn from them. What behaviors have they changed? What processes have they refined? Focus on the Root Cause of Success and spend the time making behavioral change not debating corporate metrics. Wring out the time sponge and get back hours to devote to real results.

Root Cause Analysis: Getting the Maximum Return On Investment from RCA

Many Root Cause Analysis (RCA) practitioners tend to rest a bit when they finish the report. They think “Wow that’s a good looking report, now off to solve another problem” and they miss the fact that they have not solved the first problem yet. There is no return on investment for doing RCA reports… It is the implementation of the most cost effective solution that delivers the maximum money to the bottom line. With that said below is a list of four ways to ensure that you get the most bang for your RCA buck.
Follow multiple causal chains to provide multiple solutions for review
Look for all of the ways it could be prevented or mitigated including both the actions and conditions that led to the event. If you just using 5 Whys you may miss one or the other.
Evaluate all the solutions 
Sometimes we tend to recommend our “pet solutions” meaning that we use the solutions that have worked in the past without understanding the cost and benefits and comparing that to other possible solutions. We need to look at all of the ways to lower risk to an acceptable level at an acceptable cost. The logic below can help with that goal.
Be Logical: Remember “and and or”
        When looking at the fault tree use logic symbols to see where you need to only tackle one item to prevent or mitigate the failure in the case of “and” or where you may need to attack multiple causes in the case of “or” branches. If either this “or” this can cause the failure then you must address both to mitigate the risk whereas with the “and” eliminating the lowest cost cause in the branch will prevent the re-occurrence of the failure.
Remember latent and systemic level roots have the best savings potential but can also have the highest cost of implementation because in many cases you must change culture and human behavior. Because of this you should understand problems to the latent level and address problems at the cost effective level.

In the end RCA is not about developing pretty reports it is about developing a business case for the best solution from a cost and risk standpoint then ensuring that those recommendations both get implemented and get the results we expected at the lowest cost. Or to say it another way:
Have fun… understand causes… evaluate solutions… implement… verify… succeed!

Five Why "Nots": 5 Reasons Why Reliability Engineers Should Use More Than 5 Whys for Root Cause Analysis

First of all let's talk about what Five Whys is before we mention what it is not. It is a problem solving tool used in many facilities and is commonly associated with Lean, Six Sigma and Kaizen implementations. The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. The method is quite simple really and involves asking "why" multiple times until the individual believes that they have reached the process cause of the problem. This sometimes (but not always) means you will stop at the fifth "why" hence the name.
While I like five whys as an "on the floor" problem solving tool I cringe when people call it root cause for five reasons:
1. There really is no such thing as "root cause" a more correct phrase would be "root causes” because there are almost always conditions and actions that come together to manifest the failure. 5 whys as it is most often used only addresses one branch of the causal chain either the condition or the action.
2. By only following one causal chain you do not get the opportunity to analysis all the contributing causes and look for the lowest cost solution that eliminates or mitigates the risk to an acceptable level.
3. The results from 5 Whys are not repeatable. Different people using 5 Whys come up with different causes for the same problem. It is all based on their existing knowledge, and experience.
4. Five Whys many times is just used to prove what the practitioner already thought instead of looking at other possibilities. 5 Whys investigators are plagued by an inability to go beyond their current knowledge which leads to them not identifying causes that they do not already know.
5. My experience tells me that Engineers that use five whys solely do more investigations due to problem reoccurrence. They are sometimes celebrated for their ability to do 27 RCA investigations per month but when you look at the list 18 are problems that they should have taken the time to do a true analysis the first time and they would not be focusing on them again. Using the 5 why method causes a tendency for investigators to stop at symptoms rather than going on to lower-level root causes. This leads to reoccurrence of the problem.
So as I mentioned earlier Five Whys is a great tool for shop floor trouble shooting but if you are going to focus on root causes then you may want to consider the more advanced root cause analysis tools. I would suggest that root cause tools like logic tree or fault tree will identify more of the contributing factors and decreases the chances of failure reoccurrence. To see how to make a simple transition from 5 Whys to logic tree check out this single point lesson here. 
Good luck solving your problems and I hope you have fun doing so!

What I Learned from a Pharmaceutical Facility in Pennsylvania

This is a continuation of the "What I learned" series. 

Pharmaceuticals manufacturing is a very interesting business. For many years excess maintenance cost and maintenance down time has not been an area of prominent concern for many of these manufactures. But, with the need for additional capacity, the expiration of various block buster patents, and the rise of contract manufacturing their world is changing.
This facility was looking to be ahead of the curve and ensure they were ready for the changing environment. They wanted to be in charge of their destiny and not have it dictated to them.
The site showed me that there are many ways to succeed with reliability implementation and it can be called many different things.
This site used the energy behind the implementation of a new Enterprise Resource Planning (ERP) system and more specifically the Enterprise Asset Management (EAM) module as the framework for their reliability improvement efforts. As they implemented modules and sections they improved the processes and data that was required to be able to reach a new level of maintenance efficiency. This sounds like a logical choice but more often than not sites get over whelmed by this level of change all at once. Then the EAM implementation becomes simply a reimplementation of old practices, bad data, and ugly procedures in a shiny new software tool. It is a bit like adding a jet engine to a 1964 AMC Pacer. It sounds cool but it just does not end that well.
This site challenged the past standards and decided the old way was not good enough. They built a clear plan with managed subproject to prevent overloading of the organization.
They realized that the regulatory and product safety administrations were not there to put you out of business. Instead,  they are there to ensure you do what you said you were going to do. This site removed nonvalue added Preventive Maintenance (PM) task and refined procedures that once drove unreliability. They did all of this without increasing risk for the company or the customer. In fact, as they improved reliability with tools like Reliability Centered Maintenance (RCM) and Root Cause Analysis (RCA) in the later part of their ERP implementation they were able to provide more stable equipment and process which leads to a more quality product. Thanks to my time with this organization I know that when building a strategy for maintenance improvement it is very important to take a long hard look at the current state of the site, the culture, and the history of major initiatives and then prescribe an improvement plan that is specific to that site and it's culture.  As a consultant or a leader this means you can not always do it the same way you did your last project. You have to be constantly pushing the boundaries, matching the needs and using the culture to help them reach the goals they have set. This may change the title of your maintenance improvement initiative to a lean or Six Sigma project or it may be a part of an EAM or ERP implementation but in the end you use the site’s successful tools and momentum to drive the results that you need.

Top 5 Maintenance and Reliability Acronyms for 2011

As the year comes to a close you begin to see a lot of list. These list cover the top X "somethings" of 2011. They are beginning to show up on the TV, the radio, and the web. In fact, on the way in to the office I heard part of the top 40 pop songs of 2011. With all of these list flying around I could not help but think about the top topics for maintenance and reliability in 2011. I have looked back over conference proceedings, discussion group post, website and blog traffic and have put together a top five acronyms list with a bit of commentary on each.

5. PdM
Predictive Maintenance is one of the maintenance and reliability tools that sites are using more and more in the place of their time based preventive task. This year, as the cost of the technology continue decreasing, more folks are adopting the technologies and wanting to talk about them. I think the key point with PdM is that your work execution process has to be strong or these technologies will just identify a lot more work that you can not get through your planning and scheduling system to execution before it runs to failure.


4. CMMS/EAM
Computerized Maintenance Management Systems/ Enterprise Asset Management Systems continue to be a big discussion point for many folks as they struggle to get the value and return on investment from these systems. Many folks continue to see the CMMS as the solution instead of the tool that enables good processes to be successful.

3. RCA
Root Cause Analysis has been very popular on this blog this year but I must admit it could be because of my focus on it as a great tool to eliminate reoccurring failures and process losses. I think the one point I would share is this: RCA doesn't have to be complicated but it requires a great deal of follow to get good results.

2. BPR
Business Process Re-engineering is a topic we see and hear most discussed around EAM implementations and LEAN projects. This tool and the process that are associated with it can remove a substantial amount of waste from your work flow. The key element for success is not that different from RCA it requires tremendous follow up and a regiment that includes the change management methodologies and our number one topic for 2011... KPIs.

1. KPI
 Key Performance Indicators or metrics as they are sometimes called have been an intense area of focus this year. They generate lots of interest as sites try to figure out where they are and how they compare to others. The one suggestion I would provide for this topic is the following: Don't compare what you dont understand. Take the time to note how the metrics are calculated and how your methodology differs from others you may be comparing with. Too often I see dissimilar metrics compared and poor discisions made based on the conclusions. If you can standardise on metrics using documents like the SMRP Metrics Compendium that is avalible through SMRP.org then you can remove some of the frustration around metrics and KPIs.

I would also be remiss if I did not mention one topic that does not have an acronym yet but was a major topic of interest in 2011.  That topic was the skills crisis or the departure of the baby boomer generation from the work force. Many of the acronyms above are crutial to capturing this departing knowledge and allowing for its use in the future. The key is to start now.
Reliability Now!

Thank you to all of you who have followed this blog this year and I wish you a Happy New Year

10 Things We Learned about Asset Health Management from Domtar

Special joint blog post with the fine folks from the Ludeca Blog:

Domtar Espanola from Ontario, Canada won Uptime Magazine’s Best Asset Health Management Program. Their goal was “Go from Reactive Maintenance to Proactive”.

To achieve this goal, they put together a plan including several proactive actions and PdM technologies integrated with an Asset Performance Management Software which allow them to closely monitor equipment health.

Kim Hunt shared some of their plan elements:

1. Implement a precision lubrication program and oil analysis
2. Skills training: Value your staff and empower them with training. From formal training to just watching Reliabilityweb Webinars together and afterwards eating cookies and holding discussions —great for team building!
3. Size your equipment properly
4. Use laser alignment and balancing for precise machine rebuilds and installs
5. Precise operator care
6. Maintain excellence in housekeeping
7. Equipment health monitoring. Use predictive tools including vibration analysis to baseline your equipment.
8. Root cause analysis and problem elimination
9. Plan and schedule your maintenance activities with effective standard operating procedures
10. Continuous improvement - you are never done!

What did they accomplish?
21% reduction in maintenance costs
30% increase in production efficiencies
Increased MTBF (Mean Time Between Failure)
A total average savings of US$450,000 per year without increasing actual/potential production loss.

Congratulations to Kim Hunt and her team for this award and a job well done.