Introduction

Service Transition is one of the process groups of the ITIL® Lifecycle that contains processes required to take a service from the design board into regular operations. Hence this process group contains processes such as change evaluation and management, application development, validation and testing, asset management and knowledge management.

The Transition Manager is not a role that is defined by ITIL but is nevertheless a very important role that is usually found in organizations that are committed to changing for the better.

People in the IT industry who want to focus on implementing change in their organizations may find the role of the transition manager to be exciting. Also, people who are already a part of the change organization (typically – a change manager), may find the transition manager role the next step they can step up to. Vendor or Supplier managers are closely linked with most of the transitions, so that is another parallel role from which people may consider switching over to the transition manager role. The term ‘transition’ is generic, but the role of transition manager is more specific to transitions of a service across the ITIL phases, across suppliers and between the business and the IT service providers.

OFTEN, a transition manager will span across multiple roles such as change manager, supplier manager and now, DevOps. This role is more suited for experienced professionals, typically with ten plus years of experience.

1. What is a Transition Manager supposed to do?

A transition manager is a key role in the IT services organization.

His primary job is to ensure that the implemented and validated services are handed over to the service operations teams – which could be the Application Management team and / or the Technical team. While it sounds simplistic, this handover is critical to the success of the service provisioning. The criticality increases depending on the importance of the system to the business and also the organizations that have designed / developed the services and that which will be responsible for the operations. Since the dynamics of designing a service are different from developing it and different from operating it, the transition manager plays a vital role in ensuring that there are no gaps as the system transitions from a concept stage to something that can provide a service.

The transition manager achieves this by working with his stakeholders on building up the right levels of knowledge in the team – both technical know-how and system-specific knowledge. He would then put in place a development methodology and/or a delivery model for the services to be delivered. Such a framework ensures that a boundary is set for the party transitioned to. The boundaries may be quantified using service level agreements (SLAs) and/or key performance indicators (KPIs). While the transition manager may not calibrate this himself, his main contribution is to ensure these are in place before handover.

2. Who are the primary stakeholders for the Transition Manager?

In the ITIL lifecycle, the Transition phase sits between the Service Design and the Service Operations phases. This means that the transition manager will have stakeholders that are process owners and process managers of both these phases, in addition to the stakeholders that are a part of the transition phase itself. Fig 8.1 depicts the stakeholders for the Transition Manager across the other phases of the ITIL lifecycle; shorter distances representing more involvement and longer distances imply lesser involvement. Across all the interactions, the transition manager endeavours to ensure that the transition process is smooth.

3. What are the possible transitions in the industry?

In the IT services industry, various kinds of transition happen for various reasons. The most common is the ‘lift-and-shift’ model, where the IT services experience a change of provider, e.g. an organization X may no longer want to use the data storage services being provided by vendor A and decide to switch over to vendor B.

There can also be a situation where the organization DEVELOPS capability over a period of time, and in-sources the services. E.g. organization X develops capability in a new technology T over a year and no longer requires the services of vendor C in the next financial year. The reverse may also happen. E.g. the organization X uses legacy technology as on date and wants to move to a new-age technology, for which it outsources the upgrade activity, followed by warranty support of a few months.

The last one also leads us to another possibility – that of a ‘fix & mix’ model. E.g. older systems that are built on evolving technology tend to accumulate technical debt. E.g. organization X has a system S that needs to be rid of technical debt. They may float an open tender to which a service provider may respond with a proposal for ‘supporting and fixing the technical debt’.

4. Why are transitions necessary in the first place?

There are many motivations for effecting a transition.

One of the most common reasons is to reduce the total cost of ownership for IT services. After an

IT system is commissioned into service (i.e. system ‘goes live’), the service consumer would expect the system to stabilise over a period and therefore the costs for managing the services the system provides should also reduce. However, this may not be the reality in many cases due to a poor design, technical debt etc. and therefore the business may look at on-boarding a different service provider. Sometimes, this could mean only a change of personnel, or also include infrastructure as well. E.g. Organization X decides to change its provider of data backup services from provider A to service provider B – this will involve a transition of the infrastructure as well as the support personnel. Or, Organization X decides to change sourcing of server administration services from vendor M to vendor N for its on-premise server farm – this is an example of change in personnel only. IT service providers compete fiercely for reducing costs in order to get business.

Often the business will also look at factors like providing customer experience – e.g. sourcing IT Service Desk services from vendors with good credentials in customer satisfaction. In a multi-vendor outsourcing setup, the business may want to consolidate all its IT services from a single provider, to enjoy economies of scale and reduce complexities of managing inter-company service level agreements. The reverse is also true, where the business may want to reduce the risk of depending on a single provider and outsource it to multiple vendors.

Some IT services may require niche skills, that may not be present in-house. This may require the transition of services to a provider who has the skills and expertise. In other cases, the business criticality of the system may be the reason for a transition.

5. What are the usual returns on investment (ROI) for a transition?

A transition is often treated as a project. It has a definite objective and must be completed in a finite amount of time. Like any other project, a transition project also represents an investment by the business, and therefore, must provide a return on this investment (ROI). The ROI will be measured most often, in monetary terms – e.g. a transition that costs $ 100K will have a ROI of 5 months if it results in a monthly monetary savings of $ 20K per month post-transition, provided the service levels do not degrade.

While that was straightforward, there are times when the primary objective is not saving costs. It may be to de-risk system stability – if a new system turns out to be highly unstable, the business may want to bring in a different vendor for supporting it as they want the system to stabilise sooner. Here, the increased stability (and consequently down-time reduction) would be the return that the business is looking for.

