Home Page > Publications > Why BI Projects Fail

Why BI Projects Fail


Most of us have read statistics on IT project failure. Some estimate that as many as 65% of IT projects fail to be on time or meet expectations. I question that statistic because if it was true and we live in a risk averse world why would any IT projects be commissioned at all? But after having spent 5 years delivering BI projects at a Fortune 50 company, I can comment on several reasons why BI projects fail. While choosing the wrong technology may be a culprit, the far more common reasons for failure lie in softer issues. By understanding these pitfalls you will have a better chance at minimising these risks.

Lack of senior stakeholder buy-in
Lack of senior stakeholder involvement has proved fatal for many BI projects. Without managing expectations of the business sponsor, nobody in the business feels committed to a project. If a project is to be a success senior management and users need to be involved from the start, and throughout the development. Priorities within the business need to be set and the expectation of the senior management team must constantly be reviewed and adjusted every month.

Weak business case & overbearing power users
Companies should start with a solid business case for why they want BI, carefully considering requirements and strategically aligning BI with business problems. In many of my projects I saw BI solutions built for the power user and thus only a handful of data experts use it. Instead the BI solutions should appeal to the majority of employees and help make their work lives simpler, the power user capabilities should be considered at a later stage in the development cycle.

Changing data requirements & not anticipating change
As commented on zdnet, "(changing requirements) can be managed by using a scope document to hold peoples' feet to the fire. Trouble arises when we begin customizing vendor applications or those standard reporting applications that we created to better match individual needs. According to the report, too much customization rarely increases usability, but it surely will increase initial and ongoing costs." Many of the requirements that drove the implementation of the BI project will change within 6 months. BI systems evolve, and as users adopt it more readily, new requirements will surface. Ensure that your company is prepared for changing requirements and choose a flexible product. Provide for some contingency of 20-30% on the BI budget to accommodate changing requirements.

Disagreement on data definitions
When deciding to have one version of the truth across a global company, you can be guaranteed that some finance managers will define metrics differently across the business. It is paramount to have a strong steering committee in charge of the global data dictionary who will make final decisions on how, what and where data gets defined before entering the warehouse. Often if consensus is not established early on through strong leadership, end-users will become disenfranchised, and adoption of the BI solution will be slow and painful.

Lack of retained talent for data analysis
The success of a BI Project is directly related to the experience of the implementation team. As noted in tech republic, "The most crucial factor to the success of any BI (or any other software project for that matter) is the knowledge of how the company works and what is stored where. Business Analysts and Data Analysts who understand these aspects of the organization are worth their weight in gold, as they are the ones who will validate or refute the success of the BI implementation. Thus an intimate knowledge of the organization's policies, business practices, history, user demographics, customer demographics are the things that can never be outsourced and yet these are the crucial elements that ensure success of a BI project. No consultant is going to learn your complex business in a few weeks. Consultants should be used to provide technical skills and knowledge on the BI product, with a view to transferring as much of that knowledge to your team before exiting."

Immature outsourcing partners
BI vendors often oversell the product and their capabilities. Be aware of "the promised land", as far too often I have seen sales people promise functionalities that a product simply does not offer. So be vigilant when doing both product and vendor selection. Find comparable implementations and don't necessarily go with the cheapest option, but the one with the most relevant experience.

Lack of technology roadmap
Since you will be creating a single database from multiple disparate sources, you must have an architecture that acts as your roadmap determining how each data source will contribute and fit into your overall BI strategy. Without a solid foundation, you are likely to build just another set of chaotic reporting databases. The architecture is crucial in determining future maintenance costs and avoiding performance issues down the road.

Performance Considerations
If performance is not part of initial project planning a BI solution will very likely fail. I have seen systems take minutes, and even hours, to generate a simple report. If the system is unbearably slow, users will go back to MS access and Excel, where they can manipulate and extract data with fewer limitations. It is important that when you deploy the solution various layers of the data are segmented into datamarts to improve performance, and that you deploy limits on the data extraction tools both to avoid the database freezing, as well as someone from outside IT building rogue MS access databases.

Not enough training
Far too often BI solutions are deployed without a significant investment in training. How can you expect a cultural change away from spreadsheets unless the end users feel relaxed and comfortable using the new BI tools. For any success, it is critical that a structured training campaign across the organisation is quickly deployed to not only create awareness of new capabilities but also to give end users the confidence to use the tools. Success of a BI project should always be measured, in part, by the adoption rate across the end users. These are the most common reasons for BI project failure. A few final words of advice... Ensure that the choice of product will scale to support data volumes, user volumes and concurrency. It is also important that the BI product you have chosen offer the right level of reporting for your organisation. It is at the ground level that BI projects succeeds or fails; most arrangements stumble during operational execution, and not at the strategic level. The above mentioned reasons are not the only ones that affect the failure of a BI implementation, but in many studies and reports they appear near the top of the list. They are all linked and it requires strong talent to execute fearlessly on them. It is less about technical issues, and more about processes and people.  
 

Quick Contact Form
Company Name
Contact Name *
Telephone Number *
Email Address *
Message