How to Write a Project Brief: Complete Guide

A bad project brief costs more than no brief — it creates the illusion of alignment while guaranteeing misalignment. This guide covers what your brief must contain, what to cut, and how to write a document that actually gets you the right vendor and the right outcome.

Artyom Dovgopol

The best briefs I've received weren't long. They were honest. They stated what the client actually wanted, what they didn't yet know, and what would disqualify a vendor. Five pages of clarity beats twenty pages of hedging every time.

Key takeaways 👌

Bad briefs don't just produce bad quotes — they produce the wrong shortlist of vendors entirely, because agencies that respond to vague briefs are almost never the ones you'd want to hire after evaluation.

The most valuable section of any brief isn't the scope description — it's the success criteria, because that's what tells vendors whether they can actually deliver what you need.

Briefs that include budget ranges and honest constraints consistently produce better proposals than briefs that hide budget to "see what vendors quote" — you don't extract hidden information; you waste everyone's time.

Introduction

You've decided to hire an agency. You're writing the brief. And you're stuck, because nobody has ever taught you how to write one — and every template you find online is either absurdly complex or uselessly generic.

This is the problem most project briefs solve badly. They either over-specify (30-page documents that read like internal PRDs and overwhelm vendors with irrelevant detail) or under-specify (two paragraphs about "modernizing our digital presence" that tell vendors nothing useful about the project).

The right brief is neither. It's a structured document that gives vendors enough information to respond with meaningful proposals, without drowning them in detail that slows the evaluation process. It states objectives clearly, defines scope precisely, shares constraints honestly, and asks the questions you genuinely need answered.

This guide covers what a good brief contains, what it deliberately leaves out, and how to structure it so your shortlist of responding vendors is high-quality from the first round. Follow it, and you'll get better proposals, faster evaluations, and fewer "we didn't know that would be in scope" conversations after signing.

Why a Bad Brief Costs More Than No Brief

Writing a weak brief feels productive — you've handed vendors a document, you can point to your process, you've "done the work." In practice, weak briefs create more expensive problems than skipping the brief entirely and having direct conversations with a few candidate agencies.

The wrong agencies respond to weak briefs. Agencies with strong process discipline recognize when briefs lack the information needed to produce accurate proposals. They either pass or ask structured follow-up questions before quoting. Agencies optimizing for billable hours respond enthusiastically to vague briefs because ambiguity creates scope flexibility — and scope flexibility is where their margin lives.

Evaluation becomes apples-to-oranges. When three agencies quote different scopes against a weak brief, comparing their proposals is impossible. You end up comparing who wrote the most impressive-looking document, not who quoted the best value for the work you actually need.

Project failure becomes baked in. The Project Management Institute's research consistently shows that unclear requirements are the #1 cause of project failure — and the brief is where requirements clarity either happens or doesn't. Teams that skip the rigor of a well-structured brief spend that rigor later, during the project, when mistakes cost more.

Vendor relationships start in debt. Even if you pick the right agency, a weak brief starts the relationship with informational debt. You spend the first 2–4 weeks of engagement answering questions that should have been answered during procurement — compressing timelines and shifting discovery work into development phases where it costs more to integrate. Pre-project analytics work should happen before the brief, not after signing — and briefs that reflect that preparation signal seriousness to every responding vendor.

The cost of a good brief is 5–15 hours of your time upfront. The cost of a bad brief is measured in weeks of project delay, budget overruns, and sometimes a failed engagement that sets your initiative back by 6+ months.

Criterion 1 — State Outcomes, Not Deliverables

The most common brief-writing mistake is describing what you want the agency to produce instead of what you want the project to accomplish.

Deliverable-focused (weak): "We need a 20-page corporate website with a blog, contact forms, and an admin panel."

Outcome-focused (strong): "We need to generate qualified leads from enterprise accounts in North America. Our current site converts visitors at under 0.5%, and sales has told us that prospects arrive unprepared for conversations. Target: 2%+ conversion rate, with 200+ qualified leads monthly within 6 months of launch. The site is one part of this; we're open to vendor recommendations on page structure, content strategy, and technical architecture."

Notice what the second version does: it tells the vendor the business problem, provides baseline metrics, sets measurable targets, and invites the vendor to contribute expertise rather than just execute a spec.

What to include in the outcomes section

