What to prepare before you brief a development team

Most projects that go badly did not go badly during the build. They went badly during the week the brief was written, and nobody noticed for two months.

You do not need a technical specification to start well. You need clear answers to a handful of questions that no developer can answer for you.

Who is actually going to use it

Not “our customers.” Which ones, doing what, on what device, in what situation.

A booking system used by office staff at a desk and one used by drivers on a phone in the rain are different products, even though the brief for both says “booking system.”

Name the primary user. If there are two very different ones, say so early — it changes the whole shape of the build, and it is far cheaper to know at the start.

What problem disappears when this works

Be specific about the pain, not the feature.

“We want a dashboard” is a solution. “It takes two days to find out which jobs are unpaid” is a problem — and it might be solved by something much simpler than a dashboard.

Teams that describe the problem get better results than teams that describe the solution, because the developer can suggest a cheaper route to the same outcome. Teams that arrive with a feature list get exactly that feature list, whether or not it fixes anything.

How it works today, including the messy parts

Write down the current process as it really runs — including the exceptions, the manual overrides, and the cases where someone just phones a colleague.

Those exceptions are where software projects overrun. Every one discovered mid-build is a change request; every one known upfront is just a design decision.

If your process only exists in one person’s head, put that person in the first meeting.

Who can say yes

Every project has moments where someone must choose between two reasonable options. If that person is unavailable, work stops or someone guesses.

Decide before the project starts who has final say, and make sure they have time for it. A project with three part-time decision makers and no tie-breaker will move at the speed of its slowest scheduling conflict.

What “done” means for version one

The most useful thing you can bring is a short list of what the first release must do — and a longer list of what it deliberately will not.

The second list matters more. It is what stops a three-month project becoming a nine-month one, and it is much easier to write at the beginning than to negotiate halfway through.

Anything on the “not now” list can still happen. It just happens after real users have told you whether it was ever needed.

What you genuinely do not need

You do not need to know which technology to use, how the database should be structured, or what the screens should look like. That is the work you are hiring for.

You also do not need a finished design. Sketches on paper are fine and often better — they invite changes, where a polished mockup invites approval.

A reasonable starting pack

Bring these and any competent team can quote accurately:

• One paragraph on the problem being removed
• The primary user, and where they are when they use it
• The current process, exceptions included
• Must-have list for version one, and an explicit not-now list
• Who approves decisions, and their availability
• Any hard constraints — a deadline that cannot move, a system it must connect to, a regulation you are bound by

That is usually one or two pages. It will save more time than a fifty-page specification, because every line of it is something only you could have supplied.