Skip to content
Product Lifecycle Templates

Project Brief

beta  ·  Family discovery-docs  ·  Phase discover  ·  Sizes lean, full  ·  ~4,350 tokens

The document that asks a named approver for authority to start finding out whether and how to proceed, before anyone commits to building anything. Lean states the mandate, objectives, exclusions, an outline justification, constraints and the decision requested; full adds the proposed approach and names the document that takes over once this one is approved.

How to tell whether you need one, how to pick lean or full, and how to grade what comes back before it reaches an approver.

Before you start: is this the right document at all?

Section titled “Before you start: is this the right document at all?”

Write a project brief when a mandate already exists and you need to ask a named approver for authority to start finding out whether and how to proceed, before anyone commits to building anything. That request, and the decision it asks for, is the whole job. A document that tries to settle the full comparison of options, or that specifies what gets built, is not a shorter or longer project brief, it has stepped into a different document’s job.

Write something else if:

You actually need Because
a business case you need the full comparison of options, including doing nothing, and a funded recommendation. This document carries only an outline of that case and names the later document and decision point where the full comparison happens
a project charter or a project initiation document (PID) the decision to proceed has already been made and you need the detailed plan, governance and risk register that runs alongside delivery. This library’s own position treats the brief’s approval as authorizing initiation-stage work, not delivery, and neither a charter nor a PID is built here
a product brief you are scoping a single product opportunity, not asking whether a whole initiative or project should proceed at all. This is the weakest-evidenced boundary this bundle’s research found, and it is labeled as inferred rather than as a line any one source draws by name
a creative or design brief you are briefing a designer or an agency on how to reach an audience or execute a design, a different discipline from asking for authority to start a project
a Project Canvas you want the same content laid out as a one-page diagram, read at a glance. That is a difference of medium, not of content: the questions this document asks still need answers
a project proposal or a one-page pitch you are trying to sell a decision nobody has committed to yet. This document instead records a mandate that already exists and asks for authority to explore it further, a boundary this library draws as its own position, since no single source in this bundle’s research draws it this way
the NSW Health or Treasury Board of Canada sense of “project brief” your organisation expects a large, iterative, gate-adjacent document that gets resubmitted across a project’s whole life. This bundle builds the shorter PRINCE2 and UK government sense instead: written once, consulted once, then retired

Write nothing at all if no one holds the authority to approve moving forward. This document exists to get a named decision from a named person, and a draft with no real decider to sign it has not done its job, whatever else it contains.

One posture worth adopting before you start writing. The UK government’s own guide, this bundle’s adaptable source, allows a short, well-defined project that is certain to proceed to skip the brief entirely and move straight to the document that follows it. If you already know for certain that this will happen, save the brief for the projects whose viability is still an open question. That is what the document is for.

Picking a variant

Section titled “Picking a variant”

Lean carries Background and Mandate, Objectives, Scope and Exclusions, Outline Business Justification, Constraints and Who Should Be Involved, and Decision Requested: enough to ask for authority to start without naming how the work will be approached or mapping it against neighbouring documents.

Full inserts Project Approach and Relationship to Other Documents after Decision Requested. The signal to move from lean to full: will a reader reasonably ask how the work will be approached and what document takes over once this one is approved, not only why the project exists and what it must achieve.

Both sizes stay short. The practitioner sources this bundle read converge on a document meant to be read in one sitting, and the primary source scales it to the project rather than fixing a length: a small project’s brief might run to a few sentences per section, and a larger or more contested one needs more. Adding Project Approach and Relationship to Other Documents should still leave the full variant reading as a page or two, not as the heavyweight, revised-across-the-project’s-life sense of the name that this bundle does not build.

The rubric

Section titled “The rubric”

Score each row 0, 1 or 2. Under 10 out of 16 on a full brief, and the approver could sign something that reads well but that nobody, including them, could point back to once the project stalls between approval and its own answers. Under 8 out of 12 on a lean brief, the same gap opens one section sooner, before Project Approach or Relationship to Other Documents even exist to catch it.

