Project Brief Template

Why most project briefs get written once and then ignored

A brief is supposed to be the thing everyone can point to when there's a disagreement about what the project is. Most stop working for that purpose within a month, because the brief gets treated as a kickoff formality rather than a page anyone is expected to open again. It gets written to satisfy a process step, filed away, and quietly stops being the source of truth it was meant to be.

It lives in a document nobody opens again. A brief written in a slide deck or a shared doc, separate from the board where the actual work happens, gets read once at kickoff and then never again. Not because it stopped being true. Nothing points back to it, so nobody has much reason to open it a second time.

Scope is a description, not a boundary. Most briefs say what the project is about but not what it explicitly excludes, so "is this in scope" gets re-argued every few weeks instead of settled once at the start, usually in favour of whoever asked most recently.

Success criteria are a feeling, not a test. "Improve the refund process" can't be checked against anything. Nobody can say with confidence, three months in, whether the project actually succeeded, because success was never written down as something with a number attached.

Stakeholders are a list of names, not roles. Without saying who approves and who is merely informed, a decision that needs one signature ends up waiting on a meeting with everyone in it, because nobody wrote down who actually gets to say yes.

The brief and the board are in different tools. Even a well-written brief loses its usefulness if reaching it means leaving the place where the actual work is tracked. It becomes something people mean to check, not something they naturally see.

Nobody who joins later gets pointed to it. A brief written for the original team is invisible to anyone who joins in month three, so they piece together the goal and the boundaries from conversations instead of reading the one page meant to answer both.

How to use it

1. 01Write it before the board exists, or in the same sitting right after. It's meant to come first, not get backfilled once work is already underway and half-decided.
2. 02Put goal, scope and success criteria on one page, not scattered across a slide deck, an email thread and someone's meeting notes.
3. 03List stakeholders by role, not just name. Deciding who approves what at kickoff avoids a mid-project argument about it, when the answer matters far more.
4. 04Turn each in-scope item into a task straight from the sentence. The first pass at the board should come from the brief, not a separate planning session that quietly redefines the project.
5. 05Leave it alone after that. Revisit it only when scope genuinely changes, and log the change as an edit with history, not a weekly rewrite.
6. 06Point new team members at it first, before the board. The brief answers why the project exists at all, which the board, full of individual tasks, was never built to explain on its own.
7. 07Keep it to one page. A brief that grows into a ten-page document stops getting read in full, and the parts that matter most (the boundary and the test for success) end up buried under detail that belongs on the board instead.
8. 08Write the out-of-scope list even when it feels obvious. The items that seem too obvious to mention are usually the ones somebody asks about three weeks later.

That last point is the difference between this and a status report: a brief is written once and referenced, not produced on a schedule. If a brief is being edited every week, it's probably being used as a status report by mistake. The two documents answer different questions, and shouldn't be asked to do each other's job. On ShipSprint the brief lives on the wiki page next to the board it belongs to, and any sentence in it can become a task in one click, so the first pass at the board actually comes from what was agreed at kickoff, not from a fresh guess at what the project needs.