What to Ask a Power BI Consultant Before Your First Dashboard Project

Hiring a Power BI consultant feels like a straightforward step. You have data, you want dashboards, and the consultant’s job is to build them. But many first-time clients discover the hard way that the questions they didn’t ask before the project started are the ones that cost them later: extended timelines, dashboards that don’t reflect the right numbers, metrics that two departments calculate differently, and tools that nobody actually uses 3 months after go-live.

Many Power BI project risks begin before development, particularly when scope, data readiness, KPI definitions, or user requirements remain unresolved. The build itself is rarely the issue. What happens in the conversations before the first line of DAX is written determines whether the project delivers anything useful.

This guide covers the questions that matter most before you commit to a Power BI dashboard project, what good answers look like, and which responses should make you pause.

TL;DR

Before you sign a Power BI consultant engagement, you need clear answers to 5 categories of questions: the consultant’s credentials and track record; how they assess your data before they quote; how they scope, price, and handle timeline changes; what technical depth they bring to data modelling and governance; and what handover, documentation, and post-launch support look like. Many Power BI project risks begin before development, particularly when scope, data readiness, or KPI definitions remain unresolved. The consultant who asks the most questions about your business before talking about dashboards is usually the one worth hiring. The one who jumps straight to visuals and delivery dates without asking about your data sources, your KPI definitions, or your user base is a risk.

Why the questions you ask before hiring a Power BI consultant matter

Problems that surface mid-build commonly trace back to decisions, assumptions, or conversations that didn’t happen early in the project. According to analysis published by BusinessCloud on BI project failure patterns, “the cheapest moment to rescue a BI project is before anyone builds anything.” Failure doesn’t typically happen during the build. It happens when the brief wasn’t specific enough, when data readiness was assumed rather than verified, or when the people who would actually use the dashboard weren’t involved in defining what it should show.

This is especially true for first-time Power BI projects, where neither the client nor the consultant has a baseline of working together. The consultant doesn’t yet know where your data lives, how clean it is, or how your organisation defines the metrics you want to track. You don’t yet know how the consultant works, what they’ll need from you, or how they’ve handled similar projects. That knowledge gap closes through questions, and the quality of those early conversations shapes everything that follows.

A Power BI consultant who asks sharp questions about your business before talking about dashboards is demonstrating something important: they understand that technical work follows the business requirements, not the other way around. The ones who jump straight to delivery timelines and visual mockups before they’ve seen your data are showing you something important too.

Questions about credentials and track record

Before evaluating a Power BI consultant technically, verify that their experience is real and relevant. The Microsoft partner ecosystem is large, and credentials vary widely in what they actually represent.

Ask for their Microsoft Solutions Partner designation. Microsoft Solutions Partner designations are area-specific and assessed across 3 dimensions: performance, skilling, and customer success. The designation most relevant to Power BI and analytics work is Data & AI. A generic Solutions Partner label without specifying the area tells you less than you might expect. When a firm claims partner status, ask which specific designation it holds and verify the certifications held by the people who will actually work on your project, not how many certified staff the company employs across all engagements.

Ask for case studies in your sector. General Power BI experience doesn’t automatically transfer to your industry. A consultant who has built dashboards for financial services firms will be familiar with the data structures, compliance requirements, and KPI definitions common in that space. One without that background may build technically correct dashboards that don’t reflect how your industry actually measures performance. Ask for 2 or 3 case studies from clients in your sector and follow up with those clients directly.

Ask who specifically will be on your project. Consulting firms often pitch with senior staff and deliver with junior staff. Before signing, confirm the names and credentials of the people who will do the actual work. Ask to meet them during the evaluation process. A hesitation to introduce the delivery team before the contract is signed is worth noting.

Ask for references and speak with them directly. According to SR Analytics’ guidance on selecting a Power BI consultant, the most useful reference questions aren’t “was it a good experience?” They’re: what went wrong and how was it handled? Would you use them again for a more complex project? Did the people who sold the engagement deliver it? Those answers tell you far more than a polished case study.

