Start with the state of the project
Imagine a fictional research assistant leaving after data cleaning but before analysis. A folder of files does not tell the next person which checks were completed, which records remain unresolved, or whether the dataset is approved for use.
A short status note can separate “done,” “in progress,” and “not started.” Naming an unresolved problem is more useful than leaving it hidden inside a filename.
A handover outline
- Purpose: the question and current project stage.
- Materials: file locations and approved access routes.
- Decisions: consequential choices and their reasons.
- Open work: pending checks, deadlines, and dependencies.
- Ownership: the person responsible for each next step.
ORI-hosted data-management guidance emphasizes records that support retrospective inspection. A handover makes that principle practical for a change in personnel.
Credit and access are separate
Leaving a project does not by itself settle authorship or permission to retain data. Those questions depend on contributions, applicable policies, agreements, and publication standards. NISO's CRediT taxonomy can help document work performed, but it does not independently grant data ownership or authorship.
Any continuing role can be stated explicitly rather than assumed: answering a limited methods question is different from remaining responsible for ongoing analysis.
Test one route through the materials
Ask whether the receiving person can find the current output, identify its inputs, and understand the next unresolved decision. If not, repair that route first. A complete archive that nobody can interpret may be less useful than a concise guide to the important materials.
The handover does not need to make the project look flawless. Its value lies in letting the next person continue from the real state of the work, including the uncertainty and unfinished decisions.
