By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
ITIL is a term often bantered about by software teams and project managers, but what does it stand for and how is it used in organizations? This article explores a brief introduction to ITIL and how Change Management is addressed in an organization which employs an ITIL methodology.
ITIL is the abbreviation for the IT Infrastructure Library and was originally developed by the British government in the late 1980s. ITIL had a modest beginning and was designed to help standardize the services offered by the UK's data centers. Today, ITIL is a methodology implemented around the globe by diverse IT organizations and corporations, large and small.
ITIL began with a series of more than 40 manuals covering IT service management (ITSM), however, in 2007, ITIL V3 (also known as the ITIL Refresh Project) was released, streamlining ITIL so that it now consists of 26 processes and functions that are grouped under five volumes with the focus around the concept of Service Lifecycle. ITIL V3 meets the current rigorous statutory demands placed on organizations as well as new technological updates. "Probably the best way to describe the difference is to look upon ITIL V2 as being process-oriented, whereas V3 is much more service-oriented," says Rob Potter, manager of best practices at TeamQuest Corp.
The five volumes of ITIL V3 are:
- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement
Change Management, the topic of today's article, is found under the Service Transition volume, which guides organizations on creating repeatable processes, among other things, to assist in transitions in new or existing services.
The following process map illustrates the standardized methodology employed by ITIL for change management and can be found on ITIL.org's website.
As shown on the above process map, breaking down and understanding ITIL's change management methodology is not difficult, as these steps are most likely already followed by most change management teams, which ITIL calls Change Advisory Boards, or CAB. Once a CAB is established under ITIL's guidelines, requests for changes (RFC) are: received; tracked; reviewed; implemented, if accepted; documented, if rejected; with follow up after implementation. ITIL also establishes a separate Emergency CAB or ECAB.
ITIL's change management has been tested and proven reliable and trustworthy throughout the years as it enhances the IT organization's reputation, increases productivity, with less adverse impact on software and services. However, as with most things, one change management methodology does not serve all aspects of a software project.
For example, ITIL recommends that the CAB consist of highly experienced and senior key individuals who look after the interests of the customers. While these individuals offer invaluable insight and vision to any team, CAB responsibilities include drilling down into each RFC to understand the change request and the impact on the software, along with the sometimes rather tedious effort of prioritizing approved RFCs for future release packages. Such details are usually not in the scope of senior and key individuals, thus they may not make the best CAB members. Rather, consider members who use or support the tool regularly and know the inner workings of the project. These are the people who are passionate about release package items and who will make the time to attend meetings. They will also be willing to drill down into the possibly mundane details that will best serve the end-user or customer.
Another area to carefully consider when implementing ITIL's change management has to do with emergencies. ITIL recommends an Emergency Change Advisory Board (ECAB), which is made up of two experienced service employees. The above process map depicts the ECAB as a separate entity or board, rather than an integrated role within the existing CAB. The danger with this is that the ECAB may make decisions that do not take into consideration already established long-range plans and goals of the CAB. The process map attempts to have the ECAB's triangle merge into the space of the regular RFC process, but even this could result in contrary decisions being made by the ECAB. A good rule of thumb is: One software, one Change Control Council (CCC). Emergencies are best handled by the team that understands the day-to-day operations of the software and is fully briefed on the long-range goals and plans. This is best filled by the existing CAB, not a separate entity that may or may not have full knowledge of the CAB's inner workings.
ITIL also encourages a standardized risk assessment process to simplify the review and approval of change requests. This process is intended to identify the risks that are involved should a change not occur. The ITIL risk assessment distinguishes between two categories of change, critical and non-critical. This is a good place for a CAB to start with regarding its prioritization of requests, but it should not be deemed all encompassing. For example, a non-critical change can have an important impact on the end-users' experience, even though there is no real risk to the software. In addition, non-critical changes may be readily inserted into software code that is part of a release package with minimal effort or cost. Simply organizing requests into critical and non-critical categories, even if based on standardized criteria, can limit the overall success and robustness of a software application.
The benefits to ITIL's Change Management are many, including the creation of a CAB, improved risk assessment through preliminary analysis of critical vs. non-critical changes, and reduced incidents due to managed change through standardized processes. However, ITIL's change management methodology may not always fit an organization's individual needs. When applying ITIL to your organization, be sure to add some common sense for best results.
Kay Diller has worked in high tech for over 15 years, mostly as a software release manager and business writer. She has led many IT change control councils, which is where she came to appreciate the strength a CCC brings to any software application.