Critical systems that deal with business sensitive information, e.g. Business Intelligence systems, financial reporting etc., are less prone to be outsourced to external IT service providers. As a system matures, IT service provisioning may tend to be brought in-house – the return in this case being confidentiality.

Global businesses will also need the capability to scale on demand – this may require choosing of IT service providers that can serve the entire span – the most common example of this being the adoption of the cloud platforms such as AWS and Azure.

6. A new service associated with huge revenue and impacting thousands of users is being rolled out into operations, however, this is within the same organization. Do we need a transition manager or EVEN have a transition process?

Yes.

Unfortunately, most of our organisations tend to operate in silos. This means that there is no common language and practices across departments within the same organization. Organizations that aspire to operate on ITIL best practices, realize that the leap from developing an IT service to when the service is being consumed by the end users is a big one. No matter how robust the design is and how skilled the developers were, there is always the potential of the services not producing the desired outcome and customer experience.

Because the development and support organisations represented in the ITIL life-cycle by the service design and the service operations phases do not necessarily operate as a single unit, there has to be a middle layer, an interface, that understands the process aspects of both sides and acts a glue to provide the necessary rationalization so that when the ownership of the service changes hands, nothing falls through the cracks.

The reputation of a service provider organisation rests on the ‘quality of service’ that the system provides, and therefore, utmost care must be taken to ensure that the service design and operations organisations work in a closed loop (much like the DevOps closed loop representation) so that no loose ends reach the service consumer.

7. What are the factors for consideration during an IT outsourcing transition?

There are many possible reasons behind a business taking a decision to outsource its IT services provisioning to an external vendor over doing it in-house. One of the primary reasons is to continue focusing on the core competence of the business. E.g. a traditional advertising agency that aspires to enter the digital advertising domain may still consider creative designing as its core competence. Therefore, it may outsource the technology aspects of digital such as Google Ad-words, site analytics etc. to an IT service provider that specialises in this.

Another reason could be to utilise the specialist services of an external IT service provider in a new domain, e.g. if a company has recently implemented an ERP solution, it may not have sufficient skills to service the ERP system internally, and this can be grown over a period, till when the business needs to have someone better skilled at it do it for them.

Sometimes, due the costs of labour in the country where the business exists, they may want to outsource the IT services provisioning to a vendor who is in another region where labour costs are lower. Businesses will also do this to derive time zone benefits, e.g. a longer window of support cover for an e-commerce platform that must be available 24X7. India has been in the forefront of the IT outsourcing industry for almost 2 decades now.

Finally, the total cost of ownership is another factor that drives outsourcing. E.g. countless COMPANIES have outsourced their infrastructure and platforms to cloud-based service providers such as Amazon, Google and Microsoft. This has reduced the IT capital investment and provides the flexibility to scale on demand.

8. How important is an assets database for a transition?

One of the key factors in achieving a great transition is a comprehensive transfer of knowledge. Knowledge is intangible and therefore, measuring the ‘levels of knowledge’ is always a difficult task. However, assets are tangible – code repositories, configuration files, technical and functional documentation, service level reports, monitoring dashboards are tangible items that are key to providing IT services. Infrastructure, code repositories, documentation and reports are all assets for the service – and a list of these are maintained in the assets database. 

Every transition must include the transfer of the assets at a detailed level – not just the existence of the asset, but also the interfaces (as a part of the Configuration Management Database – CMDB), the associated documentation, known errors and workarounds implemented, changes in progress (which means that there are assets being created or modified) and the service levels associated with the assets or groups of assets. This means that the assets database is critical to the completion of an effective transition.

9. What are the key activities during a transition?

Once the scope of a transition has been decided, there would typically a period when the receiving organisation would understand the services at a high-level. During this time, the receiver of the transition will understand the business objectives of the services, the expected business and IT service levels, assess the system stability and perform an estimation of the manpower required to service the system, functional and technical skills required, interfaces to the other systems and stakeholders involved. This initial phase is called the due diligence phase and information gathered will be used in the next phase – planning.

In the planning phase, the knowledge transfer activities will be planned, and handover dates finalised. Topics for the knowledge transfer, the subject matter experts to deliver it, the timings – all will be decided during the planning phase.

The next 2 phases often carried on in parallel are the knowledge transfer and the shadow phases. During these phases, knowledge will be transferred systematically to the receiving organization, and the latter will successively be able to demonstrate autonomy in being able to provide the services independently. Together, these two phases represent the maximum efforts being spent in making the transition.

The final phase is that of handover – where the incoming organization formally accepts the accountability for providing the IT services. Identified stakeholders will be informed and new communication channels will be ironed out.

10. Can you start a transition without the availability of the design documentation?

One of the most common risk issues highlighted during a transition is the absence of documentation, especially in an Agile setup where one of the values lays more importance on working software over comprehensive documentation. Under documentation, the most outdated is the design document, as subsequent iterations during service development have outdated what was written at the beginning, which means that the working software, or the ‘as-built’ system varies from what it was supposed to be, technically.

While this may sound alarming, we need to accept that evolution is a key to survival in today’s world, so this variation is reasonable, and in the best interests of the business. Therefore, we may need to start a transition even though the design documentation is outdated or absent. Of course there are ways to work around this apparent difficulty – by referring to the conversations in the user stories, having more dialogue with the development team, the testing and validation teams that have worked on building the service – and documenting them for future reference, or updating anything that exists. Establishing a traceability between the business objectives (that have not changed) and the working software is essential. This is a like reengineering the design document from the system that has been built, i.e. going from left-to-right in Fig.