What Is a Project Brief?

The project brief is the shortest document in a project and frequently the most consequential, because it is where everyone agrees what the project is for before money is spent.

Quick answer: A project brief is a short document — usually a page — that states the problem a project will solve, what success looks like, the key constraints and who decides. It comes before the detailed plan and exists to get agreement on direction while changing it is still cheap.

The Project Brief, Defined

A brief captures intent: why the project exists and how you will know it worked.

Short by design

A brief is deliberately brief. A page, occasionally two. It is not the plan, the schedule or the specification.

Its brevity is the point. A one-page document gets read by every stakeholder; a fifteen-page one gets approved without being read, which defeats the purpose.

What it is for

Alignment before commitment. The brief is where a sponsor, a delivery lead and stakeholders confirm they share an understanding of the problem and the target outcome.

Disagreements surfaced at brief stage cost a conversation. The same disagreements surfaced three months into delivery cost rework.

When it gets written

At the very start, before planning begins and usually before a project is formally approved.

It often serves as the basis for the approval decision itself: here is the problem, here is what success would be, here is roughly what it will take.

What a Project Brief Contains

Section Contains Length

Lead with the problem

What is wrong or missing, and for whom 2–3 sentences Objective What the project will achieve 1 sentence Success criteria Measurable outcomes and dates 2–4 statements Scope What is included, at a high level Short list Out of scope What is explicitly excluded Short list Constraints Budget, deadline, technology, regulatory limits Short list Stakeholders Who is affected and who must be consulted Short list

Name one decision-maker

Key risks The two or three things most likely

Keep it to a page

2–3 lines

Brief Compared With Related Documents

Document Purpose When Length

Common Project Brief Mistakes

Agree the problem and target outcome Before planning One page Project charter Formally authorise the project and sponsor At approval One to three pages Project plan Describe how it will be delivered After approval Two pages plus schedule Creative brief Direct creative work Before creative production One page Statement of work Define a supplier engagement At contract Several pages

In smaller organisations the brief and charter are frequently the same document.

Writing a Brief People Read

Start from the problem, name one person who decides, and stop at a page.

Lead with the problem The most useful sentence in a brief describes the problem — what is not working, for whom, and what it costs.

Starting with the problem keeps options open. A brief that opens with a solution has already made the most important decision without discussing it.

Name one decision-maker One person, not a committee, who has authority to approve and to resolve disagreements.

Briefs that name a group as the decision-maker produce projects where decisions stall, because nobody in a group takes responsibility for the hard calls.

Keep it to a page If it does not fit on a page, the thinking is not finished yet. Cut until only the essential remains.

Detail belongs in the plan. Once the brief is agreed, keeping it attached to the project itself — Taskzin keeps docs linked to the work they describe — means people can refer back to the original intent when scope questions arise, rather than hunting for it in a shared drive.

Common Project Brief Mistakes Solution-first framing, unmeasurable success, and briefs written retroactively.

Describing the solution, not the problem

"Build a new customer portal" is a solution. "Customers cannot see their order status without calling us, generating 400 calls a week" is a problem.

The problem framing allows the team to discover that a portal might not be the best answer. The solution framing does not.

Success that cannot be measured

"Improve customer experience" cannot be assessed at the end, so the project never formally succeeds or fails.

Every success criterion needs a number and a date. If a stakeholder resists that, the real disagreement is about what the project is for, and better to have it now.

Writing it after the work starts

A brief written once delivery is underway documents decisions already made rather than informing them.

It becomes a formality, and the alignment it was meant to produce never happens.