Project Brief Template for Software Projects (One Page)
ยท 5 min read
A project brief is a one-page statement of what a project is, why it exists and what done looks like. It is the shortest document that still lets a new person understand the project, and it is usually the first thing written, before requirements, estimates or a contract.
Below is a template you can copy, the reasoning behind each field, and a short example.
What a project brief is for
A brief aligns people before the expensive work starts. Its jobs are to make sure everyone describes the project the same way, to surface disagreements while they are cheap to fix, and to give the next documents, such as requirements and a statement of work, something solid to build on.
It is not a specification. If you find yourself listing screens or database fields, you have moved on to a later document.
The project brief template
Project name:
Date / version / owner:
1. Purpose
One or two sentences: why this project exists.
2. Background and problem
What is happening now, who is affected, what it costs.
3. Objectives
2-4 outcomes. For each: how it will be measured.
4. Scope
In scope:
Out of scope:
5. Users and stakeholders
Who will use it. Who decides. Who must be consulted.
6. Deliverables
What will exist at the end (software, documents, training).
7. Constraints and assumptions
Deadline, budget range, technology or regulatory limits, things
assumed but not yet confirmed.
8. Risks and open questions
What could derail this, and what still needs an answer (owner + date).
9. Success criteria
How the sponsor will judge that the project worked.
10. Next steps
The first two or three actions, with owners.
Aim for one page. If it grows past two, move detail into linked documents and keep the brief as the summary.
How to fill in each field
Purpose and problem
The purpose is a single sentence a stakeholder could repeat to a colleague. Test it: if two people on the project would say it differently, the brief has done its first job by showing you that.
For the problem, describe what is wrong today without naming the solution. "Customers email support for order status and wait for a reply" gives the team room to find the best fix. "Build a portal" does not.
Objectives and success criteria
Objectives are the outcomes you want; success criteria are how the sponsor will judge them. They are close but not identical: an objective might be fewer support contacts about order status, and the criterion might be a target the sponsor has agreed on, checked after launch.
Include a baseline where you can. If you cannot yet measure the starting point, put "measure baseline" in the next steps instead of guessing a number.
Scope
In-scope and out-of-scope lists belong in the brief because scope disagreements are cheapest to resolve now. Write the out-of-scope list from the point of view of someone who might reasonably expect those items, such as payments or an admin area, and mark them explicitly.
When you later turn the brief into a statement of work, this section is the starting point. How to scope a software project walks through that step, and SOW vs discovery phase explains what to do when the requirements are still unclear.
Users and stakeholders
Distinguish people who use the result from people who decide about it and people who only need to be informed. A stakeholder missed here tends to show up late with a requirement that changes the plan.
Deliverables
Name what will exist at the end, in concrete terms: a working application, documentation, a handover session. It is fine if the list is short. A deliverable that cannot be named cannot be accepted.
Constraints, assumptions, risks
Keep constraints, which are fixed, apart from assumptions, which are beliefs that may turn out wrong. Give each risk and open question an owner and a date, otherwise they stay open.
A short filled-in example
The example is invented.
Project name: Customer order portal
Version / owner: v1, operations lead
Purpose
Let wholesale customers check order status and download invoices without
contacting support.
Problem
Support answers repeated email requests about order status and invoice
copies. Customers wait for replies to simple lookups.
Objectives
- Fewer support contacts about order status and invoices.
Measure: ticket categories, baseline taken from the last three months.
- Customers find invoices themselves.
Measure: invoice downloads per active customer.
Scope
In: sign-in, order list with status, invoice download.
Out: ordering, payments, changing delivery addresses.
Deliverables
Working portal, short user guide, handover session for support staff.
Constraints
Order data stays in the existing ERP. Launch tied to the next quarterly
customer mailing.
Open questions
Which system is the source of truth for status? Owner: operations lead.
Next steps
1. Confirm the source of truth for status.
2. Collect the ticket baseline.
3. Draft requirements.
Common mistakes
- A brief that is really a feature list. Start from the problem and the outcome.
- No out-of-scope section. Everyone adds their own expectations.
- Objectives that cannot be measured. "Better experience" tells nobody when to stop.
- Nobody owns the open questions. Give each one a name and a date.
- Writing it once and filing it. Treat it as a living page and update it when decisions change.
From brief to the rest of discovery
A brief is the first step. Next come requirements, the stakeholders and risks in more detail, and then estimates and a plan. The discovery phase checklist and discovery phase template cover those steps.
If your starting point is a pile of kickoff slides, emails and call transcripts, Discovery Phase AI can read those files and draft the discovery stages for you to review and correct. The example report shows what the result looks like, using an invented project.
Whichever route you take, keep the brief to one page that people actually read.