You may have heard the term “succession planning” in regards to royalty, the peaceful transition of power in a democracy, or if you’re transitioning out of a role and are being asked to train your replacement. The goal in each case is the same: a continuity of knowledge, access, and responsibility between people filling the same role.
While this kind of planning is common in many hierarchical organizations, it is often overlooked within the context of managing research data. As the primary investigator, you may think of the research project as “yours,” and centre your data management plan around how you intend to collect, organize, process, utilize, publish, and archive your data. But access to and responsibility for that data also needs to be considered. For multi-person research teams and long-term projects, you may have other investigators and research assistants join your team for a while before moving on, so having a defined process for granting and revoking access to the data is important. Even for solo researchers, sometimes life may take us in unexpected directions on very short notice, and having the ability to hand off a project easily can be immensely helpful in weathering those surprises. Sometimes you may need to step away from a project for a few weeks or months or years, with the intention to resume the project later; in such a case, the person who is succeeding you as the responsible party is your future self.
Succession planning is relevant to all of the steps in the research data management lifecycle. For each step, you can document the expected and actual process, the responsibilities and access needs for the person or people who complete that process, and instructions about how to transfer that responsibility and access from one party to another. These considerations, like the rest of your data management plan, are part of the living process of conducting research, and should be kept up to date along with the rest of the plan.
When considering succession planning for your research project, it can be helpful to reflect on previous instances where you’ve inherited a project from someone else. Try to think of an example of a smooth handoff that was managed well, and one where things went poorly and you struggled to get your bearings. What were the differences between those two scenarios? Similarly, you can identify previous instances where you’ve had to hand off a project to someone else. What went well or poorly when you were the one handing over responsibility versus when you were receiving it?
Succession planning doesn’t need to be a huge part of your data management plan, but giving it some thought ahead of time and incorporating it into your project documentation can make a big difference when your team grows or shrinks or when your life context changes unexpectedly. I hope you’ll take this opportunity to add some notes to your plan. Your successor will thank you for those efforts, even if your successor is future you.