Questions about your data before the project starts

Data readiness is the most consistent hidden cost driver in any Power BI engagement. Consultants who quote a project without first assessing your data sources are either guessing at the scope or planning to surface the real cost later through change orders.

A capable Power BI consultant will ask you several questions before they quote. If they don’t, ask them why they haven’t.

What they should ask you

The consultant should want to know where your data lives: ERP systems, CRM platforms, spreadsheets, cloud databases, on-premises servers, or a mix. They should ask how data is currently extracted and whether that process is automated or done manually before each reporting cycle. They should ask whether your key metrics are defined consistently across departments, or whether “revenue” or “project utilisation” means different things to different teams. They should ask whether you’re aware of any existing data quality problems.

Clean reporting data typically needs to be accurate, complete, consistent across departments, updated frequently enough to act on, standardised in format, and accessible without manual exports before each refresh. If your data doesn’t meet those conditions going in, the dashboard reflects that. A consultant who doesn’t check is building on an untested foundation.

What you should ask them

Ask the consultant directly: what’s your process for assessing data readiness before you start building? A good answer describes a discovery phase that happens before any modelling work begins. Ask whether data preparation work is included in their quoted scope or billed separately. Ask what happens if they find significant data quality issues during the project. If the answer is a change order without a clear process, that’s useful information.

Ask whether they’ve worked on projects where poor source data extended the timeline. Ask how they handled it. The answer should describe a clear escalation path, a defined remediation process, and honest communication with the client about the impact on cost and delivery. An answer that minimises data risk or implies it rarely happens is not a reassuring one.

Questions about project scope and timeline

Scope is where Power BI engagements most often go wrong for first-time clients. A dashboard that sounded clearly defined in the sales conversation can turn out to mean very different things to the client and the consultant. Getting specific about scope before the work starts protects both parties.

Understanding what’s included

According to timeline data published by Perceptive Analytics on Power BI build costs, Power BI projects fall into 3 broad tiers based on complexity. The ranges below are illustrative planning guidance; actual schedules vary by data readiness, scope, security requirements, review cycles, and team availability.

Ask the consultant which tier your project falls into and what’s driving their estimate. If they propose a 4-week timeline for a project involving 5 data sources across 3 systems with conflicting KPI definitions, ask them to walk through that logic. Ask what a change in data complexity would do to the timeline.

Ask how scope changes are handled. Every Power BI engagement will surface something unexpected: a data source that doesn’t connect as expected, a KPI definition that requires a new calculated column, a stakeholder who wants a metric added after the initial brief. Ask what the process is for handling those changes, whether they require a formal change request, and how they’re priced. A consultant with no change management process is one who resolves ambiguity informally, which rarely works in the client’s favour.

Timeline risks to surface upfront

Ask what has historically caused timeline overruns in similar projects. According to Perceptive Analytics, the biggest drivers are data readiness problems, stakeholder misalignment on metric definitions, and governance requirements discovered mid-project. If the consultant’s answer doesn’t include at least 2 of those 3, ask follow-up questions.

Ask whether a discovery phase is part of the quoted engagement. Discovery is a defined scoping period before any modelling or development starts, where a good consultant validates your data sources, confirms KPI definitions with relevant stakeholders, maps the data model structure, and finalises scope. Engagements that skip discovery in favour of going straight to development commonly surface the same work as unplanned rework later.

Questions about technical depth

Not all Power BI consultants have the same technical depth. Tool familiarity is common. The harder skills, data modelling, DAX formula design, and governance architecture, are where experience levels diverge significantly.

According to The Sunflower Lab’s analysis of Power BI hiring mistakes, the most frequent error organisations make is hiring for visual design and tool familiarity rather than data modelling depth. “Anyone can build a chart,” the analysis notes. The harder job is turning how a business actually measures itself into one set of numbers everyone trusts, and getting that right requires strong semantic model design and accurate DAX.

