Free Project Brief Template (Fillable + Example)

What should a project brief template contain?

The brief needs eight blocks, and the order matters more than the headings. Each block answers a single question, so a reader can find the answer without reading the whole document.

The order is not arbitrary. Starting with the decision keeps the document honest, because the author knows from the first line that somebody has to say yes. Most templates start with background and produce three pages of context and one line of commitment.

If you want a single test for whether a block is finished: could a new team member read it and make a decision without calling you? If not, it is a note, not a brief.

What is the difference between a project brief, a charter, and a statement of work?

They overlap in content and differ in authority. A brief supports a decision to explore; a charter authorises the project and the manager; a statement of work commits a supplier to deliverables; a project plan explains how the work will be delivered.

PRINCE2 is explicit about the sequencing. Its project brief is produced while starting up a project, is used by the project board to decide whether to authorise the initiation stage, and is then expanded into the project initiation documentation. After the PID exists, the brief is no longer used in active project management. It is a decision document with a short life, not an archive.

PMBOK leans the other way: the charter authorises the project, names the project manager, and gives that manager authority to apply resources. Many organisations merge the two. That is fine, as long as the document is clear about which decision it is asking for.

The practical rule: a funder who has not committed money needs a one-page brief; a governance body about to release budget needs a charter with signatures.

How do you fill in the template in 90 minutes?

Fill it in this order: decision, outcome, out of scope, acceptance, dates, money, people, risks. Write badly first, then cut. The blocks that feel hardest, the outcome and the acceptance criteria, are hard because they require a conversation, not because they require better wording.

Here is a workable 90-minute session for two people, usually the sponsor and the person who will run the work.

Minutes 0–10: write the decision sentence. One sentence, with a number in it. “Approve £60,000 and one designer for eight weeks to rebuild the onboarding flow.” If you cannot write it, the project is not ready for a brief. It is ready for a conversation about what is being asked.

Minutes 10–25: agree the outcome and the baseline. Name the metric, its current value, the target, and the date. If no baseline exists, the first milestone becomes “establish baseline”, which is an honest answer and a common one.

Minutes 25–40: list what is out of scope. Aim for five named exclusions, especially the adjacent things stakeholders assume are included. “Migration of historical accounts” and “a native mobile app” are worth more in this list than in any risk register.

Minutes 40–55: write acceptance criteria. Three to six testable statements. Each should be checkable by someone who did not write it. “Search returns results in under 400 ms for 95% of queries” is testable. “Search feels fast” is not.

Minutes 55–70: dates and money. One end date, three milestones, a budget range, and a tolerance. State the tolerance as a number: “changes up to 10% of budget can be approved by the sponsor without a steering review.”

Minutes 70–80: names. One accountable owner, one decision-maker, and the people who must be consulted. Use names, not roles, because roles change and names create obligation.

Minutes 80–90: risks and assumptions. Five entries maximum, each with an owner. If the list is longer than five, you are listing fears, not risks.

Then stop. Send it. Do not spend the afternoon formatting it.

What does a completed project brief look like?

Below is a filled example for a mid-sized internal project, deliberately unglamorous so the structure is visible. The scenario: a B2B software company whose trial-to-paid conversion has drifted down, and whose support team spends too much time on setup questions.

Decision requested. Approve $48,000 and two engineers for six weeks to rebuild the trial onboarding flow, with a go-live before the Q2 campaign.

Problem and evidence. Trial-to-paid conversion fell from 18.4% to 14.1% over two quarters. Setup-related tickets are 38% of first-week support volume, and the median time from signup to first successful import is 3 days 11 hours.

Intended outcome. Trial-to-paid conversion returns to at least 17.5% within 90 days of launch, and median time to first successful import drops below 24 hours.

In scope. A guided setup checklist; a sample-data importer; three contextual help panels; a progress email sequence; analytics events for each setup step.

Out of scope. Pricing page changes, a native mobile app, migration of existing customer data, localization beyond English, and any change to the billing system.

Acceptance criteria. A new trial account reaches a completed import in under 20 minutes with no support contact, verified with 12 usability sessions. The checklist persists across sessions. Every step emits an analytics event with a stable name. Error states show a recovery action, not a stack trace.

Time and money. Six weeks, three milestones: prototype end of week 2, internal beta end of week 4, launch end of week 6. Budget $48,000, tolerance 10%, so changes up to $4,800 can be approved by the sponsor without a steering review.

People. Accountable owner: Head of Growth. Decision-maker: VP Product. Delivery lead: staff engineer. Consulted: Support lead, Legal, and one customer advisory member.

Risks and assumptions. Assumption: the current importer can be reused. Risk: the analytics migration slips and delays measurement, owner the data lead. Risk: support team capacity during beta, owner the support lead.

That is 348 words. It fits on one page with normal margins, and it contains everything a sponsor needs to say yes, no, or “not yet”. Notice what is absent: task lists, Gantt charts, staffing histograms, a glossary, and a page of company background. Those belong in the plan, and adding them here would only delay the decision.

How long should a project brief be?

One page for most projects, two pages when the work is regulated, contracted, or cross-organisational. Length is a cost, and the cost is easy to calculate.

Assume a loaded cost of $85 per hour for the people in the room, which is a reasonable blended rate for a mid-level product, design, and engineering group in a US or Western European company.

• A two-page brief is about 700 words. Drafting takes 90 minutes, two reviewers spend 30 minutes each, and one revision pass takes 30 minutes. Total: 3 hours, or $255.
• A 14-page brief is about 5,000 words. Drafting takes 8 hours, four reviewers spend 90 minutes each, a consolidation pass takes 3 hours, and a second review round takes 2 hours. Total: 19 hours, or $1,615.
• The difference is $1,360 and 16 hours, spent before anyone has approved the work.

