It summarizes the problem, goal, success measures, scope, deliverables, milestones, stakeholders, constraints, risks, and next decision. One page is a useful target for a straightforward project.
Project brief at a glance
| Section | Required answer |
|---|---|
| Background | What problem or opportunity exists now? |
| Goal | What should change, and how will success be measured? |
| Scope | What is included and explicitly excluded? |
| Deliverables | What observable outputs will exist? |
| Milestones | Which few dates matter for approval and coordination? |
| Stakeholders | Who decides, does, advises, and needs information? |
| Constraints and risks | What can limit or change the project? |
| Approval | Who authorizes the next stage, and under which conditions? |
Copyable Markdown project brief
# Project brief: [Project name]
**Sponsor or client:** [Name]
**Project owner:** [Name]
**Version:** 1.0
**Date:** YYYY-MM-DD
## Project in one sentence
[What will change, for whom, and by when?]
## Background and problem
[Current situation and why action is needed now.]
## Goal and success measures
| Goal | Measure | Baseline | Target | Date |
|---|---|---:|---:|---|
| [Goal] | [Metric] | [Value] | [Value] | YYYY-MM-DD |
## Scope
### In scope
- [Item]
### Out of scope
- [Item]
## Deliverables
| Deliverable | Owner | Acceptance condition | Due |
|---|---|---|---|
| [Thing that will exist] | [Name] | [Observable condition] | YYYY-MM-DD |
## Stakeholders and decision rights
| Person or group | Role | Decides, does, advises, or is informed |
|---|---|---|
| [Name] | [Role] | [Responsibility] |
## Budget and constraints
- [Limit, deadline, policy, tool, or dependency]
## Top risks and assumptions
| Type | Item | Impact | Owner or validation action |
|---|---|---|---|
| Risk | [Event] | [Consequence] | [Response] |
## Approval
| Role | Name | Decision | Date | Conditions |
|---|---|---|---|---|
| Sponsor | [Name] | Approved / Revise | YYYY-MM-DD | [Conditions] |
What should a project brief include?
A project brief should include only the information needed to decide whether the proposed work is sufficiently clear and worthwhile to plan in detail.
For a small project, that usually means:
- the problem or opportunity;
- one measurable goal;
- scope in and out;
- deliverables and acceptance conditions;
- the few milestones that matter;
- sponsor, owner, and decision rights;
- budget and fixed constraints;
- top risks, assumptions, and open questions;
- approval and next step.
Write the project in one sentence
Use this pattern:
Deliver [change or output] for [audience] so that [measurable result] by [date].
Example:
Replace the customer-help platform for support teams while preserving all indexed URLs and keeping launch-week 404 responses below 0.5% by 30 November.
The sentence will not replace the rest of the brief, but it reveals whether the project has a clear outcome.
Define scope with an explicit out list
An in-scope list says what the team intends to deliver. An out-of-scope list prevents reasonable but unapproved additions from entering unnoticed.
“Website redesign” is too broad. Name the pages, audiences, channels, regions, data, and integrations included or excluded.
Describe deliverables as observable outputs
“Improve onboarding” is an objective, not a deliverable.
A deliverable is something that will exist: an approved five-step flow, training guide, migrated article set, campaign package, or signed supplier agreement.
Add an acceptance condition so completion is testable.
Keep milestones few and meaningful
Milestones represent important project states or decision gates, such as brief approved, pilot complete, launch authorized, or migration verified.
Do not turn the brief into a detailed task schedule. That belongs in the project plan or task system.
Completed project brief example
## Project in one sentence
Move 120 published help articles to the new platform by 30 November, preserve every indexed URL, and keep launch-week 404 responses below 0.5%.
## Scope
### In scope
- Article migration, redirect map, pre-launch QA, and rollback plan
### Out of scope
- Rewriting article content
- New translations
## Approval condition
The sponsor approves detailed planning after the URL inventory and migration estimate are confirmed.
The example is short, but it gives an approver a measurable outcome, scope boundary, and next gate.
Project brief versus project plan
A project brief is the concise definition used to align and authorize direction.
A project plan is the maintained delivery document containing detailed milestones, work, dependencies, risks, communication, and change control.
The brief usually comes first. Once approved, its goals and boundaries should flow into the plan rather than being rewritten differently.
Project brief versus business case
A business case compares investment options, costs, benefits, risks, and expected value to decide whether an initiative should proceed.
A project brief defines the shape of the proposed work. A material investment may need a business case before the brief or alongside it.
Common project-brief mistakes
- Writing several pages of background before stating the goal.
- Using goals that cannot be measured.
- Omitting the out-of-scope list.
- Listing activities instead of deliverables.
- Treating every task date as a milestone.
- Naming many stakeholders but no sponsor or owner.
- Hiding critical assumptions.
- Writing a full project plan before the direction is approved.
Project brief FAQ
How long should a project brief be?
One page is a useful target for a straightforward project. Use links or appendices for evidence and detail. Complex projects may need more space, but the first page should still stand alone.
Who writes the project brief?
The proposed project owner normally drafts it with input from the sponsor, delivery leads, subject specialists, and affected stakeholders.
When is a project brief created?
Create it after enough discovery exists to define the problem and direction, but before detailed planning and delivery commitments consume significant effort.
Does a project brief need approval?
Yes, when it is used to authorize planning or delivery. Record the decision owner, date, conditions, and next step.
Can a project brief change?
Yes. Version it and record approved material changes. Once detailed delivery begins, manage scope through the project plan and change process.