How to write the terms of reference to hire the operator of a business support program

Key Takeaways

• Terms of reference are the document that defines what is being hired, with what scope, how it is paid and how the operator of a program is evaluated. Many of the problems that show up during execution were already written there.
• The most frequent and most expensive mistake is not saying whether the contract value is a lump sum or per company, or what happens to payment when a company drops out. Nobody notices at signing, and it surfaces when it is time to pay.
• "Minimum," "maximum" and "up to" produce different contracts. Using them as synonyms shifts onto the operator a risk the price doesn't cover.
• Hours, sessions and delivery mode are methodology decisions for the operator. In the Dominican Republic, a simplified training improved micro-entrepreneurs' practices and revenues, while the standard accounting version had no significant effect (Drexler, Fischer and Schoar, AEJ: Applied Economics, 2014). What mattered was the design, not the length.
• The IDB's own rules pay for time worked when the scope is hard to define, and against deliverables when the output is clear (IDB, GN-2350-15, 2019). If the entity defines the output well, it no longer needs the hours.

Whoever writes the terms of reference for a business support program almost never runs it, and whoever runs it almost never helped write them. That gap explains why so many well-intended programs end up in arguments about how much should be paid, who was supposed to do what, or whether a figure was a target or a cap.

This guide comes from the terms of reference our team has reviewed over the last few years to decide whether to bid on processes from chambers of commerce, multilaterals, cooperation agencies and public entities in Latin America. We don't name any entity. What matters are the patterns, because in many cases they repeat. It is one of the pieces of how to design a business support program, the main guide in this section.

What are the terms of reference for an operator?

Terms of reference are the document an entity uses to describe the service it wants to hire: the objective, the scope, the expected outputs, the timeline, the budget, the payment terms, the team profile and the criteria it will use to choose between proposals. In a business support program, the "operator" is the firm or organization that delivers the support to the companies.

The rules that frame those terms change depending on who is hiring:

No legal framework solves the problems in this guide on its own. All of them allow good terms of reference, and all of them allow bad ones.

Why do terms of reference decide how the program is run?

Because the operator will do what the document asks for and pays for, in that order. If the terms ask for in-person hours and attendance sheets, that is what the entity will get, even if the program needed something else. We make this point in step 7 of the main guide, and we see it confirmed every time we review a process.

There is an understandable incentive behind it. For the funder, auditing hours and attendance is easier than auditing results, so many terms of reference end up written for the auditor and not for the program.

The trend in public procurement points the other way. The University of Oxford's Government Outcomes Lab describes the difference this way: traditional contracts pay for inputs or activities, and outcomes-based contracts pay when predefined outcomes are achieved. Colombia has its own precedents. In Empleando Futuro, the first social impact bond in a middle-income country, launched in 2017 by Prosperidad Social, IDB Lab and Swiss economic cooperation (SECO), payments depended on how many people got formal jobs, with independent verification, and not on the training hours delivered.

Paying only for impact shifts a lot of risk onto the operator and requires good measurement, so it isn't the only way out. The middle ground, which any entity can use today, is to pay against verifiable deliverables and leave the methodology, hours included, to whoever runs the program. How to define the outcomes to be verified is covered in indicators for business support programs.

How to write the terms of reference step by step

1. Define the payment unit and what happens with dropouts

Before anything else, the document has to say whether the contract value is paid for the whole program or for each company served, and what happens to payment if a company drops out midway. It is the mistake we see most often.

In a program with a fixed number of companies and a total value, the terms didn't make that distinction. When some companies didn't complete the program, the entity wanted to deduct a proportional share of the payment using a calculation that wasn't in the contract. The operator had sized its team and costs for the whole program, which kept running the same way. The dispute took weeks, and during that time the team served the companies without knowing how much it would be paid. One line on the payment unit and dropouts would have prevented it.

2. Write each figure as a minimum, a maximum or a target

Every number of companies, deliverables or sessions has to say what it is. "Minimum" binds the operator, and the price must cover it. "Maximum" or "up to" limits what the entity can demand, and if the payment is fixed, the document must say what happens when the number falls short. If the figure is a target with pay-for-results, it should say so, with the proportional payment rule or the compliance threshold.

In one invitation, "up to 50 companies" with a fixed value could be read two ways: as a cap, so the operator charged the same for 30 as for 50, or as a target, so it was bound to reach 50 for the same price. The document didn't say which. The same text asked for "8 sessions" and "a minimum of 10 hours per company" without clarifying whether those were two requirements or the same one stated twice. In another case, a multilateral's terms asked for "at least 80" and "at least 40" ventures with no ceiling and a closed budget, and its own minimum hours, added up, didn't match the figure the document declared.

The writing rule that closes this step is simple: each figure appears only once or, if it is repeated, it is written the same way.

3. Avoid fixing inputs and, if you do, make them fit the budget and timeline

It is best not to require hours or a number of sessions, for the reasons in the next step. But some funders' internal rules still ask for them, and in that case the required hours and activities have to fit within the available money and time, counting the work that isn't in person. The IDB policies say it directly: the scope of the services described in the terms should be compatible with the available budget, and under fixed-budget selection the terms must be prepared with particular care to make sure the budget is sufficient.

In one case we reviewed, the invitation declared 192 in-person hours. With session preparation, per-company documents and reports, the real work came to about 422. The same document required the track record, insurance policies and structure of a firm, but the budget matched the work of an individual consultant, with no advance payment, two months to serve 24 companies, and execution falling in December.

The case shows what happens when inputs are fixed: the entity ends up paying for a number that doesn't match the work. If they can't be avoided, a useful test before publishing is to ask someone who has run a similar program to estimate the total work from the document. If their number and the entity's don't look alike, the problem is in the terms.

