The Terms of Reference Nobody Reads: How to Write a TOR That Actually Gets Your Evaluation Right

I've seen a lot of Terms of Reference for evaluations. And I'll be honest: most of them have the same problem. They're long, vague, copy-pasted from a previous project, and filed away the moment a consultant is hired. Nobody reads them again until there's a disagreement about what the evaluation was supposed to produce. That's a waste of a powerful tool. A well-written TOR is not a formality. It is the single document that defines what an evaluation is for, who does what, and what "good" looks like at the end. Get it right, and everything downstream is easier: the inception report, the data collection, the final report, the learning sessions. Get it wrong, and you spend the next three months managing misaligned expectations. Here's how I'd approach writing one that actually works. What a TOR Is Really For According to ALNAP's guide on writing evaluation TORs, the document "defines all aspects of how a consultant or a team will conduct an evaluation. It defines the objectives and the scope" of the entire process [1]. The World Bank frames it similarly: the TOR is essentially a contract of understanding between the commissioning organization and the evaluation team [2]. But here is what those definitions miss: a TOR is also a communication tool for your own team. It forces internal clarity before external commissioning. The act of writing a TOR well requires you to answer hard questions you might have been avoiding: What decisions will this evaluation inform? Who are the real intended users of the findings? What are we actually willing to change based on results? If you can't answer those questions before you hire a consultant, no amount of budget or evaluator expertise will save you. 💡 Tip: Before drafting a single line of your TOR, hold a one-hour internal alignment session. Ask: "If the evaluation finds that this program isn't working, what would we actually do?" The answer tells you a lot about whether the evaluation is genuinely for learning or for reporting compliance. The Sections That Matter Most (and What to Put in Them)

A TOR typically covers background, purpose, scope, evaluation questions, methodology, deliverables, timeline, team requirements, and budget guidance. Most organizations have a template. The problem isn't the structure; it's the quality of what goes inside it. Here are the three sections where TORs most commonly go wrong. 1. Evaluation Questions This is the heart of the document. Weak TORs list broad questions like "Was the project effective?" or "Were beneficiaries satisfied?" These aren't evaluable questions. They're conversation starters. Strong evaluation questions are specific, answerable, and tied to a decision. Compare: Weak question Stronger version Was the project effective? To what extent did the project increase school attendance among girls aged 10-14 in the target communes, relative to baseline? Were beneficiaries satisfied? What aspects of the service delivery model do beneficiaries identify as most and least useful, and why? Was the project implemented as planned? How did actual targeting processes compare to the intended targeting criteria, and what explains any deviations? The OECD-DAC criteria (relevance, coherence, effectiveness, efficiency, impact, sustainability) are a useful organizing frame. But treat them as a checklist to consider, not a list to copy wholesale. Not every criterion needs to be evaluated in every evaluation. Choose the ones that connect to real decisions. 2. Scope Scope is where consultants and clients most often end up in conflict. A TOR that says "the evaluation will cover all project activities in all intervention zones" without specifying which activities, which zones, and which time period is not actually specifying scope. It's deferring a decision. Be explicit about: Geographic coverage: which regions, districts, or communities are in scope, and which are not Time period: what phase of the project is being evaluated Population: which beneficiary groups or sub-groups are included What is out of scope: naming exclusions prevents scope creep and protects both sides ⚠️ Warning: Scope creep is one of the most common causes of delayed evaluations and cost overruns. If your TOR is vague on scope, expect your consultant to interpret it in the most expansive (and expensive) direction possible. That's not bad faith; it's rational self-protection. 3. Methodology Guidance Here's where I'd push back on a common instinct: many TORs are either too prescriptive (they dictate an exact method before anyone has assessed feasibility) or too hands-off ("the consultant will propose an appropriate methodology"). Neither extreme serves you well. The better approach is to state your methodological preferences and constraints, and invite the consultant to propose within those boundaries. For example: "The evaluation should use mixed methods. Primary data collection should include a household survey with a minimum sample of 400 respondents, at least 4 focus group discussions with female beneficiaries, and key informant interviews with local government partners. A comparison group or difference-in-differences design is preferred where feasible, but the evaluation team should assess and justify their approach in the inception report." That kind of guidance gives a skilled evaluator real parameters to work within, without tying their hands before they've even seen your context. Deliverables: Be Specific About What You Actually Need Many TORs list "a final evaluation report" as a deliverable. That's like ordering a meal and saying you want "food." Be specific: What format? (Word document, PowerPoint presentation for senior leadership, a two-page summary for field teams?) What language(s)? What length is acceptable? Will there be a presentation of findings to staff? To the donor? To beneficiaries? Are raw datasets or analysis files also expected? The ALNAP guidance is clear that the TOR must define deliverables in enough detail that both the evaluation team and the client know exactly what is expected [1]. If you want a learning workshop, say so. If you want a management response template filled in alongside the report, include it. Don't assume consultants will offer these things voluntarily. 📝 Note: Some organizations now require evaluators to submit a "learning brief" alongside the full report, a short 2-4 page document designed for program staff who won't read a 60-page report. If that matters to you, put it in the TOR. Team Composition and Selection Criteria Be honest about who you need. If the program is in a specific region with a specific language context, say that local language proficiency is required. If the topic is technically complex, specify the academic or professional background you expect. One thing many TORs get wrong: they list required qualifications but don't say how proposals will be evaluated. If you're asking consultants to compete, give them the criteria. Something like: Criterion Weight Relevant evaluation experience 30% Technical and methodological quality of proposal 30% Understanding of the local context 20% Budget reasonableness 20% This is not bureaucratic overhead. It forces your own team to agree on what matters before you start reviewing proposals, which is exactly the right time to have that conversation. The One Thing That Makes a TOR Worth Reading According to a practical guide on TOR quality, the best TORs share a simple trait: they're "specific to this group" and "short enough to be read" [3]. That second point is underrated. A 40-page TOR that covers every conceivable contingency will not be read carefully by anyone. A 10-12 page TOR that makes hard choices about what matters and communicates those choices clearly will actually be used. Write for the evaluator who is reading your TOR at 9pm before their inception meeting tomorrow. What do they absolutely need to understand? Lead with that. 💡 Tip: After you draft your TOR, ask one person who wasn't involved in writing it to read it and answer three questions: What is this evaluation supposed to find out? What will the consultant produce? What makes a good proposal? If they can't answer those from the document alone, revise before you publish. Putting It Together

If I were sitting down with your team to write a TOR from scratch, here's the sequence I'd suggest: Clarify the purpose and intended use of the evaluation before anything else Draft specific, decision-linked evaluation questions (aim for 4-6 maximum) Define scope explicitly, including what is out of scope Specify methodological constraints and preferences without over-prescribing List all deliverables in detail, including format, language, and audience Define team qualifications and selection criteria Set a realistic timeline, with buffer for inception report feedback and report revisions Review the full draft against the question: "Could a skilled consultant work from this document alone?" If you'd like, I can help you draft or review a TOR for an upcoming evaluation. That's exactly the kind of work I do at vera.ignex.io, whether you're starting from a blank page or working from an existing draft that needs sharpening. The TOR is not paperwork. It's the foundation. Get it right, and the evaluation has a real chance of generating something worth learning from. Follow Vera for more on MEL & project management: LinkedIn · Instagram · Facebook · X