The document you are trying to write does not exist
Most software briefs are written by someone who has been told to write a specification, cannot write one honestly, and produces a hybrid: half a feature list invented on the drive to the office, half a wish. It goes out to four firms. Three of them price the feature list, which is a description of a solution nobody has validated. The fourth asks a lot of questions and looks slow and expensive next to the other three. The buyer picks a number, and in month three discovers the number was for a different project. This is not a vendor problem. It is a document problem, and it is fixable in about a week of your own time.
A brief has one job, and describing the software is not it. Its job is to let a competent stranger decide three things: whether they can help you, what they would do in the first two weeks, and what it would cost to find out whether the rest is possible. Everything that serves those three decisions belongs in the document. Everything else is padding, and padding is expensive because it hides the parts that matter.
That reframing does most of the work. Once the brief is aimed at a decision rather than at a build, the parts you genuinely do not know stop being embarrassing gaps and become the content. "We do not know whether the data supports this" is a sentence that helps a good firm quote you accurately. It is also the sentence most buyers delete because it looks like weakness. It is not weakness. It is the actual state of the project, and every firm worth hiring is going to work it out in the first conversation anyway.
You are probably here because
- You have been asked for requirements and you do not have any that survive a follow-up question
- Two quotes came back a factor of five apart and you cannot tell which one understood the job
- The last project was priced off a feature list and changed shape in month two
- Someone said “we should do something with AI here” and it became your problem to define
All four have the same cause: the document is describing a solution instead of a decision. The six sections below are what a brief carries instead.
Describe the current process in nouns and numbers
This is the section that separates briefs that get useful responses from briefs that get boilerplate, and it is the one most often written in adjectives. "Our reconciliation process is inefficient and manual" tells a reader nothing they can price. Replace every adjective with a countable noun.
Who touches the work, by role and headcount. How many items go through it in a week, and what a busy week looks like versus a quiet one. Where each item comes from and what format it arrives in. How long a single item takes, and what portion of that is waiting versus working. What happens when one is wrong, who catches it, and how long the catch takes. What the process costs, either in hours or in dollars, even roughly.
Six sentences of that beats three pages of narrative. And write the numbers you are unsure of with the uncertainty attached: "roughly 400 a week, could be 300, nobody measures it" is more useful than a confident 400 that turns out to be 900 in the third month. A firm that knows the number is soft will design for both.
Then attach an example. One real record with the sensitive fields blacked out. One page of the actual report. One screenshot of the actual screen somebody stares at all day. A single genuine artifact is worth more than any amount of description, because it silently answers a dozen questions the reader did not know to ask: what the field names really are, how dirty the input is, whether the dates are consistent, whether the thing you called a form is a PDF or a spreadsheet somebody emails around.
Where the writing time should go — our default weights
Weights sum to 100. Our starting point, not a measurement. Note the last row: your solution guess is worth including and worth the least space.
State the outcome as something a stranger could measure
The outcome is not a feature. It is the observable difference between the world with the software and the world without it, written so that a person who was not in the room could check it.
Four ingredients, and none are optional: what changes, for whom, by how much, and how you would know. "Cut the time to close the month from nine days to four, measured on the next two closes." "Handle 80 percent of tier-one tickets without a human touching them, measured over a full month, with the other 20 percent routed the way they are today." "Let a regional manager answer a question about their own territory without filing a request with the analytics team."
If you cannot write the number, write the number you would like and mark it as an aspiration. A brief that says "we would like 80 percent and we have no idea whether that is achievable; tell us what you think is achievable and why" is a strong brief. It has just told every responder that the first piece of work is a feasibility answer, and it has invited them to compete on their judgment rather than on their confidence, which is the trade you want to be making.
Name the data, and name the person who can grant access
More projects stall here than anywhere else, and it never shows up in the brief. The technical work is possible, the vendor is competent, the budget is approved, and week three is spent waiting for someone in another department to decide whether an export is allowed. That wait routinely runs longer than the build.
So write it down before you send the brief. What systems hold the data. Who owns each one, by name and role, not by department. Whether the data has ever left that system before, and if so how. Whether anything in it is regulated, contractual, or belongs to a customer rather than to you. Whether a copy can be moved to a vendor environment, or whether the work has to happen inside yours. What the approval path looks like and roughly how long it has taken in the past.
Two sentences here change the shape of every response you get: "IT has confirmed a read-only extract can be provided within two weeks of contract signature" or "we have not yet asked whether this data can leave our environment." The first buys you a clean schedule. The second buys you a vendor who plans for the delay instead of discovering it. Either is fine. Silence is what costs you.
Constraints are more useful than requirements
A requirement narrows what gets built. A constraint narrows what is possible, and that is far more valuable to a reader. Most briefs are heavy on the first and silent on the second, which is backwards.
What it has to live next to. Name the systems it must read from or write to, by product and version. "Our ERP" is not an answer; a named system with a named version and whether it has an API is.
Who uses it and where they are. Twelve internal analysts at desks is a different product from four hundred field staff on phones with bad signal, and the difference is not a feature toggle.
Where it can run. Your cloud, their cloud, your data center, an environment nobody may connect to from outside. This single line can double or halve a quote, and it is frequently omitted.
What cannot move. A regulatory audit in March. A contract renewal that makes the current tool unusable in Q3. A parent company standard on where data may reside. Date constraints are the ones buyers most often keep to themselves and most regret keeping.
Who has to approve it and what they care about. Legal, security, a works council, a customer with an audit right. Naming them early is not bureaucracy; it is the difference between a review that takes two weeks and one that takes two quarters.
Say what you have measured and what you are guessing
Mark every number in the brief as one of three things: measured, estimated, or assumed. It takes a word each and it changes how the whole document is read.
Measured means somebody pulled it from a system this month. Estimated means an experienced person's judgment. Assumed means you needed a number to write the sentence. All three are legitimate. Mixing them silently is not, because the reader has to treat every figure as equally solid, and the one that is load-bearing is usually the one nobody checked.
Number the paragraphs
Give every paragraph in the brief a number, or at least every section. It costs nothing and it changes the responses: instead of a generic proposal, you get answers that say “on 3.2, we would do X; on 4.1, we think the number is optimistic and here is why.” It also makes comparing three responses side by side a mechanical task instead of a reading exercise. Buyers who do this once never stop.
Send us the draft and we will mark it up.
Email whatever you have to contact@precisionfederal.com — a page of notes is enough, and it does not have to be tidy. You get back a short written note naming what a responder cannot price from it and the three questions we would have to ask. One business day. No charge and no obligation to hire anyone.
contact@precisionfederal.comWhat to leave deliberately open
The architecture. The tools. The model, if there is one. The database. Whether it is a web application, a background job or a change to something you already own. State the outcome and the constraints and let the responses differ on method, because the difference between the responses is the most useful information you are going to get in this whole process.
When four firms propose four different approaches to the same well-written brief, you have learned something real about the problem. When they all propose the same thing because you told them what to propose, you have learned nothing and you have quietly given up the one advantage of hiring people who do this for a living.
There is one exception. If you have a genuine preference — your team knows one language, your operations group refuses to add a fifth vendor to the stack, your board has a standard — say so plainly and say it is a preference or a rule. What harms you is the unwritten preference that surfaces at selection, after four firms have spent real time on a proposal that was never going to be chosen.
Money: give a range or give the decision rule
Buyers are told not to name a budget because vendors will spend it. That advice costs more than it saves. Without a range, responders must guess at the scale of the thing, and the guesses come back several times apart — not because anyone is dishonest, but because "improve our reporting" is a genuine 40,000-dollar project and a genuine 900,000-dollar project depending on what was meant.
You have two honest options. Name a range: "we have approved 150 to 250 for the first phase and can go further if the first phase pays." Or name the rule that decides: "this is worth funding if it saves two full-time roles inside a year; show us the arithmetic and we will fund to that." The second is often better, because it tells responders what has to be true rather than what is available, and a good firm will tell you when the arithmetic does not work.
What to avoid is the shape where the budget is real, known, and withheld, while responders are asked for a fixed price on an undefined scope. That produces one of two outcomes: a low bid that becomes a change-order argument, or a high bid that prices your ambiguity as risk. Both cost you more than saying the number.
What a missing item costs you in the responses you get back
How much each omission degrades the quotes you receive, as we rank it. Judgment, not a study — the ordering is the useful part.
Reading the responses
A well-written brief changes what comes back, and the differences are easy to read once you know what you are looking at.
| What comes back | What it usually means | What to do |
|---|---|---|
| A price and a timeline, no questions | They priced the feature list, or they are pricing a template | Ask what they would do in week one and what would change the number |
| Five sharp questions before any number | They read it and found the load-bearing unknowns | This is the good signal. Answer the questions properly |
| A phased shape: small paid step, then a decision | They think the risk sits in the unknowns, and they are usually right | Ask what the first step would have to show to justify the second |
| A quote far below the others | Different scope, not a better rate. Almost always | Ask them to restate the scope in their own words and compare |
| An architecture diagram in week one | A solution they already had, matched to your brief | Ask which parts would change if the data is worse than described |
| “We would not do this project” | Sometimes the most valuable response you get | Ask why, in writing. It is free diligence |
Weight the questions heavily. A firm that asks whether your 400 items a week are evenly distributed, or who resolves the disagreement when two records conflict, has read the brief and thought about the work. A firm that asks nothing has either done this exact thing before — in which case they should say so, specifically — or has not engaged with it at all.
The mistakes we see most often
- A feature list invented by the buyer, priced faithfully by three vendors, wrong by month two
- Adjectives where numbers belong — “slow”, “manual”, “inefficient”, “scalable”
- No sample record, so nobody discovers the data is worse than described until week three
- Data access assumed rather than checked with the person who has to approve it
- The real deadline withheld because it seemed like leverage
- An unwritten technology preference that only surfaces at selection
- A fixed price demanded on an undefined scope, which prices your ambiguity as their risk
- Twelve pages of background and one paragraph on what success would look like
A week to write it
Writing the brief
Step six is the one that pays and the one everybody skips. If the colleague describes something you did not intend, the brief is ambiguous in exactly the way it will be ambiguous to a vendor — and you found it for the price of a coffee instead of the price of a phase. Two to four pages is the right length. Past four, add an appendix rather than more prose.
Before you send it
- The current process is described in countable nouns, not adjectives
- One real, redacted sample record or document is attached
- The outcome names what changes, for whom, by how much, and how it is checked
- Every number is marked measured, estimated or assumed
- The data owner is named, and someone has actually asked them
- Constraints are separated into hard rules and preferences
- The real deadline and what drives it are both written down
- A budget range or a funding rule appears in the document
- The method is left open on purpose, and the brief says so
- Someone outside the project read it and described the right thing back to you
Bottom line
You cannot specify software you have not designed, and you should not try. What you can do is describe the current world precisely, state what would have to be different for the project to be worth funding, name the things that cannot move, and be explicit about what nobody knows yet. That document is short, it takes about a week, and it produces quotes you can actually compare — because every firm reading it is pricing the same problem instead of pricing their own interpretation of your feature list. The unknowns do not go away when you leave them out of the brief. They just get priced blind, by someone who did not know they were guessing.
Frequently asked questions
Two to four pages, plus attachments. Past four pages the important material starts hiding inside the background, and readers skim. If you have more to say, put it in an appendix and keep the front of the document to the current process, the outcome, the constraints and the decision. Screenshots and sample records belong in the appendix and are worth more than the prose.
Yes, as a range or as a funding rule. Without one, responders guess at the scale of the project and the guesses come back several times apart, which tells you nothing about who is better. The alternative that works just as well is to state what has to be true for the project to be worth funding — a payback period, a headcount saving — and let firms show the arithmetic against it.
Write that sentence into the brief and make the feasibility answer the first deliverable. Ask each responder what they would need to see to give you a confident number, how long that would take, and what it would cost. Their answers to that question are more diagnostic of quality than anything else in a proposal, because it is the question that cannot be answered from a template.
No, it is the point. Divergent proposals against one clear brief tell you where the real design choices are and what each firm believes about the risk. Convergent proposals usually mean the brief specified the solution. Read the differences, ask each firm why they chose their approach over the others, and you will learn more about the problem than any amount of internal analysis would have produced.
Use it for the commercial terms and ignore its requirements section, which is built for buying something that already exists. A template asking for a numbered list of functional requirements will force you to invent them, and the invented list becomes the contract. Attach your brief as the technical content and let the template carry the terms, the timeline and the evaluation process.