How to Write a One-Page Project Brief Before Work Starts

Most project trouble starts before the project does. Two people have different pictures of what “the new reporting dashboard” means, nobody wrote down what was out of scope, and three weeks in someone asks who is actually deciding. A one-page project brief is the cheapest way to catch these disagreements while they are still conversations instead of rework.

It is not a project plan. It does not list tasks or dates in detail. It answers the questions that, if left open, will cost you the most later.

Use Seven Short Sections

A brief that fits on one page tends to get read. These sections cover what matters:

1. Problem. What is wrong today, for whom, and how you know.
2. Goal. What will be true when the project succeeds, ideally measurable.
3. Scope. What is included.
4. Out of scope. What is explicitly not included.
5. Owner and decision maker. Who runs it, and who settles disagreements.
6. Constraints. Budget, deadline, dependencies, technical limits.
7. Definition of done. How everyone will agree the project is finished.

Atlassian’s Team Playbook has workshop formats, such as a project poster, built on many of the same questions, if you want to fill the brief in together.

State The Problem Before The Solution

Briefs often begin with the solution: “Build a reporting dashboard for account managers.” That skips the question that justifies the work.

Before:

Project: New reporting dashboard. We need a dashboard so account managers can see client data in one place.

After:

Problem: Account managers spend about three hours each Monday assembling client reports from four systems, and two clients flagged errors in October reports. Goal: Weekly client reports take under 30 minutes to prepare and contain no manual copy steps.

With the problem written down, the team can ask whether a dashboard is the best fix, or whether an automated export would do the job in a third of the time.

Write The Out Of Scope List Deliberately

The out of scope section is where a brief earns its keep. List the things people will reasonably assume are included:

• Historical data before January 2025.
• Client-facing access to the dashboard.
• Changes to how data is entered in the CRM.

Each line prevents a future argument. When a request arrives mid-project that falls outside the brief, you can point to it, and if it truly needs to be added, write a short scope change message rather than absorbing it silently.

Name One Decision Maker

“The team will decide” is not a decision process. Name the person who settles disagreements about scope and priority. It can be the owner or a sponsor, but it must be one person. If that person is senior and busy, agree how to reach them for decisions, for example a weekly slot or a decision request email.

Get Sign Off, Then Link It Everywhere

Share the draft with the people who will do the work and the people who will receive it. Ask one question: “Is anything here wrong or missing?” Revise once, then mark it agreed with a date. Link the brief from the kickoff invite, the project board, and the team channel so new joiners find it. A project kickoff email is a natural place to share the final version.

A Context For Project Briefs

A Wrivio Context for project briefs could say:

Rewrite these notes as a one-page project brief with these headings: Problem, Goal, Scope, Out Of Scope, Owner And Decision Maker, Constraints, Definition Of Done. Use plain, specific language. Keep every name, number, date, system, and budget figure exactly as written. Where a section has no information in the notes, write “To be decided” instead of inventing content.

Press Ctrl+Shift+Space, paste your rough notes, and look at the “To be decided” lines in the result. Those are the open questions to resolve before kickoff, and they are usually the most valuable output of the exercise.

Common Questions

What is the difference between a project brief and a project plan?

A brief defines the problem, goal, scope, owner, and definition of done before work starts. A plan breaks the work into tasks, dates, and assignments once the brief is agreed.

How long should a project brief be?

One page is a good limit for most projects. Longer briefs are rarely read in full, and detail usually belongs in the plan or linked documents.

Who should write the project brief?

Usually the project owner, with input from the sponsor and the people doing the work. The draft should be reviewed by both the team and the people receiving the result before it is agreed.

Why include an out of scope section?

Because it prevents the most common source of project conflict: different assumptions about what is included. Listing exclusions explicitly makes later scope changes visible and deliberate.

Download Wrivio for Windows to turn scattered kickoff notes into a clear one-page brief everyone can agree on.