I never saw that coming!

Being proactive takes some practice. It doesn’t come naturally to everyone. In the comic above, Joe is sheepishly requesting a new part for his Jeep that is obviously in bad shape. We can gather from the limerick that Joe ignored the temperature gauge and his Jeep overheated. Maybe this wasn’t even the first time this happened and Joe had been hesitant to do anything about the high temperature readings. Why do we do things like that?

One reason could be “the ostrich effect”. George Lowenstein originally coined this phrase to describe situations where knowing something bad has happened is much more painful than suspecting that something bad might have happened. In other words, when things seem too rare or bad to actually occur, we ignore them and hope that they never do. This is a potentially dangerous situation when the consequence is high. What if Joe’s jeep was in the middle of combat? What if it was carrying supplies to the front line?

We all probably can think of situations where we have witnessed this type of behavior. In maintenance and reliability, one example might be when we don’t take actions based on negative Predictive Maintenance results. The oil analysis gives an indication that abnormal levels of contaminants were detected. Do you immediately create a work order to do get to the root cause?

Another interesting point of the cartoon above is the statement that a good soldier “digs out the cause and he acts”. When I facilitate courses on Root Cause Analysis, one of the main points that I try to get across is that all the good effort of a properly conducted Root Cause Analysis will be wasted if no corrective actions are taken. That’s where the rubber hits the road. Investigating and diagnosing a recurring problem can be fun and certainly will garner attention from your boss when you report and document the root cause(s) of a particularly damning issue. But if you stop and move on after the applause dies down, you will miss the opportunity to provide tangible increases to the value stream.

Next time you are presented with some bad or unpopular information, don’t be afraid to accept and acknowledge the fact. But instead of sticking your head in the ground and pretending that it didn’t happen, roll up your sleeves, dig into the issues, find the root causes, document your solutions and go about making the changes necessary to ensure the problems never occur again. After all, someone has to.

How much is enough?

The equipment is not in its normal condition and needs to be replaced now. . . or does it? Here is a situation that I see quite often and is addressed in this image. The warning in the limerick is not to overreact and deadline (or declare unfit for service) your vehicle just because it’s not in it’s normal condition. In this case, the graphic indicates that oil seepage from the wheel end bearings is “OK”, but “a streaky wet leak” is not.

I can’t count the number of times I’ve seen and heard of instances where all planned work for the shift was halted because something looked amiss and was immediately corrected. That isn’t to say that there aren’t good reasons to repair things immediately. The issue I’m exploring is whether certain conditions can be left alone and the repair can be scheduled to be completed at a later date. Do exact, defined conditions need to be stated? Can we trust the technicians that are operating and maintaining our equipment to know what is OK and what needs to be corrected immediately?

Early in my career, I believed strongly that taking all guesswork from the technician’s and operator’s control was the goal of any process or procedure. This was especially true when writing or reviewing Preventive Maintenance procedures or On-Condition inspections. As a result, I wrote job plans that were very specific and left little to interpretation, especially when something during the procedure was out of the ordinary. In my opinion, the clearer the steps were and the less the technicians had to think the better. As I’ve matured in my understanding of how maintenance programs operate best, I began to realize that there is a fine line between too much and too  little detail. Giving someone so much detail that you take away their ability to exercise their own good judgement disrespects them and makes them feel inferior. Leaving them with no idea of what the intent of the procedure is leads to misunderstandings and work that does not address the failure modes intended to mitigate. While I don’t think there’s a magic formula for how much detail is enough, I do think there are some general rules of thumb to keep in mind.

  • Use short sentences that get straight to the point.
  • Use “active” voice in a “positive” sense. “Verify switch is on”, not “Check switch is not off” or “Switch should be on”.
  • Do not use abbreviations or acronyms, especially industry-specific ones.
  • Put warning messages and notes BEFORE the step they reference.
  • Be specific about the range of values you’re interested in. Use the ends of the range, not nominal and plus/minus.
  • Don’t require calculations in the procedure.

If it’s worth doing, it’s worth doing right

I’ve been doing some thinking about “Continuous Improvement” lately and was lucky enough to find a Dope Sheet with an example of Poka-Yoke, a technique that makes it impossible to make mistakes. More accurately, the image above shows Joe getting ready to use a headspace gauge to adjust the distance between the face of the bolt and the base of the cartridge case on a caliber .50 HB machine gun, M2. You didn’t know that by looking at it? Well, I might as well admit that I had to look up a few things on the internet. According to an online manual I happened to find, “Firing a weapon that has improperly set headspace and timing could result in damage to the machine gun, or injury to the gunner”. By reading the limerick, you can guess that some soldiers were adjusting the headspace by “ear” or “pre-arranged marks” and mistakes were likely made that could have led to failures and/or injuries.

A Poka-Yoke can be as simple as the go/no-go gauge shown above (a two-sided tool for checking tolerances of a part or assembly) or as complex as a set of limit switches that prevent a drill press operator from drilling a hole too shallow or deep. One of my favorite examples of a Poka-Yoke is a gas cap. In this one item are two separate ways to prevent you from making a mistake. One, is the lanyard that keeps you from driving off without your gas cap and the second is the ratchet mechanism that keeps you from over-tightening the gas cap and damaging something or keeping you from getting it off the next time you fill up. If you count the entry to the gas tank in this example, you can add the different diameters of gas pump fill nozzles that prevent you from filling up your unleaded gas car with diesel fuel.

