Transition - starts earlier than you think

The Transition Mode of Operation (TMO) is a well-disguised challenge in IT sourcing. It is barely noticeable and is quite often overlooked because it runs parallel to the phasing out Current Mode of Operation (CMO) and the ramping up Future Mode of Operation (FMO). In this critical situation, many companies rely on their providers' willingness to cooperate and their expertise. In most cases, the customer has clear SLAs with them and feels secure as a result. However, very few service providers are experts in this transition phase - or feel responsible for it.

It is usually the technicians in the TMO who move servers from A to B and check whether apps are running and access is working. However, the structural framework for the services is often neglected because timetables are set up incorrectly. This is because the providers orientate themselves to the day on which the last server is migrated and the last notebook is installed - the complete FMO. The wrong assumption is that processes and peripheral systems only need to start now.

Service Commencement Days

Clients and all providers involved should urgently say goodbye to focussing on the one key date on which the services are transferred. The reality of sourcing is different, because future mode begins on the day the first service is offered by the new provider. This is followed by a few months with many small service commencement days until the full FMO. In this phase, operational responsibility is gradually transferred from the existing service provider to the new one, and thus also to its processes and tools. If the service support processes of the providers are not linked at an early stage, the customer lives in two worlds.

Service desk as a single point of contact

As an example, this means that the service desk must act as a single point of contact at all times in the TMO. Otherwise, end users will have to decide where to call in the event of a problem - a clear no-go. If this is not guaranteed during the PC rollout of the new service provider, users will call the existing provider, who, however, does not know the new computers. Therefore, all tickets must be forwarded and all necessary information about the systems must be exchanged. If the single point of contact is switched, it goes the other way round: the telephone numbers are routed. The new provider must then recognise the tickets and forward them back to its predecessor if workstations or apps have not yet been migrated.

Moving technology, tools and processes

The transition mode of operation is not just about the technical transition, but also about setting up and, if necessary, linking all processes. They must also function from the first migrated system. If this is not guaranteed, the customer gradually begins to realise that he will not receive any availability reports and poor support during the honeymoon period. From that moment on, he and his stakeholders regret having opted for this provider - because only a transition that is invisible to the customer is a good transition.

The processes and systems that must always be in place at all providers on day 1 of the transition include

• The monitoring of all systems (old/new);
• Ticket systems and routing;
• Backup systems;
• Consumption-based billing;
• WAN connections;
• Automatic incident creation with correlation rules;
• Security setups such as Identity & Access Management (IAM) or Privilege Access Management (PAM);
• SLA reporting;
• ...

When the move to production falters

As many high-level plans identify the end of the transition as the service commencement day, provider teams are not prepared to function operationally months in advance. It is important to note that the delivery team (operations) must manage the TMO, not the T&T team (project). If the move to production does not take place as planned, the shadow will fall not only on IT and its providers, but also on the entire IT sourcing industry. All service providers in the TMO should therefore pull together, especially as one supplier is rarely solely to blame for the misery. The fundamental problem is the realisation that everything has to be ready months in advance - as a rule, the wrong date is targeted.

Who bears the responsibility?

If the customer does not accept the poor start of the TMO and the entire transition is postponed as a result, someone has to pay the bill: The one who wrote the bad plan, or the one who accepted the bad plan. The problem is that when providers present their transition plan, many customers rely on the experience of the professionals and approve it. By doing so, however, they unconsciously assume responsibility for the accuracy of the plan. This puts the provider on the safe side legally. Even if this attitude is understandable, it is not sustainable for the IT sourcing industry.

Practising the right TMO planning

The TMO is a phase in which the true maturity level of the provider comes into play - or not. However, it is difficult for everyone involved to adjust incorrect plans retrospectively. With luck, external experts can be brought in to resolve the deadlocked situation in good time and alleviate the problems. Sometimes it is too late for that. In my opinion, it is in the interest of all providers to set up a professional TMO. To this end, a joint exchange of transition professionals would be helpful in order to learn from best practices. The aim is not only to strengthen the reputation of the sourcing industry, but also to make life easier for customers and colleagues - because everyone is affected by shortcomings in TMO.

Anyone interested in discussing the topic and/or starting an overarching quality initiative is welcome to get in touch with me. I look forward to your feedback!