Transition Management

Classic Service Transitions

The last thing you need when you have convinced a client to award a contract to you is to find that the transition is ill prepared. It immediately raises the question whether the sales organization is in sync with the delivery organization and whether the new project is a welcome addition to the portfolio of the supplier - or a nuisance. Unfortunately, this important interface between the pre-sales and the post-sales teams is often not handled well at all. In some cases the closure celebrations have long gone before people have any idea who will take on the transition challenge. In other cases a team turns up and tries to renegotiate details of the contract relating to the transition. These are unnecessary but highly effective ways of alienating customers.

We found it useful to develop a transition perspective as part of the bid process, in addition to making sure that the delivery stakeholders support all the solution proposals being made. Starting from the "LoI" (Letter of Intent), we assigned one person with a good standing in the delivery team to think exclusively in a "post closure" mode, while the rest of the team remained focused closing the deal. It meant that milestones, service levels and timelines remained in focus with respect to their feasibility during the transition phase and that contributions the customer or current supplier must make were not forgotten.

Moreover, it is helpful to create a dedicated transition and transformation group of experts, that knows the risks inherent and can ramp up quickly to meet the challenges of this phase. As a project, it must have and owner and a project manager and be planned from the current "CMO" to the future "FMO" mode of operations with all the relevant dimensions, from the service to be delivered via security, risk management, processes, infrastructure, finance, legal and procurement aspects to the integration of the people affected who may be very concerned about the prospect of a changed employer and pending future rationalizations. The skills and profiles of strong performers required to manage a transition are different to those managing acquisitions or service delivery operations.

As transition and transformation gather momentum, it is recommended to assign someone to think only in FMO mode, focusing on what must be right on the day the hand over to service operations occurs. Preferably, of course, the future service delivery manager in charge during the contract cycle to the end of contract (EOC). During the final project phase, a change of perspective is necessary - from that of an implementer "what is there left to do?" to the much broader perspective of a user "what do I need (to know) on D-Day?". It includes basic training and the identification of power users or champions, but goes significantly beyond this in terms of a detailed  "walk through" of a typical day in the new environment, including the tasks, decisions, interfaces arising, and the infrastructure, hardware, software and knowledge required - a full simulation of the "moment of truth".

Offshore Project & Service Transitions

The verdict is still open on how fast the success of offshoring can be repeated when language, mental resistance as well as cultural barriers need to be overcome. Overall, there is no alternative to selective and intelligent offshoring. It is probably fair to say that the learning curve is still rather steep but that continental Europe is making progress. In the context of international collaboration the value of employing international standards becomes apparent, as teams need to minimize the scope for misunderstandings in their definitions, processes,  measurements and communications. They also help to achieve the security standards required by most customers today.

As so often, the biggest mistakes happen at the beginning. My favorite is when people announce that they have agreed a target percentage offshore ratio with the client without any clear concept of what will be transferred. In other cases the involvement of the offshore partner is too late, so that important opportunities to design for offshore are missed. And there are cases where offshore is seen as a sort of residual activity in an attempt to keep the interesting activities onshore. Such design errors are the perfect recipe for friction, frustrating results and prolonged mental resistance. Indeed, many companies are mentally not ready for this type of change. The insufficient attention to international standards and elementary mistakes in setting up projects can hold up progress toward effective and efficient international collaboration for years.

When you analyze how exemplary companies manage to have satisfied customers in Europe across language and cultural barriers, you notice that they take over complete modules of activities -services or software development- and that they do so by way of a structured and well rehearsed knowledge transfer method. You also find that they mirror the incentives of those managing the onshore and offshore service so they are totally aligned. And you will find that they work according to the most advanced levels of the normative standards we outlined in the section on governance above.

The transition process must be a joint team effort from the start with the customer, the contracting onshore and the delivering offshore partners having to take a different share of the workload depending on the phase of the project and the project type. The onshore team will be supported by traveling staff from the offshore location to avoid hard handover points and will gradually draw most of the activities over to the offshore site. This changes as project completion approaches and acceptance testing and roll out begin. These activities are onshore lead, with bug fixing teams supporting from the offshore center. In the steady state, the first level support may happen onshore, supplemented by second and third level support offshore. Similarly, change requests may initially be handled onshore, while build, testing and deployment happens offshore. Conclusion? It can be made to work, but not by organizations with a low level of maturity in their normative standards.