The article was updated on September 01, 2020.
There are dozens of things that can go wrong at any point in time during the development of your project. A good provider will go above and beyond to fix such issues if any arise. The truth is, however, that not all software development companies are good.
According to different estimates, from 25% to 50% of all clients will be faced with the need to terminate a contract or switch providers at some point during the lifespan of their project. There are many reasons for this, including constant delays with the project’s delivery, a lack of communication, or the inability of a vendor to meet the expected quality standards.
If you have faced a dishonest service provider, it is best to end your cooperation as soon as possible. Yet, to avoid doing even more harm to your project, you need a solid project transition plan to ensure that the project is smoothly transferred from one vendor to another.
In this article, we will delve into the nuances and phases of transition management and provide first-hand advice on how to switch providers with minimum risk to your business.
Why do you need an established IT transition management process? The challenges and risks of switching vendors
According to various sources, a successful project transition plan from one vendor to another can take 2-3 months. The more complex the project, the longer the transition will take. The current stage of the project’s development also has a significant impact on the duration of the project’s transition.
In addition to the time needed for the project transition plan, there are some other challenges a business owner should be aware of when switching providers:
- The past provider is unwilling to cooperate with the new one. Indeed, the company is not contractually obliged to support the incoming provider. So, in most cases you will need to act as a mediator, transferring the project knowledge from one part to another. Alternatively, you can put a monetary reward in place at the early phases of transition management to spark the interest of the leaving party to mitigate the loss of project knowledge.
- The transition of IP rights and dealing with confidential information. Upon the termination of the contract, the provider must transfer all assets. However, there is no way to verify if every one of the vendor’s employees deleted the files related to your project or not. The only thing you can do is to make sure there is a rock-solid NDA in place, so you can press charges in case of leaks.
- Service disruption. In the last weeks of project development, after you have announced your plans to terminate your cooperation, the vendor can reassign your development resources to another project, or developers themselves can lose motivation. There is little you can do about this. Just make sure to minimize the disruption for the most vital business processes.
Yes, switching providers can be a challenging, costly, and risky process. However, if you fail to do so, you can be stuck with an unreliable provider, leading to poor quality of the end product and even bigger delays.
To optimize the effort and navigate possible pitfalls of managing a smooth outsourcing transition, follow our 3-step guide.
A software development vendor transition plan: A step by step guide to a smooth project transition plan
As a product owner, there are many things you can do to facilitate a smooth project transition plan. Namely, we recommend following the three steps listed below during the early phases of transition management.
Make sure to understand the basics
Knowing the ins-and-outs of your product specifics is a must. So, if you haven’t gotten into the details yet, it is high time you do so!
Here are the questions your team needs to know the answers to when working on the project transition plan from one vendor to another:
What’s your tech stack?
When you are working on a software project transition plan, make sure to understand which technologies the developers you hire should be skilled in. Outline the list of technologies that make up your tech stack, as seen in the example below:
- Front-end technologies – HTML, Java, CSS;
- Back-end technologies – Ruby, PHP, Java, .NET;
- Frameworks – Node.js, Angular.js, etc.;
- Database – SQL, MongoDB.
If you are scaling your product on mobile as well, include mobile technologies to your stack as well. Understanding which tools you are using to bring products to the market helps you choose a fit software vendor and increases the speed of selection.
Third-party integrations you add to the project
Adding third-party integrations is one of the best practices that helps improve user experience and increases the project’s conversion. Outline all the integrations you’ve added and plan on adding to your platform. This way, you can choose people experienced in creating a needed type of gateway.
Here are the top types of third-party integrations developers use:
- Payment integrations – Stripe, PayPal, BrainTree;
- Delivery and shipping integrations – FedEx, Shippo, etc.;
- Invoice and accounting integrations – QuickBooks, Xero, and others;
- CRM tools – Zoho, Salesforce, etc.
Where you are hosting your platform
To make sure that the vendor you choose as a part of the project transition plan will deploy and maintain your project skillfully, choose a vendor who knows how to maintain an app on the hosting platform you use.
Be ready to explain to the vendor, why you chose a particular hosting platform over alternatives. Take your time to get to know the most common platforms and determine why they were not a good fit for your project:
- GitHub Pages – for hosting small projects and static pages;
- Cloud storage platforms – AWS or Google Cloud Platform;
- Serverless architecture vendors (these allow developers to pay for as many resources as the project is using at the moment) – AWS Lambda, Google Cloud, or Microsoft Azure.
What platforms your project supports
Last but not least, you should aim at hiring a vendor skilled in supporting the type of platform you have built – be it a progressive web application, a single-page application, a native iOS or Android product, or a cross-platform app.
To make sure that your vendor follows the best development practices, be clear on the platform you prioritize over others, and choose a contractor who specializes in the field.
A lot of business owners use platforms like Clutch.co or GoodFirms to aid in the selection of a software development vendor. These are helpful for finding contractors specializing in building a particular product type.
Develop the knowledge transition plan for software projects
! Before you dive into details, here is a project transition checklist in Excel suitable for transition of the projects of up to 10-15 people.
A knowledge transition plan for software projects should cover the following sources of information:
- Project specifications. Regardless of the development stage that your software project, is at, collect and provide all available requirements to the new vendor. While the latest version of the specs is a must, initial project documentation (if you have any) would be a great source of background information and will help the new team understand what was going on with the project before.
- Code documentation. Well-documented source code can speed up the transition process and help the new team feel at home with your project. Read more about “best practices of code documentation” in our article (or at least make sure the comments and code docs are in English).
- Assets transfer. Be it mockups, design files, or other assets, your current team (the one you are leaving) should hand all of the project-related documents and files over to you. To avoid any misunderstanding, consult with the newly hired team about their requirements (e.g. file formats).
- Development credentials. To get their feet wet with your project, the new team needs access to your project’s repository, CI, task tracking system, etc. Thus, you might need to create new accounts and make sure to deactivate the old ones (more on that – later). The tools and credentials can vary depending on the type of project or tech stack, so better ask the new vendor to provide a list of required information.
- Deployment procedures. Deploying updates directly to the live application is a very dangerous move. Just to be safe, make sure the new team is aware of the specifics of your project’s deployment process, if any.
- Any other technical information relevant to the project that should be included into the onboarding documents for the new team.
Check this project transition checklist in Excel suitable for transition of the projects of up to 10-15 people.
Establish IP ownership
Usually, any work that is conducted by a software development company is considered a work for hire, which makes you a sole owner of all the intellectual property created by your contractor. However, you need to make sure that this message is clearly stated in the agreement.
Read more about code ownership and IP rights at Eastern Peak here.
To take full ownership of the product and keep your IP safe, you will need to ask your outgoing vendor to provide the list of accounts and access credentials to a number of tools and services where the project’s assets are stored or deployed. You will need to deactivate the old accounts (or change passwords) so that the old team no longer has access to your product. Otherwise your IP rights might be at risk.
According to a standard NDA, the provider should destroy all assets and information related to your project after the termination of the contract. Make that clear with the vendor you are leaving.
Get the new team up to speed
After you choose the vendor capable of deploying, maintaining, and scaling your project, make sure that the newly onboarded team has all the tools needed to start working.
Let’s break the knowledge transition plan for software projects down into smaller, manageable steps.
Step #1. Updating the team on the project status
Before changing vendors, make sure you have a clear understanding of how much the previous team has accomplished. Take some time to assess the progress the vendor you used to work with made.
Group all tasks in the following categories:
- done – all completed software development, testing, and design assignments;
- in progress – the tasks the vendor you worked with didn’t get to finish and the code that hasn’t been deployed yet;
- to-do – the assignments your vendor hasn’t started working on.
Step #2. Sharing workflows
Making sure that project stakeholders and the tech team are on the same page is crucial for the project’s success. As the one in charge of the software vendor transition plan, you need to make sure that software developers understand the strategies and best practices used to build projects.
Here’s what you should get the team up to speed on:
- project management methodology – let the vendor know which methodologies they should follow – Agile, Waterfall, Kanban, and others;
- roles – clarify the responsibilities of each member in your team;
- communication – collect a toolset you use for communication, efficiency monitoring, and other processes.
Sharing this data with vendors will help you be on the same page and streamline software development.
Step #3. Mapping out risks and challenges
Finally, before completing the software development transition plan, make sure the team you are bringing on board is fully aware of the challenges they might meet along the way.
Here are the main types of risks you should keep tabs on and tell the vendor about:
- Technology-related bottlenecks. If you have recently integrated a new technology into the project, optimizing it will take some time and bring along the risk of crashes.
- Architecture related risks can complicate the project’s deployment and maintenance.
- Performance risks the previous vendor you worked with had to deal with – these may eventually resurface. If you miss out on performance bottlenecks, you’ll start losing users and revenue.
- Legal risks that could have to do with third-party technologies and patents, data security, and other aspects of the project.
Managing the handoff
The success of project handover largely depends on the way your previous team of vendors was handling their work. Before terminating the collaboration with the development team and switching to a new vendor, make sure that all project files are prepared for a hand-off.
Here is the project transition plan checklist project owners should implement before letting a vendor team go:
- Make sure that developers have documented their work and best practices and shared these files with you.
- Find out which tasks a vendor accomplished and which parts of the scope aren’t delivered yet.
- Consider hiring lawyers and technical consultants to help you protect intellectual property and avoid financial damage after the exit.
If you are wondering how to hand over a project if your relationship with the last vendor ended abruptly, here’s the good news. Onboarding a new vendor responsibly can make up for project management miss-outs.
Here is a software transition plan checklist company managers and CTOs should follow to streamline the process:
- Before signing a service agreement with new software vendors, ask them for a detailed code review. This way, you’ll understand how thorough and action-driven their report is. Other than that, code reviews help managers understand how much time and money they will need to complete the project.
- Create clear documentation standards and monitor compliance. If your previous team didn’t do a great job at keeping track of their work, make sure the new talent is more thorough. Emphasize the importance of code documentation and mention clear reporting practices in the service agreement.
- Forward all the correspondence with the old team to new vendors so that they can catch up and understand what the last contractor you worked with already accomplished. Being aware of the previous team’s best practices and shortcomings is a solid way to complete your project handover checklist.
IT service transition checklist. Where to start?
Our team at Eastern Peak has vast experience helping business owners make the IT transition management process smooth and efficient. Thus, we have developed our own approach to this task.
Our IT service transition checklist includes the following steps:
- Initial consultation. The project transition plan starts with understanding the project’s current stage of development, the main problems that were faced by the previous vendor, how those can be solved, and how to avoid similar issues in the future. We analyze the major transition risks, taking into account the vendor’s specifics, development stage, team size, etc.
- Transition process planning. At this point we cover all the steps that you should take to start the transition process (as described earlier in the article) and prepare all onboarding documents.
- Project review and recommendations. Before jumping into action, we carefully analyze the project’s assets delivered by our previous vendor and provide recommendations on their improvement. We also can help you choose a more efficient project management toolset and suggest ways to make your product even better. If there is any information lacking, we will tell you exactly what is needed. As a result, we will be able to start the onboarding process with your dedicated development team at Eastern Peak.
The above-described process runs under close supervision of experienced product managers and software architects. In this way, you can be sure that the transition is smooth and effortless.
See this project transition checklist in Excel suitable for transition of the projects of up to 10-15 people.
If you are planning to switch your software development provider, don’t hesitate to get in touch.