Sometimes a company might feel the need to change contractors at some point. Nobody likes being deceived or misled by empty promises especially when it is about doing business. As a software development company, JayDevs realizes the scale of vendors’ responsibility and the importance of a proper project transition plan in case of searching for a new provider.
While choosing an IT service provider, you as a customer would expect to get the best bang for your buck for developing your product. However, the implementation phase doesn’t always go smoothly and you might consider changing your IT vendor.
Many of our actual customers asked us for assistance in addressing the consequences of destructive cooperation with other software vendors. Here, we’ll help you solve potential issues from switching vendors. In this article, you will find a step-by-step guide for implementing an efficient transition process from one vendor to another, a list of required documents, and at the end of the article, you can download the project transition plan checklist in PDF.
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, an inconvenient and slow communication process, etc. Make sure you know the exact reason why you want to change your 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 all the knowledge about the project 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 service 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 time frame 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 transition process 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 a 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 essential 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.
- Project transition plan template — 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, roles and responsibilities during the transition phase, and the time when services facilitating such transfer are provided.
Step Four: Completing the Project Transition Plan to a New IT Vendor
After signing the SOW, discuss the knowledge transition with the new dedicated development team.
For a successful transition, you’ll need to gather the core artifacts included in software development checklists and communicate them to a new contractor.
Project specifications
Make sure you have comprehensive project documentation outlining the project’s objectives, requirements, deliverables, and specific functionalities. This could help to create a safe basis for successful project implementation and support while and after transitioning.
Code documentation
Let your previous vendor do a thorough review of the existing codebase and update the documentation to ensure it accurately reflects the system’s architecture. Make sure it includes well-documented code structure, design patterns, dependencies, and custom frameworks or libraries used. You can also document the coding standards so the new project team can follow them while implementing new features.
Road map
The project roadmap is crucial to share with the new vendor for a clear understanding of the project’s timeline, milestones, and future goals. This helps the new team align their efforts and plan their activities accordingly.
Third-party integrations you add to the project
Identify and document all third-party integrations utilized in the project, such as APIs, databases, and external services. Provide information on their purpose, configuration, and dependencies, ensuring the new vendor understands how these integrations function within the system.
Where you are hosting your platform
Document the information on the current hosting provider and server configurations. These details would help the new IT vendor to determine if there is a need to migrate to a new hosting platform and plan the transition accordingly.
Data about automated tests
If automated tests exist for the project, gather information on the current test suite. This may include test scripts, frameworks, and test environment setup instructions. This may help a new team to execute these tests effectively, as well as to implement valuable updates.
Assets transfer
Establish and ask your previous vendor to provide a complete set of project-related assets, such as design files, branding guidelines, or media resources. This will help a new team to manage the ongoing development and maintenance without a hassle.
Develop the knowledge transition plan for software projects
The information technology transition plan should outline core steps and actions required for knowledge transition from one service provider to another. In other words, you should identify employees responsible for sharing the gathered information within the specific timeframes, and wrap it up into a software transition plan template.
Establish IP ownership
As part of the vendor transition plan, it is crucial to clearly define and document intellectual property (IP) ownership. Ensure all parties involved agree on the ownership terms for the project and associated assets.
Get the new team up to speed
Relying on your plan, make the following steps to bring the new team up to speed:
Step #1. Updating the team on the project status
Conduct a comprehensive project overview session with the new team, providing an introduction to the project’s history, goals, and achievements. Share information about the current project status, including any ongoing tasks, issues, or pending deliverables.
Step #2. Sharing workflows
Introduce the new team to the project workflows, including development processes, version control, bug tracking, and deployment procedures. Share all the tools used during collaboration, like project management, communication, and collaboration tools.
Step #3. Mapping out risks and challenges
Identify and discuss any known issues, pending bug fixes, or areas of improvement. Collaboratively develop strategies or action plans to track these challenges and address them early in the development process. This could be a helping hand not only for smooth development but for the maintenance phase as well.
In practice, it’s a rare situation to have all of the above artifacts within the IT transition plan. Yet, 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 vendor-to-vendor transition risks and make your vendor transition solution a success.
Hire Dedicated Developers You Need
Scale your team with premium-class remote developers with 5+ years of experience and the expertise you require.
Let's Talk
