Knowledge transfer in software development outsourcing: how to move projects to a new vendor
When you’re switching a project to a new software development provider, knowledge transfer is essential. It’s important that everything is handed over properly so the new vendor can start working quickly. But what exactly is knowledge transfer? It’s the process of giving information from one group or person to another.
In software development outsourcing, it means giving all the details about the project — from design specs to code samples and user manuals. To make sure the transition goes smoothly, you need to create an organized documentation package with all the relevant data. This way, once the new team takes over, they can easily understand what’s going on.
What are the pitfalls to avoid when moving from one software vendor to another?
When you’re transferring a project to a new vendor, the process is never as easy as just handing over the files and walking away. Knowledge transfer in development outsourcing requires careful planning and management. If you want a new team to work efficiently on your product, you need to know the pitfalls of moving from one software vendor to another.
Diverse mindsets. Each person looks at a situation from their own angle. With different backgrounds, knowledge and experience, different teams may come up with different solutions to bring your project to life. While this is totally fine for new projects, it may lead to unnecessary costs and time loss in legacy projects.
Lack of well structured documentation. If the previous team did not create a detailed project documentation, new developers will have to spend more time on knowledge transfer and understanding product peculiarities. So, before you give the green light to development, make sure that SRS, API documentation, release notes, how-to-guides, and other tutorials are in place.
Underestimating tacit knowledge. Tacit knowledge is acquired through experience and observation and cannot be recorded on paper or shared verbally. For example, it is almost impossible to explain how to debug complex software or evaluate the suitability of a new technology. The decision is made based on professional competence and critical thinking, and such knowledge can be passed only through mutual cooperation.
Lack of a knowledge sharing plan. Unsystematic knowledge transfer leads to lost time, misunderstanding the product concept, and late releases. To get a new team up and running quickly, you need to create a knowledge transfer plan between vendors. This might include setting up regular video calls, sharing files in a cloud-based system, and collaborating in a mutual workspace. Having a knowledge transfer document in place, you will know when the team is ready to start working on the project.
Inefficient knowledge transfer tools. Sharing information can be much more efficient if you use modern tools like Google Drive, Slack, GitHub, SonarQube, Zoom, and more.
How to execute knowledge transfer
Knowledge transfer outlines how you will pass on your years of experience and hard-earned knowledge to the members of your team who are taking on new or expanded roles. There is no single approach to knowledge transfer for outsourcing. Each company decides how to share experience depending on the specifics and needs of the project. However, by following the steps below, you can be sure that nothing important will be missed.
Step 1. Define the goals of the knowledge transfer
Before you start the knowledge transfer process, you need to define its goals. In other words, what do you want to achieve?
- Are you looking to hand off the project and walk away? Or are you going to take an active part in the development?
- Do you want to entrust the team management to a remote CTO? Or are you going to control the development process by yourself?
- Can you transfer the full amount of data to your provider? Or are you limited by certain regulations, such as the GDPR?
Your goals will dictate the scope and structure of the knowledge transfer process. So it’s important to take the time to define them upfront.
Step 2. Decide what knowledge needs to be transferred
To prepare for a knowledge transfer between development teams, you need to take inventory of the information in place and decide what to share. This means taking a step back and assessing the following:
- What knowledge is currently possessed by your team?
- What knowledge do you currently have access to?
- What knowledge do you need to outsource?
- What knowledge do you need to revise?
Once you have a good understanding of the answers to these questions, you can start creating a plan for transferring that knowledge.
Step 3. Identify the knowledge holders
Not everyone in the company is a knowledge holder. You need to identify key people who can convey vital information regarding the project implementation.
Key people are those who know how the software works, how the business works, and how all the pieces fit together.
You’ll need to sit down with them and have a conversation about what they know and what they don’t. You’ll also need to identify their areas of expertise, and then record all of this information in knowledge transfer documentation.
Step 4. Design the transfer process
Here are a few steps to help you get started:
1. Define the scope of the transfer. What exactly do you want the new team to be able to do? For example, you may hand off the implementation of a full project, its specific features, or managerial tasks. The scope of tasks will define the scope of data to be transferred and the scope of knowledge to be possessed by the new team.
2. Outline the steps involved in completing each task. This will help the new team understand the process and how they fit into it. For example, you may indicate that the new CTO should get acquainted with the current RACI matrix, and the development team should run the code review in Git.
3. Create a training plan that covers everything they need to know. This should include how to use the software and systems, as well as general best practices.
4. Make sure all your documentation is up-to-date and accurate. The last thing you want is for the new team to be struggling because they can’t find the right information.
5. Transfer ownership of all accounts and passwords. Make sure the previous team does not have access to the project after the knowledge transfer.
Step 5. Execute the transfer
At this stage, you should prepare a roadmap for ensuring a smooth knowledge transition. It will outline all the steps you and your team will need to take to ensure that the new development center can hit the ground running.
Included in the plan should be:
- a timetable for the transfer
- details on who will be responsible for each step of the process
- a list of resources (including people, documents, and software) that need to be transferred
- the steps you will take to ensure that communication is smooth between your current team and the new development center
Step 6. Evaluate the success of the transfer
After you have prepared and organized the knowledge transfer, it is important to evaluate its efficiency, but how to do it? First of all, you need to determine the components of success. Is it the number of people who have been trained? The amount of money saved as a result of the transfer? The improvement in customer satisfaction?
The following questions can help you define knowledge transfer metrics no matter whether you run a startup or an enterprise.
1. What was the original goal of the transfer?
2. How well did the transfer meet that goal?
3. Which methods were used to assess the results of the transfer?
4. What factors contributed to the success or failure of the transfer?
5. What lessons were learned from the experience?
Evaluating knowledge transfers is an important part of learning from past successes and failures. By understanding what works and what doesn’t, you can continue to improve your processes and achieve even better results.
Knowledge transfer roles: who does what
When you’re considering transferring your company’s technology to an outsourcing partner, it’s helpful to understand the different roles and their associated responsibilities during the process. In a classic example, the knowledge transfer participants are as follows:
CTO. They are responsible for the overall technology strategy. During the knowledge transfer, a CTO should ensure that the company’s goals are understood and met.
Project manager (PM). They monitor project progress and set deadlines for task implementation. During the knowledge transfer, they communicate product requirements, current development progress, and the usual development routine.
Developers and testers. They are responsible for product development and checking. When sharing knowledge with a new outsourcing team, they should
- create detailed documentation of all system functions and processes
- identify potential risks the software may encounter
- share the code base and encourage the new team for code review
- work with the outsourcing partner to create a plan for migrating data and systems
DevOps. They ensure that all systems are integrated and aligned with company standards. When sharing knowledge with a new team, DevOps should explain what technologies are used to deploy the software in a given IT infrastructure.
Conclusion
Companies decide to make a knowledge transfer and sitch software development providers when they realize that the current technology partner can no longer meet their needs. It is necessary to carefully prepare for this process. The important step is to select a new software development provider and discuss with them all the nuances of project management.
At Erbis, we have extensive experience in modernizing software products and dealing with legacy code. When such a project comes to us, we study documentation, test the product on different devices, and review the code.
Then we create a product development plan where we what and when will be done. When the client approves the plan, we start development.
If you feel that it’s time to change your software development provider but don’t know where to start, don’t hesitate to contact us. We’ll be happy to help.
