Questions to Ask a Power BI Consultant Before You Sign

What should you ask about scoping before any work starts?

Ask what they need from you before they can estimate the job. A consultant who names specific inputs — a sample extract, a list of tables, read access to a test workspace, the names of the people who will actually use the report — has scoped work like yours before. One who returns a number on the first call has priced a guess, and guesses get corrected in your direction.

Ask exactly this:

• “What do you need from us before you can put an hours estimate on this?”
• “Which part of what I just described would you push back on?”
• “What is explicitly out of scope in this estimate?”

Why it matters. Scope is where a Power BI engagement is won or lost. Almost every overrun traces back to a request that was never written down precisely enough to argue about — “a sales dashboard” can mean four visuals on one page or a governed model feeding nine departments.

A strong answer sounds like: they list the discovery inputs, they disagree with at least one thing you asked for and explain why, and they volunteer the exclusions before you ask. Pushback on the first call is a buying signal, not a red flag — it means they are picturing the build.

Walk away if you hear: a flat quote with no questions about your data; “we’ll work the details out as we go”; or a refusal to name anything as out of scope. An estimate with no exclusions is not a fixed price — it is an unpriced argument scheduled for later.

How do you test a consultant's data modeling method?

Ask how they would structure the model before they have seen a byte of your data. The answer you want contains the words “star schema”: a fact table per business process, dimensions that describe it, and a dedicated date table. It is the shape Microsoft's own guidance recommends, and it is the single biggest predictor of whether the report is still fast and trustworthy a year from now.

Ask exactly this:

• “Will this be a star schema? What do you expect the fact and dimension tables to be?”
• “Where does the date table come from, and will you mark it as a date table?”
• “How would you handle the many-to-many relationship between our orders and our budget lines?”
• “What would you do differently if this model has to grow to five years of history?”

Why it matters. A flat, wide table imported straight from a system export works fine on demo data. It gets slow, ambiguous, and impossible to extend the moment a second business question arrives — and the fix is a rebuild you pay for twice. Microsoft's star schema guidance for Power BI (opens in new tab) is public, short, and worth reading before the call so you can hear whether the answer matches it. Our own Power BI star schema best practices guide covers the same ground in plain English.

A strong answer sounds like: they guess at your fact and dimension tables from a two-minute description, they insist on a separate date table rather than using the date column on your sales table, and they treat bidirectional filtering as a last resort they can justify.

Walk away if you hear: “Power BI can handle any shape”; “we’ll just flatten it in Power Query”; or an inability to explain, in one sentence, why a flat table causes problems later. This is the question that most cleanly separates people who have maintained a model from people who have only built one.

What questions expose real DAX depth?

Skip the function trivia. Anyone can name SUM and AVERAGE. Depth shows up in how someone explains filter context — what CALCULATE actually does, why a measure can be right on every row and wrong on the total, and when a calculated column is the correct tool instead of a measure.

Ask exactly this:

• “Explain what CALCULATE does to filter context, in plain English, to someone non-technical.”
• “A measure is correct on every row but wrong on the total. What do you check first?”
• “When would you use a calculated column instead of a measure — and when would you refuse to?”
• “How would you build year-to-date and prior-year comparisons for us?”

Why it matters. Most “the numbers are wrong” escalations are not data problems; they are filter-context problems written by someone who copied a formula that worked in a different model. The totals question in particular is a fast, honest filter: it is the first thing a working consultant has debugged, and it is unanswerable from memory if you have not.

A strong answer sounds like: CALCULATE described as changing the filter context a measure evaluates in; the totals problem diagnosed as a non-additive measure needing an iterator such as SUMX rather than a bigger SUM; calculated columns reserved for things you need to slice or group by, kept out of the model where a measure will do; and time comparisons built on a marked date table with the standard time-intelligence functions instead of hand-rolled date arithmetic.

Walk away if you hear: a list of function names with no mention of context; “I’d just add a column for it” as the answer to everything; or Power BI blamed for the wrong total. The last one is the tell — the total is almost never Power BI's fault.

Who owns the gateway and the refresh schedule after go-live?

