In working with customers’ IT Service Management initiatives across industries, one of the most common issues I hear is that many new or modified services are “thrown over the wall.” You know, that feeling that all the Operations staff get when confronted yet again with another change that needs to be implemented, preferably yesterday (because the customer wants us to), with no questions asked. For example, the change may not be fully tested, missing a tested back-out plan, have incomplete or nonexistent release notes, or be without a communication plan to support the implementation plan.

Service Transition is basically the bridge between Service Design and Service Operation. The processes identified in this phase of the Service Lifecycle are:

• Transition Planning and Support
• Change Management
• Service Asset and Configuration Management
• Release and Deployment Management
• Service Validation and Testing
• Evaluation
• Knowledge Management

All these processes, when carefully planned and implemented, will help you break down the “wall” between the Service Design side and the Service Operation side of the house. Let’s go over a couple of things to consider that help with this.

Use ITIL as a Guideline, Not a Goal

Although most of us, when referring to ITIL's Good Practices, will say ITIL should be used as a guideline, the majority still doesn’t really know what that means or how best to do that. As Oscar Wilde once said, "Rules are for the obedience of fools and the guidance of wise men." The wise will use ITIL as a guide, enabling organizations to adopt and adapt ITIL. Key to this, however, is that organizations need to understand what their requirements are, and what it is they want improved or corrected. Quite often, I run into CXOs who “manage by magazine.” They heard they need a CMDB, Change Management, SLAs and Service Catalogs, but when asking why they want those implemented, essentially what the business justification is, more often than not, they do not know the answer.

Service Asset and Configuration Management vs. Configuration Management System

Another challenge in many organizations is understanding the difference between “Service Asset and Configuration Management” and the “Configuration Management System.” Basically, it comes down to “Process” versus “Technology.” Often I see that the implementation of this process is mainly focused on the technology piece, rather than the process part of it. One needs to keep in mind “a fool with a tool is still a fool.” It is important to understand first what the information requirements are. The key here is “information” requirements, not “data” requirements. I see a lot of efforts focusing on defining and gathering an enormous amount of data, without knowing what information is really required, for example from a Service Level Agreement, Key Performance Indicator or Process perspective. If we look at the purpose and objectives listed for this process in the ITIL v3 book, they can be translated into the following.

• The information provided is used for decision-making purposes. Hence, the information needs to be accurate. Inaccuracy inevitably leads to incorrect decisions, which will lead to unstable and inflexible services.
  
• The information needs to be accessible. This means more than just physically accessible. It also means accessible from a logical perspective. Many times, “information” maintained by engineers is only understood by those engineers and not the rest of the organization. As a result, although physical access to the information is granted, the rest of the organization cannot use it for decision-making purposes.
  
• Last, but not least, the information needs to be timely. Accurate and accessible information becomes meaningless if we cannot get to it when we need it.

Accuracy, accessibility and timeliness are the key components to be applied to the limited amount of data needed to provide decision-making information as opposed to all data available out there.

Change Management Bureaucracy

Change Management is often seen by the organization as bureaucracy. It is a fact that Change Management introduces bureaucracy into the organization and there is no reason to deny it. The bureaucracy can be mitigated by providing an ROI. This means we need to focus on professional bureaucracy, demonstrating that the short-term investment of time leads to long-term reduction of time and money.  This reduction of time will be experienced in other areas such as Incident Management where we should see a reduction in adverse impacts of our changes.

Another important key factor is to understand that with Change Management we are looking for a way to manage and facilitate changes in such a way that we are in control of all changes in an effective and efficient way, and we ensure the stability and flexibility of our IT services by doing so. Being in control of all changes means we need to ensure the Change process encompasses all the different ways change requests can be introduced, e.g. “request for change” documents, service desk calls, project initiation documents, etc. Organizations need to ensure appropriate procedures and forms are available to cover all anticipated requests. Remember, one size does not necessarily fit all!

Change Impact vs. Risk

One of the things organizations are very confused about is the change impact. Here, again, most people seem to know the definition, but when applied, quite often what is being referred to is the impact when the change goes wrong. This, however, is part of the risk of the change. The change impact is the effect to the organization, to the service and/or to the service levels when the change is being implemented. Together with the urgency, the impact determines the priority of the change. The risk of the change also determines the level at which the change needs to be controlled and approved. Here is where, next to the likelihood of the change going wrong, we look at the impact of incidents if and when the change goes wrong. It is very important to distinguish between these two to ensure an effective and efficient change process.

Of course, you and I both can come up with many more considerations that are helpful. I encourage you to send me some of your examples or send your comments on those in this article.

About the Author:
Adriaan van de Rijken, ITIL Service Manager and Practitioner serves as Executive Consultant at Plexent, an IT Service Management company.  Adriaan has specialized in organizational change and provided strategic advice on Service Management to the business side of IT for more than 20 years.  You can reach him at avanderijken@plexent.com or 972.381.0077.

 

Previous Article | Next Article