The business problem you're solving. Not the symptom (low traffic, outdated design) but the underlying issue (can't generate leads, can't onboard enterprise customers, can't support a new product line).

Current-state metrics. Actual numbers where you have them: traffic, conversion rates, bounce rates, specific user feedback. Vendors can work with messy data; they can't work with nothing.

Success criteria. What has to be true 6–12 months after launch for this project to be considered successful? Revenue targets, efficiency gains, reduced support tickets — specific, measurable outcomes.

Constraints on the solution. Things you know the solution must or must not do (compliance requirements, brand restrictions, technology constraints).

What to leave out of the outcomes section

Prescribed solutions. Don't tell the vendor what technology to use, how many pages to build, or what features to include unless those are non-negotiable constraints. Let them bring expertise.

Unverifiable claims. Don't write "industry-leading design" or "best-in-class user experience" as outcomes. Those aren't measurable, and vendors will interpret them as invitations to inflate scope.

Criterion 2 — Define Scope Precisely (In and Out)

Scope is where most briefs either succeed or fail. The failure mode isn't lack of detail — it's lack of discipline about what's in scope versus what isn't.

The two-column approach

Structure scope as two columns:

In scope: specific functionality, pages, or deliverables the project must produce; integrations that must work at launch; user roles and permissions that must be supported; content migration or creation tasks the agency owns; testing and QA responsibilities.

Out of scope: functionality deliberately excluded from this phase (but may be in future phases); work you or other vendors will handle (content writing, photography, SEO strategy); integrations that are nice-to-have but not required for launch; post-launch maintenance and support (unless being procured simultaneously).

The "out of scope" column is often more valuable than "in scope." It prevents the classic scope argument where both sides point to the same ambiguous bullet point after launch and disagree about whether it was included.

Getting scope clarity without over-specifying

You don't need to specify every button and page. You do need to specify the structural elements that determine project cost and complexity:

How many content types? (e.g., 5 primary content types: pages, blog posts, case studies, resources, products)

How many languages or locales? (Multilingual sites have 2–4x the complexity of single-language sites)

How many user roles? (Admin-only is simple; admin + editor + author + viewer with different permissions is complex)

Which systems must integrate? (Name them — not "integrations with our CRM" but "must integrate with HubSpot for contact sync and Salesforce for opportunity tracking")

Mobile, tablet, desktop responsive — or mobile-first? (This changes design and development approach significantly)

For complex projects where scope itself needs specialist thinking, a vendor with experience writing formal technical specifications can help you convert business requirements into technical scope — and the quality of that translation is one of the most important things you're evaluating during vendor selection.

The single biggest problem in communication is the illusion that it has taken place.

— George Bernard Shaw, Playwright, Nobel Laureate

Criterion 3 — Audience & User Context

The brief section most commonly skipped is the one that most determines whether the resulting product actually works.

Vendors can design interfaces, write code, and produce pixel-perfect layouts without knowing anything about your users — but the results will be generic. Interfaces that serve specific users well require vendors to understand those users well enough to make hundreds of small design decisions correctly.

What to include about your users

Primary and secondary user types. Who visits the site or uses the product? Don't list demographics — list behaviors and intents. "Enterprise buyers evaluating vendors for a planned 2026 purchase" is more useful than "B2B decision-makers aged 35-55."

User goals per type. What is each user type trying to accomplish when they interact with your product? What does success look like for them? What friction do they currently experience?

Existing research. Share what you already know about your users — analytics patterns, customer interview findings, support ticket themes, sales team observations. Vendors can build on existing insight far more effectively than starting from zero.

Access to users for research. Tell vendors whether they can interview or test with your actual users. If yes, the vendor can propose research-driven discovery. If no, they'll need to work from your existing data plus assumptions — and that constraint matters for their proposal.

Use case scenarios. Describe 2–3 specific scenarios where users interact with the current product and what outcome you want for each scenario in the new product. These scenarios become the test cases for evaluating whether the delivered work actually solves the problem.

What about personas?

If you've built user personas — genuine, research-based ones — share them. If you haven't, don't create them just for the brief. Fabricated personas confuse vendors more than they help. The fundamentals of user research that drive useful personas are work the vendor can propose doing as part of discovery — and often should, if the project depth justifies it.

Vendor design tradeoff between user types