Ask this during vetting, not after the first 6am refresh failure. Any on-premises or private-network source needs a data gateway installed on a machine, registered under an account, storing credentials that somebody has to rotate. If that machine is the consultant's laptop and that account is their personal Microsoft account, you have not bought a report — you have bought a dependency with a heartbeat.

Ask exactly this:

• “Which machine will the gateway run on, and who owns the account it is registered to?”
• “Whose credentials are stored on the data source, and what is the process when that password changes?”
• “Who receives the refresh-failure notification — only you, or our team as well?”
• “What is the refresh window, and what is the plan when a refresh starts running longer than it?”

Why it matters. Refresh is the part of a Power BI estate that fails on its own schedule, months after everyone has moved on. Microsoft's on-premises data gateway documentation (opens in new tab) is explicit that the gateway is infrastructure — it belongs on a machine that stays on, patched, owned, and monitored by the organisation that depends on it.

A strong answer sounds like: the gateway on a server or always-on machine you control, registered to a service account rather than a person, credentials your admin can rotate without calling anyone, failure notifications going to your team and theirs, and a written recovery procedure handed over with everything else.

Walk away if you hear: “I’ll host the gateway for you” offered as a convenience; “we’ll register it under my account, it’s simpler”; or refresh treated as an afterthought to sort out once the visuals are approved. Convenience now is a hostage situation later.

What should you ask about row-level security and governance?

If anyone will see a report they must not see all of, ask two questions: how the roles will be defined, and how each role will be tested before release. Roles are easy to create and quietly easy to get wrong. The testing answer is what separates a consultant who has shipped row-level security from one who has read the documentation page.

Ask exactly this:

• “Static or dynamic roles for our case, and why that one?”
• “How will you test each role before release, and will we get the test evidence in writing?”
• “What happens to row-level security for someone who is a member or admin of the workspace?”
• “After handover, who reviews role membership when someone joins or leaves?”

Why it matters. A security failure in a report is not a bug you file — it is a manager seeing another department's payroll. Microsoft's row-level security documentation (opens in new tab) is clear that RLS restricts data for users with read access; people with edit permissions on the workspace are not filtered by it, which is exactly the detail a shallow answer misses.

A strong answer sounds like: dynamic roles driven by a user-mapping table and USERPRINCIPALNAME when the list of people changes; static roles when it genuinely does not; testing with “View as role” and a real second account before release; and a plain statement that workspace members with edit rights bypass RLS, so viewer-level access is the correct sharing model.

Walk away if you hear: “we’ll add security at the end”; a plan to publish a separate copy of the report per manager as anything other than a stopgap for a handful of people; or a testing answer that amounts to “we’ll check it looks right.”

Which handover artefacts should you demand in writing?

Ask for the deliverable list in the agreement, not in the kick-off email. The test is simple: if this consultant became unavailable next month, could a competent replacement pick the work up without starting over? Everything on the list below exists to make the answer yes.

• The report and model source files (.pbix or .pbip), delivered to you, not linked from their drive
• The semantic model published in your tenant, in a workspace your admin owns
• A data dictionary: every measure, what it means in business terms, and its DAX
• A refresh and gateway runbook: sources, credentials owner, schedule, what to do when it fails
• Role definitions and RLS test evidence, if the report is secured
• A short walkthrough recording for whoever inherits it internally

A strong answer sounds like: they offer most of this before you finish the question, and they can describe how they document measures because they already have a format for it.

Walk away if you hear: “the report is the deliverable”; files kept in the consultant's own tenant or personal storage; or documentation offered as a later add-on with no price. Documentation being chargeable is reasonable. Documentation being unavailable is a lock-in strategy.

What does post-go-live support actually include?

Week five is where Power BI engagements quietly fail. The build is signed off, the consultant has moved on, and then a source system changes a column name. Ask who fixes that, how fast, and whether it costs you a new statement of work to find out.

Ask exactly this:

• “Where is the line between a defect you fix and a change request I pay for — and who decides?”
• “What is your response time when a scheduled refresh breaks?”
• “Is there a warranty period after go-live? How long, and what does it cover?”
• “How do I buy twenty minutes of your time in three months without starting a new project?”

