How to Structure a Research Project Record
A research project record should let someone outside the team understand what was done, with what approvals and data, years later. A practical structure that scales from one study to many.
A research project generates records in a dozen places: a protocol in one folder, approvals in someone's email, consent forms in a cabinet, data on a shared drive, meeting decisions in nobody's notes. The test of a good project record is simple: could someone who was not on the team reconstruct what was done, under which approvals, with which data, and why decisions were made? Here is a structure that passes that test.
One project, one record
Start with a single record for the project that everything else hangs from. It holds the fixed facts: title, identifier, principal investigator, funder and grant reference, start and end dates, status, and where the data lives. If the project has distinct studies, sites or work packages, give each its own sub-record under the project, so a question about one site does not require reading everything.
The sections every project record needs
- Protocol and versions. Every version, dated, with a one-line summary of what changed and why. Amendments are where audits look first.
- Approvals. Ethics, data access, institutional sign-offs: the approval document, its reference, the version of the protocol it covers and its expiry or renewal date.
- People and roles. Who is on the team, in what role, from when to when, and with what access to data. Role changes are part of the record.
- Participants or sources. Consent records and withdrawals, kept separately from research data and restricted. Our consent record-keeping guide covers the detail.
- Data. A register of datasets: what, where, format, version, who can access, and retention.
- Decisions log. Dated entries for meaningful decisions: an analysis change, an exclusion rule, a deviation from protocol, and who agreed it.
- Outputs. Papers, reports, presentations, with the data and code versions they used.
- Funder reporting. Reports submitted, due dates and correspondence.
The data management plan sits alongside this; see a data management plan template for a small lab. The plan says what you intend; the project record shows what happened.
Dates are the backbone
Approval expiries, reporting deadlines, consent re-contact dates and data retention end dates are what projects miss. Record each as a real date, not a sentence in a note, so it can appear on a calendar and be checked.
Separate identity from data
Keep anything that identifies participants apart from the analysis data, with tighter access. The project record should point to where identifiable information lives and who may open it, without copying it into general notes.
How this looks in Herarx
A project template gives every new study the same shape: typed fields for the fixed facts, tables for protocol versions, approvals and datasets, contact roles for the team and external partners, and tracked dates that appear on the calendar. Studies or sites can be sub-cases that roll up to the project. Files, tasks and comments stay on the record, and the timeline keeps the history. For projects holding sensitive participant material, a case can be switched to Advanced Security so it is encrypted and visible only to its members.
Close it properly
At the end, add a closing note: what was delivered, where the final data is deposited, what is retained, until when, and who owns it after the team disperses. That note is what the next person reads first.
