Based on which source you look at, a staggering 70-90% of all business intelligence (BI) initiatives fail. With such a high likelihood of failure, why would any company continue to move forward with spending the money and resources on these initiatives? Well… imagine every critical decision made in your company, from multi-million-dollar strategic decisions on down to daily operational ones, being made based on current data. No more best guesses, rooted in experience, hunches, or wind direction. Giving your company the on-demand ability to quickly draw data and perform analysis on it enables them to make the most informed decisions possible. In aggregate, the benefit of your team being able to do this would be immeasurable. It also represents the one competitive edge over your competition that you have complete control over. It is for these reasons that companies rightfully continue to spend significant time and capital on business intelligence initiatives.
If we were to find a silver lining in all of these instances of failure, it would be the well-documented trail of what not to do. I've taken some time to review writings about this and, combined with my own experiences as a business intelligence developer and eventually an executive, to draw my own conclusions on the most likely failure points and more importantly, how to avoid them.
Lack of Sustained C-suite Support
It all starts here. The vision of how business intelligence is used and implemented throughout the company begins at the executive level. Step one of executive involvement should be to form a steering committee. Select key stakeholders from your business leadership, your analysts and your technical teams. With your guidance, the steering committee will: 1.) drive the prerequisite business requirements gathering process (more on this later), 2.) own the software and/or vendor selection process and 3.) make all strategic decisions on the implementation. But executive involvement doesn't end there.
Once the implementation starts, the c-suite needs to stay engaged throughout the lifetime of the project. Executive-level involvement, in anything, sends a clear message to all involved that this is important and team members will be held accountable. Can your project still succeed with reduced executive-level involvement? Perhaps, but don't forget the odds we're talking about.
Too Large of a Scope
Based on my own experience, this is the clear number two cause of failure and in many cases, it can undo strong executive-level support. Trying to implement a business intelligence solution across too many different business units at the same time, or worse yet, the entire company is an expensive failure waiting to happen. There is a multitude of reasons as to why.
While this aspect is often overlooked, it is critical. A BI implementation is only as good as the underlying data supporting it. Ideally, that data is stored in a data warehouse, which has been optimized to support analysis. It is fair to assume that your BI implementation is going to provide you with information that your company has not been able to produce in the past. That being the case, your underlying data warehouse will at the very least need to be architecturally reviewed, possibly modified, or in some cases redesigned. Now put this within the context of trying to implement BI across large parts of your company. The requisite task of reviewing/modifying your databases has now become exponentially larger. In many cases, this will be a bigger time commitment than the actual BI tool implementation.
Another added challenge with taking on too large of scope will be supporting all the logistics behind installing the application for clients. Moving too many users to a new app, increases the likelihood of overwhelming your support staff, even if done in phases. There will be issues with installations, it is inevitable given no two PC's are configured identically. These bugs will be worked out, but it takes time.
Training will be an even larger logistical challenge. Scheduling and supporting training for a large part of your company will require significant time and resources. Training everyone at the same time also does not cultivate the development of power users, who would be able to help others in your company learn how to use the tool.
Far and away, the best solution to avoiding all of these challenges is to set up a proof of concept. Along with your steering committee, select a strategic group that would: 1.) benefit greatly from a BI tool, 2.) currently performs analysis, 3.) is moderately sized, 4.) is technically proficient. Ideally, this group would already have a high-value analysis capability in mind that a BI implementation could provide them.
By going forward with a proof of concept approach with a group like this, you should be able to see a working prototype of your BI implementation in a much shorter time frame. If the implementation is successful, you have the added benefit quickly seeing a positive effect on your bottom line. Given that the group you have selected is technically proficient and already performs analysis, it is most likely that they will continue to learn and explore the capabilities of your new BI tool as they continue to do analysis, becoming power users along the way. A successful implementation should also create a positive environment for acceptance by future users.
The prototype approach will also allow your team to benefit from lessons learned. Kinks in logistics can be identified and addressed before future roll-outs.
Lack of Well Thought Out Business Requirements
This is the bane of virtually any technical implementation. It is perhaps more difficult to articulate in the case of business intelligence functionality given the dynamic, situational nature of the analysis. Regardless, this is an absolute dependency for a successful business intelligence implementation. Until you can define what your needs are, you should not be spending a penny on a BI implementation (or any implementation for that matter). This is especially true when you are dealing with a vendor. You are setting a bad precedent if you begin to meet with vendors without a business requirements document in hand.
Making it Too Much About the Technology
This holds true for both the tool selection process as well as the implementation. The needs of your company as defined in your business requirements always come first. While it would be nice to have the best in class business intelligence tool that your industry's market leaders use, it will do you no good if it is poorly implemented. Vendor led implementations are especially susceptible to this, so be vigilant about enforcing the client/vendor hierarchy and your priority of functionality over bells and whistles.
Bad Data (or Perceived Bad Data)
This point expands upon the data architecture review topic I referred to earlier. Before rolling out your new BI application to users, the underlying data must be correct. Nothing will kill a BI implementation quicker than users not trusting that the data they are working with. Do not assume that because your BI tool will be pulling data from a well-vetted data warehouse, it will be correct. Your user testing should be verifying that data is being pulled from the underlying data sources correctly. Also, users who are new to pulling their own data may not be used to nuances as in regards to how they should be pulling it. For example, the difference between year to date sales based on calendar month-end versus fiscal month-end. If your user community is going to include people new to working with data, this should be addressed in your training programs.
Conclusion
This list is by no means exhaustive, but it highlights, in my view, all of the primary causes of failure. Depending on a number of variables specific to your company, you may have modifications or additions to this list, but your company's odds of having a successful business intelligence implementation will be greatly increased if it can avoid the failure points I've laid out.
Please contact me galen@vectordecisionsupport.com if you have any questions on this blog post. I would also love to hear about any shared experiences. And, if you should decide to move forward with your own business intelligence implementation, I hope you have found this useful and I wish you all the best.