Toggle Menu

Insights > Advanced Data & Analytics > Why Do Most Business Intelligence (BI) Projects Fail?

Why Do Most Business Intelligence (BI) Projects Fail?

It is frustrating to see a project fail, but even more frustrating to wonder what happened. Projects that fail for a variety of reasons often go way over budget and are delivered later than expected. The end results range from solutions that totally miss the mark on what the customers wanted to solutions that do […]


September 26, 2013

It is frustrating to see a project fail, but even more frustrating to wonder what happened.

Projects that fail for a variety of reasons often go way over budget and are delivered later than expected. The end results range from solutions that totally miss the mark on what the customers wanted to solutions that do not work at all.

None of this is good news. It gets even more complicated when the project is a big-budget, high-profile endeavor that leaves leaders disappointed, upset, and pointing fingers.  This is often the case with data solutions. All of this is code for using information (data) to make strategic decisions for your business, such as which new product to roll out, how and when to hire staff, or where to cut budgets.

BI often extends beyond just the IT team charged with implementing a tool or getting access to the data. It often includes C-suite executives, sales, customers and everyone else in between. All the more reason to get it right from the start.

This post will explore four of the common causes of failure of a BI project as well as opportunities to address those challenges before it is too late.

Reason 1: Too Much Data, Too Little Strategy

One of the first reasons a BI project fails can be traced to improperly establishing the initial approach. “Big Data” is a hot topic around Washington D.C., and many organizations from Maryland to Virginia jump in without asking key questions like:

  1. How will we use this data?
  2. What problem are we trying to solve?
  3. Who will be viewing the reports or end product?
  4. What decisions do they ultimately want to make using this data?

Many organizations take on an “if you build it, they will come” approach without first gathering the necessary requirements from the people who will be using the data. They will then pull every piece of available data from every possible source – without first vetting if that data is truly necessary and useful. The unfavorable consequence of having too much information is that the customer may be unable to conduct effective data analysis for accurate decision-making. Having a lot of information that is confusing to interpret – or doesn’t track the right things – can frustrate executives and tank an entire project.

Additionally, not having constraints or requirements for gathering data can adversely affect a project’s timeline. Many teams who follow this approach end up building massive data warehouses that can take months – or years – to complete before anything is delivered to the end-users. By then the underlying business value could have changed drastically or become irrelevant.

To avoid this pitfall, BI teams should first clearly define the project’s approach before building a data warehouse or selecting a tool. They should spend time talking to end-users to determine what end data they really need and how they plan to use the information. It is essential to deliver applicable information (and the right amount of it) to the most appropriate people, on-time, and in a way they can easily understand.

Reason 2: Poor Data Quality

Another common reason that BI projects can fail is due to problems with the data itself. Even the best data warehouse will provide undesirable results if the information quality is poor. Many teams encounter this situation when creating a data warehouse, only to discover the underlying data is outdated, incomplete, or based on antiquated sources (like manual data entry). In this scenario, BI teams often end up spending more time fixing bad data than doing the expert analysis they were hired to do.

To avoid this pitfall, teams should plan for and execute data quality analysis processes. For example, if report requirements indicate a reliance on location, look into the quality of the location data. Are City, State, Country, Zip Code, etc. available for each transaction? If not, what percentage of transactions have the data? Can it be derived from other information to fill in the gaps? Was any of the information entered manually, resulting in a mishmash of spellings such as Pennasylvania, Pennsylvania, and Pennslyvania?

If so, identify the extent of the problem and implement a solution such as a mapping table (with common misspellings mapped to the correct value) to increase the data quality. Finally, capture and promote the data quality metrics associated with reports so that end users understand the extent to which the data can be relied upon.

Reason 3: Limited Access to the Data

A BI project won’t succeed if there are too many barriers to accessing information. For example, having too many security requirements can stand in the way of delivering timely results to the people who need data to make decisions.

Sometimes due to the nature of the data, this situation cannot be helped. However, teams can combat this obstacle by focusing on getting just the data needed to provide the needed business value at the time (following the guidelines in Reason 1). In addition, teams can offer to obfuscate sensitive information if it is part of an existing data feed they would otherwise be able to use, or just pull aggregate information if that will meet the business needs while minimizing the security concerns.

Reason 4: Amazing BI Tools – That No One Likes (or Knows How to Use)

There are terrific BI tools and all of them can help you turn your company into a data-driven powerhouse. Plenty of options are available, from the basics of Excel’s PowerPivot, to the data discovery darlings (Tableau, SpotFire, QlikView), and even the enterprise behemoths (Cognos, BusinessObjects, SAS). Oftentimes organizations will fall in love with a tool as part of their BI initiative, purchase it, and then decide they do not have the budget to adequately train staff. Or they will invest in a tool selected by IT professionals, without consulting end-users on their needs.

Organizations using the wrong BI tools bring additional obstacles to project success. Staff members who do not like a specific product will often revert back to the “old way” of doing things – essentially making all your efforts (and money spent!) null and void. In other organizations, only one or two people will truly understand how to use a tool and create bottlenecks to progress, or become bogged down by numerous requests.

To combat this, you need to sell your BI solution within your entire organization. You may think that users will figure out the system if they want their data badly enough, but they will only adapt if it is something they agree with and can use. Otherwise, they will revert to antiquated, error-prone methods to get data – like someone else using the tool to pull the data for them. Plan ahead to train users on not only the tools, but also the data they can access via the tools.

The more you work to promote use of your BI solution and data in your organization in general, the more you are starting to create an information culture.

By being aware of problems with a project’s approach, data quality, or access issues, you may be able to avoid common pitfalls.

What other pitfalls have you seen on your BI projects?

You Might Also Like

Agile Transformation

Responding to Change Over Following a Plan: Agile Lessons from Antarctica

I spent the first part of January in Antarctica hanging out with penguins, whales, and...

Agile Transformation

Meet the Experts: Sarah Shirck

In this interview, Excella’s Change Management Xpert Sarah Shirck discusses the importance of empathy and...

Agile Transformation

Executive Storytelling, a Component of Large Scale Transformation

I frequently work with executives on their Agile Transformation efforts and one thing is certain,...