Three Mistakes to Avoid in your Business Intelligence Project

Imagine you're about to go on a large expedition that will cost millions of dollars and over a year to complete. You plan to get it done in six months, so you choose the company's best people for your team and you purchase the best equipment. You're getting ready to start, but then you read a study that says you have more than a 50 percent chance of failure on this expedition. Would you still take the journey?

Related: What Is Business Intelligence?

This is exactly what happens when businesses embark on business intelligence (BI) projects . They usually hire the most expensive IT employees or consultants and purchase the best equipment for their year-long journey. The journey can cost millions, but a Gartner study in 2005 reported that more than half of BI projects fail. Unfortunately, the situation hasn't improved since that survey was taken. A more recent Kognitio survey shows that two-thirds of businesses still fail to receive value out of the BI system they install.

During the gold rush, many pioneers headed out west, even though there was little chance of seeing gold. Similarly, many companies have been embarking on a risky BI journey, even though there's a low chance of success. Why? If mined properly, there's gold in the data that can help the bottom line and add new customers. In other words, a $1 investment might yield $10 in return. The consolidation of a company's data sources into a single data warehouse can alert you, for example, that a customer's order placed online yields a negative return in the general ledger system after all costs are accounted for. It can also help you prepare for data mining, which can reduce marketing costs and further focus an organization on the best customers to pursue.

But why are organizations failing so miserably to achieve business value from or even complete BI projects? This is the question that our consulting company has been working to answer the past five years. I'll share the biggest reasons for failure that we found and the guidelines we've used to build entire prototype BI projects in as little as a week. By following some of these guidelines, you can avoid mistakes that can lead to your BI project failing.

Related: Business Intelligence Explained for the DBA

Mistake #1: Project Scoped Too Large

We often inherit BI projects that have already been attempted by businesses or other consulting companies. The number one mistake we see is that the business has bit off more than it could chew. Because BI projects can take 6 to 12 months to complete, many businesses look at them as an enterprise waterfall project. As such, they spend 3 months on planning before they set off on their journey. After three months of planning and only a few months of coding, the project fails because the business has not seen any business value yet and there's no political appetite to continue funding that type of project.

Instead, you should think iteratively. Break your BI project into two- or four-week iterations and deliver an entire solution every iteration. We use the Scrum methodology, which forces the business leaders and technologists to meet at each iteration and talk about what IT has delivered in that iteration. This gives the business leaders control and the opportunity to reprioritize the work prior to the next iteration. The iteration review meeting should include:

In addition, there should be a daily meeting for the BI project team members and any interested business partners. In this meeting, only three questions should be answered:

1. What did you accomplish since the last meeting?

2. What are you going to accomplish until the next meeting?

3. What roadblocks do you presently have?

The project manager's job then becomes to remove the identified roadblocks.

People will stop coming to the meetings if they stray past those three questions. Each meeting should last no longer than 10 to 15 minutes. However, you should reserve a few minutes after the meeting for side discussions with interested parties.

I've managed development teams using this methodology and the teams went from floundering without a purpose to overachieving in just a few months. It works even better with BI because you're showing the business leaders true value every iteration and they can make course corrections on the fly if needed.

So what's the downside? Well, rapidly moving teams might not have perfectly defined requirements and might make wrong assumptions. However, no matter what methodology you use, every project is going to need course corrections and you can do them quicker with an agile methodology like Scrum.

Mistake #2: No Business Sponsorship

Imagine you're in the construction industry, building a massive skyscraper. In the midst of this project, you decide to add terraces to each floor (which will mean months of delay), without checking to see whether they're needed or even wanted. Without strong business sponsorship for your project, this is exactly what building a data warehouse is like. The builders might add unnecessary elements that delay the project's completion.

Although the idea to build a data warehouse will most likely originate from CIOs or IT staff members, they should never be in the driver seat of a data warehouse project. They can be the nagging spouse in the passenger seat navigating, but the business leaders should take control and drive the project, making decisions such as what areas to tackle first.

However, when you develop your BI project, you need to make sure you have a business leader who is an advocate for the data warehouse project. Have you ever been to a meeting where three people brought different reports with three different numbers, leaving the participants wondering (or arguing about) which number was correct? When completed, the data warehouse will fix this problem, but until then, you need an advocate in the business driver seat to ensure that any rogue reports die and that there's only one version of the truth.

Mistake #3: Not Addressing Data Quality Problems

All companies have some data quality problems, but many companies don't realize how bad the problems are until they embark on a reporting project to view a consolidated picture of their customers or product sales. In a 2011 InformationWeek survey of CIOs , 55 percent cited data quality as the biggest barrier for companies implementing successful BI solutions. In development, there's the notion of technical debt, where you continue to make technical compromises in order to get the project complete. Data quality is the biggest technical debt we see in BI.

For example, a company might have three systems in which customers' names are formatted differently. One system might use the format "Brian Knight," another might use "Brian S. Knight," and the third "Knight, Brian." Because these systems don't talk to each other, there's no master record. As a result, reports run from these three systems aren't consistent. More important, when you bring the three systems together, you potentially will be reporting three numbers for the same customer instead of consolidating the information.

One fix for this data quality problem is having a staging area where you can transform your data. SQL Server Integration Services (SSIS) has a number of ways you can easily do this. One is a fuzzy grouping component that can consolidate your data, even if the data is formatted differently. You send three versions of Brian Knight into the component, and SSIS will let you know which record is the master record and which two are the duplicates. There's also a new component in SSIS in SQL Server 2012 called the DQS Cleansing transformation, which ties into the Data Quality Services (DQS) component of SQL Server. With DQS, your data steward, business analyst, or quality assurance (QA) team can build business rules around what is good and bad data. SSIS will then follow those rules as data is being transformed.

Another fix is to stop kicking the can down the street and confront the problem head-on with a master data management strategy. This fix might take several months to implement if there are politics at play—each group might fight to have its record be the master so it doesn't have to change its system. Microsoft has built a solution to that end in SQL Server called Master Data Services (MDS), which provides a platform upon which to build a master data management strategy. With MDS, you fix the record in Excel, and MDS pushes the master record through your enterprise to the various systems.

Beat the Odds

Nothing delivers business value better than BI. It helps organizations find new customers and enhance the customer relationships they already have. Most important, everyone is marching with the same numbers. However, despite all that value, most BI projects fail. To avoid failure, you need to break your BI project into two- or four-week iterations so that you start realizing its benefits the first month. You also need a business leader who is an advocate to ensure that everyone is marching to the same numbers. Finally, you need to address data quality problems over a few iterations of the project so that your new reports will be consistent and not contain multiple versions of the truth.