Why Power BI Projects Fail and How to Prevent It

The answer to why Power BI projects fail is almost always the same after six years of consulting: the critical questions were never asked before the build started. Not the wrong visuals. Not weak DAX. Not an untrained developer. The discovery phase was rushed, skipped, or treated as a formality — and every assumption made in its absence became a problem to fix later, at far greater cost.

Understanding why Power BI projects fail starts with understanding what happens in the gap between “we need a dashboard” and “here is the first query.” That gap — the discovery phase — is where projects are won or lost. When it is done well, the build is predictable, the output matches expectations, and users actually adopt it. When it is skipped, the project inherits a full set of hidden assumptions that surface at the worst possible moments.

To solve this, I built the pbi-requirements-gathering skill — a free, open-source Claude skill on GitHub that runs the full requirements conversation automatically. It covers all 10 phases I’ll walk through below. This guide explains the thinking behind every single question in the skill: why it belongs in discovery, what it uncovers, and what happens when it gets skipped.

The 10 Phases at a Glance

Phase	Questions	What gets skipped	Failure mode
1. Business Context	10	Decision definition, sponsorship	Scope drift, no adoption
2. Data & Sources	10	Data quality, access rights	Mid-project rework, access delays
3. Data Modelling	13	Star schema, naming, source control	Slow model, unmaintainable DAX
4. Performance	10	Storage mode, data volume	Slow reports, refresh failures
5. Infrastructure	13	Gateway, capacity, refresh limits	Silent failures post go-live
6. Visual Requirements	13	KPI prioritisation, fiscal year	Wrong time intelligence, report bloat
7. Security & Licensing	12	RLS design, viewer count	Retrofit security, licensing shock
8. Business Logic	10	KPI definitions, data dictionary	Disputed numbers, trust collapse
9. Governance	12	Naming, certification, retirement	Report sprawl, metric drift
10. Adoption	12	Training plan, champions, support	Report abandoned within 90 days

Phase 1 — Business Context & Sponsorship

Phase 1 is where most of the reasons why Power BI projects fail are planted. A project without a defined business problem is a design exercise, not a solution. The goal of this phase is to understand why this report needs to exist and who is truly behind it. Vague scope and weak sponsorship are the two most common reasons projects stall before they ship — and both can be identified in the first conversation, if you ask the right questions.

What is the main business problem this report needs to solve?

This is the foundational question. Without a clear problem, every design decision is subjective. The answer forces the conversation away from feature requests and toward outcomes.

What decisions will people make using this report — and who makes those decisions?

A report that doesn’t influence a decision has no purpose. Identifying the decision and the decision-maker sets the scope and ensures the right data is in the right format for the right person.

Who are the primary end users — executives, managers, analysts, frontline operations?

The audience determines the level of detail, the complexity of navigation, and the design language. A report built for an analyst will overwhelm an executive, and vice versa.

How technically confident are the end users — do they know Power BI or are they just consumers?

This shapes whether you need guided navigation, tooltips, and simplified filtering — or whether the audience can handle cross-filtering, drill-throughs, and custom slicers without training.

Is there an existing report or tool being replaced? If so, what is wrong with it?

Understanding what came before prevents you from rebuilding the same mistakes. It also surfaces what users are already attached to, which is critical for adoption planning.

What does success look like 3 months after go-live?

Vague success criteria guarantee a disputed outcome. A useful test: if someone opens this report and sees a number they don’t expect, what do they do next? If you can answer that, you’ve defined success.

Who is the executive sponsor — the person who owns the outcome, controls the budget, and will champion this if there is resistance?

Without a named sponsor who is genuinely committed, the project has no protection when priorities shift, budgets tighten, or organisational resistance appears.

Is the sponsor genuinely engaged or nominally attached — do they attend reviews, or are they just a name on an email?

A sponsor who signed off the budget but doesn’t attend reviews is not a sponsor. They are a liability. This distinction is uncomfortable to surface but essential.

Has Power BI been tried before in this organisation and abandoned? If so, why?

If Power BI was tried and failed before, the same conditions may still exist. Understanding the history prevents repeating the same mistakes and surfaces existing scepticism that needs to be managed.

Is there resistance from people who currently own the reports being replaced — Excel owners, legacy system owners?

This is a people problem, not a technical one. The person most attached to the Excel report they built over five years is also the most knowledgeable about the business logic it contains. Involve them early or they become a blocker.

“Active executive sponsorship is the single strongest predictor of BI project success. The sponsor doesn’t need to know Power BI. They need to hold the vision, remove blockers, and make their team use it. A sponsor who is only ‘aware’ of the project is not a sponsor.”

Microsoft’s Fabric Adoption Roadmap covers executive sponsorship and Centre of Excellence structure in depth — it’s a useful framework to share with clients whose sponsorship model is unclear.

Phase 2 — Data & Sources

