Project Brief Template: Scope, Deliverables, Deadlines + Example

A project brief explains why a project exists, what it will deliver, who is responsible, and which limits the work must respect. For freelancers and small teams, it should be short enough to read before starting and specific enough to resolve an ordinary scope question.

Use the template below to get the essential decisions in one place. Then turn the agreed deliverables into dated tasks, keeping the brief available as the reference for the work.

Copy-paste project brief template

Replace the prompts with your answers. Mark unresolved points as open questions, each with a person responsible for answering and a decision date.

1. Project details

• Project name:
• Client or internal team:
• Brief owner:
• Final decision-maker:
• Current version and date:
• Status: Draft / awaiting confirmation / agreed / revised
• Target start:
• Target delivery:

2. Background and problem

What is happening now?

[Describe the current situation in a few sentences.]

What problem should this project solve?

[Name the specific problem and who experiences it.]

Why does it matter now?

[Explain the deadline, opportunity, or operational reason for doing the work.]

3. Goal and intended audience

• Primary goal:
• Who the work is for:
• What those people should be able to do afterward:
• How we will evaluate the result:
• When we will review that result:

4. Scope

Included work:

• [Included item]
• [Included item]
• [Included item]

Excluded work:

• [Excluded item]
• [Excluded item]

Assumptions the plan depends on:

• [Assumption]
• [Assumption]

5. Deliverables and completion criteria

For each deliverable, record:

• Deliverable name:
• What will be handed over:
• Format or location:
• Person responsible:
• Reviewer:
• Due date:
• What must be true for it to count as complete:

6. Milestones and dependencies

• Required inputs and who provides them:
• Input deadlines:
• First review milestone:
• Feedback deadline:
• Final review milestone:
• Delivery or release date:
• What happens to the schedule if an input is late:

7. Budget and capacity

• Agreed budget or budget limit:
• Work basis: Fixed scope / hourly / internal time allocation
• Available time or team capacity:
• Tools or external costs included:
• Costs needing separate confirmation:

8. Feedback and approval

• Who gathers feedback:
• Who provides the final decision:
• How feedback will be delivered:
• Review rounds included in this plan:
• Where decisions will be recorded:

9. Risks and open questions

For each unresolved item, record:

• Question or risk:
• Effect on the work:
• Person responsible:
• Answer or decision needed by:

10. Changes after agreement

• Where new requests are recorded:
• Who assesses the effect on scope, time, and cost:
• Who decides whether the change proceeds:
• Where the revised brief and decision will be kept:

11. Confirmation

• Brief confirmed by:
• Version confirmed:
• Date:
• Remaining conditions or unresolved points:

What makes a project brief useful?

A useful brief gives people enough information to begin work without filling the gaps with their own assumptions.

It should help answer four practical questions:

1. Are we solving the right problem?
2. Is this request included?
3. What counts as finished?
4. Who makes the next decision?

If the document cannot answer those questions, adding more background will not necessarily improve it. Look for missing decisions first.

For example, “refresh the website” leaves the scope open. “Refresh the homepage using the existing site structure, with approved copy and no changes to checkout” sets a clearer boundary.

How to complete the important sections

Separate the problem from the requested solution

A client may ask for a redesign because visitors keep asking what the business does. The redesign is the proposed work; the unclear offer is the problem.

Recording both helps you assess decisions during the project. A visual change may look better while leaving the original problem untouched.

Write the goal in language the client and delivery team can both use. For example: “Make the main service and inquiry path clear on the homepage.”

Make deliverables observable

“Improve onboarding” describes an ambition. “Deliver a welcome email, a getting-started page, and a three-step setup checklist” identifies outputs someone can review.

For each output, add a completion condition. A form might be complete when a visitor can submit it and the agreed inbox receives the details. A report might be complete when it covers the agreed period and answers the specified questions.

Keep the delivery checks separate from longer-term business outcomes. A working inquiry form can be verified at handover. Whether it produces more qualified inquiries requires observation after launch.

