Three Pieces of Graduate Advice That I Wish I Had Listened To

It is the time of the year when everyone gives advice to new graduates before they start new jobs in the "real world" and begin the career climb. I thought I would toss in a few pieces of advice to all new engineering grads that I wish I had listened to when I graduated. 
First, look to turn a few things off before you think about turning new ones on. 
What I mean is that in many cases if you focus on removing the waste in the system then you may not need new equipment or people and in fact you may not even need all that you currently have. We always want to buy shiny new things because it is fun and exciting but what we find in many cases is that we do not really need them to meet the engineering need.
For example (read real life mistake):
When you are running low on compressed air, do not buy a new air compressor before taking the time to fix all the leaks in the current system. You may find that once the leaks are fixed you do not need all the equipment you have now. If you do not buy the new one then that is money saved on both the equipment and the maintenance of the additional equipment.
Redesign is your last option not your first
When you find a problem do not look to create a new better redesigned version without first truly understanding why the current one does not meet expectations. When you create a new one you bring in a whole new set of failure modes that will need to be understood.
For example (read real life mistake):
If the position counter on a Schlafhorst spinning frame is not counting one should try to understand why it is not sensing the bolts instead of first redesigning it completely as a retro reflective counter system in a dusty environment. Rumor has it the dusty environment will add new failure modes to the system.
Its all in the detail: double check the dimensions.
Said a different way, measure twice and have someone else cut once.
For example (read real life mistake):
When designing new carts to hold 108 inch loads of cores a 105 inch beautifully designed and built cart is well... kinda useless.

What advice would you give to new graduates as they start their journey? Leave them in the comments below.

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?

Three reasons why I detest "wrench time" as a benchmarking tool.

Ranting about Reliability:
Wrench time and wrench time studies are two of the most misused, misunderstood, and painful to deal with elements of maintenance benchmarking for three reasons:

• different definitions and standards
• data that is skewed by the act of collection
• overzealous comparisons of dissimilar metrics from different locations

We all like the implications of knowing the amount of non value added work within our maintenance schedules and we would love to be able to measure and then trend the removal of non value added time. This is a good thing, but lets look at what gets in the way and one thing to help improve our results for each challenges.
The first struggle is around the definition or standard for wrench time. What is in? What is out? Is travel time part of wrench time? How much is too much? Is prework wrench time? Is trouble shooting wrench time? You need to answer these questions and more to get something standardized for your location. A good place to start is the SMRP Metric for wrench time but my guess is that you will need to add additional clarifications to make it relevant to your site.
The data is not accurate. By virtue of focusing on the data it changes the behaviors. If you tell me you are going to watch me type out this blog and count my mistypes I will by nature slow my typing and make less errors. The same thing happens when we do wrench time studies so the numbers we get will be different than actual. I suggest the use of something known as a DILO instead of typical stop watch time studies or other tool driven methods. In a DILO or Day In The Life Of you work with the craftsman to understand what gets in his way or what irritates him as he tries to complete his daily work. You are with him or her through their day learning based on their experiences. This approach is more about helping them and less about "watching and judging" them. In the end, you identify problems like missing permits, lost parts, and wrong tools and you see first had what that is costing them in time and patience without driving a wedge between parts of the organization. If you want to talk more about DILO send me an email and I will share with you tips and tricks based on my experience. 
Some days it seems that everyone thinks they should compare their wrench time numbers to everyone else. This one is common for many metrics and KPIs but as I have suggested in the past it would be best if the sites looked at their ability to improve the metric and talked about what their delta over the last quarter was as opposed to the raw number. Then they could talk about the specific actions they have taken to get that delta. The raw metric are just too different in most cases to be compared and bad decisions can be made with bad data from bad comparisons.

Now I know I did not necessarily solve anything here but I hope I have provided a few ideas that might help as you calculated and evaluate your maintenance wrench time on your quest to reliability now.