No matter the size of the organization, the industry, or the market sector, and no matter how long it has been in existence or how dependent it may or may not be on technology, every organization struggles with change. Projects run over time and over budget. New elements seem to break what was working before. Rollouts fail part way through, with no clear way to get back to the starting point. And all the while, we are hemorrhaging time and money, and losing credibility with the business.
These are just a few of the challenges that the guidance in the Information Technology Infrastructure Library (ITIL) Version 3 is intended to help address, in particular through the volume covering the third phase of the service life cycle: Service Transition.
The use of the word "transition" is significant. How often have IT professionals complained about applications being "thrown over the wall" (the project or problem is passed to another department without consultation) from development into production with little or no visible support? Development and operations play the blame game, while the customers and users wonder what's going on and why it just can't work.
Merriam-Webster defines "transition" as "passage from one state, stage, subject, or place to another." This definition brings to light the fundamental questions that need to be asked and answered in a successful service transition strategy:
How can we be sure that we know precisely what the new state will look like?
How can we ensure that we know precisely where we are starting from?
How can we ensure that the new state has been fully achieved?
ITIL V3 tries to answer these questions with greater depth and precision than in earlier versions. Many of the processes, activities, roles, and functions involved in successful transitions are addressed in ITIL's guidance on the second phase of the service life cycle: Service Design. The position the book takes is that if service transition starts from the position of a comprehensive design, then the first question above should be well on the way to being answered.
And it can reasonably be argued that successful design is not possible without having some fairly robust answers to the second question as well. This is one key lesson of ITIL V3—everything we do affects everything else we do. Relationships between the elements of information technology service management (ITSM) are not purely linear.
While effective and efficient service transition is enabled through coordinated effort in all the phases, it is naturally most sharply focused in the transition phase itself, in the work described in these processes:
- transition planning and support
- service asset and configuration management
- change management
- release and deployment management
- service validation and testing
- knowledge management
The work of these processes is designed to address the issues every organization has experienced with change in a way that will embed repeatability into work methods. Why fix a single project when you could improve the conduct of them all? Why treat only symptoms; why not attack the underlying disease? The following will take a brief look at the organization of some of the most impactful advice from ITIL V3 on the subject of service transition.
Transition Planning and Support
Symptoms: Organizations with weakness in this area are likely to present symptoms such as insufficient resources for comprehensive testing, the situation of the "left hand not knowing what the right hand is doing," poorly coordinated interaction between projects, and failure to replicate successful methods.
Treatment: Organizations seeking to treat the underlying disease of these symptoms can adopt recommendations of ITIL V3 regarding transition planning and support. This process is intended to plan and coordinate Service Transition resources, to minimize the risk of transition failure and disruption, to ensure the adoption of a common framework of processes and procedures for transition work, and to monitor progress and provide reporting. This process allows for centralized, coordinated planning across all transition activity to maximize success.
Service Asset and Configuration Management
Symptoms: Weakness here shows obvious symptoms. During technology rollouts, there are significant surprises: the staff discovers that the actual environment does not match what was expected; repeated manual efforts are needed to know what configuration items exist and to understand service dependencies; deployments cause new issues because dependencies are not understood; and needed hardware or software either isn't available when needed or disappears without a trace.
Treatment: The guidance for service asset and configuration management should help organizations to provide accurate and complete information about configuration items and configurations to the right people and systems at the right time, in order to support their work; to control assets and configurations, and achieve compliance when required; and to ensure timely resolution of issues by illuminating all important relationships and dependencies.
To support these objectives, ITIL V3 prescribes more than simply a single or a group of federated configuration management databases (CMDBs); it recommends a comprehensive configuration management system (CMS) that provides for CMDBs, data collection, integration, processing, and presentation of all relevant information.
Symptoms: Change management weakness will become clear through such symptoms as the identification of rogue changes; a high volume of emergency changes; failed deployments because of poor change assessment; slow processing of changes; and changes with long and difficult post-execution support.
Treatment: Good change management, according to ITIL V3 guidance, continues to be about making good change decisions: should we or shouldn't we—and if we should, under what conditions? It is also about reducing risk, coordinating and prioritizing, and about building consistent and structured but efficient work methods to allow success within acceptable time frames. In change management, ITIL V3 challenges us to match the level of rigor to the level of risk.
Release and Deployment Management
Symptoms: Rollouts that take longer than planned; releases that have to be backed out; large amounts of last-minute overtime to complete releases; or internal teams that aren't prepared to support a new or changed service can indicate weaknesses in the release and deployment management process.
Treatment: With the addition of the transition planning and support process, as well as the supporting processes of service validation and testing and of evaluation, the release and deployment management process is now defined more sharply, and provides better clarity on ensuring change success. Follow this guidance to "put teeth" into deployment methods, embedding the discipline that is needed. This is the process where we see the impact of the focus not just on installation, but on true "transitioning" of changes into successful operation in support of the business. This focus is reflected in particular by the addition of guidance for early life support of a change prior to final transitioning into service operation.
The use of the word "establish" in ITIL V3, in relation to a new or changed services, is language that makes the mission of transition crystal clear. This word has the sense of solidity and stability that the business is looking for in its IT services. ITIL V3 says that, in release and deployment management, we seek to "establish effective use of the service to support business operation" (Lacy and Macfarlane 2007, 84).
Service Validation and Testing, Evaluation, and Knowledge Management
Many of the other weaknesses that plague organizations are addressed by these three processes. Service validation and testing is a process used during release and deployment to provide rigor around release quality assurance. Without solid validation and testing, releases will be riddled with weaknesses, spawn multiple incidents, and run high risks of failing to deliver their promised value. This process leverages long industry experience in quality assurance (QA) testing techniques, but extends the ideas to provide comprehensive testing and validation of all aspects of the service change, not just the purely technical.
In the phases of service transition, the evaluation process is prominent during deployment, before the final transition of a new or changed service into operation. Evaluation takes inputs from change, service design, and testing, evaluates the predicted performance of a change, and compares it with actual performance prior to final acceptance. Its goal is to ensure that all parties, but particularly the customer, have sufficient information from which to make the final acceptance decision: is the performance acceptable, or do we have to do more before we can consider the work done?
And finally, this takes us to knowledge management. While this process is, of course, important throughout every phase of the service life cycle, weakness in this area may be most glaring in service transition. ITIL V3 advises readers of the critical role played by knowledge management in good decision making, and prescribes the use of a service knowledge management system (SKMS) of much the same architecture as the CMS (and including the CMS in it), to enable the collection of data and its transformation into information, then into knowledge, and ultimately into wisdom.
All of the guidance provided in ITIL V3 on service transitioning is valuable, but perhaps the strongest message of all is the simple fact that an entire phase of the life cycle is devoted to it. Service transition is more than just the installation of a new piece of software or a new server in the server farm. Service transition is the critical passage from idea to reality, the passage from design to value creation, the passage from infancy to independent adulthood.
We must work to strike the delicate balance between speed and quality, building enough rigor into our methods to ensure the risk of failure is kept at acceptable levels. We have suffered from the symptoms of weak service transition for too long, but the ITSM community has been doing the research, and the treatments are becoming more and more mature. We had a wonderful start with ITIL V1 and V2, and now ITIL V3 offers us a better prescription for the health of our IT services.
Lacy, Shirley, and Macfarlane, Ivor. 2007. Service Transition, section 4.4.1. In ITIL Version 3. London: Stationery Office.
About the author
Lou Hunnebeck is an IT service manager with over 20 years of experience in service industries, and is currently Third Sky, Inc.'s vice president (VP) of ITSM Vision and Strategy. Her career has led her to ITSM from a background of process consulting, training, and service management systems consulting. Hunnebeck has led global teams in best practice and methodology design, and has served on the QA team for ITIL Version 3. She is currently a member of the ITIL V3 Examination Panel.