An institution that wants a water decision support system usually cannot just appoint someone. It has to write a terms of reference, publish it, and choose between the bids that come back. The quality of that document decides the quality of everything downstream, because a supplier can only price what is written.
The most common outcome of a weak ToR is not a bad system. It is a set of bids that cannot be compared with each other, because each bidder has resolved the ambiguities differently and priced their own interpretation.
Start with the decision, not the tool
A ToR should open by naming the decision the system exists to support, and it should do that before it names any technology. Specifying a platform, a database or a visualisation library first inverts the problem: it fixes the answer and leaves the question open.
Write the decision as a sentence with an actor and a frequency. Something closer to "the basin office decides each month how much water to release from storage" than to "a dashboard for reservoir monitoring". Everything else in the document can then be justified against that sentence, and requirements that cannot be justified against it are candidates for deletion.
Inventory the data before you ask anyone to price it
Undefined data is the single largest source of incomparable bids. If the ToR does not say what exists, every bidder prices a different risk, and the cheapest bid is usually the one that assumed the data was cleaner than it is.
State plainly, for each source:
- What it is and who owns it. Naming the owner matters as much as naming the dataset, because access is an organisational problem more often than a technical one.
- The period of record and its gaps. Gaps are not a detail. Reconstructing a broken record before calibration is real work, and a bidder who is not told about it will not price it.
- The format and how it is accessed. An API, a database, a monthly spreadsheet emailed by a colleague, and a PDF are four very different propositions.
- Whether it is already quality controlled, and by whom.
Where you genuinely do not know, say that too, and ask bidders to price a short data assessment as a separable first phase. An honest unknown is far cheaper than a hidden one.
Say what the system has to be right about
Acceptance criteria are what turn a deliverable into something that can be judged. Without them, acceptance becomes a matter of opinion at exactly the moment when everyone is tired and the budget is spent.
For anything with a model underneath, that means naming the calibration targets: which observations the model must reproduce, and what agreement is considered adequate. For the system around it, it means naming the conditions it must handle: how much data, how many concurrent users, how quickly a screen must return. These are not difficult to write and their absence is the reason so many of these projects end in an argument.
Separate what must be simulated from what must be shown
These are different pieces of work with different risk profiles, and a ToR that conflates them will get a price for one of them. Building an interface over an existing, trusted model is a software project. Building the model as well is a hydrology project with a software project attached, and the second is where the schedule risk lives.
If the intended system needs scenario or what-if behaviour, say so explicitly, because that requirement changes the architecture rather than adding a screen. A model that has to be re-run on demand with user-supplied inputs is a different system from one that publishes precomputed results, and our basin scale modelling work is usually where that distinction gets settled.
Name who operates it afterwards
A ToR should state who will own the system after handover and what they are expected to be able to do with it. This is the requirement most often left out and the one that most reliably determines whether the system is still in use in three years.
It also has concrete consequences for the bid. A system to be operated by a two-person technical team needs different documentation, different training and arguably different technology choices from one that will be maintained by a rotating cohort of research fellows. Ask for the handover artefacts by name: source code, deployment instructions, model files, data dictionaries, and a written description of what to do when something breaks.
Ask for the licensing position in writing
Who owns the code, who may modify it, and what happens if the supplier is unavailable in two years are questions with clean answers if asked up front and awkward ones if asked later. State the position you require rather than inviting each bidder to propose their own, otherwise the bids will differ on terms that are harder to compare than price.
A ToR outline you can adapt
A workable structure for this kind of procurement, in the order a bidder needs to read it:
- Background and the decision. The institution, the problem, and the sentence naming the decision, its owner and its frequency.
- Scope. What is in, and explicitly what is out.
- Data. The inventory described above, with owners, gaps, formats and access.
- Functional requirements. What the system must let someone do, written as tasks rather than features.
- Modelling requirements. What must be simulated, at what resolution, and against what it will be calibrated.
- Acceptance criteria. How you will decide the work is finished.
- Deliverables. The system, the models, the pipelines, the documentation, the source, named individually.
- Operation and handover. Who owns it, what training they receive, what support period applies.
- Licensing and intellectual property.
- Evaluation criteria and weightings. Say how you will score, so bidders write to it.
The four gaps that cost the most
If you change nothing else, close these: the decision is not named, the data is not inventoried, there are no acceptance criteria, and nobody is named as the operator after handover. Each of the four independently produces bids that cannot be compared, and together they produce a project that is difficult to end.
None of this requires technical expertise to write. It requires deciding, internally and before publication, what the system is for. We are happy to comment on a draft ToR whether or not we intend to bid, because a document that describes the work honestly is easier for everyone to price. That is the same conversation that starts any decision support system we build, and it is what our consulting and modelling services are organised around.