A call for tenders launched without solid terms of reference is a consultant delivering an off-topic report and a wasted budget. The terms of reference document frames everything: scope, deliverables, timeline, responsibilities. Writing terms of reference for a project requires more than just a copy-paste of a template. The real work consists of formulating expectations clearly enough for an external provider to understand what is expected of them from the first reading.
Data and usage rights clause in the TDR: the costly oversight
We still see TDRs that describe the objectives and timeline at length but say nothing about the ownership of the data collected. In recent years, several donors and development agencies have imposed specific clauses in their templates regarding data localization, conditions for reuse (open data, licenses, anonymization), and the obligation to describe sources and collection methods in the deliverables.
See also : Packing for a Mediterranean Trip: Tips and Practical Advice
Specifically, if your project involves field surveys or the collection of sensitive data, specify in the TDR who holds the raw data after the mission. Also indicate under what license the deliverables will be distributed. A consultant leaving with their Excel files without any obligation to transfer is a direct loss for the commissioning organization.
When drafting an example of terms of reference for an evaluation or research project, this data section is no longer optional: it conditions the acceptability of the document with many public funders or multi-donors.
Read also : Tips and tricks to get sand for free
Risk management section in a TDR: structuring critical assumptions
A TDR that does not mention operational risks forces the provider to improvise in the face of unforeseen events. Recent methodological guides emphasize the inclusion of a dedicated section covering three distinct aspects.
- Identification of operational risks: delays in data collection, unavailability of data, security constraints in the field, refusal of stakeholder participation.
- Critical assumptions: what must happen for the mission to proceed as planned (access to sites, availability of the project team on the commissioning side, validation of tools on time).
- The monitoring and mitigation mechanism: who decides on a plan B, within what timeframe, and how to adjust the timeline or budget if a risk materializes.
A TDR without a risk section transfers all responsibility to the provider, who will charge for this uncertainty in their financial proposal. It is better to name the gray areas upfront than to discover them mid-course.
Writing objectives and deliverables in a TDR: the field method
The objectives section is where most TDRs derail. We find formulations like “contribute to the improvement of local governance,” without any measurable indicators. The provider does not know what is expected, and evaluating their performance becomes impossible.
Start from the final deliverable. If you expect an evaluation report, describe its minimum structure: indicative number of pages, inclusion or not of a scoring matrix, format of the annexes (raw data, interview transcripts). Then work your way up to the general objective.
For example, instead of writing “evaluate the impact of the program,” formulate: produce an evaluation report documenting the measurable effects of the program on direct beneficiaries, including a geographic area analysis and prioritized operational recommendations. The consultant knows exactly what they need to deliver.
Tasks and timeline: break down without stifling
List the main tasks without micromanaging the methodology. The TDR sets the “what” and the “when,” the provider proposes the “how” in their technical offer. Three to five major phases are sufficient in most projects: framing and document review, data collection, analysis, writing, presentation.
Associate each phase with a verifiable intermediate deliverable (framing note, provisional report, presentation of findings). This breakdown allows for real monitoring, not a forty-line Gantt chart that no one will read.
Versioning and validating a TDR document with collaborative tools
A TDR often goes through five, sometimes ten versions before validation. Without a change tracking tool, you end up with files named “TDR_final_v3_corrected_REAL_FINAL.docx” and no one knows which version is authoritative.
Several organizations now recommend using collaborative suites (Google Workspace, SharePoint) to co-write, comment, and version TDRs. The direct advantage: every modification is tracked, comments remain attached to the text, and validation occurs in a single flow instead of a cascade of emails.
- Assign a version manager who consolidates feedback and resolves disagreements before each new iteration.
- Use a clear naming system from the start (TDR_ProjectName_v1.0, v1.1 for minor corrections, v2.0 after structural revision).
- Lock the document once validated by the signing authority, and archive previous versions without deleting them.
The validated TDR becomes the reference contractual document. Any subsequent modifications must go through a formal amendment, not an informal email.
When AI enters the writing process
Recently, some writers have been using AI assistants to produce a first draft of the TDR. The tool can speed up the structuring of the plan and the formulation of repetitive sections (administrative clauses, format of deliverables). Feedback on this point varies: the time savings are real for formatting, but human proofreading remains essential to verify coherence between objectives, budget, and timeline.
A well-written TDR can be recognized by a simple test: a provider who knows neither your organization nor your sector should be able to write a relevant technical offer by reading only this document. If this is not the case, information is missing, or the objectives remain too vague. Review your TDR with this filter before disseminating it, and you will avoid most contractual misunderstandings.