A Check List for Knowledge Transfer

Sooner or later, you have to deal with the task of project acceptance or transfer. To do that efficiently, I follow my own check list, so as not to lose sight of anything and make it in such a way that the customer or project owner would not notice the change of teams.

knowledge transfer knowledge transfer
  • Team structure: 

    ×

    How to do this task:
    Subtasks:
  • Members of the team

    ×

    How to do this task:
    Subtasks:
  • Hierarchy and responsibilities, reporting

    ×

    How to do this task:
    Subtasks:
  • The customer's / related teams' / vendor's contacts

    ×

    How to do this task:
    Subtasks:
  • Business requirements, trying to get access to

    ×

    How to do this task:
    Subtasks:
  • Description of business requirements

    ×

    How to do this task:
    Subtasks:
  • User documentation

    ×

    How to do this task:
    Subtasks:
  • Test cases

    ×

    How to do this task:
    Subtasks:
  • Source code:

    ×

    How to do this task:
    Subtasks:
  • Repository URLs

    ×

    How to do this task:
    Subtasks:
  • Creating accounts with the required rights

    ×

    How to do this task:
    Subtasks:
  • Getting all configuration scripts and requirements for developers' workstations

    ×

    How to do this task:
    Subtasks:
  • If possible, creating automated scripts of environment deployment or creating system images – to save precious time for the developers.

    ×

    How to do this task:
    Subtasks:
  • Technical documentation:

    ×

    How to do this task:
    Subtasks:
  • System architecture

    ×

    How to do this task:
    Subtasks:
  • Sub-system architecture

    ×

    How to do this task:
    Subtasks:
  • Architecture in terms of technical primitives

    ×

    How to do this task:
    Subtasks:
  • Architecture in terms of business tasks, use cases

    ×

    How to do this task:
    Subtasks:
  • Team's technical debts

    ×

    How to do this task:
    Subtasks:
  • All technical findings and proposals regarding the existing system

    ×

    How to do this task:
    Subtasks:
  • It is possible to carry out an experiment: ask the new team to create a "pattern" of the system with the purpose of identifying infrastructure components that ensure the system's operability, and superimpose business requirements on that – judging by my experience, people catch on the project much quicker.

    ×

    How to do this task:
    Subtasks:
  • Delivery and environment system: 

    ×

    How to do this task:
    Subtasks:
  • CI/CD servers

    ×

    How to do this task:
    Subtasks:
  • Test infrastructure

    ×

    How to do this task:
    Subtasks:
  • Build versions

    ×

    How to do this task:
    Subtasks:
  • Information systems (very important):  

    ×

    How to do this task:
    Subtasks:
  • User requests handling system

    ×

    How to do this task:
    Subtasks:
  • Bus tracking system

    ×

    How to do this task:
    Subtasks:
  • Knowledge base system / information portal

    ×

    How to do this task:
    Subtasks:
  • Monitoring system

    ×

    How to do this task:
    Subtasks:
  • User actions analytics system

    ×

    How to do this task:
    Subtasks:
  • It is crucial to identify contact persons for all issues regarding each system

    ×

    How to do this task:
    Subtasks:
  • Also all procedures and ceremonials: flow processing of user requests; flow approvals of new technical documentation

    ×

    How to do this task:
    Subtasks:
  • Processes and a list of decision makers (DM):

    ×

    How to do this task:
    Subtasks:
  • Procedures and a list of DMs connected with daily routines

    ×

    How to do this task:
    Subtasks:
  • Procedures and a list of DMs connected with closing a sprint / iteration / work stage

    ×

    How to do this task:
    Subtasks:
  • Procedures and a list of DMs connected with planning a new release / iteration

    ×

    How to do this task:
    Subtasks:
  • Procedures connected with handling Change Requests, and a list of DMs

    ×

    How to do this task:
    Subtasks:
  • Procedures and ceremonials connected with issuing a new release

    ×

    How to do this task:
    Subtasks:
  • Testing, quality assurance team: 

    ×

    How to do this task:
    Subtasks:
  • Necessary to get access to all test script databases

    ×

    How to do this task:
    Subtasks:
  • Necessary to get the description of release issue procedures

    ×

    How to do this task:
    Subtasks:
  • User accounts – I bring them out, to keep in mind: 

    ×

    How to do this task:
    Subtasks:
  • Testing / staging / production user accounts for testing the product

    ×

    How to do this task:
    Subtasks:
  • Accounts in the analytics / vendors / partners systems

    ×

    How to do this task:
    Subtasks:
  • Field of action: 

    ×

    How to do this task:
    Subtasks:
  • Work plan

    ×

    How to do this task:
    Subtasks:
  • Roadmap

    ×

    How to do this task:
    Subtasks:
  •  Objectives definition in technical terms

    ×

    How to do this task:
    Subtasks:
  • Objectives definition in terms of product

    ×

    How to do this task:
    Subtasks:
  • Third party services, vendors, partners: 

    ×

    How to do this task:
    Subtasks:
  • Access to all third party systems with admin rights – to be able to add your own users

    ×

    How to do this task:
    Subtasks:
  • Contacts of all vendors and partners, their DMs, interaction schedule, their team structure, responsibilities, and a brief description of the interaction domain and the team's objectives

    ×

    How to do this task:
    Subtasks:
  • The "Objectives" Section is very important: 

    ×

    How to do this task:
    Subtasks:
  • What is required from the development, testing, and support teams?

    ×

    How to do this task:
    Subtasks:
  • What are the objectives of the new team?

    ×

    How to do this task:
    Subtasks:

593 copy saved

593 copies saved