If your vendor's design team had to make a difficult tradeoff between two user types your brief mentions — do you tell them which user wins, or do they have to guess?

Criterion 4 — Technical Requirements & Constraints

Technical requirements are where buyers most often over-specify or under-specify. The goal is neither a feature list nor a silence — it's a structured description of the constraints that matter.

What every brief should include technically

Current technology stack. What do you run today? CMS, framework, hosting, integrations. Even if you're rebuilding from scratch, the current stack informs what data needs to migrate and what operational patterns your team is accustomed to.

Must-have integrations. Specific systems the new solution must connect to — with API documentation references if you have them. "Integrates with Salesforce" is not enough; "integrates with Salesforce via REST API for bi-directional contact sync using existing webhook infrastructure" is.

Performance requirements. Page load targets (under 2 seconds on mobile is standard), uptime commitments, concurrent user capacity, traffic expectations.

Security and compliance constraints. SOC 2, HIPAA, PCI, GDPR, CCPA — any regulatory framework the solution must comply with. Don't bury this in a footnote; compliance fundamentally shapes architecture decisions.

Hosting and infrastructure preferences. Do you have preferred cloud providers? Infrastructure-as-code requirements? SSO integration with your identity provider?

Browser and device support. Modern evergreen browsers only, or do you need to support older browsers for specific client segments?

What to leave to the vendor