Data modelling and DAX

Ask the consultant to walk you through how they approach semantic model design for a project with your kind of data complexity. They should be able to explain, in plain terms, the relationship between fact tables and dimension tables, why model design affects report performance, and how they avoid calculation errors that cause totals to shift when filters are applied.

Ask them to describe a DAX formula they’ve written recently that solved a non-trivial problem. The explanation doesn’t need to be technical, but it should be coherent. If they can’t explain the purpose and logic of a formula in plain language, they’re unlikely to be able to explain your report results to non-technical stakeholders either.

Governance and security

Ask how they handle row-level security. Row-level security (RLS) controls which data users in the Viewer role can see within a shared report, and is often appropriate when managers should see only their team’s data or when reports contain figures that shouldn’t be visible to all staff. The right security design also depends on workspace roles and source-level access controls, so ask the consultant how they design RLS alongside those other controls rather than as a standalone setting configured at the end of the project.

Ask about workspace governance: how they structure Power BI workspaces, how they manage the separation between development and production environments, and how they handle refresh scheduling and monitoring. These are the factors that determine whether your dashboards stay accurate and accessible after the consultant leaves. A consultant whose governance plan consists of “we’ll set it up and you can manage it from there” without formal documentation or handover is creating dependency.

Microsoft Fabric awareness

Microsoft Fabric, the unified analytics platform that integrates Power BI with data engineering, data science, and real-time intelligence, is now a mainstream consideration for organisations planning Power BI at scale. According to Microsoft’s documentation on Fabric and Power BI integration, Fabric brings together OneLake storage, Dataflows Gen2, and Power BI semantic models in a single environment. Ask whether the consultant has Fabric experience and how they’d incorporate it into your architecture if your data needs grow. An answer of “we’ll cross that bridge when we come to it” from a consultant pitching an enterprise engagement is not adequate.

Questions about KPI definition and stakeholder alignment

One of the most consistent causes of Power BI dashboard failure has nothing to do with the consultant’s technical skills. It’s that different parts of the organisation define the same metric differently, and nobody resolves that before the build starts.

Research published by 2WTech on Power BI dashboard failure causes identifies “too many metrics and conflicting KPI definitions” as one of the 5 root causes of dashboard projects that don’t deliver value. When finance calculates project profitability one way and operations calculates it another, a single dashboard can produce 2 different answers to the same question depending on whose filter is applied.

Ask the consultant how they handle KPI definition conflicts during a project. A good answer describes a structured process, usually a workshop or discovery session, where the consultant facilitates agreement between relevant stakeholders before any metrics are built into the model. A weak answer treats this as a client problem rather than a project risk.

Ask how they document agreed metric definitions. Every metric in a Power BI report should have a documented definition that describes exactly what it measures, what data source it draws from, how it’s calculated, and who owns it. That documentation becomes the reference point when a stakeholder questions a number 6 months after go-live. Ask whether this documentation is part of the standard engagement scope.

Questions about user adoption

A technically correct Power BI dashboard that no one uses is a failed project. According to Algoscale’s analysis of BI consulting mistakes, “adoption drives ROI,” and adoption is consistently under-planned compared to the technical work that precedes it.

Ask the consultant what their approach to user adoption looks like. The answer should go beyond “we’ll train people at the end.” It should describe early engagement with actual end users during requirements gathering, training tailored to different user types, and a plan for what happens when users run into problems after go-live.

Ask whether they identify business champions during the project. Internal champions, staff within the client organisation who are genuinely engaged with the tool and can support colleagues informally, are one of the strongest predictors of sustained adoption. A consultant who includes champion identification in their adoption plan is thinking about long-term use, not just delivery.

Ask what usage looks like 90 days after go-live on similar projects. If a consultant has data on this, or has clear observations from past clients, that’s a positive signal. If they don’t track this or haven’t thought about it, ask yourself whether their definition of “success” matches yours.