Data is almost never as clean or accessible as the client believes. The goal of this phase is to understand the raw material before any model design begins. The most expensive mistake in Power BI is designing a data model based on a description of the data rather than the data itself. This phase prevents that.

Where does the data live today — Excel files, SQL Server, cloud database, ERP, API, SharePoint, Dataverse?

The data source determines the connector, the refresh method, the gateway requirements, and the likely data quality. A flat Excel file and a normalised SQL Server database require fundamentally different approaches.

How many distinct data sources are involved?

Each additional source adds complexity: another permission to negotiate, another refresh schedule to manage, another join logic to agree on. Scope problems are often hidden inside a growing list of “we also need data from…”

Has the data quality been validated — are there known issues like duplicates, nulls, inconsistent formats, missing values?

“The data is clean” is the most dangerous phrase in a discovery session. Assume it is not until proven otherwise. Data quality problems discovered mid-build cost far more to fix than those caught in week one.

Who owns each data source and who has permission to pull from it?

Access rights are almost always more complicated than expected. Identifying the data owner for each source at the start prevents the situation where a model is built and then cannot be refreshed because nobody has the right credentials.

What is the required data refresh frequency — real-time, hourly, daily, weekly, monthly?

Refresh frequency drives architecture decisions. Real-time requirements have massive implications for storage mode choice, license tier, and source system load. This question must be asked before any technical design is started.

How far back does historical data need to go?

Historical depth affects model size, refresh time, and whether Import mode is even viable. If five years of transactional history are required and the data doesn’t exist in a clean archive, that is a scope problem to surface now.

Is there an existing data warehouse or staging layer, or does Power BI connect directly to source systems?

Direct connections to live source systems cause query timeouts, lock contention, and refresh failures. A staging layer is almost always worth building. Power BI Dataflows offer a managed staging layer inside the Power BI service for teams without a dedicated data warehouse.

Can you get a sample data extract in the first week?

This is the single most important data question. If the client cannot provide a sample extract early, it is a red flag about data access, ownership, or quality. Never design a model on assumptions — only on data you can actually see.

Are there any known data issues that have caused reporting problems in the past?

Past problems tend to resurface. If the previous report had a known issue with duplicated sales records, that issue still exists in the source. Understanding historical problems prevents inheriting them.

Is the data structured, semi-structured, or unstructured — or a mix?

Semi-structured data (JSON from an API, nested XML from an ERP export) requires additional Power Query transformation work that must be scoped. Unstructured data (free-text comments, emails) is generally not reportable in Power BI without preprocessing.

“Always request a sample extract in week one. Never design a data model based on a description of the data. Only design based on what you can actually see and query.”

Phase 3 — Data Modelling & Semantic Layer

The data model is the foundation of every Power BI project. A badly structured model cannot be fixed with clever DAX — it has to be rebuilt. The decisions made in this phase determine performance, maintainability, correctness, and the ability for multiple developers to collaborate without overwriting each other’s work. This is the phase with the highest density of questions, because it is the phase with the most technical debt risk.

Is there an existing data model in Power BI Desktop or Analysis Services — or are we starting from scratch?

An existing model may carry years of technical debt: calculated columns that should be measures, flat tables that should be normalised, undocumented logic baked into DAX. Understanding what exists before inheriting it is essential.

Is the data currently structured as a star schema — fact tables and dimension tables — or is it flat, denormalised tables?

Flat denormalised tables are the most common starting point and the most expensive long-term technical debt in Power BI. The star schema is not optional — it is the architecture that enables correct DAX, fast VertiPaq compression, and clean relationships.

If flat — is there an understanding of what the fact tables and dimensions should be before building starts?

A flat table with 50 columns needs to be decomposed into facts and dimensions before the first relationship is drawn. Agreeing on this decomposition in discovery prevents a model redesign three weeks into development.

Are there multiple fact tables — for example sales, inventory, and returns — that need to share common dimensions?

Shared dimensions across multiple fact tables (a conformed dimension model) require deliberate design. Without it, you end up with duplicate dimension tables and broken cross-filtering between subject areas.

Are metric and KPI definitions documented anywhere — a data dictionary, a business glossary, or even a shared spreadsheet?

Undocumented KPIs are DAX written on sand. If the definition of “revenue” lives only in someone’s head, the DAX encoding it will be challenged at go-live. Documentation forces alignment before a single measure is written.

Are there calculated columns or measures that currently exist in Excel or other tools that need to be replicated in DAX?

Excel logic is often more complex than it appears — nested IFs, array formulas, hidden lookups. Identifying these early gives time to reverse-engineer the intent correctly rather than discovering them during UAT.

Are naming conventions defined — for tables, columns, measures, and calculated fields?

Without naming conventions, three developers produce three different naming styles and the model becomes unreadable within weeks. Conventions agreed before development starts are enforced for free by habit.

