How to Write a Project Brief That Actually Gets Work Started

Projects fail for many reasons, but a disproportionate number of them fail because nobody wrote down what the project was actually supposed to accomplish. Or they wrote it down in a way that was vague enough that three people read it and reached three different conclusions.

A project brief isn't bureaucracy. It's the insurance policy that prevents you from building the wrong thing, discovering the scope three weeks in, or shipping something the client never asked for.

The Cost of a Bad Brief

Bad briefs produce a specific cascade: work starts before the goal is clear, decisions get made individually rather than collectively, assumptions harden into implementation, and the discrepancy between what was built and what was wanted surfaces at review. At that point, the cost of correction is enormous compared to the cost of 90 minutes of upfront clarity.

The brief also solves a subtler problem: alignment. When five people read the same brief and execute independently, they make judgment calls along the way. Without a brief, those judgment calls are anchored to guesswork. With a good brief, they're anchored to the stated goal and constraints, which means independent decisions converge rather than diverge.

What Belongs in a Project Brief

1. Goal — one sentence

What is this project trying to accomplish? Not what will be built — what outcome will the work create?

Bad goal: "Redesign the customer dashboard."

Good goal: "Reduce customer time-to-first-insight from the current 4 minutes to under 90 seconds by improving the dashboard's information hierarchy."

The good version gives you a way to evaluate whether decisions made during the project are moving toward the goal. The bad version doesn't.

2. Scope — what's in and what's out

Explicitly define both. "What's in" is expected. "What's out" is the discipline most teams skip. Explicitly stating what is out of scope for this project prevents scope creep more reliably than any other practice.

If you're not sure what to put in the "out of scope" section, ask: what adjacent things might a team member reasonably assume are part of this project? List those, evaluate each, and explicitly mark the ones that are not.

3. Stakeholders — who decides what

List everyone who has a stake in this project and their role:

• Sponsor: the person who owns the outcome and can authorize scope changes
• Lead: the person responsible for day-to-day execution
• Contributors: who is doing the work
• Reviewers: who has approval authority at each stage
• Informed: who gets notified without decision-making authority

The most painful project confusion comes from unclarity about who can approve changes and who needs to be consulted. This section resolves that upfront.

4. Constraints — time, budget, technical limits

What are the fixed parameters? Hard deadline. Budget ceiling. Technical infrastructure that can't change. Regulatory requirements. Team capacity limits.

Constraints aren't optional information — they're inputs to every decision made during the project. A team that doesn't know the hard deadline will make different tradeoffs than a team that does.

5. Definition of done

This is the section most briefs omit. What exactly does "complete" mean for this project?

For a software project: "Feature is live in production, has passed UAT, documentation is updated, and the ops runbook has been reviewed."

For a marketing project: "Campaign assets are approved by legal, uploaded to the campaign platform, go-live date confirmed, and post-launch tracking is in place."

Without a clear definition of done, projects have a tendency to linger. There's always one more revision, one more review, one more tweak. A specific definition of done creates a clean endpoint.

What Doesn't Belong in a Brief

A project brief is not a specification. It doesn't define how the work will be done, what technology will be used, or the detailed task breakdown. That comes later, in the project plan.

A brief should be readable in five minutes. If yours takes twenty minutes to read, it's too long. Move detailed specifications into separate appendices or linked documents.

A brief is also not a project status report. Once work starts, status lives in your project management system, not the brief. The brief should remain stable — a reference for "what are we doing and why" — not a living document that updates every week.

Template

Here's a minimal template you can use directly:

Project Brief: [Name]
Owner: [Name]
Date: [Date]
Target completion: [Date]

GOAL
[One sentence: what outcome does this create?]

SCOPE
In scope:
- [item]
- [item]

Out of scope:
- [item]
- [item]

STAKEHOLDERS
Sponsor: [name] — authorizes scope changes
Lead: [name] — accountable for delivery
Contributors: [names] — doing the work
Reviewers: [names + what they approve]
Informed: [names]

CONSTRAINTS
[Time, budget, technical, regulatory — whatever applies]

DEFINITION OF DONE
[Specific, verifiable criteria for "complete"]

This takes 20-30 minutes to write for most projects. It saves hours of confusion downstream.

How the Brief Connects to Task Work

Once the brief is written, it becomes the reference point for the project plan and task descriptions. When someone writes a task, the "why" of the task should be traceable to a line in the brief. This creates alignment at the task level — not just at the project level.

For guidance on writing tasks that reflect this clarity, see how to write a good task description.

A brief also anchors the project setup in your PM tool. The goal statement becomes the project description. The definition of done becomes the criteria for your final milestone. The constraints translate to due dates and budget fields.

The Brief Review Before Kickoff

Before work starts, review the brief as a team. Not a long meeting — 30 minutes max. Cover:

1. Does everyone understand the goal and agree with it?
2. Are there scoping assumptions that need to be surfaced?
3. Are there ambiguities in the constraints or definition of done?
4. Do the right people have review authority, or are there missing approvers?

Questions that arise here are cheap. The same questions raised mid-project are expensive.

A team that makes brief review a standard practice for every project will have fewer mid-project surprises, faster execution, and cleaner handoffs than a team that skips it. The brief is the work before the work — and it's always worth doing.

Ready to Put This Into Practice?

Use the template above for your next project. It takes less time to write than the first round of corrections it prevents.

Start free →