Reviewing a Terms of Reference before approval is one of the most important steps in technical procurement. The requirements written into a TOR directly influence which vendors can participate, how proposals can be compared, what scope is ultimately delivered, how project cost develops, and how acceptance will be verified at the end of the project.

A poorly structured TOR does not create problems only during procurement. Ambiguous or unnecessary requirements can later result in scope gaps, change requests, cost overruns, delivery disputes, and systems that technically meet the contract but are not operationally ready.

1. Is the project objective clearly defined?

Before reviewing the technical specification, begin by asking whether the TOR clearly explains the problem the organization is trying to solve and the outcome the investment is expected to achieve.

If the TOR begins primarily with a list of equipment, features, or technical specifications without connecting them to a business or operational requirement, the solution may have been defined before the actual need was fully understood.

2. Are the requirements connected to real operational needs?

Important requirements should be traceable to a Business Requirement, User Requirement, or Operational Requirement.

For example, if the TOR specifies that a system must support a certain number of concurrent users, that number should be justified by actual usage, capacity planning, or expected growth rather than copied from a vendor specification sheet.

Connecting technical requirements to real use cases also helps distinguish between mandatory requirements and preferences.

3. Are any specifications higher than necessary?

Over-specification is a common procurement risk. Requirements that exceed actual operational needs can increase purchase cost, reduce competition, and create unnecessary lifecycle cost.

During a TOR review, each significant technical requirement should be challenged with a simple question: is this capability necessary to achieve the intended project outcome, and what would happen if the requirement were reduced?

4. Is there a risk of specification lock-in?

Specification lock-in occurs when technical requirements are written in a way that only a limited number of manufacturers or solutions can satisfy, without a legitimate operational reason for restricting competition.

Not every specific requirement is inappropriate. Compatibility, standardization, cybersecurity, safety, integration, or regulatory constraints may justify certain limitations. The key issue is whether the restriction can be explained and supported by evidence.

5. Is the Scope of Work complete?

A TOR that clearly specifies what must be purchased but fails to define the surrounding scope can create additional cost and disagreement during implementation.

The scope should consider activities such as supply, installation, configuration, integration, testing, training, documentation, warranty, support, and transition into operational use.

6. Are inclusions and exclusions clearly defined?

Items that are not clearly identified as included or excluded are often interpreted differently by different parties.

Infrastructure, cabling, network configuration, data migration, interface development, site preparation, utilities, and connections to existing systems should therefore have clear ownership.

7. Can all vendors interpret the TOR consistently?

One of the purposes of a TOR is to allow vendors to propose solutions against a common set of requirements.

If the wording is too broad or ambiguous, each vendor may propose a different scope, capacity, service level, or architecture.

This makes an apples-to-apples comparison difficult even if all prices appear in the same commercial comparison table.

8. Do the evaluation criteria align with the TOR?

Defining extensive technical requirements has limited value if the vendor evaluation process does not reflect what those requirements are intended to achieve.

If reliability, service capability, integration, lifecycle cost, implementation risk, or vendor support are important to the project, they should be represented appropriately in the vendor evaluation criteria.

9. Are the acceptance criteria and test methods clear?

A requirement that cannot be verified during acceptance creates risk for both the client and the vendor.

For each critical requirement, the project team should be able to answer: how will it be tested, who will verify it, what evidence must be provided, and what result constitutes a pass or fail?

Acceptance criteria should be linked to appropriate test methods such as FAT, SAT, UAT, commissioning, inspection, document review, or performance testing before procurement begins—not after the system has already been delivered.

10. Can the TOR be explained and audited later?

A well-developed TOR should support decision traceability, particularly for requirements that materially influence competition, technology choice, project cost, or vendor eligibility.

The organization should be able to explain why each important requirement exists, what information supported it, and what operational or technical constraint it addresses.

This traceability supports procurement governance, internal audit, conflict-of-interest management, and the ability to respond to questions regarding specification lock-in or vendor bias.

TOR Review Checklist Before Approval