State what is excluded

Exclusions are useful when a related request could reasonably be mistaken for part of the work.

For a homepage project, that might include additional pages, a new booking system, or rewriting the entire site’s copy. For a reporting project, it might include cleaning historical data outside the agreed period.

Use specific boundaries that reflect the conversation. An enormous list of irrelevant exclusions makes the brief harder to read.

Give inputs and feedback their own dates

A delivery date depends on more than production time. The team may need copy, access, source files, or a decision before the next step can begin.

Name who provides each input and when it is needed. Then describe how you will revisit the schedule if it arrives late.

Avoid treating delayed feedback as something the delivery team can automatically absorb. Review the remaining work before confirming a replacement date.

Filled project brief example

This example is fictional. The business, people, budget, and schedule illustrate how to complete the template; they are not reported client results or a pricing recommendation.

Project details

• Project: Northline Studio homepage refresh.
• Client: Northline Studio, a small interior design business.
• Brief owner: Alex, freelance web designer.
• Final decision-maker: Maya, studio owner.
• Version: 1.0, confirmed before work begins.
• Delivery window: Three working weeks, subject to the input dates below.

Background, goal, and audience

The current homepage shows completed projects but does not clearly explain which services the studio offers or how a potential client should inquire.

The primary audience is homeowners considering a residential interior design project.

The goal is to make the service, relevant examples, and inquiry path clear. At delivery, the team will verify that those elements are present and functional. Four weeks after launch, Maya will review the inquiries received and any recurring questions about the service.

Included scope

• Redesign and build the existing homepage.
• Add the approved service explanation and six supplied project images.
• Connect the homepage inquiry button to the existing contact form.
• Check the page on desktop and mobile.
• Provide a short handover note explaining how to update its content.

Excluded scope

• New service or portfolio pages.
• A booking or payment integration.
• Rewriting the rest of the website.
• A broader search optimization campaign.

Deliverables and completion criteria

Inputs and schedule

• Week 1, Monday: Maya provides final service copy, six images, and site access.
• Week 1, Thursday: Alex provides the homepage design.
• Week 1, Friday: Maya returns one consolidated design review.
• Week 2: Alex implements the agreed design.
• Week 3, Monday: Maya reviews the built page.
• Week 3, Tuesday: Maya returns one consolidated list of corrections against the approved design.
• Week 3, Thursday: Alex completes corrections and functional checks.
• Week 3, Friday: Final confirmation, publication, and handover.

If required inputs or feedback arrive late, Alex and Maya review the remaining work and confirm a revised delivery date before making a new commitment.

Budget, reviews, and open questions

• Illustrative budget: $2,400 for the defined scope.
• External costs: New subscriptions or paid assets require separate confirmation.
• Reviews: One consolidated design review and one built-page correction review.
• Feedback owner: Maya gathers feedback and provides the final decision.
• Open question: Which inbox should receive inquiry notifications? Maya confirms by the end of week one.

Changes after agreement

New requests are recorded separately from the approved deliverables. Alex assesses the effect on the schedule and budget; Maya decides whether to proceed. Any accepted change is reflected in a new brief version and updated tasks.

Turn the brief into a working plan

The brief defines the work. The plan organizes how to deliver it.

Take each deliverable and break it into actions small enough to schedule and review. For the fictional homepage project, “Build homepage” might become:

• Confirm receipt of the approved copy and images.
• Create the page sections from the approved layout.
• Add the service explanation and project images.
• Connect and test the inquiry path.
• Check the page in the agreed browsers and screen sizes.
• Prepare the client review version.
• Apply the agreed corrections.
• Prepare the handover instructions.

Keep the relationship to the brief visible. If a task does not support a deliverable, a completion check, or a necessary preparation step, ask why it is in the plan.

Also give client inputs and review decisions their own tasks. “Waiting for feedback” is a state; “Ask Maya for the consolidated review on Friday” is an action.

