Red Flags to Watch for When Hiring a Power BI Consultant

The consultant optimised for the demo, not for the estate — and the demo is what got signed off. The promotion data was never in the model, the fact table was loaded at invoice-header grain rather than line grain, and the measures were written against a flat table joined together in Power Query that cannot be extended without breaking every visual on every page.

Below are the signals that predict that outcome, visible in the first meeting, before you have spent anything — and the signals that look like red flags and are not.

A consultant who leads with visuals instead of the data model. Power BI performance, extensibility and security are all decided by the semantic model beneath the report — table grain, relationships, star schema design and storage mode. A consultant who discusses colours, KPI tiles and page layout before asking about source systems is designing a demo, not an estate.

Microsoft's modelling guidance is explicit: a well-designed semantic model provides dimension tables for filtering and grouping and fact tables for summarising, loaded at a consistent grain. Grain is decided in week one, and it determines whether question number forty-seven is a two-hour change or a rebuild. If nobody asks what a row in your sales fact table represents, nobody has made that decision deliberately.

• Leading with visuals rather than the data model. Predicts extensibility failure — every new question becomes a new project because the model was shaped around the demoed visuals, not your business entities
• No questions about your ERP, the grain of your data, or how metrics are defined. Predicts a numbers argument in month three — if nobody asked whether "revenue" means gross or net of credit notes, you get a dashboard that disagrees with finance and no way to adjudicate
• A single-file approach, report and model in one .pbix. Predicts a maintenance bottleneck — Microsoft recommends separating reports from models when authors differ or one model serves many reports; one file per report means measures drift into three versions of gross margin
• DAX complexity used as a substitute for modelling. Predicts performance problems and a bus factor of one — a 400-line measure written to work around a missing dimension is a liability disguised as expertise
• Storage mode chosen by default rather than by argument. Predicts stale data or a slow report — "we always import" and "we'll do DirectQuery so it's real-time" are habits, not decisions; Import, DirectQuery and Direct Lake each carry constraints that should be argued from volume and refresh window

No mention of row-level security until you raise it predicts a rework cycle or an access incident. RLS is not a switch flipped at the end — roles and DAX filter expressions are defined in Power BI Desktop and published with the model, and RLS restricts rows only for users in the workspace Viewer role. It does not apply to workspace Admins, Members or Contributors, and does not hide columns or measures. If sales directors are meant to see only their own region, that changes the dimension design, and it belongs in week one.

No plan for who owns the semantic model after handover predicts paralysis. Six months after go-live somebody renames a measure and eleven visuals break, because renaming tables, columns or measures is a breaking change for any report connected live. Ask who holds the model, who approves a change, and how dependent reports are identified before a change ships. If the answer is "your team will pick it up", ask which named person, with what training, and what they do when the refresh fails at 03:00.

A fixed price quoted before anyone has seen the data predicts scope defence — a firm price on unseen source systems is either padded heavily or protected by refusing every change request that reveals what the data actually looks like. The honest shape is fixed-price discovery, then fixed-price delivery on a scope written after discovery. Unwillingness to name what they will not do predicts an overextended engagement — a practitioner who has delivered in your sector has boundaries, and a firm that says yes to everything is selling capacity, not judgement.

A portfolio of screenshots with no production references predicts demo-grade delivery — screenshots prove someone can build a page; ask instead how many users, how long it has run, how many refresh failures a month, and whether you can speak to whoever runs it now. And the pitch team is not the delivery team — the most common and least discussed failure in mid-market engagements. The partner who understood your OEE definition disappears after kick-off and a junior inherits a set of notes. Ask for names, CVs and the percentage of time each will spend on your work, then put it in the contract.

Three behaviours that feel discouraging in a sales meeting are strong positive signals. "The first slice will be smaller than you asked for" — a partner proposing one fact table, three dimensions and two decisions in six weeks is not lacking ambition; they are protecting you from the failure mode where twelve dashboards ship and none is trusted. "I cannot price this until I have seen the data" — the variance sits almost entirely in the sources; a clean Business Central extract and a twenty-year-old Epicor instance with three custom tables are different projects wearing the same job title, and refusing to guess is discipline, not evasion.

"Your data is not ready" — the least comfortable and most useful sentence in the process. Duplicate customers, no consistent product hierarchy and dates stored as text produce an untrustworthy model however well it is built. Each of these three means the consultant is pricing reality rather than managing your expectations toward a signature.

A good answer to the first sounds like: "One row per sales order line — your rebates and returns are at line level. Header grain loses promotion analysis later." The answers to those five are more revealing than any capability deck.

This is a screening method, not a guarantee. A good talker can pass every question — these tests filter out consultants who have never thought about modelling, not someone who has read the same Microsoft documentation you have; the only real protection is a small paid discovery with a defined deliverable before you commit to a build. Some red flags are your organisation's, not theirs — if nobody on your side can say what OTIF means or who signs off a definition, even an excellent consultant builds against assumptions.

A perfect star schema will not rescue bad master data — that work sits upstream of the report consultant. Sometimes the throwaway build is the right call — a single dashboard for a board meeting in three weeks does not need a certified model or a handover plan. And none of this predicts whether people will use it — adoption depends on whether the numbers match the ones operations already trust, and whether anyone changes what they do on Monday.

Before you shortlist anyone, answer four questions internally this week:

• What decision is this for? One decision, one owner, one cadence. "Visibility" is not a decision
• What is the grain of the answer? Per order line, per SKU per plant per day, per shipment. Write it down
• Who is allowed to see what? If it is "everyone sees everything", say so explicitly — that is a valid choice, and it changes the design
• Who will own the model in a year? A name, not a department. If there is no name, price a support arrangement rather than pretending otherwise

A consultant who engages properly with those four is worth talking to further. One who steers back to a demo has told you what they optimise for. Apply every test above to us, too — ask what grain we would build at, what we will not do, and whether the person in the meeting is the person doing the work. An article about red flags that exempts its author would be a red flag in itself.