How do I prepare a concise project brief before work begins?
Quick answer
Write a short shared brief that states the intended outcome and audience, what is included and excluded, known constraints, unresolved questions, and observable acceptance criteria. Name an owner and approver, and set a review date. Mark unknowns rather than guessing. Confirm the brief with the people doing and approving the work, then update it when decisions or circumstances change.
The question, the details, the next step.
I have a project starting soon, but the request is scattered across messages. What should I put in a concise brief?
Bring the information into one small document organized around decisions people need to make. State the outcome—what should be different when the work is done and who it is for—then record the scope, constraints, open questions, and completion criteria. Include an owner, approver, and review date.
Keep only details that are known and useful now. If something is uncertain, label it as an assumption or question rather than presenting it as settled. The brief is a shared starting point, not a promise that nothing will change.
How do I make the outcome concrete if the request is vague, like “improve the onboarding materials,” and avoid guessing at a solution?
Describe a result someone can inspect without assuming how to achieve it. For example, as a hypothetical placeholder: “New team members can find the current onboarding steps and identify where to ask questions.” That is more specific than “make onboarding better,” but it does not assume that a new website, training session, or policy is needed.
A useful fill-in pattern is: “For [audience], [desired change] so that [purpose].” Use only details the requester has confirmed. If people disagree about what improvement means, capture that disagreement as an open question instead of hiding it in the outcome statement.
What belongs in scope and constraints? I want the brief to stay short, but still show what is not included.
Record boundaries that could change the work or someone’s expectations. Under “in scope,” name the main deliverable and essential supporting work. Under “out of scope,” note likely misunderstandings. For example, a hypothetical brief could say that updating existing materials is included, while redesigning the entire onboarding process is not yet agreed.
List confirmed limits such as a deadline, required format, available people, or dependencies; don’t invent them. Use a placeholder like [confirmed deadline] or mark an item “not yet known.” Leave minor implementation choices out unless they affect a decision. Ask: could omitting this detail cause rework or disagreement?
Can you give me a fill-in template with acceptance criteria and a way to handle missing answers?
Copy and adapt this starting point. Delete headings that do not help, and replace placeholders with confirmed details.
Project: [short name] Owner / approver: [name or role] Last updated / review date: [date] Outcome: For [audience], [desired change] so that [purpose]. Deliverables: [what will be produced] In scope: [work included] Out of scope: [work excluded or not yet agreed] Constraints and dependencies: [confirmed limits, inputs, or “not yet known”] Open questions: [question] — [who will resolve it] — [when] Acceptance criteria: The work is ready when [observable condition 1] and [observable condition 2].
For a hypothetical materials project, a criterion might be that the agreed pages are delivered in the requested format and the named approver confirms they cover the agreed topics. That describes what the example team would check for completion; it does not establish that the materials are effective.
Do not silently fill gaps with guesses. Mark important unknowns, and note who will resolve them and when if those responsibilities are agreed. Raise questions that could change scope, timing, or completion expectations before dependent work begins. Share the brief with the requester, people doing the work, and whoever will judge completion. Ask them to confirm the outcome, boundaries, and criteria. Update the relevant sections and review date when decisions change, and make significant changes visible to affected people.
A practical checklist
State the outcome and audience in inspectable terms.
Separate included work from exclusions and unagreed possibilities.
Record confirmed constraints; label assumptions and unknowns.
Give important open questions an owner and due date when agreed.
Write observable acceptance criteria and identify the approver.
Share the brief and set a review date.
A few more useful answers
How long should a project brief be?
Keep it as short as possible while still clarifying the outcome, boundaries, constraints, and completion criteria. A single page can be a useful target, not a rule; add detail only when it helps someone make or carry out a decision.
What if the requester cannot answer every question before work starts?
Mark unanswered items explicitly and distinguish blockers from details that can be settled later. Note who will resolve each important question and when, if those responsibilities and dates are agreed.
Should the brief change after work begins?
Yes, when decisions or circumstances change. Update the relevant sections and review date, and make significant changes visible to the people affected so they can confirm revised expectations.