# Criterion 0 1 2
1 Mandate is traceable No mandate is named, or the trigger is described only as an unattributed good idea A mandate is named, but a reader cannot tell who issued it or what form it took You can name who issued the mandate, what form it took, and a reader unfamiliar with the project can tell why it needs to start now rather than later
2 Objectives are checkable An objective is an activity, not an outcome, for example “build queue alerts” An outcome is named, but the measure attached to it is something only the author could check For every objective, a reader who did not write it could look at the stated measure and tell, without asking, whether the objective was met
3 Exclusions do real work The exclusions field is blank, or names nothing a reader would otherwise have assumed was included An exclusion is named, but you cannot point to who might reasonably have assumed it was in scope You can name the specific request or assumption the exclusion heads off, and who would plausibly have made it
4 Justification stays outline The section says nothing about why the project is worth doing, or it attempts the full comparison of options itself A reason is given, but the estimate reads as final and no later document is named for the full comparison A reason is given, the estimate is explicitly illustrative, and a named document and decision point is where the full comparison of options will happen
5 Stakeholders earn their place A row names a department or a job title, with no person and no stated reason A named person appears, but the reason given is generic, an “interested party” or similar Every row names a real person or role and states the specific decision or dependency the project cannot proceed without their involvement
6 Decision has an approver No decision is named, or the section describes circulating the document for comment A decision and an approver are named, but nothing shows the approver actually agreed to decide, an email nobody replied to You can point to when and how the named approver agreed to decide, and the document that takes over once they have
7 Approach shows its reasoning (full only) An approach is named with no reasoning behind it, “build,” with nothing else Reasoning is given for the chosen approach, but no alternative is named as having been considered The approach is named, and you can point to the alternative that was considered and the specific reason it was rejected
8 Handoff is named (full only) The section describes this brief as revised alongside the project, or names no document that supersedes it A successor document is named, but not the point at which it takes over or what triggers the handoff You can name the specific document that supersedes this brief, and the point after which this brief stops being consulted

Which rows apply to what. Full ships all eight rows because a reader of the full variant can ask about approach and handoff as well as why, what and who. Lean ships six, every row except the two that grade a section it does not carry.

Document Rows Maximum Score against
lean 1-6 12 8
full all 8 16 10

Anti-patterns

Section titled “Anti-patterns”

Vague, unmeasurable objectives. An objective stated with a verb like improve, optimise or streamline gives a reader nothing to check later. State the outcome and the measure together, not the verb alone.

A missing or unwritten exclusions field. An unwritten boundary is not a small boundary, it is one nobody has agreed to yet, and the dispute over it arrives later instead of now. Whether writing an exclusions field measurably reduces scope creep is not something this bundle’s research measured; treat it as a recommendation several of the sources make, not as a proven effect.

A field that needs an essay. A section that keeps growing to answer one hard question is a signal the project may need a fuller document, not that this section should grow to hold the answer. Send the hard question to the document built for it, and keep this one short.

An unapproved draft treated as a mandate. A brief with no named approver, and no record of that approver actually agreeing to decide, has not done its job, whatever else it contains. Circulating a document for comment is not the same act as asking someone to decide.

Rushing it, or over-elaborating it, before viability is confirmed. Both failures run in opposite directions and both defeat the same purpose. A brief is meant to cost little relative to the decision it supports; racing past the questions it exists to raise, or answering them at a level of detail the decision does not yet need, both spend more than the document should.

Treating the brief as the finished business case. Its own outline justification is not a substitute for the fuller comparison of options a business case brings to a later approval (business-case_guide.md:17). A brief that tries to settle that comparison itself has stepped outside its own boundary.

Naming an approach with no reasoning. At this early stage the approach can still change. What a reader needs is the thinking behind the choice, build, buy or a mix, not a one-word answer with nothing to show whether an alternative was ever considered.

Treating the brief as a living document. In the sense this bundle builds, a project brief is written once and retired once initiation documentation exists. It is not revised in place across the project’s life the way a business case or an initiation document would be; a brief still being updated after the decision it asked for has already been made is the heavyweight sense of the name, not this one.

When it is good enough

Section titled “When it is good enough”

When you can point to who issued the mandate and why it needs to start now rather than later, when every stakeholder row names a person or role the project genuinely cannot proceed without, and when a named person has actually agreed, out loud, to decide.

Then delete every HTML comment. A document nobody has agreed to decide on is not a mandate, whatever else it contains, so the last thing worth checking is not a section of the brief at all: has the person named as approver actually said yes to deciding, not merely been copied on the draft.

The artifacts

Section titled “The artifacts”

project-brief_template-lean.md · ~4,350 tokens

---
title: "{{project_name}} Project Brief"
project_name: "{{project_name}}"
author: "{{author}}"
approver: "{{approver}}"
status: "{{status}}"
last_updated: "{{date}}"
doc_type: project-brief
size: lean
source_template: project-brief
source_template_version: 0.1.0
---