Specific frameworks (unless you have a strong reason — team expertise, existing system integration, organizational standards), hosting architecture choices (unless you've standardized on specific providers), and front-end technology choices (vendors will recommend based on your project profile) are all best left to the vendor's expertise.

The best briefs give vendors the constraints they must work within and the problems they must solve — then let them bring their expertise to the choices in between. For B2B applications specifically, vendors have strong opinions about architecture based on the integration complexity B2B products typically require — and those opinions are worth more than arbitrary framework preferences you impose before proposals arrive.

Interesting fact 👀

The Project Management Institute's 2023 Pulse of the Profession report found that 37% of projects fail primarily due to unclear requirements and objectives — making requirements clarity the single largest controllable factor in project success. Organizations with mature requirements practices waste 28 times less money than those without. Source: Project Management Institute, 2023

Criterion 5 — Budget & Timeline Honesty

The most counterproductive brief-writing pattern is hiding budget to "see what vendors quote." This tactic feels clever and is actually self-defeating.

Why hidden budgets produce worse proposals. Without budget context, competent vendors quote ranges — often wide ones — which gives you less information, not more. They can't tell whether you're shopping for a $30K minimum-viable version or a $200K enterprise build. The quotes you receive will reflect that uncertainty, and comparing them becomes harder.

Why sharing budget produces better proposals. Vendors given a budget range can propose the best solution achievable within it — making scope tradeoffs that reflect your priorities. You get proposals that are comparable (all targeting the same budget) and that demonstrate how each vendor thinks about tradeoffs.

What to share about budget

A realistic range. "$75K–$125K" gives vendors a bracket to work within. Avoid fake precision ("$87,500") and avoid absurd ranges ("$50K–$500K").

What's included. Does your budget cover design, development, content, project management, launch support? Or just development? Be explicit.

Future-phase budget. If this is phase 1 of a larger initiative, mention it. Vendors will propose differently for a one-time project versus a long-term partnership.

Non-negotiable constraints. "Budget is fixed; scope is flexible" produces different proposals than "scope is fixed; budget has 20% flexibility." Tell vendors which lever can move.

What to share about timeline

Target launch date and why. "We need to launch by Q3 2026 because that aligns with our annual conference" is more useful than "as soon as possible."

Internal resource availability. Will you have a dedicated internal project lead, or will this compete with other responsibilities? Be honest — vendors plan accordingly.

Approval cycle realities. If every design deliverable needs 2-week legal review, say so. Vendors who learn about these cycles mid-project can't replan around them.

Seasonal constraints. If you need the site live before a product launch, conference, or regulatory deadline, flag it.

The projects that go well have honest budgets and timelines from the start. Projects that hide these factors to "negotiate harder" consistently end up with worse outcomes, worse vendor relationships, and — ironically — worse financial results.

Criterion 6 — Deliverables & Success Metrics

The final structural criterion is the one most buyers conflate with outcomes: deliverables and success metrics.

Deliverables

List the specific artifacts you expect the vendor to produce — both during the project and at its completion.

During the project: discovery findings document, information architecture and sitemap, wireframes (low-fidelity and high-fidelity), visual design comps (for key page types), interactive prototypes, design system documentation, and development progress demos (at agreed milestones).

At project completion: fully functional production deployment, admin training documentation, technical handoff documentation (architecture diagrams, deployment runbooks, dependency lists), source code access (with agreed ownership terms), launched analytics and monitoring, and post-launch support agreement (scope, duration, rates).

Success metrics

Deliverables confirm the vendor built what they said they'd build. Success metrics confirm what they built actually works. The distinction matters.

Leading indicators (measurable within 2–4 weeks post-launch): page load speed, mobile performance scores, accessibility scores, uptime, error rates.

Lagging indicators (measurable over 3–6 months): conversion rate changes, traffic growth, user engagement depth, support ticket volume, internal team productivity gains.

Business outcomes (measurable over 6–12 months): revenue impact, lead quality improvements, customer acquisition cost changes, retention improvements.

Require vendors to acknowledge these metrics in their proposals — to commit to what they'll measure, how they'll report, and what they'll do if metrics miss targets after launch. Vendors who can't articulate measurement plans aren't accountable to outcomes. Vendors who can are the ones you want.

Making the Final Decision: Your Brief Template

The ideal brief is 8–15 pages — long enough to provide real information, short enough that serious vendors will actually read all of it.

The recommended structure

1. Executive summary (1 page). What you're doing, why, and what you need from vendors.

2. Company context (1 page). Who you are, what you do, what stage the business is in.

3. Project objectives & outcomes (1–2 pages). The business problems, success criteria, and measurable targets.

4. Scope (2–3 pages). In scope and out of scope, structured as defined above.

5. User context (1–2 pages). Primary users, their goals, and existing research.

6. Technical requirements & constraints (1–2 pages). Current stack, integrations, performance targets, compliance.

7. Budget & timeline (1 page). Ranges, constraints, and flexibility.

8. Deliverables & success metrics (1 page). What you expect to receive and how success will be measured.

9. Evaluation criteria & process (1 page). What you'll judge proposals on, timeline for decisions, contact information.

What to include in the evaluation criteria section

Tell vendors exactly how you'll evaluate proposals: what weight you'll put on price vs. methodology vs. team vs. portfolio; what specific examples you want to see (case studies in your industry, similar project types, post-launch outcomes data); how many vendors you're contacting and when you'll shortlist; what the next stages look like (clarification calls, finalist presentations, reference checks); and who the decision-makers are and when they'll be involved.

This transparency saves everyone time. Vendors can invest appropriately in their responses. You get better-targeted proposals. And you signal that this is a serious, structured procurement — which attracts serious, structured vendors. The connection between brief quality and project management execution through every subsequent phase is direct: briefs that prepare for governance produce projects that maintain it.

What to Communicate About Budget

Sharing budget doesn't mean giving vendors a blank check. Structure your budget communication to get useful proposals while maintaining negotiation flexibility.

The three-tier approach

Share budget in three pieces:

1. Fixed elements. "The total program budget is $150K. This is non-negotiable."

2. Flexible elements. "Within that budget, $30K is reserved for discovery and strategy work. The remaining $120K covers design and development. We have 10% flexibility in how these allocate if the vendor recommends a different balance."

3. Future expansion. "Phase 2 is anticipated for Q1 2027 with a similar budget envelope, dependent on phase 1 outcomes."

What vendors need to know about budget philosophy

Fixed price or time-and-materials? Are you procuring a fixed-scope engagement, or contracting for capability at an agreed hourly rate?

Payment milestones? Monthly installments, milestone-based payments, or net-30 after deliverables?

Maintenance retainer? Do you want post-launch support included in the proposal, or will you procure it separately?

Technology licensing costs? Are SaaS platforms, fonts, stock imagery, or hosting costs included in the vendor's budget or yours?

The goal is to remove ambiguity about money before proposals arrive. Ambiguity here produces proposals you can't compare and relationships that start with friction.

Red Flags: Signs Your Brief Is Incomplete

Before sending the brief, test it against these red flags. If any apply, revise before distributing.

Red flag 1: No stated success metrics. If your brief describes what will be built but not how success will be measured, vendors will default to measuring themselves on "deliverables shipped." That's not the same as outcomes delivered.

Red flag 2: No budget range. If you've chosen to withhold budget, reconsider. The tactical logic for hiding it is weaker than the operational logic for sharing it.

Red flag 3: Vague user context. If your users section describes demographics but not behaviors, vendors will design for abstract users rather than real ones. Fix this before sending.

Red flag 4: Unclear decision process. If vendors can't tell from your brief how their proposal will be evaluated, they won't know what to emphasize. You'll get generic proposals instead of targeted ones.

Red flag 5: Prescribed solutions. If your brief tells vendors exactly what to build (page structure, framework choice, specific features), you're hiring an executor, not a partner. Expect execution-level thinking, not strategic thinking, in the proposals you receive.

Red flag 6: No discussion of what's outside this project. If your brief only describes what the vendor owns, you'll end up arguing about the edges. Explicitly naming what's out of scope — content production, ongoing SEO, your internal marketing team's responsibilities — prevents most of those arguments.

Red flag 7: Inflated importance of everything. If every requirement is "must-have" and every deadline is "hard," vendors will discount everything to identify what actually matters. Prioritize honestly. Must-haves, should-haves, and nice-to-haves produce better proposals than uniform urgency across all requirements.

FAQ

How long should the brief be?

8–15 pages is the sweet spot. Shorter, and you haven't included enough to enable good proposals. Longer, and vendors will skim rather than read, missing important context. A well-structured 12-page brief beats a 30-page brief every time.

Should I send the same brief to every vendor?

Yes, with one nuance: you can tailor the introduction (why you're interested in each specific vendor) and the examples you reference (case studies most relevant to each vendor's portfolio). The core structure, scope, budget, and evaluation criteria should be identical across all vendors you're considering.

How many vendors should I send it to?

Five to seven is optimal. Fewer than four, and you don't have enough comparison. More than seven, and you'll be overwhelmed by proposals — and vendors will know they have lower odds of winning, which reduces the effort they'll invest in responding.

Should I include my current website's weaknesses or be neutral?

Be specific and candid about current weaknesses. Vendors will figure them out during their own analysis anyway — sharing them upfront signals that you're a serious, self-aware client, and helps vendors propose solutions targeted at your actual problems.

What if vendors ask questions during the proposal period?

Welcome questions — they're a positive signal. Commit to a question deadline (1 week after brief distribution, typically) and share all questions and answers with all competing vendors simultaneously. This keeps the playing field level and often surfaces ambiguities in your brief you didn't notice.

Should I request a fixed-price or time-and-materials proposal?

For well-defined projects with stable requirements: fixed price. For complex projects with evolving requirements: time-and-materials with a not-to-exceed ceiling. For most mid-market projects: hybrid (fixed-price for discovery and design phases, T&M for development with scope guardrails).

What's the biggest brief-writing mistake?

Hiding information to maintain negotiation leverage — about budget, timeline, internal politics, or previous failed projects. Every piece of hidden information produces worse proposals, wastes vendor time, and gets revealed during the engagement anyway. Start honest, stay honest.

live

Want to discuss your project?

Share your vision with us, and we'll reach out soon to explore the details and bring your idea to life.

Conclusion

A good project brief is one of the highest-ROI documents you'll write. Fifteen hours of investment in the brief typically saves 50+ hours during vendor evaluation, prevents tens of thousands in scope-change disputes, and dramatically increases your chances of choosing the right partner.

The mechanics aren't complicated. State outcomes clearly. Define scope with discipline. Share user context, technical constraints, and budget honestly. Specify deliverables and success metrics. Explain how you'll evaluate proposals. Invite questions and address ambiguities before finalizing decisions.

What's hard isn't the mechanics — it's the discipline. Writing a good brief forces you to decide what you actually want, admit what you don't know, and prioritize honestly among competing goals. Most buyers skip this rigor because it's uncomfortable. The ones who don't skip it consistently get better vendors, better proposals, and better project outcomes.

If you're staring at a blank document right now, don't start with the template. Start with three conversations: with your own team (what does success actually mean?), with a trusted advisor (what are we missing?), and with one candidate vendor (what would you want to know before quoting?). Those three conversations produce the raw material that becomes a good brief — and the document writes itself from there.

How to Write a Project Brief