No matter the size of the organization, the industry or market sector, no matter how long they’ve been in existence or how dependent they 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, money and credibility with the business.

These are just a few of the challenges that the guidance in ITIL® version 3 is intended to help address, in particular through the guidance in the book covering the third phase of the Service Lifecycle: Service Transition. What is the ITIL® v3 prescription for treating all these ills?

The use of the word “transition” is significant. How often have IT professionals complained about applications being “thrown over the wall” 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 with precision what the new state will look like?
 How can we ensure that we know with precision 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 answers are addressed in the guidance on the second phase of the Service Lifecycle: Service Design. The position is that, if Service Transition starts from the position of a comprehensive design, then the first question 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 effects everything else we do. Relationships between the elements of 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 & Support
 Service Asset & Configuration Management
 Change Management
 Release & Deployment Management
 Service Validation & Testing
 Evaluation
 Knowledge Management

The work of these processes is designed to address the issues every organization has experienced with change and address them 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 & Support
Symptoms: Organizations with weakness in this area are likely to present symptoms such as insufficient resources for comprehensive testing, 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 that these symptoms belie can adopt recommendations of ITIL® v3 around Transition Planning & Support. This process is intended to plan and coordinate service transition resources, work to minimize the

You do not have flash or javascript support.

Average (1 vote)

Reply