Is there a standard measure naming format — for example prefixes like [Sales Amount], [# Orders], [% Margin]?

A prefix system makes the model self-documenting. Users browsing the field list can immediately identify whether they’re looking at a count, a ratio, a currency amount, or a text field — without opening documentation.

Will multiple developers or teams work on this project simultaneously?

A single developer working alone has different tooling needs than a team of three. Multi-developer projects require source control, branching strategies, and a file format that Git can actually work with.

If multiple developers — how will conflicts be managed? Is there a branching strategy or will developers work on separate files?

Direct commits to a shared PBIX file with no branching is a race condition waiting to happen. One person will overwrite another’s work. A feature-branch strategy with code review before merging to main is the professional standard.

Is Git integration being used or planned — Power BI Projects (.pbip) format enables source control with Azure DevOps or GitHub?

PBIX files are binary and cannot be diffed or merged. PBIP splits the model and report into readable TMDL and JSON files. On any multi-developer project, migrating to .pbip from day one is not optional — migrating a complex model later is a painful, high-risk process.

Are there existing CI/CD pipelines for data or reporting assets that Power BI should integrate with?

Some organisations have mature DevOps practices for data. Understanding whether Power BI needs to slot into an existing pipeline — or whether it will be managed independently — affects tooling choices and deployment strategy.

Is the plan to use a shared certified dataset that multiple reports connect to, or will each report have its own model?

A certified shared dataset is the most underused feature in Power BI. Build the semantic model once, certify it, and let multiple reports connect to it. Without this, every team builds their own version of revenue and the numbers will never reconcile.

Phase 4 — Performance & Scale

Storage mode is the most consequential technical decision in a Power BI project — and it is almost always made too late, or not consciously made at all. The wrong choice is expensive to reverse once the model is populated and reports are in active use. This phase forces that decision early, when changing course is still cheap.

Approximately how many rows of data — thousands, millions, tens of millions, hundreds of millions?

Row count is the first input into every storage mode and capacity decision. A model with 100,000 rows has almost no performance constraints. A model with 500 million rows requires deliberate architecture from the start.

How many concurrent users at peak time?

Concurrent users drive capacity requirements. Ten users on a Pro workspace is very different from 200 users on a shared Premium capacity. This answer determines whether the current license tier is viable or whether a capacity upgrade is part of the project scope.

Is Import mode acceptable — data loaded into Power BI memory — or does it need to be live?

Import delivers the best query performance but data is always a snapshot of the last refresh. DirectQuery keeps data live but every visual generates a query against the source system. The business tolerance for data latency — not technical preference — should drive this decision.

Are there existing performance complaints about current reporting tools?

If users already describe the current reporting environment as slow, the problem is often in the source system or data architecture — not the reporting layer. Switching to Power BI without fixing the underlying issue will reproduce the same complaints.

What is the expected data growth rate — will this double in 12 months?

A model that performs well today with 10 million rows may not perform in 18 months with 80 million rows. Planning for growth at the architecture stage prevents an emergency re-architecture mid-engagement.

Are there large historical datasets that could be archived or aggregated rather than loaded in full?

Loading five years of daily transactional data in full is often unnecessary. Rolling 13-month import with a summarised historical table is a common pattern that dramatically reduces model size without losing analytical capability.

Are there high-cardinality columns in the data — for example free-text fields, GUIDs, long product codes?

The VertiPaq compression engine excels at columns with low cardinality. A column with 10 distinct values across 10 million rows is nearly free. A column with 10 million unique GUIDs or free-text strings can single-handedly double the model size. Identify and remove these early.

Will aggregation tables or incremental refresh be needed to manage volume?

For large models, aggregation tables pre-summarise frequently queried data so that most visuals never touch the detail-level rows. Incremental refresh prevents full dataset reloads by only processing new or changed records. Both require Premium or Fabric capacity and need to be planned from the start.

Are there complex DAX calculations expected — time intelligence, rolling averages, period-over-period comparisons?

Complex DAX on large models with DirectQuery can cause severe performance issues. Identifying the calculation complexity upfront informs whether certain calculations should be pre-computed in SQL or Power Query rather than calculated at query time in DAX.

What is the acceptable report load time — is 3 seconds acceptable, or does it need to be under 1 second?

Without a defined performance target, there is no way to know whether the build is successful. “It feels slow” is not a specification. A named target — for example, 2 seconds for a dashboard page refresh — is testable and achievable.

Phase 5 — Admin, Infrastructure & Storage Mode

The operational environment determines whether the report works day-to-day after go-live. Refresh failures, gateway misconfigurations, and capacity limits do not appear during development — they appear three weeks after go-live, when users notice the data stopped updating and nobody knows who to call. This phase surfaces every operational risk before it becomes an incident.

What Power BI infrastructure exists — shared capacity, Premium Per User, Premium capacity, or Microsoft Fabric?

The capacity tier defines refresh frequency limits, model size limits, incremental refresh availability, and deployment pipeline access. Many projects are scoped against the wrong tier and hit limits at go-live. Microsoft Fabric fundamentally changes the architecture options available.

Is Microsoft Fabric in use or being evaluated — is Direct Lake on the roadmap?

Fabric changes the architecture fundamentally. Direct Lake mode enables query performance close to Import with data freshness close to DirectQuery, but requires data to exist in OneLake as Delta Parquet. If Fabric is coming, designing a traditional Import model now creates migration work later.

If Direct Lake — is the data already in OneLake as Delta Parquet?

Direct Lake is only viable if the data pipeline delivers Delta Parquet files to OneLake. If data is still in on-premise SQL Server, Direct Lake is not yet an option. Surfacing this gap early prevents a project being planned around a capability that doesn’t yet exist in the environment.

What is the maximum acceptable data latency — how stale can data be?

This question determines the refresh schedule. If users can tolerate data that is 24 hours old, a single daily refresh is sufficient. If they need data current within the hour, that drives a completely different technical approach and license tier requirement.

How many scheduled refreshes per day, and during which hours?

Pro licenses allow a maximum of 8 scheduled refreshes per day. Premium Per User and Premium capacity allow 48. If the client needs hourly refresh and is on Pro, that is a licensing conversation that must happen before the architecture is finalised.

Are existing datasets already hitting refresh limits?

If the current Power BI environment already has datasets failing due to refresh limits or timeouts, adding a new project without addressing the underlying capacity issue will make the problem worse. This is a signal to investigate before committing to a refresh schedule.

Is there an on-premise data gateway — who manages it and how often is it maintained?

The on-premise gateway is the most frequently broken component in any Power BI environment. It runs on a server that gets rebooted, patched, or decommissioned without the BI team being told. Name the gateway owner, document the server, and establish an alerting process. These are non-negotiable for production workloads.

Are deployment pipelines in use — dev, test, and production environments?

Publishing directly to production without a test environment is a governance and quality risk. A three-stage deployment pipeline (dev → test → prod) is available on Premium and Fabric and should be the standard for any report that business decisions depend on.

What happens when a refresh fails — is there monitoring and alerting?

Silent refresh failures mean stale data that users don’t know is stale. This is worse than a visible failure because decisions are made on outdated numbers with no warning. Refresh failure alerts should be configured before go-live, not added as a post-launch afterthought.

Who is the Power BI Service admin?

Identifying the Service admin upfront ensures there is someone with the authority to configure tenant settings, manage capacity, create workspaces, and approve deployment pipeline promotions. An unknown or unresponsive admin causes delays at the worst moments.

What tenant-level settings are relevant — is export to Excel allowed, can users download PBIX files, is publish to web enabled or blocked?

Tenant settings are frequently ignored in requirements conversations and cause surprises at go-live. A DLP policy that blocks Excel exports. A setting that prevents embedding. Restrictions on publish-to-web. These are security and governance decisions, not technical ones, and they need to be agreed before the report is built.

Are workspace-level permissions managed centrally by IT, or self-managed by report owners?

Self-managed workspace permissions create inconsistency, security gaps, and access management overhead. Understanding the permission model upfront determines how user provisioning will be handled at go-live and ongoing.

Is there a process for provisioning new workspaces — or does anyone create workspaces freely?

Free workspace creation leads to sprawl: 200 workspaces with names like “Test – John” and “Finance copy FINAL v3”. A governed provisioning process with a naming convention takes 30 minutes to agree and saves months of cleanup.

Phase 6 — Report & Visual Requirements

More pages and more visuals is not better. Without explicit prioritisation, reports end up showing everything — which communicates nothing. This phase captures what users actually need to see, manages expectations about scope, and surfaces design constraints before any development begins.

Roughly how many reports and pages are needed?

Scope estimation starts here. A request for 15 reports in week one is a negotiation, not a requirement. Understanding the full intended scope early allows a phased delivery plan to be agreed before work begins, rather than being forced by a missed deadline.

Is this a one-shot delivery or iterative — v1 delivered and improved, or one go-live date?

Big-bang go-lives carry all the risk. An iterative delivery — v1 that proves value fast, then expanding in subsequent sprints — is almost always a better outcome for both parties. This question opens the conversation about delivery model before the client has committed to a single go-live date.

Are there existing mockups, sketches, or examples from other tools they like?

Existing mockups — even rough hand-drawn sketches — dramatically reduce design iteration cycles. They also reveal hidden requirements: a mockup with 40 columns in a table is an education opportunity; a mockup with a clear KPI card layout is a head start.

What are the 5 most important KPIs — can they rank them in priority order?

If every KPI is equally important, the report communicates nothing. Forcing a priority ranking — “if you could only see one number every morning, what would it be?” — reveals what actually matters and grounds the visual hierarchy of every page.

What time dimensions matter most — daily, monthly, YTD, rolling 12 months, fiscal year?

Time dimensions drive the complexity of DAX time intelligence measures and the design of the date table. Getting these wrong means rebuilding significant DAX after go-live. YTD, rolling averages, and period-over-period comparisons all require specific measure patterns that should be planned in advance.

Does the organisation have a fiscal year that differs from the calendar year?

A fiscal year that starts in April or October requires a custom date table with fiscal-year logic built in. Time intelligence DAX written against a standard calendar year will produce wrong results against a fiscal calendar. This question saves hours of rework.

Do visuals need to follow company branding — specific colours, fonts, logo placement?

Branding is not a cosmetic concern — it affects whether the report feels like it belongs to the organisation or like a default Power BI template. A report theme file locked to brand colours, fonts, and visual defaults takes 30 minutes to build and saves hours of per-visual formatting across every page.

Are there any regulatory requirements on how data is displayed or labelled?

Financial services, healthcare, and public sector clients often have compliance requirements that affect how numbers are displayed, what disclaimers must appear, and which data can be shown to which users. Discovering these requirements after the report is built is costly.

Will users need to drill down into detail or is high-level summary sufficient?

Drill-through pages, detail tables, and row-level expansion significantly increase build complexity. If users only need summary-level insight, building extensive drill-through capability wastes time and creates maintenance burden. Confirm the requirement before building it.

Do reports need to work on mobile devices?

Mobile layouts in Power BI require a separate, manually-designed layout for each report page. This is significant additional design effort that is often discovered late. If mobile is required, it must be scoped and designed as part of the project — not added as an afterthought after desktop development is complete.

Are tooltips, bookmarks, or custom navigation expected?

Advanced interactivity features — custom navigation buttons, bookmark-based filtering panels, tooltip pages — add development time and complexity. Each one needs to be explicitly scoped. “Make it interactive” is not a requirement.

Are custom visuals required — third-party visuals from AppSource, Zebra BI, Deneb?

Custom visuals from AppSource require IT approval in many organisations. They can break with Power BI updates, are not always supported by the vendor, and some require their own licenses (Zebra BI, for example). The decision to use custom visuals needs to happen in requirements, not mid-development.

Is there a report theme file already defined, or does one need to be created?

A theme file that locks colours, fonts, and visual defaults across every report page ensures brand consistency and eliminates repetitive formatting work. If one doesn’t exist, creating it is a small upfront investment that pays back throughout the project.

Phase 7 — Security, Access & Licensing

Security designed after a report is built is painful and expensive to retrofit. Licensing surprises at go-live are worse. This phase surfaces both before any model design begins — because the security model directly influences the data model structure, and the licensing model directly constrains the architecture choices.

Who needs access — internal staff only, or also external guests or partners?

External guest access via Azure B2B changes the authentication approach and may require specific tenant configuration. Discovering that external partners need access after the workspace is set up causes rework and potential security gaps.

Do different users need to see different subsets of data — is Row Level Security needed?

RLS is a data model feature — it must be designed before the model is built, not retrofitted after. If regional managers should only see their region’s data, the security table and DAX filter expressions need to be in the requirements specification, not discovered during UAT.

If RLS — is it based on user email, department, region, management hierarchy, or a combination?

The complexity of the RLS logic determines how it is implemented. Static roles suit simple, infrequently-changing rules. Dynamic RLS with a security mapping table suits complex, frequently-changing rules like management hierarchies. The choice must be made before development begins.

How are users authenticated — Microsoft 365, Azure AD, other?

Power BI authentication is tied to Azure Active Directory. If the organisation uses a different identity provider, understanding the SSO and federation setup is essential for access management and for understanding how RLS user matching will work.

What Power BI licenses do users currently have — Free, Pro, or Premium Per User?

Free users cannot access Pro workspaces. Pro users cannot access Premium workspace features like paginated reports or deployment pipelines. Confirming the current license baseline prevents a go-live where half the intended audience cannot open the report.

Is there Premium capacity or Fabric capacity?

Premium capacity enables free viewer access at scale, larger dataset sizes, and advanced features. If no Premium capacity exists and the intended audience is large, the licensing cost model changes significantly — and that conversation needs to happen before the project architecture is committed.

How many people need to VIEW the report — all consumers, not just developers?

This is the most commonly misunderstood licensing question. Developer count is always smaller than viewer count. At roughly 25 or more regular viewers, Premium Per User becomes more cost-effective than individual Pro licenses. Model the cost before the project is signed off.

Will the report be embedded in an external app, SharePoint, Teams, or a public website?

Each embedding destination has different licensing implications. Embedding in Teams for internal staff is straightforward. Embedding in a public-facing website or an external application requires Power BI Embedded licensing with a completely different commercial model.

Are there data sensitivity or compliance requirements — GDPR, HIPAA, SOC2, financial regulations?

Compliance requirements may mandate data residency, audit logging, sensitivity labelling, or specific export restrictions. Discovering a GDPR requirement that affects what data can be shown to which users after the report is built means a data model redesign.

Who manages user access on an ongoing basis after go-live?

Self-managed access is a security and compliance risk. If nobody owns the access management process, permissions accumulate indefinitely, former employees retain access, and audit trails become meaningless. Naming the access manager is a governance requirement, not a nice-to-have.

Are Microsoft Information Protection sensitivity labels in use — are datasets classified as confidential?

Sensitivity labels in Power BI inherit from the source data and propagate to exports. A dataset labelled Confidential may block Excel exports, restrict sharing, and trigger DLP policies. Understanding the label landscape prevents blocked workflows at go-live.

Is there a data loss prevention policy that could block certain exports or sharing actions?

DLP policies can silently block legitimate report sharing, Excel exports, or embed operations. A DLP policy that was not identified in requirements will cause go-live failures that look like bugs but are actually policy enforcement.

“Design RLS before the first visual. Two approaches exist: static roles defined in Power BI Desktop, and dynamic RLS using a DAX security table mapped to user emails. Retrofitting RLS into a finished report is painful, error-prone, and takes twice as long as building it correctly from the start.”

Phase 8 — Integration & Business Logic

Power BI rarely exists in isolation. It connects to source systems, integrates with automation tools, interacts with other BI platforms, and encodes business rules that are often undocumented and contested. This phase surfaces every integration dependency and forces business logic to be agreed on paper before it is written in DAX.

Does the report need to trigger alerts or push notifications when thresholds are crossed?

Data alerts and Power Automate-driven notifications are popular requirements that are often raised after development has started. They affect workspace configuration, dataset refresh strategy, and may require additional licensing. Scope them upfront.

Is Power Automate integration needed — approvals, workflows, or actions from Power BI?

Power BI can trigger Power Automate flows and embed Action buttons in reports. These integrations require Power Automate licensing and workflow design that is separate from the Power BI build. They need to be in scope from day one.

Are other BI tools currently in use — Tableau, Qlik, SSRS, Excel reports, Looker?

A multi-tool BI environment creates political complexity and potential redundancy. Understanding what other tools are in play — and which are being replaced, which are staying, and which are out of scope — prevents overlapping builds and stakeholder confusion.

Are KPI definitions agreed and documented across departments?

This is one of the most impactful questions in the entire discovery process. Finance and Sales often define revenue differently. Operations and HR often define headcount differently. These conflicts must be resolved and documented before any DAX is written — not after a number is disputed in a board presentation.

Are there complex business rules that need documenting before building starts?

Business rules that exist only in someone’s head — allocation logic, exception handling, special-case calculations — will be encoded incorrectly if not documented. A business rules register, even a simple one-page table, prevents the most common class of post-launch disputes.

Are there currency conversions, time zone adjustments, or fiscal year differences?

Currency conversion in Power BI requires an exchange rate source, a conversion strategy (end-of-period vs average), and specific DAX patterns. Time zone adjustments require data transformation. Fiscal year differences affect the date table and all time intelligence DAX. Each of these is a scoping conversation, not an implementation detail.

Is there a data glossary or data dictionary?

A data dictionary is the single source of truth for field definitions, calculation rules, and acceptable values. If one doesn’t exist, the requirements phase is the right time to create a lightweight version. Understanding how DAX evaluates measures makes clear why undocumented logic is fragile.

Will data ever flow back from Power BI into source systems?

Power BI is not a transaction system. Data writeback requests — entering targets, updating forecasts, flagging exceptions — require a separate solution (Power Apps, a writeback-enabled custom visual, or an external application). Identifying this requirement early prevents it being raised as a gap at UAT.

Does this project depend on other projects — a data warehouse migration, an ERP upgrade, a cloud move?

A Power BI project that depends on a delayed data warehouse migration will be delayed too. Mapping project dependencies in requirements allows a realistic delivery timeline to be built — rather than a plan that assumes all upstream dependencies are on time.

Are there APIs that need to be connected — external data providers, weather data, financial market feeds?

External API connections add refresh complexity (API rate limits, authentication token management, schema changes) and often require additional Power Query work or dataflow maintenance. Identifying these sources upfront allows the correct architecture to be designed from the start.

Phase 9 — Governance & Workspace Standards

Phase 9 is one of the clearest answers to why Power BI projects fail at scale. Gartner predicts 80% of data and analytics governance initiatives will fail by 2027 — not because of technology, but because of process. Governance sounds bureaucratic until a Power BI environment has 200 reports, nobody knows which ones are accurate, three versions of the same metric exist across different workspaces, and the only person who understands the original model has left the company. This phase prevents that outcome.

Is there a naming convention for workspaces — for example Finance-Prod, Sales-Dev?

Naming conventions need to be defined before the first workspace is created, not after. Retrofitting names across 50 workspaces is a painful project nobody wants to do. A simple standard — Department-Environment — takes 30 minutes to agree and prevents months of confusion.

Is there a naming convention for reports and datasets — who defines and enforces it?

Without report naming conventions, discovery becomes impossible. Users cannot find the right report. Developers create duplicates. Stale reports accumulate alongside current ones with no way to tell them apart.

Are there development standards — which visuals are approved, which are banned, what formatting rules apply?

Approved visual standards prevent report authors from using deprecated visuals, inconsistent colour usage, or custom visuals that haven’t been security-reviewed. Without standards, every report looks different and branding consistency disappears.

Is there a certification or endorsement process for datasets — promoted versus certified?

Promoted means “the owner recommends this.” Certified means “the organisation has validated this as the official source of truth.” Only certified datasets should underpin executive reporting. Without this distinction, every team builds their own version of the metric and the numbers never agree.

Who can publish reports to production — is it anyone, or is there an approval process?

Unrestricted publishing to production means untested reports go live and break user trust. An approval or promotion workflow — even a lightweight one — ensures that what reaches production has been reviewed, tested, and signed off.

Is there a process for retiring or archiving old reports — or do unused reports accumulate forever?

Unused reports consume workspace capacity, confuse users who find them via search, and create maintenance overhead. A retirement process — triggered by low usage metrics or explicit review cycles — is essential for a healthy Power BI environment.

Is there a Center of Excellence or a BI governance team — or is Power BI self-managed by each department?

Power BI governance does not self-organise. Without a CoE or a named governance team, standards erode, duplicate work accumulates, and there is no central capability for training, tooling decisions, or escalation. Even a small, informal CoE is better than none.

How is version control handled — are PBIX files saved to SharePoint, Git, or just on local machines?

PBIX files saved on local machines is not version control — it is a disaster waiting to happen. At minimum, SharePoint with version history. For serious development teams, Power BI Projects format with Git integration is the professional standard.

Is lineage tracking used — does the organisation know which reports depend on which datasets?

Lineage tracking allows the impact of a dataset change to be assessed before it is made. Without it, modifying a shared dataset breaks downstream reports in ways nobody anticipated. Power BI Service has built-in lineage views — but they only work if the workspace structure is clean.

Are usage metrics monitored — does anyone track which reports are actually used and which are abandoned?

Usage metrics are the most objective measure of whether a report delivers value. A report with zero views in 90 days is a candidate for retirement. A report with 500 views per week is a candidate for investment. Without monitoring, these decisions are made on gut feel.

Is there a formal process for requesting new reports or changes — a backlog, a ticketing system?

An informal request process — “just message me on Teams” — creates uncontrolled scope, untracked work, and no way to prioritise competing demands. A lightweight backlog, even a shared spreadsheet, provides visibility and enables deliberate prioritisation.

Are there workspace app settings configured — who can see the workspace app versus the workspace itself?

Workspace apps are the consumer-facing view of a workspace. Workspace access is the developer view. Mixing these up gives consumers access to unpublished work-in-progress. Getting the app configuration right at setup prevents inadvertent data exposure.

According to BARC research, 58% of organisations have fewer than 25% of employees actively using BI tools. That number reflects a governance failure as much as an adoption failure — reports that aren’t trusted because nobody certified them, or can’t be found because nobody named them consistently.

Phase 10 — Change Management, Training & Adoption

Adoption failure is the final and most visible answer to why Power BI projects fail. The best Power BI report in the world fails if nobody uses it. Adoption does not happen because the report is technically good — it happens because the right people were involved in designing it, trained before go-live, and have someone to call when something goes wrong. This is the most commonly skipped phase and the most commonly regretted one. BARC research shows that 55% of organisations identify training as the most effective BI adoption measure — yet most projects treat it as an afterthought.

Is there a formal adoption plan — or is the expectation that people will just start using it?

“People will figure it out” is not a plan. It is a prediction that is almost always wrong. An adoption plan does not need to be complex — it needs to name who gets trained, when, by whom, and what success looks like. Without it, a technically excellent report gets abandoned within 90 days.

Who will train end users — the developer, a dedicated trainer, recorded walkthroughs, Microsoft Learn?

Training delivered by the developer is efficient but doesn’t scale. Recorded walkthroughs are scalable but don’t answer questions. A blended approach — live training at go-live supplemented by recorded walkthroughs and documentation — is the most effective combination for most deployments. Microsoft’s Fabric Adoption Roadmap covers change management in detail.

When does training happen — before go-live, at go-live, or after?

Training delivered after go-live is almost always too late. Users who encounter the report before being trained form a first impression — usually negative — and rarely revise it. Training must happen before users see the report for the first time.

Are different user groups getting different training — executives need different training than analysts?

One-size-fits-all training fails everyone. An executive who sits through an analyst-level session will disengage within ten minutes. An analyst given only an executive walkthrough will not understand how to use the filtering and drill-through features they depend on. Segment the training and tailor the content.

Is there a support channel after go-live — who do users contact when something looks wrong or they have a question?

Users who hit a problem and can’t get help stop using the tool. A named support channel — even a Teams channel monitored by the developer — gives users confidence that the report is maintained and that issues will be addressed. Without this, problems fester silently until they reach an executive.

How will adoption be measured — is there a target for active users, report views, or business decisions influenced?

Without a measurable adoption target, there is no way to know whether the project succeeded. Report view counts, active user percentages, and reductions in Excel-based manual reporting are all valid adoption metrics. Define them before go-live.

Are there Power BI champions identified in each department — internal advocates who can support peers?

A champion network — one or two power users per department with advanced training and early access — scales adoption without scaling the support burden. Champions are not IT staff. They are business users who understand their team’s data problems and can answer questions in context. This is the single most effective adoption mechanism available.

Is there a feedback mechanism — how do users request changes or report data issues?

A report with no feedback channel accumulates unspoken frustration. Users who find an incorrect number and have no way to report it either stop trusting the report or start building their own Excel version. A named feedback channel — a form, a Teams channel, a ticketing system — maintains trust and provides a quality feedback loop.

Is there known resistance to adopting Power BI — people attached to Excel, existing reports, or other tools?

Resistance is predictable. It comes from people whose role is tied to the tool being replaced, or who distrust anything they didn’t build themselves. Identifying the resistant stakeholders before go-live allows a mitigation plan to be designed — rather than encountering them as blockers on launch day.

Is there a plan for handling that resistance — communication, involvement in design, executive mandate?

The fastest way to neutralise resistance is involvement. The person most attached to the Excel report they built over five years is also the most knowledgeable about the business logic it contains. Involve them in the Power BI design. They become a champion instead of a blocker.

Will the report replace a tool people currently rely on — and is there a transition plan or cut-over date?

Running Power BI and the old tool in parallel indefinitely creates confusion about which is the source of truth. A named cut-over date, with a clear decommissioning plan for the old tool, forces adoption and prevents the old report from quietly continuing to be used long after the new one launches.

Is there ongoing training planned for when Power BI features change or new reports are added?

Power BI releases monthly updates. Features change. New report pages get added. Users who were trained once at go-live but never again will fall behind and revert to old habits. A periodic training cadence — even a quarterly “what’s new” session — keeps the adoption curve moving upward.

This entire guide answers why Power BI projects fail — but reading it is only step one. I built the pbi-requirements-gathering skill to run this entire conversation automatically. Instead of working through 115 questions manually, you load the skill into Claude and it guides you through all 10 phases — asking each question, flagging red flags in real time, and surfacing best practice guidance when a risky answer is detected. It takes between half an hour and two hours for a typical project, depending on the speed of your input. Everything in this guide is built into the skill. If you’re starting a Power BI project, check it out on GitHub before you write a single line of DAX.

This skill was built by Lukas Reese. If you need help turning these requirements into an actual Power BI system, connect on LinkedIn or reach out via lukasreese.com.

Frequently Asked Questions

What is the most common reason Power BI projects fail?

The most common reason is the absence of structured discovery before the build starts. Projects that skip requirements gathering begin on assumptions. Those assumptions break — mid-project or at go-live — in ways that are expensive and demoralising to fix. Technical failures are rare. Requirements failures are common.

What does it mean for a Power BI project to fail?

Failure doesn’t always look like a cancelled project. It more often looks like reports that nobody opens, dashboards where users don’t trust the numbers, solutions replaced by Excel within three months, or data that appears correct but rests on undocumented assumptions. According to BARC research, 58% of organisations have fewer than 25% of employees actively using BI — that is widespread adoption failure.

How long does a proper Power BI discovery phase take?

For a small to mid-size project, a structured discovery conversation takes between half an hour and two hours, depending on the speed of your input. For large enterprise projects, it can take a full day or more. The time saved downstream — in rework, scope changes, and adoption problems — is always greater than the time invested upfront.

Can a free tool help with Power BI requirements gathering?

Yes. The pbi-requirements-gathering Claude skill on GitHub walks through all 10 discovery phases and over 100 questions using AI-guided conversation. It covers business context, data sources, modelling, performance, infrastructure, visuals, security, business logic, governance, and adoption. It is free and open source.

What is the role of executive sponsorship in Power BI projects?

Executive sponsorship is the single strongest predictor of Power BI project success. The sponsor doesn’t need to understand Power BI. They need to hold the vision, remove blockers, and ensure their team adopts the solution. A sponsor who is only nominally attached to the project — but not actively engaged — provides no protection when priorities shift or organisational resistance appears.