Be warned – I’m about to get all ITIL on you as I explain what ITIL's service transition is. A good place to start is that – it’s the phase of the service lifestyle that deals with change. Put simply, service transition deals with retiring the old, introducing the new, and managing both internal and external moves while maintaining service quality standards. OK, maybe that wasn’t as simple as I’d hoped. Please let me try again.
At its core, ITIL’s service transition book/phase is made up of the following processes (or capabilities):
This blog – and part 2 to follow – explains what each of these is responsible for and offers up some top tips for successful service transition within your organization.
This process (or capability) can be seen as a set of activities that align to project management; with it the process that provides overall planning for service transitions and coordinates the resources that they require.
The key functions of the transition planning and support capability are to: get a handle on all transition activity across the service landscape, ensure that there are no clashes, ensure overall quality, and ensure the correct policies and procedures are in place.
When setting up your transition planning and support capabilities, make sure that you have your key stakeholders mapped.
Effective stakeholder mapping will help enable you to create a solid RACI (responsible, accountable, consulted, informed) matrix to ensure that all appropriate roles and responsibilities are known and agreed.
Service asset and configuration management is the process/capability that lets you model your services such that you can manage your estate more effectively.
Done well, service asset and configuration management will identify assets and establish a baseline, manage the integrity of the assets and associated services, and maintain accurate historical, planned, and current status/state information.
The benefits of service asset and configuration management can sometimes be difficult to articulate – especially when seeking funding and other resources – because generally, the new capability doesn’t offer the quick wins associated with implementing, say, incident or change management.
One way to make it easier for key business stakeholders, and purse-string holders, to understand the benefits of service asset and configuration management is to include a data model when setting out your configuration management plans – with this something that maps out end-to-end services at a high level.
A typical data model would start with the following items:
Done well, a configuration data model will effectively represent data/information about the most common CIs such as hardware, software, and services and provide a mechanism for linking that information to show a complete view of all elements of the corporate IT environment and how they affect each other.
Change management is the process/capability that controls the lifecycle of all changes, enabling beneficial changes to be made with a minimum of disruption to IT services.
Ultimately, great change management ensures that new products and services are introduced, retired, or updated effectively, efficiently, and safely, and continuously looks at balancing technical change versus the benefits to the business.
When setting up your change management process/capability, avoid the temptation to route every single change via the change advisory board (CAB). Why? Because it might otherwise slow your organization down and nothing is more frustrating than when your CAB runs over time discussing minor issues such as making network ports live or rebooting test servers when the serious, high risk (and high impact) change content hasn’t been tabled.
To help, introduce standard changes – low risk change tasks that can be pre-approved to free up the CAB for the more visible and business-impacting changes.
Not sure how to identify low risk changes? Spend an hour with each support team and ask what changes they’re raising all the time. For the ones that are low risk/low impact follow the standard change route. Then create templates for everything else – change models – so that, for support teams, raising a change is a case of selecting the right template, updating the implementation window, and then detailing any exceptions such that it takes less than a minute to raise a change instead of ten minutes plus.
This is a quick win where changes are raised with the appropriate detail and are routed such that low impact work is automatically approved, freeing up the CAB for the big-ticket items.
Change evaluation is a process/capability triggered by change management to assess major changes. For instance, the introduction of a new service or a substantial change to an existing service, before they’re allowed to proceed to the next phase in the change life cycle.
Not every change requires a formal change evaluation process trigger, but if the change is major or enterprise-level, then that level of complexity requires a more-detailed and formal evaluation.
Change evaluation is essentially writing the business case for major service changes to provide a consistent and standardized means of determining the performance of the change. The evaluation process articulates the likely impacts of the change on business outcomes, and on existing and proposed services and IT infrastructure, enabling stakeholders to have a much more granular view of the associated benefits and risks.
There’s no such thing as a risk-free environment and thus risk management is an essential aspect of any major change. Use change evaluation to provide structure around the identification of risk, for example:
By capturing this information at each stage of the change lifecycle, the desired outcomes are more likely to be achieved and any improvements can be fed into the CSI process. What’s not to love?
Please come back soon for the second part of this article, where I’ll delve into validation, testing, release, and knowledge management. What do you think so far? Please let me know in the comments.