A student data management plan records what project files will exist, who may access them, how versions will be kept and what will happen at submission and afterwards. It should describe a process you can actually follow. Confirm your department's and supervisor's requirements before creating, collecting or sharing data.
This task complements ethics and consent; it does not provide approval or replace your institution's rules. Do not assume every dataset must be made public.
Knowing which file supports each finding makes the written project easier to review. UniDraft helps organise the material and instructions you confirm into an editable project document. Start your project documentation with UniDraft, bringing only the evidence you are permitted to share. Your approved storage, backup, access and retention arrangements remain your responsibility.
Start with a file inventory
Fictional planning example: a questionnaire project might have a blank approved instrument, an original response export, a working copy, a codebook and a table used in the report. This is a planning scenario, not evidence that students were recruited or responses collected.
For each actual item, record:
| Item | Purpose and version | Approved location and access | Person responsible | End-of-project decision |
|---|---|---|---|---|
| Your actual file group | What does this version represent? | Where may it be held, and who may open it? | Named role agreed for this project | Keep, transfer, restrict or dispose under the applicable process |
Do not put personal records, passwords or secret keys into the public worksheet. The worksheet should describe the arrangement rather than expose the material.
Work through the fictional file list
For the questionnaire scenario above, a planning inventory might look like this. These are fictional filenames and proposed roles, not records of real responses or a recommendation to collect particular personal data.
| Example item | What it would mean | Decision to confirm before using it |
|---|---|---|
| questionnaire_blank_v01 | The instrument version intended for use | Has this exact version completed the required review? |
| responses_raw_v01 | The first response export, if collection is authorised and occurs | Who may access it, and where may the original be retained? |
| responses_working_v02 | A transformed copy used for checking or analysis | What changed from the original, and where is that change recorded? |
| codebook_v02 | The meaning of variables and values in the matching working version | Does it describe the version actually used in the report? |
A filename alone does not answer those questions. Add a short README or manifest that explains each file's role, version, format and relationship to the report. Keep private participant information out of that explanatory document unless the approved process specifically requires it there.
Keep original and transformed versions distinguishable
An original export and a cleaned analysis file do different jobs. Record which file is the source, what changed, and which output was used in the submitted report. An example naming pattern could be project_dataset_working_v02; adapt it to your own agreed process. The example supplies no real data and is not a mandated institutional standard.
A short change log can name the version, date, change and reason. Keep exclusions and recoding decisions explainable rather than silently replacing previous data. The coding and cleaning guide shows how to document individual corrections without guessing a replacement value.
Make the plan operational
Ask who will perform each backup or access review, how you will check that the correct files can be recovered, and what happens when someone leaves the project. Agree storage and backup arrangements with your institution. Use the retention and disposal arrangements confirmed for your project. Check the approved handling process before moving identifiable records to an external tool.
The UK Data Service's planning guidance treats a data management plan as something reviewed during the project and connects it to responsibilities and later sharing. This is general research guidance, not a Nigerian policy or funding requirement.
The Digital Curation Centre's 2011 planning guide discusses documentation, responsibilities and day-to-day data handling. Use these general planning themes with your current institutional instructions; this article does not transfer its historical UK funder requirements or legal references to a Nigerian student project.
Explain availability honestly
An availability statement describes whether and how the underlying material may be accessed. It is different from attaching every response to a publicly shared report. Check actual permissions, restrictions and approved access arrangements; do not write “available on request” unless an authorised person can fulfil that request under the agreed process. Confirm the wording with the responsible supervisor or institutional contact.
The UK Data Service's sharing-strategy guidance distinguishes responsible sharing from unrestricted access. For your project, ask the responsible institutional contact which route is permitted and what supporting description is needed. A public link is not a substitute for that decision.
Check the handover before submission
Use this original review sheet with the person responsible for the project:
- Can you identify the file version behind each reported table or figure?
- Does the codebook or explanatory note match that version?
- Are access arrangements and responsibilities still correct?
- Is the permitted backup or recovery process understood and checked?
- Does the submission package contain only the material authorised for that audience?
- Is the later retention, transfer or disposal decision recorded, with the responsible role?
If an answer is missing, write the unresolved decision down and take it to your supervisor. Do not fill the gap with a generic promise that the project cannot carry out.
Use the ethics and consent guide for participant-process questions and the appendices guide for selecting supporting material. A signed consent form, raw response file and blank questionnaire serve different purposes and may have different access arrangements.
UniDraft helps organise the written project from the material and instructions you confirm. It does not run your research-data storage, backups or access process. Prepare your project documentation.