Why it matters. The last question is the most revealing one on this page. Plenty of firms are structured so that small work is uneconomic for them — a minimum engagement, a new scoping cycle, a four-week start date. That structure is fine for a build and terrible for a living report, and you find out which you bought at the worst possible moment.

A strong answer sounds like: a written definition of a defect, a named warranty window, a response commitment for refresh failures, and a low-friction way to buy small amounts of senior time afterwards — a retainer, a prepaid block, or an hourly arrangement with a sane minimum increment.

Walk away if you hear: “just email me” with no terms attached; support available only as a twelve-month retainer you do not need; or a minimum billing increment that turns a twenty-minute fix into half a day. If ongoing help is the plan, our Power BI consultant vs in-house analyst comparison is a useful sanity check on whether an outside team is the right shape at all.

How should you question price, estimates, and change control?

Ask what the number is made of. A credible quote breaks into named tasks with hours against each, states the rate behind them, and says in advance what happens when a task runs long. A single lump sum with no line items is not simplicity and it is not a discount — it is a place for the overrun to hide.

Ask exactly this:

• “What hourly rate is behind this, and how many hours are against each deliverable?”
• “If a task takes fifty percent longer than estimated, who absorbs that?”
• “Is there a project minimum? Do unused hours expire?”
• “What specifically triggers a change order, and what does one cost to raise?”

Why it matters. Rates for Power BI work span a wide range, and the headline number is a poor guide on its own — a senior consultant at a higher rate who gets the model right the first time routinely costs less in total than a cheaper one whose work has to be redone. Our breakdown of Power BI consultant cost per hour covers the bands you will actually be quoted, and Power BI freelancer vs consulting agency covers how the same work gets priced very differently depending on who is selling it.

A strong answer sounds like: hours per deliverable, an explicit rule for overruns, and a plain answer on minimums and expiry. Consultants who work this way tend to volunteer it, because it is the part of the deal they are proud of.

Walk away if you hear: a refusal to break the number into hours; “unused hours expire at the end of the quarter”; or a minimum engagement several times larger than the job you described. The expiry clause is the one buyers most often miss and most often regret.

Which answers should end the conversation?

Use the table below as a one-page scorecard on the call. Take the left two columns into the meeting, write what you actually heard next to each row, and compare it against the right two columns afterwards — when your notes are still honest and the pitch has worn off.

What should the consultant be asking you?

A vetting call runs both ways, and the questions coming back at you are as diagnostic as the answers. Someone who takes the order without probing is planning to build what you said rather than what you need — and the difference surfaces at user acceptance testing, when it is expensive.

Expect to be asked: who makes the decision this report is supposed to inform, and what they do today instead; which number, if it were wrong, would cause a real problem; whether anyone has tried to build this before and what happened; which systems hold the data and who administers them; and who on your side will own the report after go-live. If none of that comes up, you are talking to a pair of hands, and you will still need someone to do the thinking.

Scoping. Every request gets a written scope-and-hours estimate before any work begins. We ask for a sample of the data and the names of the people who will use the report, and we say what is out of scope in the same email. You approve the estimate; hours are deducted only for approved work.

Modeling and DAX. Star schema by default, with a dedicated date table, and measures rather than calculated columns wherever a measure will do. Senior-led delivery — 20+ years on the Microsoft platform — which is the whole reason we can quote hours rather than a padded lump sum.

Refresh, gateway and security. The gateway runs on your infrastructure under your service account, credentials stay with your admin, and refresh-failure alerts go to your team as well as ours. RLS roles are tested with “View as role” and a real test account before release, and we hand over the evidence.

Handover. Everything lives in your tenant, in a workspace your admin owns: source files, the semantic model, a measure dictionary, and a refresh runbook. There is no licence to us and no hosting dependency — if you never call us again, nothing breaks.

Support and price. Prepaid Flex hours: buy a block, email a request, get a scope estimate, approve, and we deliver — most tasks in 3–5 business days after approval. Hours never expire, there is no project minimum, and there is no contract or recurring charge. Starter is 20 hours at $125/hr ($2,500), Growth is 40 hours at $115/hr ($4,600), and Power is 80 hours at $100/hr ($8,000). Rates start from $100 per hour.