Writing requirements that produce comparable quotes
Three vendors, three quotes, three different scopes and no way to compare them. The problem is upstream: five sections decide whether quotes are comparable, and length is not one of them.
By Laurent TulpanPublished 9 min read
Three vendors, three quotes, and no way to compare them. One is half the price of another, and it takes a week of meetings to find out why: they did not scope the same work.
The instinct is to blame the vendors. The cause is upstream. Quotes are comparable when the request makes it impossible to answer a different question, and that is a property of the document, not of the market.
Five sections decide it. Length is not one of them.
Section one: the problem, measured
Not the feature you want. The situation that costs you something, quantified enough that success can be declared.
Weak: modernize our quoting process.
Strong: four salespeople each produce eight to twelve quotes a week. Each quote means looking up prices in a spreadsheet, phoning the workshop to check availability, then retyping the lines into the invoicing system. Measured over two weeks in March: forty minutes per quote, twenty-five of which is lookup and retyping.
The second version lets a vendor propose something you had not thought of. The first gets you priced on the words you used.
It also gives you the only honest basis for judging the result later, which is why the measurement is worth taking before anyone is engaged rather than reconstructed afterwards from memory.
Section two: who uses it, and under what conditions
The section most often skipped, and the one that changes the design more than any feature.
Not job titles: numbers, frequency, and physical conditions. Twelve workshop operators, wearing gloves, on a tablet fixed to a workstation, in a building where the wireless network drops several times a day. That last clause changes the architecture, and discovering it during acceptance testing means paying for it as a change order.
The rule to apply to yourself here: if a constraint is obvious to everyone internally, it is invisible to everyone external. Those are exactly the constraints that get omitted, because nobody thinks to mention what everybody knows.
Section three: the three things that make quotes incomparable
If you write nothing else, write these. They are the source of nearly every unexplainable price gap, and on the filled-in documents we are asked to review, all three are missing far more often than any of them is present.
Data migration. What has to come across, how much of it, from where, and in what state. Vendors make wildly different silent assumptions here, and the cheapest quote is generally the one that assumed the least. If the data quality is unknown, say it is unknown: that is information, and it lets vendors price the investigation rather than pretend it is free.
Integrations with existing systems. Which system, which vendor, which version, what has to flow, in which direction, and whether an interface exists. “Interface to be investigated” is an honest and useful answer. Ticking “API available” without checking produces a wrong quote, and correcting it will be at your cost.
What happens after go-live. Who fixes a defect, within what time, at whose expense, and for how long. A quote that ends at delivery and a quote that includes three months of correction are not the same offer, and nothing on either page says so.
Section four: what acceptance looks like
The clause that prevents the argument, and it belongs in the request rather than being negotiated at the end.
For each critical process, one sentence describing what somebody will do to verify it works, and what result counts as a pass. Three real quotes produced by a salesperson, each in under ten minutes, timed. That is testable. “The system must be user-friendly” is not.
Two effects. Vendors price against a defined finish line, which tightens their estimates. And when the moment comes, “done” is a fact rather than an opinion, which is the difference between a delivery and a dispute.
Section five: what you keep at the end
Three items, and two of them are not enough.
The source code, actually transferred to a repository you control. The operating documentation: how it deploys, where the data live, what it depends on, how to restart it. And the credentials to the hosting and third-party services, in your name from the first day rather than transferred later.
A clause saying the code belongs to you, without having received it, has never restarted a system. This matters more in some jurisdictions than people assume: under US copyright law, software written by a contractor is not automatically yours because you paid for it.
What to leave out, deliberately
Screen layouts, unless a regulation imposes them. You will get what you drew rather than what you needed, and you will have paid a designer’s judgment to be ignored.
Technology choices, unless you have a real constraint, in which case state the constraint rather than the choice. “It must run on our existing infrastructure” is a constraint. “It must be built in a specific framework” narrows your field of vendors for reasons that are usually inherited rather than examined.
A budget you have decided to hide. Withholding it produces quotes across a range so wide that none of them is useful, and three rounds of revision. Stating a range gets you proposals sized for it, which is what you wanted.
The test before sending it
Give the document to somebody who does not know your business and ask them to describe the process back to you out loud.
If they manage it, the document is good. If they ask three questions, those three questions are precisely what a vendor will price at the most cautious end. Answering them before sending costs an hour. Answering them afterwards costs a change order.
We publish a fillable template for this, built for exactly that test, and the vendor selection service page describes what we do when somebody would rather have the questions asked by someone who has answered them from the other side of the table.
Further reading
- Build or buy: the decision that precedes the document
- Acceptance criteria that end the argument: section four, in full
- Who owns the code your contractor writes: what section five protects you from
- Fixed fee or time and materials: how the pricing model changes the answers you get
- Software requirements and vendor selection: the same work, done from your side of the table
- A construction program does not wait for a software project: when the deadline is a design constraint
The questions this raises, answered straight.
How long should a requirements document be?
Ten to twenty pages for most business software. Beyond that it stops being read, by the vendors who answer it and by you when you need to hold somebody to it. A sixty-page document is not more rigorous, it is harder to enforce, because nobody can point to the sentence that was breached.
Should we describe the solution or the problem?
The problem, with enough precision that it can be measured. A vendor who understands the problem can propose something better than what you imagined. A vendor handed a feature list will price the list.
Describe the solution only where you are genuinely constrained, and say why, because an unexplained constraint gets designed around rather than respected.
What makes two quotes impossible to compare?
Almost always the same three omissions:
- data migration
- integrations with existing systems
- what happens after go-live
Each vendor makes a different silent assumption about all three, and the cheapest quote is usually the one that assumed the least. Naming those three explicitly is what turns three prices into a comparison.
Is it worth paying someone to write it?
It is worth paying someone to challenge it, which is not the same thing. You know your process better than any outsider. What an outsider adds is the questions a vendor will ask later, asked now, when the answers are still cheap.
If you do pay, insist that the document belongs to you and can be sent to vendors who did not write it.
Recognize your situation? 20 minutes is enough to tell.
Describe what is happening on your side, and where your data and customers are. You get a plain answer on whether we can help, and a better route if there is one.