<!--
LEAN PROJECT BRIEF. The shortest form that still asks for real authority to start: where the
project comes from, what it must achieve, what is explicitly out of scope, an outline of why it is
worth doing, the constraints and people involved, and the decision being requested. Use it to ask a
named decision maker for authority to begin initiation, before anyone commits to delivering
anything. To grow it into a brief that also states the delivery approach and where it sits against
other documents, see project-brief_template-full.md. ADD sections after Decision Requested; never
rename or reorder the ones below, because the full variant is a strict ordered superset of this one.


STAYS SHORT AT EITHER SIZE. Unlike this library's business-case bundle, where the full variant adds
real financial weight, this bundle's full variant stays short too: prince2.wiki's own quality bar is
"short, focused," and Smartsheet's stronger claim is that the whole document "should be a single
page long, and anyone should be able to understand it at a glance." Length guidance is otherwise
inconsistent across the sources this bundle read, from a paragraph to a few pages, and no source
measured length against outcome. Scale to your own project rather than treating any one figure as a
rule. See project-brief_companion.md section 4.


WHAT A PROJECT BRIEF IS, AND IS NOT
It asks for authority to start finding out whether and how to proceed, before anyone commits to
building anything. It is NOT a business case (a full comparison of options and a funded
recommendation; this document carries only an outline of that case and defers the comparison, per
business-case_guide.md:17). It is NOT a project charter or a project initiation document, called a
PID (this library's POSITION: those authorize delivery once initiation is approved, and neither is
built in this library). It is NOT a product brief (which scopes a single product opportunity, where
this document scopes a whole initiative or project; this boundary is labeled inferred, since no
source read for this bundle draws it explicitly). It is NOT a creative or design brief (a different
discipline entirely). It is NOT a Project Canvas (the
same kind of content in a one-page diagram, a difference of medium, not of content). It is NOT a
project proposal or a one-page pitch (this library's POSITION: a pitch sells a decision not yet
made, while this document records a mandate that already exists and asks for authority to explore
it further). A separate, heavyweight sense of the name, published by NSW Health, the Treasury Board
of Canada and Ireland's National Transport Authority, is large, iterative and revised across a
project's whole life; this bundle does not build that document. See project-brief_companion.md
section 8.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   project-brief_companion.md), guiding questions to ASK, a GOOD and a WEAK example, and the TRAP to
   avoid. For the tables, PRIORITY explains the ordering rule and ROW HINT says what a good row
   contains.
2. Replace each {{placeholder}} with your content. Name the approver in the frontmatter and mean it:
   this document is not finished until a real person has agreed to decide.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. Before you send this for a decision: self-grade against project-brief_guide.md, then DELETE every
   HTML comment. They are guidance, not content.
-->


# {{project_name}} Project Brief


## Background and Mandate


<!-- WHAT  Where the project comes from, the mandate that triggered it, and why it needs to start
           now rather than later.
     WHY   BIS names the trigger precisely: start-up begins when a senior manager "agrees/decides to
           take responsibility for a new initiative that might best be run as a project," arriving
           from business planning, an external driver, or "identification of a significant problem
           that cannot be dealt with as a matter of routine." The mandate itself is, in BIS's own
           phrase, "often as simple as an email," so this section's job is to make that trigger
           legible to a reader who was not in the room when it was decided. Deep dive:
           project-brief_companion.md section 3 (Anatomy > Background and Mandate).
     ASK   Where did this project come from, and who issued the mandate? What form did it take, a
           conversation, an email, a formal memo? Why does it need to start now rather than later?
           What happens if nothing changes?
     GOOD  "Mandate: verbal instruction from the COO at the 2026-07 operations review, following
           three consecutive quarters of rising checkout abandonment. Why now: the pattern is
           worsening each quarter, and the holiday peak arrives in twelve weeks, after which a fix
           could not ship before the season that matters most."
     WEAK  "We think this would be a good idea." (no mandate, no source, and no reason the timing
           matters)
     TRAP  Skipping the mandate and writing only the background. A brief with no named mandate reads
           as something the project manager invented, not something a decision maker actually asked
           for. -->


- Mandate and background: {{mandate_and_background}}
- Why now: {{why_now}}


## Objectives


