The RFP froze but the need kept moving

Here is the week you probably had. You issued an RFP in early March with a requirement spec that four stakeholders signed off on. Six weeks later the proposals came back, on time, priced, and formatted to your template. You opened the scoring sheet and something felt off. The integration constraint that dominated section 4 had softened after the platform team picked a different middleware. The seat count in the volume assumptions was now 30 percent lower after a reorg. Two of the mandatory requirements were quietly no longer mandatory. Yet the scoring rubric, and the weightings behind it, still reflected the spec exactly as written on day one. You were about to rank three vendors against a need that had already moved.

This is one of the most common and least discussed failures in enterprise sourcing. It is not a vendor problem. Every vendor answered the question you asked. The problem is that the question aged between the day you asked it and the day you scored the answers, and nothing in the process was responsible for keeping it current.

Why the spec freezes and the need does not

An RFP is a snapshot. The moment you lock it and send it, you have made a bet that the requirement will hold still for the length of the response window. For a simple commodity buy over two weeks, that bet usually pays. For a platform decision with a six to ten week cycle and a dozen stakeholders, it almost never does.

The reasons are structural. Requirements are elicited from people, and people learn things during the cycle. The architecture review lands. A competing internal project changes the integration surface. Finance revises the headcount forecast. A pilot with an incumbent surfaces a constraint nobody wrote down. Each of these is a normal event. Individually none of them feels like it should reopen the RFP. Collectively they mean the document you are scoring against describes a company that no longer exists.

The freeze persists because reopening feels expensive and staying frozen feels free. Reopening means re-issuing, re-explaining, and resetting the vendor clock. Staying frozen means you score cleanly against a fixed target. The catch is that the cost of staying frozen is hidden. You do not see it as a line item. You see it later, as a contract sized for a need that changed, or a mandatory feature you paid a premium for and never turned on. We wrote about a related failure in the spec becoming folklore once its author rolls off the project.

What a moving requirement actually does to your score

The damage is not that you pick the wrong vendor, although you might. The damage is more subtle and more expensive. It shows up in three places.

First, weightings. If integration weighed 25 percent of the rubric and that constraint has since relaxed, you are handing a quarter of your decision to a factor that no longer matters. The vendor who over-invested in that answer wins points they should not have, and the vendor who fits the current need loses ground on the old one.

Second, volume and commercial terms. Proposals are priced against the assumptions in the RFP. If your seat count or transaction volume moved, every price in front of you is answering a question about a different sized deal. You cannot compare quotes cleanly, and you cannot negotiate from a benchmark, because the benchmark is anchored to a stale volume. This is where a live deal record matters. A quick price check against current volume tells you more than a scoring sheet built on last month's.

Third, the negotiation you are about to walk into. The counter offer you build from a frozen spec asks for concessions on things you no longer need and misses leverage on the things you now do. As we argued in the piece on the Negotiation Dossier, the counter offer is a document, and a document built on stale requirements negotiates for the wrong company.

The platform motion that removes the gap

The fix is not a better template. It is treating the requirement as a living record rather than a document you froze and forgot. On VendorBenchmark the AI analyst, Vera, keeps the deal record current as the requirement evolves. When the architecture note lands or the headcount forecast revises, the deal room reflects it, and so does the evaluation that reads from it.

This runs on continuous work rather than a one-time import. Thirty background jobs and six specialist agents watch the record, so drift between the original spec and the current need surfaces as a flag, not as a discovery you make weeks too late. When you re-score, you are scoring against the need as it stands, with weightings you can adjust and see the effect of immediately.

The commercial half comes from the benchmark layer. Because the record carries current volume, the comparison to 5,000 comparable deals and the wider set of 500,000+ real closed transactions is anchored to the deal you actually have. If the market moves against a deal while you are still in cycle, benchmark alerts tell you before you sign, not after. The evaluation and the negotiation both read from one current record instead of two stale ones.

What to check before you score

What this does not solve

Be clear about the boundary. Vera keeps the deal record current with the information it is given. It cannot know about a requirement change that lives only in a hallway conversation and never touches the system. If your architecture decision was made in a meeting nobody documented, the record will not reflect it until someone tells it. The platform reduces the archaeology, it does not read minds.

It also does not make the reweighting decision for you. It will surface that a constraint has relaxed and show you the effect on the score, but whether to drop it, and by how much, is a judgment your stakeholders own. The platform gives you a current, evidenced starting point. It does not replace the argument about what matters now, and it should not.

And it does not stop requirements from moving. Nothing does. A moving requirement is a healthy sign that your team is still learning during the cycle. The point is not to freeze the learning. The point is to stop scoring vendors against a version of the need that your own organisation has already abandoned. Keep the record current, and the evaluation follows the need instead of the paperwork.

Want to be updated when major licensing and pricing changes land? One analyst brief a week: the price rises, metric changes and audit campaigns that move software costs. Work email only.