Change Management – Surviving Implementation

The super power of a change manager is an “invisible shield”, just like Violet from The Incredibles

One of the things I’m getting asked about most this year is about getting the basics right – how to actually do change management in the real world. We all know that having good processes in place protect us all, ensures we meet regulatory guidelines and are generally just common sense, but what about using them so that we can build a better, stronger IT organisation? In this article, I’m going to talk about getting started and surviving the implementation phase. I’ll then follow it up with another article on how to actually run your change management process.

Let’s start from the beginning. change management sits in the transition stage of the service lifecycle. ITIL states that the objective of change management is “to ensure that changes are recorded, evaluated, authorised, prioritised, planned, tested, implemented, documented and reviewed in a controlled manner. In a nutshell, change management is about putting things in, moving things round or taking them out, and doing it safely and without setting anything on fire.

When describing the change process, I call change managers the guardians or protectors of our network. They ensure all changes are sanity checked, tested, reviewed, approved and scheduled at a sensible time. Their super power is an invisible shield (like Violet in “The Incredibles”) that protects the rest of the organisation from the adverse impact of change.

Getting started: Common Excuses and Ways Around Them

Change management is an incredibly important process because it enables you to manage, control and protect your live environment. Since the credit crunch, I’ve had more and more people coming to me saying that their change departments would either have to endure massive cut backs or stop improvement works. Here are some of the most common excuses I’ve come across for this along with some possible ways around them.

Excuse number 1: “We don’t have the time”. Ok, what about all the time wasted dealing with the impact of failed or unmanaged changes, firefighting incidents and dealing with the big angry mob camped outside the IT department waiting to lynch us for yet another mistake? Let’s be sensible, having a strong change process in place will lead to massive efficiency savings and the use of standard changes, models and templates will make the work involved repeatable.

Excuse number 2: “We don’t have the resources”. What about all the time spent going cap in hand to the rest of the business explaining why a key service was unceremoniously taken out by a badly executed change? Spin doctoring a major incident report that has to go out to external customers? I’d argue that you’re wasting resources constantly firefighting and if you’re not careful it will lead to stressed out departments and key individuals burning out from the stress of trying to keep it all together. Instead of wasting resources and talent – why not put it to good use and start getting proactive?

Excuse number 3: “We don’t have the money”. What about all the money spent on service credits or fines to disgruntled customers? Then there’s the less tangible side of cost. Reputational damage, being front-page news, and being universally slated across social media – not nice and definitely not nice having to deal with the fall out. Finally, what about compliance and regulatory concerns? Failing an audit could be the difference between staying profitable or losing a key customer.

Excuse number 4: “We can’t afford expensive consultants”. Ok, hands up. I used to be a consultant. I used to work for Pink Elephant UK and for anyone out there looking for an amazing consulting / training company then go with Pink – they rock. That aside, if you can’t afford outside help in the form of consultancy, you still have lots of options. Firstly, you have the itSMF. Again, I’m biased here because I’ve been a member, as well as a speaker for, and chair of, various sub groups and committees, all in an attempt to champion the needs of the IT service management community. Here’s the thing though, it’s useful war stories, articles, white papers and templates written by the members for the members. There’s also ISACA which focus more on the governance and COBIT side of things. There’s the Back2ITSM movement – lots of fantastic help support and information here. There’s the ITSM Review and blog sites from the likes of The IT Skeptic – lots of free resources to help you sort out your change Management process.

Excuse number 5: “I’m probably going to be made redundant anyway so what’s the point?” Yes, I am serious, this is an excuse I’ve come across. There’s no way to sugar coat it, being made redundant or even being put at risk is (to put it mildly) a rubbish experience. In that situation (and believe me, I’ve been there) all you can do is keep doing your best until you are told to do otherwise. Having a strong change management process can be a differentiator on responses to bids. Tenders as SOX compliance, or ISO 20000 accreditation can set you apart from competitors. Bottom line, we have to at least try.

Planning for Change Management

So how do you get started? First things first: you need to get buy in. Most management guides will tell you to focus on the top layer of management as they hold the purse strings, and that’s very true, but you also need buy in from your guys on the front line – the guys who will actually be using your process. Get their buy in and you’re sorted, because without it you’re stuffed.

So, starting with the guys at the top, you need to speak to them in their language and that means one thing – a business case! This doesn’t have to take forever and there are lots of templates out there you can use. The key thing is to explain clearly, in their language, why change management is so important. Things to cover in your business case are introduction, scope, options, deliverables and benefits. Now get your techies on board. There’s no “right” way of doing this. As someone with a few war stories to tell, things that have worked in the past include:

  • sitting down with your techies
  • templating everything
  • using the umbrella argument (more on that later)
Krispy Kremes can help

I’ve also found that bribing support teams with doughnuts can be very effective, as a former techie I can confirm that Krispy Kreme ones work particularly well.

