Speaking from our experience, there are many reasons why clients decide to hand over a project to another software development company. Some have their project left in shambles by unreliable vendors. Others seek to optimize costs by outsourcing the development to Central Europe.
Whichever rationale makes you reach out to another software provider, be aware that the success of the handover process is equally vital for all parties involved: you, who need to onboard the newcomers, and a new development team, who is about to take responsibility for the legacy code and often rectify the mistakes made by the previous vendor. Our point is, you need a solid transition plan. That’s why we come with a checklist* to help you get prepared for the challenge of software project handover and facilitate the team’s transition.
*The flow of the project handoff depends on the given project’s scale, complexity, and maturity, so the following steps are more of a suggestion than a must-have.
Prioritize transparency when selecting the new tech partner
Let us state the obvious: conducting a retrospective assessment of the previous team’s work and using drawn conclusions to choose a better partner is a way to go during a software project handover.
On the one hand, this helps you realize what you’re looking for in the new tech partner and spot the potential red flags from the get-go. On the other, sharing lessons learned from the false start may be a way to “test” the new squad and see how they’d deal with the challenges that were too much for the previous team to handle. By listening to their feedback, you get to assess the new software provider’s know-how, attitude, and development standards. Plus, starting off with trust and transparency is always a good idea.
Another thing worth noting regarding transparency in software project handover is that you have every right to check the new tech partner’s experience in handling digital products’ handoffs. There are a few ways to do that. Firstly, ask the new software provider to share case studies showcasing their processes and success in a project takeover.
Secondly, research and discuss their experience working with legacy code. Your software may not be old, but the tech debt starts accumulating from day one. Thus, if you’re about to change software providers, there’s a strong chance your product already has some weak spots, and a software modernization experience will come in handy.
Check out the Legacy Garage series, where our IT experts discuss how they deal with legacy issues in various projects.
Lastly, check the vendor’s position within independent rankings like Clutch or The Manifest. Such portals showcase the opinions of clients gathered during in-depth interviews and highlight the aspects essential to choosing a reliable tech partner. If this isn’t enough for you, asking your future software provider for references won’t hurt either.
Provide sufficient information and documentation
Developers are not mind readers, even the best ones. Of course, with access to code, they’re able to assess the quality of your software. However, without documentation, the code review job (which we describe in more detail in the following section) gets more time-consuming and daunting – not to mention that it forces developers to ask way more questions or, at the worse, do some reverse engineering.
To make the project kick-off as smooth as possible, you might want to provide the new development team with the following materials:
- Description of the app’s architecture, including particular modules and their correlations;
- Updated README file that includes guidelines for the system’s configuration and installation, operating instructions, list of files included, troubleshooting, changelog, detected bugs;
- Requirements files (requirements.txt, package.json) that contain the lists of packages to install when setting up the environment;
- Description of key algorithms (e.g., calculating the service price or any algorithms that are unusual) and mechanism of importing data from 3rd party systems;
- Description of key classes and the application’s layers; this simply makes it easier for the new team to find the place that requires changes;
- Description of the database structure and in the case of a relational database, a description of their correlations should also be included; this can be presented on ERP (Entity Relationship Diagram);
- Deployment guidelines, which boils down to instruction of how to deploy the source code, database and run the project on a new server, as well as any necessary administrator/test customer login credentials;
- Cloud infrastructure design, which may take many forms, ranging from description to diagrams like this one;
- Environment variables allowing to run the project swiftly;
- Access to third-party services used in the project, such as mailing lists, analytics, payments, etc.;
- UX and UI designs, be it wireframes or full-blown screens design that show the direction in which the product is going visually and in terms of the user flow.
If you’re a non-technical person and don’t have immediate access to these materials, don’t worry; these are the things that your previous vendor should provide you with at your request.
A project handover means transferring software, knowledge, experience, and responsibilities related to managing and maintaining the system during the entire product life cycle. To ensure a partnership based on consultancy, responsibility, and strong motivation, the new dev team should receive the above-mentioned documentation and comprehensive information about the product’s business context. The key areas to discuss are:
1. General introduction to the product’s idea
Under the umbrella term of “product’s idea”, you’ll find product goals, business model concept, unique value proposition, user types together with their needs, expectations, and pain points, the product’s core features, the context of use, and competitive solutions. To share this kind of information efficiently, you might want to use the following tools:
- Business Model Canvas
- Value Proposition Canvas
- User Persona
- Story Map
- Development Roadmap (functionalities divided into groups for next releases)
2. Project’s statuses: done, in progress, and to-do
This means outlining what work’s been done by the predecessor, what stage of the development roadmap you are at now, what work remains on code that hasn’t been deployed yet, and the scope of the upcoming work.
3. Challenges
The road to success is usually bumpy and full of twists and turns. Therefore, when handing over your digital product to a new tech partner, summarize the challenges you’ve encountered so far, the processes that have worked fine, and the solutions that backfired. Brainstorm with the new team the obstacles you can meet on the way and the best ways to prevent them from occurring.
4. Workflow
Lastly, don’t forget to point to the tools, workflow, and management methods you’ve relied on and decide which ones you’ll stick to after the team transition. Also, define the roles and responsibilities of the team members-to-be, especially your duties versus the upcoming project manager’s ones. Here are a bunch of questions to cover:
- Management: What kind of management framework should be applied (e.g., Scrum, Kanban, or Scrumban)? When should you agree on Scrum, how long will the sprint last? What days should Scrum events take place, and who will be involved in them?
- Roles: What are the responsibilities of particular team members, including the Product Owner, Scrum Master, and the rest of the team members?
- Communication: What tools will the team use to handle communication (e.g., Slack, Skype, Hangouts)? How often will there be video meetings?
- Workflow: What tools will we use for task management, time tracking, etc.? What will the development workflow look like?
Let the new business partner perform necessary assessments, including code review
A project well begun is half done, as the saying goes. That’s why an effective software handover process must begin with a series of reviews, such as a technical audit, QA audit, and UX audit.
Let’s start with the technical audit, which includes the backend and frontend code review. It’s a prerequisite for measuring technical debt, assessing the general health of the application, and the new team’s capabilities to handle it.
A code audit is a top-down source code analysis that takes place whether there is an app’s documentation or not. Naturally, long-established code can have some defects. However, the problem arises when their scale and severity are large. This can make implementing new features time-consuming and costly and disable effective code refactoring. Code review triggers objective feedback, risk evaluation, and a rescue plan if needed.
At Merixstudio, once we scrutinize the code of the app we’re taking over, we summarize the findings by describing and prioritizing the problems and the remedial actions. Some of the questions we address during the code audit are:
- Is there compliance with the coding standards (e.g., PEP8)?
- What is the unit test code coverage? Unit tests facilitate further development and error detection.
- Are there any sensitive data stored in the code?
Two other audits that often take place in the event of a project handover are QA and UX audits. The former involves Security, GUI, Basic API, Usability and Basic functional testing, and a Lighthouse audit. The latter is about analyzing your system from the user perspective, including available data analysis and observations. To make the most of the UX audit, the tech partner may ask you to cooperate with their researchers.
💡 If it’s your first project handover, you might wonder if the new software provider actually needs so much detail on your digital product.
We don’t blame you if asking for access to the entire codebase so early looks a bit suspicious, but we’d also like to put you at ease by saying that such requests are completely normal. With access to the code, the team that takes over the project is capable of creating a tailored proposal based on much more than just a gut feeling.
If you can’t grant the new tech partner access to the code, do expect the team to come up with a list of questions that’ll help them understand your product better. These may concern the tech solutions, processes, product features, challenges, and opportunities, but also things like reasons for project handover, priorities, and plans for the future. Depending on your answers, the new team will be able to prepare various handover scenarios, the most relevant of which will be chosen based on the state of your code.
To give you a better idea, the transition plan proposal for a system that needs improvement around tools and tests coverage to secure stable development in the future would look like that:
Whereas the handover plan for the same project, but in a situation where there are no serious code issues, and there’s a greater focus on further product development, would look like that:
This is by no means a comprehensive list of all assessments that may await your project, but it should give you an idea of what you may expect during the initial phase of software handover.
Ask the new tech partner for the transition plan
The audits are just the beginning. A reliable tech partner should provide you not only with a summary of the findings and remedies, but also with an overview of the next steps in the project handover process. Such a transition plan should give you a sense of how long particular stages will last (the exact timeframe is project-specific, as always), which software development services they will involve, and what the team composition will be. Here’s one example of how we visualize the software project handover process to our clients:
Allow time overlap with the outgoing team
Ideally, the software developers who have been working on the project would work hand in hand with the developers who are taking over the project during the overlap period. Direct information exchange between engineers is by nature concise and straight to the point, which translates into facilitating communication and shortening the feedback loop.
Mind you; the new programming team may initially work with lower velocity, as they need to get familiar with the app’s code and architecture in the first place. Having two teams overlapped can speed up the onboarding process (by the old squad being a support for a new team when specific information is needed), reduce the risk of setbacks, and keep the velocity constant.
Sometimes, however, the two teams don’t have much time to work together. It may be because your cooperation with the previous software development company ended abruptly. Or it may be because the potential new vendor proved unreliable, and you need to start looking for a trustworthy partner from scratch while the notice period is shrinking mercilessly. Whatever the reason, we’ve got good news for you: one day may be enough for such knowledge transfer.
📙 Our experience with one-day knowledge transfer for project handover
Flexibility lies at the core of Agile, also in software project handover. One day, we were approached by a client who decided to hand her project over to a different software provider. Once she terminated the contract with the old vendor, however, the new one stood her up. By the time she reached Merixstudio, the notice period with the old software house was ending.
To make the most of the remaining few days, our Discovery & Analysis Team came up with a list of questions about documentation, code, UX/UI, and QA processes that would facilitate the upcoming handover. Then, we invited the client and the old vendor’s developers to a meeting, during which we discussed the context of the product and the answers to the aforementioned questions. The deliverable was the quickly-generated initial documentation in the form a video recording of the meeting, which can serve as a source of truth not only for our team (which was to step in soon) but also for all teams yet to come.
Handling knowledge transfer in such an unusual way has a couple of benefits. For the client, it provides a source of truth for the future developer squads and gives insight into the potential new partner’s processes, level of inquisitiveness, and expertise. For the new software provider like Merixstudio, it allows gathering as much knowledge about the project as possible. It’s worth noting that in many cases, the workshop/handover team is composed of different individuals than the final project team, so a knowledge transfer video will come in handy sooner or later anyway.
Meet the new development team
Remote work is nothing new in IT. But trust us, there’s nothing like meeting in person, especially when you kick off a project. Your new development team are the people with whom you’re going to collaborate closely, probably over a fair period. The better your rapport with them, the greater your achievements will be. Create an opportunity to build a relationship – meet the development team face to face, see their office, chill out with them. The human touch can only foster the team spirit and make your cooperation more fun.
Why people and company culture matter so much in remote cooperation?
Project handover is a complex process that includes steps like development, testing, deployment, maintenance, project management, etc. We hope that this blog post has given you insight into the steps you can take to go through it smoothly. Good luck!
Your current software development vendor didn't meet your expectations? We've got a vast experience with projects passed from other companies. See how we can help you and why you should choose Merixstudio as your new IT partner.