A protocol is the scientific and operational backbone of a study. It is also, in many cases, the first thing that makes an investigator decide whether to participate. A protocol that is unclear, over-engineered, or poorly matched to what a site can actually deliver will lose investigators before recruitment begins — and retain only those who didn't read it carefully enough.
Writing a protocol that investigators want to deliver requires thinking about it from two directions simultaneously: as a scientific document and as an operational one. This isn't a soft, subjective problem — a recent benchmarking analysis of protocol amendment practices found that a substantial share of amendments made after a study is already underway are avoidable, driven by design issues that could have been caught before the protocol was finalised, not by genuinely new scientific information. Every one of those amendments carries a real cost: re-consenting participants, re-training sites, and losing momentum at exactly the point a study needs it most.
The gap between protocol and practice
Most protocols are written from the sponsor's or study team's perspective: what data do we need, what procedures does the protocol require, what regulatory commitments does it document? These are necessary questions. But they are incomplete without the complementary question: what does this look like from the site's perspective?
Investigators and site staff are often managing multiple studies simultaneously alongside their other responsibilities. Each study is competing for a limited pool of time, goodwill, and attention. A protocol that imposes unnecessary burden — complex visit schedules, excessive data entry, unclear procedures, or requirements that conflict with how the site normally operates — will underperform throughout its life. The problem is not investigators failing to follow the protocol. It is a protocol that was not designed to be followed.
| Written from the sponsor's view alone | Written with the site's view built in |
|---|---|
| Every scientifically interesting variable gets collected | Only variables the analysis plan actually needs get collected |
| Visit schedule follows the ideal research calendar | Visit schedule follows what a real clinic day can accommodate |
| Eligibility criteria protect statistical homogeneity | Eligibility criteria are checked against what a site can verify |
| Amendments happen after sites report difficulty | Feasibility issues are caught before the protocol is finalised |
Clarity over comprehensiveness
The most common protocol writing mistake is optimising for comprehensiveness rather than clarity. Long protocols are not more rigorous than short ones. They are simply harder to read — and when a document is hard to read, it is read less carefully and followed less reliably.
Every procedural requirement in a protocol should be present because it is necessary, explained clearly enough that a site coordinator who is not a subject matter specialist can follow it, and positioned logically so that the sequence makes operational sense. Requirements that are included because they were in the last protocol, or because a template includes them by default, should be questioned.
Concise, well-structured protocols with clear visit flowcharts, explicit eligibility criteria, and unambiguous procedural guidance outperform dense, comprehensive documents even when they contain less information. Less text that is read carefully is more valuable than more text that is skimmed.
Eligibility criteria that match the reality of the population
Eligibility criteria are where the gap between protocol and practice is most frequently acute. Criteria that are theoretically justified but practically difficult to verify — requiring assessments not routinely performed in the recruiting setting, or documentation that exists only in paper records — create screening failures and administrative burden.
Before finalising eligibility criteria, it is worth mapping them against a realistic participant pathway. Which criteria can be verified from information a site already has? Which require additional assessment, and is that feasible in the recruiting setting? Which criteria are scientifically essential, and which are inherited from previous studies without specific justification?
Tightening eligibility criteria to protect scientific homogeneity should be balanced against the cost of recruiting from a narrower population. If a criterion will exclude a substantial proportion of otherwise eligible participants, the scientific justification should be explicit and compelling.
Procedures that match site capabilities
A nutritional study that requires procedures routinely available only in specialist research centres will, if the recruitment target requires community sites, either recruit slowly or compromise the procedure. The match between protocol requirements and site capabilities is not a delivery problem — it is a design problem.
Site feasibility assessment before protocol finalisation is often treated as a scheduling exercise: confirming that a site can recruit the required number of participants. It should also be a capability assessment: can the site perform the specific procedures the protocol requires, with the equipment and staff available, within the time constraints of a normal working day?
Procedures that are feasible for one type of site may not be feasible for another. A protocol designed with a specific site profile in mind — and documented clearly enough that sites can assess their own fit — will perform better in practice than one designed generically.
Involvement in the design process
The most straightforward way to write a protocol investigators want to deliver is to involve investigators in writing it. Prospective investigator input — on visit schedules, procedures, eligibility criteria, and data entry requirements — consistently produces protocols that are more feasible, more efficiently executed, and better received at the sites that deliver them.
This does not mean designing by committee. It means structured input at the right stages:
The investment in that input is returned many times over in smoother delivery — and directly addresses the amendment problem raised earlier. An amendment triggered by a feasibility issue a site could have flagged during a walkthrough is, by definition, an amendment that structured early input would have prevented. Given how much amendment activity in the wider literature turns out to be avoidable rather than scientifically necessary, that walkthrough step is one of the highest-leverage stages in the entire protocol development process.