On paper, a Power BI consultant builds Power BI reports. In reality, building reports is maybe a third of the job. The rest is figuring out what should be measured, where the data actually lives, why nobody trusts last quarter's numbers, and how to leave you in a position where you do not need the consultant any more. Here is what the job actually looks like.
The five things a Power BI consultant really does
1. Asks the question behind the question. "Can you build us a sales dashboard?" usually means "we do not trust the sales numbers" or "the board is asking questions we cannot answer in a meeting". A good consultant spends the first conversation pulling on those threads, because the answers determine what gets built.
2. Untangles the data sources. Nine times out of ten, the underlying data is in worse shape than anyone admits. Sales sits in the CRM, invoices in the finance system, targets in someone's spreadsheet, and a quarter of the customer names are spelled three different ways. Mapping that out, deciding what is the source of truth and either fixing or modelling around the gaps is real work that nobody sees in the final dashboard.
3. Builds the semantic model. This is the bit people imagine when they think of Power BI work, but it is mostly invisible to the end user. Tables, relationships, measures, a proper date table, calculation groups for time intelligence, row-level security. Done well, it means the business can ask new questions of the same model for years. Done badly, it means you rebuild the whole thing in eighteen months.
4. Designs the actual reports. Layout, chart choice, colour, navigation. This is the most visible deliverable and ironically the least difficult part. The skill is restraint — not putting twelve KPIs on one page when three would do, not defaulting to a pie chart, not building a dashboard that needs an induction session to use.
5. Hands it over properly. Documentation, a short training session for the team that will own it, naming conventions people can follow, a clear list of "if this breaks, here is what to check". A consultant who does not do this is asking to be retained forever, which is great for them and bad for you.
How is that different from a developer or a BI analyst?
Job titles are blurry, but in practice:
A Power BI developer builds what they are told to build. They are good with DAX, M and the visual layer. Hire one when the design has already been decided and you need it implemented at speed.
A BI analyst usually sits inside a business function and answers ad-hoc questions in Power BI or Excel. They know the domain very well and the tooling moderately well. Hire them when you need ongoing analysis, not a platform.
A Power BI consultant does both, plus the scoping, the architecture and the handover. They are usually external, they have seen a dozen similar projects elsewhere, and they are comfortable telling you that the thing you asked for is not what you need. You hire one when the path is not obvious.
A typical week
Just to make the abstract concrete, here is a fairly normal week for one of us on a mid-sized client engagement.
Monday. Workshop with the finance team to walk through the draft P&L report. They spot three reconciliation issues that we trace back to a join in the source SQL view. Half the day is spent in the database, not in Power BI.
Tuesday. Refactoring the date table to support a 4-5-4 retail calendar. Building calculation groups so the same measures work across MTD, YTD, last-year-same-period and prior-period without duplicating DAX. Mostly a quiet day.
Wednesday. Sat in on a steering meeting where the sponsor changed their mind about which segmentation the board cares about. Spent the afternoon re-modelling and updating two report pages. Logged the change against the project plan so we have a paper trail when timelines slip.
Thursday. Set up the dev / test / prod deployment pipeline in the workspace, configured an Azure DevOps connection for the .pbip source files, and wrote a one-page note on how the client's analyst can promote changes without breaking production.
Friday. Training session with the four people who will own the report. One hour walking through the model, half an hour on how to build their own measures, half an hour of "what if I want to…" questions. Closed the laptop at 5pm with the report live and the team confident.
What you should expect to get at the end
From a well-run Power BI engagement, the deliverables should include: the .pbix or .pbip source files, any dataflows or notebooks, written documentation of the model and any custom logic, a security model written down rather than just configured, a training session recording, and a list of known limitations or future improvements. If you cannot tick all of those off, the engagement is incomplete.
If you want to see how we structure that handover specifically, our Power BI consultancy page describes the phases, and our UK consulting cost guide explains what that level of work tends to cost.
Frequently asked questions
Do I need a Power BI consultant or can my IT team handle it?
If your IT team has built and run Power BI models in production before, they can almost certainly handle it. If they are starting from scratch, a consultant for the first project saves months of expensive trial and error.
What is the difference between a Power BI consultant and a developer?
A developer builds what is specified. A consultant works out what should be specified, designs the architecture, and then either builds it or hands a clear plan to your team.
Can a Power BI consultant work remotely?
Yes, almost all the work can be done remotely. Most UK engagements are now a mix of remote delivery with occasional on-site workshops at key milestones.
Want to talk this through with someone?
We are an independent UK Power BI and Microsoft Fabric consultancy. Honest opinions, fair prices, no sales pressure.