Home · Templates · Project brief
Project brief template
A free, editable Word template for the document that comes before the project — enough definition for someone to say yes or no, and no more. The hardest part of a brief is knowing when to stop writing it.
Project brief template — Word (.docx)
Ten guided sections, scope in/out and constraints tables, outline business case, roles, and a tolerance table with escalation routes. No email wall.
What a brief is for — and what it isn't
A project brief exists to support one decision: should we start this at all?
That is a much lower bar than "how will we run it", and confusing the two is the most common mistake people make with briefs. Spend three weeks producing a beautifully detailed brief and you have not been thorough — you have done initiation work on a project nobody has yet agreed to fund. If the answer turns out to be no, that work is simply gone.
The brief is deliberately, unapologetically thin. Its successor, the PID, is where the detail belongs — written after someone has committed.
The sufficiency test. Not "is this comprehensive?" but: could a reasonable person say yes or no to this, and would they know what they were saying yes or no to? When the answer is yes, the brief is finished. Anything you add after that point is being written for your own comfort, not for the decision.
What goes in it
Background — the problem, not the solution
Start with what is wrong today, in the words of the person it is wrong for. If your background section is really a description of the thing you want to build, you have skipped the step where somebody agrees there is a problem worth paying to solve.
Objectives — what "done" looks like
Two or three, testable. "Modernise the website" is not an objective; nobody can tell you whether it happened. "Customers can reserve a book online for collection, and stock shown online matches the shelf within one hour" — that, somebody can confirm or deny.
Scope: in, and pointedly out
The in-scope list is easy and does very little work. The out-of-scope list is the one that saves you. An in-scope list is a wish; an out-of-scope list is a decision someone has signed.
| In scope | Explicitly out of scope |
|---|---|
| New public website, online reservations, stock display, events listing. | Card payments online (collection and pay in store only). Migration of historical customer accounts. Stock system replacement — the existing one stays. |
Write down anything a reader might reasonably assume is included. Every line in that right-hand column is an argument you are not going to have in month three.
Constraints and assumptions
Constraints are the walls: the date, the budget, the system you are not allowed to touch. Assumptions are the things you are proceeding as if true without having checked — and each one is a risk in a coat. "We assume the supplier can export the stock data" is fine to write; just notice that if it is wrong, the project changes shape entirely, and put it on the risk register accordingly.
Outline business case
A paragraph and a number, not a full appraisal. Why is this worth doing, roughly what will it cost, roughly what comes back? The full version — options, baselined benefits, dis-benefits — is the business case, and it belongs at initiation, once you are committed enough to justify the effort.
Roles
Who has final say (and controls the money), who speaks for the people who will use the thing, who is building it, who is running it day to day. Names, not job titles. If you cannot fill in who has final say, that is not a formatting gap — it is the reason the project will stall later, and you have found it early.
Known risks
The three or four that could change the decision. Not a full register — just the ones a board member would want to know about before saying yes. A brief with no risks reads as naivety, and it is the section that most quickly tells an experienced reader how much you have actually thought.
Common mistakes
- Writing a PID by accident. If your brief has a detailed stage plan and a communication matrix, stop — you are doing initiation work on an unapproved project.
- No out-of-scope section. The single cheapest omission to fix and the most expensive to leave.
- Objectives you cannot test. "Improve", "streamline", "modernise" — nobody can ever confirm these happened, which means the project can never be declared successfully finished.
- Solution first. The brief describes the app you already decided to build, and the problem is reverse-engineered to fit. Boards can smell this.
- No named executive. Nobody owns the money, so nobody can make the decision the brief exists to support.
Skip the blank page
Writing the brief is the bit people put off — so hand Guddle a few plain-English paragraphs about what you want to do, and it will draft the whole thing back: stages with dates and budgets, a scored risk register, starter tasks, the roles and the business case. You review, edit and approve every line before anything is created. AI does the admin; you keep the governance.
Start free — first project on usThe other templates
Common questions
How long should a project brief be?
Two to four pages is normal; one page can be plenty on a small project. Length is not the test — sufficiency is.
Who writes it, and who approves it?
Usually the person who will run the project, working with whoever is asking for it. Approval matters more than authorship: the person paying has to recognise their own problem in it. If they don't, the project has been misdefined before it has begun.
Is this an official PRINCE2 template?
No. It is an independent template written from scratch, aligned with the method's approach to starting up a project. It is not affiliated with, endorsed by, or copied from PeopleCert or AXELOS materials.