A project brief is a short, high-level document that states why a project exists, what it should achieve, what is in and out of scope, and what limits it has to work within. It is written before detailed planning starts, and it gives everyone involved the same picture of the work. This guide shows you what to put in one, how to write it in an afternoon, who should contribute, and how it differs from a project plan. It includes a template you can copy and a filled-in sample.
TL;DR
- A project brief is a one-to-two-page summary of background, objectives, scope, constraints and success measures, written so stakeholders can agree before resources are committed.
- Write it in this order: gather requirements, set boundaries, name stakeholders, draft, then get a named person to sign off.
- The brief is the summary and starting point. The project plan is the detailed, operational document that follows it.
- If you freelance, the brief is your best protection against scope creep, because it gives you a written reference to point back to.
- Copy the template below and replace every line with specifics. A brief full of generic phrases is worse than none.
Table of Contents
- What a project brief is, and what it is for
- What to include in a project brief
- How to write a project brief, step by step
- A project brief template you can copy
- A short sample: a freelance project brief
- Project brief vs. project plan vs. project charter
- Getting the brief approved
- Mistakes that weaken a brief
- Our perspective: the brief is a freelancer's first deliverable
- Build your freelance practice with the Club
- FAQ
- Sources
What a project brief is, and what it is for
Think of the brief as the project's agreement on direction. Public-sector guidance describes it as an early view of what the project should achieve. It identifies the key elements and the steps toward the objectives, establishes agreement between the senior responsible owner and the project manager or team, and enables more detailed planning. The same UK guidance says approval of the brief is the official start of the project and authorizes that more detailed planning.
A New Zealand government procurement guide takes a similar view. It treats the brief as a core document from the initial stages that formally defines the client's requirements, objectives and scope, and so becomes the foundation for delivery and for keeping stakeholders aligned.
In practice, a brief does three jobs:
- It forces clarity early. If you cannot write the objective in two sentences, the project is not ready to start.
- It earns buy-in. People approve a page they can read in five minutes. They rarely approve a forty-page plan.
- It gives you something to return to. When a request arrives in week six, you check it against the brief instead of arguing from memory.
The brief is not a pitch, and it is not a schedule. It does not say how every task will be done. That comes later.
What to include in a project brief
Professional brief-writing guidance from Wales lists the usual contents: a summary, a vision, objectives, constraints and resources, stakeholder and end-user requirements, research findings, functional and technical requirements, outputs and outcomes, and measures of success. That list comes from the built-environment field, so most business projects will use a trimmed version.
For a typical business, marketing, software or consulting project, these are the sections that earn their place:
| Section | What it answers | How long |
|---|---|---|
| Project summary | What is this, in two or three sentences? | 2 to 3 lines |
| Background | Why now? What problem or opportunity triggered it? | 1 short paragraph |
| Objectives | What will be true when the project succeeds? | 2 to 4 bullets |
| Success measures | How will we know? Which numbers or observable results? | 2 to 4 bullets |
| Scope | What is included, and what is explicitly excluded? | Two short lists |
| Deliverables | What will be handed over? | A list |
| Stakeholders | Who decides, who contributes, who is informed? | A small table |
| Timeline | Start, major milestones, target finish | 3 to 6 lines |
| Budget and resources | Money, people, tools, access | 2 to 5 lines |
| Constraints, risks, assumptions | What could block or change the work? | 3 to 6 bullets |
| Approval | Who signs off, and by when? | 1 line |
Two notes on this list.
First, the exclusions matter as much as the inclusions. "Not included: copywriting, photography, ongoing maintenance" prevents more disputes than any other line you will write.
Second, complex or innovative projects may need homework before the brief is written. The Welsh guidance notes that such projects can require research, such as reviews of precedent projects, to inform the brief. If you are entering unfamiliar territory, budget time for that before you commit to a scope.
How to write a project brief, step by step
The process comes down to gathering requirements, defining boundaries, identifying stakeholders and obtaining formal sign-off before significant resources are spent. The UK project-management guidance behind that sequence says the brief is developed by the senior responsible owner, or by a project manager using information from that owner. Here is how that works day to day.
1. Talk to the sponsor first
Book 30 to 45 minutes with whoever owns the outcome. Ask five things: what problem are we solving, what does success look like, what is the deadline and why, what is the budget range, and who else has a say. Take notes in their words. You will reuse them.
2. Write the objective before anything else
One or two sentences. Name the result, not the activity. "Launch a self-serve onboarding flow that cuts setup support tickets" is an objective. "Work on onboarding" is not.
Then attach measures. Where possible, use a number and a date: a rate, a count, a deadline. Where a number is not realistic, describe an observable result, such as "the sales team uses the new process for all new deals."
3. Draw the scope boundary
Write two lists: in scope and out of scope. If something is uncertain, put it in a third list called "to be decided," with a named owner and a date. This is also where you spot the gap between what the sponsor imagines and what the budget allows.
4. Name the stakeholders and what each one does
Use roles, not just names. Decision-maker, approver, contributor, informed. The guidance says relevant stakeholders should contribute to the brief, so show the draft to each of them before it goes to the sponsor. Surprises at the approval stage cost time.
5. Add timeline, budget and constraints
Keep it high level: start date, two to five milestones, target finish. Then list what could change the picture: a dependency on another team, a fixed launch event, limited access to users, a tool that has not been bought yet. Assumptions belong here too. "We assume content is supplied by the client by week two" is a sentence that will save you later.
6. Edit it down to one or two pages
Examples of professional briefs tend to run one to two pages in clear, accessible language, with headings for background, objectives, timeline and stakeholders, and sometimes tables for milestones or resources. If yours is longer, move the detail into the plan or an appendix. Cut jargon. A new team member should be able to read it cold and understand the project.
7. Get sign-off in writing
Send the brief to the named approver with a clear ask: "Please confirm by reply, or send changes by Friday." A written yes is enough for most projects. For larger engagements, use a formal signature step.
A project brief template you can copy
Paste this into a document, then replace every bracket with a specific.
PROJECT BRIEF
Project name: [short, plain name]
Prepared by: [name, role] Date: [date] Version: [1.0]
1. Summary
[Two or three sentences: what the project is and who it is for.]
2. Background
[Why this project, why now. The problem or opportunity.]
3. Objectives and success measures
Objective: [result you want]
Measures:
- [metric or observable result, with target and date]
- [metric or observable result, with target and date]
4. Scope
In scope:
- [item]
Out of scope:
- [item]
To be decided:
- [item, owner, decision date]
5. Deliverables
- [deliverable, format, who receives it]
6. Stakeholders
Sponsor / approver: [name]
Decision-makers: [names]
Contributors: [names]
Informed: [names]
7. Timeline
Start: [date] Key milestones: [list] Target finish: [date]
8. Budget and resources
[Budget range, team, tools, access needed]
9. Constraints, risks and assumptions
- [item]
10. Approval
Approved by: [name] Date: [date]
If you prefer a design-led layout, most document and presentation tools offer editable brief templates. The structure matters more than the tool. A plain document with the ten headings above beats a polished layout with vague content.
A short sample: a freelance project brief
Here is an invented example, shown only to illustrate the level of detail. It is a small project run by an independent project manager for a client.
Project: Customer support handbook rebuild Summary: Replace the outdated support handbook with a single searchable knowledge base that the support team maintains. Background: New hires currently learn from scattered documents, and answers differ between agents. The head of support wants one source of truth before the next hiring round. Objective: A live knowledge base covering the top 40 support topics, owned by the support team. Success measures: All 40 articles published and reviewed by the support lead; every agent trained on the process; a named owner for monthly updates. In scope: Audit of existing documents, structure, writing and editing of 40 articles, a one-hour team training session. Out of scope: Customer-facing help center redesign, translation, new tooling purchases. Stakeholders: Head of support (approver), two senior agents (contributors), operations lead (informed). Timeline: Six weeks, with the audit done by the end of week one and a draft structure agreed by the end of week two. Budget and resources: Fixed project fee agreed in the contract; two hours a week from each senior agent. Assumptions and risks: Existing documents are shared in week one; agents are available for review; no new tool is required.
Notice what makes it work: the objective is checkable, the exclusions are explicit, and each stakeholder has a role. For longer, persuasion-heavy documents, see our copyable project proposal examples. A proposal sells the work. A brief defines it.
Project brief vs. project plan vs. project charter
People mix these up constantly, so here is the clean split.
Brief vs. plan. The brief is a high-level summary for stakeholders. The plan is a detailed, operational document that explains exactly how the work will be executed. In sequence, the brief comes first to align everyone on direction, and the plan follows with task breakdowns, dependencies, resource allocation and tracking. Several project-management publishers describe it the same way, for example this explanation from a project-management software company. If a stakeholder cannot read your document in a few minutes, it is a plan, not a brief.
Brief vs. charter. Practice varies here, and the terms are used differently across methods and companies. Some organizations use a charter to approve the project and a brief afterward to summarize the key information for the team. Others, following the UK guidance cited earlier, treat approval of the brief as the project's official start. Do not argue the vocabulary. Ask the client what their approval document is called, then make sure it covers objectives, scope, constraints and who signs.
| Project brief | Project plan | |
|---|---|---|
| Purpose | Align stakeholders and get approval | Guide execution |
| Level of detail | High level | Detailed |
| Length | One to two pages | As long as the work needs |
| Written | First | After the brief is approved |
| Audience | Sponsor, stakeholders, team | Mostly the project team |
A useful way to hold the difference: the brief says what and why, and the plan says how and when in detail.
Getting the brief approved
A brief that nobody confirms is only a draft. The point of the approval step is to make shared understanding visible and to authorize the more detailed planning that follows. Three habits help.
- Name one approver. Committees stall. Ask the sponsor who has the final say and put that name on the document.
- Pre-wire the draft. Walk key contributors through it individually. Fix disagreements before the formal request.
- Record the decision. An email reply, a signature or a tracked workflow all work. If you want to see how a structured approval flow can be set up, this contract approval workflow shows a stepwise way to route documents to the right people. And when a project ends, a clean handover is the mirror image of a clean start, as this handover checklist for custom software illustrates.
After approval, store the brief where everyone can find it and put a version number on it. If scope changes, issue a new version instead of editing silently.
Mistakes that weaken a brief
Writing objectives as activities. "Redesign the website" describes work. "Increase demo requests from the site" describes a result.
Skipping exclusions. Unwritten assumptions turn into unpaid work. Our guide to five-step scope creep control shows how a clear brief makes change requests easy to handle.
Burying the reader. Long background sections hide the decision the sponsor has to make. Lead with the summary and the ask.
Copying a template without thinking. Delete sections that do not apply and add the one that does. A regulated project may need a compliance section. A creative project may need audience and tone.
Treating it as finished. A brief is a baseline. Update it, with a new version and a new sign-off, when the project's direction changes.
Forgetting the handoff into onboarding. For freelancers, the brief should feed straight into your kickoff. Our client onboarding checklist covers what to collect and confirm in the first days.
Our perspective: the brief is a freelancer's first deliverable
We work with independent project managers and consultants, and we see the same pattern. The ones who struggle with late payments, endless revisions and fuzzy expectations usually started work without a written agreement on what "done" means. The ones who thrive treat the brief as their first deliverable, not as paperwork.
A brief also changes how a client sees you. When you arrive with a one-page document that captures their goal, their limits and their stakeholders, you stop looking like a pair of hands and start looking like a partner. That is the difference between being hired for a task and being trusted with an outcome, and it is the transition many people moving from corporate roles into freelance work are trying to make.
Our advice is simple. Write the brief yourself even when the client does not ask. Keep it to two pages. Get a written yes. Then use it in every status update, so progress is always measured against what was agreed. Over time, your own brief template becomes part of how you work, and clients come to expect it.
— Ashanti
Build your freelance practice with the Club
If you are a freelance project manager or consultant, the brief is one piece of a larger craft: finding the right clients, setting terms, and delivering with confidence. The Freelance PM Club brings that together: curated job listings, expert-led courses, a template library, career coaching and a community of independent PMs. Plans on our membership page start with Job Board Access at $5 per month, with Freelancer Pro at $10 per month and Freelancer Elite at $20 per month. If you want one-to-one guidance on moving from corporate work to freelancing, take a look at our coaching. When you are ready to turn good briefs into steady work, our guide to finding freelance PM jobs lays out a two-week plan.
FAQ
What is a project brief for?
It aligns everyone on what the project is meant to achieve, within what limits, before resources are committed. It also gives the sponsor something concrete to approve. Once approved, it is the reference point for planning and for judging later change requests.
How long should a project brief be?
One to two pages is the usual target. If it runs longer, you are probably writing the plan, so move the detail into that document. A reader should be able to understand the project from the brief in a few minutes.
Who should write the project brief?
The project's sponsor, or the project manager working from the sponsor's information. Relevant stakeholders should contribute, and a named approver should sign it off. As an independent PM, you will often draft it yourself and have the client confirm it.
What are the five basics of project management?
There is no single universal list. One widely used European framework describes a project as a temporary organization with unique scope, time, cost and quality objectives, and it stresses the trade-offs between those four. A good brief states each of them, along with who is involved, so the trade-offs are discussed early.
Sources
- Guidelines for Managing Projects, UK Department for Business, Innovation and Skills
- Project brief, Construction procurement, New Zealand Government
- Introduction to Brief Writing, Design Commission for Wales
- PM² Essentials training material
- Project Briefs, Smartsheet