Unshared knowledge costs your company a lot of money. Whatever knowledge is not managed and shared is eventually lost. It is specifically true for IT outsourcing projects. Whether you are moving from one vendor to another or simply finishing cooperation with your current company, knowledge loss could result in lots of organizational waste when the whole process gets reworked from scratch. 

How to ensure the smooth knowledge transfer in IT outsourcing? Having a robust knowledge transfer plan in software development could make the whole journey easy and safe. In this article, we share our tips for the effective project transition when switching a vendor. They are backed by our experience in exchanging project and product knowledge with a number of companies we've worked with (e.g., Lebara, Gogo, Fluke, and Travelport). If you are thinking about moving to another vendor, but knowledge transfer issues hold you back, here’s what you can do to ensure a successful knowledge transfer in IT outsourcing

5 key steps in the knowledge transfer plan you should keep in mind 

Much of the project knowledge exists in documentation, but the most valuable knowledge still resides in people’s heads. Explicit knowledge that is recorded is just the tip of the iceberg. Tacit knowledge (a.k.a. implicit) based on a person’s experience, by contrast, is the most hard-to-transfer asset. According to a report [1], 51% of the average employee's workplace knowledge comes from experience.

Tacit and explicit knowledge transfer plan in software development

Challenges in capturing and transferring different types of knowledge

The biggest challenge with explicit knowledge is to ensure that knowledge is captured and people have access to it. It is critical to ensure that important knowledge is properly stored, managed, regularly reviewed and updated. It is quite easily transferred, when you have a plan and a list of items to cover. Such items like user documentation or project roadmap are examples of transferable explicit items.

When it comes to tacit knowledge, it becomes much more complicated, as tacit knowledge represents intuitive knowledge and experience. It most often resides in the minds of knowledge holders. Thus, one needs to carefully examine and understand what each stakeholder or expert can share/know. To transfer tacit knowledge, you will need to pay a lot of attention to context-dependent knowledge, e.g., troubleshooting or best practices. 

There are different knowledge transfer flows. It can be performed either from a client to a vendor, which is the best-case scenario, or from a previous vendor to a new vendor, which is a bit more challenging if you don’t have a robust plan. 

Knowledge transfer in IT outsourcing: Step-by-step plan

N-iX has a proven track record of successfully delivering projects acquired both from clients and their previous vendors. From our experience, we have realized that knowledge transfer fails when it is ad hoc and informal, and it succeeds when it is strategic and methodical. Below, you will find a plan for knowledge transfer in IT outsourcing projects based on the lessons we learned through years of cooperation with clients across the globe.

knowledge transfer plan for it projects

1. Define what knowledge to collect

Determining what information you need to gather is the backbone of the effective knowledge transfer plan. Here is a checklist of essential knowledge items to collect taken from the perspective of three different levels: organizational level, team level, and individual level. 

Organizational level ( vendor-to-vendor or client-to-vendor)

Documents

  • Sensitive data transition
  • Information on source code ownership
  • Product Regulatory Compliance (if relevant)
  • Non-disclosure agreement (if relevant)
  • Partnership termination agreement with a previous vendor (if relevant)

Team level (team members-to-team members)

Source code

  • Repository URLs with access details
  • Description of key algorithms 
  • Specification of classes and app’s layers

Internal processes and workflows

  • Deployment guidelines, system configuration and installation, operating instructions, troubleshooting, changelog, and bug tracker data
  • Software development workflow
  • Branching strategy
  • Software development tools and techniques 
  • CI/CD best practices

Access to the systems used team-wide

  • Access to the existing environment and third-party systems

Documents

  • Description of business requirements
  • Project roadmap
  • Software architecture documentation
  • Database structure design
  • Design files: mockups, graphics
  • User stories
  • Test cases
  • User documentation

It’s best to have all these items in a knowledge transfer checklist to ensure that nothing is left behind.

Individual level (expert-to-expert)

An exchange of knowledge on the individual level is the most important part of the knowledge transfer process. Inheriting an IT outsourcing project is like receiving the keys to a room you don't know how to walk into. A big part of the knowledge is the code itself. But it’s one thing to know what the code does and it’s another thing to understand what hidden landmines might be in it. Thus, one-on-one meetings, tech talks between software engineers, DevOps professionals, architects are obligatory to understand the logic behind the code and some well-established best practices when moving from one vendor to another.

2. Assign people who transfer and receive knowledge

Once you know what knowledge to collect, it’s time to determine the go-to persons in your vendor’s organization who could provide the necessary info on each level. For example, on the organizational level, it is necessary to speak to a Delivery Manager and representatives from the engagement, legal, and finance departments. On the team level, it is essential to contact a CTO, a project manager, a Scrum Master, business analyst, etc. And when it comes to a knowledge transfer from an expert to an expert, these are usually meetings between QA engineers, UX/UI specialists, software developers, DevOps professionals, BAs, software architects, etc. It’s important to understand critical tasks an expert oversees, their importance level, and possible hidden pitfalls.

project transition plan from one vendor to another: knowledge holders

