Power BI Consulting That Actually Sticks

Power BI is a presentation layer. Four things have to be true first.

Before Power BI can visualize data accurately, four things have to be true:

1. The data it’s pulling from has to be clean and reliable
2. The data model — the relationships between tables, the logic behind calculated fields — has to be correct
3. The KPIs being displayed have to be defined consistently across departments
4. Someone has to own the governance — keeping the data model current, updating reports when business logic changes

If any of those four things are broken, it doesn’t matter how good your dashboard design is.

Five failure modes I find consistently

• No single source of truth Sales pulls pipeline from Salesforce. Finance pulls revenue from the ERP. Operations works from a spreadsheet updated every Monday. All three numbers are slightly different and nobody has the authority to reconcile them.
• Manual data pulls are still happening If someone is still exporting to Excel and cleaning it up before feeding it into Power BI — the automation didn’t happen.
• KPIs are defined differently across departments “Gross margin” means one thing to your CFO and something different to your VP of Sales. These inconsistencies get embedded into the data model and cause reports to produce numbers that can’t be compared.
• No one owns the governance The most common thing I hear: “The person who built it left.” No documentation, nobody knows how to update it, no runbook.
• The data model was built on a broken foundation Relationships defined incorrectly, DAX measures that produce wrong results under certain filter conditions. These errors are often invisible until someone asks a question the original developer didn’t anticipate.

Fix the layer underneath before touching the dashboards

• Start with the source data, not the report requirements Before I know what dashboards to build, I need to understand what data you have, where it lives, and what it actually represents.
• Define KPIs before building anything I will not start building a data model until we’ve agreed on what each metric means, who owns that definition, and what the authoritative source is.
• Build for handoff, not for dependency Every data model is documented. Every DAX measure has a comment. The runbook I deliver is specific enough that someone who didn’t work on the project could update the data model a year from now without calling me.
• Work in your environment I don’t have a preferred architecture. I use the tools you already have.

Architecture before build. Always.

1. Assessment

   Two to three weeks. Review your current Power BI environment, source data, existing reporting process, and KPI framework. No production access required at this stage.

2. Data Architecture

   Design the data model — fact tables, dimension tables, relationships. Define the KPI framework: every metric, its formula, its source, and its owner. Review with stakeholders before building.

3. Build

   Build the data model in Power BI, write the DAX measures, establish data connections, configure automated refresh. Replace manual data workflows with automated connections.

4. Testing and Validation

   Run reports against historical data. Validate output against existing numbers. Resolve discrepancies before going live. Scenario test for edge cases.

5. Handoff

   Train the people who will maintain the system and the people who will use it. Deliver the runbook. 30-day check-in included.

Seven things your team owns when I leave

• A working data model with documented relationships, clean source connections, and reliable automated refresh
• A defined KPI framework — every metric has an agreed-upon definition, a designated source, and an owner
• Live dashboards the people who use them trust
• Automated data pulls replacing manual export-and-paste workflows
• A runbook specific enough that your team can maintain the system without outside help
• Trained users
• 30-day check-in

Where I do this work

Common questions