Every project that went sideways has the same autopsy. The client expected one thing, the team built another, and the words "I thought we agreed" appear somewhere in the final email thread.
The disagreement was there from day one. Nobody wrote down what the project was supposed to achieve, so everyone carried their own version in their head, and the versions only collided once the work was half done. Undoing that costs weeks. Preventing it costs half an hour.
That is what a project brief is for, and knowing how to write a project brief is one of the highest-return skills in a small business. Not a forty-page scope document. One page that states what you are doing, why, for whom, by when, and for how much. This guide gives you the seven questions to answer, a worked example, and a way to get it done in 30 minutes.
What a project brief is, and what it is not
A project brief is a short document, usually one page, that everyone touching the project agrees to before work starts. It is the reference you point to when scope starts to wander in week three.
It is not a proposal, which is a sales document written to win work. It is not a project plan, which breaks the work into tasks and dates. The brief comes before both and stays shorter than either. If the brief is right, the plan almost writes itself.
The test of a good brief: could someone who has never heard of this project read it in three minutes and correctly say what done looks like?
The 7 questions every project brief answers
Answer these in order, one short section each.
1. What is the project, in one sentence? If you cannot say it in a sentence, the project is not defined yet. "Redesign the Fenwick Cafe website so customers can order online."
2. Why now? The problem or opportunity behind the project. This is what keeps decisions sensible later, because every trade-off gets judged against the reason the project exists.
3. What does done look like? Two to four concrete outcomes you could check off. "Customers can place and pay for an order from a phone" is checkable. "Improve the digital experience" is not.
4. What is out of scope? The two or three things people might reasonably assume are included but are not. This section prevents more arguments than every other section combined.
5. Who is involved? The decision maker on each side, by name, plus who does the work. One decision maker per side. If sign-off requires a committee, the brief should say so now, not surprise you at delivery.
6. When and how much? The deadline, the budget, and any dates that cannot move. If either is a range, write the range. Vague numbers here become disputes later.
7. What could go wrong? The one or two risks you already suspect, and what you will do if they happen. You are not predicting the future, just proving you have thought past the kickoff.
The fastest way to write one is to fill in a structure that already exists:
A worked example
Here are the seven questions answered for a small, real-shaped project.
Project brief: Fenwick Cafe online ordering
The project: Redesign the Fenwick Cafe website so customers can order and pay online.
Why now: Phone orders eat about two staff hours a day and mistakes are common at lunch. Online ordering frees staff and cuts errors.
Done means:
- Customers can place and pay for an order from a phone in under two minutes.
- Orders print automatically in the kitchen.
- The menu can be updated by cafe staff without calling us.
Out of scope: Delivery integration, loyalty program, new brand or logo work.
People: Decision maker at Fenwick: Rosa (owner). Decision maker on our side: Alex. Build: Sam.
When and how much: Live by 1 August. Budget $9,500 fixed. Menu photos must come from Fenwick by 20 June.
Risks: If menu photos arrive late, launch slips a week per week of delay. If the payment provider rejects the application, we fall back to the provider Rosa already uses in store.
One page, three minutes to read, and every future "I thought we agreed" already has an answer.
The 30-minute method
You do not need a workshop to produce this. You need a timer.
- Minutes 0 to 10: draft answers to all seven questions. Write fast and rough, using what you already know from the sales conversation or the internal discussion that spawned the project. Gaps are fine, mark them.
- Minutes 10 to 20: fill the gaps. Each unanswered question goes to the one person who can answer it, usually the client or the decision maker. Short questions get fast answers: "Is delivery in scope, yes or no?"
- Minutes 20 to 30: tighten and send. Cut every sentence that does not answer one of the seven questions. Then send the brief to everyone named in it, asking one thing: "Reply if anything here is wrong."
Silence is not sign-off, so chase the decision makers until they reply. A brief nobody confirmed is just a memo.
Where the brief lives after kickoff
A brief that gets written, agreed, and then buried in an email attachment has done half its job. Its real value shows up in week three, when someone asks for "one small addition" and you need the out-of-scope list in front of you within a minute.
Keep the brief in the shared space where the project's other documents live, next to the meeting notes, the quotes, and the client files, so anyone on the team can check what was agreed without asking around. Project briefs, like the rest of your team's working knowledge, only pay off when people can actually find them. In Penno, a space holds the brief alongside everything else about the project, and when someone asks "was delivery in scope for Fenwick?", the answer comes from the brief itself, with the source shown.
Common mistakes to avoid
- Writing the plan instead of the brief. Task lists and timelines come later. The brief settles what and why before anyone argues about how.
- Skipping the out-of-scope section. This is the section that saves you. Assumptions that are never written down are the ones that cost money.
- Vague success criteria. If done cannot be checked, done will be debated.
- No named decision maker. "The client will approve it" fails the moment two people at the client disagree.
- Treating the brief as sacred. When scope genuinely changes, update the brief and re-confirm it. An outdated brief is as dangerous as no brief.
Frequently asked questions
How long should a project brief be?
One page for most small business projects, two at the outside. Past that, you are writing a project plan or a proposal and calling it a brief. Length is not rigor. Agreement is rigor.
What is the difference between a project brief and a proposal?
A proposal is written to win work and argues for an approach and a price. A brief is written after the decision to proceed and records what everyone has agreed. Many teams turn the winning proposal into the brief by stripping the sales content and adding the out-of-scope list.
Who should write the project brief?
Whoever leads the project writes it, but the decision makers on both sides must confirm it. The writing takes 30 minutes. The confirmation is what makes it worth anything.
Do internal projects need a brief?
Yes, and they are the projects that need one most. Client projects at least have a contract. Internal projects drift for months precisely because nobody wrote down what done looks like or who decides.
Ready to brief your next project properly? Start from the project brief template and have it agreed before the day is out.
