Running a software vendor RFP that does not waste six months

01Why the standard process selects badly

A traditional RFP asks vendors to describe their capability in writing, then scores those descriptions. This measures proposal quality, and proposal quality is produced by a dedicated bid team that will not touch your project. Firms large enough to maintain that function score well structurally, independent of whether their delivery engineers are any good.

The second problem is that heavy RFPs deter exactly the vendors worth talking to. A strong 40-person engineering firm may decline to spend two weeks on a speculative 60-page response, while a firm with idle capacity and a template library will respond enthusiastically. The process filters toward availability rather than quality.

02A process that fits in six weeks

The structure below surfaces more signal than a conventional RFP and costs both sides far less. The core move is replacing written self-description with observed behaviour as early as possible.

03State your budget range

Withholding budget is conventional and counterproductive. The stated reason is to avoid vendors pricing to the number; the actual effect is that you receive proposals scoped against different assumptions, which are impossible to compare.

A stated range lets vendors show you what is achievable within it, which is the genuinely useful information. A vendor who inflates to consume the budget will reveal that in the technical session, when their proposed scope does not match the problem. That is easier to detect than reverse-engineering three incomparable proposals.

04Evaluation criteria that predict delivery

Score on evidence rather than assertion. Every criterion below can be verified during the process rather than taken on trust, which is what distinguishes them from the standard scoring matrix.

• Quality of questions asked about your problem - the strongest single early signal.
• Whether the engineers who will do the work attend the technical session.
• Willingness to disagree with your stated approach and explain why.
• Evidence of CI, code review and automated testing as standard practice.
• Clarity on what they would not do, or would descope, within your budget.
• Contract willingness on IP, client-owned infrastructure and exit terms.

05Reference calls, done properly

References are pre-screened, so asking whether the vendor did a good job is wasted time. The useful questions are about specifics that a coached reference cannot smooth over, and about the parts of the engagement that generally go wrong.

Ask what went badly and how it was handled - every real engagement has something. Ask whether the people who started finished. Ask what happened when scope changed, and whether the estimate held. A reference who cannot name a single difficulty is either not a real reference or was not paying attention.

• What went wrong, and how did they handle it?
• Did the team stay stable, or did people rotate off?
• How did they behave when the estimate turned out to be wrong?
• Would you hire them for something harder than what they did for you?