Business Intelligence Challenges and the Five W’s

http://insights.iolap.com/author/scrofts/

Steven oversees all aspects of the company’s day-to-day marketing, corporate communications, research and thought leadership for its rapidly expanding global consulting programs. Steven brings to iOLAP a strong background in marketing and executive management, with extensive experience in the business-to-business technology industry. He has spent a significant amount of his career in the Business Intelligence and Data Warehousing marketplace. In 1996 he became the President and CEO of the Data Warehousing Institute (TDWI), which he sold to 1105media in Los Angeles several years ago.

View all author posts →

As a much younger writer and marketing guy watching the database technology boom of the 80’s and 90’s, I was fascinated with the advent of the data warehouse surge that started about twenty years ago. I saw it coming and watched it bloom.

The promise of a “sandbox of meaningful data” for quicker and easier use by line of business managers was exciting. And, of course, the IT people loved it because it was new, getting a lot of hype, and the development money for big projects started pouring in. A lot of projects failed, but so what, we kept learning (and spending).

Somewhere along the line business intelligence (BI) crept into our technology vocabulary. Actually, it was Howard Dresner, who would later become a Gartner analyst and founder of Dresner Advisory Services, who proposed in 1989 that business intelligence could be an umbrella term to describe, in his words, “concepts and methods to improve business decision making by using fact-based support systems.”

A great marketing buzzword that tied everything together was born. Now we could put all of these platforms, technologies and processes under one umbrella. This new direction replaced older (but similar) phrases like “management information,” and “enterprise information.” But no matter, we were moving into a whole new day.

From the advent of business intelligence, things have evolved. Big Data has emerged, along with BI growth in the Cloud and on mobile platforms. Bigger, faster and better technologies have emerged. Amazingly talented consultants and subject matter experts have taken results to a whole new level. We live in a great age of data discovery.

Why Do So Many BI Projects Fail?

It’s an interesting discussion, given the fact that Gartner stated in a rather shocking report just a couple years ago that 70-80% of corporate business intelligence projects failed. How on earth, given the number of smart people out there working on all these things, could that many projects fail?

Upon further reflection and a little research work, these BI project failures bear quite a resemblance to most of the software development projects that enterprises have been doing over the last 5 decades. It’s all about writing software, and writing new software, especially with new technologies and techniques, has always required design and planning beforehand. And it appears that’s where we’re not doing too well. At least according to Gartner.

It also stands to reason that as we have developed our senses (and appetites) for better and faster information to make better and faster decisions, we might be rushed on the front end in doing that design and planning beforehand. At least that’s part of the problem. Fifty years of similar project failures reinforce the fact that it is a problem.

The Five W’s

Let’s look at it for a few minutes from today’s view of business intelligence and the need to drive better decisions through better information. Here’s where I think project teams could apply a simple concept taught in many classic journalism classes—something called the five W’s (who, what, when, where and why). Actually, a sixth question is often included and ends in “w” instead of starting, and that’s, “how.” These examples below are just the tip of the iceberg for a detailed “Five W’s analysis” that organizations could perform, but it’s a good starting point to get you thinking as you do project analysis and planning.

Information Technology departments (IT) should not define who sees important information. Business managers should specify this visualization environment within the company’s data governance rules.
IT should be less involved in defining what should be measured. Business managers are critical to making these decisions and help drive the strategy, particularly when defining what they want to have measured. For example, what is needed as strategic data for long-term needs, tactical data for shorter-term needs and operational data that impacts the bottom line?
IT should be very careful as they try to define when and how often data needs to be refreshed. Business managers know exactly when things change based on their intimate knowledge of complex business cycles relevant to the business case in development. In accounting alone there are pieces of operational data that need hourly or daily updates, but others are not looked at until the end of a month or a quarter.
IT should listen carefully to the full business situation when contemplating where the information is kept. While business managers should listen to and rely on IT expertise, some needs, such as transaction speeds and security concerns, play a role in determining the technical environment for these projects. These needs must be listened to by the IT team.
IT should not worry about why people think a certain pieces of information are important. Business managers know the context of data and the information it reflects. What seems completely confusing or strange to IT is probably completely understand by subject matter experts who are familiar with the “personality” of the corporation and its operations.
IT needs to be careful in defining how things should be measured. Business managers are the ones who must define very specific things like when revenue is measured, how inventory is valued, and hundreds of other business rules.