Questions about post-go-live support and ownership

The question of what happens after the dashboard is delivered is the one most clients forget to ask before signing a contract. According to research from 2WTech on why Power BI dashboards fail, dashboards built as one-time projects go stale as business needs, KPIs, and data sources change. A dashboard that was accurate on day 1 can produce misleading results 6 months later if nobody is maintaining the model and definitions.

Support arrangements

Ask specifically what a post-go-live support arrangement looks like and what it costs. The range typically includes ad-hoc support billed at an hourly rate, a retainer that covers a defined number of hours per month, and a managed service that includes proactive monitoring of data refreshes, model updates, and new report development. The right choice depends on your internal Power BI capability, but you should know what you’re committing to before the project ends.

Ask what’s covered under warranty after delivery. Some consultants include a defined period during which they’ll fix bugs or issues in the delivered work at no additional cost. Others don’t. The length and scope of that warranty period varies by firm, so treat it as a contract point worth clarifying before you sign.

Documentation and knowledge transfer

Ask what documentation you’ll receive at handover. At minimum, you should expect data model documentation describing all tables, relationships, and calculated measures; a list of all data sources and refresh schedules; a record of all agreed KPI definitions; and user guides appropriate for the different types of users in your organisation.

Ask whether they provide training to your internal team on maintaining and extending the reports. According to Algoscale’s guidance on avoiding BI consulting dependency, firms that create environments only they can maintain are a long-term cost risk. A consultant who actively transfers knowledge to your team is one you’re less likely to remain permanently dependent on.

Red flags to watch for during the evaluation

Some signals during the evaluation process are worth taking seriously before you commit.

A consultant who recommends a specific approach before they’ve seen your data or understood your business questions is not doing discovery. They’re applying a template. That might be fine for a straightforward project, but it’s a risk for anything with genuine complexity.

A bid price significantly lower than others in the field is worth interrogating. According to Algoscale’s analysis, unusually low bids typically reflect one of 3 things: scope items that are missing from the proposal and will surface as change orders, less experienced staff than the sales pitch suggested, or margin recovery planned through premium-rate support or extensions. Ask the low bidder what their proposal explicitly excludes. Compare scope completeness, not headline price.

A consultant who asks very few questions about your business before presenting a proposal is a concern. A good scoping conversation for even a mid-tier project should involve detailed questions about your data sources, your users, your metric definitions, your current reporting process, and what you want to decide differently once the dashboards are live. If those questions never come, the proposal is built on assumptions, and assumptions are where project costs grow.

Slow or vague communication during the sales process will be worse during delivery. If emails go unanswered for days or questions get deflected during the pitch, that pattern doesn’t improve once the contract is signed.

Questions to ask yourself before you hire anyone

Not all the important pre-project questions are for the consultant. Some are internal, and the answers to them affect whether any consultant can deliver value.

The most important question is: what specific business decision will this dashboard support? A dashboard built around a clear decision, whether to shift resource allocation, which clients to prioritise for renewal, where project margin is being lost, is far more likely to be used than one built to “give better visibility” into a vague area.

According to BusinessCloud’s analysis of BI kickoff failures, the right pre-project questions include: whose decision will this improve? What action should a manager take if a key figure turns red? Are the actual end users involved in shaping requirements, or are proxies speaking for them? Is time and budget allocated for training and adoption, not just the build? Who owns the content and the KPI definitions in 12 months?

If the answers to those questions are unclear internally, the project isn’t ready to start. Clarifying them is not the consultant’s job alone. It’s the internal work that makes any consultant engagement productive.

How to run a structured evaluation

Once you’ve identified 3 to 5 candidate consultants, a structured evaluation process produces better decisions than informal comparison.

Start with a written requirements brief that covers your data sources, your users, your known KPI requirements, your compliance or security needs, your internal Power BI capability, and your budget range. A consultant’s response to a clear brief tells you far more than their response to a vague one. The quality of the questions they ask in response to your brief is itself an evaluation signal.

