Taking the Fear out of Knowledge Transfer With IT Vendors

Whatever the reasons for offboarding an IT vendor, there is one common statement that many have said: “I’ve been with my current IT vendor for so long. How could I possibly transfer that knowledge without completely disrupting my output?” Onboarding and offboarding IT vendors is a project in and of itself, and it needs a plan. Although there are many topics to consider when transitioning to or from an IT vendor, the most important is knowledge transfer (KT). This article will focus specifically on this area. To frame the plan, consider the scope, the amount of time allowed, and the costs involved.

First, identify the scope of the KT project by documenting the topics to cover. Because this first step can feel overwhelming, a list has been provided to help get started. This list of topics may not be all-inclusive, as certain items in this list may not be relevant. All products are different so the list should be tailored to specific needs. Also, it is broken down by roles on a project, as certain team members will have more knowledge on certain topics than others. Depending on the size and complexity of the product, documenting all of the necessary information could take some time, especially if there is currently little existing documentation.

Knowledge Transfer Topics

Development

• IT documentation
  • Technical design
    • Diagrams
    • Flow charts
    • Licensing requirements
  • Tech stack and code documentation
    • Front end technologies
    • Back end technologies
    • Frameworks and libraries
    • Database
  • Hosting technologies
    • Repositories
    • Cloud or on-prem infrastructure 
  • Existing third-party integrations and the services they perform
  • Deployment procedures
    • Tools and methodologies
    • Versioning
    • Branching strategy
  • Unit test requirements
• Detailed code review
• History of development decisions
• Technical debt
• Security requirements

Design

• Design software used
• Asset transfer
  • Wireframes
  • High-resolution designs
  • Prototypes

Quality Assurance

• Test case software
• Test strategy
  • Manual testing
  • Automated testing 
  • Performance testing 
  • Accessibility testing
• Device matrix
  • What operating systems are supported
  • What devices are supported
• User analytics 
• Previous test summary reports

Business Analyst

• Project/product requirements
• Documentation requirements
• Task status
• User workflows
• Process flows
• Use cases

Project Manager

• Project/product Requirements (scope)
• Project management methodology
• Stakeholder information
  • Contact information
  • Roles and responsibilities
• Communication plan
• Risk register review
  • Technical risks
  • Financial risks
  • Schedule risks
  • Scope risks
  • Performance risks
• Project roadmap walkthrough
  • Current milestone progress
  • Dependencies
  • Blockers
• Budget status
• Project history
• Existing meetings 
  • Ownership
  • Responsibilities
• Change management plan

Knowledge Transfer Plan

As you work to understand the scope of a KT project, you need to get a plan going. A KT project plan should encompass a stakeholder management plan; a communication plan; a risk register; a schedule, including a list of activities and meetings; acceptance criteria; and resource management. Getting the help of a project manager who is experienced in planning is a good starting point for all of this work.

Stakeholder management will be one of the more important aspects. Before doing anything, a project manager will take into consideration how the existing team will respond to the news that they are coming off the project. Understand this concept is a start to your risk register. Teams can react differently depending on how the news of offboarding is presented. Another piece to the stakeholder management plan will include who will be responsible for the various activities.

The communication plan will establish guidelines on how stakeholders should communicate, indicate which topics will need meetings, and establish ground rules for the meetings. This will be useful for mitigating the stakeholder management risk. For example, before having meetings on the smaller topics identified above, have a meeting where the new team gets a product walkthrough. The importance of this high-level overview cannot be overstated, as it will give the entire team an opportunity to understand the big picture. Meetings are a great opportunity for feedback loops to ensure there is complete understanding. Be sure to allow the teams to have follow-up meetings on topics should the need arise. Finally, a good recommendation for the communication plan is to record all of the KT meetings, so team members can re-review them at a later time.

Getting people access with the correct permissions to environments, repositories, databases, and various tools can often take considerable time. There may be access to hardware involved, and certainly software access will be critical to getting started with the knowledge transfer. Identify any potential roadblocks, such as hardware access and per-user license costs, as early as possible, and get them in the risk register for monitoring and mitigation.

Acceptance criteria are an important part of any project, and this is also very true on a KT project. When onboarding a new vendor, give the new team the opportunity to approve documentation and overall KT of a topic, as this will ensure they take responsibility for understanding the product and will empower them to ask questions until they get the necessary answers.

Capturing Implicit Knowledge in the Transition Process

While maybe not thought of as a part of KT, it is very valuable to have an agreed-upon transition plan when moving from one vendor to another. Much of this article has covered explicit knowledge, which is easier to document. But there is also implicit and tacit knowledge to consider. The fact that not everything can be documented should also be recorded in the risk register. There are a number of approaches to mitigating this risk, depending on the product. A phased approach to vendor transition can be valuable for gaining both implicit and tacit knowledge. For example, try having both the existing team and the new team work on different tasks at the same time. This will build confidence for the new team when the time comes to have a final switchover. There may also be certain tasks where a parallel approach can be valuable to gaining undocumented knowledge. This can be useful when trying to gain experience with tasks such as a product version release. If possible, it is also beneficial to work out a time period after the switchover where a subject matter expert from the previous team will be available for any final last-minute questions.

Knowledge Transfer and Transition Schedule

Finally, the schedule of the KT project can drive overall success. Like any project, adjusting a timeline will have cost and/or scope impacts. Shortening a timeline will likely impact the scope resulting in topics not being covered or covered incompletely. While shortening a timeline may seem like an immediate win, sending a team to develop and support a product that is not fully understood can have cost implications down the road.

Take the fear out of knowledge transfer by having a plan and managing risks. Plans provide a defined path for all team members to follow and will give you the needed gauge to measure the success and completeness of your KT project.