Knowledge transfer
Check whether the next person can use the handover.
A folder can be complete while the next colleague is still unable to do the work. Use this readiness checklist to test one handover package before accepting it. The output is a decision sheet that records the evidence, unresolved gaps and owner for each action.
Define the package you are accepting
Name one recurring task, project responsibility or decision that is moving to another colleague. Identify the active task card, approved instructions and relevant contacts. Write down the next work event that will require them. Define who can accept the handover and who will provide support afterward. Assess each material task separately so a well-documented routine cannot hide a gap in an important exception.
Agree what ready means before testing
Specify what the receiving colleague should be able to find, explain and attempt using an approved practice case. Choose a case that exercises a real decision and the escalation boundary. Decide which gaps would prevent acceptance and which could be managed with named support. These are local acceptance conditions for the task. Record them before seeing the result so they remain useful when the test exposes a difficulty.
Check the source and its authority
Open the instruction from the location the successor will use. Confirm its owner, version and scope. Check that the task card reflects the current instruction and identifies any local variation. A recently written note may still describe an old process. Where the account conflicts with the approved instruction, record the conflict and ask the responsible owner to resolve it before the disputed step is used.
Test access in the receiving role
Have the receiving colleague open the source and the required systems through their own approved access route. Check a dependency such as a shared mailbox, reference file or authorization contact as part of the test. A demonstration on the departing colleague’s device leaves this question unanswered. If access is pending, name the owner, expected resolution and the temporary arrangement that the accountable owner accepts.
Walk through a normal case and an exception
Ask the successor to explain the first step, select the appropriate route and identify the record that should remain afterward. Then change one condition in the practice case. Ask where the instructions stop applying and who can authorize the next action. Use a fictional or approved example suited to the task. The person responsible for the process decides which practice or supervision is appropriate.
Record observed gaps without turning them into a score
For each checklist row, record the evidence seen and whether the item is ready, requires an action or remains untested. A missing permission, unclear instruction and unfamiliar skill need different owners. Write what happened before deciding what explains it. Keep the failed attempt attached to the tested version, then repeat the affected check after a change. An overall percentage can conceal a critical unresolved dependency.
Worked example of an acceptance decision
In a fictional services company, a project coordinator is taking over the monthly subcontractor invoice review. The package includes an approved procedure and an example file. During the test, the coordinator can identify an unmatched invoice but cannot open the contract reference folder. The finance owner also finds that the card names a person who no longer approves exceptions. The decision is to resolve access and update the approval route before the first live review, with a current coordinator assigned to support that cycle.
Name the decision and the support arrangement
The accepting owner can proceed with the documented scope, proceed with explicit support for specified gaps, or defer the affected responsibility. Record why that decision fits the evidence. Include the support role, when it is available and the point at which work must pause for help. If several people own dependencies, obtain their commitments before recording the package as ready.
Review after the first real work cycle
A practice case tests the selected situation. The first real cycle may reveal a missing dependency or an exception the package did not include. Arrange a review with the receiving colleague and a current process owner. Compare the original acceptance conditions with what occurred. Update the card, contact route or support arrangement and record whether another check is needed for the next cycle.
Keep the evidence with the active version
NASA’s continuity guidance gives supervisors responsibility for planning transitions and creating opportunities for knowledge to move between people. This worksheet adds an original acceptance record for a specific handover. Keep that record beside the active package, with a date and owner. It should help the next reviewer see what was tested, which support was agreed and which questions remain open.
Frequently asked questions
Questions that come up
Who should accept a knowledge handover?
Name an accountable receiving or process owner. The departing colleague explains the work and the successor tests the package, while the accepting owner decides whether the evidence and support are sufficient for the agreed scope.
Does every item need a perfect result?
Set acceptance conditions for the particular task. Some gaps can be handled through explicit support. A critical approval, access or instruction gap may require the responsibility to remain with another owner until it is resolved.
How is this different from a shift handover checklist?
This checklist tests whether responsibility and knowledge are ready to move between roles or colleagues. Its deliverable is an acceptance record for a task package, including source, access, practice and support.
Talk to Lontra HR
Bring one real HR question.
See how a first campaign could work for your team.