Roles and responsibilities in the ITSM change management process, goals, the 7 Rs, and differences between ITIL v3 and v4 – to keep you on top of things in ITSM.
- Best practices and pitfalls
- Standardized processes via ITSM tool
- Organizational change management: Focus on people
- Differences between ITIL v3 and v4 in IT change management
- Success factors in IT change management
- The 7 Rs of IT change management
Dr. Christian Klaus has a problem. After a serious failure in his company's IT system, he is called upon to revise the change management process. His focus is clearly on risk management, one of the seven Rs in ITIL change management.
Here is what happened
The trigger for Dr. Klaus' headache was a small change to the IT setup at a regional branch. The disruption had spread across a wide area and ended up severely impacting the entire organization's communications and video conference systems. Employees working from home were cut off. Meetings between management and customers as well as suppliers could not take place. IT worked for three hours until essential business processes were up and running again.
As an ITIL expert and process owner for IT change management, Dr. Klaus was now aware of the interrelationships that had led to the outage.
The root cause analysis had been performed, but there was no post implementation review. The change in the field office had not been approved by the change process, nor had it been made by a qualified and authorized person.
Best practices and pitfalls of IT change management
The change management process provided concrete steps for risk management to prevent precisely such failures. In addition, two years ago Dr. Klaus and the IT change manager had already drafted a policy that defined the best practices of change management according to ITIL and mapped them for the company's own IT organization. Regular training sessions were held for the teams, in which the content was repeated and discussed. All the specifications from the risk management of the change management policy had been undermined – they had simply been ignored.
Standardized ITSM processes via the integrated service management tool
Theory had failed in practice, where urgent concerns too frequently lead to the bypassing of processes. It was clear to Dr. Klaus that he would not get anywhere with disciplining the teams alone. He also had another pressing need. For some time, he had wanted to support and standardize the ITSM processes in his company with an integrated service management tool. It was important that it met these requirements on his list of priorities:
- better process control over
- a tool-based forward schedule of change (FSC),
- a cross-organizational calendar planning,
- comprehensive resource management, as well as
- management and control of all change management roles and responsibilities
- Authorizations for all process activities exclusively via integration with the company-wide LDAP system
- Transparency about dependencies and possible effects in the IT infrastructure
- Transparency across all change and release management activities from initial request to post-implementation review
- Processing and documentation of all change management and release management activities in the change management tool; completely based on the asset & configuration management database (CMDB)inventory
- Simple, traceable communication on the process steps in all change management phases – at best automatically mapped within the tool
- Comprehensive, transparent risk management as a prerequisite for successful work in the change advisory board (CAB) – especially in the evaluation of emergency changes in the eCAB
- Low-effort measurement and reporting of all relevant key performance indicators (KPIs)
- Simplification of the ITIL change management workflow
Dr. Klaus was certain that an ITSM software that could handle these requirements would make a significant contribution to improving change management processes. But tools and policies by themselves are no guarantee of success. Dr. Klaus knew that nothing would work without the people in the company. After all, it was already the employees who created the value for customers with their work.
Organizational change management (OCM): Focus on people
Of course, Dr. Klaus wanted to use the possibilities of automation in a tool. However, he was aware that the planned changes with regard to more control, transparency and rights management would not be approved by all colleagues right from the start.
He had a good feeling for the sensitivities of the team. The individual roles and responsibilities were important for self-determination, indeed for the self-confidence of many – not only at headquarters, but also in the internationally distributed organization. Tried and tested, sometimes beloved processes and routines had been established for years.
People knew each other. They understood each other almost blindly, even in the preparation and implementation of critical, complex changes and large deployments. Changes in the sense of delimitation or even curtailment could quickly lead to discontent, demotivation and political intervention at management level.
In his opinion, ITIL 4 with its new principles takes this into account. While the 26 life cycle processes from ITIL 3 formulate relatively rigid, rule-based processes, the 34 management practices from ITIL 4 grant freedom for the definition of customized processes. Dr. Klaus had high hopes for organizational change management (OCM) from ITIL 4, which relies on the principle of "simple and practicable". In addition, it seemed advantageous to him that one principle of agile change management had long been internalized and lived in the team anyway: the principle of continuous (service) improvement , including the continual improvements register. Both would facilitate the realignment within the organization.
The differences between ITIL v3 and v4 in IT change management
|Describes change management as a process in service transition.||Describes change management as a service management practice and calls it change enablement.
ITIL v4 lists the basic activities in change enablement as well as the key inputs, outputs and roles.
(IT) organizations can use these guidelines to design a customized process for managing changes that reflect their individual requirements.
Change enablement practice:
The change management process according to ITIL v3 does not become obsolete and can be used as a template for individual adaptation in the IT organization.
|Focus on service transition and deployment||
Focus on the service value chain including the design and development phase
Change enablement should be designed to keep the end-to-end service management value chain in mind.
An iterative approach is designed to balance rapid implementation of an RfC on the one hand with managing the associated risks to existing services on the other.
Success factors in IT change management
Change can only happen if there is a clearly defined goal and everyone involved has confidence that the effort can lead to success. Creating this transparency and confidence was Dr. Klaus' greatest challenge.
Dr. Klaus did not have to do much convincing to prevent future failures like the recent one in the communication systems. No one wants errors and contradictions in the process workflow, disrupted processes, failures and escalations. All those who cared about a cleanly functioning, high-performance IT infrastructure were able to agree on simply regulated, comprehensible and well-documented processes with clear responsibilities and controlled risk management.
Dr. Klaus made his plan:
- He would make a strong case for his list of requirements for the future ITSM tool in the purchasing process.
- He would reiterate the importance of an integrated asset & configuration management database and emphasize the connections to the recent incident.
- At the same time, he would urge that the request for information (RfI) be expanded to include those aspects that did not solely serve procedural, system-related functionalities. Tool functions that enable transparency and automation and thus make routine work superfluous should be given more weight. More attention should also be paid to easy handling across different devices and channels.
He was pretty sure that only then colleagues would quickly embrace the changes. Only then could the changes be quickly activated in the IT change management process. And only under this condition would he be able to fulfill his mission of ensuring that major outages were prevented quickly and reliably in the future.
The 7 Rs of IT change management
One success factor for Dr. Klaus was the seven Rs. But what are they exactly?
The 7 Rs of IT change management are a checklist of relevant aspects that should be considered when creating and processing a change request. The seven simple questions help to launch changes in a structured way, which would otherwise be rejected because of too many ambiguities.
1. Who RAISED the change request?
In the abundance of departments, contact persons and co-decision makers, change requests on demand are a guarantee for chaos. First, we need to clarify where the request comes from. For whom are we doing this? Where do I get answers to queries? Systematically documenting this is the first step for structured IT change management.
2. What is the REASON for the change?
Why are we doing this? For what reason is the change needed? A good solution is worth nothing if it solves the wrong problem. On the other hand, a change often sketches out solutions that block the view of a better idea. If we gain clarity about the reasons for the change, risks and opportunities can be better assessed. For important issues, we then look for the solution that best fits the context, while avoiding high-risk changes with minimal business benefit.
The portfolio analysis along the four-field matrix helps with the classification, whereby the changes can be sorted along the two axes (1) impact (e.g., number of users and devices) and (2) urgency, similar to incident management.
3. What RETURN is required from the change?
Nobody knows the future and yet it is important to play out different scenarios. What should the change result in, so that we can say afterwards: it was worth it. Not every change translates directly into customer benefits that justify a surcharge for the software, for example in the form of a software feature. The automation of time-consuming manual tasks, on the other hand, can free up capacities in development for innovations. Automated regression and load tests relieve technical support. The reduction of technical debt keeps the development environment future-proof so that it can react quickly to innovations on the market. These soft factors need to be translated, as well as possible, into hard metrics with an eye to costs and benefits that can be used to prioritize.
4. What are the RISKS involved in the requested change?
While we focus on the optimistic side of returns with a best-case scenario at the end of the scale, we take a pessimistic view of risks with a worst-case scenario. Every change involves risks. Some can be avoided, others may have to be accepted if the opportunities on the one hand or the disadvantages of not implementing the change on the other hand outweigh the risks. But it is to be expected that changes in one part of the system will have an impact on other areas. The consequences should therefore be worked through in advance.
5. What RESOURCES are required to deliver the change?
At the macro level, this is always about time and money. At the micro level of IT change management, it is about people (skills) and machines (capabilities). These do not exist – or are missing – in a vacuum. If the forces are tied up in one project, they are missing in another. Do we tackle both anyway? At the same time? What delays occur elsewhere when we implement a change? The question does not stop with the internal IT organization, but encompasses the entire customer value chain all the way to the customer. Answers to these questions must also be incorporated into the prioritization of IT projects.
6. Who is RESPONSIBLE for the "build, test, and implement" part of the change?
Who is going to do it? Who builds, tests and implements the change? In most cases, there are different people in the team or even different departments for the individual sub-steps. Therefore, it is all the more important to make responsibilities transparent and comprehensible on the one hand, and thus implementable and enforceable on the other. It is then unmistakably clear who must take action for which task and, in the event of failure, unproductive recriminations can be avoided. Throughout change and release management, responsibility must be clearly distributed and transparent to all.
7. What is the RELATIONSHIP between the suggested change and other changes?
IT environments are complex and have many dependencies across other areas and functions in the system. Sometimes it is enough to point out effects in other areas, in other cases you have to rely on their preliminary work. An integrated configuration management database (CMDB) makes mutual dependencies transparent and enables joint time and sequence planning for implementing changes with the least possible downtime and time delays.