Want to put the agreed work on actual dates? Use SelfManager.ai to keep the brief, tasks, and decisions together. Its seven-day trial includes every feature and requires no credit card.

How to manage a project brief in SelfManager.ai

Keep one clearly identified reference

Create a project table and put the short brief in its notes, or upload the agreed document to its Docs section. SelfManager supports documents including PDF and Word files, up to 50 MB each.

Label the current version clearly. If a new brief replaces an earlier one, record what changed and when the replacement was agreed.

For an actively co-edited brief, keep the live source in the document tool you use and reference it from your work. An uploaded copy can preserve the agreed version, but it does not become a collaborative document editor.

Use AI to identify actions and gaps

SelfManager’s table AI can work with the table’s tasks and notes, and with documents when you include Docs.

Try this prompt:

Review this project brief and the tasks already listed. Identify the deliverables, required inputs, review milestones, and completion checks. Suggest missing tasks separately. List unanswered questions. Do not invent a budget, deadline, owner, or client approval. Distinguish what the brief explicitly says from your recommendations.

Check the answer against the brief. An inferred task can be useful without becoming part of the agreed scope automatically.

Place the work on its dates

Use dated tables for the days on which preparation, delivery, and review should happen. Write responsibility clearly in the task or notes, especially when different people provide inputs.

AI Plan can draft a schedule for up to thirty-one days and provides an editable preview before approval. Supply the confirmed dates, available capacity, and dependencies from the brief, then review the proposed order and workload.

For a longer project, plan the next practical period in detail and retain the later milestones in the brief. Revisit them as the work becomes clearer.

Keep decisions and progress connected

Use comments to record clarification, feedback, and changes. Share the relevant tables when a client or teammate needs to participate.

At review time, compare completed and open tasks with the agreed deliverables. AI Review can summarize the recorded work; verify its interpretation against the current brief before using it as a client update.

SelfManager Team costs $30 per month, or $300 per year with annual billing, with unlimited free collaborators. Pricing checked October 2026.

It suits small teams that want dated execution and a record of decisions. If the project requires formal dependency management, resource allocation, or specialized approval controls, include those needs when selecting the planning tool.

A final check before work begins

Read the brief from the perspective of someone who was not on the planning call.

• Can they explain the problem and intended audience?
• Can they identify the deliverables and exclusions?
• Do they know what counts as complete?
• Are the input dates and review responsibilities clear?
• Can they tell what remains undecided?
• Do they know where to record a proposed change?

You do not need perfect certainty before starting. You do need to separate confirmed decisions from assumptions and give important unanswered questions a path to resolution.

Keep the brief available during delivery. Its value comes from using it when a task, request, or deadline needs clarification.

Start SelfManager’s seven-day trial and turn your next project brief into dated work. Keep the reference document, next actions, and decisions connected from the first review through handover.

Frequently asked questions

What should a project brief include?

Include the background, goal, audience, scope, deliverables, completion criteria, responsibilities, milestones, required inputs, budget constraints, and open questions. Record who confirms the brief and how changes will be handled.

How long should a project brief be?

Use the shortest document that makes the important decisions clear. A small, well-defined project may fit on one or two pages. Add detail where it prevents a real misunderstanding, and reference longer supporting specifications rather than duplicating everything.

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

A project brief defines the intended outcome, boundaries, and key decisions. A project plan turns that definition into tasks, dates, responsibilities, and an execution sequence. Keep both aligned when scope or timing changes.

Who writes and approves the project brief?

Name one person to maintain the brief, with input from the people requesting and delivering the work. Identify the final decision-maker explicitly. For a client project, record which version the client and delivery lead have confirmed.

Can AI write a project brief from client notes?

Yes. AI can organize notes into a draft and identify missing information. Ask it to distinguish confirmed facts, assumptions, and open questions. Review the scope, budget, dates, and responsibilities with the relevant people before treating the draft as agreed.