Five Whys and Wishbone: Program and Training Sponsorship

Over the years I have seen many sponsors give great supporting speeches but I have also noted a few that failed miserably along the way. Lets learn from them. One in particular was the kick off of a new root cause analysis facilitators program in a facility with a history of " flavor of the month" programs and lack luster performance. The "leader" did not attend the workshop because he was "fully up to speed" but came in at the end to say how important this new initiative was to the facilities future. He opened his speech with how he had used "five whys and wishbone" to solve problems in the past and that it could be done with no additional resources so it was perfect for them. It went down hill from there. All I could think was "I guess you could use wishbones but how many turkeys would it take to get to the root causes." For those of you who have seen my root cause methodology you know we talk about five whys and fish bones as the simplest of tools that can be used to create a culture of root cause but certainty are not the tools of serious problem solvers like the reliability engineers this "sponsor" was speaking to. My point is if you want your initiative to have even half a chance of success then take some time to learn what they are about. Brush up on the details. Spend a few minutes with the instructor finding out what the key questions are that you need to ask to really lend you support to the program and drive results. Also take a few minutes to understand what the practitioners will need. 

Many leader spend the time and show their support by attending the full class and learning with their team but if this is not an option then many instructors offer executive half day overviews of the course that can be provided prior to the start of the full workshop. In these session they cover all of the basic requirements, key concepts, question that need to be asked to drive results, and key expectations the leader should have.

Happy Training 

3 Reasons Why Operations Does Not Support Maintenance and Reliability

One of the most common things maintenance folks say is that operations does not support maintenance and reliability. It sounds like this:
"If it weren't for operations we would be reliable"
"They think their job is to break it and then it is our job to fix it... and fast"
"They will not let us have the equipment for PM and they wonder why it breaks down"
Want to know what operations has to say? Here are three quotes and a set of underlining causes:
1. Operations says: "Every time I give them the equipment for PM downtime it runs worse on start up than it did at shutdown"
Reason: Maintenance overly relies on invasive PMs that induce infant mortality instead of using Condition Based Maintenance (CBM) which is performed while the equipment is running and does not induce failures. If maintenance could get fifteen percent of there labor dedicated to CBM and then fifteen percent dedicated to PM then the balance would be better and the number of maintenance induced failures would drop. One example is eliminating the PM where you open a gearboxes up for a gear inspection and transitioning them to CBM inspections which can accomplish the same task without the potential for reassembly errors or foreign contamination in the gear box.
2. Operations says: "Maintenance never sticks to the schedule. They ask for 8 hours and take 16" Maintenance creates a schedule with work that is only marginally planned and then overruns the outage timeline because the estimates are completely inaccurate. If you don't take the time to break the job down into estimable task or steps then it becomes very hard to produce and accurate schedule. The way this sounds in the field is "Oh that job, it will take about a half shift for two guys"
3. Operations says: "This equipment runs better if I can just keep it running and keep maintenance out of it."
Maintenance does not practice precision maintenance therefor as work is completed defects are induced and equipment fails prematurely. One example is the installation of a bearing on a shaft with a hammer and chisel instead of a bearing heater and impact fitting tools.

The point here is that if we as maintenance and reliability professionals start by addressing our issues it becomes much easier to ask operations to address theirs. Or to say it another way:
If you wanna make the world a better place
take a look at yourself, and then make a change
MJ

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.

Ranting About Reliability: Anybody Seen the Operator?

The ornery old man is loose on the RN blog again: laugh, cry and enjoy

For the love of all things holy, good, and reliable, Operator stay with your machine when you have a break down. A break down is not an invitation to go to the break room. Why you say? Because maintenance technicians are not freaking mind readers. They should not have to guess why the line is down. It's not like that work order with the one line description that reads "formulator broke" cleared up anything. Besides, if you stay with the equipment not only will you be able to pass on what is broken you can also describe what was happening just prior to the failure. This will be incredibly helpful to your troubleshooting teammate. If you are lucky, you might even learn something or even teach something as you and your maintenance partner work together to not only solve the problem but also reduce the chance of re-occurrence. When the work is complete you can start the line together. This will insure the repair was effective and there will not be a delay from completion of the work to production start-up.

And another thing, would you please tell me why operators should be rewarded with a break when we have had a failure. It should be all hands, including operators, on deck working to resolve the issue. We are here to make things not make hours and if anyone is just interested in making hours you may get the rude awakening that comes with off shoring to lower cost countries that don't make hours they take jobs. 

Have a happy Monday ...