A tender is not the paperwork before the real project starts. It is the moment when you have the most influence over the result and when every improvement costs the least. A week spent on the document can save months later.
I have written tenders for broadcasters and answered them for vendors, and the ones that worked well shared the same habits. Here are seven.
1. It describes the need, not the product
A good tender explains what the facility has to do: how many productions at once, which formats, what has to be live, what has to be shared. It leaves the solution open. That invites more vendors to bid, gives you real alternatives to compare, and keeps the design responsibility with the people who know their products best.
2. It starts from the workflow
Before the equipment list comes a page per production type: who does what, in which order, and what happens at a shift change or during a failure. With that page, every vendor sizes the same system, and the bids become comparable. It is also the page your operators will recognise themselves in, which makes adoption easier later.
3. It knows what matters most
A short list of true must-haves, then a longer list of should-haves and could-haves. The must list is the one you would exclude a bidder on; everything else is scored. This way the scoring can tell a strong answer from a weak one, and the decision is easy to explain to the board.
4. It asks for evidence
For every key requirement, the tender asks how it is met and where it already runs, and it says which items will be shown in a proof of concept. That turns a compliance matrix from a list of ticks into a conversation about real capability, and it rewards the vendors who have actually done it.
5. It gives every interface an owner
Large projects are split into lots, and the work between the lots is where surprises live: timing, the network, integration with existing systems, power and cooling, removal of old equipment. A simple responsibility matrix, one line per interface with one owner, keeps the budget and the schedule intact after signing.
6. It compares the cost of owning, not only buying
A facility runs for seven to ten years, and more of its cost is now in licences, subscriptions, support and upgrades. A good tender asks for the full picture over that period, with licence models and renewal prices written out, so the bid that is cheapest on day one is also the best value in year five.
7. It defines what done means
Factory and site acceptance tests, clear criteria, documentation and training as deliverables, and payment milestones linked to all of it. Everyone knows what finished looks like, the integrator can plan for it, and the operators get a system that works the way they expected.
What to do with it
Before publishing your next tender, read it once with these questions in mind:
- Could several vendors answer this honestly, each with their own solution?
- Would two bidders size the system the same way from the workflow description?
- Is the must list short, and does every key requirement ask for evidence?
- Does every interface have an owner, and is “done” defined in tests?
- Are you comparing cost over the life of the system?
A yes on most of these is a good sign. Where the answer is no, that is where a few hours now pay off most.
In short
The tender is where a project is won or lost, long before anyone installs anything. Describe the need, start from the workflow, ask for evidence, give every interface an owner, compare the full cost and define done. Get those right and the rest of the project becomes a lot more predictable.
Writing a tender for a renewal or a new facility? I’m happy to give it a second pair of eyes.
Found this useful? Pass it on to someone facing the same decision.