<!-- WHAT  What the project must achieve, stated so a reader can tell later whether it did.
     WHY   BIS's own start-up checklist calls for objectives that are "achievable and measurable
           (SMART)," and prince2.wiki repeats SMART as the brief's own quality bar. How firmly
           sources hold that bar varies: Oxford City Council's template asks for it only "wherever
           possible," one practitioner source states it as a flat requirement ("Avoid vague verbs
           like improve, optimise or streamline, because nobody can tell when they are done"), and
           at least one published template carries no measurability wording for this field at all.
           Treat SMART as the convergent recommendation, not a universal rule every published
           template enforces. Deep dive: project-brief_companion.md section 3 (Anatomy >
           Objectives).
     ASK   What must this project achieve to be judged complete and successful? How will you know,
           concretely, whether each objective was met? Is each one stated as an outcome rather than
           an activity?
     PRIORITY  Order objectives by how central each is to the mandate above. A brief carrying many
           objectives at this size is probably several projects wearing one brief.
     ROW HINT  A good row states an outcome a reader could check later, and names what checking it
           would look like. A weak row is an activity, or a vague verb, with nothing to measure.
     GOOD  | OBJ-1 | Cut checkout abandonment on the self-checkout lanes from 14% to under 8% |
           Weekly abandonment rate from point-of-sale logs, measured for four weeks after launch |
     WEAK  | OBJ-1 | Improve the self-checkout experience | |
     TRAP  Writing an activity, "build queue alerts," instead of an outcome, "cut abandonment to
           under 8%." An activity tells you the project shipped; only an outcome tells you it
           worked. -->


| ID | Objective | How you will know it succeeded |
|---|---|---|
| {{objective_id}} | {{objective_statement}} | {{objective_measure}} |


## Scope and Exclusions


<!-- WHAT  What is in scope, including the deliverables, and what is explicitly out, as its own
           named field rather than folded into a general paragraph.
     WHY   BIS's own start-up checklist item is exactly this pairing, "Scope - what in and what's
           out," and Oxford City Council gives the exclusion half a numbered heading of its own, "3
           Project Scope and Exclusions," prompting "What is outside the remit of the project?"
           Deliverables belong on the in-scope side: BIS's own contents list names "Deliverables,"
           and Oxford City Council carries a matching deliverables section of its own. Several
           sources recommend naming exclusions specifically because an unwritten boundary invites
           disputes later; none of them measured whether writing one actually reduces scope creep,
           and this section does not repeat that as a measured fact. Deep dive:
           project-brief_companion.md section 3 (Anatomy > Scope and Exclusions), section 7
           (anti-patterns).
     ASK   What deliverables are in scope? What is explicitly out, that someone might otherwise
           assume is included? What would you say to a stakeholder who asked for something on the
           excluded list?
     GOOD  In scope: "Self-service queue-length alerts on the four busiest self-checkout lanes,
           shown on the existing overhead displays." Exclusions: "Staffed-lane queueing is
           explicitly out of scope; this project does not touch cashier scheduling or staffing
           levels."
     WEAK  In scope: "Improve checkout." Exclusions: (left blank)
     TRAP  Leaving exclusions blank because nothing seems worth excluding yet. An unwritten boundary
           is not a small boundary, it is one nobody has agreed to yet, and the dispute arrives
           later instead of now. -->


- In scope and deliverables: {{in_scope_and_deliverables}}
- Explicitly out of scope: {{exclusions}}


## Outline Business Justification


<!-- WHAT  Why this project is worth doing, in outline only, an illustrative estimate of time and
           cost, and a named pointer to where the full comparison of options happens.
     WHY   prince2.wiki names "outline business case" as one item in its own composition list for
           the brief, and prince2.ca states plainly that in PRINCE2 "the creation of the business
           case (in outline form) is part of the project brief." This library's own business-case
           guide states the boundary from its own side: "a project brief absorbs an outline business
           case as one component and retires once initiation documentation exists; the business
           case itself keeps being refined, it does not retire with the brief"
           (business-case_guide.md:17). This section carries the outline only; it does not attempt
           the fuller comparison of options, including doing nothing, that a business-case document
           brings to a later decision. Deep dive: project-brief_companion.md section 3 (Anatomy >
           Outline Business Justification), section 6 (the business-case nesting debate).
     ASK   Why is this worth doing? Who benefits, and how? What is an illustrative, not final,
           estimate of the time and cost involved? What later document, and what decision gate, will
           bring the fuller comparison of options?
     GOOD  "Reduces checkout abandonment, the retailer's second-largest source of lost sales per the
           Q2 operations review. Illustrative estimate: roughly six engineer-weeks and no new
           hardware, to be confirmed. A full comparison against alternatives, including doing
           nothing, will be brought to a business case at the September funding review."
     WEAK  "This will definitely pay for itself many times over." (no comparison named, no estimate,
           no pointer to where the real case gets made)
     TRAP  Treating this section as the finished business case. A brief that tries to settle the
           comparison of options itself has stepped outside its own boundary; that comparison
           belongs to a business-case document, not here. -->


