4 Steps IT Project Transition Plan from One Vendor to Another

Step One: Current state analysis

Evaluate three factors before making a decision to switch vendors: vendor value, risks, and contract termination cost.

Assessment of the current vendor

List everything you don’t like about your current vendor. For instance, missed deadlines, poor feature implementation, overpricing during development, inexperienced developers, inconvenient and slow communication process, etc. Make sure you know the exact reason why you want to change your software development provider. This will help you better understand your demands from another supplier and the nuances you want to avoid. 

Risks associated with switching vendors

• Challenges of drawing up an RFP and SOW. It might also include issues with knowledge transfer — the process when all documentation, data access, and project knowledge are transferred from the current to the new software development vendor. If your existing contract does not include a section about assistance in a smooth transition to a new vendor (termination assistance services) — you might face issues with knowledge transfer. 
• Problems with contract termination. Depending on the contractual stage, the complexity of its termination will vary. Termination closer to the end of the contract period will prevent services quality drop, loss of data, etc. 
• Intellectual property rights transfer and work with confidential information. Make sure that the intellectual property rights belong to you, and this is stipulated in the contract. As for confidential information, there is no way to check if all vendor employees deleted files related to your project. However, if you had a strong non-disclosure agreement, you could file a charge should the leak occur.

Cost of terminating the existing contract

Analyze the termination fees in the current contract. Typically, no termination fee is charged at the end of the contract or in case of a breach of contract terms by the vendor (so-called termination for cause). Conversely, the closer the termination date is to the start date of the contract, the higher the termination fee. You can try to negotiate a lower cost if the termination decision is mutual or if the facts speak in favor of the contract breach by the current vendor.

If you are still positive about changing the software development vendor following an evaluation of all three factors you can proceed to the next step — planning.

Step Two: Planning

Planning includes business strategy, development process handover timeline, contract termination strategy, and development schedule with a new vendor. 

Creation of a business strategy

The business strategy is the goals and outcomes you hope to achieve with the new vendor. For instance:

• Find a large pool of developers with different skills in a specific region: Lithuania, for example.
• Reduce the high costs associated with the current vendor.
• Increase efficiency: double the number of implemented features per development iteration (sprint), reduce the number of code errors, etc.

Set the timeline for development stages handover

Determine the timeframe to transfer every software development stage from the current to the new vendor. If the current provider is not involved in the process, ask them to prepare a detailed knowledge transfer plan for the new vendor.

Define a contract termination strategy

Plan your strategy to mitigate possible issues with your current vendor considering the terms of the existing contract. For instance, if needed, prolong the contract with the current vendor for a transitional period; consider leveraging retention bonuses i.e. a bonus for continuing to work to avoid suppliers defection, etc.

Step Three: Plan implementation and choosing a new IT service provider

Use the RFP and SOW as a starting point to find your new IT service provider

The request for proposals should clearly state the scope of work required from the vendor — the more concise it is, the better the proposal you can expect from the vendor. Be sure to include these provisions in your RFP when changing vendors:

• Summary — specify the goal of your request for proposal.
• Stakeholder Relationship — specify the roles and responsibilities of the dedicated development team and the client.
• Legal Terms and Conditions — include the main contract terms (the so-called term sheet) in advance: project description, the start date and the end dates of the contract, the country regulating the disputes within the contract scope, etc.
• Approach for Transition — describe the timeframe for gradual transition of development functions from a current to a new vendor.
• Scope of Work — describe the work scope.
• Vendor Background Information — request general information about the outsourcing company, their experience in a specific tech stack, their client base, etc.
• Expected Vendor Performance — clearly define the SLA that the vendor will have to meet (SLA – a service-level agreement stating what, when and how services will be provided).
• Vendor Capabilities Form (to be filled out by the vendor) — lists everything you expect from the vendor and determines the level of proficiency per each task.
• Termination — specify the conditions that may lead to the termination of cooperation: refusal to provide services, failure to meet performance standards, failure to meet deadlines, etc.
• Price Bid — specify the type of contract you need based on the pricing model: fixed price, time and materials, dedicated. 

Conduct a comparative analysis of proposals from potential vendors

Determine the most important criteria to make the final decision on whom to work with. These criteria can include the supplier’s location, software developers hourly rates, the level of developers, any extra additional costs, etc. Having chosen a service provider and finished negotiations with them, take care of the SOW for the contract. The SOW should contain the following sections:

• Executive Summary — the goal of the agreement.
• Term and Termination — the duration of the contract and termination rights.
• Vendor Scope of work — a description of the services that will be provided.
• Vendor Statement of Work — a more granular work description (processes and requirements) than provided in the RFP.
• Documentation — documents and reports the vendor is responsible for, including schedules for delivery and development stages accomplishment.
• SLA / Vendor Performance — prioritize SLAs based on their importance to project development and define the penalties to be charged for non-delivery.
• Transition Plan — states the roles and responsibilities of both parties during the project transition period. Specify how everything related to the development stages will be transferred to the new vendor.
• Operational calendar — working hours, public holidays, etc.
• Pricing — specify your pricing model, developer rates, and how funds will be sent.
• Fee adjustments — specify how payments are corrected in case of:
  exchange rate fluctuations;
  payment adjustments considering changes in the scope of development.
• Exit Management Plan — develop a plan that outlines the steps to be taken if you or the IT vendor terminate the contract. These steps should include how to transfer the service to a new IT provider, knowledge transfer, roles and responsibilities during the transition phase, and the time when services facilitating such transfer are provided.

Step Four: Completing the transition to a new IT vendor

After signing the SOW, discuss the knowledge transfer plan with the new dedicated development team.

Knowledge transfer plan checklist:

• Project specifications, code documentation, and a road map — gather project specifications, code documentation (including source code, description of application architecture, description of key algorithms, description of application layers, database structure description, frameworks and libraries used), deployment flow recommendations, and environment setup.
• Development credentials — in order to get the project your new development team needs access to the project’s repository, issue tracking system, etc. Request access to all accounts used for your project from the previous vendor. Then update access to all accounts and tools connected to your project and remove the accounts of previous providers. If you’re not sure what tools and credentials a new software development vendor needs, ask them to provide a list of the required information.
• Assets transfer — ask your current development team to transfer all the project-related documents and files to you: design files (Figma files as a rule) etc, depending on your project.

Checklist

Use our Software Development Project Transition Checklist to make the transition process of your project seamless and successful.

Download

Download

In practice, you are unlikely to have all of the above artifacts, but specifications, source code, API, and project deployment instructions should be the bare minimum you need to provide to a new dedicated development team.

Having this data, the new team will be able to continue working on the project without having to develop everything from scratch.

Summing up

Changing vendors within your product development is always unique and has specific challenges arising from the existing contract. However, by following the recommendations in our article, you will be able to get the expected product, minimize the risks and minimize the negative impact when switching software development vendors.