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

Rob England: The People in ITSM

Maori proverb: "He aha te mea nui? He tangata. He tangata. He tangata." What is the most important thing? It is people, it is people, it is people.

It’s all about the people.

A service exists to serve people.  It is built and delivered by people.

Even in the most technical domains like IT, the service is about managing information for people to use, and managing the way they use it.

When we change IT, a lot of the time we are ultimately changing the way people behave, the way they do things.

There is an old mantra “People, Process, Technology” to which I always add “…in that order”.  By which I mean prioritise in that order, and start in that order.

People, Practices, Things.

Actually I don’t like that mantra; I prefer “People, Practices, Things” as a broader, more inclusive set.  Either way, it all starts with people.

We’ve been using railways (railroads) as examples for this series of articles.  Ask a railway how important the people are.  Railways are complex and very dynamic: they need to adapt to constantly changing conditions, on a daily basis and across the decades.  We are slowly getting to the point where we can automate the running of railways, but only because the trains run in a tightly designed, constructed and operated environment that relies on people to make it work and keep it safe.  Much like IT.

I’ve never bought into this feel-good stuff about successful companies being dependent on a caring people culture.  Some of the most successful railroads in the ultra-competitive US environment have pretty rough people cultures – they treat their staff like cattle.   And other railroads are good to their people – though most of them are off to what we would consider the tough end of the spectrum.  I don’t think it correlates.  I could say the same about software companies I have worked for:  from second family to sweatshop.

However it is probably true that all successful companies have a strong culture.  Staff know how it works.  They may or may not like the culture but if it is strong they identify with it and align to it, to some extent.  So culture is important.

And cultural change is hard – in fact it is a black art.  The bad news is that changing the way people behave – remember our first paragraph? – is cultural change.  Behaviours only change permanently if the underlying attitudes change.  And people’s attitudes only change if their beliefs move at least a little bit.  Culture change.  Fifty years ago railroads were places where men – all men – died regularly, learned on the job, and fought as hard as they worked.  Now the people are trained professionals and the first priority of most railroads is safety.  Twenty years ago the New Zealand Railways had 56,000 employees, couldn’t move anything without losing it, lost millions, and wouldn’t know what to do with a container.  Now 11,000 move record volumes of freight and do it profitably.

“Just because you can change software in seconds doesn’t mean organisational change happens like that”

You can’t make those transformations in short timeframes.  Just because you can change software in seconds doesn’t mean organisational change happens like that.  You would think railroads take longer to change hardware technology than we do in IT because it is all big chunky stuff, but really our hardware and software platforms change at about the same pace; years and even decades.   Plenty of Windows XP still around.

Technology is the fast changer compared to people and process.  Just because you rolled a flash new technology out doesn’t mean people are going to start using it any differently unless you ensure they change and their processes change.  That human rate of change is slow.  People  will change quickly in response to external pressures like war or threatening managers, but that change won’t stick until their attitudes and beliefs shift.  I bet the safety culture on US railroads took at least one generational cycle to really embed.

In response to a few high-profile crashes, governments in the US, UK and other places have mandated the introduction of higher levels of automation in train control over recent decades (despite the much higher carnage on the roads but that’s another discussion).  Much of this push for automation stems from frustration over driving change in behaviours.  Does any of this remind you of IT initiatives like DevOps?

Culture can change, and sometimes it can change quite quickly, by human standards.  It takes strong and motivational leadership, a concerted programme, and some good cultural change science.  The leading set of ideas are those of John Kotter and his Eight Steps to change, but there are many ideas and models now in this area.  In IT, everyone should read Balanced Diversity by Karen Ferris.  And you will find a multitude of suggestions on my free site He Tangata.

Whatever methods you use for change, pay attention to three aspects:  motivation, communication and development.

Motivate them in these ways:

  1. by getting them involved and consulted;
  2. by showing how they benefit from the change;
  3. by making them accountable and measuring that accountability;
  4. and by incenting them.

Communicate early, communicate often, and be as transparent about decision-making as you can.  Tough decisions are more palatable if people understand why.  Communication is two-way: consult, solicit feedback (including anonymous), run workshops and town-halls.

Development is not just one training course.   Training should be followed up, refreshed, and repeated for new entrants. Training is not enough: practical workshops, on-the-job monitoring, coaching support, local super-users and many other mechanisms all help people learn what they need to make change successful.

One final thought: examine your current and planned IT projects, and work out how much effort and money is being spent on the people aspects of the changes the project wants to achieve.  I’d love to see some comparative research on the proportions of money spent on people aspects of projects in different industries like railroading, because we in IT still seem to suffer the delusion that we work with information and technology.