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