Ask for a proof of concept using a small sample of your actual data. A time-limited pilot using a representative data extract tests real technical skill, exposes how the consultant communicates during delivery, and confirms whether the people who pitched the engagement are the ones doing the work. According to Algoscale’s evaluation guidance, a proof of concept is one of the most reliable ways to close the gap between what a consultant says they can do and what they actually deliver.

Score consultants against a consistent set of criteria: credentials and relevant case studies, data readiness process, scope and timeline logic, technical depth in modelling and governance, adoption and training approach, documentation and handover plan, and communication quality throughout the evaluation. Weighting those criteria based on your organisation’s priorities gives you a structured basis for the decision rather than a gut feel about which presentation you liked best.

Making the most of the first project

A first Power BI dashboard project is a learning exercise as much as a delivery exercise. Even a well-scoped, well-executed engagement will surface things about your data, your reporting needs, and your internal processes that you didn’t know before you started.

The organisations that get the most value from Power BI treat the first project as the foundation for a broader reporting capability, not a one-time build. They use the KPI definitions agreed during the project as the basis for a shared metric glossary. They use the governance structures put in place by the consultant as the model for future report development. They identify the internal staff who are most engaged with the tool during the project and invest in developing their skills.

According to Microsoft’s Power BI community guidance on report adoption, adoption at the organisational level happens in stages, from individual report consumers to self-service analysts to governed enterprise BI. A well-scoped first project, with the right consultant, sets the direction for that journey. The questions you ask before you start determine which direction that is.

Getting the first conversation right

A Power BI consultant engagement that starts with the right questions is one where both sides understand what success looks like, what the risks are, and what each party is responsible for. That shared understanding doesn’t happen automatically. It happens because the right questions were asked and answered before any work began.

The best consultants welcome detailed pre-project questions. They use those conversations to scope more accurately, reduce their own delivery risk, and produce better outcomes for clients. A consultant who is reluctant to answer specific questions about their process, their team, their data assessment approach, or their post-go-live support before you sign should give you pause.

According to a 2026 overview of Power BI consulting published by Smartbridge, the shift toward Microsoft Fabric and AI-assisted reporting in 2026 has raised the baseline of what a capable Power BI consultant needs to know. The right questions to ask have grown more specific as the platform has grown more capable. That’s a reason to go into the evaluation process with a prepared list, not to rely on the conversation to surface what matters.

A reporting capability that serves real decisions made by real people using real data takes more than a set of dashboards. The questions in this guide give you the tools to assess whether the consultant in front of you can deliver that.

FAQs

What is a Power BI consultant and what do they do?

A Power BI consultant designs, builds, and deploys reporting solutions using Microsoft Power BI. Their work covers connecting data sources, building semantic models, writing DAX calculations, creating dashboards and reports, configuring security and governance, and training end users. More experienced consultants also advise on data architecture, KPI definition, and adoption strategy.

How much does a Power BI consultant project typically cost?

Cost depends on project complexity. A single dashboard built on one clean data source typically takes 2 to 4 weeks of consultant time as a planning reference point. A multi-source implementation with governance runs 4 to 8 weeks. An enterprise rollout with a governed semantic model, row-level security, and organisation-wide deployment runs 8 to 12 or more weeks. Actual duration varies by data readiness, scope, and review cycles. Consulting rates vary by region and firm, so cost estimates should be compared at the scope level, not the headline number.

What credentials should a Power BI consultant have?

Look for Microsoft-certified individuals, such as those holding the PL-300 (Microsoft Certified: Power BI Data Analyst Associate) or DP-600 certifications, and firms holding a Microsoft Solutions Partner designation in Data & AI, the area most relevant to analytics work. Also verify relevant case studies in your sector and speak directly with past clients.

What questions should a Power BI consultant ask me before quoting?

