Government buys technology slower than almost any other sector. A 2022 Gartner survey put average decision time at 22 months, the longest of any industry surveyed. The reason isn't budget approvals or committee politics. In that same survey, 68 percent of projects stalled because the buying team couldn't get enough product detail from vendors, and 48 percent hit six or more separate delays. The bottleneck is market information, and it shows up after the clock has already started.
If you run IT at a Canadian municipality without a dedicated CIO, none of this is news. Plenty of towns don't have one; the senior IT person is usually a manager or coordinator reporting up through the Director of Corporate Services. A 2025 Euna report found that many departments run the whole procurement cycle with a team of one to three people. Citing 2024 research from the National Cooperative Procurement Partners, that same report puts the average project at 87 staff hours, with roughly half of that spent writing requirements. So half the time your team spends on the costliest document it writes is spent guessing at a market nobody on the team has actually seen.
The portals start after the hard part
BC Bid, MERX, Biddingo: they do their jobs well. But a tender portal only enters the picture once the requirements already exist. By the time an RFP is posted, the real decisions are made: scope, criteria, weighting, and your best guess at what's out there. The portal distributes those choices. It doesn't shape them.
So the actual learning happens somewhere else entirely, a cold vendor pitch here, whatever the next region over bought last year there. Neither is a real read on the market. Both are just samples of whoever happened to reach you first.
Where the 22 months go
Posting isn't the slow part. Most teams walk into the RFP process blind and end up using the tender itself as their first real look at the market. Every question that should have been answered months earlier turns into a Q&A round, an addendum, or an extension. That's where the months pile up.
Nothing stops you from learning what's out there before, or outside of, a formal tender. Your procurement policy doesn't bar market awareness; it bars awarding a contract the wrong way. Below the tender threshold, many purchases don't need an RFP at all, so the process you're bracing for might never even apply. For 2026 to 2027 the Canadian Free Trade Agreement sets that floor at 139,000 dollars for goods or services (Treasury Board Contracting Policy Notice 2025-8), and most municipal buying bylaws set their own floor lower still. Most of the lost time isn't structural. It's spent learning things, what vendors can do, what they charge, that you could just as easily learn earlier, in parallel, at no real risk.
How to see the market with a thin team
This works with a small team precisely because it all happens in writing, and it only happens once. Four habits carry the weight.
Write the criteria before you talk to anyone
Before the first vendor call, write down what would actually make a tool acceptable. Six headings cover most municipal software buys:
- Capability: the three to five outcomes the tool has to deliver
- Security posture: the certifications and software vendor questionnaire answers you'll need anyway
- Data residency: where the data physically lives, stated plainly
- Access: whatever standard your department requires
- Support: hours, channels, and escalation path, in writing
- Budget band: a range you could defend in front of council
This is the same work that eats roughly half of the 87 hours the NCPP research counted. Doing it early doesn't add work; it just moves the effort to the point where getting it wrong is cheap. At that stage, a mistake is an edit. Nine months later, it's an addendum.
Collect department input once, in writing
Forrester's 2024 research counts about 13 people in a typical B2B purchase, and puts 89 percent of purchases across two or more departments. Thirteen people are not going to reach consensus in a meeting on your timeline. Circulate the draft criteria once. Ask everyone to add, strike, or reweight, in writing. Disagreements become edits, which are easy to resolve, instead of objections raised in month nine, which usually aren't. The document itself becomes the record of consensus, so consensus stops requiring a meeting at all.
Ask every vendor the same questions
A demo answers questions the vendor chose, not the ones you asked. Two polished presentations from two different vendors will often contradict each other, and you won't catch it until you put them side by side. Send every vendor an identical set of questions in an identical structure. If your team already runs vendor forms or vendor application form templates, keep the same fields for every application vendor. Read the answers in one table. A contradiction that would have surfaced in month eleven now surfaces in week one. Save the demos for the two or three tools that actually earned the meeting.
Keep what you learn on file
File the criteria, the weights, and every vendor's answers. When another department needs something similar next year, they start from a real record of the market instead of from zero. For a team of one to three people, that file does the remembering the org chart says you don't have room for.
Three doors, all of them better
Once the field is actually in front of you, the cheapest door is the first one: if a strong fit sits below your tender threshold, deal with that vendor directly. No tender required. If the timing's wrong, the work still holds its value, file it and move on. And if a formal RFP really is required, you write it already knowing what the market can deliver. That's the real answer to how to write rfp requirements: start from what's actually out there, not from a guess.
That last door matters more than it looks. Euna's 2025 report found that 62 percent of public agencies get only two to five bids per RFP. A thin field isn't just bad luck; it's often a requirements problem. Vendors skip RFPs that read as vague, self-contradictory, or quietly written around whoever already has the contract. An RFP written after you've actually seen the field aims at a budget band that's real. It reads, to the vendors who fit, as winnable. Better awareness going in tends to produce a stronger field coming back.
Where PartnerAZ fits
Your criteria stay private. Qualified vendors apply against them anyway, and a team of one to three gets the field handed back already sorted by fit.
A vendor can pay to appear in your results. It cannot pay to rank higher. Fit alone sets the order, and that's the only reason the ranking is worth trusting.
The 22 months and the 87 hours are two symptoms of the same problem: meeting the market for the first time inside a process that's already running on a clock.
Look at the market before the RFP exists, and the RFP stops being the place where you find out what you're actually buying.
Q&A
Why is pre-RFP market discovery especially important for municipalities without a dedicated procurement team?
Many towns run procurement and IT with a skeleton crew, sometimes one to three people handling the whole cycle. Since so much of that limited time goes into writing requirements, learning the market first means the RFP isn't the first place they encounter real product detail.
Does looking at vendors before an RFP conflict with municipal procurement rules?
No. Market awareness is allowed before and outside a tender; knowing what solutions exist isn't the same as awarding a contract improperly. Below the local threshold, and under a town's own bylaw, a formal RFP may not even be required.
What should a municipality define before speaking with vendors?
Clear criteria first: required capabilities, security posture, data residency, access requirements, support expectations, and a budget band the team could actually defend. That makes vendor answers comparable and surfaces major gaps before the process is already underway.
Why should every vendor answer the same questions?
Because standardized questions are the only way to compare answers fairly. A vendor-paced demo shows whatever that vendor wants to highlight; identical questions, read side by side, surface contradictions early and narrow the field to the two or three tools worth a live demo.
How does PartnerAZ rank vendors in the results?
Criteria stay private; qualified vendors apply against them. Vendors can pay to appear in results, never to rank higher. The order comes from fit alone, which is what makes it worth trusting.