A good brief for a Power BI consultant answers two questions: which decisions should this reporting support, and who makes them. Everything else is detail. Bring those two answers, a list of where your data lives, the name of the person who can grant access, and one example of a number nobody currently trusts. Leave behind the chart mock-ups, the forty-page requirements document and the screenshot of a competitor's dashboard.
That's the whole checklist, and you can assemble it in an afternoon. The rest of this post is why each item earns its place, because the reasoning is what stops the project drifting later.
What are the two questions your brief must answer?
Which decisions should this reporting support? Not which numbers you'd like to see. Which decisions get made, by whom, how often, that better information would improve. "The ops manager decides every Monday which orders to chase" is a brief. "We'd like visibility of orders" is a mood.
This question does more work than everything else combined, because it's the difference between a report that gets opened and a report that gets built. A consultant who knows the Monday decision can design a page that answers it in seconds. A consultant given "visibility" will build you visibility: two hundred visuals, technically accurate, opened twice.
Who makes those decisions? Named people, because they're the users the design must serve, they're the ones who must trust the numbers, and one of them needs the authority to answer definition questions during the build. Projects don't stall on technology; they stall waiting for someone to rule on what "active customer" means. Knowing on day one whose ruling counts is worth weeks.
What should you bring to the first conversation?
Beyond the two questions, four things, none of which need to be polished.
A list of where the data lives. System names and rough purpose is plenty: "Business Central for finance, HubSpot for the pipeline, a scheduling spreadsheet that runs the warehouse". You don't need to know versions or table names. You do need to mention the spreadsheet, because there's always a spreadsheet, it's always load-bearing, and it's always the thing that surprises the estimate when it surfaces in week three.
The name of the person who can grant access. Your IT manager, your managed service provider, whoever holds the keys. Access is the most common cause of dead time at the start of a project, and it's pure admin. Knowing who to ask, and warning them it's coming, can save a fortnight; I've covered how it stretches timelines elsewhere and it's the most preventable delay on the list.
One number nobody trusts. Every business has one: the margin figure that finance and sales calculate differently, the stock count that's always wrong on a Monday. Bringing it does two jobs. It shows the consultant where the definitional bodies are buried, and their reaction tells you about them. A good one leans in, because one number, several answers is usually the real project. One who waves it away is planning to build on sand.
What you tried before, honestly. The abandoned dashboard, the report the last person built that nobody opens. Not to assign blame, but because the failure modes of the last attempt are the cheapest design input available for this one.
What should you leave out of a Power BI brief?
The counterintuitive part: the things people spend the most time preparing are the things worth skipping.
| What | Bring or skip | Why |
|---|---|---|
| The decisions the reporting must support | Bring | It's the design brief. Everything hangs off it |
| Named decision-makers, one with authority to rule on definitions | Bring | Unanswered definition questions are the top cause of drift |
| Systems list, spreadsheets included | Bring | Scope and price honesty depend on it |
| The person who can grant access | Bring | The most preventable delay in the industry |
| A number nobody trusts | Bring | Marks where the real work is, and tests the consultant |
| A wishlist of every field anyone might want | Skip | Guarantees an overbuilt model nobody opens |
| Chart-by-chart mock-ups | Skip | Prescribes a solution before the problem is understood |
| A competitor's dashboard screenshot | Skip | Their decisions aren't yours; it anchors design on the wrong brief |
| A forty-page requirements document | Skip | Ages badly, reads as scope, and buries the two real questions |
| Your budget ceiling, in the first sentence | Hold | Share the bracket once you've heard how they'd scope it |
The wishlist deserves its own sentence, because it feels like diligence. Circulating "what would everyone like to see?" produces a list of everything anyone could imagine wanting, and a consultant who builds to it delivers an estate sized for the imagined power user rather than the Monday decision. The wishlist isn't a brief. It's the opposite of one: a brief is what you've decided matters, a wishlist is the decision not yet made, outsourced.
Mock-ups have a subtler cost. Hand a builder a picture and you'll get the picture, faithfully, including its mistakes. What you want from a good consultant is their design judgement applied to your decisions, and a mock-up switches that off. Describe the question; let them propose the page.
What access will a consultant actually need?
You don't need to grant anything before the first conversation, and be wary of anyone who asks. But it helps to know what a reasonable request looks like when it comes.
Expect: read-only access to the source systems in scope, or an export while permissions are sorted; somewhere agreed for the work to live, usually a workspace in your Power BI tenant; and a named contact for access questions. Read-only matters and a decent consultant will volunteer it: reporting work never needs the ability to change your source data, so nothing they do can break your systems.
For my own engagements, the pattern is the same and published: on a build, access gets agreed in scoping and the work lands in your tenant, documented, with no lock-in. If sharing live systems makes you nervous on a first engagement, say so; an export-first start is a perfectly good way to begin, and an NDA before real data moves is normal, not awkward.
What should the consultant be asking you?
A brief is a two-way test, and their questions tell you more than their portfolio.
Good signs: they ask about decisions and who makes them, how you'd know the numbers were right, what happens at month end, which reports people actually open today, and what happened to the last attempt. Best of all is the consultant who narrows scope in the first conversation, because "which of these can we drop from phase one?" is what caring about adoption sounds like.
Warning signs: the first question is which visuals you want, real data is waved off as unnecessary for an estimate, everything on your wishlist is possible with no push-back, and nobody asks who'll answer questions during the build. Anyone who quotes a fixed price for a system build before understanding your data isn't confident, they're pricing blind, and one of you will pay for it.
How does a good brief change the price?
Directly, because uncertainty is priced in, always. A consultant quoting against vague scope either pads the number to cover the unknowns or bids low and recovers it in change requests. Both are expensive; the second is also unpleasant.
A brief with the decisions named, the systems listed and an access owner identified shrinks the unknowns, which is what makes honest fixed pricing possible: my £9,500 three-week sprint can be a fixed number precisely because its scope is capped and those questions get answered in scoping. And if you can't answer the two questions yet, that's not a failed brief, it's a different starting point: a £950 Health Check on an existing estate, or a discovery conversation on a new one, exists to build the brief with you. For calibrating quotes once you have one, what Power BI work costs in the UK has the published numbers.
Common questions
What should a Power BI project brief include?
Five things: the decisions the reporting should support, the named people who make them, a list of the systems and spreadsheets holding the data, the person who can grant access, and an example of a number nobody currently trusts. That's enough for a serious first conversation and a meaningful estimate. Length is no virtue; a page that answers those beats forty pages that don't.
Do I need to know what charts or dashboards I want?
No, and it's usually better if you don't prescribe them. Chart choice is the consultant's craft; your part is the questions the charts must answer. Describe the Monday decision and let them propose the page. If you hand over mock-ups, you'll get your mock-ups back, including their flaws, with the consultant's design judgement switched off.
How technical does my brief need to be?
Not at all. System names and what they're used for is plenty; nobody expects table names or data types from a buyer. The technical discovery is the consultant's job in scoping. The parts only you can supply are the business parts: the decisions, the people, and where the bodies are buried.
Should I share real data before signing anything?
A sample, under an NDA, once you're in serious scoping: yes, and it's in your interest, because estimates made without seeing data are guesses with confidence. Full system access can wait until an engagement starts, and should be read-only when it comes. Be more wary of a consultant who insists real data is unnecessary for a fixed quote than of one who asks to see some.
What if we don't know what we want yet?
Say exactly that, because it changes the right starting point rather than disqualifying you. If you have an existing estate, a scored review tells you where you stand before you brief anyone on where to go. If you're starting fresh, a discovery conversation exists to find the two questions with you. What to avoid is disguising "we don't know" as a wishlist, which commissions an expensive answer to an unasked question.
Should I tell a consultant my budget?
Share the bracket once you've heard how they'd approach the scope, rather than opening with a ceiling. Hearing their scoping first tells you whether they think in phases and where they'd cut, which is exactly the judgement you're hiring. Then be straight about the bracket, because a good consultant shapes scope to it honestly, and published pricing helps you sanity-check what a bracket should buy.
Who from our side needs to be involved?
Three roles, sometimes one person: a sponsor who owns the outcome, a decision-maker with the authority to rule on definitions within a day or two, and whoever controls system access. The middle one matters most and is most often missing. A project with a definitions committee moves at the speed of the committee.
My prices referenced above are as published on the linked service pages, September 2026. If you'd rather pressure-test your brief before sending it to anyone, the free 20-minute intro call is a reasonable place to do it, and I'll tell you if the honest answer is that you're not ready to brief anyone yet.