An RFP can run smoothly, produce a preferred supplier and end with a signed contract. Then implementation starts. The equipment is specified, but the infrastructure isn't ready. The delivery dates looked achievable until someone checked site access. Responsibilities that seemed obvious during procurement turn out to mean different things to the customer and the supplier.
These problems often have their roots in the RFP itself. The procurement may have answered which supplier to choose without properly addressing what it will take to deliver the project.
A good RFP does both. It gives the organisation a fair basis for choosing a capable supplier, and it sets up the conditions for delivery to work once the contract is signed.
Describing the outcome, not just the shopping list
Many technical specifications read like an equipment list: a set number of devices, a particular console configuration, a minimum storage capacity. Those details matter, but on their own they invite suppliers to price the list rather than solve the problem.
It is usually more useful to explain what the organisation needs to be able to do when the project is finished. For a radio replacement, that might be the coverage field teams rely on, the way dispatchers handle calls during a major incident, and how long the old and new systems must run side by side. Suppliers can then propose how they would meet those needs, and evaluators can judge whether each proposal is credible.
Acceptance that is measurable from the start
If the RFP doesn't describe how the finished system will be tested and accepted, that conversation tends to happen late, under schedule pressure, with both parties reading the contract differently. Requirements such as "reliable coverage" or "fit for operational use" are hard to accept against because nobody has agreed what they mean.
Acceptance criteria don't need to be final at RFP stage, but they should be specific enough for suppliers to price and plan around. Coverage targets with a stated test method, performance thresholds, the number of sites to be tested, and who signs off at each stage all help. Asking suppliers to describe their own testing approach, including early factory or pilot testing before full rollout, also tells evaluators a lot about how they will run the project.
How the work will actually be delivered
A delivery plan is part of the bid, not an administrative attachment. The RFP should ask for an implementation programme with realistic durations, key dependencies and the assumptions behind them, along with the people who will do the work.
Named key personnel and their availability matter more than company capability statements. A supplier may have delivered similar projects elsewhere, but if the experienced project manager and lead engineer are committed to another contract for the first six months, that experience won't help this one. It is reasonable to ask who will be assigned, what proportion of their time they will spend on the project, and what happens if they leave.
A technically compliant proposal with an unrealistic implementation programme is not necessarily a good bid. If a supplier proposes to complete forty site installations in a period that allows no time for access approvals or weather, the evaluation should treat that as a delivery risk rather than an attractive date.
Honesty about site readiness and responsibilities
Suppliers can only plan around what they are told. If sites need power upgrades, new cabling, tower strengthening or building consents, the RFP should say so, or at least say what is known and what isn't. The same applies to site access: restricted hours, security inductions, shared facilities, landowner approvals and seasonal constraints all affect the schedule.
Customer obligations deserve the same attention. Many delivery delays come from things the customer was expected to provide — network connections, configuration data, user availability for training, decisions on design questions — rather than from the supplier. Where other contractors are working on the same sites or systems, the interfaces between them need to be described, along with who coordinates the work.
A simple responsibilities table in the RFP, covering what the customer provides, what the supplier provides and what is shared, prevents a lot of disagreement later. Suppliers should be asked to confirm it or state their exceptions.
The whole-of-life price
The lowest purchase price is not always the lowest cost. Support and maintenance, licensing, spares, software upgrades, training and eventual replacement can outweigh the initial capital cost over the life of a system.
Ask suppliers to price over a defined period using a consistent structure, so evaluators can compare like with like. Just as important, ask them to list their exclusions and assumptions clearly. A price that excludes site works, travel, integration with existing systems or third-party costs may look competitive until those items reappear as variations.
A fair and consistent evaluation
Evaluation criteria and their weightings should be published in the RFP and applied as published. Suppliers put real effort into their responses and are entitled to know how they will be assessed. Changing the emphasis partway through, or giving weight to factors that weren't disclosed, undermines confidence in the result.
For New Zealand government agencies and the procurements they cover, the Government Procurement Rules set mandatory expectations: equal access to information, managed conflicts of interest, documented decisions and clear communication with all respondents. For other organisations, the same principles are good practice rather than a legal requirement, and the organisation's own procurement policy and, where needed, its legal and probity advisers should guide how they are applied. Asking every supplier the same practical questions about resourcing, site readiness and testing is part of a fair process.
Planning for handover, not just installation
A project isn't finished when the equipment is installed. Training, documentation, transition to support, warranty arrangements and the decommissioning of old systems all need to be planned. An RFP that asks how the supplier will hand over the system, and what the operations and support teams will need to take ownership, avoids a common gap between go-live and business as usual.
Carrying the commitments into the contract and project plan
During evaluation, suppliers make commitments, state assumptions and clarify their proposals in writing. Those details are often the most useful part of the process, and they are easily lost.
Before the contract is signed, someone should go through the response and clarifications and make sure the important points are reflected in the contract schedules: named personnel, delivery milestones, acceptance criteria, responsibilities and agreed assumptions. The same information should go into the project plan, risk register and dependency list, so the delivery team starts with what was actually agreed rather than a summary of it.
The best RFP isn't necessarily the one that produces the most detailed response. It's the one that helps an organisation choose a capable supplier and gives both parties a realistic basis for delivery.
At TandemIT, we work across procurement and project delivery. That means looking beyond supplier selection to the practicalities of implementation, acceptance and handover. If you're preparing an RFP for a complex technology or infrastructure project, we can help — see our procurement and supplier management services or get in touch.