Once you’ve got your buy in, gather and confirm your requirements.  At the risk of playing management bingo here, a good approach is to set up workshops. Engage with both IT and the rest of the business so that there are no surprises. If you have an internal risk or audit department now is the time to befriend them! Using the aforementioned donuts as bribery if necessary, get their input as they will have the most up to date regulatory requirements you need to adhere to such as SOX or Basel 3.

Define the scope otherwise it will creep! Plan what you want to cover carefully. Do you want to cover all production equipment? What about test and DR environments? Whatever scope you agree, make sure it is included in any SLAs, OLAs or underpinning contracts so that you have documented what you are working to.

Keep your end users in mind

When writing your policy, process and procedures, keep your end users in mind. Don’t try to cover everything in red tape or people will find ways to circumvent your process. Let’s start with your policy. This is your statement of intent, your list of “thou shall” and  “thou shall nots”. Make sure it’s clear, concise and is in alignment with existing company standards. I know this might sound counterintuitive but also, prepare for it to be broken. It might sound strange but there will be times where something will need to be fixed in the middle of the night or there will need to be an urgent update to your website. It’s important that changes are raised in enough time for them to be reviewed and authorised, but exceptions will pop up so plan for them now when you’re not under pressure. Examples of when an emergency process could be used are:

  • Something’s broken or on fire (fixing a major incident)
  • Something’s about to be broken (preventing a major incident)
  • Major commercial reasons (in response to a move by a competitor)
  • A major risk to compliance has been identified (e.g. base rate changes, virus patches)

When looking at your process, make sure you have all the bases covered. This will include:

  • Recording and processing the change
  • Change assessment
  • Change Advisory Board (CAB)
  • Build and test
  • Implement
  • Review and close

I’ll talk about these in lots of detail in part two of this article.

Training & Communications

You’re about to go live with your sparkly new change management process and you want it to be a success so tell people about it! First, attend every team meeting, management huddle and town hall that you can get away with! Get people onside so that they know how much help change management can be and to reassure them they won’t have to go through lots of red tape just for the sake of it. Another way of getting your message out is to use posters. They’re bright, cheerful and cheap – here is one that I’ve used often.

Pelt front line teams with coloured balls if necessary! Not too hard though!

In terms of training you need to think about your change management team and your stakeholders, the people that will be raising changes using your process. For your change management team there are lots of practical courses out there that can help – a few examples could include:

  • ITIL Foundation
  • ITIL – Service Transition
  • ITIL – Release Control and Validation (RCV)
  • SDI Managers Certificate
  • ISO 20000

Other important considerations include:

  • On the job training
  • Shadowing

But what about your front line teams who will be raising the changes and carry out the work? Again put some training together – make it interactive so that it will be memorable – in the past I have been pelted by brightly coloured balls by a colleague in the name of explaining change management so there really is no excuse for death by PowerPoint!

Things to cover are:

  • The process, its scope and the definition of a change
  • Raising a change record to include things like implementation plans, back out plans, testing, risk categorisation (“no it is not ok to just put medium”) and DR considerations
  • Templates & models
  • Benefits

I’ve done a fair few of these in my time so if you would like some help or examples just ping me on my contact details below.

Go Live

So you’re good to go. You’ve gathered your requirements, confirmed your scope, got buy in and have written up your policy, process & procedures. You’ve socialised it with support teams, ensured everyone has been trained up and have communicated the go live date. So deep breath time, go for it! Trust yourself, this is a starting point, your process will improve over time.


I’ve written lots about metrics recently and have spoken about the basics in a previous article on availability, incident and problem management but in short:

You need to have a mission statement. It doesn’t have to be fancy but it does need to be a statement of intent for your team and your process. An example of a change management statement could be “to deliver changes effectively, efficiently and safely so that we put the customer at the heart of everything we do”.

Next come the CSF’s or critical success factors. CSFs look at how you can achieve your mission and some examples for change management could include:

  • To ensure all changes are carried out effectively and safely.
  • To ensure all changes are carried out efficiently, on time and with no out of scope emergency work.
  • To work closely with our customers & stakeholders to ensure we keep improving while continuing to meet their needs

Finally, we have Key Performance Indicators or KPIs. These give you the detail on how you are performing at the day to day level and act as an early warning system so that if things are going wrong, you can act on them quickly. Some example KPIs for change could include:

  • More than 98% changes are implemented successfully
  • Less than 5% of changes are emergency changes
  • Less than 10% of changes are rescheduled more than once
  • Less than 1% of changes are out of process

So you’ve survived your change process implementation – smile,  relax and take a deep breath because now the real work starts! Come back soon for part two of this article which will give you some practical advice on running your new change management process.

Image Credit 1

Image Credit 2

Image Credit 3

People and products: we all get old eventually

