How to Develop Research SOPs That People Can Use

Start with a recurring problem. Perhaps datasets reach an analyst without a dictionary, internal reviews have no clear owner, or project teams use different versions of an approval form. Describe the consequence in practical terms: extra questions, uncertain decisions, duplicated work or missing records. An SOP is useful when a defined procedure can reduce that ambiguity.

Distinguish a procedure from a policy, work instruction and template. A policy sets the institution's position or expectations. An SOP explains the sequence and responsibilities for a process. A work instruction can give detailed guidance for one technical step. A template helps record required information. Keep these relationships clear instead of placing every detail in one document.

Some research decisions cannot be standardised into a fixed answer. An SOP can specify when a specialist review is needed, what information the reviewer receives and how the decision is recorded. It should not force every study into one method. The goal is consistent handling of decisions while preserving the judgement appropriate to the research.

Ask the people who initiate, perform, approve and receive the work to describe a recent example. Record the starting event, inputs, steps, decisions, outputs and handovers. Include informal workarounds; these may reveal requirements that the official process misses. A map of intended practice is useful later, but first establish what actually happens.

Identify where work waits and why. A delay may arise because the responsible person is unclear, information is incomplete, a system cannot accept the file, or an approval requires time. Each cause suggests a different intervention. Adding another sign-off to every step can make a process more complicated without improving the underlying decision.

Mark exceptions. What happens when a collaborator sends an unusual file, a required reviewer is unavailable, or the requested analysis changes after the dataset is transferred? The SOP need not anticipate every event, but it should provide an escalation route and a way to record departures. Users need to know when they can resolve an issue themselves and when they must seek a decision.

Prepare an inventory before drafting individual documents. Give each proposed SOP a process owner, intended users, reason for priority and related policies or forms. Group closely related activities where a shared procedure will remain readable. Split them when their responsibilities, technical requirements or approval routes differ materially.

Prioritise by the significance of the problem, frequency of the task and feasibility of improvement. A frequently repeated handover with missing information may be a better starting point than a rare, highly complex process requiring several specialist approvals. Do not confuse the ease of writing a document with the importance of implementing the process.

Check existing material before creating more. A current institutional procedure may already cover part of the activity. Link to it and explain the local handover rather than copying sections that will become outdated separately. Research-process standardisation support can begin with this inventory, helping an institution decide which documents need revision, consolidation or removal.

Use a consistent opening record: procedure title, identifier, version, owner, approver, effective date and review trigger. Then define purpose, scope, starting event, required inputs, responsibilities, steps, exceptions and records. This is a proposed document structure, not a universal mandatory format. Adjust it to institutional requirements and the complexity of the task.

Write in direct language. “The project coordinator checks that the data dictionary identifies units and missing-value codes” gives a person a task and a criterion. “Data quality should be ensured” does not. Where a step depends on judgement, say who decides and what evidence informs the decision. Link to a technical instruction when detailed methods belong elsewhere.

Keep the distinction between preparation and approval explicit. The person assembling a submission package may check that declarations are present, but the relevant authors or institutional authority must confirm their content. A procedure should not quietly transfer scholarly, ethical or financial responsibility to an administrator who lacks the authority or information to exercise it.

Consider a research group that repeatedly sends datasets to an analyst without enough context. The following is an illustrative workflow, not a procedure currently operated by Outlier Science. Its purpose is to make the transfer understandable and reviewable before analysis begins.

The starting event is a project lead requesting analysis of an identified data version. The lead prepares a study brief, the permitted dataset, a dictionary, collection materials and a note of known issues. The coordinator checks that the agreed package is present and that the transfer route has been authorised. The analyst reviews structure and raises questions; the project lead resolves factual uncertainties or records why they remain unresolved.

The procedure should state that an incomplete package can be returned for clarification and that the analyst does not invent missing definitions. It should also explain how a corrected dataset replaces the earlier version without erasing the record of what changed. The UK Data Service documentation guidance supports recording variable meaning and file relationships; the handover sequence above is an original practical example.

A form should capture information required for an actual decision. For every field, identify who supplies it, who uses it and what happens if it is missing. Remove fields collected only because an older form contained them. Keep explanatory text near the field that needs it, especially where users might confuse a date, identifier or status.

Separate mandatory information from information that is useful only in some cases. A laboratory method identifier may be essential for one handover and irrelevant to another. A form that marks everything required encourages invented entries or vague placeholders. A defined “not applicable” response, with a reason where needed, is better than forcing users to pretend that the question applies.

Make records easy to retrieve. Name the storage location, access owner and relationship between the completed form and the underlying project. Avoid maintaining competing copies by email without a clear current version. For wider documentation arrangements, research data management support can help align project records, metadata and access decisions.

Ask someone who did not write the SOP to use it on a realistic example. Observe where they pause, misunderstand a term or need information the procedure never requests. Include at least one exception case, such as an incomplete input or an unavailable approver. Record both the document changes and any operational changes needed.

The pilot should test the whole process, not only whether the text is readable. Confirm that the named roles exist, the storage location is accessible to authorised users, the approval route works and the outputs can be used by the receiving person. If a procedure assumes specialist capacity that has not been allocated, clearer wording will not solve that gap.

Use feedback to simplify where possible. A redundant approval can be removed only by the appropriate authority, but an unnecessary duplicate field may be an easy improvement. Document what changed and why. Then approve the version that will actually be used. Training on a draft that changes substantially immediately afterwards can create confusion about which instructions apply.

Include a brief exception record in the pilot. For example, a collaborator may provide a dataset whose variable names differ from the agreed dictionary. The receiving analyst records the mismatch, identifies the affected files and requests clarification from the project lead. The lead confirms whether the dictionary is outdated or the wrong file was transferred. The corrected package receives a new version identifier before analysis proceeds. This is an illustrative resolution, not a reason to reject every imperfect input automatically.

The record should preserve the question, decision, decision-maker and resulting version. It should also indicate whether the incident suggests a change to the procedure or was a one-off event. That distinction helps an owner improve recurring problems without rewriting the SOP after every unusual request.

Assign one accountable owner to each procedure, even where several departments contribute. Define who can propose changes, who reviews them and who approves a new version. Keep obsolete versions distinguishable from current ones while retaining records required by institutional policy. A user should be able to identify the applicable version without asking the original author.

Set review triggers as well as a routine review interval. A new system, changed policy, significant error or repeated exception may justify an earlier review. Minor language corrections and substantive procedural changes need different communication. Tell users what changed and whether training or a change in practice is necessary.

For research involving specialised standards, the owner should map the SOP to the applicable requirements with qualified input. A generic procedure inventory cannot establish compliance. The mapping should identify the actual requirement, the relevant step, the evidence kept and the person responsible for verifying the interpretation. Keep this reference record controlled alongside the procedure.

Review whether staff can find the procedure, whether required inputs arrive, whether exceptions are resolved through the intended route and whether the output supports the next task. These questions reveal more than counting the number of SOPs written. Sample records proportionately and explain how the results will be used to improve the process.

Avoid turning every deviation into a disciplinary issue. Some deviations expose a procedure that does not fit real work. Others show a training need or a consequential control failure. Investigate the circumstances before deciding what response is appropriate. A constructive review should preserve accountability while making it possible for staff to report difficulties early.

For a first project, select one process with a clear owner, repeated demand and a visible problem. Map it, draft the smallest workable procedure, pilot it and review the evidence. The research-office planning guide shows how procedures fit within a wider support function. A useful SOP earns its place by making a specific task more dependable and its decisions easier to trace.