A thorough consultant should ask where your data lives, how it’s currently extracted and refreshed, whether KPIs are defined consistently across your organisation, what your internal Power BI capability is, who the intended users are, and what decisions the dashboards are meant to support. If none of those questions come up, the quote is built on assumptions.

What is a Power BI discovery phase and do I need one?

A discovery phase is a structured scoping period before any development work starts. The consultant uses it to audit your data sources, confirm KPI definitions with stakeholders, map the initial data model, and finalise scope. Skipping discovery commonly surfaces the same work as unplanned rework later in the project.

How do I know if my data is ready for a Power BI project?

Data readiness means your source data is accurate, complete, consistent across departments, updated frequently enough to act on, standardised in format, and accessible without manual exports before each refresh. A consultant who does not assess data readiness before quoting is guessing at scope. Ask for a data readiness assessment as part of any pre-project scoping.

What is DAX and why does it matter for my Power BI project?

DAX (Data Analysis Expressions) is the formula language used in Power BI to build calculated measures and columns. Weak DAX design causes incorrect totals, results that shift when filters are applied, and slow report performance. Ask any consultant to explain a complex DAX calculation they have written in plain terms. The ability to do that is a signal of genuine understanding.

What is row-level security in Power BI and when do I need it?

Row-level security (RLS) controls which data users in the Viewer role can see within a shared report. It is often appropriate when regional managers or department heads should see only data relevant to their area. The right security approach also involves workspace role design and source-level access controls. Ask the consultant how they design RLS alongside those other controls rather than treating it as a standalone setting added at the end.

How long does a typical Power BI dashboard project take?

A single dashboard on clean data takes 2 to 4 weeks as a planning reference point. A set of dashboards drawing from multiple sources takes 4 to 8 weeks. A full enterprise implementation with governed models and org-wide deployment takes 8 to 12 weeks or longer. Actual schedules vary based on data readiness, scope complexity, and review cycles. Data quality issues, stakeholder misalignment on metrics, and undiscovered governance requirements are the most common causes of delay.

What is a Power BI proof of concept and should I request one?

A proof of concept is a short, time-limited pilot where the consultant builds a working prototype using a small sample of your actual data. It lets you assess technical quality, communication style, and whether the pitch team and the delivery team are the same people. For higher-stakes or longer engagements, requesting a proof of concept before signing is a sound approach.

What should handover documentation include after a Power BI project?

At minimum, handover documentation should include: a data model diagram with all table relationships and calculated measures documented; a list of all data sources, connection types, and refresh schedules; agreed KPI definitions for every metric in the reports; and user guides appropriate for different user types. Ask to see a sample from a previous engagement before you sign.

What is Microsoft Fabric and does it affect my Power BI project?

Microsoft Fabric is a unified analytics platform that brings Power BI together with data engineering, data warehousing, and real-time intelligence in a single environment. For organisations planning to grow their Power BI capability significantly, Fabric is an increasingly relevant architectural consideration. Ask any consultant pitching an enterprise engagement what their Fabric experience is and whether it should factor into your design.

How should I evaluate Power BI consultant proposals?

Compare proposals on scope completeness rather than headline price. Ask each consultant what their proposal excludes. Score candidates against consistent criteria: credentials and sector experience, data readiness process, scope and timeline logic, technical depth in modelling and governance, adoption and training plan, and documentation at handover. A structured scorecard produces better decisions than informal comparison.

What are the most common reasons Power BI projects fail?

The most consistent failure causes are: no clearly defined business question the dashboard is meant to answer; unreliable or inconsistent source data; too many KPIs crammed into one report; weak data model design causing slow or inaccurate results; and no plan for maintaining the dashboards after go-live. All of these are discoverable before the build starts.

How do I ensure Power BI dashboards are actually used after launch?

Adoption planning should start before the build, not after delivery. Involve actual end users in requirements gathering, not just their managers. Provide training tailored to different user types. Identify internal champions who can support colleagues after launch. Set clear success metrics, such as active user counts or decisions made using the tool, and track them at 30, 60, and 90 days post-launch.