RFP development and bid evaluation

I write security specifications and evaluate the bids that come back. I take no commissions, hold no margin on anything I specify, and sell no hardware, software or installation, so there is no version of this engagement where I benefit from the answer. That is not a positioning line, it is the independence policy, and on this page it is the qualification.

Why tenders go wrong

Most security RFPs are written by someone with a stake in the result, or by someone with no technical depth who asked a friendly vendor for help. Both produce the same failure, just for different reasons.

• The spec describes a product, not an outcome. Part numbers and feature lists that exactly match one manufacturer, so the tender is decided before it opens.
• The scope has holes. Cabling, licensing, storage, network, power, and commissioning left ambiguous, then priced as change orders once the contract is signed.
• Bids are not comparable. Three submissions with different assumptions, different exclusions, and no common basis, which makes the lowest number look like the best value when it is usually the most excluded.
• Nobody defined acceptance. No test criteria, so the system is "complete" when the integrator says it is rather than when it demonstrably works.

Writing the specification

The goal is a document that lets several competent vendors bid honestly against the same requirement, and that gives you something to hold them to afterwards.

• Performance requirements over part numbers. Identification-grade coverage at a defined point, retention against a stated policy, failover behaviour described as a result rather than a product feature.
• The whole scope, named. Network, cabling, power, storage, licensing, configuration, commissioning, documentation, training, warranty. Everything that gets quietly excluded is listed and priced.
• A mandatory response format. If every bidder answers in the same structure, the submissions can actually be compared.
• Acceptance and commissioning criteria written in. The tests that must pass before final payment, defined before anyone has an incentive to argue about them.
• Evaluation criteria published up front, with weightings, so the award is defensible if it is challenged.

Evaluating what comes back

Bid evaluation is where the money is either protected or lost. Submissions are normalised so they can be compared honestly, scored against the published criteria, and the result is documented well enough to survive a challenge.

• Normalising quotes that were deliberately built to look cheaper than they are.
• Finding the exclusions, the assumptions, and the allowances that become change orders.
• Checking the proposed design actually meets the requirement rather than restating it.
• Scoring against the published matrix, with written reasoning for each score.
• A recommendation you can put in front of a board, a council, or a procurement officer.

Who this is for

Anyone spending public or institutional money on security systems, and anyone who has been burned by a tender that produced the wrong system at the right price.

• Municipalities, regions, and public agencies running competitive procurement.
• Utilities, transit authorities, ports, and critical infrastructure operators.
• Healthcare, education, and cultural institutions with capital projects.
• Multi-site private owners standardising across a portfolio.
• Anyone who needs the evaluation to be defensible because the award may be challenged.

What you get

• A tender-ready specification in your own procurement format, with scope, performance requirements, response structure, and acceptance criteria.
• Answers to bidder questions during the tender period, so clarifications do not quietly reshape the scope.
• A scored evaluation against the published criteria, with written reasoning and the exclusions surfaced.
• A written recommendation suitable for a council report or board paper.

Scoped and priced in writing before the work starts. Specification writing and bid evaluation can be taken together or separately, though taking both is what closes the gap between what was asked for and what gets scored.