How to Write a One-Page Project Brief (Template and Example)

What a project brief is, and what it is not

A project brief is the reference point you return to whenever someone asks “is this part of the project?” or “why are we doing this?” For small teams, one page is the right length: long enough to remove ambiguity, short enough that people read it and come back to it. It is not a plan. It does not list tasks or detailed dates; those belong in your work breakdown and schedule, which a good brief makes much easier to build.

Write the brief before detailed planning starts. A brief written after work has begun tends to document decisions that were never discussed, which defeats the purpose. If your team writes only one project document, make it this one. It takes an hour or two, and it can save weeks of rework when two stakeholders turn out to have different pictures of the result.

The eight sections

Each section answers a question that someone will eventually ask. Keep every section to a few lines; if one grows longer, the detail probably belongs in a separate document that the brief links to. Write in plain language without team jargon, because finance, leadership or a client may read it too. Put the version number and the date it was agreed at the top, along with the target end date and any fixed milestones, such as a trade show or a contract deadline.

• Background: why this project, and why now, in two or three sentences
• Outcome: the change the project should cause, in one sentence
• Deliverables: what the team will produce to achieve the outcome
• Out of scope: things someone could reasonably assume are included but are not
• Success criteria: three to five specific, measurable, time-bound checks
• Constraints: fixed dates, budget, technology and people
• Roles: the sponsor, the project lead and who approves each deliverable
• Risks and assumptions: what could go wrong, and what you are taking on trust

Outcome, scope and success criteria

These three sections do most of the work, and they are where vague briefs fail. Start with the outcome, not the output. The output is what the team produces, such as a new booking page; the outcome is the change it should cause, such as fewer phone calls to reception. Then write the out-of-scope list, aiming for at least three items. “Mobile app” or “migrating old records” are typical entries that settle an argument before it starts.

Success criteria turn the outcome into something you can check. Include three kinds: outcome criteria for the business result, delivery criteria for deadline and budget, and quality criteria for what a deliverable must meet to be accepted. “At least 40 percent of bookings made online in the eight weeks after launch” can be checked; “a smoother booking experience” cannot. Choose criteria the team can influence, and name who will measure each one and when.

A template you can copy

Copy this into a shared document and replace each bracketed prompt. Delete prompts that do not apply rather than writing “N/A”, and keep the result to one page at a normal font size. If you cannot fill a prompt, such as the approver, that gap is worth resolving before work starts, not after.

A worked example

Here is a completed brief for a fictional six-person physiotherapy clinic replacing phone-only booking with online booking. Notice that the out-of-scope list names the things people would most likely assume, that every success criterion has a number and a time frame, and that the one big assumption has an owner and a date by which it will be checked.

Get it challenged, then agreed

Treat the draft as something to be challenged, not simply approved. Share it with the sponsor and two or three key stakeholders, and ask each the same three questions: what is missing, what would make this project a failure in your eyes, and which constraint is least flexible? The second question is often the most revealing, because it surfaces expectations nobody wrote down. Then book a 30-minute meeting to resolve disagreements instead of collecting comments indefinitely.

Once the brief is agreed, record the version and date at the top, store it where the whole team can find it, and link to it from your task board and status reports. When scope changes later, update the brief deliberately and raise the version number, rather than letting additions creep in through conversations nobody recorded.

Common mistakes and a one-minute test

Three mistakes are especially common. Treating assumptions as facts: “the client will supply content by week two” is an assumption, and listing it as one means it gets checked early. Leaving out the approver, so nobody knows who can declare a deliverable finished. And defining the solution before the problem, which locks the team into one approach too soon. As a final test, hand the brief to someone who attended none of the meetings and ask them to explain the project back to you in one minute.

The Project Management for Small Teams course starts from this brief and builds the rest of a lightweight system around it: a work breakdown with range-based estimates, a milestone plan, a RACI chart for ownership, weekly check-ins and status reports, and a simple process for risks and change requests, so the agreements in the brief hold up once work is under way.