Why BI projects fail -- and how to succeed instead

You can't simply shop for a BI solution and expect good results -- you need to think through your strategy first. Here's how to go about it

Business intelligence projects tend to suffer from a fundamental lack of strategy. Many companies think of BI as a tool choice, meaning they treat it like an operating system or virtualization technology decision. Hey, it's a software package, right?

In reality, a BI project may involve several different tools: a real “BI” tool, a tool for simple dashboards (which may not be the same thing), an exploration tool for querying the data, and a “quick hits” tool like Tableau. However, the tool choice is the icing, not the cake -- and this is expensive icing to eat without first figuring out the ingredients.

A successful initiative starts with a good strategy, and a good strategy starts with identifying the business need. The most valuable BI initiatives unite information and technology so that the insights gleaned directly reflect the extent to which the organization’s strategy is working and supports better decision making.

The balanced scorecard is one popular methodology for linking strategy, technology, and performance management. Other methodologies, such as applied information economics, combine statistical analysis, portfolio theory, and decision science in order to help firms calculate the economic value of better information. Whether you use a published methodology or develop your own approach in-house, the important point is to make sure your BI activities are keyed to generating real business value, not merely creating pretty, but useless, dashboards and reports.

Many companies seek to become “data driven” without a clear understanding of what it means. I had one client describe itself this way, then tell me directly after that they had avoided a huge scandal based on their risk team’s ability to sit down and judge a person’s character by looking them in the eye. An executive team needs to have a real heart-to-heart, then decide what data they usually look at, what decisions they make based on that data, and how they decide to go the other way. The next management layer down needs to do the same.

Next, ask: What data do we wish we had and how would that lead to different decisions? The answers to these questions form top-level requirements for any BI project.

Another huge mistake is failing to pick the right team. Many companies punt on this for political reasons and either “invite the world” or build a “coalition of the willing” (usually those who jump in from the initial invite-the-world meetings). Instead a team of data experts, data analysts, and business experts must come together with the right technical expertise. This usually means bringing in outside help, though that help needs to be able to talk to management and talk tech. Bringing in 100 “tool experts” who really know [insert your BI tool here] won't help if no one can talk up and down the stack.

This all sounds great, but what if the data is strewn across disparate systems? A successful BI project does not forget about either business integration (more later) or data integration. (Note: Do not buy any of those virtual schema meta-matrix products; they all suck.) This is where Hadoop, data lakes, enterprise data hubs, and data warehouses are not only trendy, but essential.

Nothing makes an IT department more nervous than asking for a feed to a key operational system. Moreover, a lot of BI tools are resource hungry. Your requirements should dictate what, how much, and how often (that is, how “real time” you need it to be) data must be fed into your data warehousing technology. As part of the pitch, you promise IT to stop doing point-to-point and start with hub-and-spoke integration to the data lake.

In other words, you need one big feed to serve all instead of hundreds of operational, system-killing little feeds that can’t be controlled easily. It's very difficult, despite what BI salespeople say, to give easy access to your data without toppling your operational systems unless you've deployed a data lake or a data warehouse to shoulder the load.

Based on the business requirements and the technology you need to support (Hadoop, Teradata, or whatever), you can finally get down to picking your BI tools. Which support the type of data analytics you’re after? Who in your company will use them? A lot of BI tools require system experts to be intimately involved, whereas others are so simple a business analyst with rudimentary SQL skills can use it. You'll probably need more than one tool to suit all of your use cases.

You did your homework, identified the use cases, picked a good team, started a data integration project, and chose the right tools. Now comes the hard part: changing your business and your decisions based on the data and the reports. Managers, like other human beings, resist change.

Moreover, BI projects shouldn't have a fixed beginning and end -- this isn't a sprint to become “data driven.” A process is needed to reduce the number of useless reports (which can only be identified through disuse) and find new opportunities in the data. Sometimes this is serendipitous, sometimes it is an intelligent manager asking not only what but why when they see something they don’t understand.

Here's the bottom line, in a handy do's-and-don'ts format:

  • Don’t simply run a tool-choice project
  • Do cherry-pick the right team
  • Do integrate the data so that it can be queried performance-wise without bringing down the house
  • Don’t merely pick a tool -- pick the right tools for all your requirements and use cases
  • Do let the data change your decision making and the structure of your organization itself if necessary
  • Do have a process to weed out useless analytics and find new ones

Execute well, and you might have yourself a successful business intelligence project.

Copyright © 2014 IDG Communications, Inc.

How to choose a low-code development platform