That difference is worth paying only if the longer document changes a decision. It rarely does. A 14-page brief is usually a plan wearing a brief’s title, and it gets reviewed the way plans get reviewed: slowly, partially, and after the budget is already committed.

Long documents also get delegated. A sponsor who receives 14 pages replies “looks fine, go ahead” or says nothing. A sponsor who receives one page with a number and a date makes a decision.

Two pages is the practical ceiling. If the content does not fit, the material is either a plan or an appendix, and both can live somewhere else with a link.

Which numbers belong in a brief, and which do not?

Numbers belong in a brief when they frame a decision. They do not belong when they pretend to be a forecast. The distinction is whether the number changes what the approver would do.

Two external findings are worth keeping in mind when you are tempted to soften the boundaries.

First, scope creep is normal, not exceptional. PMI’s 2018 Pulse of the Profession reported that 52% of projects experienced scope creep in the previous 12 months. A brief cannot prevent that, but it changes the conversation. If the brief says the budget is $48,000 with a 10% tolerance, a $4,000 request is a decision the sponsor can make in an email. Without the tolerance line, the same request becomes a steering committee agenda item three weeks later.

Second, a lot of work runs without a defined approach at all. Wellingtone’s 2026 State of Project Management survey reports that roughly a quarter of organisations still run projects without a defined delivery approach. That is the population a one-page brief is designed for: teams that will never adopt a 40-page methodology but can be persuaded to fill in one page before they start.

Here is the arithmetic that makes the tolerance line concrete. A $48,000 budget with a 10% tolerance creates a $4,800 decision envelope. Suppose the project receives four change requests averaging $2,100 each, a total of $8,400. With the tolerance stated, the first two are approved by the sponsor within a day and the remaining $3,600 goes to the steering group once. Without it, all four go to the steering group, which meets fortnightly, adding an estimated three weeks of waiting across the project. At a loaded cost of $85 per hour for eight people, three weeks of delay is 960 hours, or $81,600 in capacity sitting idle. The tolerance line took 90 seconds to write.

Where do project briefs fail in practice?

Five failures account for most of the wasted effort.

Written by the delivery team, for the sponsor, without the sponsor. The team produces a document that answers the questions the team finds interesting. The sponsor wanted to know the cost, the date, and what happens if they say no. If the sponsor does not contribute two sentences, the brief is a proposal, not an agreement.

Out of scope reduced to one line. “Out of scope: anything not listed above” is not a boundary, it is a wish. Named exclusions are the only ones that survive contact with a stakeholder who has a different memory of the kickoff.

Success written as activity. “Deliver a new onboarding flow” describes an output. “Reduce time to first value from 3.4 days to under 24 hours” describes an outcome. The first cannot fail; the second can, which is exactly why it is useful.

No named decision-maker. “The steering group” is not a person. When two stakeholders disagree in week five, the brief should already say who breaks the tie, and it should be someone who was in the room when the brief was approved.

Never revisited. A brief that is filed and forgotten becomes a document people cite selectively. The fix is small: review it at every change request and at every milestone, and record the date of the last review on the first page.

When is a one-page brief not enough?

A short brief is the right default, but four situations justify more structure.

For everything else, the one-pager plus a linked plan is enough. The trade-off is explicit: a longer brief buys traceability and enforceability, and it costs time, delegation, and the chance that nobody reads the part that mattered.

It suits small and mid-sized teams without a PMO, agencies briefing client work, and anyone handed a project with a title and no boundaries. It does not suit programmes with a mandated governance template. Use theirs, then add the two blocks it usually lacks: named exclusions and a stated tolerance.

How does a project brief template fit into a project management tool?

A template is only useful if it lives where the work happens. A document in a shared drive gets opened twice; the same content inside the project record gets read whenever someone checks scope, dates, or ownership.

Put the brief in the tool rather than beside it. The eight blocks map onto fields a project already has: the outcome becomes the goal, milestones become dates, owners become assignees, exclusions become a pinned note, and the tolerance becomes a rule for what needs approval.

Doitify is our product, so treat this section as disclosure rather than review. It is built as one workspace for projects, tasks, sub-tasks, checklists, owners, and due dates, with Kanban boards, Gantt charts, roadmaps, calendars, workload views, reports, automations, import and export, and project documents. Doitify Copilot and AI Coach can turn a stated goal into tasks, sub-tasks, and a plan. It is not a document-authoring tool, and it will not write the brief for you. What it does is keep the brief’s decisions attached to the work they govern, so the out-of-scope list is visible when a new request arrives.

The honest summary: use a template to make the decision, use the tool to keep the decision alive. Neither replaces the other, and a team that fills in one page and pins it to the project is already ahead of most.

Conclusion

A project brief template earns its place by making a decision cheaper to take. One page, eight blocks, one named decision-maker, and a tolerance that says what can change without a meeting. It takes 90 minutes, costs a few hundred dollars of staff time, and prevents the version of the project that starts with enthusiasm and ends with a scope argument in month three.

Use the filled example above as a model, not a script. Write the decision first, name the exclusions before anyone gets attached to them, and make acceptance testable by someone who was not in the room. Then pin the result where the work happens.

The brief is not paperwork. It is the cheapest point in the project to disagree.

If this post on project brief template was helpful, you might also enjoy Project Manager vs Product Manager: 5 Key Differences and Best Project Management Software for Agencies in 2026.