Procurement Requirements Vendors Can Be Held To
Poor specifications lead to poor outcomes. Build requirements that make supplier bids comparable and performance enforceable.
A procurement requirement that can't be measured can't be enforced — no matter how confidently a vendor claims to meet it. "Highly reliable," "industry-standard security," "fast support response" are the kind of specifications that make an RFP easy to write and almost impossible to hold anyone to later.
The cost of vague requirements rarely shows up during procurement. It shows up eighteen months into a contract, when performance falls short of what the utility expected and the vendor points out, correctly, that the contract never actually defined what "expected" meant.
This briefing sets out how to write requirements precise enough to make bids genuinely comparable, and specific enough to be enforced once the contract is signed.
From requirement to enforceable clause
A requirement is only as strong as its weakest link in a four-step chain — and most procurement documents break that chain in the first or last step.
Figure 1. A requirement that never becomes a number, and a number that's never attached to a remedy, are the two most common places procurement leverage quietly disappears.
Vague vs enforceable wording
Six risk points worth naming
Unmeasurable language
Words like "reliable," "robust," or "industry-leading" can't be tested against, so they can't be enforced.
No defined measurement method
A percentage target without a stated calculation method gets contested the moment performance is questioned.
No named remedy
A missed SLA without a pre-agreed consequence is a conversation, not a contractual lever.
Bids that aren't comparable
Vague requirements let vendors answer the question they'd prefer to answer, not the one actually asked.
Requirements copied from a different programme
Inherited specifications that don't reflect the current estate's scale or technology leave real gaps unaddressed.
No acceptance test tied to go-live
A requirement without a defined test event gets waved through and only tested for the first time in production.
Writing requirements that hold
Write every requirement as a measurable criterion
A number, a method, and a period — not "robust" or "industry-standard."
Define the test method alongside the requirement
How it will be measured, by whom, and under what conditions.
Attach a remedy to every SLA
A credit, a right to re-test, or an escalation path, agreed before the contract is signed.
Score bids against identical, specific questions
So a comparison actually compares like for like.
Build acceptance testing into the go-live plan
Not as a formality, but as the first real enforcement of the requirements.
The best procurement specification isn't the longest one — it's the one where every requirement has a number attached, a test method defined, and a consequence agreed if it isn't met. That's the difference between a document vendors can respond to and a document a utility can actually hold them to.
How a read moves across the estate
HOVER OR TAP A STAGE TO EXPAND TECHNICAL SPECS
Requirements that survive a contract
A requirement a vendor can be held to is one that's measurable, time-bound and tied to a remedy. 'Best-effort support' and 'industry-standard security' aren't requirements — they're aspirations, and they dissolve the moment something goes wrong.
The procurement that holds up is the one written in the language of SLAs, conformance tests and exit obligations, with the evidence defined before the contract is signed.
- 01
- 02
- 03
- 04Energy Industry Practice — Energy UK
Chris Gales
Chris Gales leads CEHG. He converts complex technical and commercial choices into clear decisions and dependable outcomes for utilities running connected device estates at scale.
He writes these field notes from the practice — on bearer migration, smart metering architecture, procurement and operations — to help estates start counting down early.