Scope creep and client misalignment kill more freelance data projects than bad SQL. This lesson teaches you how to write a one-page project brief that defines what's in, what's out, and what "done" looks like — before you open a single file.
Here's a scenario that plays out more often than any data freelancer wants to admit. You finish a Power BI dashboard after two weeks of work. It's clean, well-structured, and answers every question the client mentioned in your initial call. You send it over, feeling good. The client replies: "This is great, but I was expecting something we could filter by individual sales rep. Also, I thought this would connect live to our CRM, not pull from a static Excel export. Can we redo it?"
You never discussed live CRM connectivity. You never discussed rep-level filtering. But the client is absolutely convinced those were implied. Neither of you is lying — you simply had different mental pictures of what "done" looked like, and nobody wrote it down before the work started.
This is exactly the problem a freelance data project brief solves. It's a single page — sometimes two — that captures what the project is, what it isn't, what success looks like, what data you'll be working with, and who is responsible for what. By the end of this lesson, you'll know how to write one from scratch, understand why each section exists, and have a reusable template you can adapt for any data engagement. You'll also understand how to use the brief as a professional tool that builds client trust rather than just a defensive document you hide behind.
What you'll learn:
You don't need any technical knowledge to complete this lesson. If you've ever had a client conversation about a data project — even an informal one — you have everything you need to follow along. This lesson sits naturally after qualifying your client in a discovery call and before writing a formal contract. If you haven't yet thought about how you structure and price your engagements, you may find it useful to read about pricing your data projects alongside this lesson, because the brief directly informs how you scope your price.
Most freelancers skip the project brief because it feels like extra admin on top of already-done work. You've had the discovery call. You've sent the proposal. The client signed off. Why write yet another document?
The answer is that proposals and briefs do different jobs. A freelance proposal is a sales document. It's written before the client commits, and its job is to convince them you're the right person for the work. A project brief is an operational document. It's written after the client commits, and its job is to align both parties on exactly what is going to happen before anyone opens a dataset.
Think of it like ordering a custom piece of furniture. The proposal is the catalog page and the quote. The brief is the specification sheet the carpenter takes into the workshop — the one that says "oak, not pine; 180cm, not 160cm; two drawers, not three." Without the spec sheet, you get the carpenter's best guess, which may be beautiful but wrong.
Key insight
A project brief is not a legal contract. It's an alignment tool. Its value isn't in what happens if someone violates it — it's in the shared clarity it creates before work begins. Think of it as a contract's more readable, relationship-building older sibling.
Data projects have a particular alignment problem that other freelance work doesn't. A client who commissions a logo has a pretty clear sense of what a logo is. A client who commissions a "sales performance dashboard" may be imagining anything from a single-tab Excel pivot table to a live Power BI report with row-level security and automated email snapshots. The brief forces both parties to describe the same concrete thing.
Let's walk through each section in the order they appear on the page, with worked examples drawn from a realistic scenario. Our running example throughout this lesson will be a project for a fictional client: Meridian Plumbing Supplies, a regional wholesale distributor who wants a monthly sales performance report built in Power BI.
This is your two- to three-sentence plain-English description of what the project is. Avoid jargon. The test is whether someone who didn't attend your discovery call could read this and immediately understand the purpose of the work.
Example:
Meridian Plumbing Supplies requires a Power BI report that summarises monthly sales performance across their five regional branches. The report will allow the sales director and branch managers to track revenue, units sold, and gross margin by product category and salesperson. The aim is to replace an existing process where a finance analyst manually produces a spreadsheet each month.
Notice what this section does: it names the client, names the tool, describes the audience, and explains the business reason for the project. That last point — the business reason — is often left out, and its absence leads to problems later. When you both understand that the goal is to replace a manual monthly process, you can make better decisions together about what "good enough" looks like.
Tip
Write the project overview in a voice the client would use to describe it internally, not the voice you'd use to describe it to a fellow data professional. If the client forwards the brief to their CFO for sign-off, it should make sense without a translator.
This is the most important section in the brief, and the one most likely to be vague if you let it be. "Success" in a data project sounds abstract, but it doesn't have to be.
Start by listing the business objectives — what the client wants to be able to do that they can't do now. Then translate each objective into a concrete, testable success criterion.
Example:
| Objective | Success Criterion |
|---|---|
| Replace the manual monthly sales spreadsheet | Report is delivered to branch managers by the 3rd working day of each month without analyst intervention |
| Allow branch-level comparison | Managers can filter by branch and see their own data without seeing other branches' figures |
| Track margin by product category | Gross margin % is visible for each of the 12 product categories in their catalogue |
This table format is deliberate. It forces specificity. "The client can see margins" is not a success criterion. "Gross margin % is visible for each of the 12 product categories in their catalogue" is.
Warning
Watch out for objectives that are really aspirations dressed up as deliverables. "Improve decision-making across the business" is not something you can verify on delivery day. Push clients to describe what a decision-maker would actually do differently as a result of the report. That conversation almost always leads to a more honest and testable success criterion.
This section lists, explicitly and specifically, the work you will do. Be generous with detail here. Every line item you include is a line item the client cannot later claim was "implied."
Example — In Scope:
Write this as a bulleted list. Avoid paragraphs — they're harder to scan and easier to argue over.
This section is the one freelancers most often leave out, and it is frequently the one that would have saved them the most grief. Everything that is not listed here can be argued to be "included but forgotten." An explicit exclusion list closes that door.
Think through the adjacent work that a client might reasonably expect to be included, and exclude anything that isn't. For a Power BI project, common exclusions include:
Example — Out of Scope:
Tip
When you're unsure whether something is in or out of scope, ask yourself: "Would a reasonable client expect this to be included based on our conversations?" If the answer is "possibly," it should appear explicitly on one of these two lists. Ambiguity is where scope creep breeds.
This section describes what data you need, in what format, and when you need it. It also clarifies who is responsible for providing it. This matters enormously in practice — data projects frequently stall not because the analyst can't do the work, but because the client hasn't delivered the files.
Example:
| Data Source | Format | Provided By | Required By |
|---|---|---|---|
| Monthly sales transactions | CSV export from Sage 200 | Finance team (Sarah Chen) | 5th of each month |
| Product catalogue with category mapping | Excel file | Product manager (Tom Walsh) | Project kickoff + updated as needed |
| Branch reference data (names, regions) | Any format | Operations team | Project kickoff |
| Sample historical data for testing (Jan–Dec 2023) | CSV | Finance team (Sarah Chen) | Within 3 business days of contract signing |
Including names is intentional. "The client will provide the data" is easy to ignore. "Sarah Chen in finance will provide the monthly CSV by the 5th" creates a specific commitment from a named person.
Also include a note about data access and security:
Data handling note
All data provided by Meridian will be used exclusively for the purposes of this project. Files will be stored locally and deleted upon project completion unless otherwise agreed. No data will be shared with third parties.
If the project involves sensitive customer data, a personal data handling clause like this is not optional — and you may need more formal provisions. See legal and financial basics for freelance data consultants for a deeper treatment of data handling obligations.
A timeline section creates mutual accountability for pace. Without it, clients feel comfortable asking for updates every three days, and you have no shared reference point for whether a project is on track.
Structure this as milestones, not day-by-day tasks. Milestones are observable events — something has either happened or it hasn't. Tasks are internal planning items that belong in your own project management tool.
Example:
| Milestone | Target Date | Depends On |
|---|---|---|
| Data received and confirmed | Day 3 | Client delivers files per Section 5 |
| Data model and schema complete | Day 7 | — |
| Draft report pages complete | Day 14 | — |
| Client review period | Days 14–18 | Client feedback within 4 business days |
| Revisions complete | Day 21 | Feedback received by Day 18 |
| Final delivery and walkthrough | Day 23 | — |
The "Depends On" column does something important: it makes client dependencies visible. If the client doesn't deliver files by Day 3, they can see in writing that subsequent milestones will shift. This isn't adversarial — it's just honest project management.
Every project has things you've assumed to be true that haven't been explicitly confirmed. List them. If an assumption turns out to be wrong, this section is your early warning system — and your record that you flagged it.
Example — Assumptions:
Example — Open Questions (to resolve at kickoff):
Open questions are not a sign of incomplete preparation — they're a sign of professional thoroughness. Clients respect a consultant who knows what they don't yet know.
The brief should fit on one page if possible, two pages at most. Use a clean, professional layout:
The version number matters. If you revise the brief mid-project because the scope changes, you want a clear record of what changed and when. "v2.0 — added Executive Summary page, removed mobile layout" is a useful audit trail.
Note
You don't need expensive document software for this. A well-formatted Word document, Google Doc, or even a Notion page works fine. What matters is that it looks intentional and professional, not that it was produced in a specialist tool.
Writing the brief is only half the job. The other half is making sure the client actually reads it and agrees with it — which means you can't just email it as an attachment with "please review."
Schedule a 20-minute kickoff call specifically to walk through the brief together. Share your screen and read each section aloud, pausing to ask confirming questions:
That last question is the one that saves the most heartache. Clients often read an exclusion list and feel a small but important jolt of "wait, I assumed that was in." The kickoff call is the right moment to surface that, not three weeks later when you're presenting the finished work.
Once the client confirms they're happy with the brief, ask them to reply to the email thread with a simple "Confirmed, I agree with the project brief dated [date]." You don't need a formal signature for a one-page brief, though for larger engagements you should absolutely have a signed contract. A written confirmation in an email thread is sufficient for alignment purposes.
For a deeper look at building the entire client onboarding experience around documents like this, building a freelance data client onboarding system walks through the welcome pack and first-week process in full.
Take a past or hypothetical data project and write a complete project brief using the seven-section structure from this lesson. If you don't have a client project to draw from, use this scenario:
Scenario: A marketing agency wants you to build a Google Sheets–based reporting tracker that shows campaign performance across Facebook, Google, and LinkedIn ads. They have four clients whose data is currently in separate spreadsheets maintained by an account manager. They want a consolidated view that shows cost per lead by platform and client.
Your exercise:
When you're done, read it aloud as if you were walking a client through it on a call. Notice where you stumble — those are the sections that need more clarity.
Mistake: Writing the brief after the work has started
The brief only works as an alignment tool if it's written before work begins. Written after the fact, it reads as justification rather than agreement, and clients treat it accordingly. Make the brief the first deliverable of every engagement — even if it means a short delay before you open any files.
Mistake: Using technical language in the success criteria
"The DAX measures will calculate correctly across all date relationships" is not a client success criterion — it's an internal quality standard. Success criteria should describe what the client will be able to do or see, not how your data model will function.
Mistake: Listing inclusions but not exclusions
The exclusion list is the one that prevents scope creep, which is one of the most damaging dynamics in freelance client relationships. An inclusion list without an exclusion list is an open invitation: "anything not on this list is fair game." Always write both.
Mistake: Leaving data delivery responsibilities vague
"Client will provide data" is not specific enough. Name who provides it, in what format, and by when. If the client doesn't deliver data on time, the brief makes it clear whose side the delay is on.
Mistake: Treating the brief as a legal weapon rather than a working document
Some freelancers write briefs that read like legal notices — stiff, defensive, full of cover-your-backside language. Clients notice this tone, and it sets a transactional and adversarial atmosphere before work has begun. Write the brief as if you're both collaborating to describe the project accurately, because that's exactly what you're doing.
Warning
If a client refuses to engage with the brief — won't read it, won't confirm it, dismisses it as "unnecessary paperwork" — treat that as a signal worth taking seriously. Clients who resist alignment documents before the work often resist accountability conversations during the work. This is covered in depth in the lesson on qualifying clients before you pitch.
A freelance data project brief is a one-to-two page document written after the client commits to a project and before any technical work begins. It contains seven sections: a plain-English project overview, measurable success criteria, an explicit list of what's in scope, an explicit list of what's out of scope, a data and access requirements table, a milestone timeline with dependencies, and a list of assumptions and open questions.
The brief works because it forces both parties to describe the same concrete project in writing. It prevents the "I thought that was included" conversations that derail even well-intentioned engagements. And when you walk a client through it on a kickoff call, it also builds trust — because clients can see that you've thought the project through carefully before touching a single dataset.
Once you have a template that works, the brief takes about 30–45 minutes to write for a typical project. That time investment will save you multiples of it in revision rounds, scope arguments, and difficult client conversations.
Where to go next: