# How to Create a Data Documentation Plan for Collaborative Research By the end of this article you will be able to draft a complete data documentation plan for a multi-person research project, fill in a reusable template with a worked example, set up a shared folder and data dictionary with real commands, and choose research collaboration tools that keep documentation current across institutions. You will need a plain-text editor, a shared drive or repository your whole team can access, and about half a day of meeting time with your collaborators. ## Why Collaborative Projects Break Without a Documentation Plan ![Comparison of a documentation plan and a data management plan across when written, use, who it serves and what it covers.](/article-images/illustrations/data-documentation-plan-template-research-collaboration-plan-vs-dmp.webp) Most scientific collaboration does not fail because of the science. It fails because six months into a project, nobody remembers what the column named `val_2b` in the shared spreadsheet means, which of three similar files is the final version, or whether the missing values were coded as blanks or as 999. The evidence for this problem is broad. A survey of 585 NIH-funded Alzheimer's disease and related dementias investigators found that 193 of them (33 percent) worked with international collaborators, and that data-sharing practices and experiences differed between groups, with men (60.6 percent versus 50.3 percent) and White researchers (73.6 percent versus 61.1 percent) more represented among those working internationally. Cross-border scientific collaboration multiplies the number of institutions, file formats, languages, and expectations involved, which makes undocumented data nearly impossible to reuse. In toxicology, reviewers of metabolomics research identified metabolite misannotation, insufficient quality assurance and quality control, and weak documentation as core threats to reproducibility, and called for standardized protocols for sample preparation, analytical workflows, and data processing [1]. In Parkinson's disease clinical research, authors of a 2025 review found there is no international standard for how symptomatic medications are documented across trials, which makes it hard to compare medication use between studies [2]. A data documentation plan is the written agreement that prevents these failures. It specifies what data the project will produce, how each variable is defined, where files live, who can access them, how versions are tracked, and how a newcomer could understand the dataset without asking anyone. A documentation plan is not the same as a [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) plan (DMP). A DMP is usually written once, before funding, to satisfy a funder. A data documentation plan is a living operational document the team uses weekly. It tells a collaborator joining in month nine exactly where the data is and what every field means. ## Free Data Documentation Plan Template (Research Collaboration Format) The template below is the core format this article builds out. You can copy it into a shared document today at no cost. It contains eight sections, and each section answers one question a collaborator will eventually ask. | Section | Question it answers | Example entry | |--|--|--| | 1. Project overview | What is this study about? | "Longitudinal gut microbiome survey of 200 volunteers, 12 months" | | 2. Dataset inventory | What files exist and where? | `data/raw/16S_fastq/` contains 2,400 sequencing files | | 3. Data dictionary | What does each variable mean? | `age` = participant age at enrollment, integer, years, missing = 999 | | 4. File naming and versioning | Which file is current? | `YYYYMMDD_analysis_v##.R` with git tags | | 5. Roles and access | Who can read or edit what? | Analysts read raw data, only PI writes to `data/final/` | | 6. Quality control | How is data checked? | Duplicate check, range checks, monthly checksum audit | | 7. Privacy and ethics | How is sensitive data protected? | De-identification before upload, consent scope documented | | 8. Sharing and retention | Where does data go at the end? | Deposit in a public repository on publication | Fill each section in one short meeting rather than trying to write it alone. Teams that document collectively adopt the plan more consistently than teams where one person writes rules nobody else reads. A concrete data documentation plan template research collaboration example looks like this for section 3: ```csv variable,description,type,units,allowed_values,missing_code,collected_by participant_id,Unique anonymized subject code,string,none,LAB-#####,none,site coordinator age,Participant age at enrollment,integer,years,18-100,999,site coordinator bmi,Body mass index at visit 1,decimal,kg/m2,15.0-60.0,NA,site nurse sequence_batch,Illumina run identifier,string,none,RUN_###,none,sequencing core ``` The columns matter. `type` prevents someone from reading ages as text. `allowed_values` lets an automated range check catch entry errors. `missing_code` prevents the classic bug where blanks and sentinel values get mixed. `collected_by` tells a downstream analyst who to contact when a value looks wrong. ## Step-by-Step Walkthrough ### Step 1: Inventory every dataset the project will produce Open a spreadsheet with one row per dataset. Record the dataset name, responsible person, format, approximate size, and sensitivity level (public, internal, or restricted). Keep the list honest rather than exhaustive. If your project has sequencing reads, a clinical spreadsheet, and analysis outputs, that is three rows, not thirty. Expected output, a completed inventory with three rows: ```text dataset owner format size sensitivity 16S sequencing Kim FASTQ ~400 GB restricted clinical table Osei CSV ~5 MB restricted analysis outputs Both CSV, PNG ~50 MB internal ``` ### Step 2: Create a shared project skeleton Run these commands in a terminal on the machine that hosts your shared repository, or send them to whoever does: ```bash mkdir -p microbiome-study/{docs,data/raw,data/processed,data/final,code,results} ``` Verify the structure: ```bash find microbiome-study -type d ``` Expected output: ```text microbiome-study microbiome-study/code microbiome-study/data microbiome-study/data/final microbiome-study/data/processed microbiome-study/data/raw microbiome-study/docs microbiome-study/results ``` The `docs/` folder is where your documentation plan lives. Everything in it is text, so it can be version controlled alongside the data. ### Step 3: Write the project README with structured metadata Create `docs/README.md` and start it with YAML frontmatter, a simple key-value format that both humans and scripts can read: ```yaml --- project: Longitudinal gut microbiome survey version: 1.0 last_updated: 2026-11-11 maintainer: a.osei@university.edu license: CC-BY-4.0 (code and processed data) sensitivity: restricted until publication related_documents: - data_dictionary.csv - access_policy.md - qc_protocol.md --- ``` Below the frontmatter, write three short paragraphs: what the study measures, how to request access, and what to do first if you are a new collaborator. A reader should reach working data in under ten minutes using only this file. ### Step 4: Build the data dictionary as a CSV, not a document Store the dictionary in `docs/data_dictionary.csv` using the format shown in the template example above. A CSV beats a word processor table because analysis scripts can read it, it merges cleanly in version control, and it can be validated programmatically. Check your dictionary for completeness with a one-line script: ```bash awk -F, 'NR>1 && ($3=="" || $6=="") {print "Incomplete row:", NR}' docs/data_dictionary.csv ``` Expected output on a complete dictionary is nothing. If a row prints, that variable is missing a type or a missing-value code, and you fix it before data collection starts. ### Step 5: Define version control rules and tag releases Use git for code and documentation. Initialize the documentation repository and record the first version: ```bash cd microbiome-study git init git add docs/ git commit -m "Add data documentation plan v1.0" git tag v1.0-docs ``` Expected output after the commit: ```text [main (root-commit) 3f2a91c] Add data documentation plan v1.0 3 files changed, 87 insertions(+) ``` The tag gives every collaborator a citable reference point. When someone says "the analysis from March," you can check out the tagged state instead of guessing. For data files that are too large for git, use checksums. A checksum is a short fixed-length string computed from a file, which changes if even one byte of the file changes: ```bash md5sum data/raw/*.csv > docs/checksums_clinical.txt ``` Later, rerun the command with the `-c` flag to verify nothing was corrupted or silently altered: ```bash md5sum -c docs/checksums_clinical.txt ``` Expected output: ```text data/raw/clinical_2026.csv: OK data/raw/medication_log_2026.csv: OK ``` ### Step 6: Write the access policy before the first file is shared Document three tiers in `docs/access_policy.md`: public, internal (project members), and restricted (named individuals). Assign every dataset from your inventory to a tier. State explicitly who approves access changes and how requests are logged. This single page prevents the most common collaborative accident, which is a sensitive file pasted into a general chat channel. ### Step 7: Schedule reviews and assign ownership Add a final section naming one person as documentation maintainer and setting a review cadence. For active projects, a 30-minute review at the end of each analysis cycle is enough. The maintainer updates the version number in the README frontmatter and tags a new release, so the documentation history matches the data history. ## Choosing Research Collaboration Tools Your documentation plan should name the tools, not just the practices, because vague tool agreements produce shadow spreadsheets. The table below summarizes common options by job. | Job | Tool category | What it does well | Watch out for | |--|--|--|--| | Versioning code and docs | Git hosting platforms | Full history, tags, review of changes | Large raw data files do not belong here | | Shared data storage | Institutional cloud drives | Access control, sync across sites | Version sprawl without naming rules | | Metadata and catalogs | Study data portals | Searchable variable-level metadata | Setup effort must match project size | | Long-term deposit | disciplinary repositories | [Persistent identifiers](/knowledge/bioinformatics/persistent-identifiers-in-bioinformatics-selection-criteria-and-implementation-workflow), public release | Deposit formats must be planned early | | Sensitive data analysis | controlled or federated environments | Data stays put, analysis moves to it | Requires more setup and agreed protocols | Two principles from recent literature should guide tool choices. First, documentation and infrastructure should be designed together. The IDERHA project, one of the first pan-European health data spaces, aligned its platform architecture, standardization approaches, and documentation as a single framework rather than treating documentation as an afterthought [3]. Second, tool decisions interact with privacy law. A narrative review of legal frameworks for health data sharing emphasizes that GDPR, HIPAA, the EU AI Act, and the European Health Data Space impose different requirements, and that de-identification and privacy-preserving techniques must be selected against the specific regulations that apply to your data [4]. If your collaboration spans jurisdictions, your documentation plan needs a line stating which regulation governs each dataset. ## Access Control, Governance, and Sensitive Data ![Decision path for sensitive datasets: human data, cross-border rules and file movement, ending in institutional governance review.](/article-images/illustrations/data-documentation-plan-template-research-collaboration-sensitive-data-path.webp) Multi-institution collaborations need rules for who sees what, and those rules should be written down, not assumed. A governance study of data trusts and repositories refined a set of essential requirements from twelve to fifteen minimum specifications across five categories: legal, governance, management, data users, and stakeholder and public engagement [5]. You do not need all fifteen for a small lab collaboration, but the categories are a useful checklist. At minimum, your documentation plan should state the legal basis for holding each dataset, the named person accountable for governance, how user access is granted and revoked, and how external stakeholders such as patient representatives are engaged. Access control itself is a technical topic with a growing literature. Work on cross-organizational data sharing shows that when each institution has its own local access policies, those policies can conflict, and combining them into a single enforceable global policy is a recognized engineering problem [6]. A practical takeaway for ordinary research teams is simpler: document per-dataset permissions in one place and reconcile them whenever a new institution joins. For projects handling telemetry, genomic, or other sensitive data at scale, policy-driven frameworks with stakeholder-specific, time-based, and location-aware access restrictions have been demonstrated in operational settings [7], and blockchain-based approaches can provide tamper-proof provenance tracking of data lifecycles across institutions [8]. Decentralized virtual research environments offer another model, where collaborators share data through peer-to-peer infrastructure with trust controls rather than a central server. Federated learning goes further by training models across institutions without moving raw patient data at all, and a systematic review of 124 peer-reviewed articles found server-client federated architectures are now the dominant deployment strategy, with differential privacy, secure aggregation, and cryptographic computation as the central privacy-preserving mechanisms [9]. Most lab teams will not need any of those architectures. What they should borrow is the underlying habit: write down who can access each dataset, under what conditions, and how compliance is checked. For human data, consent scope belongs in the documentation plan. A qualitative study in Uganda engaged 86 participants, including researchers, ethics committee members, and community advisory board members, and surfaced concerns about informed consent, third-party data access, inequities between high-income and low- and middle-income country researchers, and missing benefit-sharing frameworks [10]. For projects involving Indigenous knowledge or community-derived data, the CARE principles, which stand for collective benefit, authority to control, responsibility, and ethics, provide a governance framework that goes beyond open data by default [11]. And where biological samples or sequence data cross borders, the Nagoya Protocol may require fair benefit-sharing arrangements, which formal agreements can turn into long-term collaborations rather than one-way extraction [12]. ## Standardization, Metadata Quality, and Reuse The whole point of a documentation plan is that someone outside your team can reuse the data. Three practices raise reuse value substantially. First, use community standards where they exist. Fields with mature standards, such as clinical research minimum data sets, show the payoff. In UK care homes, the absence of a consistent approach to collecting residents' information limits research and care planning, while countries with standardized minimum data sets use that data for population understanding, resource allocation, and service monitoring [13]. Even in fields without a standard, the cost of skipping one is measurable. The Parkinson's disease medication documentation review cited above exists precisely because inconsistent documentation across international trials undermines comparison [2]. If your field lacks a standard, your documentation plan can still define an internal one and state it explicitly. Second, capture metadata at the level of the measurement, not the project. A research database for experimental electrocatalysis illustrates the target: its datasets include detailed information on reaction conditions, material properties, and performance metrics, structured in both web-based and machine-readable formats across 241 experimental entries, specifically to improve reproducibility and support machine learning applications [14]. For a biology lab, the equivalent means recording instrument settings, reagent lots, calibration dates, and processing software versions in the dictionary or a companion methods file, not just in someone's [lab notebook](/knowledge/molecular-biology/lab-notebook). Third, build quality control into documentation. The metabolomics review recommends rigorous quality assurance and quality control practices to minimize batch effects, and cross-validation across measurement platforms to strengthen conclusions [1]. In your plan, this becomes a QC section listing automated checks (range checks, duplicate detection, checksum audits) and the frequency at which each runs. Even outside academia, the same pattern holds. Vodafone's COVID-19 mobility data collaboration with governments and supranational entities succeeded on the technical side but identified regulatory challenges as the main risk to realizing the full value of shared data [15], a reminder that governance documentation deserves as much care as technical documentation. ## Common Mistakes and Limitations - Writing the plan after data collection starts. A data dictionary drafted in month six documents guesses, not decisions. Draft it during protocol design, when variable definitions are still negotiable. - Keeping the dictionary in a word processor. Proprietary document formats resist scripts, lose change history, and create merge conflicts. Use CSV or YAML in version control. - One undocumented column per dataset is enough to break reuse. The cost of an undefined variable compounds silently, because every downstream analyst either asks around or guesses. - Naming files by intuition. `final_v2_REAL.csv` is a documentation failure. Encode dates and versions in filenames as shown in Step 5 and enforce the pattern in the plan. - Confusing access control with ethics approval. Granting a collaborator read access does not settle consent scope, secondary use questions, or authorship expectations. The plan needs sections for both. - Treating privacy as a checkbox. De-identification choices, applicable regulations, and cross-border transfer rules vary by dataset and jurisdiction, as the legal review of GDPR, HIPAA, and related frameworks makes clear [4]. Route sensitive datasets through your institution's data governance process rather than deciding solo. - Assuming the plan maintains itself. Assign a named maintainer and a review cadence, or the documentation drifts within one personnel change. - One honest limitation. A documentation plan improves collaboration but does not replace project-specific legal review, ethics board approval, or your institution's data security requirements. Individual datasets, especially human subject data, need case-by-case assessment by the responsible offices at your institution. ## Frequently Asked Questions ### What is a data documentation plan and how does it differ from a data management plan? A data documentation plan is a living operational document defining variables, file locations, versioning, access rules, and quality checks for an active project. A data management plan is typically a one-time funder-required document written before a project starts. You need both, but only one gets used weekly. ### Where can I find a free data documentation plan template for research collaboration? The eight-section template in this article (project overview, dataset inventory, data dictionary, naming and versioning, roles and access, quality control, privacy and ethics, sharing and retention) is free to copy and adapt. Many universities and repositories also publish their own templates, so check your institution's library or data services office first. ### What does a good data documentation plan example look like in practice? A good example includes a concrete data dictionary row such as `age, Participant age at enrollment, integer, years, 18-100, 999, site coordinator`, a README with machine-readable metadata at the top, and named file versioning rules. Abstract promises like "data will be documented" are not examples. Field-level entries are. ### Which research collaboration tools should a small lab start with? Start with git hosting for code and documentation, an institutional cloud drive for shared data files, and a disciplinary repository for final deposits. This combination covers versioning, storage, and reuse without new software licenses, and every tool in it can be referenced from your documentation plan. ### How detailed should a data dictionary be? Detailed enough that a stranger could correctly parse and analyze the dataset without contacting you. At minimum, record each variable's description, type, units, allowed values, missing-value code, and who collected it. Anything less will generate questions within a few months. ### How do I handle sensitive human data in a documentation plan? Assign each dataset a sensitivity tier, document consent scope, describe de-identification steps, name the applicable regulation, and specify an access approval workflow before any file moves between institutions. For cross-border work, state which jurisdiction's rules govern each dataset. ### Who owns and maintains the documentation in a multi-institution project? Name one maintainer in the plan itself, usually the data lead at the lead institution, and record their contact in the README. Ownership of the data and stewardship of the documentation are separate roles, and both should be assigned by name rather than by committee. ### How often should the data documentation plan be updated? Review it at the end of every analysis cycle or at least quarterly during active data collection, update the version number and tag in version control each time, and freeze a final version when the dataset is deposited in a repository so the published documentation matches the published data permanently. ## Sources 1. [Addressing Pitfalls of Metabolomics for Toxicology: A Call for Standardization, Reproducibility and Data Sharing.](https://pubmed.ncbi.nlm.nih.gov/40619682/) 2. [Addressing the need for standardization of symptomatic medication documentation in Parkinson's disease clinical research: A call to action.](https://pubmed.ncbi.nlm.nih.gov/39973486/) 3. [Getting ready for the European Health Data Space (EHDS): IDERHA's plan to align with the latest EHDS requirements for the secondary use of health data.](https://pubmed.ncbi.nlm.nih.gov/39185338/) 4. [Data sharing for responsible artificial intelligence in dentistry: a narrative review of legal frameworks and privacy-preserving techniques.](https://pubmed.ncbi.nlm.nih.gov/40998104/) 5. [Essential requirements for the governance and management of data trusts, data repositories, and other data collaborations](https://pubmed.ncbi.nlm.nih.gov/38419825/) 6. [Automated Policy Combination for Secure Data Sharing in Cross-Organizational Collaborations](https://doi.org/10.1109/ACCESS.2016.2585185) 7. [Network data sharing: a governance framework for ensuring data sovereignty and privacy compliance](https://doi.org/10.1364/JOCN.559523) 8. [Blockchain Technology for Big-data Sharing in Material Genome Engineering](https://pubmed.ncbi.nlm.nih.gov/41253894/) 9. [FEDERATED LEARNING FOR PRIVACY-PRESERVING HEALTHCARE DATA SHARING: ENABLING GLOBAL AI COLLABORATION](https://doi.org/10.63125/jga18304) 10. [“It just feels morally not right to Sell the data”: Ethical and social perspectives on human genomic data sharing in Uganda-A phenomenological qualitative study](https://pubmed.ncbi.nlm.nih.gov/40959607/) 11. [The case for data sharing in traditional, complementary, and integrative medicine research](https://pubmed.ncbi.nlm.nih.gov/39834890/) 12. [Including Digital Sequence Data in the Nagoya Protocol Can Promote Data Sharing.](https://pubmed.ncbi.nlm.nih.gov/32654776/) 13. [Uptake and use of a minimum data set (MDS) for older people living and dying in care homes in England: a realist review protocol.](https://pubmed.ncbi.nlm.nih.gov/33191266/) 14. [A research database for experimental electrocatalysis: Advancing data sharing and reusability.](https://pubmed.ncbi.nlm.nih.gov/41025581/) 15. [Data sharing and collaborations with Telco data during the COVID-19 pandemic: A Vodafone case study](https://pubmed.ncbi.nlm.nih.gov/34901859/)