Key takeaways
- The terms of reference is the whole contest: it fixes scope, acceptance criteria, ownership and support, and every later stage is constrained by it.
- Write acceptance criteria naming a real office, real records and a real test — a feature list is nearly impossible to fail and therefore proves nothing.
- Put migration of the existing records in scope explicitly, with a reconciliation report, or the cheapest compliant bid will exclude it.
- Name source-code ownership or escrow, data export format and environment access in the TOR rather than settling them after award.
- Budget for the year after go-live; a procurement funding only the build has funded the least durable part of the programme.
Executive summary
A government software procurement in the Philippines runs under RA 9184, the Government Procurement Reform Act. The opportunity is posted on PhilGEPS, and the agency’s Bids and Awards Committee evaluates submissions against the terms of reference. That TOR is the whole contest: it fixes the scope, the acceptance criteria, the ownership of what is produced and the support obligations afterwards.
The common failure is not corruption or incompetence. It is a TOR written as a feature list, evaluated on price, and awarded to a bidder who priced exactly the feature list and nothing that makes the system survive contact with an office.
The problem
A feature list is easy to write and easy to bid against, which is why so many terms of reference are one. It is also nearly impossible to fail. A bidder can deliver every listed feature and still hand over a system nobody uses: no migration of the records the office already holds, no training, no way to export the data, and no maintainable path once the person who built it moves on.
The second problem is that the cheapest compliant bid wins. Where the TOR does not require data migration, the bid excluding it is cheaper and equally compliant. Where the TOR does not name who owns the source code, that gets settled after award, from a much weaker position.
The third is timing. Procurement calendars and budget cycles rarely align with how long the non-software work takes — the ordinance, the process redesign, the staffing of the counters. A system delivered on schedule into an office that is not ready is recorded as a delivered project and experienced as a failed one.
Technical discussion
Write acceptance criteria, not features
A feature says “online application form”. An acceptance criterion says “an applicant can submit a renewal, pay, and see the status change using only a phone, and the assessment matches the manual computation for twenty sample businesses supplied by the treasurer’s office”. The second is testable, and it cannot be satisfied by a demonstration.
Put the existing data in scope explicitly
Every office already holds records, and they are never as clean as the reports imply. Require migration of a named record set, delivered with a reconciliation report showing what moved, what did not, and why. Without that clause the incumbent data quietly becomes the next administration’s problem.
Name the ownership and exit terms
Source code ownership or escrow, data export in a documented format, and the environment access needed to run the system are three separate things, and all three belong in the TOR. An agency that cannot export its own records in a usable form has bought a subscription to its own data.
Budget for the year after go-live
Support, hosting and change requests cover the period in which a system either becomes part of how the office works or quietly falls out of use. A procurement that funds only the build has funded the least durable part of the programme.
Stage the acceptance
Acceptance in a single event at the end concentrates all the risk at the point of least time and least leverage. Stage it: a design acceptance, a functional acceptance on a pilot office, then full acceptance after a defined period of live running — each with a payment attached.
Recommendations
Run the process redesign before the procurement, not after award. RA 11032 requires streamlining as well as automation. Automating a process that has not been simplified encodes the queue into software and makes it harder to change afterwards.
Ask bidders for a migration and training plan inside the technical proposal. It is the cheapest available way to distinguish a bidder who has delivered into a live office from one who has not.
Name a technical evaluator who will actually use the system. A committee evaluating documents alone cannot separate a maintainable system from a demonstration; the office that will operate it can.
Put the data-protection position in writing. The agency is the personal information controller under RA 10173 and the vendor is a processor. Roles, retention, breach notification and sub-processing belong in the contract rather than in an assurance.
Conclusion
The terms of reference is the only document that a losing bidder, a winning bidder, an auditor and the office running the system all read. Time spent on it is worth more than time spent on any later stage, because every later stage is constrained by it.
If only one change is possible, replace the feature list with acceptance criteria naming a real office, real records and a real test. The rest follows from that.