- Why this is worth doing: {{outline_justification}}
- Outline estimate, illustrative and not final: {{outline_estimate}}
- Full comparison of options deferred to: {{business_case_reference}}


## Constraints and Who Should Be Involved


<!-- WHAT  Known constraints and dependencies on the work, brief notes on risks and assumptions,
           and the people who need to be part of it.
     WHY   BIS states the pairing directly in its own summary sentence, "the Project Brief says why
           the project is needed, what it must achieve and who should be involved," and separately
           lists constraints, stakeholders and dependencies among the brief's contents. AXELOS's own
           glossary names constraints as part of the standards-body definition itself. Risks and
           assumptions belong here too, as a line or two each rather than a formal register:
           prince2.wiki's own composition list names "risks," and its starting-up page describes the
           brief as covering "the scope, objectives, risks, and approach," which is also where
           prince2.wiki names "project management team structure" as part of what the wider process
           assembles into the brief. A formal risk-scoring table stays out of a document this size;
           that belongs to the heavyweight public-sector sense this bundle does not build. Deep
           dive: project-brief_companion.md section 3 (Anatomy > Constraints and Who Should Be
           Involved).
     ASK   What constraints, and what dependencies on other work, apply here? What are the known
           risks and assumptions, in a line or two each? Who needs to be involved, and why, beyond
           the approver named in the frontmatter?
     PRIORITY  List every person whose absence would stop the project cold, not everyone who might
           be interested. A stakeholder with no stated reason for being on the list probably should
           not be.
     ROW HINT  A good row names a real person or role, and states in a few words why they need to be
           involved. A weak row is a job title with no stated reason.
     GOOD  | Ines Draper | VP, Store Operations | Owns the budget and the overhead-display hardware
           this project depends on |
     WEAK  | IT | | |
     TRAP  Listing a whole department as one row. "Engineering" is not a stakeholder; the specific
           person or role who owns the decision or the dependency is. -->


- Constraints and dependencies: {{constraints_and_dependencies}}
- Known risks and assumptions: {{risks_and_assumptions}}


| Name | Role | Why involved |
|---|---|---|
| {{stakeholder_name}} | {{stakeholder_role}} | {{stakeholder_reason}} |


## Decision Requested


<!-- WHAT  The decision being asked for, who is being asked, and what happens to the answer.
     WHY   prince2.wiki states the decision plainly, the brief "is used by the project board to make
           the first key decision: whether to authorise the initiation stage," and its own
           starting-up page names the request itself as that process's final output, "to send a
           request to the project board to initiate the project." BIS lists what the approvers are
           confirming when they sign off, ending with a commitment to plan rather than to build:
           they are willing to provide the project manager with the time and resources "needed to
           plan the project in detail and to produce the Project Initiation Document (PID)." One
           practitioner source frames approval itself as what changes the document's status: "A
           brief that is filled in but never approved is a wish list, not a mandate; the signature
           is what turns it into permission to start," and another puts the same instruction more
           bluntly, "Get it approved by the decider, out loud." This section also carries the
           discovery-docs family contract's own obligation: every member must say, in its
           companion, what document takes over once the decision is made; naming that document
           here, and recording the approver's own answer, is this library's own structural choice.
           Deep dive: project-brief_companion.md section 3 (Anatomy > Decision Requested), section 6
           (what approval actually authorizes).
     ASK   What decision are you asking for, proceed to a business case, proceed straight to
           initiation, or stop? What document takes over once the decision is made? Has the person
           named as approver in the frontmatter actually agreed to decide, not just to be copied?
     GOOD  "Decision requested: authorize proceeding to a full business case. Next document: a
           business-case draft, due before the September funding review. Approved by Ines Draper,
           VP Store Operations, out loud at the 2026-08-04 operations sync, not left as an email
           nobody replied to."
     WEAK  "Please take a look and let us know your thoughts." (no decision named, no next document,
           and no approver who has actually agreed to decide)
     TRAP  Circulating a brief for comment without ever naming a decision or a decider. A brief that
           nobody approves is a wish list, not a mandate, whatever else it contains. -->


- Decision requested: {{decision_requested}}
- Approver: {{approver}}
- Next document once decided: {{next_document}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 8 sections across 1 format(s), methodology PRINCE2, typically owned by PM.