Change Manager

Careers in IT service management

Tracey Torble

• Editore: BCS, The Chartered Institute for IT
• Anno: 2019
• ISBN:
  9781780174662
• Argomento: Computer Science
• Categoria: System Administration

Change management is about the control of all changes that have an effect on the IT services and hence, the business of an organisation. This practical book describes the change manager role in depth including purpose, typical responsibilities and required skills. Change management methods, techniques, useful tools and relevant standards and frameworks are also covered, and career progression opportunities are discussed.

1 OVERVIEW OF THE FIELD

This chapter sets the scene for technical change management by first introducing the wider discipline of IT service management, within which technical change management sits, and then going on to define change management itself and describe the purpose, benefits and some of the perceived problems and difficulties associated with the process.

INTRODUCTION TO IT SERVICE MANAGEMENT

IT service management, in the context of this book, refers to a comprehensive framework of good practice processes that work together to support the delivery of IT services. Proactive processes conspire to design and implement robust systems that resist failure, while reactive processes provide a safety net for when failure is unavoidable. Together they maintain the integrity of IT so that end-users can rely on its availability when they need it.

IT service management is a mature concept that has evolved over several decades and has drawn ideas and improvements from many private- and public-sector organisations. Its success has evolved into generic service management, with concepts adopted beyond IT services. The IT Infrastructure Library, or ITIL^®, is a well-known IT service management framework, which, at the time of writing this guide, has begun its transformation into Version 4 (Foundation level manual and certification launched in February 2019 and more to follow. For up-to-date information about ITIL^®, see the Axelos website dedicated pages).¹

IT + service + management

Instead of restating that which is better expressed elsewhere, I offer my own perspective on an industry that was born in my lifetime but whose absence might now be unthinkable.

In the late 1980s, IT was just IT. Most of its output came from a central function; few people had PCs, and personal devices were only beginning to emerge (the brick phone). The concept of IT as a service for others to operate came later. For me, the shift came with the advent of email and the impact it had on the communication possibilities of the international company I worked for at the time. It significantly reduced the need for travel and making calls at unsociable hours, and users embraced it for its function rather than its novelty.

Uptake was quick and IT service provision rapidly became a full-time job. This happened so fast that we didn’t think about managing it at that stage. It was enough to keep up with demand as new technologies were adopted that transformed ways of working, and it was as much as we could manage just throwing down track ahead of the train. The first time the email system properly broke was the first time we stopped to look behind us, at which point the train ran us down.

Only at this point did we realise we must manage the service, not just provide the equipment, and as I progressed to new roles the world of ITIL^® opened before my eyes. This marked a turning point, when I stopped looking at IT from the bottom up and started looking at it from the top down. As a junior IT support manager in the foothills of IT service management, having a frame of reference gave me an invaluable perspective on the bigger picture and my relative position (and what was missing). I should point out that, to me then, IT service management meant ITIL^®, and it still does. I should also point out that other frameworks are available, and the generic term IT Service Management (ITSM) reflects that.

IT service management is about the management of IT services; there are as many ways to do that as there are practitioners. ITSM refers to the body of knowledge that suggests how best to go about it, based on the accumulated experience of many practitioners over many years. At one end of the scale, it is just guidance; it is not compulsory; you don’t have to do it all, or any of it, if it doesn’t fit your needs and you can take your pick of what does. At the other end of the scale, it has been formalised into an international standard – ISO/IEC 20000 – in which compliance is implicit.

Whatever the requirement, as with many ‘rules’ it pays to understand them before you break them, in the interests of efficiency and not reinventing the wheel. To do anything other than stand on the shoulders of giants in the fast-paced world of technology is surely wilful neglect.

For a more comprehensive view of IT service management, its history, its aims and its processes, there are many frameworks to consider. These are introduced in more detail in Chapter 6, with pointers for further reading.

INTRODUCTION TO CHANGE MANAGEMENT

Change management is one of many IT service management processes. In ITIL^®, it belongs to the Service Transition phase of the life cycle, but it is relevant from beginning to end. This section goes into more detail about change management and its pros and cons in IT governance.

What is change management?

ITIL^® definition

‘The process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.’²

Copyright © AXELOS Limited 2012. All rights reserved. Material is reproduced with the permission of AXELOS.

In practice, change management means establishing a way for all technical changes to be identified centrally, at the initiation stage, before any work is done, and channelled consistently through transparent planning, testing, implementation and review.

At a high level it might look something like Figure 1.1.

The throughput of change will vary according to local needs and methods. For example, major software projects might deliver one big change in accordance with traditional waterfall development practice, or lots of small ones in line with an Agile approach; maintenance changes might align with supplier or manufacturer cycles or be bundled to fit a more tolerable schedule in the organisation. Fixes might be packaged and scheduled or depend on an alternative emergency process, but a strong ability to implement short-term workarounds might help to avoid that.

Figure 1.1 High level steps in a change management process

Why is it necessary?

Here are some good reasons for having a change management process:

• Central control of change provides an overview of needs, plans and costs so that they can be approved, prioritised and managed efficiently.

• Rigorous planning, testing and review help to ensure successful implementation.

• Sharing plans across IT and the business means that everyone knows what is happening when and can plan their own activity accordingly.

• Outputs from change management are inputs to other processes, which are more effective as a result.

In the smallest organisation with just one person making technical changes, there is still some value in outlining a definitive change management process. It saves time planning by providing a standard checklist starting place for each change; it ensures that nothing is accidentally missed that could potentially result in a problem during or after a change and it provides a baseline from which to improve, through review and revision of the process and its success in delivering change that works. Making mistakes is forgivable; making the same mistakes repeatedly is not.

In an organisation with more than one person making changes it becomes even more important, as a change management process will provide a consistent way of working for everyone to follow. It ensures that everything being done is out in the open so that all stakeholders can identify the impact of others’ work on their own, it highlights potential conflicts and thus helps everyone to plan effectively.

In an organisation that is adopting other IT service management processes, change management is an important source of information without which the value of other processes can be curtailed. For example, incident and problem management make use of information about changes in their diagnosis; configuration management records are updated as a result of completed changes; and so on.

Furthermore, the processes embedded in ITSM generally, and ITIL^® specifically, are the result of decades of practice, review and revision, sourced from practitioners across a wide spectrum of industry and services. They have evolved as technology and our dependency on it have developed. Change management is one of those processes and it is therefore safe to assume that it plays an important role in the delivery and management of IT services, or it wouldn’t be included.

OK, it is necessary, but what are the benefits?

When we stop to think about it, the need for change management is obvious. It is about planning and executing technical change in such a way as to pre-empt any undesirable knock-on effects – things not working as they should after change has been applied, consequences not fully understood, preparation for all eventualities not made, delays restoring service after the fact. Whether from ignorance or blind optimism, the risks of proceeding without change management are too great.

The undesirable effects of change can derail business as usual. Those trying to get on with business can’t and those trying to get on with something else get drawn back into problem solving and fire-fighting the fallout. Obviously, this is not good for business and the bottom line is that it costs money. Most of all, it is avoidable; that’s why change management exists. To opt out of it knowing this is a risky strategy.

Benefits of change management include:

• reduces the risk of service downtime;

• reduces the need for business users to report service failures or experience interruption to their work;

• supports training and mobility across projects through use of consistent methods;

• p...