A project brief is useful when it reduces ambiguity without pretending every detail is already known. Its job is to give the people doing the work enough context to ask better questions and choose an appropriate route.
Begin with the change
Describe what should become possible after the project. A sentence such as “researchers should be able to compare prepared compound records without editing spreadsheets manually” is more useful than “build an AI platform.”
The first version of the outcome can be imperfect. It simply needs to identify who is affected, what currently happens, and what should improve.
Show the starting materials
List what already exists: data, designs, code, structures, documents, hosting, or a manual workflow. Include formats, approximate scale, ownership, known quality issues, and any access restrictions.
Do not send sensitive material in an initial enquiry. First agree how confidential or regulated information can be reviewed safely.
Define the delivery
Name the form in which the result must be usable. A deployed interface, documented script, prepared dataset, technical report, figure set, or handover session are different deliverables even when they use similar underlying work.
If there are acceptance criteria, state them in observable language. Avoid criteria such as “modern” or “high quality” unless the brief explains what they mean in context.
Expose constraints and unknowns
Useful constraints include deadlines, budget boundaries, required environments, technologies that must or must not be used, maintenance expectations, dependencies, and review availability.
Unknowns are not a failure of the brief. Naming them early can reveal that a discovery sprint is the safest first engagement.
Working checklist
Before you move forward.
- The user or decision the work supports
- The current process or starting material
- The intended form of delivery
- Known constraints and dependencies
- What would count as complete
- Sensitive information withheld until a secure route is agreed