After a long and intense day, Anna is about to make the final update in the newly introduced core manufacturing system before handing over to the next shift, but realizes with horror that the system is down. Immediately Anna understands that this means the next shift will not be able to work and calls the service desk. Anna describes the problem and explains the business impact to the service desk agent. Almost immediately, Anna understands that the person on the phone has no idea what system she is talking about and her frustration increases even more. What Anna doesn’t know, is that on the other side of the phone line, the service desk agent is as equally frustrated, despite trying several key words in the knowledge base, he cannot get any hits on the system the user is referring to. Apparently, no information about this new system has been handed over to him and his colleagues at the service desk.
This scenario is just one example of a situation that can occur if you fail to transition a service correctly to operations. However, it is not only the service desk that will be affected, all roles involved in the maintenance and operations of services will suffer from poor service transition. In addition, projects that strive to deliver a high quality service will struggle considerably, if a defined and clear service transition process is lacking. Most importantly, it is the end user who will draw the short straw as the consumer of an inadequate service.
In a recent survey that 3gamma conducted on the theme ’The state of ITSM in agile organizations’,
poor handover from development to operations was stated as one of the top 3 reasons for low quality and increased costs for IT services. In addition, 75% of the respondents stated that the development of new services must be done with greater consideration to maintenance and operations. These figures speaks very clearly, something is missing in today’s IT organizations.
The solution is called service transition. This is the process where a product is transformed into a service, i.e. where the additional customer value is added. This value comes in the form of support, processes, service level agreements, documentation etc. Aspects of which will not be directly visible to the users, but in the end will ensure that they not only get a high quality product but a high quality service that will hopefully make their day-to-day job easier.
Achieving this requires someone with an overall view of the IT organization and its delivery processes. Someone to coordinate the work and direct all stakeholders towards the common goal. Someone who takes on the role of ‘the keeper’ of the ’Operations gate‘. This someone is the service management office (SMO):
- The SMO is responsible for all processes and the general management of services throughout the organization and thus has the necessary knowledge and overall cross-organizational view that is needed to facilitate this process successfully.
- The main role of the SMO in the service transition is to link all parts of the organization under the service introduction ’umbrella‘, this will act as a facilitator, making sure that all parties involved understand the processes and that knowledge flows freely.
- Another equally important role of the SMO is to be the ‘gatekeeper’, ensuring that products are transformed into manageable and maintainable services before handing over to operations. One of the key-roles, is the person responsible for managing the service in its operational state through its entire lifecycle, e.g. the service manager. As part of the ‘gatekeeping’, the SMO must assure that the service manager is ready to accept the responsibility of the service and that all of his/her requirements are fulfilled.
It is important to remember though, that the SMO is not the ’doer‘ in the service transition process, the deliverables and content will be provided by the project. The SMO is merely the facilitator that makes it happen.
To be able to facilitate and support the service transition and the ’doers‘, there needs to be a structure in place. Below is an example of supporting elements that the SMO might provide as part of the service transition process:
- Checklist that describes what needs to be delivered by whom
- Appointed approvers for all deliverables
- Various templates such as service desk knowledge documents
- Meeting structure and schedule, e.g. startup meeting, follow up meetings, review meetings
- Time schedule with milestones
- Process description including roles and responsibilities
- Contact details
Besides the above elements, there are also a number of essential aspects that need to be taken into consideration when setting up the service transition process:
- It is vital to create the right conditions for all parties involved. At first, it might seem like an overwhelming task and it is recommended to take a methodical approach, starting small at the outset then progressing step by step.
- Involve stakeholders! Make sure that the receivers are heavily involved in defining the requirements and in the approval of the service transition deliverables. They are the ones that will use the result in their day-to-day operations and no one knows better than them what is required.
- Identify the ’pain-point‘ for the organization, i.e. what is most important. If the confidence in the service desk is low, then focus on the handover to service desk in your service transition version 1. If high availability is key for your organization, focus on implementation of monitoring and event management. When the process has matured, expand the scope.
- Define a clear process with clear steps, roles and responsibilities, deadlines and interfaces, so that it is obvious to everyone what is expected from all parties involved. Be clear about the timelines for the project and ensure ’post go-live support’
- Make sure that the SMO is involved with the service transition process at an early stage in the project, enabling the project manager to plan for service transition. Aligning with the project model will benefit the process.
With service transition, all aspects of the service are in place from day 1. The scenarios we described in the introduction of this post will, hopefully, not occur. Instead, the Service Desk will know how to resolve the incident in the first place and alternatively which resolver group to assign it to. The project manager knows what is expected, who to turn to for support and will have the process to support him. The resolver teams have sufficient documentation about the service and how to resolve incidents and requests. Additionally, waste is being eliminated, both in project and operations phase, which leads to a more cost effective IT Organization. In the end, the users are happier. All this as a result of choosing a structured and communicative way of working, using the SMO as the ‘spider in the web’.
Linda Lyxell Ahnsberg