You can also assign roles or mention these personas in the knowledge transfer document for IT projects. This way, even if an employee leaves the company, the role in the project remains and the successor will be able to pick up. 

3. Select the most effective methods for knowledge transfer

Having non-stop meetings assuming that your new development team will be able to grasp all the information isn’t the best way to ensure knowledge transfer. Important knowledge should be captured and properly stored. If it is a meeting, then it should have an agenda and meeting notes or other files that you could further work on. But there is a variety of other knowledge transfer methods, and here we’ve outlined those that prove to be the most effective for knowledge transfer in IT outsourcing. 

  • Technical documentation: architecture overview, release notes, how-to guides, presentations, knowledge base articles, etc.
  • On-site training for a focus team (receiving team)
  • Live training for a focus team
  • Q&A sessions
  • Tech talks 
  • Live demos
  • One-on-one meetings

4. Choose knowledge storage

Make sure that the team has a designated secure space that stores all the items discussed in the previous step. If you have no dedicated space for company-wide knowledge management, it might be the right time to make this decision and stick to it. While searching for a knowledge storage, make sure that it: 

  • Supports a variety of formats, like text, images, video, audio, etc.;
  • Has enough scaling capacity;
  • Provides different access levels for various roles (like superadmin, admin, user).

You can choose a single platform or have a combination of solutions (e.g., knowledge base in Confluence, an internal portal with docs and videos, intranet, etc.). Provide access to the knowledge base to all involved parties and make sure it is updated on a regular basis. 

In future, this platform can serve as a knowledge management system for the whole company or a department that is dealing with a particular software or project. 

5. Conduct knowledge transfer 

The final step is to conduct the knowledge transfer based on your plan. Once you have collected all the knowledge elements and allocated designated experts, proceed according to your plan. Unfortunately, there is no formula or script that would allow you to measure the success of the process. However, there are certain things you can pay attention to:

  1. You can analyze how quickly your team has managed to get started with the project: set up the development, QA, staging and production environments and get access to the systems used team-wide to be able to deploy releases and debug.
  2. Every team member has access to project description and specifications. Common tasks are performed routinely and do not take a lot of time and/or human efforts. On average employees report spending eight hours per week roaming online for information and reworking an existing task or a process.
  3. The team has a secure knowledge storage, that they can refer to in case they have any questions or need to clarify something. 

The successful knowledge transfer will save you money and streamline the productivity of your new software development team. 

Knowledge transfer process at N-iX projects

We have been refining our knowledge transfer plan for more than 20 years, since the partnership with our first clients. It has been tested by time and our clients report its effectiveness as it meets their success criteria. The knowledge transfer plan is an integral part of cooperation with the majority of our clients, including Lebara, Fluke, Gogo, and Travelport.

Here at N-iX we help companies with project transition plan from one vendor to another, offering them a detailed plan for this process

Here are our success stories:

  • Our partnership with Lebara , one of Europe's fastest-growing mobile companies, started in 2014. Back then, we worked under a staff augmentation model of cooperation, and most of the software development was done on the client’s side. Now, we have a big development team of more than 100 engineers who work on multiple products for Lebara in Kyiv and Lviv. We have managed to successfully acquire knowledge from the client’s team in London. And today, most of the tech leads, project managers, and prevailing tech-related decision making are on our side.
  • Fluke Corporation, a leading manufacturer of industrial test, measurement, and diagnostic equipment, started cooperation with N-iX with a small development team of eight specialists. Within two years, it has increased to 22 members. Thanks to the effective knowledge transfer plan in place, N-iX team easily integrated with the client’s other remote teams located in the USA (Everett, Florida), India (Bangalore), and Ireland (Dublin) and ensured successful delivery of the products.
  • Gogo, a North American market leader in in-flight connectivity, has teamed up with N-iX to expand its development capabilities. N-iX engineers started the project by initiating a knowledge transfer process that ensured speed development and high productivity of software engineers. The N-iX team has provided end-to-end software development of the cloud-based platform which collects data from more than 20 different sources and found the reasons for ill-performance and equipment failures, reducing the number of not-fault-founds by eight times.
  • Travelport Locomote partnered with N-iX in 2017 to enhance its existing corporate travel platform and enter new markets. The N-iX team has established close cooperation with the client and other distributed teams located in different countries, including Australia, the UK, and Romania. The knowledge transfer plan has helped to integrate coding practices between different distributed teams and get new teams of the client up and running quickly.

Wrap-up

The success of knowledge transfer in IT outsourcing depends on several aspects: people, processes, and a product. Without the proper understanding of what the product does, how it operates, and what people are responsible for specific tasks, it is impossible for a vendor to deliver on the client’s expectations. 

Our knowledge transfer plan covers all the important types of information you need to gather when moving to a new vendor. Not sure about how to build a knowledge transfer plan in your particular case? See if we can help you.

References

  1. Panopto Workplace Knowledge and Productivity Report 
  2. Experience and Knowledge Management in Software Engineering by Kurt Schneider
  3. Handbook of Organizational Learning and Knowledge Management, by Mark Easterby-Smith

Have a question?

Speak to an expert

Required fields*

Table of contents