Partnership
How to brief a technology supplier so you get what you asked for
Most disappointing technology projects were mis-briefed rather than badly built. A good brief describes the outcome, the constraints and the decision.
When a project disappoints, the post-mortem usually settles on the supplier. Sometimes that is fair. More often the work was built accurately to a brief that described a solution nobody had validated, in place of a problem everybody recognised.
A brief is not a specification. Its job is to transfer enough understanding that a competent outsider can disagree with you usefully — and that is the part most briefs are written to prevent.
What a good brief contains
- The outcome — what will be true afterwards that is not true now, described from the business's side rather than the system's. Not "a new portal" but "customers can check order status without phoning us".
- The constraint that actually binds — the deadline, the budget, the system that cannot be touched, the regulator. Naming it early changes the shape of every proposal you receive.
- Who decides — one named person per decision. Ambiguity here is the single most reliable predictor of a project that slips.
- What success looks like — the measure you will judge it by, agreed before anyone builds. If you cannot name one, that is worth resolving before you spend.
- What is out of scope — the most valuable line in the document, and the one most often left out.
The three questions worth asking any supplier
Once the brief is out, the proposals will look more similar than they are. These three questions separate them faster than a feature comparison.
What would make you turn this work down?
Everyone has an answer. A supplier who does not is either very new or telling you what they think you want to hear, and both cost the same eventually.
What is the riskiest assumption in your proposal?
You are testing whether they have identified one. A proposal with no acknowledged risk is a proposal where the risk has been moved to you without being priced.
What happens if we stop working together in a year?
Ask it before the relationship is good rather than after it has soured. The answer tells you who holds the credentials, where the code and data live, and whether anyone else could pick the work up. A supplier confident in their work answers this comfortably.
“A brief's job is to transfer enough understanding that a competent outsider can disagree with you usefully.”
Write the brief before you shortlist
The common sequence — shortlist suppliers, then let their conversations shape the requirement — feels efficient and quietly costs you the ability to compare. Each proposal ends up answering a slightly different question, and the decision reduces to whichever conversation you enjoyed most.
Two pages is usually enough. If the brief runs past five, it has probably stopped describing the problem and started designing the solution — which is the work you are paying someone else to do.
Written first, the brief does something a shortlist cannot: it makes disagreement visible. When two suppliers read the same page and propose materially different things, you have learned something real about the problem — and that is worth considerably more than a tidier procurement process.
Have a Question About This?
If this raised something you are unsure about in your own setup, bring us the actual situation.