The Five W’s (and one H) were memorialized in Rudyard Kipling’s “Just So Stories,” written in 1902. He includes a brief poem that opens with:

I keep six honest serving-men

(They taught me all I knew);

Their names are What and Why and When

And How and Where and Who

Also known as the “Kipling Method,” he uses these questions to explore problems and challenge the results. Perhaps using some of these simple questions might help turn all the information into real and valuable business intelligence.

Flaws That Can Cause BI Project Failure

Using the Five W’s and an H “talking points” above, there are several common mistakes that continue to bubble up that cause problems for a lot of BI projects. As you read each one—think of how the Five W’s could impact its outcomes.

Lack of Business User Support. IT departments often push through, get budget for, and lead BI projects from a data-centric and technical viewpoint. When this happens, the business users can get confused as to its purpose. Business values are not obviously visible and despite a lot of work, the users don’t adopt the system. An interesting metric can emerge—and it’s not a good one—more people were involved in building the BI project than people who are willing to use it.
Failure to Frequently Tune BI Initiatives. IT development teams can fall into a trap of finishing one project and moving on to the next one as if corporate BI success is just a series of discrete project completions to “check off the boxes.” BI is really a moving target that reflects 1) the growth and strategy of the company, and 2) the growth and understanding of business users and the value of data now available to them. If the BI users start requesting a lot of changes, especially if the upfront work was quite adequate, it is not a bad thing. It means they are using the system and they are starting to think analytically about the business. Be smart and define a good review process that includes the right people.
Don’t Underestimate the Need to Find Culture Changers. There are still many companies that are loaded with Excel users who only feel comfortable with their existing download scripts that grab data from internal systems and then import into spreadsheets for their own manipulations and calculations. These are never shared and the proliferation of “information silos” continues. Confusion from different frames of reference means an unmanaged and unreliable view of the business. Make sure you have the right sponsors who believe that a corporate-wide (or at least business unit-wide) view of accurate, transparent data is paramount. Have the desire and strength to cut through political and personality barriers in order to change culture.
Lack of a Documented BI Strategy. Put a team together and write up a strategy document, including an assessment of where you are and road map that lays out where you want to go. Obviously, the team needs to have both business and IT members, but don’t make the team so large that “paralysis by analysis” sets in. Management by committee can come with its own set of problems, so pick the right people with the same overall business goals. Rock stars will emerge as well as others who don’t want to get on the bus. If they are not engaged, move on without them. They’ll usually be as glad as you that they are not part of the team.
Acknowledge Data Quality Issues. Talking about data quality is about as exciting as talking about the foundation of your house. But like the foundation, whose structural importance is very significant, data quality can be a make or break deal on BI projects. One of the quickest ways to kill BI project adoption is to have the users all sitting around questioning the answers they are seeing. Irrelevant, incomplete, inaccurate or questionable data are fatal flaws. Spend a lot of up-front time defining data quality issues and concerns and how to keep only good data inside the BI platform. Extra work up front will pay huge dividends.
Failing to Get Outside Assessments. There’s no doubt that you have smart people inside your organization—both on the IT and the business side. But sometimes everyone can get so close to the details that they fail to step back and look at the big picture. A good example of this is to simply buy a BI platform from your standard resource application vendor. BI platforms are not just a snap-in commodity that you plug in and turn on. To fully deliver the functions you want, based on your internal road map, you might be better served in ways you haven’t considered. Do not be afraid to get an outside consulting organization to come in and look at things—and be open to their ideas and alternatives. The depth and breadth of solutions out there is large and growing, especially in the Big Data and Cloud-based BI platforms. That extra set of eyes and hands can often pay big dividends.
Think Big but Act Small. Of course you want a good road map and overall BI direction, but we are all human and want immediate gratification now and then. Pick a project, or a component of a project, where some rapid prototyping/proof of concept can be done quickly to show people where the project is headed. Dashboards or other data visualization prototypes come to mind. These quick evidences give people a reason to be excited and to keep up the pace. Execution breeds confidence. In addition, this mentality also reduces project risks because issues can often be identified early and helps people understand the value of properly analyzing user requirements. Just remember: Scope, Prototype, Present. But get there quickly.

Summary

Flaws and failures have always been part of the technology world, and will always be there, but it doesn’t mean we don’t work hard to avoid them. As you look at some of the reasons for failure listed above, go back to the “Five W’s and an H” discussion and apply those to your project planning and analysis. You’ll find out that Mr. Kipling was on to something—even if it sounds a little old-fashioned today.