How to write a brief for a software project

Most people put off approaching a software developer because they think they need a specification first, and they know they are not qualified to write one. They are right about the second part and wrong about the first.

A brief is not a specification. A specification describes a solution, in detail, and writing one before anybody understands the problem is how projects end up building the wrong thing precisely. A brief describes a business, a process and a problem, and it is the thing only you can write. Two or three pages is plenty.

Here is what to put in it, what you can leave out, and why the leaving out matters as much as the putting in.

Start with the problem, not the feature list

The commonest way a brief goes wrong is that it opens with a list of screens. "We need a dashboard, a customer database and a reporting module." That tells a developer nothing about whether any of it is worth building, and it rules out the better answer somebody might have offered.

Write the problem instead. What happens today, what it costs you, and what you want to be different. If you can finish the sentence "at the moment we lose about half a day a week to..." you have a better opening than any feature list.

The test: could a reader who has never met your business explain, in one sentence, why you are spending money on this? If not, the brief is not ready.

Describe the process as it happens

This is the most valuable section and the one people skimp on. Take one real example of the work (one order, one job, one referral, one enquiry) and follow it from the moment it arrives to the moment it is finished and invoiced.

Say who touches it, in what order, and what they do. Name the systems and the files. Include the awkward parts: the email that has to be forwarded, the figure copied from one screen into another, the spreadsheet that gets checked against the accounts package on a Friday. Those are usually where the value of the project sits, and they are invisible from the outside.

Write it as it actually is, not as the policy says it should be. Nobody is being marked. If two branches do it differently, say so. That difference will otherwise surface halfway through the build as a surprise, and surprises are what make projects run over. Our guide to how long bespoke software takes goes into why undiscovered process variation is the single biggest cause of delay.

Say who uses it, and where they are

Numbers and circumstances, not job titles alone. Four people in the office, eleven engineers in vans with phones, two managers who want a figure on a Monday morning, and a customer base of 300 who currently ring up to ask where their order is.

Whether people need it away from a desk changes the shape of the whole system, so it belongs near the top. So does the count: software for six concurrent users and software for sixty are different builds, even when the screens look the same.

State what success looks like, using numbers you already have

It is not "improve efficiency", but something you could check a year later.

"Order entry takes fifteen minutes and we do forty a week." "We re-key every invoice into Xero." "We cannot tell you how many quotes turned into work last quarter without an afternoon of exports." Those are measurable, they make the business case arithmetic simple, and they give the developer something to design against.

You do not need precision. An honest estimate from the person who does the job is worth more than a figure from a system nobody trusts.

List the systems it has to live with

Every package the new system touches or replaces: the accounts software and which version, the CRM, the website, the stock system, the card machine, the spreadsheet that is really a database. Note which ones are non-negotiable.

Say whether they are cloud or installed on a machine in the office, because it decides whether an integration is straightforward or a project of its own. This is the ground covered on our system integration page, and it is worth flagging early. The difference between a system that writes to your accounts package and one that exports a file for someone to import is a real difference in both cost and daily effort.

Be honest about budget and timing

People hide the budget because they think naming a number means paying it. In practice, withholding it wastes everybody's time: a developer who does not know whether you are thinking £8k or £80k cannot tell you what is feasible, so you get a proposal aimed at the wrong problem.

A range is fine. "We have thought about £20k to £30k and we would want it inside the financial year" lets a supplier tell you honestly whether that works, or which part of it to do first. We publish indicative bands on the bespoke software cost page so you can arrive with a sensible number, and the budgeting guide covers when the money actually leaves the bank.

If there is a real deadline (a contract renewal, an audit, a system going out of support, a grant that expires), say what it is and why. A date with a reason behind it gets planned around. A date without one gets discounted.

Say what is out of scope

One short paragraph, and it saves more trouble than anything else in the document. "We are not changing the accounts package." "Payroll is not part of this." "The public website stays as it is."

The same applies to the process itself. If part of how you work is about to change, flag it, because building software around a process you are already unhappy with makes the wrong shape permanent. That is the warning in our guide on outgrowing spreadsheets, and it holds for any replacement project.

Two things worth a line each

Data protection. Note whether the system will hold personal data, and whose: customers, employees, patients, children. It changes decisions about hosting, access and retention, and it is much cheaper to design in than to retrofit. The ICO's guidance for organisations is the authoritative starting point if you are unsure what applies to you.

Who decides. Name the person who can settle a question in a day. Projects stall on decisions far more often than on code.

What you do not need to work out

Database design, hosting, frameworks, which cloud, how the screens should look, whether it should be a web app or a desktop one. Those are the supplier's job, and a brief that specifies them narrows the options before anyone has understood the problem.

You also do not need to have decided whether bespoke is the right answer at all. A good supplier will tell you when an off-the-shelf package does the job, which is the honest comparison our guide to bespoke software versus off the shelf sets out. Saying "we are not sure this needs building" in the brief is a strength, not a gap.

What happens next

Expect questions. A brief is the start of a conversation, not a tender document, and any supplier worth using will want to watch the process rather than only read about it. What the brief buys you is a first conversation about the right things, and quotes that can be compared because they were all answering the same question.

If you would rather talk it through before writing anything, that is what the free process audit is for: an hour, usually on site, mapping what actually happens. You can get in touch and we will tell you honestly whether there is a project here at all.