I'm A Change Manager... But Do Not Ask Me To Change. 3 Part Series

I was reminded this week during my travel that even when your business is facilitating change in organizations, change is still hard.
For those of you who travel regularly for business you probably read the USAToday newspaper. It ends up under or outside your hotel door every morning. For many of us it becomes a ritualistic part of our morning on the road. Well this week as I traveled I noticed the USAToday has changed... a lot. The content and the political slant are the same but the layout, logo, fonts and the headers are completely different. Things are not exactly where they were and now they have added new bits like the "tweet of the day." I have quickly developed a modest dislike for the changes. The format actually bothers me because it does not look like "my paper". My morning ritual has forever been changed and I was not involved or warned. As I have spoken with other business travelers they too were shocked by the major changes. And, what is up with that weird extra blank bit at the bottom of the page. But enough of the ranting, the real point is no matter who you are chances are you are not a big fan of change no mater what the size and scope. Change is even hard when it is necessary for survival.
So what can we as leaders do to facilitate changes and ensure they are successful?
Three things that I find that can help are project planning, risk analysis, and focused communication.
In this blog we will talk about the first of these, the project plan. It is a crucial step that many project that miss their projected return on investment treat as optional. In these sites they may start with a plan but do not edit the plan and keep it current. The interesting thing is the project plan meets the needs of the individual who is changing at every point in their change process. If you are familiar with Ken Blanchard and his Situational Leadership 2 model I believe the plan plays a key part in each of those four famous phases. It helps early on by describing the scope and elements of the change and answering how the individual will be affected. As the project progresses and the individual reaches what I call the valley of despair it breaks the overwhelming large project into small bite size task that can more easily be completed driving the change forward. As the individual hits the third phase of the change process the plan shows completed task or progress even when the overall change effort may have not made it to the point of generating a return on investment. This visualization of accomplishment is important to drive the project forward to completion. During this completion phase the project should be developing the projected return on investment and now the completed project plan is a trophy of sorts to take pride in the accomplishments and use as an example for others on how they can make the change as well.
Now if only I had seen the plan for the big change to the USAToday...

Fish Bone Alone Doesn't Deliver Root Causes

Chances are, fish bone or Ishikawa diagrams alone will not get you to the root causes. I refer to the fish bone as basic root cause tool. They serve a purpose and they do enable root cause investigations but they do not necessarily have the power to be a stand alone tool.
Let's talk about why and then what they are very good for.
The reason they are not able to give you all the root causes comes from the way they are used. In general they produce a categorized list physical causes and human causes but they do not identify  causal chains or underlying systemic or latent causes. Many times they only feature the symptoms of these latent causes as the bones of the fish. If you choose to only use the fish bone you have the potential to miss many issues and the connections that tie them together. I have reviewed many of these diagrams where the real root causes were just under the surface of the list but never brought to light during the investigation.
The real focus for me is the return on investment and if my root cause program is driven by only fish bone than I am implementing more solutions trying to address all of the identified bones of the fish at additional cost and I am more than likely suffering reoccurring failures driving lost production and additional analysis cost.
So what do I use the fish bone for? Personally I like to use it in three ways first as a lead in to the FMEA when working with a group that may have not used that tool before. I would take the bones of the fish and transition them over to a spread sheet or FMEA tool. This can help me get folks engaged and help to began the population of the next tool.
The second way that I use the fish bone is to is as a brain storming tool where we can identify many things that could have caused the failure and then I assign the individual bones to groups and they go out and look for data to confirm or deny the existence of that cause. Then when the team gets back together to apply the next tool and pursue root causes and solutions we have data to keep the process moving.
The third reason that I use the tool is as a facilitation exercise for when I have a quite or boisterous root cause team or team members. In this situation we use stick notes and we all write and stick causes to the diagram. This give the less expressive folks and alternative in writing instead of speaking and it allows the expressive folks to see the sticky note and know they were heard. This can get a group to develop many more possible causes and then they can verify, investigate and eliminate with data producing a better lead in to the next more thorough tool in your root cause process.
So to wrap it up fish bone analysis is a tool that has its place in the root cause process but if you want the lowest total cost of solution you will need to couple it with other tools from your root cause tool box. To read more on root cause check out these post from the past.

What are your thoughts?

News From the Reliability World: GPAllied Acquires ABB Reliability Services

NEWS from the Reliability World:
I wanted to double-blog this week to welcome a new team of coworkers to the Allied Reliability Group and GPAllied. This week we announced the acquisition of ABB Reliability Services and the old HSBRT group. I am personally quite excited to get to work with these great folks once again. We worked together in the past and I have learned both from and with them. I am convinced that what they bring to the table will make our organization stronger and allow us to provide more results for our clients. I look forward to some of them adding content here for the ReliabilityNow reader to enjoy.
I have never mentioned all that the Allied Reliability Group has to offer but with these additions I think a quick list is in order.
Total Plant Reliability Implementation
WCR Benchmarking with 30 years of history
Operator Care
Craft Skills
Reliability Engineering
Condition based maintenance
CMMS /EAM implementation
Planning and Scheduling
Rapid Action Teams
Change Management
Blended Learning Solutions
World Class Public Education

ABB RS welcome to the the Allied Reliability Group
Welcome to the new GPAllied

For more information please see the press release here!

You Don't Need an Asset Manager!?!

This week I am attending the Global Forum on Maintenance and Asset Management (GFMAM) executive meeting in Rio de Janerio Brazil. We are talking about things like the reliability, Asset Management Landscape and the upcoming ISO 55000 standard. One point that has been discussed quite a lot is the concept of an Asset Manager. In the US we are seeing companies and individuals "upscale" their titles from maintenance to reliability to life cycle management and now asset management. The sometimes missed point is that each of these is substantially different from the one before. You could argue that maintenance is a subset of reliability and reliability is a subset of asset management but even if you don't agree with that I would suggest that you might agree the scope of asset management is none the less very broad. If you would like to see GFMAM's asset management landscape which outlines the many elements click on the link above. So based on the breadth of the topic of asset management many of us have come to the conclusion that one person can not acquire the necessary level of knowledge to adequately manage the full scope and will not have the necessary time and focus.
My current understanding affords me the opinion that the best solution is an asset management core team. This team would be made up of an engineering manager, maintenance manager, operations manager, and a financial manager working together. If we use this structure we can cover all of the topics of the asset management landscape with an individual who has the understanding of the core concepts of asset management but also has the specific knowledge of the topics in their area of focus and function.  On the other hand if your organization goes with the stand alone asset manager, by the global definition, the individual will be overwhelmed and could find themselves in conflict with the other managers. By the nature of the job description the AM will play in the other manager's sandbox and at the least create a perception of minimizing their power and influence. 
What are your thoughts? Have you seen the asset management landscape? Do you have an operations or maintenance manager that reports to asset manager?