Organizations invariably spend a considerable amount of time and money before entering into contracts with IT service providers and the negotiations are typically long drawn. Having thus invested in the process of selecting vendors, many organizations shy away from ousting IT suppliers once the contract is underway. And in most cases, once the contract has terminated, the incumbent IT provider is awarded an extension so as to avoid the pains of choosing a new supplier.
However, in the recent past there have been a number of cases where customers have either terminated a contract or switched suppliers post-termination. Deals to the tune of over $1.5 bn have seen acrimonious splits over pricing issues and in another case a customer dropped its IT provider to replace it with the incumbent supplier of its newly acquired arm.
Needless to say these decisions to switch vendors have always been a well thought over one. These decisions need to incorporate the base understanding and benefit rationalization of switching to a new vendor. For this, the customers need to well aware of the risks involved in changing suppliers, either mid-contract or post-termination. Once the risks are identified, they can be tackled with a certain amount of visibility into the future in conjunction with a thorough analysis of the existing conditions which gives a clear picture to the customer, on the cause and effects of the switching decision.
Need for switching vendors
Customers have switched IT providers for reasons as varied as pricing issues to nonperformance
on service levels to cultural nonalignment of organizations. At a broad level, the key
factors that act as a catalyst and hasten the switching of IT providers can be clubbed into the
- Customer Landscape Changes: The customer may be ready to move up its value ladder and hence may have outgrown the vendor. In some cases, the customer could find the regional vendor unable to service their global needs. Or in some cases, customers may feel that handing off operations to a contractor makes it the outsourcing customer less nimbleand may seek to regain control of its operations.
- Vendor Market Changes: Once a contract iswell underway, customers may realize that the vendor market has expanded and there are more players now who can help them build competitive advantage.
- Vendor Rationalization: In most cases, as a means of diversifying risk, outsourcing customers divide their portfolio among multiple vendors. As a result, certain customers experience a loss of purchasing power. In a bid to regain some of this purchasing power, customers may look to reduce the number of vendors. This may necessitate transitioning certain outsourced functions from one vendor to another existing one.
- Relationship/Performance Issues: In many cases, the vendor may fall short of the
expectations of the outsourcing engagement. A survey from Benchmark Research
found that outsourcing clients have experienced significant problems in managing
their post-contractual relationships. This can arise because of multiple causes:
- Unrealistic expectation setting prior to before signing the contract
- Vendor not meeting service level agreements that are part of the contract
- The vendor may actually be delivering on the service agreements but the
- client sees less value than expected.
Risks in switching vendors
Switching from one outsourcing vendor to another mid-contract involves the effort and risk of both terminating and entering into an outsourcing agreement. Switching vendors can be costly, considering the employee time and effort for transition, and the legal and consulting fees as well.
Some of the costs and risks in changing vendors are:
- Knowledge Transition A key risk in changing vendors is ineffective knowledge transition between the incumbent vendor and the new vendor(s). While this risk has a lower impact in the case of switching vendors post-contract termination, in the scenario of changing vendors mid-contract this can be a serious concern. Effort must be taken to ensure that complete and effective knowledge transition happens between all the vendor parties involved.
- Knowledge Stickiness The problem of stickiness is not peculiar to a scenario of changing vendors but is more a issue in knowledge transfer. However it merits separate mention because in the case of switching suppliers, the risk of stickiness is magnified.
Stickiness is the core characteristic of specialized, personal and tacit knowledge that inhibits easy transfer. Some of the origins of stickiness are strained relationships, lack of motivation on the part of the source, lack of absorptive capacity of the recipient and the extent of knowledge that is tacit. All of these factors need to be dealt with when switching vendors midway during an engagement.
- Business Disruption Risk If the customer is seeking to change vendors at the end of a contract, they would factor in the time required to get a new vendor on board so as to prevent disruption of business. However in case of mid-contract termination, the customer has to ensure that moving from one vendor to the other does not disrupt the business. The transition between vendors, even in a hostile scenario, has to be managed in a way that lets the business proceed as usual.
- Organizational Alignment Risks Changing a vendor in the course of a project requires the customer organization to work with a new vendor. Such changes are usually met with resistance in many organizations and needs to be resolved by the customer organization and the new vendor working together.
- Costs of exiting the current sourcing contract In the absence of a reversibility clause, the legal and consultancy charges could turn out to be huge for the client and can be a bottleneck for a smooth transition to a new vendor. These termination charges and unwind costs are a key consideration before taking the call for a new vendor.
Once the customer is aware of the costs and risks involved in switching IT vendors, the customer can take a call on the approach that needs to be adopted in changing vendors.
Approaches to Switching Vendors
Depending upon the context in which the vendor replacement occurs, there can be the different approaches to switching vendors. At one extreme is the scenario of a hostile transition from one vendor to another in the course of an ongoing engagement entailing compressed timelines. At the other extreme is the case of end-of-contract mutually-agreedon transition from one supplier to the other. This would allow the luxury of detailed transition, over longer time lines. Depending on such scenarios the following are some of the approaches that may be chosen:
- The Big Bang Approach
In case a hostile vendor transition seems a possibility, companies opt for a big bang approach to facilitate a quick transition, especially in business critical engagements.
The project time line is charted out keeping in mind the lack of co-operation the existing vendor may exhibit. Since there are chances that the current vendor shall be reticent in participating in the transition process, it is critical that all key stakeholders of client are taken into confidence.
After having explored the possibility of poaching resources from the existing vendor the changeover is done in a short time span, leaving minimal chance for any planned hostility by the existing vendor. The incumbent vendor may initiate ways and means to prevent a smooth transition by trying to dismiss or transfer key stakeholders and developers to another project which might lead to the loss of important information –the new vendor and the customer need to be prepared for such an eventuality.
- The Phased Approach
In the phased approach of new vendor transition the most business critical processes
are transitioned on a priority.
The customer chooses to transition in a phase wise manner, in which controls from the existing vendor and deliverables of the same are gradually taken over by the new vendor. Initially only the base subset of necessary operations is transitioned to the new vendor and the rest are gradually taken over depending on the priority of the processes and their business impacts.
Given the time frame that this transition requires, it is imperative that the transition
requires co-operation between the outgoing vendor and the new vendor.
Given these different approaches, the customer needs to make the right choice as to which approach is best suited for its current situation. The choice of the approach depends not only on the extent of co-operation that may be possible between the customer, the incumbent vendor and the new vendor, but also on the strategic importance of the functions being transferred.
For instance, if the functions that need to be transferred are business critical and there is a possibility that the co-operation from the incumbent vendor may not be complete, the customer may be better off using the Big Bang approach rather than using a Phased approach. This stems from the reasoning that the customer may want to get the functions transferred immediately and avoid any business disruption – opting for a Phased approach may result in delays in implementation owing to lack of co-operation, thus affecting the business continuity.
Recommended Framework for Transitioning
When switching vendors, the customer has to first decide the approach that is to be adopted and once that decision is made, the customer along with the new vendor must embark on getting the knowledge transferred from the incumbent to the new vendor. This does not pose an issue in the case of a mutually agreed upon, end-of-contract vendor switching scenario where total co-operation of the incumbent vendor can be expected. However, in cases where the co-operation from the incumbent is unlikely to be complete, transitioning can be tricky. In such scenarios, the customer, in tandem with the new vendor, must ensure that all required know-how is obtained from the incumbent vendo before the vendor exits.
Customers may choose to go about this process in different ways, depending on the exact scenario that exists. Described below is a recommended, 5-step framework, Analyze-Build Portfolio-Architect-Transition-Execute (ABATE), for transitioning, especially suited for cases where full co-operation from the incumbent cannot be expected.
The new vendor must thoroughly analyze the current scenario and the customer vendor dynamics. This helps the new vendor understand the context, and the situation of the customer as well as that of the existing vendor.
The new vendor must understand the reason the customer cites for switching vendors in a mid-contract situation. Getting an insight into these reasons would help in drawing up a comprehensive contract with the customer so as to prevent similar distasteful situations later on, once the contract is in place.
- Build Portfolio
With an understanding of the ground situation from the earlier stage, the new vendor, along with the customer, must build a portfolio of the functions that need to be transferred from the incumbent vendor. This is critical as it determines the scope of the new contract that will be inked. In cases where the switching of vendors is taken up mid-engagement, the new vendor would also need to capture the exact state in which the different projects of the engagement are.
As part of the portfolio building exercise, the new vendor, in conjunction with the customer, must also prioritize the different functions that need to be transferred. This prioritization must take into account parameters like the business criticality of the function and the state of the project.
At this stage, the customer and the new vendor must also create a repository of all the project related documentation that can be obtained from the incumbent as this will help reduce the time required for transition.
These details, along with the results of the analysis stage, would contribute to the contract that would be created between the new vendor and the customer.
The next step in the process is to create a contract between the new supplier and the customer. This new contract must be exhaustive and must imbibe lessons from the customer’s prior experience with the incumbent. The new vendor must aid the customer in drawing up a contract that has mutually beneficial safe guards for both sides.
Once the contract is in place, the next step is the actual transitioning of the knowledge from the incumbent to the new supplier. Ideally this phase would require certain degree of co-operation from the incumbent. In cases where there is low cooperation from the incumbent, the onus is on the vendor and the customer to ensure that sufficient know-how is gathered from the incumbent that will allow the new vendor to take over the functions.
The new vendor can consider measures like employing project members from the incumbent vendor team, shadowing customer SMEs, use of checklists, scientific
knowledge transfer processes, setting up knowledge repositories and continuous monitoring to ensure that all required know how is obtained before the incumbent
The last step in the process is the execution phase where the business processes outsourced are transitioned from the existing vendor to the new vendor. Metrics are
defined in conjunction with the customer and these are monitored against the service
level agreements set up in step 3 to ensure that the engagement is on track.
As part of the entire switching process there are a series of practices that the new vendor and the customer can adopt to ensure successful transitioning. Some of these are as follows:
- “Poaching” – The customer must examine its contract with the incumbent and if this does not restrain it from hiring the vendor employees, the customer must identify key vendor resources and get them on board. In some cases, the customer may be inhibited by contractual agreements from directly hiring the incumbent supplier employees. In these cases, the new vendor can step in and employ few important team members from the incumbent supplier organization so as to ensure knowledge continuity
- Infrastructure Set Up – The customer has to ensure that the right infrastructure set up is in place to allow for a fast and efficient transition from the incumbent to the new vendor. Unavailability of critical requirements like network access or communication links at this stage can set the schedule back by a fair extent. In cases where the incumbent vendor is not fully supportive and its exit date is non-negotiable, such a delay can derail the entire transition effort.
- Data touch points and Documentation – Important documentation like the manuals, data on the client systems, as well as the architecture standards for the customer’s environment etc should be obtained from the incumbent. The customer must help to identify and catalogue any such documentation that may exist. The complete repository of such documentation and other such system interdependencies are extremely useful for a successful transition to the new vendor.
- Secure Incumbent buy-in – The customer must take all possible steps to secure cooperation from the incumbent vendor for the transition. This could involve different
measures like ensuring incumbent participation through exit clauses in the contract or
putting in place incentives for the incumbent resources to be part of the transition.
- Debriefing – The customer must help identify the key resources who worked with the
incumbent vendor or on the vendor’s application so as to get full details of the functions outsourced. The new vendor can then have detailed discussions with these key resources so as to fill in any gaps in the knowledge transitioned.
- Scientific Inputs to selecting resources – Many a time, customers make the error of
assuming that resources who have spent more time in a function or on an application are the SMEs for that function/application. This has been proven to be erroneous and the new vendor must educate the customer that long term experience does not always mean increasing expertise. Ignoring this, may result in the new vendor spending time
with customer personnel who may not be the key resources.
- Address Learning Styles – The customer must ensure that the new vendor is using
the available team effectively during the transition phase.
Different team members have different learning styles and recognizing this can help channel their efforts better. For example, identifying the “Accommodators” in the team and putting them onto trial fixes and enhancements while using “Divergers” for Application Demos would be better than sending the first group for Demos and assigning trail runs to the second.
- Transferring Software licenses – The customer along with the new vendor must identify the software that are required to be in place for the new vendor to take up the outsourced function and the rights of these must be transferred from the incumbent supplier to the new vendor, if the contract allows for this.
The above mentioned is not an exhaustive list since every scenario involving a change of vendors is different & unique. Hence, for some transitions this checklist may not suffice or be mapped to directly. The customer and the new vendor must work jointly to mitigate all the risks that may be posed by the change of suppliers and by having in place processes and systems like the framework described above, the transition can be made seamless and smooth.
Symbyo Framework in action
Symbyo has worked on a number of engagements where we replaced incumbent vendors – both mid-contract and also post-contract termination. In all of these engagements Symbyo successfully transitioned from the incumbent with minimal disruption of services to the customer.
HOW SYMBYO USE THE ABATE FRAMEWORK
The entire transition from an outgoing vendor to symbyo is done in an accelerated manner to meet the project deadlines.
Timelines: Day 1 – Day 2
A team from Symbyo meet with the customer and over a series of discussions analyzed the ground scenario. The team also meet with key members of the outgoing team to get their perspective of the situation. The inputs from these meetings are instrumental in determining the course of the project.
- Build Portfolio
Timelines: Day 1 – Day 3
TDuring these two days, Symbyo in conjunction with the customer prepare a list of functions and services that have to be transitioned from the incumbent vendor within the 2 week time frame.
A detailed list of documents and artifacts that would help in transition is prepared and the customer take on the responsibility of obtaining these from the incumbent.
Timelines: Day 4 – Day 5
With inputs from the previous two phases, the customer and Symbyo prepare a contract for the new relationship. This contract has in place exit clauses and other practices that were not followed in the earlier contract the customer had with the incumbent.
Timelines: Day 6 – Day 10
This phase covers both the planning for transition and the actual transition.
A comprehensive transition plan, spanning the transition of all components, is developed by Symbyo in collaboration with the client. This plan also detailed the transition process, roles, resources, task break up and timelines set up in collaboration with the client. The KT planning stage covers the following:
- Discussing and defining training inventory and schedule
- Pre-requisite skill set for Symbyo’s resources
- Quality control measures to track the status of KT
- Once the planning was completed and the plan was signed off by the customer and Symbyo, the actual transition was kicked off. The following are key highlights of the transition phase
- Transition properly planned and divided into different phases with Checkpoints in each phase, and clear deliverables. The different phases included
- Environment Setup
- Business Overview
- Technical Overview
- Database Overview
- The different components of the KT are
- Technical Environment Training for familiarization to technical
environment, inventory collection, tools, utilities, commands etc.
- Business Training which consisted of business overview and functionality discussions for each business functionality and interfaces, user procedures and product training.
- Techno-Business or Application Training where technical sessions for business concepts were conducted.
- Formal documented transition sessions are organized involving vendor and Symbyo team with pre-decided daily and weekly deliverables.
- The system documents were updated and validated to ensure accurate knowledge transfer.
- Reverse presentations were made to the client at the end of each day. This ensured that the data/info provided by the contractors was validated and the gaps were identified and addressed at very early stages.
Timelines: Day 10 – End of engagement
Post-transition, Symbyo completely replaced the incumbent and took full ownership of the outsourced function. Metrics were continually collected and analyzed to ensure that the terms laid out in the SLA were met. Once steady state was achieved, Symbyinitiated process improvement measures that helped deliver greater benefits to the client.
In the final analysis:
Switching vendors is a reality in the IT services domain and therefore it deems fit that, sooner clients and vendors take of this fact and prepares to tackle it, the better.
Customers need to understand the different risks that can affect their business as a result of inefficient vendor switching. The customer must also decide on the best approach that needs to be taken to go about the transition. This decision must take into consideration the strategic importance of the functions in balance and the extent of co-operation that can be expected between the customer, the incumbent vendor and the new supplier. The new vendor has a key role to play in the entire process – right from helping the customer in exiting the relation with the incumbent to forming the new contract. The new vendor also has the responsibility of helping capture the know how from the incumbent, using the best practices for the same.
Customers need to understand that switching vendors is not an easy task; it is daunting and tiresome. But at the same time, they must realize that it is not an impossible task. With proper planning and analysis, and backed by a strong vendor, the customer can certainly exit from an engagement with the incumbent and partner with the new vendor with no impact on the business.