Power BI Fraud

This post discusses the forms, origins, and indications of fraud and misrepresentation in the context of Power BI consulting and contract engagements. The intent of this content is to help the reader determine whether a fraud or misrepresentation has occurred and identify characteristics that suggest the potential for a significant variance between expectations and deliverables.

Fraud Defined

There’s fraudulent misrepresentation, in which the offender knew of the misrepresentation, and there’s negligent misrepresentation, in which the offender did not. In either form of misrepresentation, the impacted party is harmed based on something they were led to believe by the offender as true not being true.

For example, if a Power BI consultant or that consultant’s firm advises a company that the consultant is an expert in Power BI solution design and development, and the consulting firm knows that the consultant is new to Power BI and is still learning the fundamentals its core languages (DAX, M), that would be fraudulent misrepresentation. However, if the consultant has delivered a few proof-of-concept or small-scale, simple Power BI solutions and this limited experience leads the consulting firm to believe the consultant is a Power BI expert or ‘technical architect’, then that would be negligent misrepresentation.

My guess is that negligent misrepresentation is much more common than fraudulent misrepresentation. In these circumstances, there’s no malicious intent to deceive, but there’s an ignorance or overly optimistic view of one’s abilities that conveniently aligns with a desire to a fill a lucrative position or land a profitable project engagement.

Fraud Happens

I believe the great majority of people want to act in a moral and ethical way such as telling the truth as best they understand it. Nonetheless, there are many examples of various frauds, scams, or Ponzi schemes which indicates that at least a certain percentage of the population is more than willing to act unethically or in a dishonest manner to obtain financial or other benefits. A few public examples that come to mind are the Enron accounting scandal, the Bernie Madoff Ponzi scheme, and the rating and selling of mortgage-backed securities prior to the great financial crisis in 2008-2009.

Beyond acknowledging that fraud (and negligent representation) is very much a real thing, it’s worth noting that some frauds can go undetected for a a long period of time and often grow larger in the process. In the case of the few examples mentioned, the deception took place over a period of years until the truth and reality began to surface with devastating impacts for those who were deceived. I tend to think that with Power BI, it’s almost impossible to hide or deceive for years but certainly a few to several months are possible and significant harm can accrue over this time.

It May Not Be Fraud

Given the pressure, timelines and capital invested in Power BI projects, it’s definitely possible that a Power BI consultant or firm could be incorrectly and unjustly identified as a fraud (or negligent misrepresentation) by the client/company. Here are a few of the top scenarios in which the failure to deliver is not the responsibility Power BI consultant or firm:

• Simplistic Understanding of Power BI
  • Power BI is a vast and deep platform with roots that go back to Microsoft BI tools that have been around for a long time, namely Analysis Services and Reporting Services.
  • It’s essential that companies identify which tools within Power BI are most relevant for their given project or role and focus the screening process around technical knowledge of the features and use cases for those tools.
    • For example, if the project deliverable is an end-to-end solution from scratch for the merchandising department, then it’s critical to find experience and skill with Power BI datasets and what that entails (DAX, RLS, composite models, etc.), not just the reporting and visualization layer.
    • If you think paginated reports have any role at all in the project (they probably do) then confirm there’s experience with this tool too.

• No Data Warehouse
  • Power BI and its data transformation capabilities via dataflows and Power Query (M) doesn’t remove the need and value of a true data warehouse.
  • In some scenarios, the company/client may believe they have a data warehouse but it’s actually just an operational data store (essentially a copy of source system tables). Proper data integrity constraints, support for slowly changing dimensions, and stable incremental load processes all benefit the BI solutions downstream.
  • A small set of highly skilled and resourceful Power BI consultants may be able to work around various shortcomings in the data warehouse but in general a poorly designed and/or unstable data warehouse and its ETL/ELT process severely reduces the probabilities of success with Power BI.

• Business Stakeholders as Solution Architects
  • If the Power BI consultant or firm doesn’t have any real control or input into how a solution is designed and delivered, then again the consultant could be placed in a difficult or even impossible situation.
  • For example, if a key stakeholder from the Accounting or Finance department insists that all existing Microsoft Excel reports, including those with complex and elaborate formulas and formatting, be replaced with Power BI reports, this would be a recipe for trouble and disappointment.
    • A more successful approach would be to point at least some of the Excel reports to a Power BI dataset as the data source (perhaps via cube functions) while using Power BI and possibly paginated reports for other reports.
  • A slight variation of this situation is when someone from the IT/BI department with limited to no technical knowledge of Power BI makes the decision for how something should be implemented in Power BI. In either situation, the best solution is for people to ‘stay in their lane’ so to speak and avoid assuming that Power BI can or should do something because some other BI tool or platform does.