Here are some steps you can take to implement a Poka-Yoke in your area:

  1. Look for a process or operation that is a leading cause of production loss, waste or equipment downtime. Use a Pareto chart or other tool to identify one that has lots of room for improvement.
  2. Apply Fault Tree Analysis or some other fault finding tool to identify all of the ways the process or operation can fail.
  3. Decide on a Poka-Yoke technique to use. Here are some approaches:
  4. Shut Out – Does not allow an error to occur
    Attention Type – Alerts that an error has been made
    More comprehensive – A combination or an alert to keep an error from happening

  5. Test it in the field to see if it works or if some adjustments need to be made.
  6. Train the users, review the performance, measure the results and publicize the success.

I recently has reviewing an adjustment procedure on a vehicle that described ensuring a gap of .25″ – .38″ between a door and a jam. I was made aware of the adjustment procedure after reports of the doors not closing properly and causing increased dwell time at the stations and decreased carrying capacity. There happened to be 24 doors on each vehicle and 12 vehicles in the fleet. Using a tape-measure or scale would have taken the craftworker forever and it still wouldn’t have eliminated the possibility of missing the dimension. I felt this was a great opportunity to create a go/no-go gauge for the craftworkers to use. Now, a quick check at a few points around the door with both sides of the gauge ensures that the doors are adjusted properly.

Does anyone have any good examples of a Poka-Yoke in their area? How about one that maybe didn’t work? What happened and what did you do afterwards?

[added 6/11 – After publishing the above post, I continued to do some research into continuous improvement and was slightly dismayed to learn that a go/no-go gauge is, technically, not a Poka-Yoke. Since it relies on the operator to remember to use it, it will not guarantee a mistake cannot be made. My apologies.]

With great power comes great responsibility

In response to a couple of comments from last weeks blog, I decided to look into and make a post about the role of leadership and the difference between responsibility and blame.

This image is a really good one. It features a solemn Joe sitting on his bunk. You can see he’s in charge (an E-2, I believe?) and had a particularly rough day that doesn’t seem to bother his buddy who’s sawing logs in the top bunk. The papers scattered around him give us a good idea of why is head is in his hands. The graph to his left shows the steady increase in the number of “Deadlined Vehicles”. I have to admit that I had to look up this term. To those who don’t know, in the Army (and maybe other branches) vehicles are declared “Deadlined” if they are not fit for duty. This increasing trend is obviously a bad one for Joe. I can only guess that this increase is due to the fact that Joe has been less than diligent in his Preventive Maintenance completion. I can guess this by the fact that Joe’s been forced to write “P.M. is a command responsibility” over and over again.

The first line is the limerick is a interesting question; “Who’s to blame for each massacred tank?” It’s a question that most of us have asked at one time or another. Is it a fair question? Is anyone to blame for a failure? I think we’ve all heard about the danger of assigning blame in any fault finding investigation (e.g., Root Cause Analysis). But, the difference between blame and responsibility is important.

Blame (whether blaming yourself or someone else) is resistance. For those familiar with Seth Godin’s philosophy, it’s your lizard brain taking over. More importantly, it’s a negative step in a failure investigation. When you blame someone you are telling them that they don’t have the power to make the right decision. You are taking the ability to do the right thing away from them and making them the victim. It’s the easy way out and has no upside. It just makes people feel bad, which is a HUGE demotivator and almost impossible to recover from.

Instead, as a reliability or maintenance leader take responsibility for the situation. Responsibility is acceptance. Acceptance allows you to accept what has happened, learn from your mistakes and move on. Allow yourself the opportunity to feel good after the investigation that the incident will not happen again, because everyone knows that they have the power to make the right choice and if they make a mistake they will not be blamed.

In the end, as the limerick states, the responsibility for the failure “goes with the glories of rank”. This has not changed in the 60 years since this was published. Don’t shy away from this gift. Embrace the opportunity to demonstrate to those around you that you have the ability to be responsible for things within your control.

Are there any instances where assigning blame is justified? Are there any positive aspects to assigning blame? Are there any negative aspects of accepting responsibility? Let me know your thoughts below. Thanks.

No, you cannot borrow my truck

Joe's Dope Sheet #1

Before I go headfirst into my first blog post, I wanted to stop and give a little credit to the images that I plan on using to illustrate how good maintenance practices never go out of style. In 1951, the US Army began publishing PS Magazine. The idea was to publish a magazine about Preventive Maintenance that soldiers would actually want to read. They found an artist named Will Eisner and his company began creating artwork for the magazine. Eisner believed that comics had teaching potential and convinced many talented artists to help him. Each month contained an item called “Joe’s Dope Sheet” and each month followed the same story: a soldier who ignores preventive maintenance learns of its importance in the end.

This being the first post in my new blog, it’s somewhat appropriate that the topic addressed in the very first issue of PS Magazine was something as basic as treating your equipment with care. The image says it all from the long trail of boxes that fell out of Joe’s truck when he hit every bump, to the utter destruction of his truck at the bottom of the mountain. Basic care of the assets that are in our control is one of the easiest ways to assure that they are useful and productive for as long as possible.

Here are a couple of ways that I feel maintenance and reliability professionals can help create a culture of basic asset care and avoid instances of equipment being treated like Joe’s truck.

  • Create a feeling of ownership. Those that are responsible for the care of your company assets (craftworkers, engineers, managers, etc.) need to feel as if the equipment is their own. One way of creating this culture is to get everyone involved in decisions about new initiatives or changes to the maintenance plan.
  • Ask for advice from the workers that operate and maintain the equipment on a daily basis. Let them know that they are the experts on the machines and that others value their opinions.
  • Consider assigning specific equipment tasks to the same individuals all of the time. The level of familiarity that comes with being around one or two assets could create a feeling of ownership.

Does anyone have any other ideas for creating a culture of basic asset care? Does anyone agree or disagree with the examples that I gave above? I’d love to hear some feedback. Thanks.


Welcome to the blog!