How to write a one-page project brief

A project brief is written to get a decision. That is the argument of this page: a brief is not documentation of a project, it is the one page that lets somebody say yes, no or not yet to a piece of work. It is finished when the person deciding has nothing left to ask.

What a brief is for

A request arrives as a sentence: "we need an audit log". Somebody then has to decide what happens to it: plan it, look into it first, park it or decline it. The brief is what that person reads. They were not in the thread, will read it once, and have to act on it without you in the room.

That is why it is one page. A longer brief has usually started to answer how, which is the next document, written only if this one gets a yes.

A brief is not a commitment. Promising people and a date takes more: capacity the delivering team gave, and dependencies the other side confirmed. That is a later and different list of six, set out in what a decision-ready demand contains. That essay argues for a bar; this page is a template.

The six fields, in order

The order matters at the top: the outcome cannot be written before the problem, or the scope before the outcome. The running example is invented.

1. The problem. What is going wrong today, for whom, and what it costs. Write it before any solution, and without naming one.

• Weak: "We don't have an audit log."
• Strong: "When an enterprise customer's security team asks who changed a permission, support has to ask an engineer to search production logs, which go back thirty days. Older questions cannot be answered at all."

The weak line is a solution with "we don't have" in front of it. If you can only state the problem by naming the thing you want built, you have a topic, not a request.

2. The outcome. What will be true afterwards that is not true today.

• Weak: "Better visibility of admin activity."
• Strong: "An account admin can see who changed which permission and when, for up to twelve months back, without contacting us."

Write it so that someone could later tell whether it happened. "Better" cannot be checked; "an admin can see it without contacting us" can, by anyone. Use a number only if you have a real one.

3. Scope, in and out. Two lists, written with equal care.

• Weak: "In scope: audit logging. Out of scope: everything else."
• Strong: "In: changes to roles, permissions and sign-in settings, viewable by account admins. Out: logging who viewed what, streaming events to a customer's own security tooling, and history from before launch, which the current logs cannot supply."

The out list is the half that gets used later, because scope is mostly what you are not doing. Name what someone will plausibly ask for, with the reason where there is one.

4. The owner. One person, by name.

• Weak: "Owner: Platform team."
• Strong: "Owner: Ines Duarte, engineering manager, Platform. She has been asked and has agreed."

The owner of a brief answers for the decision, not necessarily for the build. A team name fills the field without answering it: an owner is a person.

5. Who must be consulted. The people whose answer the work waits for, and what each has to answer.

• Weak: "Stakeholders: Sales, Support, Security, Legal, Product, Customer Success."
• Strong: "Marek Zielinski in Security decides which actions count as admin actions. Aoife Brennan in Legal confirms how long entries that name a person may be kept. Support and Sales are informed."

Consulted means the work waits. Informed means it does not. It is the line a RACI matrix draws between its C and its I. Six departments in a row says who is interested. Two names and a question each says where the work can stall.

6. Why now. An event or a date, and what waiting costs.

• Weak: "This is a top priority for the business."
• Strong: "Two enterprise renewals in January include a security questionnaire that asks for this. Last year's was answered 'planned'."

Priority is a conclusion; the brief should hold the evidence for it. If there is honestly no deadline, write "no deadline". It tells the reader that "not now" is a safe answer.

One line under the six: what you do not know

Finish with the open questions: "We do not know whether twelve months is long enough for either customer, or how much storage a year of events needs." That line tells the reader whether to plan the work or look into it first.

If there are none, say so in words. "No material unknowns" is a claim somebody can challenge; a blank is not. Sorting what you were told into facts, assumptions and open questions is its own essay.

What to leave out

• The solution. Architecture, vendor, screens. Stating only the problem lets the people who would build it propose something cheaper than the requester imagined.
• An estimate nobody gave. A size typed in by the brief's author gets quoted back as a promise. Size comes from the delivering team, later, and even then an estimate is not a commitment.
• A delivery date. The date the world imposes belongs in why now. The date the team will hit does not exist yet.
• Tasks, milestones and a risk register. They belong to the plan, and nobody has agreed to plan yet.
• The history. Who asked first and how the thread went.

When the page runs over, delete every sentence the reader would not miss while deciding.

A filled-in example

The six strong lines above, read top to bottom, are a complete brief. For a second one laid out as a page, see the filled-in one-pager for a fictional demand: moving quarterly finance reports off a legacy data warehouse. That demand has been committed, so its page carries a timeline and an effort figure at the top and calls its outcome the committed outcome. Below that, the fields are the same six in the same order. Its stakeholders line is a plain list of parties, the weak form of field five: when you write your own, add the question each one has to answer.

Project brief vs project charter, business case and PRD

The names are used loosely. What separates the documents is the question each answers and when it is written.

A project proposal is a brief with something to sell: written to persuade a client or a funder, it adds an approach and a price. The four in the table are written at different moments and do not replace one another. The brief comes first because it is the cheapest to write and to turn down. If you only ever write one, write the brief, and do not mistake it for a charter: a brief authorises nothing.

A project brief template to copy

Copy it as it stands and replace everything in square brackets.

[Working title: short and specific]

Problem: [what is going wrong today, for whom, and what it costs. No solution named.]

Outcome: [what will be true afterwards that is not true today, written so someone could check it.]

In scope: [a short list of what the work covers.]

Out of scope: [what someone will plausibly ask for, with the reason where there is one.]

Owner: [one person, by name, who has agreed.]

Must be consulted: [who the work waits for, and what each has to answer.]

Why now: [the event or date, and what waiting costs. Or: no deadline.]

Open questions: [what you do not know yet. Or: no material unknowns.]

Write it with the requester, while they still have the context. The step before this one, the form the requester fills in, is a much shorter intake form template. The work of writing a brief is what the glossary calls shaping.

If you use DeliverySheet

This document is what the Shape stage produces; the screen calls it the decision brief. Once a request is captured, the AI drafts whichever of these fields the text supports: problem, desired outcome, why now, a suggested owner, the likely affected parties and an early scope, in and out. The Shape screen then carries a "not yet confirmed" badge until a person confirms the shape. The AI drafts and suggests. It does not decide.

Leaving Shape is checked on the server, against a bar that is not identical to the template: a title, a problem, a desired outcome, an impact or a why now, a suggested owner for the next decision, and the unknowns, where an explicit "No material unknowns known" counts and an empty field does not. Scope and affected parties are optional there, and firm scope is set at Plan. The owner field accepts a team name; writing a person is still up to you.

The one-pager is the same demand laid out to forward: problem, outcome, scope in and out, owner, stakeholders and why now, printable to PDF. It leaves out the unknowns, the dependencies and the risks, which stay on the demand. Until Decide confirms the owner onto a delivery path, the label reads "Likely owner". Sending it is your job: there is no integration with Slack, Jira or Linear.