Top 5 Reasons Why Your Business Intelligence Project Will Fail

1. Lack of business support; BI projects set themselves a much higher bar compared to “normal” projects. When (and I intentionally exclude “if”) the project is delayed, or fails to fully meet the expectations it sets for itself, having the support of people with a decision making capacity is critical.
2. Poor data quality; Other than lack of business support, nothing kills a BI/Data Warehousing project quicker than poor data quality. Other systems may be able to hide poor quality data, but it’s fully exposed in a BI solution. The two most common outcomes when dealing with poor data quality are ETL processes failing, for example, duplicate primary keys from unexpected data patterns, and decisions made on the basis of incorrect data. In such cases, the reliability and accuracy of the system will be questioned, and the business will then start to question the investment in the system itself. See point 1.
3. Trying to be all things to all people; Promising the business a swift passage to the land of milk and honey often leads to disappointment when the high expectations cannot be met. Terms such as “Data Mining” and “Predictive Data Analysis” roll off the tongue, and powerpoint presentations make these things seem dead simple; the reality of course is that they’re difficult to implement properly, and very few projects deliver on the promise sold to the business.
4. Early release of Ad-Hoc reporting tools; Continuing on from the previous point, projects that try and solve every problem ASAP often fall into the trap of releasing ad-hoc reporting tools (e.g.; Microsoft Report Builder) early, convincing themselves that the users can help themselves to the data however (and whenever) they like it. The problem of course, is that trying to build report models that enable such user access whilst avoiding performance problems and user frustrations is very difficult. Further, letting users help themselves often means that the ability to capture business requirements (and therefore build an appropriate BI solution) is compromised. See my previous post on this topic, Herding Cats: Dealing with open ended reporting requirements.
5. Not employing BI specialists; BI specialists are hard to find (and they’re typically expensive). There’s a world of difference between designing a database, designing an application and designing multi-dimensional cubes (properly). Don’t fall for the trap of expecting a DBA or .Net developer to pickup the skills needed, and therefore save money on staff overhead.

Antidotes to the above;

1. Identify an influential sponsor early, keep them regularly updated of progress and risks, and give them the information they need to communicate to the rest of the decision makers.
2. Ideally, ensure the source systems have a rigorous data validation module (DVM) built into them to prevent poor data from becoming an issue in the first place. Failing that (almost always the case) ensure the BI solution’s ETL processes cater for a vast array of potential data quality issues and either prevent dubious data from entering the BI solution, or build data quality reports to communicate the problems back to the administrators of the source systems.
3. Start small. Be agile. Be realistic. Fully solve a small number of business problems properly before attempting to solve everything at once. Use your business sponsor to spread the word, and feed off the early successes.
4. Resist the temptation to release ad-hoc reporting tools as long as possible. Understand the business requirements for user reports, and build the appropriate canned reports or cubes to meet those requirements. Such solutions are much more controlled, and therefore have a much better chance of meeting the performance and functional expectations of the largest number of end users.
5. Engage with appropriately qualified BI specialists as soon as possible, ideally those that have experienced failure on a previous BI project. Their skills and experience will save you a massive amount of time (and money) in the long term, despite the short term spike in staff costs.

Comments

[we are cloud]

hi, we enjoyed your post so much that we included it on our list "Five top fives in Business Intelligence".. check it out here! http://bimehq.com/business-intelligence/top-five/