Never Met a Maintenance Manager that had Enough People

Of all the sites I have been in all over the world, I have never met a maintenance manager who said to me “You know Shon I just have too many people.” In fact most ask me how they should go about bringing more into their fiefdom. It usually sounds a bit like this: “I need to hire planners, supervisors and a few more crafts in order to improve my reliability. If I could get support for more I could make this happen.”

Interestingly, the data tells me something entirely different. The average facility in our database is spending forty percent too much on maintenance. A portion somewhere between forty and sixty percent, depending on the industry, of that overage is labor. They are maintaining a wrench time, craft time doing value added work, of twenty three percent against a best practice of sixty-five percent. Think about that number a second, if you have twenty five craftsmen at twenty three percent wrench time that yields five point seven five FTEs (Dedicated fully utilized resource). On the flip side if you take one of those craftsmen and provide him the tools and training required to be a quality planner and scheduler then you can improve your wrench time to a very sustainable fifty-five percent. Now even with one person out of the craft ranks you can yield ten point four five FTEs without an overall head count increase. That is a eighty-one percent productivity increase… Image what that would do to your work backlog…and this is only one step to attaching high maintenance cost and unreliability. We could also talk about preventive maintenance optimization as well as others steps to provide additional gains. I'm a visual guy so here is another look at the math.

Now we know that it takes time to make the transition to the higher level of performance and that not every site is truly overstaffed but if you don’t think long and hard about wrench time productivity before you think about increasing your staff you could be doing both you, your company, and the person you hire a disservice. If you trust the benefits of planning and scheduling, the capability of your staff and you take the time to build a plan to get there you can do actually do more with less.

“But We Are Different”

These are four words that I hear at the beginning of every reliability improvement journey but I’m sure you could hear it at the beginning of any major change where comparisons are made to “best practices”.

Let me first explain why it is so common. It is all driven by the way people accept change also known as change dynamics. The Kubler-Ross model for grief gives us a great place to start understanding this common phrase. This grief model was the genesis of many of the organizational change models that exist today including the one that was shown in my July 9^th blog on change dynamics. In Kubler-Ross the first stage is denial and the individual is denying that they can make the change. They are denying it could work for them. The list of reasons are long but for fun I have included a few that I have heard at the beginning of what became some very successful change project:

We are different because…

                                          we are smaller

                                          we are bigger

                                          we make smelter power (still not sure how this one is different)

                                          we are older than the others

                                          we are a new facility

                                          we are on an island

                                          we are in the city

We as change leaders, have to help the group discover that they are capable of operating differently and that it is normal to think that they are different and that the improvements or tools will not work for them. This is a great time to show them examples of others who have made the journey and just how different they weren’t.

From a reliability improvement project standpoint we show them the deliverables, tools and process and then we describe how they were used in two completely different locations. We convince them of the existence of our version of the “The Grand Unification Theory” which states that standard improvement tools are universal and they work no matter what you do or where you do it. For instance process mapping works in hospitals and aluminum smelters. It works on all business processes. Root Cause helps the Navy solve problems just as well as the pharmaceutical industry. Failure modes analysis works on equipment and it can also be used on change projects as a risk identification and mitigation tool.  In the end these and other basic tools work to shape a solution that is tailored for their culture and can help them make the transition to "best practices" levels of performance.

So when you hear the words “but we are different” you know that this is your opportunity to educate on the dynamics of change, what they can expect during each stage, and the “The Grand Unification Theory”

Be different and make a change

Don’t Stop at RACI

I was recently in attendance for a “best practice” presentation where the presenter said “the value of RACI is in the exercise… we never looked at ours again”, and there I found my soap box.

Before I climb up on said soap box, let me first explain the acronym RACI, or RASI as some call it. RACI stands for Responsible, Accountable, Consulted, and Informed. In the case of RASI, the last two letters change to Support and Information. There are other variations out there as well. I have added one simple example below.

RACI is a tool we use during business process reengineering that clarifies roles for each step within the business process. So, to put this in the simple contexts of how it is used, we would first start by mapping out the “as is” or current state process. Then we would identify both valuable steps and waste. The waste would be engineered out and the valuable steps would be carried forth to the “to be” or target process. At this point, we would list who, by title, is responsible or accountable for each step in the process. This is where the presenter stopped…

Here are a few of the problems associated with stopping at this point:

RACI are done in small focus teams; therefore, only a small part of the population that will be affected by the change is present.

Second, what if the HR-stored job descriptions do not contain these steps or, worse yet, contradict them.

Third, if we believe “what we measure gets improved”, then the changes in responsibility have to be associated with metrics to ensure the change.

In order to build this into the culture, you must take this a step further. You should take all the new RACI tables for your business process and reorganize them by job title. You then take this list of tasks by job title and compare it against your existing job descriptions. Are they the same? Can one person do all of the activities from the RACI and the job descriptions? In many cases, the job descriptions are old and out dated and when they are compared to the RACI task list, it is more than one person can handle. At this point, you begin to combine the two and redistribute the work. Remember, if you change anything from the RACI list, you have to go back and revisit the processes and original RACI documents. Once you have finalized the new RACI job descriptions, then you create performance metrics to drive the changes and use the new document in all performance reviews. If you take this extra step, then your performance management system and metrics will be linked to your business processes, which in turn will drive the new behavior that the business process reengineering effort requires for success.