Project Brief Template: Agree on the Work Before You Start

A project brief is a short agreement about the problem, the intended result, the work included, and the people who can approve it. Write it before committing to delivery. A useful brief lets the requester and the person doing the work notice different expectations while changing the plan is still cheap.

If one person expects a finished handbook and another expects a rough outline, a beautiful schedule will only organize the misunderstanding.

What should the brief contain?

Include enough information to answer three questions: why this work, what counts as finished, and who can resolve a disagreement? Leave detailed task scheduling in the project plan so the brief stays readable.

Download the editable project brief. It is a plain text document with writing prompts and the completed example below; no account is required. Open it in a text editor or paste it into your team's shared document.

These seven sections are our suggested format, not a universal standard. Your organization may require additional fields or a formal authorization document.

Atlassian's project poster guidance separates the problem, validation, and readiness to proceed. That distinction is useful here: an attractive proposed solution does not establish that the problem is understood.

Write “new employees cannot locate the current expense instructions” before writing “build a portal.” The first sentence describes a need. The second commits to one possible answer, perhaps before you know whether a simpler change would work.

What does a completed example look like?

A completed brief uses concrete nouns and observable acceptance checks. The following project is fictional; its quantities and dates illustrate a small assignment, not measured results or a recommended universal deadline.

Project: new-starter expense FAQ.

Problem and audience: new employees ask their team lead where to find expense instructions. The current welcome message links to several documents without explaining which one to use.

Intended outcome: a new starter can find the approved instructions and the correct contact without searching through the whole document collection.

Deliverable: one shared FAQ answering six questions agreed with the operations lead, plus an updated link in the welcome message.

Acceptance: every answer links to the current approved policy; the operations lead confirms accuracy; a colleague unfamiliar with the draft can locate the submission instructions and the help contact.

Included work: collect recurring questions, draft answers, request policy review, revise the FAQ, and replace the welcome-message link.

Excluded work: changing reimbursement rules, selecting expense software, translating the FAQ, or rewriting the full employee handbook.

Owner and approver: Morgan coordinates the document. Casey, the operations lead, approves policy wording and confirms who will maintain it.

Timing: a proposed two-week window, subject to Casey confirming a review slot. Publication is needed before the next cohort receives its welcome message.

Open question: the team has two competing links to the travel policy. Casey will confirm the authoritative version before Morgan drafts that answer.

Notice the acceptance check concerns usefulness and accuracy, not merely word count. A six-question document can still fail if readers cannot find the right answer.

The example also distinguishes an intended outcome from a guarantee. Publishing an FAQ does not prove that questions or interruptions decreased. That would require a later observation with a clear comparison.

How do you write it with the requester?

Draft the agreement, then ask the requester to challenge it before you promise a schedule. You are looking for disagreement about the result, not compliments about the document's formatting.

Start with these questions:

1. What happened that made this work necessary?
2. Who will use the result, and what will they do with it?
3. What would make you reject an otherwise polished delivery?
4. Which part could be removed without defeating the purpose?
5. Who can answer questions or approve changes while we work?

In the FAQ example, “make onboarding better” is too broad to guide a draft. “Help new starters find the approved expense steps” gives the writer a usable boundary.

Ask the requester to finish this sentence: “I will consider this ready when…” Then test whether their answer can be checked. “When it looks professional” needs a follow-up. “When the policy owner approves each answer and the welcome link works” is much clearer.

Atlassian's project planning template treats scope, responsibilities, timing, and deliverables as connected planning information. Use that connection to find missing commitments: a delivery date depends on an available reviewer, not just an available writer.

Share a short confirmation: “I understand this as an FAQ and a revised welcome link. A new portal and policy changes are outside this assignment. Please correct that scope before I schedule the draft.”

Once the agreement is clear, use the project kickoff agenda to coordinate the people involved. The brief is the reference document; the kickoff is the conversation that checks readiness.

What if the scope is uncertain?

Make uncertainty visible and give it an owner. A brief can contain unresolved questions, but it should not disguise them as confirmed requirements or silently assume the most convenient answer.

Separate three kinds of statement:

• Confirmed: the FAQ must link to approved policy.
• Assumed: the existing shared-document location will remain available.
• Unresolved: which of the two travel-policy links is current?

For each assumption, ask what breaks if it is wrong. If the storage location is uncertain, do not spend the whole week formatting links that may have to move. Confirm the location or choose a reversible draft format.

For each open question, record a responsible person and the point at which the answer becomes necessary. “Casey confirms the policy before the travel answer is drafted” is more useful than “policy question pending.”

The project poster method explicitly asks teams to validate what they know and identify what they still need to learn. You can apply that principle without turning a small assignment into a research program.

If the uncertainty is fundamental, agree on a discovery deliverable first. An approved list of questions and sources may be the right first result; a fully written handbook may be premature.

How do you keep the agreement useful?

Keep one current brief and record meaningful changes where everyone can find them. A document that still describes last week's scope is a source of conflicting instructions.

When someone asks for an extra deliverable, write the consequence before agreeing: “Adding translated versions changes the review work and publication date. We can keep the English FAQ date and schedule translation separately, or revise the whole delivery.”

Preserve the original commitment in the change history. Record what changed, who agreed, and what happened to timing or capacity. Do not quietly replace the date and leave the requester believing nothing slipped.

Bring the accepted work into your weekly plan. If this becomes recurring maintenance, document the repeatable steps in a standard operating procedure.

Do Only 3 Things a Day addresses the next problem: making room for the important work amid everything else. A brief defines a commitment; your daily choices determine whether that commitment receives attention.

Frequently asked questions

How long should a project brief be?

Aim for a document someone can review in one sitting. A page may be enough for a small assignment. Add detail when it resolves a real ambiguity, not simply to make the brief look substantial.

Is a brief the same as a project charter?

Not necessarily. A brief summarizes the intended work; a charter may formally authorize a project and establish authority. Terminology varies, so use your organization's required document when approval or funding depends on it.

Who should approve the brief?

The person authorized to accept the result should confirm it, with input from the people doing and depending on the work. Approval from someone without that authority may not resolve later disagreements.

Can I use a brief for personal work?

Yes. State the outcome, exclusions, and a finish test before starting. This is particularly useful when you keep enlarging a personal project because you never decided what the first useful version would include.