Business Intelligence (BI) Implementations go wrong more often than right. I’ve experienced this first hand and this post is going to outline the top challenges that get in the way of a successfully deployed dashboard at a lean tech startup.
In this post, BI encompasses reports and dashboards used for internal and external (customer-facing) purposes.
Business Intelligence Is More Than A Feature; It Is a New Layer to the Tech Stack
Often, BI is treated as if it were another feature. This means a developer will be assigned the task, with the requirements distilled into a JIRA ticket and an expectation for completion within a sprint. This way oversimplifies the process of deploying your first dashboard. What is missed is that BI functions like a standalone application. It requires it’s own tech stack and follows a development lifecycle.
For lean tech startups, running BI off of your production database may work initially, but this approach has serious limitations and will break frequently. As requirements evolve and data grows, the queries needed for reports will take longer to run and may time out. Queries will also get more complex to capture new and changing business logic. Additionally, more data sources will be needed for additional reports which adds another layer of complexity.
The BI Tool: A Critical Component, Not the Entirety, of the Data Stack
A BI tool should enhance the data stack, not constitute it. The initial step to the data project should be setting up a data pipeline and a data warehouse. These are critical foundation blocks for the BI tool. Connecting a BI tool directly to an application database has several risks and challenges:
- Performance Constraints: Source systems like MySQL or Salesforce are not designed for BI workloads. These systems are designed to retrieve specific data points and will perform poorly when you try and run queries that aggregate lots of data. A data warehouse is designed to aggregate high volumes of data efficiently which is a core use case for BI.
- Data Centralization: Having a centralized place to work with all your data from many sources is critical to operationalizing BI within an organization. Only being able to report on a fraction of available data means that teams will still have to resort to manual efforts to create reports. I am a big fan of using Google BigQuery as a centralized place because it’s cost-effective, performant, and has a great ecosystem to get your data connected.
- Economical and Secure: A big benefit of using a data warehouse like BigQuery is that it is serverless which means a team does not have to spend resources on maintance or scaling the database. Additionally, data warehouses come with other features not found in traditional application databases like row-level security which is essential for BI reporting.
Expedited Setup Process: The Need for Efficiency and Efficacy
Every BI tool looks the same when you look at the output. That’s not the differentiating factor for a BI tool. The difference is in the implementation and the data operations. A great BI tool is cloud-based and does not require you to manage infrastructure. I am a huge fan of Sigma Computing because of this point. They don’t store or process any data which makes the tool extremely lightweight.
When I was going through the selection process, I was amazed that tools like Tableau and PowerBI among other tools require you to bounce between a local desktop version and a managed server version. It’s incredibly clumsy and time-consuming to manage this. However, it is really common to see this type of setup for a BI tool. I’ve been a part of implementations where we were required to bring our own infrastructure which caused the project to never get off the ground. Setting up dedicated infrastructure is time-consuming, expensive, and requires a lot of ongoing maintenance. It would require a full-time developer which also adds to the total cost of the project.
The Importance of Having a Dedicated Data-Oriented Person Managing the Implementation
I am biased on this point but I think it’s crucial to have a data-oriented person at the center of the decision-making and implementation. Someone who is not data-oriented will not be able to outline requirements for a dashboard and will not be able to understand features of a BI tool in order to make the best selection. A data-oriented person will also be able to ask the right questions during the sales calls to better understand what it takes to go live.
Data projects do not have a finite ending. There’s a never-ending flow of requests for new reports and changes to existing reports. The traditional software engineering development cycle is too slow for BI and, in most cases, unnecessary. Changes to reports and dashboards need to be built, edited, and deployed fast. A slow deployment time can cause the project to fail because it uses too many valuable resources. This will cause the organization to take resources away from data projects and back to making product enhancements for the main app.
Lastly, building a dashboard is not purely technical. There’s an element of design that is needed to create engaging and effective reports. Without that skill, the output will be a bunch of data tables that provide no insight. I consider it a failed project if your output looks exactly like the output from a SQL query. The point of BI is to provide insights into your data.
Dashboards and Reports Need Clear Requirements and Defined KPIs
Once the technical hurdles are cleared, not having a clear requirement for a report will also cause the project to fail. I’ve been a part of a team where the technical obstacles were cleared, but when it came time to build the report, nobody knew what they wanted to build. This is a really important and complex part of the entire process that gets overlooked. We all want a nice-looking dashboard that has valuable insights, but it’s often invisible how much time it takes to get all the pieces in place. Internal stakeholders need to meet regularly to define key metrics in a report. This phase of the project is less technical and more design-oriented. This is where the report tells a story and provides meaningful insights.
Exercise Caution When Engaging with Consultants
Consultants often capitalize on complexity. Because the data projects are so complex, consultants can seem like a shortcut. However, it’s essential to assess their recommendations critically because oftentimes their interests are more aligned with upselling rather than the organization’s best goals.
I have been introduced to consultants in my journey and I have found two things to recurring themes. The first is that they sell technology that is outdated because data technology changes so fast. There is a lot of investment in the data space and new vendors pop up regularly. The second theme is that they would try to put me in a one-size-fits-all solution. Larger companies like Salesforce and Microsoft want your entire tech stack using their tools. While you can get a lot of efficiency gains that way, I prefer not to be locked into a specific vendor. The risk of vendor lock-in comes with higher price hikes at renewal and higher switching costs when a better technology emerges.
For lean tech startups, consultants can introduce more complexities and are usually too expensive. The need for consultants is becoming less relevant with the rise of better technology. I use Ascend.io which has created a robust app to elegantly handle all the complexities of building and maintaining data pipelines in a scalable way. A benefit of a vendor like Ascend.io is that you are not stuck with a custom-built solution that only the consultant knows how to configure.
Finally, as mentioned previously, data projects never end and it’s not solely about setting up a data stack. Report and dashboard building will be an ongoing effort and it’s key to have a dedicated person who knows how the data stack works and can continue to build reports with the organization’s best interests.
Final Thoughts
Challenges with BI implementations are widespread and you can check out numerous Gartner reports to understand the broader landscape. Here’s one.
Thanks for reading!