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.

First, I try to handle the following set data and access rights.

Team structure:

1. Members of the team
2. Hierarchy and responsibilities, reporting
3. The customer's / related teams' / vendor's contacts

Business requirements, trying to get access to:

1. Description of business requirements
2. User documentation
3. Test cases

Source code:

1. Repository URLs
2. Creating accounts with the required rights
3. Getting all configuration scripts and requirements for developers' workstations
4. If possible, creating automated scripts of environment deployment or creating system images – to save precious time for the developers.
5. Check_List_Knowledge_Transfer.jpg

Technical documentation:

1. System architecture
2. Sub-system architecture
3. Architecture in terms of technical primitives
4. Architecture in terms of business tasks, use cases
5. Team's technical debts
6. All technical findings and proposals regarding the existing system
7. 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.

Delivery and environment system:

1. CI/CD servers
2. Test infrastructure
3. Build versions

Information systems (very important):

1. User requests handling system
2. Bus tracking system
3. Knowledge base system / information portal
4. Monitoring system
5. User actions analytics system
6. It is crucial to identify contact persons for all issues regarding each system
7. Also all procedures and ceremonials: flow processing of user requests; flow approvals of new technical documentation

Processes and a list of decision makers (DM):

1. Procedures and a list of DMs connected with daily routines
2. Procedures and a list of DMs connected with closing a sprint / iteration / work stage
3. Procedures and a list of DMs connected with planning a new release / iteration
4. Procedures connected with handling Change Requests, and a list of DMs
5. Procedures and ceremonials connected with issuing a new release

Testing, quality assurance team:

1. Necessary to get access to all test script databases
2. Necessary to get the description of release issue procedures

User accounts – I bring them out, to keep in mind:

1. Testing / staging / production user accounts for testing the product
2. Accounts in the analytics / vendors / partners systems

Field of action:

1. Work plan
2. Roadmap
3. Objectives definition in technical terms
4. Objectives definition in terms of product

Third party services, vendors, partners:

1. Access to all third party systems with admin rights – to be able to add your own users
2. 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

The "Objectives" Section is very important:

1. What is required from the development, testing, and support teams?
2. What are the objectives of the new team?

Of course, the modern development frameworks can greatly help in project implementation, and in general all ceremonials and team roles are known, but the real world is not perfect, and therefore it's better to get through the team's activities from start to finish.

It should be noted that the best way to carry out a knowledge transfer would be to keep two teams in parallel, in which case the entire team would be able to gradually flow into the development process, talk with knowledge holders about the issues of system configuration, process systems (for example JIRA), bug life cycle, etc.

If the team works according to Scrum or Scrumban, I would recommend to conduct one or two sprints, observing all the ceremonials: planning, groomings, triage, retrospectives, demos.

Interested in improving your skills? Check out our Agile trainings.

Ivan Alyakskin

Software Consultant