You do not need the requirements first

There is a version of this conversation we have several times a year. Somebody has a real problem, a budget and authority to spend it, and they are not ready to talk to us because they have not finished writing the requirements. They have been not-ready for four months.

The instinct is sound: be prepared, do not waste anybody’s time, know what you are asking for. It is also, in this particular case, expensive. The document is being written at the moment when the organization knows least about the answer, by people who have never built this, without access to the questions that would change it.

What the long document actually does¶

A long requirements document delays the project by however long it takes to write, and that is the smallest cost.

It also fixes decisions early that would be better made late. Requirements documents are full of solutions wearing the clothes of requirements: “the system shall provide a dashboard showing X” is a design decision, and it may well be the right one, but it arrived before anyone asked what question the dashboard is meant to answer or who is going to be looking at it at seven in the morning.

And it does not do the job people hope it does. A detailed specification feels like risk transfer: if it is written down and they miss it, that is on them. What it actually transfers is blame. Blame is worth much less than it appears at the point where the system does not do what you needed, because you still do not have the system, and now you have an argument as well.

The page you actually need¶

Five things. They can be written badly and in an email, and any firm worth hiring can start a real conversation from them.

1. 1.What starts the work. A customer calls, an order arrives, a truck reaches a gate, a month ends. Software is mostly a response to something happening, and naming the trigger is worth more than naming the feature.
2. 2.Who does it today, and with what. A person, a spreadsheet, three systems and a phone call. This is the single most useful paragraph you can write, because it is the only part of the description that is definitely true.
3. 3.What it costs when it goes wrong. Not a feeling: an order re-keyed, a day of a controller’s time, a customer lost last quarter. This decides the budget more honestly than any estimate does.
4. 4.What must not change. The system you are not replacing, the regulator, the customer who will not accept a new file format, the two people who will not be retrained. Constraints shape a design far more than wishes do.
5. 5.How you would know it worked. One sentence, ideally with a number in it. If it cannot be written, that is the most important thing to discover, and better now than at acceptance.

But we have to compare vendors fairly¶

Fair vendor comparison is the strongest argument for the long document, and it is worth taking seriously: a procurement process needs a common basis, and sending five firms five different conversations feels unfair and unauditable.

The trouble is what a common feature list actually produces. Every firm prices the list you supplied, so every proposal comes back within a similar range, and the exercise tells you nothing about which of them understood the problem, because none of them was asked to.

Issue the problem and the constraints instead, hold them identical, and let the responses differ. Then you are comparing the thing that matters: what each firm thinks the real difficulty is. The one who identifies a risk the others missed has told you something a matching feature list never could, and the one who simply restated your document back has told you something too.

Federal acquisition takes the same position in writing, which is a useful thing to be able to point at when the objection is that this is not how serious buyers behave. FAR 11.002 directs agencies (opens in a new tab) to state requirements in terms of the functions to be performed, the performance required, or the essential physical characteristics, rather than as a design somebody has already chosen. The reason is the one above: a solicitation written as a design forecloses the better approach a bidder would otherwise have offered, and it does it invisibly, because nothing in the responses reveals what nobody was allowed to propose.

What happens if you send the page¶

You get questions, and the questions are the deliverable. They are how you find out whether a firm is listening, whether they have done this before, and whether they will tell you something you did not want to hear in the first hour rather than the ninth month.

The requirements still get written. They get written afterwards, by people who now know what they are for, and they are shorter.