ivor graphWe all know that as we get older we lose some of our faculties and our usefulness changes. One interesting aspect of ageing workers is that it isn’t just about being good, bad, better or worse. In many jobs – and jobs as diverse as consultancy and bricklaying come to my mind – the actual deliverable usefulness changes as our strength and endurance fade but knowledge and experience grow to compensate and allow us to deliver continued, albeit different, value.

I suspect this feature, seen in the human species, is widely applicable, and extends even to best practice frameworks.

Let me try and explain what I mean.

For those of us who are parents, the first step to accepting the inevitable path to obsolescence and replacement is when we find ourselves asking our children to get something for us – because bending down or going upstairs is easier for them than us. Once past that point you have accepted not only aging but your progeny being better at things than you are. Inevitably that superior ability will spread from minor physical capability, like getting upstairs quickly, through to intellectual and perceptive ability such as understanding the world and innovation. For professional footballers, this tends to happen around 30, after which experience and positional understanding need to compensate for sheer speed and strength. For non-manual workers it is much later, but it happens just the same. The positioning of senility in best practice frameworks is less precise and perhaps still open to discussion.

Like parents, ITIL was originally young and fancy-free, and the only go-to place for building ITSM processes and practices. But in due course, ITIL spawned progeny (like COBIT, MOF and ISO2000[1]) – or alternatives if you prefer to see it that way. And some of those newcomers have now matured, as children do, to offer stronger options than ITIL for some aspects of the ITSM best practice world.

So, maybe ITIL has started to show its age, the joints are creaking a bit and we see some really interesting challenges from the next generation who understand the new environment a little better and maybe still have the flexibility to adapt more. More crucially, we see initiatives that don’t have to be bolted on to a historical behemoth of existing products and commitments.

Of course ITIL still has massive value. Like experience in craftsmen, the years of refinement, the market pervasiveness, global understanding and more mean ITIL still leads and delivers real value to those who use it to help them get better at service management. But like the aging craftsman with good apprentices, have we reached the point where ITIL has something to learn from the newcomers, rather than trying to stick to the idea that age and longevity equals right and correct and form the only way to go on?

Certainly it seems to me that some of the new ideas being floated challenge established ITIL detail in many ways but not ITIL’s experience, position and reputation. Preserving that (for want of a better word) authority in the industry will rely, to some degree, on accepting where others might now be better. Most of what originally went into ITIL came from elsewhere. Quite deliberately there was very little original put into ITIL guidance – the whole point of best practice is that it is out there working in the best organisations. Since ITIL’s launch we have seen, in turn, ITIL’s ideas instigate and invigorate new best practice ideas. That’s the good part of getting older, seeing your children be successes, perhaps even seeing them outdo your own efforts.

In practice, I wonder about ITIL in two ways.

  • It should be no surprise that in terms of basic mechanics and core strengths – like process details – ITIL is falling behind its younger children, friends or competitors. But the breadth and broader strategic focus that came with the later versions still sets it apart and gives it value – but perhaps a different kind and less exclusive value – experience taking over from strength? It is encouraging to hear Axelos talk about new white papers discussing the integration of ITIL and others best practices. But where does ITIL go? Should it compete head on with other process approaches, seek an overarching integration role, or simply claim it is the original and best?
  • Is ITIL flexible enough to take on new ideas, or should those ideas look to younger backs to carry them and just point out to them? As just one example, recent discussions questioning the merits in retaining a separation between incident and problem make real sense. But where will they get properly documented to gain broad acceptance? Because, for sure, we need a well documented alternative approach for any degree of acceptance. (Interestingly much of that idea has come from old human heads rather than young upstarts. I suspect that once the young upstarts do get going in our industry then the degree of challenge to established idea might go up by a few orders of magnitude. I’m rather looking forward to it all!)

As an ageing parent myself, I know the best chance of contentment lies in accepting my children’s now superior abilities, and in letting them do things for me. Certainly they now solve more challenges for me than I do for them. There is satisfaction that your genes – and lots of work – are actually firmly embedded into the future – the quickest route to immortality may indeed be via your children?

Of course, analogies should not be pushed too far and we need to see best practice use in its own right. We should expect much more overlap, some competition and hopefully a bit of mutual support. Oh, hang on; maybe they are like families after all?

The golden rule

But the golden rule for using best practices – be they for ITSM, cooking or anything else – has always been to look at all the relevant ideas and build what is best for you. In ITSM now we are both lucky and challenged to have a wider range of ideas than ever before. That might actually lead to diversity of ITSM approaches rather than the convergence to one (ITL based) view as we have seen in the last 20 years.

ITIL is the product in charge still, its market position makes it well placed to lead and inspire. Integration would be wonderful, but unlikely, coordination would be helpful, competition would be disappointing. Whichever way things go, ITIL made this happen, and should be proud of that. Learning from your children is a good trait, I’m learning a lot and enjoying the experience, hope ITIL will too.

[1] All of these acknowledged their basis on ITIL in their early versions