CHANGE: Don't be a Statistic!

Change is inevitable, how you manage the organizational aspects will make all the difference

For decades the industry experts have been telling us that 70% of organizational change fails. These experts include recognizable names such as Kotter, Blanchard, and McKinsey. It’s a scary story! This means that 70% of changes fail to recognize a return on investment, and achievement of stated goals and objectives.

In service management the change could be the introduction of new technology, organizational restructure or process improvement. These changes could represent a significant investment of time, money and resources. So can we afford not to break the cycle and allow history to keep repeating itself?

Not only do failed changes result in wasted time, money and effort but they also make subsequent changes even harder. Failed changes result in cynicism, lost productivity, low morale and change fatigue. Expecting people to change their ways of working will be increasingly harder if they have been subject to a series of failed change initiatives in the past.

Failure is due to lack of focus on organizational change

It is my belief that 70% of changes fail due to the lack of focus on organisational change. Projects have specific objectives including on time, on budget and delivery of specified functionality. Projects install changes but do not implement them unless organizational change is included within the project.

If a change is to be truly embedded into the fabric of the organization and recognize the desired outcomes, there has to be a focus on the people. Organizational change is a challenge to many because it involves people and every one of those people is different. They have different desires, beliefs, values, attitudes, assumptions and behaviors. An individual may embrace one change because it is aligned with their value system and they can answer the “What’s in it for me?” (WIIFM) question. The next change may be rejected because that question cannot be answered or the change is perceived to have a negative impact on the individual, their role or their career.

Therefore before we embark on any change we need to clearly identify the target audience. That is anyone who may be impacted in anyway by this change, both directly and indirectly. We need to understand the target audience and their level of awareness for the need to change.

Through identification of the right sponsors for the change at every level within the organization, equipping them with the skills and capability to raise awareness and create a desire to change we are more likely to have a successful outcome.

Announcing is not implementing!

A communication strategy and plan is a key component of the organizational change program. It needs to address the needs of the audience, the key messages and how they will be packaged and delivered. The sender of the message is important. Messages around the business need for change are received better when they are delivered from the CxO level. Messages about how the change will affect an individual are better received from that person’s manager or supervisor.

We also need to select a variety of practices or activities to ensure that the change becomes embedded and people do not revert to old ways of working or their comfort zone.

In 2011 I wrote a book called ‘Balanced Diversity – A Portfolio Approach to Organizational Change’ which provides 59 distinct practices that can be selected from to embed change. Although the framework introduced in the book can be used for any change in any organization, I have discussed how it can specifically be used within IT service management.

In IT we often expect that providing people with some training or undertaking an ITSM maturity assessment will create the desire for change. It takes much more than that and because every change is different we need to use different practices that address the specific needs of the change and the target audience.

I don’t have the space here to discuss each of the 59 practices but a white paper on the subject can be read here.

Keep checking – there is no room for  ‘set and forget’

Finally it is critical to keep checking back to ensure that the change is being successfully embedded into the organization. We often talk about the Demming cycle in IT service management but don’t apply it to organizational change. We need to plan what practices we are going to use to embed the change, do them but them continually check back to ensure they are having the desired effect. If they are not, we need to act before the situation is irretrievable.

If you don’t want to become a 70% statistic and you want to ensure that your changes are a success, get some organizational change capability on your projects. It will be worth the investment.

Image – © Lilya – Fotolia.com

Not Invented Here…

Fieldwork at the Ostrich School of Coping Skills

One of the biggest challenges I’ve been put up against this year is probably the view that, if something wasn’t invented here, it’s no good. And boy, have I struggled with trying to make things look like we actually invented them here.

I won’t try to figure out why the ‘not invented here syndrome’ is so rooted in our organization. There are probably lots of reasons, historical, organizational, cultural, previous experiences and what not. Some experts tell me I have to change the attitude among my co-workers and kill the opinions that abound and are aimed towards massacring external influences. That would probably be a good thing, if you had the support and means to do it. I, and my ITSM colleagues, went for another approach.

The post-it walls

We have a ‘war-room’ on the third floor of the building where most of operations and tech department are located. That’s where people gather whenever there are major incidents going on, or just for debriefing when the nightshift go off and the dayshift starts. The walls of this room were once covered with whiteboards and huge post-its. Every now and then some manager would move the post-its around and write stuff on them during the meetings that were held there.

When we looked into this room we discovered that they had built a sort of an incident and problem management ticketing system with post-its on whiteboards.

As we are interested in having people working in the ITSM-tools we have, and actually following the defined processes, we of course asked:

Why don’t you use the ITSM-suite and the incident and problem management processes?

We mostly got mumblings and a lot of staring at shoes in response. The ones who spoke back did so in a quite animated manner. Some claimed that the processes were over complicated and useless, others argued that the ITSM tool didn’t meet their requirements or that it was too hard to understand how to use it.

No problem, we thought, let’s work together to change what doesn’t work well enough in the tool and the processes. However, the people in the room were not so interested in that.

First of all, they didn’t recognize what they did as incident or problem management, it was the ‘8:45 war-room meeting and that’s where we actually work’. So even if we had some shiny processes to help them do their job more efficiently, we weren’t welcome. Just for that reason.

Furthermore, not only did we miss the opportunity to control, but also the ability to measure the processes and activities. Apart from that, you had to be physically present in the room to be able to get all the information needed to work on the cases. The various managers had different ideas on how to do things as well, so we never got a chance to actually work in a process oriented way or with commonly agreed routines.

Inventing it here

We started by accepting the methods used in the room with the post-its and slowly but patiently planting small but important changes to the methods and the vocabulary. We did some parallel registration of the data on the post-its in the problem management ticketing tool, and we began to show the advantages of a tool that wasn’t physically restricted to a single room.

By now we’ve lost the post-its and we register and follow all PM tickets in the ITSM tool. We’ve started to deliver some metrics on what we believe should be important to the company, and we show that our methods get the job done faster and with better results than before.

There’s still a long way to go to make this stick throughout the entire organization and to be able to convince all the people involved that it makes a difference.

But, just the same, we have actually invented problem management here at my company and we are proud of it!

(Please just don’t tell anyone…)

Image Credit