4. Pay against deliverables and leave the methodology to the operator

The terms should describe what the program has to achieve, which outputs are delivered and how they are verified, and let each bidder say how it will do it. How many hours, how many sessions, one-on-one or in groups, in person or online: all of that is methodology, and methodology is what the entity should evaluate in the proposals instead of fixing it in advance.

The IDB policies support this approach. They ask that terms of reference not be too detailed or inflexible, so that consultants can propose their own methodology and staff. And they distinguish two types of contract: the time-based contract, which pays fees by the hour, day or month and is used when the scope is difficult to define, and the lump-sum contract, where payments are linked to clearly specified outputs. The same document notes that time-based contracts are generally used for most training services. But when the entity defines the output it expects precisely, the reason to pay for hours disappears.

The evidence also suggests that more hours don't guarantee more effect. Drexler, Fischer and Schoar compared two trainings for micro-entrepreneurs in the Dominican Republic: a standard accounting course and a simplified one based on rules of thumb. The simplified one improved financial practices and revenues; the standard one had no significant effect. What made the difference was the design of the content.

Fixing the format takes away the entity's ability to compare approaches and the operator's room to adjust the program to the actual cohort. What is worth fixing precisely is the minimum team profiles, the deliverables, how they will be verified and the payment schedule tied to them.

5. Separate what depends on the entity from what depends on the operator

If part of the program is delivered by the entity or another contractor, the document has to say so, and no operator payment should depend on something the operator doesn't control. The IDB sets this as a general rule: the terms must clearly define the responsibilities of each party.

In a program for 24 companies, the operator delivered phases II and III, while the entry diagnosis and the closing were in the hands of the entity or another operator. The second payment depended on the entity disbursing, on time, some vouchers the operator had to support. If the disbursement was delayed, the operator couldn't close its phase on schedule, and its payment was tied to someone else's process. On top of that, the evaluation criterion for the work plan asked for consistency with all four phases of the program, two of which weren't the operator's.

6. State what the outcome is measured against and who builds the baseline

Asking for "an outcome indicator" is not enough. The terms have to say what starting point it will be measured against, with what instrument, and who builds it. If the entity builds the baseline, the operator needs to see it before bidding. If the operator builds it, it has to be in the scope and in the budget.

In what we reviewed, a complete lack of baseline was not a pattern. What was frequent was asking for the indicator without saying what it would be compared against, which leaves the question open until the final report.

7. Check that the annexes say the same as the main document

Before publishing, someone who didn't write the document should read all of it, annexes included, looking for contradictions. These are minor errors, but they appear in almost every process. One invitation set the timeline at "seven (6) months." In a public call, the annexes contradicted the main terms on the age limits for talent and on the number of bidders, and one of the annexes was an outdated version.

Checklist before publishing

These six questions are the ones we use in a design session with the entity before the process goes out. If any of them doesn't have a written answer in the document, it isn't ready yet.

Real case: a process in Central America with well-written terms

A process to train advisors at small business support centers in Central America showed what happens when the terms are well written. The minimum team profiles were clear and left no room for interpretation. Payments of 20, 40 and 40 percent were tied to three defined deliverables. And the wording left the operator to decide the how.

That room changed the design. With 75 advisors taking part, one-on-one mentoring was hardly viable, so we proposed it in groups of 8 to 10 advisors, a format that was more viable and also methodologically stronger. If the terms had fixed individual sessions, that option wouldn't have existed.

What made the process work was the combination: precision in what the entity needed to control (profiles, deliverables, payments) and freedom in what the operator knew how to do better.

Frequently asked questions about terms of reference for operators

Who should write the terms of reference for a business support program?

The hiring entity should write them, ideally with support from someone who has run a similar program. There is one restriction to keep in mind: in IDB-funded projects, consultants hired to prepare the terms of reference for a project should not be hired to carry it out. If the entity asks a potential operator for help, it should be to review the design, not to draft the document.

How are companies that drop out of the program handled?

With a rule written from the start. The usual options are paying for the program as a whole with a minimum threshold of companies that finish, paying per company with partial payment by the phase reached, or allowing replacements up to a certain date. Any of them works if it is in the document. None of them works if it is decided afterwards.

Why shouldn't terms of reference ask for hours?

Because hours are a methodology decision and say nothing about what changed in the companies. An operator can achieve the same result with less of the business owner's time, and the evidence shows that a simpler training can work better than a longer one. The IDB's own rules reserve time-based payment for when the scope is hard to define. If the entity defines the output, it can pay against deliverables, like the 20, 40 and 40 percent scheme in the Central America case, without losing traceability for the audit.

Should the budget be published in the terms of reference?

Generally yes, because it lets bidders fit the scope to what exists and avoids proposals that don't fit. Under the IDB's fixed-budget selection it is mandatory. What doesn't make sense is publishing a budget while requiring inputs that don't fit in it.

Which evaluation criteria should be used to choose the operator?

It is worth evaluating what the operator will control: experience with similar programs, the quality of the proposed methodology, the team, and how well the work plan fits the phases it is responsible for. A criterion that evaluates phases someone else delivers, or that rewards the number of hours offered, ends up choosing whoever promises more rather than whoever will achieve more.

The terms of reference are the program's first design

A program starts being run well or badly with the document used to hire its operator. When the terms state clearly what is being paid for, what each figure means and what each party does, the operator spends its time on the companies. When they don't, part of that time goes into clarifying what the document left unsaid.

If you are preparing the terms of reference for a program, we can review them with you in a design session using the checklist in this guide, before the process goes out.

Request a design session | How we work with institutions

Read also: The future of results-based business support | Indicators for business support programs