• Underestimated Project Scope and Complexity
  • To a client or stakeholder not close to the technical details of a project, the project deliverable such as a dashboard and a few reports may seem very straight forward.
    • The technical reality, however, could involve the integration and cleansing of multiple data sources, custom dynamic or user-based security, significant performance optimizations and testing, and the translation of complex business logic into DAX measures.    
  • Based on this misunderstanding, the client/company may conclude that a Power BI developer with 1-2 years of experience will be fine.
    • The reality could be that a much more experienced or senior resource is needed along with support from data engineers and others in the organization.   

There are surely other scenarios in which the Power BI consultant or firm shouldn’t be blamed or at least not held fully responsible for not delivering. The main point is to confirm if the consultant was put in a situation to succeed and if there was alignment and clarity on expectations relative to experience/skills and project scope and complexity.

It May Be Fraud (or Negligence)

The following list identifies the characteristics and issues I’ve observed in projects that lead me to believe that some level of fraud or negligent misrepresentation has occurred. At a high level, the most common scenarios I experience are data visualization professionals and/or business analysts with good soft skills being put in positions to build and manage Power BI datasets (Analysis Services models) or to carry out broader technical responsibilities within the Power BI environment or outside (e.g. Azure SQL, Azure Functions).

• Power BI Desktop Only
  • An experienced Power BI consultant that builds datasets for a living will almost certainly install and use several additional supporting tools including but not limited to Tabular Editor, DAX Studio, and ALM Toolkit.
  • If the consultant doesn’t have and use these tools confidently and regularly, there’s a real possibility that the consultant is only a report author, perhaps with some very basic data modeling and DAX skills.

• Power BI Reports Only
  • An experienced Power BI consultant will almost certainly be familiar with the three different reports in Power BI including paginated reports (formerly SSRS) and Excel.
  • If the consultant doesn’t consider the use cases or application of these other report types for the given project in addition to Power BI reports, and/or insists on developing in Power BI Desktop, this also suggests a major knowledge and skill gap.
    • I’ve been in a project in which a ‘consultant’ didn’t know what Power BI Report Builder even was and how to get started with a paginated report.

• Improper Terminology
  • An experienced Power BI consultant will consistently use the correct terms when referring to various artifacts in a solution. Using terms such as datasets, reports, dashboards, live connections, DirectQuery, workspaces and apps with the correct definition and context is essential for effective communication in projects.
  • I’ve had a Power BI ‘consultant’ ask me “Why are we using these live connections, aren’t they less performant than import mode?” (He misunderstood live connections with DirectQuery)
  • I’ve had a Power BI ‘consultant’ tell me that he built a ‘Power BI Desktop’. (I don’t recall if it was actually a dataset, a report, or both).

• Frequent Delays and ‘Blockers’
  • The Power BI consulting fraud will typically ask for additional time to ‘research’ issues such as why a dataset failed to refresh or why a metric seems to be off. Likewise, the fraud may also advise that completion of a task is blocked for various reasons and that others will need to be engaged.
  • Certainly it’s true that issues arise in Power BI projects that do require research and sometimes there are real ‘blockers’ but with frauds it’s almost always ‘something’.
    • Even a basic task assignment can become a fiasco because the fraud is trying to learn on the fly and find any way to make something work for now, regardless of performance or scalability or sustainability.
  • An actual Power BI consultant would follow a methodical process of checking various areas/aspects of a solution and relatively quickly share findings and resolutions.   

• All-or-Nothing for Everything
  • Incremental data refresh has been supported for some time and experienced dataset developers will likely also be familiar with custom partition-based processing scripts. Additionally, BISM Normalizer and ALM Toolkit have been around for years to support incremental deployments to Analysis Services models and Power BI datasets.
  • The Power BI fraud, however, is much less likely to consider or implement incremental data refresh processes (much less scripts) and will generally rely on overwriting an entire PBI dataset (data and metadata) via the Publish button in Power BI Desktop.

• Breaking Changes
  • An actual Power BI consultant is going to understand the implications of changes to data sources and the Power BI dataset and thus take actions to avoid any breaking changes from reaching end users. These actions include source-to-target documentation, SQL view objects per dataset table, and clear processes with the data warehouse and other teams on managing changes.
  • A fraud will regularly be caught off guard by the behavior and impacts of various changes. For example, since the fraud doesn’t use ALM Toolkit, a change may be deployed to a dataset that the fraud wasn’t aware of.
  • In troubleshooting the breaking change, the fraud will require hours or even days because either the technologies of the source layers are not well understood or because the solution is unnecessarily complex and convoluted. For example, a DAX measure may reference a dimension table which contains several calculated DAX columns which are built on the results of a complex Power Query (M) expression which, in turn utilizes a long SQL statement as its source.  
    • You may find my recent post on deploying (or avoiding) breaking changes useful for more details.

• Source Control
  • It’s perfectly reasonable to expect the consultant to understand and adopt whatever the company or team uses for source control such as Azure DevOps and git Repos.
  • If the consultant is completely new to terms and processes such as committing changes and creating branches and pull requests, there’s a significant probability the consultant has never been around a real IT/BI shop.

