Six misconceptions about deploying BI applications and systems

Faulty project management assumptions can limit the effectiveness of business intelligence tools. Don't let them lower your return on BI investments.

Business intelligence systems provide a significant return on investment for organizations -- when they're effectively

designed, deployed and managed. But BI applications often have a more limited impact, and less of a payback, than they should.

Rick ShermanRick Sherman

Several data points help illustrate the limitations and shortcomings of many BI deployments.

  • A typical Fortune 1000 company implements six or more different BI tools.
  • BI technology hasn't become widespread at most companies; in fact, on average, the use of BI apps has plateaued at about 25% of business users over the past few years.
  • Spreadsheets remain the only truly pervasive BI tool.

In many cases, the success of BI systems has been constrained by some common misconceptions among BI managers and their teams about both the design and deployment processes. Let's take a look at six of those misconceptions and how they can hold back BI projects.

BI applications should be designed for the business power user. Power users are the most active BI users, and they can offer terrific insights on business needs and valuable feedback on the pluses and minuses of different BI tools. But the reality is that they don't represent the characteristics of a typical business user. It's the same as with new smartphones or other consumer technologies: The initial buyers (or users) are great to kick off adoption, but to be successful, products (or applications) have to reach out to a more mainstream audience. Too often BI systems are too complex or over-engineered for the mass of business users who just want to read reports or do simple data analysis through business intelligence dashboards. Companies can avoid this trap by becoming more inclusive and getting a variety of users involved in the planning and design stages.

Become more inclusive and get a variety of users involved in the planning and design stages of your BI project.

One BI style will satisfy all business users. Originally, BI deployments involved a bunch of static reports that were distributed to end users. BI has evolved greatly over the years and now includes a wide range of analytical tools and styles. They include dashboards, scorecards, ad hoc querying, data visualization, data discovery, self-service and mobile BI -- not to mention big data analytics, predictive analytics and other forms of advanced analytics. It's all too common for BI teams to assume that every business user wants to analyze data the same way, with the same tools. Users get frustrated when they're pigeonholed like that, and many revert to using their spreadsheets.

BI systems work best when IT departments run report factories. Some IT groups and BI teams believe that the only way to consistently provide high-quality and high-performance reporting capabilities is for them to control the development of all the reports that business users want to see. Although their intentions are good, the results are almost never beneficial to the business. An IT or BI team that believes it can create all the reports a business needs will quickly be overwhelmed, leaving it with an insurmountably backlogged report queue.

Self-service BI means you just need to give users access to data. At the other end of the spectrum from centralizing report creation are short-sighted self-service BI implementations. Self-service software offers plenty of potential business value and should be part of a BI portfolio, but it isn't as easy as it sounds. Many organizations get caught up in the self-service hype and think all that's needed for success is to give business users tools, grant them access to BI data and get out of their way. But users of self-service BI tools often need more support than expected -- on an ongoing basis. Also, self-service applications don't reduce the need to eliminate silos of inconsistent and incomplete data. If they persist, effective BI analysis will be a challenge.

Business users know exactly what they want before a BI project begins, and those requirements won't change. The time-honored tradition of gathering requirements from business users, creating specifications based on those requirements, developing applications from the specs and then giving users a look at the resulting software makes sense for a lot of applications. But it doesn't always work well on BI projects. Often, the traditional approach ends with users saying that the BI applications you've worked so hard to build don't give them what they need. They might not have had such a solid grasp on the business needs to begin with -- or those needs might have evolved during the months (and months) it took to finalize the applications. An Agile BI approach, with incremental rollouts of features and functionality, could be more fruitful. At the least, you should keep in close contact with users all along the way so you don't get blindsided by changing requirements.

More on managing business intelligence projects

Get best-practices advice for business intelligence success

Read about BI's growth to mass-market availability

Learn what myths affect business intelligence managers

Spreadsheets will no longer be the tool of choice for BI analysis. Organizations have a love/hate relationship with spreadsheets when it comes to BI. For IT and BI managers, spreadsheets should give way to business intelligence tools, which offer increased functionality for users and better management capabilities for BI teams. But users will quickly go back to their spreadsheets if they think BI software is too difficult to use or if they see limitations in the analytical capabilities provided by BI implementations. The solution to this quagmire is to adopt spreadsheets as part of a BI portfolio and support their effective -- and judicious -- use. The problem now isn't that they're being used for BI purposes -- it's that they're being used for the wrong things and in the wrong ways. For example, users shouldn't be copying data from various sources into Excel and integrating it in worksheets, then manipulating the data and doing analyses on their own versions of information. That's a recipe for creating data inconsistencies -- and inconsistent BI findings.

BI systems can pay big dividends if they're built and managed properly. The goal of a BI project isn't to deploy the tool with the most features; it's to produce the maximum amount of business value possible. There shouldn't be any misconception about that -- and avoiding the ones above will help you deliver what you've promised.

About the author:
Rick Sherman is the founder of Athena IT Solutions LLC, a consulting and training services company that focuses on business intelligence, data integration and data warehousing. Sherman is also an adjunct faculty member at Northeastern University's Graduate School of Engineering in Boston, and he offers advice and analysis in his blog, The Data Doghouse. Email him at rsherman@athena-solutions.com.

Email us at editor@searchbusinessanalytics.com and follow us on Twitter: @BizAnalyticsTT.

This was first published in September 2013

Dig deeper on Business intelligence project management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Related Discussions

Rick Sherman, Founder, Athena IT Solutions asks:

How well-managed are the BI programs in your organizations?

3  Responses So Far

Join the Discussion

8 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchDataManagement

SearchAWS

SearchContentManagement

SearchCRM

SearchOracle

SearchSAP

SearchSQLServer

Close