Branimir Valentic There are few processes inside the current version of ITIL that are less known, but certainly not less important. The transition planning and support process is one of them. I have to admit, companies that I work with do many of the activities described inside the process, but not in a structured and organized way.
Passing a single change throughout the transition phase is, maybe, less complex. But, having many customers, introducing several releases or changes at the same time – things get complicated. That’s where a structured approach to the service transition phase of a lifecycle must be introduced.
Where does it start?
An authorized change or the introduction of a new service is the trigger. Or, if you think about tangibles – (authorized) Change Proposal or Service Design Package (SDP). Major changes will have to have SDP developed or updated, as well as new services. It is important to mention that major change also includes decommissioning of an asset or service. Parts of SDP that are direct input into transition planning and support include:
- Description of a service – end-result of transition is clear
- Design of the service, divided into stages – using this information you can, for example, develop a new service, compare deliverables and requirements at the end of each stage and authorize progress to the next stage
- Service Acceptance Criteria (SAC) – set of requirements that will confirm that service meets functional and quality criteria and that operation can handle it. As a service provider, you are probably familiar with an acceptance test where your customer confirms that the delivered service matches their requirements – SAC will confirm that and finalize the transition phase.
What does it do?
Transition planning and support considers all aspects of a new or changed service design, makes plans for transition of a service into the live environment and coordinates required resources. Basically, transition planning and support is a bridge that ensures that service requirements, which are formulated in SDP, arrive into service operation.
Figure: Transition planning and support – bridging design and operation
In real life, e.g. when introducing a new service, there is always some kind of specification or description of a new service. Such specification contains many parameters, which ITIL considers as part of SDP. As far as I can tell, what is usually missing are SAC and release and deployment plans, which are crucial for the transition phase. Also, release and deployment, as well as most of the transition activities, are carried out as a project, which is basically OK. But, it is important to become a part of project management activities so that transition methodology integrates with the project. Or, some alternative will do. Once I witnessed deployment of new service where design of the service as well as SAC were updated (some parts even built from scratch) during the acceptance test. It’s hard to image the stress and hassle that were present…
Here are few activities that belong to transition planning and support:
- Human resources – assigning roles and responsibilities for all activities, defining authorization, assigning trainings and knowledge transfer
- Criteria – ensuring that entry and exit criteria for each stage are defined as well as criteria for stopping, i.e. starting transition activities (e.g. deployment, test… etc.)
- Stakeholders – organizing, coordinating and communicating with stakeholders, which include all parties who are taking part in transition activities or have an interest in whether those activities are successful, e.g. customers, third parties (vendors, suppliers, partners) users, IT service management staff, including people involved in transition activities
- Execution – managing baselines (state of the architecture or the service before the transition of a service starts), definition of points where change authorization is needed, error handling and control, resource and cost planning… etc.
Where does it end?
The main products of transition planning and support are plans. They cover different topics, e.g. Change management plan, Test plan and report, Evaluation plan, Release plan, Deployment plan, Schedule (for example milestones defined in the SDP) plan, Financial plan (usually covers required budgetary data)… To successfully finalize the transition phase, it is important that the SDP (or however you, internally, name such a document) contain entry and exit criteria as well as deliverables of each stage in new or changed service introduction.
Is it necessary?
Yes and no. For sure, transition can work without official transition planning and support process (anyway, some other transition processes will take over some actions from the process), but you will avoid bumps in the road if transition planning and support is in place.
Download a free sample of our Transition Planning and Support process template to see how to set up the process.
