What a good project brief contains

Most briefs are feature lists. Five pages, a contact form, a blog, an admin panel, mobile responsive. Everything in that list is true and none of it says what the project is for, which means the people building it are guessing about the only thing that matters.

A brief that produces good work does something different. It describes a problem clearly enough that someone else could propose a solution you had not thought of.

Start with what is not working

One paragraph, in plain language, about the situation rather than the fix.

"We get around forty enquiries a month and close maybe three. We think people cannot tell what we actually do."

That is more useful than ten pages of specification, because it lets someone challenge the assumption. Perhaps the site is fine and the follow-up is the problem — which is more often the case than anyone expects. A feature list cannot surface that. A problem statement can.

Say who it is for

Not a demographic. A recognisable person with a situation.

"An operations manager at a 30-person manufacturer who has been told to fix a process and does not know whether they need software or just a decision."

Everyone building can picture that person. "SMEs in the NCR region" describes nobody, and work aimed at nobody reads like it.

Say what would count as success

Specific and checkable. "More enquiries" is not a target. "Ten qualified enquiries a month, up from four" is.

And write down what would count as failure, which almost nobody does and which sharpens everything. "If it looks better and the enquiries stay the same, this was a waste." That sentence changes how a project gets built.

A brief that cannot be failed cannot be succeeded at either. It can only be delivered.

Say what you will not do

Constraints are the most useful part and the most often left out.

The budget, as a real range. The date, and what happens if it moves. The tools you are keeping regardless. The things that are decided and not open — a brand you will not change, a system you cannot replace.

Withholding the budget to "see what they come back with" produces proposals aimed at an imagined number, and a round of re-scoping that costs everyone a fortnight. Say the range. A partner worth having will tell you what fits in it.

Say who decides

One name. Others can advise, but one person consolidates feedback and decides. Briefs that skip this produce projects where three people give conflicting direction and the work oscillates.

Also say how fast that person can respond. If reviews will take a week because of how your business runs, that is not a problem — it is a fact the timeline should be built around. Pretending otherwise just means the plan is wrong from day one.

What to leave out

Solutions, mostly. If you have already decided on the answer, say so and say why — but if you are open, leave it open. The value of hiring people who have solved this before is that they may know a smaller way.

Examples of sites you like, without saying why. Three links are useless. "We like this one because the pricing is clear immediately" is worth more than thirty.

Page counts. The structure should come out of the problem, not into it.

The test

Give the brief to someone who does not know your business and ask what problem it is solving and who for. If they can answer, it is a good brief.

If they can only tell you what is being built, you have written a specification — and specifications produce exactly what was asked for, which is only useful if the request was right.