• DAX
  • Writing DAX measures that add to, remove, or revise the filter context, utilize variables, and implement common patterns such as time intelligence, semi-additive logic, and role-playing dimensions are all well within reason for an actual Power BI consultant.
  • For Power BI frauds, removing a dimension table from the filter context of a measure might actually be considered a complex issue or a ‘blocker’ that requires time to ‘research’.
    • Typically inexperienced Power BI developers will lean heavily on the FILTER and RELATED functions, even when they’re not needed and introduce performance issues. They also often use calculated columns and tables liberally with limited concern for the implications.
    • The fraud is almost certainly not going to be aware of or comfortable implementing calculation groups so as a consequence you’ll see many more measures developed than are necessary.
    • They may use the CALCULATE function even when it has no impact on the behavior of the measure, I guess because they see it being used often.

• Newer Features Not Utilized
  • Actual Power BI consultants follow the Power BI blog and Release Plans such that they’re able to take advantage of the latest features and plan for the future.
  • A fraud typically gets comfortable with several reporting features such as bookmarks and drillthrough pages but isn’t highly aware of what’s new or what’s coming in other areas of Power BI and how that could relate to the current project.

• No Solution Architecture
  • A real Power BI consultant is going to prepare a design document (probably several) that describes how permissions/access will work across the workspaces and premium capacities involved, how reports and dashboards will be distributed from workspaces to apps, how the dataset will be designed (aggregation table(s)?), etc.
    • Security and access requirements will be addressed very early on in the project lifecycle – at least the consultant will ask the right questions about roles and sensitive data.
  • The Power BI fraud doesn’t see the overall architecture or ask these questions in advance. To the fraud, it’s all and always about the visualizations and/or user experience. If you ask for a solution architecture or multiple reports and dashboards, the fraud may claim that ‘we’re still in a POC state’ or may try to consolidate many distinct visualizations into a very large Power BI report file with many pages.
    • The thought and planning of separating content into different reports (and types of reports) and dashboards helps separate the inexperienced report author from a more senior resource.

• Large local PBIX Files; No Parameters
  • If the Power BI consultant is developing with and storing the local Power BI Desktop file (.pbix) with many millions of rows (e.g. 100MB+ files), I would be a bit concerned.
    • You would normally expect parameters to be applied to the larger table queries such that a relatively small sample of data is loaded to the local file and thus opening, saving, and optionally editing the file is very fast.
      • Experienced dataset developers would have a deployment process and parameters configured such that the parameters in the Power BI service are set to load all the data.
    • Again, the Power BI fraud is not going to be very familiar with other layers of Power BI beyond report visualization so parameters and any tools/processes for deploying dataset changes may be foreign concepts.

• Permissions and Licensing Knowledge Gaps
  • A real Power BI consultant is going to know what permissions are associated with different use cases (e.g. view report, create report) and will ask questions to confirm that a user isn’t granted more permissions than necessary. For example, the consultant may ask for a security group of self-service report authors that will be granted the build permission to a Power BI dataset and and a security group that will have access to a published Power BI app.
    • The consultant will know what Power BI licenses or premium capacity are involved or required in each scenario.
  • A Power BI fraud is much more likely to just add users to the same workspace of the source Power BI dataset with member or higher role. The fraud will struggle to determine why a user doesn’t have access – searching the membership of an Azure AD security group, for example, is just not something a report author is typically familiar or comfortable with.

Please note that my project experience doesn’t touch all areas of the Power Platform or even Power BI for that matter. Therefore, there are likely many other signs or characteristics associated with other parts of Power BI that aren’t included in this list.

Again, though I used the term ‘fraud’ throughout this post, most of the time I don’t think a technical or legal definition of ‘fraud’ (including the intent to deceive) has occurred. Nonetheless, negligent misrepresentation of Power BI skill and experience levels is a very real threat to projects and potentially an entire Power BI environment for a company so it should be taken seriously.

As one indication of the prevalence of fraud or negligence, I would estimate that 15% of my project time over the past three years has been either A) assisting (basically training) other supposed Power BI consultants (with high bill rates) on very basic topics like those listed in this post or B) troubleshooting issues with their solutions which result from a limited knowledge of Power BI.

It’s wrong for companies to pay high fees for very limited technical skills and it’s usually not interesting or rewarding for me to have to re-factor their work or support their solutions when they break down. Hopefully this post contributes to some form of justice in which those who’ve invested the time to learn Power BI at a deeper level are rewarded and those who have not are exposed for who they are.

Wrapping Up

Thanks for visiting Insight Quest. I hope this long blog post was at least somewhat instructive on a topic that you don’t hear much about but that you know or have suspected exists. If interested in email notification for the next blog post, you can enter your email in the Subscribe widget on the homepage.