Six Reasons Business Intelligence Projects Fail to Fully Deliver
In working with clients, we periodically encounter business intelligence (BI) initiatives that have, for whatever reason, failed to live up to expectations. They simply aren’t providing the business value that was anticipated. Often, an interesting characteristic is that there are different yard-sticks used to measure success. The business needs actionable information, but IT may be more focused on their up-time statistics than how strong the BI system impacts the business. Here are six of the most common reasons we see that BI systems fall short of expectations.
If you build it, but…no one comes.
Solid alignment with business objectives and strategy is critical to adoption of a new BI initiative. After all, it will take at least some amount of time and effort to learn about a new BI tool, and to change existing work processes and patterns to take advantage of it. Done correctly, BI is disruptive. Sometimes the BI system is conceived by a well-meaning IT department that focuses too much on the technology, and not enough on solving specific business issues. The result may be mis-aligned from what is really needed, not taking advantage of specific business opportunities that are important to business stakeholders.
Lesson: Bring business stakeholders in early, and leverage BI to address their specific needs. Involve them in the process to build alignment, ownership, and momentum.
Things that go bump in the night.
Sometimes, the reliability of the BI system causes business stakeholders to abandon it. Do your ETL processes frequently fail? Do you regularly field questions from stakeholders like “When will the data warehouse load complete?” If data is not provided in a timely fashion, stakeholders will not rely on the BI system, and will develop workarounds. Lesson: Invest in making ETL a solid, reliable, resilient process. That includes the way the process is architected and developed, as well as having servers and associated hardware that are up to the task. Don’t scrimp on memory, processors, etc.
Crisis of confidence.
So, your BI system is attacking a meaningful business problem, and it reliably loads fresh data nightly. Great. But if the stakeholders feel that the data value are not correct or reliable, they will hang on to old spreadsheets and manual downloads. It is possible that business rules were not implemented correctly in ETL. It is possible that there are exceptions no one told the BI team about. Whatever the cause, it must be corrected. I have found that often, when the new BI system disagrees with a historic report, more often than not the new BI system is actually correct. After all, stakeholders have just re-hashed/confirmed the business rules. Sometimes the old reports have outdated rules in them that are left over from discontinued business practices. Even in this case, when the BI system is actually correct, business stakeholders may still lack confidence in the numbers simply because they are different. Lesson: Spend plenty of time reconciling the BI system back to known, trusted sources and reports. Be able to explain why there are variances. You may drive out problems with the new system or problems with the old one. Either way, it’s a win.
Are we there yet?
Most companies get that BI is about being nimble, responding quickly to changes in the business landscape. Yet some BI teams still organize their projects in such a way that it can take a year or more to get results to the business stakeholders. And then, as the business changes, the approach is not nimble enough to keep up. Lesson: Create a BI roadmap up front that guides development in short phases, delivering solid business value at the conclusion of each phase. The length of phases will vary depending on the team and technical environment, but if it is more than 60 days between major deliveries, rethink your delivery approach.
Your only tool is a hammer.
In the old days, stakeholders were thrilled if they could get a report that generally contained what they wanted. Often that report was dumped into Excel and further manipulated. In other words, the report was the starting point, not the completed information the business actually required. Today, however, reports are never enough. In fact, we recommend minimizing the number and use of reports in favor of other tools like data discovery, visualization, and dashboarding capabilities. It is possible to have way too many tools in your toolbox, each requiring skills, training, and infrastructure to support. But equally bad is having only a single tool that creates static reports. Lesson: Map out the ways your stakeholders can interact with the data. Ensure that the tools in your tool box allow dashboarding, visualization, discovery, trending, as well as traditional reporting. Learn to match each capability with specific usage scenarios in order to truly drive the business forward.
Wrong team skills.
BI is very different from standard application development. All data is ugly. Developing ETL code can be hard. The kinds of challenges we must address in a BI system are very different from those in other kinds of development, such as transactional systems or web portals. Do not expect success in a BI program if it is staffed by people who have never done BI before. From the way requirements are gathered, to the way the project is managed, to implementing business rules, to performance tuning, to the approach to testing and validation, not to mention the user interface, almost nothing is the same as traditional application development. Lesson: At a minimum, the Business Analyst, Data Modeler, and ETL Developer, as well as developers in any presentation-layer tools should be experienced on several BI projects. These skills can be learned, but it is a very steep learning curve without a guide. If you don’t have those skills on staff, consider hiring experienced team members or leveraging outside services to lead and mentor.
If you evaluate your BI program against these six areas, you will greatly increase its value, and avoid many potential pot holes along the way.