Never underestimate the importance of change management

This white paper will get you thinking about your change management process, and help you figure out what works best for your organization and when.

Some of the topics covered include:

Tips for standard change success
Change evaluation - looking at what actually happened
Evaluating change success from the customer’s perception
Allowing for the ongoing evolution of changes and services

Receive a free copy of our white paper

Never Underestimate the Importance of  
By Ivor Macfarlane  
Never Underestimate the Importance of Change Management  
Effective change management is at the heart of successful service  
management, but it can be difficult to focus the resources available into  
getting the best return on the undoubted effort that change management  
requires. This white paper looks at some potential approaches to focusing  
that effort where it will deliver the best return.  
Specifically, it looks at accepting inevitable change without debate  
and empowering staff as much as possible via the use of increased  
standard changes.  
It also covers the concept of change success, which needs to be clearly  
understood and verified that it’s based upon delivered business value.  
The intention is to get you, the reader, thinking, and doing, more than simply  
lifting a one-size-fits-all change management process from best-practice  
guidance. Instead, I hope you can work out what works best for your  
organization and when.  
Never Underestimate the Importance of Change Management  
Change Management: Picket Fences  
and Living in the Community  
For many in the IT industry, the introduction to formal change management  
often starts with ITSM – through work experience of change advisory boards  
(CABs) or request for change (RFC) procedures, or via an ITIL, COBIT,  
ISO2000, or similar ITSM training course. Change management is certainly  
an important part of, and a powerful tool for, ITSM. But changes within IT also  
affect every other area of an organization, i.e. outside of IT. And conversely,  
in these days of pervasive IT, all changes initiated and agreed on without IT’s  
participation will no doubt also have IT consequences and aspects.  
It’s the siloed mentality that we often talk of within IT, and it’s perhaps a  
major reason for the perceived lack of benefits from change management  
where IT has traditionally tried to fence out the rest of the organization,  
and to fence in consideration of the change to within IT, or even to within  
IT operations. Or, perhaps the issue is that IT thinks that it can build an  
impermeable fence, when in fact the fence they manage is more like the  
picket fence we might erect at the edge of our residential property. It’s useful  
to define where ownership and responsibility for maintenance start and end,  
but we know that the picket fence will not stop the outside world’s influence  
on the things inside it. It lets in balls, cats, garbage, and more – and what  
constitutes “acceptable behavior” is largely set outside of the fence too, by  
our neighbors and society.  
So in this change management analogy, there is a need to combine local  
detailed expertise with fitting into neighborhood constraints and influencing  
factors. We can summarize this as follows:  
There are defined areas of influence and control. How you do things,  
i.e. change management, is your business but the output has to  
be acceptable to the outside world. And anyways, in the modern,  
technology-reliant world what you need to do or achieve is probably  
driven from outside of IT much of the time. So you must know who  
makes the decisions, who you have to satisfy, and the constraints that  
you are working under.  
You can rarely deliver the required change by only doing things inside  
the fence. Additional work will most likely need to be done outside the  
fence to actually deliver value from the change.  
Never Underestimate the Importance of Change Management  
Effective change for the wider organizational picture can only be done  
efficiently if there is collaboration across the fence or fences. This means  
talking, helping, and understanding the views of those inside and  
outside the IT fence.  
You just have to accept that you do not have total control of the change  
and change environment. Your home may be your castle, but modern-  
day castles require planning and permission for significant changes. And  
you don’t have to be happy about it but you do have to accept it.  
All of this really comes down to remembering who the IT services are being  
created, changed, and delivered for, and recognizing all the legitimate  
stakeholders involved. It should also be about recognizing that other people,  
and teams, have fence borders too. So any IT initiated changes shouldn’t  
dictate how others behave within their own picket fences. Instead, the  
change should set out the required inputs and outputs (not how others  
might achieve them).  
This effectively echoes the hybrid change management approach evolving  
in many organizations. These organizations take value from 21st century  
initiatives like DevOps – that preach broader organization-wide collaboration,  
uniting towards a common goal – along with retained value from earlier  
frameworks like ITIL that deliver the degree of rigor and control necessary in  
many elements of the wider organization.  
Never Underestimate the Importance of Change Management  
Embracing Pragmatism and Avoiding  
A large part of the issue, and a commonly-raised reason for rejecting  
formal change management procedures is that they generate bottlenecks  
without benefit, locking down change progress and speed in unnecessary  
bureaucracy. Much of that complaint, for many organizations, over the last  
20 years has been justified.  
However, this over-control of change procedures and a need to examine  
every aspect of every change was never mandated nor even desirable.  
Instead, a good change management process should have a range of  
features designed to prevent bureaucracy, and to ensure that detailed,  
expensive, and time-consuming focus is not given to any changes that do  
not justify it.  
Never Underestimate the Importance of Change Management  
Practical Change Management: Don’t Fight  
the Unbeatable  
Once we see that change management needs to take a broad perspective  
coupled with local concentration, it’s clear that many proposed changes are  
not actually ”requests” but instructions, or are effectively inevitable for other  
reasons. Such reasons might include changes to the external environment  
such as new laws, technologies, political circumstances, or culture. This  
idea can, in part at least, be related to the concept – introduced in the ITIL  
2011 Service Transition book – of a change proposal. Seeing at least some  
change proposals from senior management levels as inevitable, and being  
pragmatic about them, can reduce wasted time and effort. More importantly,  
it can free resources to focus on assessing and questioning those changes  
where an informed decision is required.  
Therefore, a flow chart’s steps for that kind of change might look something  
like this:  
Step 1: Is it inevitable that this change will happen?  
For example:  
Has the board already approved it, and its funding?  
Is it a legal requirement, or mandated by a policy the organization is  
committed to?  
Does someone sufficiently above your pay grade want it enough?  
None of this, of course, means that it’s necessarily a sensible request (see  
later steps for that) but just about any one of these reasons means that you  
will be wasting your time considering the change in terms of “desirability.”  
In short, you are not being invited to assess the change or to give approval;  
you are being told to do it. Accept this and move on to the next steps.  
Step 2: Does the change make it clear what the required  
outcome is?  
Perhaps the change only talks about how things are to be done – such as  
“buy a particular software package,” “increase network capacity,” “duplicate  
system in a new location,” or “double the number of staff on the service  
desk.” If it’s about a new service, does it tell you what the business service  
being supported is, and what that business service’s success measures are?  
Never Underestimate the Importance of Change Management  
If the answer is no, then politely ask why the change is happening, because  
you’re allowed to suggest alternative ways of delivering what’s wanted. Even  
when the idea comes from the top, it’s constructive for change management  
to realize that there are better – and especially cheaper – ways to deliver  
what the requester wants.  
However, if you do that and it’s still being mandated by someone who you  
know you cannot win an argument with, you can be resentful but don’t  
waste more efforts trying to beat it.  
But do ask if it’s feasible and legal. As the expert “inside the fence” you’re  
allowed to point out that what is suggested cannot be done, or would break  
rules that the organization generally adheres to. This includes company  
policy as well as the law of the land.  
Also, if the skills or capacity to do the change aren’t available, then you  
need to say so. Others may not listen to you but you should document the  
question and answer. If you do not raise the issue as it happens, then you  
will be blamed for later failures.  
Step 3: Now make it happen.  
If you’ve established the outcome required, this should allow you to work  
with other parts of the organization – and suppliers, partners, etc. – outside  
the fence. In fact, it should make it essential.  
Never Underestimate the Importance of Change Management  
Don’t Sweat the Small Stuff  
At the other end of the change spectrum, the most valuable change tool in  
the ITIL box is standard change. This term was first used in the 1990s and  
adopted into the development of ITIL V2.  
Standard changes are usually described as pre-approved changes of low  
impact changes that do not need to be debated and considered as to  
whether they should be accepted and implemented. What this means is that  
no time is spent on assessing them. The more changes that an organization  
can deal with as standard changes, then the more resources and time the  
organization will have to consider the changes that do need to be carefully  
thought through.  
If standard change really is the key to success, what are the ways to expand  
its use? Some relevant tips and approaches include:  
Having an ongoing mechanism for creating standard changes.  
Just about all standard changes didn’t start out that way. The first  
time that a particular kind of change is requested, it will need examination  
and assessment. It ’s only when it becomes frequent that it becomes a  
candidate for the routine and is moved over to become a standard change.  
Looking for more candidates for standard-change treatment.  
Actively research through recent changes; look for trends and for the  
kinds of change that (just about) always get approved. These should  
not be going through the normal change routes, tying up resources and  
creating change backlogs and bottlenecks, when the standard change  
route could be used.  
Not getting hung up on homogeneity – your organization is almost  
certainly not uniform. There will be kinds of change that you could  
delegate to be standard changes in some parts of your organization,  
but might be considered risky in others. So do that. Nothing in the  
ITSM best practice guidance suggests that a standard change has to  
apply to every part of the organization, nor at all times. Perhaps at peak  
business times you need to block some standard changes, and perhaps  
encourage them when you can be less risk-averse. This attitude might  
also effectively move change to safer times too.  
Understanding and maintaining your standard changes using the  
same process, tools, and publicity as you might for services and  
service requests (which is what standard changes effectively become).  
Maybe formalize this as a standard change catalog to match (or to be  
part of) your service catalog.  
First used by Alexander Kist in the 1990s.  
A term I first heard used by Jenn Ostrom, in 2015.  
Never Underestimate the Importance of Change Management  
In fact, as with most management decisions, good use of standard changes  
is based on simple risk management, which means taking the right level of  
risk on purpose. There may be risks attributable to failed standard changes,  
but they are likely to be outweighed by the benefits to the organization –  
benefits that come from faster and less expensive implementation using  
standard change procedures.  
The combination of accepting inevitable changes, and encouraging  
standard changes, allows available resources to focus on considering those  
changes where a skilled and informed decision is required – as shown in the  
diagram below.  
Change Spectrum  
Focus resources where you  
will make a difference  
as usual  
from on high  
Never Underestimate the Importance of Change Management  
Understanding Change Success  
One common change management question, and one that I’ve been  
asked many times, is “What success rate should we being aiming for in our  
organization?” However, not once in seeking clarification from the askers did  
I get a meaningful answer to my question back to them: “What constitutes  
success for changes?”  
When there is something measured it almost always seems related to “Did  
we do the change as we were told to?”, or maybe even “as we decided to?”  
If we go back to thinking outside of our fences again, there should be better  
questions to ask if we are to establish the success or failure of change.  
Maybe questions such as:  
Is what we have done useful?  
Are we delivering any of the requested outcomes?  
What did it cost, and how long did it take?  
What else – good or bad – happened because of what we have done?  
And there’s also an issue around when the success of a change can be  
established. Is it when:  
The new hardware, software, etc. is installed and working (technological  
success only)?  
People can use it (feasibility)?  
People actually do use it (acceptance)?  
It is perceived as normal practice (incorporation)?  
As we go down the list, it’s clear that success will need to involve looking  
outside the fences. For significant changes – something that will affect the  
way people work in the organization – really measuring success relies on  
taking the time to find out about the business value delivered.  
And then, how good does it have to be for us to call a change successful?  
For example:  
Does it have to delivery everything required, just the important things  
agreed beforehand of course), or maybe it just needs most things  
51%, 80% say) to be considered worthwhile?  
How much damage is acceptable? Is the change a success if it does  
everything it was meant to, but now other things don’t work so well?  
Does it have to work for everyone, or is making it right for the most  
important people enough?  
Clearly, there isn’t one universal measure of success. But there doesn’t have  
to be just one measure of success in an organization either. Each change can  
and arguably should – be assessed beforehand for what would constitute  
success. As with standard change, if your organization isn’t homogeneous  
then neither should your change management success parameters.  
Never Underestimate the Importance of Change Management  
Change Evaluation – Looking at What  
Actually Happened  
Evaluating a change involves looking at what’s actually happened as  
opposed to focusing on whether you’ve done what you set out to do.  
It is rare for any change to deliver only exactly what was intended. Most will  
exhibit some side effects, and many will deliver only some of the desired  
outputs. Assessment of final success depends on looking at what the  
changed service actually does, ideally without being diverted too much by  
knowing what was meant.  
While this degree of total evaluation is only really appropriate for significant  
changes affecting the organization, some of the concepts do have  
wider application. Real success measures for a change cannot be done  
immediately; there needs to be time allowed for things to go wrong before  
claiming success. But as well as the links into incident and problem  
management to establish what might have gone wrong, an organization  
can (usefully) also try to track what has gone unexpectedly right after a  
change. Of course it’s not always easy, but evidence can come from service  
desk, service review meetings, business relationship management, account  
management, and more. Clues may also come through network and  
capacity management activity identifying unexpected usage of services.  
An analogy as an example of evaluation  
Imagine that you have booked a beach holiday. You are planning  
to relax, sunbathe, swim, and drink cocktails. Just before you  
leave, due to political turmoil at your intended destination, the  
tour operator cancels. Nothing similar is possible and they offer  
you a holiday in a mountain region instead. You spend two  
weeks walking, exploring the villages and local restaurants, and  
sampling a wide range of local wines. Assessing the success  
of the holiday against your intended results shows it as a failure  
even though you had a great time. Final evaluation should show  
the holiday as a success, albeit an accidental success.  
Never Underestimate the Importance of Change Management  
Evaluating Change Success – Customer  
Perception is Key  
Most people don’t consider themselves recovered from illness just because  
the doctor tells them that they’re cured. They decide that by themselves.  
Similarly, the customer, not the supplier, decides change success. So,  
ultimately, change management needs to be viewed from the perspective of  
the service customer. Therefore, getting the change right – and accepting or  
rejecting the right changes – logically relies on a customer perspective.  
IT and business people often have different attitudes, focuses, and priorities.  
This is especially so with IT services that support non-technical aspects  
of an organization. This makes it very hard for IT staff to really develop  
full appreciation of the customer perspective, and so successful change  
assessment and implementation require a significant degree of active  
involvement from the business staff.  
Allow for the Evolution of Changes and  
Earlier we discussed the need for delay between the implementation of a  
change and the final assessment of its success because we must allow  
enough time for any slow-to-surface issues to be noticed. In part, this is also  
required because of the ongoing evolution of services and work practices.  
As with Darwinian evolution, services evolve through trial and error (known  
as the Deming Cycle if it’s being actively driven by improvement programs);  
and acceptance/rejection can be influenced by external factors as well as  
internal innovation.  
The most perfect execution of change can appear as a failure in practical  
terms if other factors affecting the service change. For example, say you  
have what seems like a good improvement to a financial management  
service. Following a change to financial regulations down the road, the  
“improvement” might actually become inappropriate, despite how well it was  
implemented originally.  
Never Underestimate the Importance of Change Management  
For success in change management, an organization needs to be  
concerned with the broad perspective and with the detailed examination  
and delivery of all the aspects of a change. One of those aspects will be IT.  
So IT needs to apply internal expertise and also to work with other service  
providers and with customers/users.  
Knowing that efforts are successful is essential but complicated, and again  
requires broad involvement to be meaningful.  
There are good techniques within the available best-practice guidance to  
reduce the bureaucracy of change management. That, in turn, allows IT  
departments to focus their limited resources on where the best return will  
come from. Organizations will then be able to get on with most change  
unencumbered by bureaucracy, taking advantage of modern approaches to  
change, innovation, and rapid deployment.  
Most importantly, successful change management is not a cut-and-paste of  
what works at other organizations. Instead, you need to find out what works  
best in your organization.  
Want to learn how SysAid can help you improve your change management?