Work on your software project may still be in progress, but you may realise that your relationship with your IT contractor is not working out, and parting ways seems inevitable. There may be multiple reasons behind it: maybe you face issues with the project timeline, product performance, or communication, or maybe you just need people with a different set of skills at this stage of the product development cycle. These are the most common prerequisites for project handover to a new team.
However, if the latter is not your case, first try negotiating and defining your concerns with the team. After careful evaluation of your motivation and reasoning, we'd recommend evaluating your final decision and implementing mitigation strategies to fix and improve the current team's issues. If the sticking point is the quality of the product, inviting third-party consultation agencies (who will evaluate the job of the technical team, provide recommendations, and control their implementation) might help you to avoid a painful project handover. Most companies care about their reputation; thus, they will try to streamline their working processes. If all your efforts don't make any difference, you can then consider the contractor's departure and your project's handover to someone else.
To keep the ball rolling, it's better to notify the contractor about your decision to transfer the project to a different team in advance. Thank them for the job they have done and show them your appreciation for their time and effort invested in your project. Parting amicably should be your priority, as you are very likely to contact this team again during the project handover and your new team might need your old team's help.
Software project handover common concerns
Switching to a new development team is a risky step often associated with various concerns. The most common of them are as follows:
Losing access to intellectual property
Overcomplicated onboarding process
Financial risks
Losing access to intellectual property
As you are planning to terminate the project amid the contract, you may still have the remaining balance left to pay to the old team. Therefore, there is a chance that they will not provide you with access to the code. However, if you were able to build a somewhat decent relationship with them, you will manage to negotiate and get it back. It's important because, without full access to the repository, you will have to pay the new team for development from scratch, which doubles your spendings. You should also get back all the reports & credentials related to your project environment, including the task tracker, project documentation, infrastructure, etc.
Overcomplicated onboarding process
It's another risk associated with project handover. It is likely that the new team will not be able to clearly understand and maintain the old code. To mitigate this risk, the new team should first look through all the project-related documents and evaluate their state and quality. Regardless of how your existing code is written and documented, new members will take it from there with it, but it is going to affect the following important aspects:
- The qualification level of engineers working on your project;
- The duration of the examination and onboarding processes;
- The duration of further support and feature development stages.
So, if the examination reveals an unreadable, extremely buggy “spaghetti” code, the new team will have to rewrite it and apply multiple fixes. It will take them more time and result in additional expenses for you. In extreme cases, they might even suggest restarting the development anew instead of attempting to organise the low-quality code. However, if such requests are coming, they should be well-justified and backed with the audit documentation. You may also expect written recommendations and more accurate estimates as a result of the audit.
Financial risks
A client who was forced to transfer their project to a new contractor is very suspicious and hesitates to trust a new team. It's normal after having a bad experience. They are not only concerned about the product development itself but also afraid of getting victimised by swindlers. A disappointed business owner may even expect that their new contractor will get the money but won't generate any additional value. It's not the best starting point for collaboration with a new partner. To avoid such disappointment, you need to carefully research the potential software development contractor. Moreover, you can even set a probation period during which you can test and assess the team's work or contact their previous clients and ask them any work-related questions.
The majority of the challenges while switching to a new technical team in the project are usually related to documentation. Some issues might also occur due to insufficient testing and confusing software architecture. To get prepared for such risks, you need to know what this stage looks like and what might await you. Below, you will find precise answers to the most important questions.
How to prepare yourself for the switching of development teams in your project?
Before switching the development team, try to pull as much project information and documentation as possible. It will greatly affect how fast the new team will be able to grasp the projects' context and onboard. Let's discuss what exactly you might need.
Ensure that you are the owner of the repository
Irresponsible outsourcers can work on the code locally, without providing the customer with full access to their repository and ownership status. If you want to terminate the contract, you need to make sure that your contractors don't keep the intellectual property of your project to themselves. They may even refuse to provide access to it. Please be aware that this is illegal; you should not be deprived of your rights. If your former contractor is refusing to give your code—the product you were paying for—back to you, you can legally sue them. In most cases, it is explicitly stated in the contract: the owner of the code and any other intellectual property of the project is the client.
Request the core set of the documents from your soon-to-be-ex contractor
Documents can be technical and business. Be sure that you collect both to ensure faster understanding of the project context and product functionality by your new team. The documents need to be up to date, legible, and legitimate. All information related to the project should be properly documented. The documentation should contain a full project overview. You need to be able to refer to it for justification of any future interactions and issues that may arise between yourself and the technical team. Moreover, it can help you track the thought processes of previous technicians and better understand their decision-making.
What does switching to a new development team look like?
Discuss the existing problems with prospective companies
First, you have to research the market and make a list of companies you potentially want to collaborate with. Make a phone call to discuss the existing problems. It will help you understand how well you fit each other and figure out whether the new team has enough expertise to work on your project. To make the most of such conversations, it's better to elaborate the short-term and long-term goals of the project and create a list of problems hindering the implementation stage.
Elaborating the statement of work
A statement of work (SoW) is the document stating the negotiated objectives, deadlines, and costs. Moreover, it also outlines the services to be rendered and the responsibilities of all stakeholders. This document is used to make sure that all the involved parties are fulfilling their part of the contract. It will help you track what the contractor should deliver and explain what you have to provide to the contractor to get your project completed at the highest level of quality. Therefore, it is important to make a highly detailed SoW to minimise any future disputes between the business owner and the contractor.
Technical or complex audit
Before signing the contract, the new team may require conducting a technical or complex audit. It includes the evaluation of code, IT infrastructure, policies, business processes, and operations. It is needed to inspect the risks and ensure that your business is efficiently operating and securely processing all the data. Finally, the potential contractor should provide an audit report and explain whether they have enough expertise to work on your product. At this stage, the business owner can evaluate the contractor's experience, core skills, and interest in the project.
At Mad Devs, we are providing professional consulting service to streamline your business processes. We have worked on 50+ diverse IT projects, developing software and building processes for our customers to help them succeed and save money. If you need an audit of your company's IT infrastructure and software development processes, please contact us.
Onboarding
After you have chosen the team and signed the contract and SoW, the onboarding process begins. First, you need to make an introduction call to get to know the new team and collect their ideas related to your project. These intro calls are very important as they are setting the tone of your future relationship. You will also check the team's interest in the project and motivation to work. Note that the members of your new team will not necessarily be the ones involved with the initial audit. After the introductory meetings and Q&A sessions, you can consider the onboarding stage completed. The new team will start working on your project.
Bear in mind that extended deadlines are possible at this stage. Adaptation and newly revealed challenges will take some time. The new team will need to establish work processes in accordance with their standards first. Usually, full acclimatisation takes a couple of months. You should expect first big features, not just minor improvements, after the dust settles down. A good team will take ownership of their mistakes. Don't put up with any excuses of linking their own mistakes to the work done by your old team, if you have allocated enough time for the project handover.
Conclusion
Start searching for a new team only if you are 100% sure that you need to break up with the initial developers. Project handovers might be risky and expensive. Look for a reliable technical partner with years of experience in your domain. You should be able to effectively and comfortably communicate with them. Make sure that they are interested and involved in the project. The project handover will require some time and effort. However, if you stay organised, make proper arrangements, and have clear expectations, you will be able to successfully complete this mission, and all the troubles will pay off in the end.
Latest articles here
